On Jan 10, 2008 9:24 AM, Chris Friesen <[EMAIL PROTECTED]> wrote:
> After a recent userspace app change, we've started seeing packets being
> dropped by the ethernet hardware (e1000, NAPI is enabled). The
> error/dropped/fifo counts are going up in ethtool:
(These are perhaps too obvious, but I d
On Dec 14, 2007 11:09 PM, Ray Lee <[EMAIL PROTECTED]> wrote:
> On Dec 14, 2007 6:41 PM, Gabriel C <[EMAIL PROTECTED]> wrote:
> Correct, absolutely no traffic. So if it works for you, then either
> it's something that got fixed between -rc3 and -rc5, or something odd
>
On Dec 14, 2007 6:41 PM, Gabriel C <[EMAIL PROTECTED]> wrote:
> Rafael J. Wysocki wrote:
> > On Friday, 14 of December 2007, Ray Lee wrote:
> >> tshark -i eth0, eth1, lo are all empty. Works under 2.6.23.0 just
> >> fine. A quick scan of the log between 2.6.
tshark -i eth0, eth1, lo are all empty. Works under 2.6.23.0 just
fine. A quick scan of the log between 2.6.24-rc3 and current tip
(-rc5) doesn't show any obvious fixes, but then again, what do I know.
I'll check current tip on the weekend when I'll have the luxury to
have my main system down long
Hello there Shish,
On Aug 10, 2007 11:39 PM, Shish <[EMAIL PROTECTED]> wrote:
> Something seems to have broken in 2.6.23-rc2, and I'm not sure what, or
> where I should look for further debugging. The info I have:
>
> On my 2.6.23-rc2 desktop, things run fine.
>
> On my test server, built from the
On Nov 13, 2007 7:24 AM, Giacomo A. Catenazzi <[EMAIL PROTECTED]> wrote:
> As a long time kernel tester, I see some problem with the
> newer "new development model". In the short merge windows,
> after to much time, there are to many patches.
I think the root issue there is that it's hard to get a
(adding netdev cc:)
On 8/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Sat, 4 Aug 2007, Ingo Molnar wrote:
>
> > * Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> >> There are positive reports in the never-ending "my system crawls like
> >> an XT when copying large files" bugzilla entry:
>
Michael Buesch wrote:
> Congratulations to your decision ;)
Sometimes making decisions via Brownian motion has its advantages.
> Which kernel are you using?
Hmm, I'm using the mercurial repository, let me see if I can translate that to
a git
head... Looks like git tree c2bb88baa52429b6b76e3ba42
Hey all, more data on my bcm43xx problem report from a few weeks back.
By random chance I acquired a brain, and decided to rebuild my latest kernel
pull with as many debugging options on as I could stand. Got the below, plus
a dead keyboard (except for Magic SysRq) (but only if I let userspace com
Larry Finger wrote:
> Johannes Berg wrote:
>> Hah, that's a lot more plausible than bcm43xx's drain patch actually
>> causing this. So maybe somehow interrupts for bcm43xx aren't routed
>> properly or something...
>>
>> Ray, please check /proc/interrupts when this happens.
When it happens, I can't
First off, thanks for all your help.
Second off,
On 11/16/06, Larry Finger <[EMAIL PROTECTED]> wrote:
Ray Lee wrote:
>
> If I could figure out a way to make it repeatable, I'd happily do a blind
> bisect.
[...]
> I'm open to suggestions on how to make the pr
Michael Buesch wrote:
> On Thursday 16 November 2006 19:17, Larry Finger wrote:
>> Ray Lee wrote:
>>> Larry Finger wrote:
>>>> Ray Lee wrote:
>>>>> Michael Buesch wrote:
>>>>>> On Wednesday 15 November 2006 20:01, Ray Lee wrote:
Larry Finger wrote:
> Ray Lee wrote:
>> Michael Buesch wrote:
>>> On Wednesday 15 November 2006 20:01, Ray Lee wrote:
>>>> Suggestions? Requests for even more info?
>>> Yeah, enable bcm43xx debugging.
>>
>> Sigh, didn't even think to lo
Michael Buesch wrote:
> On Wednesday 15 November 2006 20:01, Ray Lee wrote:
>> Suggestions? Requests for even more info?
>
> Yeah, enable bcm43xx debugging.
Sigh, didn't even think to look for that. Okay, enabled and compiling a new
kernel. This will take a few days to tri
Hey all,
I ran 2.6.19-rc3 for almost two weeks or so with no difficulties (none related
to the bcm43xx driver, at least). However, Andrew asked me to double check the
latest release to see if my problem report against 2.6.18 (hard locks) was
fixed. Good news is that it still is fixed. Bad news is
(re-adding linux-kernel.)
Larry Finger wrote:
> Would you please test the attached patch that should be applied to a
> vanilla 2.6.18? I'm currently running it, but only for a few minutes. It
> comes up fine and I ran it through several ifdown/ifup cycles without
> any problem.
Okay, this is far
Rafael J. Wysocki wrote:
>> 2.6.18 vanilla and 2.6.18 with your patch both lock my system hard
>> with bcm43xx. I've got an HP/Compaq nx6125 laptop. Symptoms are that
>> it will associate fine on its own and send traffic to/fro upon ifup,
>> but when I do an iwconfig, ifdown, ifup to change the acc
On 9/22/06, Larry Finger <[EMAIL PROTECTED]> wrote:
When we found the cause of NETDEV watchdog timeouts in the wireless-2.6 code,
I knew that the 2.6.18 release code would cause a serious regression.
I don't know if this is the lockup you're trying to address, but
2.6.18's bcm43xx has definitel
On 8/18/06, Andrew Morton <[EMAIL PROTECTED]> wrote:
I assert that this can be solved by putting swap on local disks. Peter
asserts that this isn't acceptable due to disk unreliability. I point
out that local disk reliability can be increased via MD, all goes quiet.
A good exposition w
19 matches
Mail list logo
