On Tue, 2007-05-29 at 22:45 +0200, Michael Buesch wrote: > On Tuesday 29 May 2007 16:14:35 Gary Zambrano wrote: > > On Mon, 2007-05-28 at 16:55 +0200, Michael Buesch wrote: > > > On Monday 28 May 2007 16:12:12 Maximilian Engelhardt wrote: > > > > On Monday 28 May 2007, Michael Buesch wrote: > > > > > Can you also test the following patch? > > > > > I think there's a bug in b44 that is doesn't properly discard > > > > > shared IRQs, so it might possibly generate a NAPI storm, dunno. > > > > > Worth a try. > > > > > > > > > > Index: linux-2.6.22-rc3/drivers/net/b44.c > > > > > =================================================================== > > > > > --- linux-2.6.22-rc3.orig/drivers/net/b44.c 2007-05-27 23:01:44.000000000 > > > > > +0200 +++ linux-2.6.22-rc3/drivers/net/b44.c 2007-05-28 12:48:27.000000000 > > > > > +0200 @@ -911,6 +911,8 @@ static irqreturn_t b44_interrupt(int irq > > > > > spin_lock(&bp->lock); > > > > > > > > > > istat = br32(bp, B44_ISTAT); > > > > > + if (istat == 0xFFFFFFFF) > > > > > + goto out; /* Shared IRQ not for us */ > > > > > imask = br32(bp, B44_IMASK); > > > > > > > > > > /* The interrupt mask register controls which interrupt bits > > > > > @@ -942,6 +944,7 @@ irq_ack: > > > > > bw32(bp, B44_ISTAT, istat); > > > > > br32(bp, B44_ISTAT); > > > > > } > > > > > +out: > > > > > spin_unlock(&bp->lock); > > > > > return IRQ_RETVAL(handled); > > > > > } > > > > > > > > I did try this patch on a affected kernel, but I didn't notice any big > > > > difference. Perhaps the kernel is a bit less slow during the test, but It's > > > > hard to tell. > > > > > > Ok, but anyway. I think this is a bug and needs to be fixed this way. Gary? > > > > > > > Thanks Michael. > > No, I don't think this is a bug and it does not need to be fixed. > > Are you sure? I'm not so sure, because > 1) On bcm43xx the reverse engineers told us that the card > returns 0xFFFFFFFF for no-irq-pending. Since b44 and bcm43xx > are very similiar in IRQ and DMA I just thought it would > be the case there, too. Just guessing. The b44 interrupt status reg returns a value of 0 if no interrupts are pending. The b44 uses a mask to determine which bits (events) can generate device interrupts on the system. If the masked interrupt status register bits are not asserted, then the b44 will return to the system with handled = 0. So, I think the way the b44 interrupt code is written should be ok and not a bug. > 2) PCMCIA cards usually return all-ones if you try to read a > register of a card that's been removed. So it's good > practice to check for this and bail out early in the IRQ > path. Do PCMCIA cards (PC-card, not neccessarily a real > 16bit PCMCIA card) for b44 exist? I do not know of any pccard application of the b44. As far as I know b44s live on motherboards and in the wireless soc. Thanks, Gary - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
