<swivel>AlmuHS: if you seem unable to affect the logged output with your modifications, maybe check the md5sum of the Xorg binary and vesa_drv.so or whatever the driver is vs. the md5sum of the one you built to make sure it's reaching your test environment? <youpi>what does your print line look like exactly? <AlmuHS>pruebas@hurd:~$ ls -l /var/log/Xorg.0.log <AlmuHS>-rw-r--r-- 1 root root 5494 jul 6 00:18 /var/log/Xorg.0.log <swivel>you could also strings/grep the binary for something unique about what you're printing to ensure it's there <AlmuHS>youpi: the first message is this xf86DrvMsg(1, X_WARNING, "VESA testing starts\n"); <AlmuHS>xf86DrvMsg(1, X_WARNING, "VESA testing starts\n"); <AlmuHS>xf86DrvMsg(pScrn->scrnIndex, X_WARNING,"testing function %s\n", __func__); <youpi>swivel's idea to strings| grep the binary to make sure that your text is getting in is worth checking <swivel>wouldn't be the first time someone pulled their hair out in such a scenario without even getting their changes in the execution environment for some unrelated reason ;) <youpi>AlmuHS: no, strings should be enough <swivel>esp. if you're using package rebuild scripts and such <youpi>non-beginners make the same mistake, they just remember to use such trick to check what they're doing wrong :) <AlmuHS>then I have to compile manually, is not= <youpi>no, that shouldn't be needed <youpi>but first use strings and grep to make sure whether or not your messages are getting in what you have installed in the end <AlmuHS>yes, but I have to find the binary first <youpi>dpkg -L xserver-xorg-video-vesa <youpi>will tell you the list of files <AlmuHS>this? /usr/lib/xorg/modules/drivers/vesa_drv.so <swivel>strings /usr/lib/xorg/modules/drivers/vesa_drv.so | grep "testing starts" <youpi>how do you install your generated .deb file? <AlmuHS>youpi: sudo dpkg -i xserver-xorg-video-vesa-dbgsym_2.4.0-2_hurd-i386.deb <youpi>it's not the dbgsym taht you need <youpi>the -dbgsym one only contains the debugging symbols, not the actual binary <AlmuHS>in other time I installed the real package. I've just notices this time might be not compiled well <AlmuHS>sudo dpkg -i xserver-xorg-video-vesa_2.4.0-2_hurd-i386.deb <AlmuHS>pruebas@hurd:/usr/lib/xorg/modules/drivers$ strings vesa_drv.so | grep "testing starts" <AlmuHS>but, anyways, it's the only message that it's printed in the Xorg log <AlmuHS>pruebas@hurd:/usr/lib/xorg/modules/drivers$ grep testing /var/log/Xorg.0.log <AlmuHS>[555652.712] (WW) VESA testing starts <youpi>at least you get something, that's a start <youpi>possibly VESAPciProbe is not getting called because of a libpciaccess call issue inside the Xorg server itself <youpi>i.e. the xorg-server package <youpi>grep tells it's basically only in ./hw/xfree86/common/* <AlmuHS>i can repeat the test recovering the 2017 libpciaccess, to see an ideal running <youpi>possibly you'll see functions getting called <youpi>which would mean that the problem is not what these functions do, but that they aren't getting called at all <youpi>thus the problem not triggering inside the vesa driver, but in the xorg server code calling the vesa driver <youpi>a segfault is a nice thing, it tells you where a problem actually got critical <AlmuHS>the 2017 libpciaccess didn't have pci. <youpi>yes, sure, that's probably the trigger, but we need to know what exactly doesn't work with pci-arbiter <AlmuHS>segmentation fault at address 0xc <youpi>ok but theres also a backtrace, isn't there? <AlmuHS>wait, I'll copy Xorg log in pastebin <youpi>perhaps you made a mistake in your message printing, that lead to the crash <AlmuHS>maybe I can replace It with a fixed value <youpi>you can as well write 0 instead of pScrn->scrnIndex <swivel>pScrn ? pScrn->scrnIndex : -1 or something perhaps <youpi>we don't really care about the screen number actually <swivel>cool, good practice to just be defensive in general WRT dereferencing pointers in debugging prints on unfamiliar code <swivel>almuhs: you've embarked on quite the toolbelt-enlarging rabbit hole, I'm just happy to see keithp's refactoring of Xorg into easily compilable modules is paying off in yet another situation :) <swivel>it used to be brutal to iterate on something like this <AlmuHS>the long functions and files is one of the older bad practices in coding <damo22>youpi: you said that vm_allocate_contiguous can be in the kernel only, but we do need an RPC to access it from userspace <youpi>I just meant that it doesn't need to be attached to the device master port, it can be on the host master port <damo22>i see, i made it on the mem device <youpi>because I don't think we'll ever need to redirect that in a bootstrap translator <damo22>Hi AlmuHS does HS stand for HurdSMP ? <AlmuHS>youpi: now Xorg works (using 2017 libpciaccess) <AlmuHS>pruebas@hurd:~$ grep "testing" /var/log/Xorg.0.log <AlmuHS>[557721.491] (WW) VESA testing starts <AlmuHS>[557721.621] (WW) VESA(0): testing function VESAPreInit <AlmuHS>[557721.621] (WW) VESA(0): testing in function VESAPreInit finished <AlmuHS>[557721.911] (WW) VESA(0): testing function VESAMapVidMem <AlmuHS>pruebas@hurd:~$ grep "libpciaccess" /var/log/Xorg.0.log <AlmuHS>[557721.491] (WW) libpciaccess enabled in function VESAPciProbe <AlmuHS>[557721.911] (WW) VESA(0): libpciaccess enabled in function VESAMapVidMem <youpi>so PreInit was not getting called previously? <youpi>this really look like the trigger is not inside the vesa driver, but xorg <youpi>well, if none of the vesa functions that call libpciaccess are getting called, the libpciaccess issue can't be triggering inside the vesa driver <AlmuHS>openbox has crashed after a minutes <AlmuHS>i had to kill Xorg with ctrl+alt+bksp <AlmuHS>after kill xorg, kdb has crashed also <youpi>well, ok, but I guess it's a different issue <youpi>better chase only one issue at a time <AlmuHS>yes. anyway, the openbox log maybe is simpler than Xfce log <AlmuHS>the Xorg log using openbox, I refers ***Server sets mode: +nt
***Server sets mode: +nt
***rekado_ is now known as rekado
<rekado>I’m running a Guixy Hurd VM and noticed that *often* it would fail to boot <rekado>the last thing it prints is ‘start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] exec’ <rekado>do you have any hints as to what I could do to figure out why this happens? <janneke>but it seems the ext2fs code suggests it needs to be compiled-in "#ifdef EXT2FS_DEBUG" <janneke>hmm, "ext2fs.static --help" says we don't/didn't compile it in <janneke>(not sure using --debug would tell us something...but yeah) <janneke>ugh, it seems the source code needs to be patched to enable it ***pavlushka_ is now known as pavlushka
<gnu_srs>youpi: Is SIGCONT expected to work as expected? <gnu_srs>OK, i just saw a test failure in src/libgo/go/os/signal/signal_test.go