<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>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 was targetting exactly no processors for the irqs <damo22>i probably need to remove the irq specific EOI workaround its not working <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 <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>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>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 <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 <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>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 <youpi>and the hurd console is not getting keyboard presses apparently <damo22>yeah i saw that too, i dont know why <damo22>maybe its a level/edge problem with IRR <damo22>i didnt wrap the EOI in masking of irq <damo22>afaik, QEMU emulates a very old ioapic <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