From: Ben Greear <[EMAIL PROTECTED]>
Date: Wed, 18 Jan 2006 16:35:28 -0800
> We've had worse kernel bugs in official releases!
Please document the change that made it into an official release that
broke every user of a given piece of hardware, regardless of kernel
configuration or chip revision o
David S. Miller wrote:
It's pretty stupid and counter productive, and in this case here
resulted in Intel's engineering process looking rather poor. This
e1000 incident is one of the worst vendor driver maintainence bombs
I've seen in my 10+ years of doing Linux kernel work.
We've had worse k
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Wed, 18 Jan 2006 19:10:32 -0500
> Its just plain inefficient.
I think part of this has to do with Intel's internal legal
policies for public code release. It's time consuming and
highly encourages the engineers to batch code releases so
that they minim
From: "Ronciak, John" <[EMAIL PROTECTED]>
Date: Wed, 18 Jan 2006 15:46:24 -0800
> What was tested was the entire patch set which included the pre-fetch
> patch.
Therefore, you sent patches you know you had to make major surgery
to before submission compared to what you actually tested.
You submi
Ronciak, John wrote:
What was tested was the entire patch set which included the pre-fetch
patch. Since there so much controversy over the pre-fetch patch let
last time we moved that patch to the end of the patch set. Then we
asked ourselves if we should send that patch out at all. We decided
rg, Jesse
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Kirsher, Jeffrey T;
> Ronciak, John; netdev@vger.kernel.org
> Subject: Re: e1000 breakage in Jeff's tree
>
>
> From: Jesse Brandeburg <[EMAIL PROTECTED]>
> Date: Wed, 18 Jan 2006 14:20:28 -0800 (Pacific Sta
Jesse Brandeburg <[EMAIL PROTECTED]> wrote:
>
> On Wed, 18 Jan 2006, Andrew Morton wrote:
> > git-bisect of mainline claims that the regression was introduced by commit
> > 0fadb0597d240d4ed279042cab632d567510a1a3, "e1000: Fix collision distance".
> > Jeff(K), I can test patches...
>
> it appears
From: Jesse Brandeburg <[EMAIL PROTECTED]>
Date: Wed, 18 Jan 2006 14:20:28 -0800 (Pacific Standard Time)
> The root cause of the bug is that the receive routine was in a bad state
> because we didn't submit our prefetch patch, which unfortunately didn't
> have just prefetchy things in it.
So di
On Wed, 18 Jan 2006, Andrew Morton wrote:
git-bisect of mainline claims that the regression was introduced by commit
0fadb0597d240d4ed279042cab632d567510a1a3, "e1000: Fix collision distance".
Jeff(K), I can test patches...
it appears git bisect is wrong, there is nothing in that patch that woul
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> > It'd be easier for me to just pull the bare patches out of git. But I
> > haven't yet worked out how to persuade git to do that in a sane fashion
> > (help)
>
> I use 'git-diff-tree -p $hash'
>
I seemed to screw that up and got
Andrew Morton wrote:
It'd be easier for me to just pull the bare patches out of git. But I
haven't yet worked out how to persuade git to do that in a sane fashion
(help)
I use 'git-diff-tree -p $hash'
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the bo
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> > The e1000 changes which popped up in Jeff's netdev tree today break the
> > driver on my emt64 box. There's no real sign of damage apart from the fact
> > that it simply won't send stuff.
> >
> > e1000: :01:02.0: e1000_probe:
Andrew Morton wrote:
The e1000 changes which popped up in Jeff's netdev tree today break the
driver on my emt64 box. There's no real sign of damage apart from the fact
that it simply won't send stuff.
e1000: :01:02.0: e1000_probe: (PCI:33MHz:32-bit) 00:0e:0c:2f:2c:c1
e1000: eth0: e1000_prob
13 matches
Mail list logo
