John W. Linville wrote:
Obviously it is between you and Dave to decide what is best. We are
carrying this patch in RHEL4 at the moment, so I didn't want to hold
it back from upstream. If you think you have a better solution then
"it's on you"... :-)
Since 2.6.18 already has the recovery logic in place, we can probably
holdoff merging this patch upstream.
If e1000 is having similar problems with a similar AMD chipset, it
must be a fairly widespread problem. It might be a good idea to
push this patch to -stable.
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 7 Jul 2006 14:22:11 -0700
John W. Linville wrote:
quoted
Obviously it is between you and Dave to decide what is best. We are
carrying this patch in RHEL4 at the moment, so I didn't want to hold
it back from upstream. If you think you have a better solution then
"it's on you"... :-)
Since 2.6.18 already has the recovery logic in place, we can probably
holdoff merging this patch upstream.
I think that since we do have a proof positive report, and well
documented success of the fix, we should add the fix even though
we have the fallback thing to take care of it.
This is how we were going to use the fall-back code, to make the the
chipset blacklist more robust yet still allow the user's machine to
work meanwhile. Here, we have enough information to add the blacklist
entry safely.
What do you think?