How do you guys test things like:
- max_interrupt_work exceeded
- Tx stuck, invoke tx_timeout
- All the possible error conditions like rxearly,
receiver overrun, etc, etc.
My approach to the first two was to put a 5 mSec delay in
boomerang_rx(), decrease max_interrupt_work to 5 and ping flood it.
This produces some pretty ugly results. Most of the time the packet
dumping code:
if ((status & (0x7fe - (UpComplete | DownComplete))) == 0) {
/* Just ack these and return. */
outw(AckIntr | UpComplete | DownComplete, ioaddr + EL3_CMD);
works just fine. But just occasionally this test doesn't return true
and we fall into:
printk(KERN_WARNING "%s: Too much work in interrupt, status "
"%4.4x. Temporarily disabling functions (%4.4x).\n",
dev->name, status, SetStatusEnb | ((~status) & 0x7FE));
/* Disable all pending interrupts. */
outw(SetStatusEnb | ((~status) & 0x7FE), ioaddr +
EL3_CMD);
outw(AckIntr | 0x7FF, ioaddr + EL3_CMD);
/* The timer will reenable interrupts. */
break;
and all hell breaks loose. Very occasionally the tx_timeout will do the
right thing, but most of the time the ISR is invoked (possibly for Tx -
I haven't checked). Within the ISR the following test:
if (status & RxComplete)
vortex_rx(dev);
returns true. We enter vortex_rx()! But this is with 3c905B
hardware. vortex_rx() doesn't talk to 3c905's and it loops infinitely.
I don't want to blow more time on this corner case if there is a better
way to exercise this code.
Of course, my testing methods could be causing the above problems to
occur...
--
-akpm-
"Excellent. If it will not panic here, your kernel will be destroyed
secretly and fatally" - Alexey K
|