Opened 5 years ago
Closed 3 years ago
#818 closed defect (fixed)
e1k driver appears to claim the wrong interrupt
Reported by: | Colin Parker | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 0.11.1 |
Component: | helenos/drv/e1k | Version: | mainline |
Keywords: | Cc: | ||
Blocker for: | Depends on: | ||
See also: |
Description
In the IRQ pseudo-code for the e1k driver, the interrupt claim is based on reading a non-zero value for the interrupt cause read (ICR) register of the device. However, the interrupt mask is set so that only one bit (ICR_RXT0) will trigger interrupts. This means that if another interrupt cause is true, the driver will claim any IRQs even though the e1k was not the source of the interrupt. I was able to work around this by having the pseudo-code mask the register before testing.
Background: I've compiled HelenOS for amd64 targeting EFI firmware rather than PC. I test it using qemu and the Intel Tianocore/EDK2 firmware. Using default PC firmware this problem doesn't seem to have symptoms, but in my configuration it prevents both the USB ehci and e1k drivers from sharing the IRQ. So I suspect it also involves something like a race condition between the drivers, but with my suggested fix it should work in both situations.
Change History (2)
comment:1 by , 5 years ago
comment:2 by , 3 years ago
Milestone: | → 0.11.1 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
This was fixed on May 17, 2020 in changeset 807be7ee42522e194eac3944cc4b65503a2f8c26. Thanks again Colin for reporting and fixing this bug!
That sound like good root cause and reasonable fix. Can you submit a pull request, please? Thanks!