Alan Cox, Thu Feb 08 2001 - 02:42:52 EST:
> > It's the printk that gets it wrong, although that's harmless.
> > Intel's documentation states that the bug does NOT exist if the
> > bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct,
> > the printk is wrong.
>
> So why does it fix the problem for him. His report and your reply don't
> make sense viewed together
Wish I'd seen this patch about a month and a half before. I had borrowed two
machines from IBM Denmark for evaluation and their motherboard mounted eepro100
cards (forget which exact chip version it was) didn't quite work with the driver
in the standard RH 6.2.
On boot up it said something about the Receiver lock up bug (only one of the two
messages, I think) and then it locked up anyway half an hour and a couple of
hundred ethernet packets later. I didn't have time to look really closely at
the source code at the time :/
Just another data point indicating that the current receiver lock up enabling
code isn't good enough on newish chips.
-Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 15 2001 - 21:00:14 EST