<Pellescours>pci-userspace in debug, by changing the #if 0 to #if 1? <damo22>just for ease otherwise you have to recompile again <biblio>damo22: i am trying to fix libacpi. I am calling acpi_get_irq_number(1,0,0) for 01:00.0 Ethernet controller. But acpi_ns_get_attached_data() could not find the device. <biblio>damo22: my question is calling acpi_get_irq_number(1,0,0) for 01:00.0 is correct b/d/f ? <damo22>you can check with libpciaccess too <Pellescours>damo22: I build as you said, I just started rumpdisk and stopped it and it prints a: <Pellescours>irq handler [11]: release dead delivery 1 unacked irqs port f5ed2018 entry f5c9e8e0 <Pellescours>so the undelivered irq seems to be related to rumpdisk <damo22>at least on non-IOAPIC interrupts <damo22>i dont know how to check the irq <damo22>i assumed its fixed in the gnumach disk driver <Pellescours>but the logs that I made appears are those from pci-userspace, they are triggered only by rump <damo22>its the interrupt handler it could be any interrupt <Pellescours>ethernet controller has the same Interrupt: pin A routed to IRQ 11 <damo22>ahh its a problem with sharing interrupts then <damo22>i cant remember how we handle that <Pellescours>i don’t see any mention nor TODO about shared irq in intr code <Pellescours>there is a flag flags |= SA_SHIRQ which is always set <damo22>right, so how does it know which handler to use for different drivers if its the same irq number <youpi>devices and drivers are supposed to cope well with spurious interrupt notifications <damo22>so then the unhandled interrupt is expected <Pellescours>actually by looking to debug code I understand that irq are delivered correctly <Pellescours>there is a lot of irq fired 11 followed by k_handle...k_done <Pellescours>so the log about the 1 irq is probably a false positive due to the irq sharing with ethernet controller <Pellescours>note: improve mach irq sharing detection and logging <Pellescours>Ok, when I try to manipulate my disk handle by rump, I have a lot of program crashing <damo22>if you are stepping through the actual handler, i *think* you are interrupting gnumach so it probably times out on other ports? im not sure <Pellescours>currently when I start rumpdisk and I do a ls /dev, the storeio for my wd0 is crashing in loop. I don’t know if I did a wrong manipulation with my disk or what but at the begining it was not crashing (until I tried to play with partitions) <biblio>hi, I am looking for HURD interrupt handler docs. <biblio>damo22: acpi_get_irq_numer() -> is calling func call back register_slot() inside failed to get data from acpi_get_data(). So, I added acpi_attach_data() before for testing. Now, it gives some value but not correct one. I think we should first focus on acpi_is_install_interrupt_handler(..) <biblio>damo22: acpi_os_install_interrupt_handler* <damo22>biblio: you can use device_open('irq' etc <damo22>but then we need to know which irq to install the handler on, etc <damo22>maybe that is an argument to the function? <biblio>damo22: I am checking acpica-reference pdf. I will try with device_open('irq'. Yes it could be an argument to the function. I will verify. <damo22>biblio, check the gnumach source code for "irq" <damo22>there are some RPCs you can call on the irq mach device once opened <damo22>you can look at rumpkernel package under pci-userspace/src-gnu/pci_user.c there is an example of how to register an interrupt handler <biblio>damo22: thanks this is what I was looking for. <damo22>hmm looks like device_intr_register and device_intr_ack is the only irq RPCs we have, so it looks like there will be code duplication between rumpkernel and acpi <damo22>ie, registering an interrupt handler needs to create an interrupt thread and call the handler? ***biblio_ is now known as biblio
<biblio>damo22: I am not sure about interrupt thread yet. But if it multi-threading libacpica is a prerequisite then I will fix the locking issue first. <damo22>you can start from the other branch then <damo22>i got close, but ended up in deadlock on a semaphore <biblio>damo22: yap I can do that. No prob. I can debug and find the cause of deadlock. <biblio>damo22: one issue I found in register_slot(...). We are trying alloc on a pointer *context. I was able to solve it by using a new node as context->next. But I will send a patch after solving is fully.