IRC channel logs

<damo22>youpi1: i dont think we need that pmap==kernel_pmap change because MARK_CPU_ACTIVE() already calls pmap_update_interrupt() on itself as if it got interrupted, if its coming out of idle

<damo22>with the change reverted, it calls the updates much less frequently and only when needed

<user_oreloznog>o/

<youpi1>damo22: but what if the kernel is not idle, and busy doing some stuff? How will it flush its tlb?

<damo22>youpi1: the kernel is a task too isnt it? can't it be interrupted?

<youpi1>it's a special kind of task

<youpi1>e.g. when switching from user to kernel, there's no cr3 change

<damo22>the kernel does not need to flush a tlb, only a cpu does?

<youpi1>I agree that it's useless to shoot down tlb when the cpu is idle, because it'll know to call pmap_update_interrupt, but that's not the only case that the pmap==kernel_pmap test triggers

<youpi1>sure

<youpi1>but here we're talking about the kernel pmap

<youpi1>so all cpus are concerned

<youpi1>if one cpu does some virtual memory mapping in the kernel space, all cpus need to be aware

<youpi1>one exception would be pmapwindow, which is completely temporary, and thus other cpus don't need to be aware of it

<damo22>perhaps the macro call to signal_cpus needs to be altered such that it will signal all other cpus whenever the kernel_pmap is involved

<youpi1>oops, re-reading the pmap==kernel_pmap change, it actually is about cpus_idle

<youpi1>scratch what I said

<youpi1>that's the problem when you don't take the time to read what you're talking about

<youpi1>ACTION just out from bed

<youpi1>we however need to make sure it's properly synchronized

<damo22>#define PMAP_UPDATE_TLBS(pmap, s, e) ... seems to signal_cpus when its needed

<damo22>it signals all cpus using a pmap except itself, and then flushes itself if its needed

<damo22>the kernel cannot be busy doing something else, because this is the kernel code?

<youpi1>the kernel can be busy doing something else on other processors

<damo22>ok so it has other threads, i forgot

<youpi1>I pushed the change to avoid IPI during idle

<youpi1>that being said, if it was a burden it means we have too many signal_cpus calls compared to what should be needed

<youpi1>and *that*'s what should be optimized

<youpi1>by tracking what kernel map updates may not have to be signaled to other cpus

<youpi1>e.g. mapwindow

<damo22>hmm yes

<youpi1>PMAP_UPDATE_TLBS probably needs a "private" parameter

<youpi1>that pmap_put_mapwindow sets

<damo22>is there any reason not to enable debug_all_traps_with_kdb by default

<youpi1>because traps do happen in userspace :)

<damo22>it only applies when kdb is enabled

<damo22>ok

<youpi1>I notably run buildds with kdb enabled by default

<youpi1>to catch issues there

<youpi1>but I don't want debug_all_traps

<damo22>ok

<youpi1>really, debug_all_traps is a rare thing one wants

<youpi1>damo22: I have just pushed an important fix

<youpi1>I don't know if the kernel was indeed optimizing in your builds, but that could very well go all wrong

<damo22>ok

<damo22>then cat gnumach-undef-bad; exit 2; else true; fi

<damo22>cpu_pause

<youpi1>I pushed making mapwindow not send IPIs, that should be relieving quit ea bit

<damo22>cpu_pause is a missing symbol

<damo22>Hurd server bootstrap: ext2fs[part:2:device:wd0] exec startup proc auth.

