> > > >> Mind to put a (maybe rate limited) printk into the interrupt thread > > > >> that prints out "reg" > > > >> and "reg_mcu" so that we can see which interrupts get triggered? > > > > > > > > log attached, generated with: > > > Thanks. Unfortunately nothing special in there. Mostly RX and TX > > > interrupts. So there must be something else ... > > > > Tim, is this on x86 hw? Or something else? > > I don't know if this will do any good or harm but it could be worth a try > as the spec for rt61pci says something like: "Don't enable interrupt > mitigation in the same write as releasing the other masks.". Since we > always write a mitigation period of 0xff == "No mitigation period" we can > simply leave interrupt mitigation disabled. > > I really don't have any clue if this will fix anything but it might be > worth a try. i have been running this patch for a few days and i haven't experienced the problem again. according to `top', the kernel thread `irq/16-0000:08:' still is the kernel thread, that is using the most cpu time (after an uptime of 8 hours) it is about 50 seconds, while the second most expensive kernel thread (`kworker/2:1') takes below 5 seconds of cpu time. cheers, tim -- tim@xxxxxxxxxx http://tim.klingt.org Cheat your landlord if you can and must, but do not try to shortchange the Muse. It cannot be done. You can't fake quality any more than you can fake a good meal. William S. Burroughs
Attachment:
signature.asc
Description: This is a digitally signed message part.
