IRC channel logs


back to list of logs

<damo22>netdde is waiting on gsync_wait
<damo22> Kernel Page fault trap, eip 0xc1051d19, code 0, cr2 244
<damo22>kernel: Page fault (14), code=0
<damo22>Stopped at cause_ast_check+0x9: pushl 0x244(%eax)
<damo22>that was trying to compile gnumach with -j8 with no pinning
<damo22>when i set HW_FOOTPRINT = 1 it boots to a shell most of the time
<damo22>with no pinning
<damo22>cause_ast_check fails if the last_processor is not set, but HW_FOOTPRINT seems to fix htat
<damo22>solid_black: wb
<solid_black>hi damo22
<damo22>solid_black: how is your patch coming along
<solid_black>not ready yet, but I'm planning to work on it today
<damo22>i got to a shell with no pinning
<solid_black>you mean full boot-up?
<solid_black>now that's a \o/-worthy :)
<solid_black>"mostly", though?
<damo22>i need to test more
<damo22>i got a deadlock compiling gnumach -j8 with full bootup
<solid_black>let's debug it then
<damo22>i cant enter kdb
<solid_black>can you attach gdb?
<damo22>good q
<damo22>it trashes my disk though
<youpi>"let's debug it then": rather enable unpinning progressively
<youpi>to determine which piece of the system is hanging
<solid_black>my (non-smp, i386) build of gnumach seems to hang right after probing disks, inside ahci_interrupt() -- any idea what's that about?
<solid_black>that doesn't happen if I drop -M q35
<damo22>well my git server is down
<damo22>i thought i had a bug that i couldnt git push from a full smp system, but the server is not up
<solid_black>so you mean networking works otherwise?
<damo22>what is \u0318f9
<damo22>or 01f389
<solid_black>heh, I guess not everything is UTF-8 enabled yet
<youpi>unicode 01f389
<youpi>U+1F389 PARTY POPPER
<damo22>if you want a system that works like mine, apply HW_FOOTPRINT = 1
<solid_black>my IRC client here has a prominent emoji input popover, so I thought it'd work, and nobody told me otherwise before
<damo22>otherwise im on master plus your vm patch
<damo22>and a couple of minor ones i mailed in already
<youpi>> cause_ast_check fails if the last_processor is not set, but HW_FOOTPRINT seems to fix htat
<youpi>ok but that's only by luck, we'd want to fix it even without HW_FOOTPRINT
<damo22>there is a comment near HW_FOOTPRINT block in thread.c
<damo22>it says something like context switch code is supposed to set last_processor when its not defined
<damo22>but i cant seem to find it
<damo22>solid_black: i dont think its utf-8, it seems to be unicode 32 bit code
<solid_black>I assume my client is sending UTF-8 over the wire, and then yours is displaying it as a unicode codepoint to you
<youpi>damo22: you're probably just missing the font
<solid_black>damo22: that displayed as the emoji here; what did you do?
<damo22>>>> print('\U0001f389')
<damo22>in python
<damo22>copy and pasted into my irc buffer
<solid_black>ok, I have a way to panic Mach on i386, and the same should give me a kernel write primitive on x86_64, which is easily escalated into full access
<solid_black>is such a vulnerability known?
<youpi>very most probably not
<solid_black>I haven't tested on x86_64 though, maybe I should verify that it works & I can get root
<youpi>we want to fix it anyway
<damo22>solid_black, finding more 0days?
<damo22>im glad youre working for us
<damo22>ie not against us
<damo22>solid_black: can i pm you for a sec
<solid_black>youpi: what am I supposed to put into sources.list for hurd-amd64 -- or
<Denis>hello all. I managed to trigger a kernel crash in Hurd, is there a specific procedure to report it, or I just send the details to bug-hurd@?
<youpi>solid_black: better use debian-ports, to get the most up to date packages
<youpi>solid_black: actually, use both :)
<solid_black>yeah, I've just tried that
<youpi>some packages I built them by hand quite roughly
<youpi>so I cannot upload them to debian-ports
<solid_black>can't quite get it to upgrade though; it hangs on dpkg-preconfigure with errors about bogus ports in exec & ext2fs
<youpi>it seems preconfigure has a hang yes, you can just kill it
<solid_black>ideally we should debug the bogus ports things
<solid_black>but that'd need debuginfo
<youpi>we don't have debuginfo?
<youpi>for what package?
<solid_black>I thought we don't have debuginfo for all of them? and you said that's because you're bootstrapping and that doesn't produce debuginfo packages?
<solid_black>maybe I misunderstood
<solid_black>let me see
<youpi>the packages on people don't have symbols indeed
<youpi>but packages fro mdebian-ports are properly built
<solid_black>just killing it seems to have worked indeed
<solid_black>oh, there's already a gdb? is that with flavio's patches?
<youpi>getting debugging tools is always a priority :)
<solid_black>"gdb: warning: A handler for the OS ABI "GNU/Hurd" is not built into this configuration"
<youpi>yes, probably worth having a look
<youpi>it doesn't seem to be preventing from most debugging functions
<solid_black>why are gnumach-image-1.8-486 and gnumach-image-1.8-486-dbg two separate packages?
<solid_black>is the latter built with MACH_DEBUG?
<damo22>dbg has kdb
<solid_black>is there a debuginfo package for the regular gnumach-image?
<damo22>dbg != debuginfo
<solid_black>yes, I'd expect it to be called gnumach-image-1.8-486-dbgsym
<damo22>is the kernel really stripped?
<solid_black>is it not? I'd expect it to be, like all binaries are
<solid_black>over here in the Alpine-based distro, 'gnumach' contains the stripped kernel image, gnumach-dbg contains the debuginfo for it, and the proper debuglink is injected into /boot/gnumach
<youpi>the gnumach debian packaging is really old, it doesn't follow current practices and thus doesn't generate a dbgsym package
<youpi>contribution welcome ;)
<damo22>Denis: if its a zero-day bug, probably email our maintainer before making it public, otherwise if its just a crash, just mail it to bug-hurd
<youpi>dh_strip: warning: Could not find the BuildID in debian/gnumach-image-1.8-486/boot/gnumach-1.8-486
<youpi>so apparently it's not a packaging issue
<solid_black>totally worked!
<solid_black>damo22 youpi: ^
<damo22>hopefully we can fix these and they become much more rare
<damo22>although we have a russian hacker to help
<gnucode>solid_black: congrats on finding another 0 day vulnerability.