IRC channel logs


back to list of logs

<dsmith>I heard Ubuntu was and ancient African word meaning "I can't configure Debian" ...
<damo22>search device eth0
<damo22>there is device dummy0, base addr: 0
<damo22>there is device eth0, base addr: 107f000
<damo22>device_intr_register returns 0
<damo22><6>r8169: eth0: link down
<damo22>but lspci hang
<damo22>ls /servers/bus/pci hangs
<damo22>hmm maybe i will upgrade
<damo22>on a debian hurd system, what is the output of showtrans /servers/bus/pci ?
<damo22>second pci-arbiter is not working correctly
<damo22>on real hw
<damo22>first one might be stuck? 5 root 14 -6 159308 26572 0 D 0.0 1.7 0:00.09 pci-arbi+
<damo22>maybe acpi is stuck?
<damo22>youpi: if the irq routing table is wrong on a mainboard bios, would it be possible that pci-arbiter hangs?
<damo22>or netdde, for example, trying to obtain the wrong interrupt?
<anatoly_>solid_black: in layman's words: where is the shot? :-) I mean git repo with aports or similar
<azert>damo22: what does hang? Is it pci-arbiter or the whole world ?
<azert>Does the kernel debugger works while it’s hanged?
<solid_black>anatoly: I haven't published it anywhere yet (and won't be able to, until tomorrow)
<solid_black>probably should make a temporary place *somewhere* so you can look at it & experiment with it
<solid_black>but if enough people are interested and we're going to keep going with this, we'd need a more official place to host the git repo
<youpi>damo22: /server/bus/pci is just /hurd/pci-arbiter
<youpi>obtaining the wrong interrupt can make the driver stuck, but normally not the whole translator
<youpi>as in: operations are supposed to be at least interruptible
<youpi>but yes, if it's not completely properly programmed, it could get stuck if the interrupt that tells the operation is done is never received
<youpi>usually drivers implement an irq timeout, though
<anatoly>solid_black: I think something and somewhere is better than waiting the right moment :-) But no hurry of course, I was just curious
<damo22>youpi: yes, i think its stuck due to wrong interrupt
<damo22>but i dont know how to program the pci irq in the bios for this board
<damo22>like which one is connected where
<youpi>is this 32bit or 64bit?
<damo22>its a 64 bit cpu running 32 bit gnumach
<damo22>somehow linux finds the irq fine, but uses MSI
<damo22>hmm perhaps the APIC irqs are set up right because linux uses ACPI for routing
<damo22>but i am not using --enable-apic
<damo22>so it must be the legacy PIC interrupts that are set up wrong in the PIRQ table?
<damo22>maybe i can ask linux to not use ACPI for pci routing
<damo22>correct, booting with "noapic nolapic" causes eth card to be down
<azert>Yesterday I tried Linuxbrew on Debian GNU/Hurd. If you make him believe that it’s running on x86_64 Linux during installation, then it works. I could install a few software with their dependencies
<azert>It gets everything from source
<azert>The page say it’s incompatible with i386, but there aren’t really any technical reasons why it should be
<azert>Going to uninstall it now
<solid_black>why are people saying negative things about Debian now :(
<youpi>because people like saying negative things on whatever
<gnu_srs>solid_black: Because Debian is forcing users into systemd and usrmerge (for no advantage at all) :(
<janneke>also, Dunning-Kruger effect
<azert>Im just being sarcastic
<azert>Not being serious one single second
<azert>About brew
<azert>hate on the internet is like sin in the Catholic Church
<janneke>we used to build gnumach for i686-linux...
<janneke>that worked up to 1.8+git20221224
<janneke>but 1.8+git20230410 (and later) don't build for me
<janneke>NULL not defined, u_char, not defined; something with _POSIX_SOURCE in include/sys/types.h
<janneke>i'm wondering what i'm doing wrong
<janneke>linux/dev/include/linux/fs.h:280:9: error: unknown type name ‘uid_t’
<janneke>hmm, this seems to fix the compilation part of the build =>
<janneke>but now i'm hit by the gnumach-undef-bad
<janneke>thingy, what was that again?
<youpi>janneke: it looks like you told the compiler to build in hosted mode
<youpi>we set CFLAGS="$CFLAGS -ffreestanding -nostdlib" in to avoid the compiler e.g. turning printf into puts
<janneke>youpi: thanks
<janneke>i see those flags being used, so i'll just have find which object file is misbehaving
<janneke>at least i understand what to look for now
<janneke>okay, the plot thickens; e.g. kern/printf.o isn't compiled with those flags
<janneke>some files are, some aren't
<janneke>more tomorrow, this seems doable :)