IRC channel logs
2024-12-21.log
back to list of logs
<azert>Pellescours: I think damo22 fixed that for grub giving you a framebuffer. You could try booting qemu with the coreboot bios instead of the default <Pellescours>but gnumach hardcode the number of columns, so I don’t think it will work <azert>the console client don’t pass through gnumach but talks directly to hw as I understand it <azert>He could have probably implemented it in the file you pointed, but he didn’t <azert>as such , most of that is probably dead code <damo22>i added grub fb to hurd/console but it seems to still be limited to 80chars <damo22>im not sure how to increase it to fill the screen <damo22>if youre using coreboot, you need to select linear framebuffer mode at compile time <damo22>the part that uses the fb.c driver must be calling fb_set_dimension with (80,25) <damo22>perhaps we can autodetect the current_width and current_height inside the driver? <damo22>but the caller needs to use that too <Pellescours>isn't it gnumach that configure the console framebuffer ? <damo22>the raw mach_print console is a separate tihng <damo22>yeah but i wrote an alternative driver to that <damo22>mine uses the multiboot gfx into <damo22>it detects the multiboot framebuffer default field <damo22>which is set by gnumach in its boot header <Pellescours>yeah but i mean the driver, I think debian hurd package is still configured to take the vga.c one <damo22>if it detects fb type it switches to that <Pellescours>this value MULTIBOOT_VIDEO_MODE_TYPE_EGA_TEXT, is for legacy 80 comumn or the extended one ? <damo22>if you want linear framebuffer you need to switch it to MULTIBOOT_VIDEO_MODE_TYPE_LINEARFB and provide the width and height in pixels <damo22>then the vga driver will switch to framebuffer in console-client <Pellescours>ahhh but the debian package does not contain theses changes yet <damo22>uhm, we dont switch to the new fb upstream either <damo22>because its handy to keep the mach console for now <damo22>otherwise mach_print cant print anywhere <damo22>it does not have framebuffer support <damo22>what is the status of things today? <damo22>theres some outstanding paging thing <damo22>i got stuck, it doesnt receive packets <damo22>actually it receives the packet i just sent <damo22>should we ask y o u p i to merge our rumpkernel branch? <damo22>do you think its ready? i think it works <Pellescours>did you check rumpusbdisk ? a new method was needed when i made the updated <damo22>i dont know what that function was supposed to contain <damo22>it resulted in missing symbol at link time <Pellescours>yeah, netbsd added this dma function (don't remember the exact name) for some drivers <Pellescours>we need an implementation for rump, I'm not even sure it need to be in pci-userspace or directly in a rump library <damo22>Only the Pentium and P6 family processors support the INIT-deassert IPI <damo22>coreboot uses an all except self IPI to do mp init <damo22>(03:42:48 PM) jakllsch: if they're approriately disabled by platform firmware, disabled cores are actually disabled <damo22>maybe we can use all_except_self IPI indeed <damo22>youpi: do you agree with this assessment? <damo22>According to my BKDG, this is not supported on my LAPIC DirectedEoiSupport: directed EOI support. Read-only. Reset: 0. 0=Directed EOI capability not supported. <damo22>but it has an extended feature that allows specific eoi <youpi>damo22: I don't know, I haven't read documentation about all this <damo22>i keep hearing things that change my mind <damo22>my latest assumption is that disabled cores are not woken by IPI to all but self <damo22>so my latest patches should be good <damo22>i found a register in my AMD cpu that allows 8 bit apic ids <damo22>i just wrote a patch that will throw a warning if its not configured correctly <ZhaoM>youpi: is there an official failed build log of vim? Or I just need to apt-source vim and make sure all tests can pass on my machine <youpi>but building on your machine should be giving you the same <damo22>that explains why cpu number is wrong on my AMD <damo22>it is only configured for 4 bit apic ids but has 8 bit apic ids <damo22>so the ipis are not going to the right place <damo22>ExtApicIdEn: extended APIC ID enable. Read-write. Reset: 0. 1=Enable 8-bit APIC ID; <damo22>APIC20[ApicId] supports an 8-bit value; an interrupt broadcast in physical destination mode requires <damo22>that the IntDest[7:0]=1111_1111b (instead of xxxx_1111b); a match in physical destination mode <damo22>occurs when (IntDest[7:0] == ApicId[7:0]) instead of (IntDest[3:0] == ApicId[3:0]). <zamfofex>ZhaoM: I’m a bit late, but I think the large gap is the exact intent of the ^L you see. They are meant to separate things into pages (e.g. when printing, it ends the page and adds a gap at the bottom to go to the next one). <zamfofex>On a terminal, it works like a vertical tab, aligning chunks of code to a line number multiple of some preconfigured value. <damo22>i may have discovered a bug in latest version of coreboot that this board supports <gfleury>i am trying to cross compile gnumach on cachOS. I hit with this error "fatal error: kern/mach_debug.server.h: No such file or directory"