Linux 2.6.23
http://bugzilla.kernel.org/show_bug.cgi?id=9300
Under any sort of traffic load (recursive scp from another box of a
bunch of mp3s, for instance), I get continuous stalls. Recovers every
time, but is dog slow.
NETDEV WATCHDOG: eth2: transmit timed out
eth2: Transmit timed out, sta
Jesse Brandeburg wrote:
Analysis follows, but I wanted to ask you to bisect back if you can to
find the apparent patch to make the difference. Basically at this
point I'd say its not likely to be an e1000 issue, but I'd like to
follow up and make sure.
That's going to be ugly, since I can't re
Jesse Brandeburg wrote:
On 10/22/06, Martin J. Bligh <[EMAIL PROTECTED]> wrote:
Martin J. Bligh wrote:
> I'm getting a lot of these type of errors if I run 2.6.18. If
> I run the standard Ubuntu Dapper kernel, I don't get them.
> What do they indicate?
Hi Martin,
Martin J. Bligh wrote:
I'm getting a lot of these type of errors if I run 2.6.18. If
I run the standard Ubuntu Dapper kernel, I don't get them.
What do they indicate?
Oct 21 18:48:28 localhost kernel: buffer_info[next_to_clean]
Oct 21 18:48:28 localhost kernel: time_stamp
I'm getting a lot of these type of errors if I run 2.6.18. If
I run the standard Ubuntu Dapper kernel, I don't get them.
What do they indicate?
Oct 21 18:48:28 localhost kernel: buffer_info[next_to_clean]
Oct 21 18:48:28 localhost kernel: time_stamp <7b79d33>
Oct 21 18:48:28 localhost
David Miller wrote:
From: [EMAIL PROTECTED]
Date: Mon, 14 Aug 2006 23:03:43 -0700
From: Martin Bligh <[EMAIL PROTECTED]>
Signed-off-by: Martin Bligh <[EMAIL PROTECTED]>
Cc: "David S. Miller" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Applied to net-2.6.19.
I implem
> > [Bug 5958] CF bluetooth card oopses machine when
> > http://bugzilla.kernel.org/show_bug.cgi?id=5958
>
> This isn't a serial bug - it's a bluetooth ldisc bug. I reported it
> to the bluetooth folk back when it first got raised by Pavel. However,
> they seem to be completely disintereste
--Francois Romieu <[EMAIL PROTECTED]> wrote (on Tuesday, August 02, 2005
23:43:40 +0200):
> Daniel Phillips <[EMAIL PROTECTED]> :
> [...]
>> A point on memory pressure: here, we are not talking about the continuous
>> state of running under heavy load, but rather the microscopically short
>>
