IRC channel logs


back to list of 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
<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>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
<youpi1>I notably run buildds with kdb enabled by default
<youpi1>to catch issues there
<youpi1>but I don't want debug_all_traps
<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>then cat gnumach-undef-bad; exit 2; else true; fi
<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:
<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
<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:
<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:
<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?
<almuhs>I'm using this image
<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>seee hurd/running/qemu.mdwn:
<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
<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>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>this error
<almuhs>it's the same that i found after install from the installer
<almuhs>qemu script
<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
<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"