<damo22>{cpu3} ../i386/intel/pmap.c:1016: pmap_get_mapwindow: Assertion `map < &mapwindo

<damo22>ws[sizeof (mapwindows) / sizeof (*mapwindows)]' failed.Debugger invoked: asserti

<damo22>on failure

<damo22>Kernel Breakpoint trap, eip 0xc100d6d4

<almuhs>damo22: i'm waiting your fpu patch

<damo22>ok i can mail that in now

<almuhs>are there any new change to keep in mind?

<almuhs>yesterday I was testing upstream + init_fpu() line, and I get a harddisk loop en Qemu, and a crash after send IPI in a Thinkpad R60e

<damo22>almuhs: youpi has made some critical changes but master is currently broken, i can mail in my patch and a fix

<almuhs>yes, do it

<almuhs>received. How can apply these patches?

<damo22>save the emails as two text files, check out master, pull then git am patch1 patch2

<almuhs>ok, i will do it

<damo22>or you can just try this remote: http://git.zammit.org/gnumach-sv.git/log/?h=feat-smpx-slow

<almuhs>i will try too

<almuhs>upstream's master continues producing harddisk loop in qemu. Now i go to try your version

<damo22>youpi1: you rejected my patch, but master does not compile without it

<youpi1>current master compiles fine

<youpi1>that was just missing a #include

<almuhs>damo22: your version produce harddisk loop too

<damo22>almuhs: you should ignore my branch now and pull on master, use that

<almuhs>ok, i re-try again

<damo22>i need to test * c1da11e5 (HEAD -> master, zammit/master, origin/master, origin/HEAD) pmap: Make mapwindow per CPU

<almuhs>qemu seems keep in harddisk loop with upstream's master

<youpi1>almuhs: are you using in-gnumach disk drivers?

<youpi1>they're definiitely not smp-safe

<almuhs> https://pasteboard.co/q7gGSvdApRNf.png

<youpi1>and we don't want to take the time to fix them

<youpi1>yes, that's it

<youpi1>forget about it and use rumpdisk

<almuhs>i don't get install in SATA mode from Debian GNU/Hurd installer

<youpi1>then fix it ;)

<youpi1>or copy over a pre-installed image

<almuhs>i don't know how to fix the installer, but a pre-installed version could be a temporary solution

<almuhs>but only for Qemu

<almuhs>when i come back to my office, i will send yours the error which my thinkpad produce when i execute Debian GNU/Hurd installer

<almuhs>in SATA mode

<damo22>[ 25.7000050] cd0(ahcisata0:2:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) (using DMA), NCQ (31 tags)

<damo22>[ 26.0800050] blake2s: self-test passed

<damo22>[ 26.0800050] chacha: Portable C ChaCha

<damo22>hang in idle

<damo22>with -smp 8

<almuhs>what is that?

<damo22>rumpdisk's boot log

<damo22> 4 ext2fs (f59a8b60): (f5998548) .W.O.F(mach_msg_continue) 0

<damo22> 5 exec (f59a8a90): (f59983f8) ..SO..(thread_bootstrap_return)

<almuhs>the installer seems to work fine with SATA in Qemu. Now I go to my office

<damo22>good luck, im off to bed

<almuhs>I have this error when I boot with Qemu in SATA mode: https://pasteboard.co/O2jUVRrc0sbo.png

<almuhs>i've reinstalled Debian GNU/Hurd with SATA using latest installation image

<almuhs>youpi: what is your sata configuration in qemu?

<youpi1>-device ahci,id=ahci1 -drive id=root,if=none,format=raw,media=disk,file=/home/hurd,cache=writeback -device ide-hd,drive=root,bus=ahci1.1

<almuhs>this is the mine: https://pastebin.com/ATKKB63k

<almuhs>thanks

<almuhs>by any reason, now the installer detects my harddisk image as 2 GB

<almuhs>i'm downloading a pre-installed image

<almuhs>in real hardware, i continue with problems: the R60e doesn't load the installer, R61i load the installer but doesn't detect the disk (only detects the DVD), and T410 doesn't load the installer too

<almuhs>how can to fix it? https://pasteboard.co/WdKqKXklLBdH.png

<almuhs>I'm using this image https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd.img.zip

<youpi1>fix the grub configuration to pass sd0

<almuhs>it demands a fsck

<almuhs>and i don't get to execute it: fsck don't find the device

<youpi1>fix /etc/fstab then

<almuhs>how can i access to the image harddrive?

<youpi1>err, by mounting it ?

<almuhs>how can i mount an img file?

<youpi1>note the offset mount option

<youpi1>byu mounting it

<youpi1>moutn

<youpi1>bkldazyh

<youpi1>seee hurd/running/qemu.mdwn:

<almuhs>ok

<almuhs>almu@debian-t480s:~$ sudo mount -o loop,offset=1953792 hurd_qemu/debian-hurd.img /mnt

<almuhs>mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.

<almuhs> dmesg(1) may have more information after failed mount system call.

<youpi1>check your offset

<youpi1>according to the partition table

<youpi1>notice the sector size

<almuhs>Device Boot Start End Sectors Size Id Type

<almuhs>hurd_qemu/debian-hurd.img1 2048 1953791 1951744 953M 82 Linux swap / S

<almuhs>hurd_qemu/debian-hurd.img2 1953792 10239999 8286208 4G 83 Linux

<youpi1>notice the sector size

<almuhs>4G?

<youpi1>didn't you read the explanation?

<youpi1>see above

<youpi1>pastye *evertying*

<youpi1>otherwise I can't divine what your computer prints

<almuhs>almu@debian-t480s:~$ sudo fdisk -lu hurd_qemu/debian-hurd.img

<almuhs>Disk hurd_qemu/debian-hurd.img: 4.88 GiB, 5243928576 bytes, 10242048 sectors

<almuhs>Units: sectors of 1 * 512 = 512 bytes

<almuhs>Sector size (logical/physical): 512 bytes / 512 bytes

<almuhs>I/O size (minimum/optimal): 512 bytes / 512 bytes

<almuhs>Disklabel type: dos

<almuhs>Disk identifier: 0x46bda940

<almuhs>Device Boot Start End Sectors Size Id Type

<almuhs>hurd_qemu/debian-hurd.img1 2048 1953791 1951744 953M 82 Linux swap / S

<almuhs>hurd_qemu/debian-hurd.img2 1953792 10239999 8286208 4G 83 Linux

<youpi1>(13:22:27) almuhs: Units: sectors of 1 * 512 = 512 bytes

<youpi1>« Now take the number of sectors for the beginning of the partition and multiply it by the sector size. My partition starts at sector 63 and I have a sector size of 512 therefore my offset is 32256. For a start at 2048 the ofsset is 1048576. »

<youpi1>aren't these wiki explanation clear?

<youpi1>what needs to be fixed there?

<almuhs>i go to try with this

<youpi1>this = ?

<almuhs>« Now take the number of sectors for the beginning of the partition and multiply it by the sector size. My partition starts at sector 63 and I have a sector size of 512 therefore my offset is 32256. For a start at 2048 the ofsset is 1048576. »

<almuhs>i go to calculate my offset

<youpi1>ok, good, one second I was thinking you were about to just blindly use 32256 or 1048576

<almuhs>my offset is 1000341504

<almuhs>almu@debian-t480s:~$ sudo mount -o loop,offset=1000341504 hurd_qemu/debian-hurd.img /mnt

<almuhs>almu@debian-t480s:~$ ls /mnt

<almuhs>bin dev ftp: http: lib media opt root sbin srv usr

<almuhs>boot etc home hurd lost+found mnt proc run servers tmp var

<almuhs>almu@debian-t480s:~$

<almuhs>my calculus are 1953792 * 512

<almuhs>replaced all hd0 with sd0 in grub.cfg

<almuhs>fixed fstab too

<almuhs>but i find again the irq handler error

<almuhs> https://pasteboard.co/ci8TP6oEUEQW.png

<almuhs>this error

<almuhs>it's the same that i found after install from the installer

<almuhs>grub.cfg https://pastebin.com/Yaf6taT7

<almuhs>fstab https://pastebin.com/VieuH6wq

<almuhs>qemu script https://pastebin.com/CysSUEfL

<Pellescours>almuhs: my answer is late, but to mount an ilage with partitions, losetup and then partprobe and you'll see them wothout having to say the offset

<Pellescours>losetup /dev/loop0 image; partprobe /dev/loop0; and you'll should see /dev/loop0p1 and /dev/loop0p2

<almuhs>thanks, i take note about this

<almuhs>now i have a new problem, check screenshot

<Pellescours>I think you need to have the acpi translator started

<Pellescours>so you need to have libacpica to be installed

<Pellescours>1st grub module acpi 2nd module pci-arviter 3rd module rumpdisk and then exec

<youpi1>the irq line is not an error, it's just telling you that netdde took handle of the irq of the network board

<almuhs>youpi1: then, why boot stops in this point?

<youpi1>no idea

<almuhs>are there any more recent image?

<youpi1>the url link points to "latest", so it's latest

<almuhs>trying then with virtualbox

<softwar>it works with gnome-boxes

<softwar> https://wiki.gnome.org/Apps/Boxes

<almuhs>yes, i know gnome-boxes

<softwar>I got xwindows working with debian 2021 hurd, just like linux. My only problem is with ext2 corrupting, then that's it

<almuhs>installed latest iso of Debian GNU/Hurd in VirtualBox. It works fine

<almuhs>installing in virtualbox, i noticed that only works if the cdrom is IDE. The harddisk can be SATA, but the cdrom must be IDE

<almuhs>virt manager has the same problem: if cdrom is SATA, the installer don't find the device

<almuhs>don't rumpdisk supports SATA CDROM?

<almuhs>or is the installer which don't support it?

<youpi1>almuhs: /var/log/syslog will tell you

<almuhs>thanks, i go to check that file

<gnu_srs1>Pellescours: I'm using kpartx to get access to partitions. apt-cache search partprobe gives nothing, but it seems to be from parted.

<almuhs>i've just discovered the reason because my qemu VM keeps freezed during booting: my NIC was set to pcnet, which are in gnumach

<almuhs>changing NIC to e1000, the boot continues

<almuhs>but now, booting from smp kernel, the boot freezes after "proc auth"

IRC channel logs

2023-02-15.log