IRC channel logs


back to list of logs

<Pellescours>pci-userspace in debug, by changing the #if 0 to #if 1?
<damo22>keep your old librump debs
<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>should be
<biblio>damo22: ok thanks
<damo22>you can check with libpciaccess too
<damo22>00:1f:2 would be 0, 31, 2
<biblio>damo22: ok noted.
<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>my network device is irq11
<damo22>can you check
<Pellescours>how do I check that ?
<damo22>good q
<damo22>i think irq10 is the disk
<damo22>at least on non-IOAPIC interrupts
<Pellescours>but all logs talks about irq 11
<damo22>i dont know how to check the irq
<damo22>i assumed its fixed in the gnumach disk driver
<damo22>lspci -vv ?
<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>SATA controller … Interrupt: pin A routed to IRQ 11
<Pellescours>ethernet controller has the same Interrupt: pin A routed to IRQ 11
<damo22>ahh its a problem with sharing interrupts then
<damo22>check the gnumach code
<damo22>i cant remember how we handle that
<Pellescours>I’m not sure it handle shared interrupt
<Pellescours>how should it behave in case of shared irq?
<damo22>i have a feeling we disabled it
<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>it calls them all
<youpi>devices and drivers are supposed to cope well with spurious interrupt notifications
<damo22>hmm ok
<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>where is the crash server writing core files?
<damo22>i think
<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)
<Pellescours>time to bed
<damo22>thanks for looking into it
<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
<damo22>the detail is buried in the debian patches
<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>would be great
<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.