linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* r8169 bug in 2.4.22, too much work at interrupt indefinitely
@ 2003-10-23 23:38 John Bäckstrand 
  2003-10-23 23:53 ` Stephen Hemminger
  0 siblings, 1 reply; 3+ messages in thread
From: John Bäckstrand  @ 2003-10-23 23:38 UTC (permalink / raw)
  To: linux-kernel

The r8169 driver in 2.4.22 with or without debian patches/acpi/usb devices sharing the same interrupt: the driver always ends up locking the machine by having indefinitely much to do in the interrupt handler? 

Commented the printk out, still hangs the machine anyway. It happens even without a cable in the card. I have found no references to any bug reports at all with this card, and I cant see any bugfixes being in 2.5/2.6 but not 2.4 either. I can see the card TX/RX:ing a few hundred packets or more (3-60 secs) before hanging.

Any way to debug this, or should I just try 2.6?

---
John Bäckstrand



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: r8169 bug in 2.4.22, too much work at interrupt indefinitely
  2003-10-23 23:38 r8169 bug in 2.4.22, too much work at interrupt indefinitely John Bäckstrand 
@ 2003-10-23 23:53 ` Stephen Hemminger
  2003-10-24 10:12   ` Jeff Garzik
  0 siblings, 1 reply; 3+ messages in thread
From: Stephen Hemminger @ 2003-10-23 23:53 UTC (permalink / raw)
  To: linux-kernel

On Fri, 24 Oct 2003 01:38:14 +0200
"John Bäckstrand"  <sandos@home.se> wrote:

> The r8169 driver in 2.4.22 with or without debian patches/acpi/usb devices sharing the same interrupt: the driver always ends up locking the machine by having indefinitely much to do in the interrupt handler? 
> 
> Commented the printk out, still hangs the machine anyway. It happens even without a cable in the card. I have found no references to any bug reports at all with this card, and I cant see any bugfixes being in 2.5/2.6 but not 2.4 either. I can see the card TX/RX:ing a few hundred packets or more (3-60 secs) before hanging.
> 
> Any way to debug this, or should I just try 2.6?
> 
> ---
> John Bäckstrand

2.6 will have the same problem.   I have a version that uses NAPI that shouldn't hang.
It seems to work fine, but didn't want to submit it without more testing.



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: r8169 bug in 2.4.22, too much work at interrupt indefinitely
  2003-10-23 23:53 ` Stephen Hemminger
@ 2003-10-24 10:12   ` Jeff Garzik
  0 siblings, 0 replies; 3+ messages in thread
From: Jeff Garzik @ 2003-10-24 10:12 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: linux-kernel

Stephen Hemminger wrote:
> On Fri, 24 Oct 2003 01:38:14 +0200
> "John Bäckstrand"  <sandos@home.se> wrote:
> 
> 
>>The r8169 driver in 2.4.22 with or without debian patches/acpi/usb devices sharing the same interrupt: the driver always ends up locking the machine by having indefinitely much to do in the interrupt handler? 
>>
>>Commented the printk out, still hangs the machine anyway. It happens even without a cable in the card. I have found no references to any bug reports at all with this card, and I cant see any bugfixes being in 2.5/2.6 but not 2.4 either. I can see the card TX/RX:ing a few hundred packets or more (3-60 secs) before hanging.
>>
>>Any way to debug this, or should I just try 2.6?
>>
>>---
>>John Bäckstrand
> 
> 
> 2.6 will have the same problem.   I have a version that uses NAPI that shouldn't hang.
> It seems to work fine, but didn't want to submit it without more testing.


Are you sure you're not thinking about 8139too, not r8169?


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2003-10-24 10:12 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-10-23 23:38 r8169 bug in 2.4.22, too much work at interrupt indefinitely John Bäckstrand 
2003-10-23 23:53 ` Stephen Hemminger
2003-10-24 10:12   ` Jeff Garzik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).