[eepro100] Re: system hangs @ boot-time when bringing up eth0

[Andrey Savochkin]

Derek,

On Fri, Sep 08, 2000 at 02:09:21PM -0400, Derek Glidden wrote:
> Andrey Savochkin wrote:
> > Certainly, I regret that the driver has the defect and the inconvenience it
> > caused, but the issue doesn't worth more than a short complain :-)
> 
> Wow, boy, I'm just not sure how to respond to that.  I don't want to
> come off sounding like a jerk, (because I'm not, really, I swear) but
> ... "you gotta be kidding me?!"  
> 
[snip]
> Things are even worse than that because now we're stuck with the options
> of a) using an older kernel, b) trying to back-port all the patches made
> against the more recent kernels into an older kernel or c) trying to
> forward-port the older eepro driver into recent kernels.  a) sucks
> because kind of the whole point of kernel upgrades is to fix stuff that
> might be broken and in our case we use patches for stuff like IPVS where
> the recent versions only apply to recent kernels, and b) and c) suck
> because we don't get paid to hack kernel patches around so our systems
> work reliably.

If you had asked people about how to solve this problem, you would get exact
instructions what to do or what driver to download.
That's how the system works: if something goes wrong, you're able to contact
the developers directly and get quick fixes.

[snip]
> 
> > I believe (however, not absolutely sure without the documentation) that the
> > bug has existed in the driver for a very long time, a few years.
> > The sporadic faults started to appear only recently because the operation
> > timings were changed by innocent and unrelated changes.
> 
> Perhaps it's existed, but whatever those changes are have certainly
> aggravated the problem to the extent that it's much more visible.  I've
> *never* seen this bug pop up with older eepro drivers.  
> 
> Whether or not the bug might have existed before, whatever has been
> changed has turned it from something that might occur in very very rare
> situations into something that is common, which, logically I think,
> would turn it from nearly a non-issue into a major bug.  Again, not
> being a kernel hacker, I can't say that I am intimately familiar with
> kernel development, but it would seem to me that a situation like that
> would require that those changes be backed out, at least from the

It wouldn't do it.
Backing out all the changes would cause even more troubles.
The mainstream driver in 2.2.14 kernel was absolutely broken for 82559ER
chips (because a third-party dirty hack had slipped in), it had wrong EEPROM
access timings (in MMIO mode) that caused problems for really a lot of
people and so on, so I evaluate that in that case much more people would
suffer.  It's the choice between bad and worse...

> "stable" kernel series, until a more concrete reason why this happens
> was worked out and a "real" fix was developed.  
> 
> Also I must take issue with the term "sporadic faults."  I see it on a

I meant that on a single system it's reproducible not in 100% reboots.

> daily basis nowadays.  It's really annoying.

So, fix it.  Grab Donald's driver.  Apply any of the fixes I've given on
linux-kernel list.  Man, your system is in your hands!  Nobody's playing
dirty games of hiding information.  It's the opposite case: all people
involved are ready to help you.

Best regards
					Andrey V.
					Savochkin