IRC channel logs


back to list of logs

<swivel>AlmuHS: if you seem unable to affect the logged output with your modifications, maybe check the md5sum of the Xorg binary and 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>The date of the file
<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>others are like this
<AlmuHS>xf86DrvMsg(pScrn->scrnIndex, X_WARNING,"testing function %s\n", __func__);
<youpi>ok, that looks good
<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
<youpi>yes, that's very common
<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=
<AlmuHS>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/
<swivel>strings /usr/lib/xorg/modules/drivers/ | grep "testing starts"
<AlmuHS>the string is not here
<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>it's the other one
<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>wait a minutes to repackage
<AlmuHS>sudo dpkg -i xserver-xorg-video-vesa_2.4.0-2_hurd-i386.deb
<AlmuHS>pruebas@hurd:/usr/lib/xorg/modules/drivers$ strings | grep "testing starts"
<AlmuHS>VESA 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>which function is that?
<youpi>(really, use __func__)
<youpi>(and __LINE__)
<AlmuHS>I used __func__
<youpi>I mean everywhere :)
<AlmuHS>this is the initial function
<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
<AlmuHS>could be possible
<youpi>grep tells it's basically only in ./hw/xfree86/common/*
<youpi>that's worth checking
<AlmuHS>i can repeat the test recovering the 2017 libpciaccess, to see an ideal running
<youpi>that can be useful yes
<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
<AlmuHS>ok, wait a minutes
<AlmuHS>fuck, now it appears a segfault
<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>i think yes
<AlmuHS>wait, I'll copy Xorg log in pastebin
<youpi>perhaps you made a mistake in your message printing, that lead to the crash
<youpi>possibly pScrn is null
<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
<youpi>it'll just be 0
<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>ok i will move it again
<damo22>to use host priv port
<damo22>im back to work now
<damo22>Hi AlmuHS does HS stand for HurdSMP ?
<AlmuHS>HS is a old alias
<AlmuHS>youpi: now Xorg works (using 2017 libpciaccess)
<AlmuHS>i go to check the log
<AlmuHS>youpi: now I can see my messages (and so much info)
<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>i've repeated the test using openbox
<AlmuHS>openbox has crashed after a minutes
<AlmuHS>i had to kill Xorg with ctrl+alt+bksp
<AlmuHS>youpi: check the new log above
<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
<AlmuHS>good night
<rekado_>hi there
***rekado_ is now known as rekado
<rekado>Hi there
<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>oh, bad timing...youpi just left?
<janneke>rekado: i found there's a --debug switch:
<janneke>but it seems the ext2fs code suggests it needs to be compiled-in "#ifdef EXT2FS_DEBUG"
<janneke>lemme see
<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?
<youpi>well, yes ?
<gnu_srs>OK, i just saw a test failure in src/libgo/go/os/signal/signal_test.go