IRC channel logs


back to list of logs

<damo22>"(03:18:38) youpi: damo22: had you tried the non-bootstrap pci-arbiter when there is no bootstrap pci-arbiter ?" <--- no i didnt try that
***Server sets mode: +nt
<damo22>i get device timeout with APIC + SMP + rumpdisk
<damo22>maybe the EOI is not quite right
<damo22>on some older IOAPICs there is no irq specific EOI register
<damo22>so i did a workaround
<damo22>hmm maybe the focus processor needs to be set to BSP
<damo22>so all interrupts are guaranteed to arrive at the base processor
<damo22>youpi: what happens if the EOI gets sent so late that it is after a new interrupt occurs
<damo22>currently, i made the irq_acknowledge() call the EOI
<damo22>but i dont know if its actually irq specific
<damo22>i think i found the bug
<damo22>i was targetting exactly no processors for the irqs
<damo22>i probably need to remove the irq specific EOI workaround its not working
<damo22>ok have sent more patches
<damo22>i found a few more bugs in addition to what i sent to the mailing list
<damo22>but it still doesnt work correctly on qemu
<damo22>i think its related to EOI / masking
<damo22>youpi: with the two patches i just sent in, it boots in qemu and allocates irq for eth0 but hits the bug with WDCTL_RST failed on ahci
<damo22>with APIC+SMP
<youpi>damo22: I fixed the pci-arbiter's device-master-port option
<youpi>see the latest hurd commit, the option name was not coherent with other bootstrap translators
<damo22>ah ok
<damo22>do you have a workaround for qemu ahci bug?
<damo22>can i just put a check in there that checks if the cmd->thing exists
<youpi>I haven't had any look at that
<youpi>I'm just trying to stick the parts altogether
<damo22>ok, no probs, its just annoying because i dont have a working machine yet, to test on real hw i have to fix libacpica
<damo22>should i create a new branch of incubator for libacpica?
<youpi> /servers/bus/pci doesn't seem to be working with a pci-arbiter being run at bootstrap? didn't we have a plan to make it open the pci mach device? or make libpciaccess use it?
<damo22>oh? i thought it does
<damo22>i have 2x patches for libpciaccess
<damo22>almost upstreamed but there is outstanding comment from you
<damo22>i need to sleep now, i have an early start
<damo22>thanks for your help
<youpi>with the latest apic commits I am still getting "Tty c10aa460 was stuck" messages when printing to com0
<damo22>ah ok, maybe we need to unmask_irq(COM)
<damo22>like i did for kd interrupt in model_dep.c
<damo22>nothing probably unmasks the irq initially so it never interrupts
<youpi>it should be in their own drivres once they are set up, rather than in machine_init
<damo22>yes i tried putting it in their driver before but for some reason it got masked again
<damo22>so i used a sledgehammer and put it where i could see it working
<youpi>possibly put it in take_dev_irq
<youpi>or the open() driver method
<damo22>i think kd has to be quite late
<damo22>or early
<damo22>maybe the initial state of the APIC is undefined
<damo22>we should probably have a method that clears it out of all interrupts
<youpi>usually you cannot really rely on the hardware state
<youpi>the previous OS or bios may have set it in various ways
<youpi>it seems that unmasking the irqs did the trick indeed
<youpi>the installer is booting
<youpi>I'm not geting any output on the vga console, though
<damo22>its tricky too i saw in linux kernel, the IRR has different behaviour depending on level/edge
<damo22>are you using a separate console for stdout
<damo22>when i split my console it would not print
<damo22>but it works in -curses mode
<youpi>yes, with console=com0
<damo22>something is fishy there
<youpi>and the hurd console is not getting keyboard presses apparently
<damo22>yeah i saw that too, i dont know why
<damo22>but debugger works
<damo22>maybe its a level/edge problem with IRR
<damo22>i didnt wrap the EOI in masking of irq
<damo22>but if i do, it hangs
<damo22>afaik, QEMU emulates a very old ioapic
<damo22>one with discrete pins
<damo22>i tried to support all apics
<damo22>if you have time, you can try removing the " = 1; /* FIXME Assume all machines have this" and let it be zero so it falls back to old ioapic method
<damo22>it should detect if the ioapic hardware itself supports the specific EOI register
<damo22>but that pathway seems to not work so well currently
<damo22>the legacy pic seems easier to actually use
<damo22>but i dont think it will work with smp
<damo22>it has different behaviour with accel=kvm and without kvm
***Emulatorman___ is now known as Emulatorman