Messages in this thread | | | From | "Robbert Kouprie" <> | Subject | RE: The buggy APIC of the Abit BP6 | Date | Thu, 13 Jun 2002 15:30:20 +0200 |
| |
Helge Hafting wrote:
> > Jun 12 23:47:56 radium kernel: unexpected IRQ trap at vector 7d > > Jun 12 23:47:56 radium kernel: unexpected IRQ trap at vector 7d > > It _can_ be solved - rebooting cures it, so assuming the problem > is autodetectable it _can_ be solved by doing whatever it is > a reboot (or driver reload) does to the APIC.
True.
> My guess is that the APIC setup for that IRQ have to be reprogrammed. > you could do that as a quirk for the BP6. > The first question is if there is a reliable way to detect this > condition. "No interrupts from a device" could simply mean that > it isn't used much at the time. You get a unexpected IRQ trap - do > the problem always manifest itself this way?
Yes, I always get the "unexpected IRQ trap at vector 7d" message. This is the same message even with different NICs (though they were placed in the same PCI slot). About 30-120 seconds after this message (depending on some driver timeout value I guess) the NETDEV watchdog kicks in with a "eth0: transmit timed out".
> The second question is if all the PCI card drivers out there > survive a lost interrupt handled outside the driver. > If not, you have to close+reopen the device, and that involves > userspace. > A network card will need reinitialization, a disk controller > remounting...
That could indeed be a problem. But this will become clear pretty soon once this APIC reprogramming workaround is actually implemented in the kernel. Then I will be able to test that. Any ideas how this workaround in the kernel would look like?
Thanks for the help, - Robbert Kouprie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |