IRC channel logs
2024-01-21.log
back to list of logs
<dsmith>I heard Ubuntu was and ancient African word meaning "I can't configure Debian" ... <damo22>there is device dummy0, base addr: 0 <damo22>there is device eth0, base addr: 107f000 <damo22>on a debian hurd system, what is the output of showtrans /servers/bus/pci ? <damo22>second pci-arbiter is not working correctly <damo22>first one might be stuck? 5 root 14 -6 159308 26572 0 D 0.0 1.7 0:00.09 pci-arbi+ <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 <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 <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) :( <azert>Not being serious one single second <azert>hate on the internet is like sin in the Catholic Church <janneke>we used to build gnumach for i686-linux... <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>linux/dev/include/linux/fs.h:280:9: error: unknown type name ‘uid_t’ <janneke>but now i'm hit by the gnumach-undef-bad <youpi>janneke: it looks like you told the compiler to build in hosted mode <youpi>we set CFLAGS="$CFLAGS -ffreestanding -nostdlib" in configure.ac to avoid the compiler e.g. turning printf into puts <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