I recently discovered (as others have posted to the list) that the
currently included eepro100 driver doesn't work on Intel 815 (and
possibly other) integrated mainboards. I stops working after a bit
of activity and in some circumstances totally locks up the machine.
For more details scan the archives, lots of people have run into
this.
I'm now using the e100 driver from the Intel web site, which works
perfectly, and light testing shows the Scyld (Don Becker) driver
to work as well. The Intel driver seems to have an incompatible
license (noxious advertising clause?), but the Scyld drivers don't...
at least there isn't any license mentioned and of course many
of the net drivers in the current kernel are just earlier versions
of the Scyld drivers.
815 MBs are pretty common, so getting a solution to this should
be pretty important. I'm surprised that RedHat didn't include
the Scyld drivers in 7.2... these network lockups should present
a major support headache for them.
So what's the scoop? Anyone have plans to fix this?
:j
--
J?rgen Botz | While differing widely in the various
[email protected] | little bits we know, in our infinite
| ignorance we are all equal. -Karl Popper
Jurgen Botz wrote:
> I'm now using the e100 driver from the Intel web site, which works
> perfectly, and light testing shows the Scyld (Don Becker) driver
> to work as well. The Intel driver seems to have an incompatible
> license (noxious advertising clause?), but the Scyld drivers don't...
> at least there isn't any license mentioned and of course many
> of the net drivers in the current kernel are just earlier versions
> of the Scyld drivers.
The Scyld drivers have only recently started working with the 2.4 series,
and there is some unholly war between Becker and the rest of the kernel
hackers...so I don't think you'll ever see his drivers in the standard
kernel again... RH usually tries to load the e100 (Intel's driver)
instead of the eepro100. The e100's license is close to compatible
with the kernel, and I've heard rumors that the remaining issues may
be worked out... I've also heard the code is ugly as hell...but it
does seem to work. If only the e100 supported MII IOCTLs then I'd
use it all the time!
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
> I'm now using the e100 driver from the Intel web site, which works
> perfectly, and light testing shows the Scyld (Don Becker) driver
> to work as well. The Intel driver seems to have an incompatible
> license (noxious advertising clause?), but the Scyld drivers don't...
> at least there isn't any license mentioned and of course many=20
> of the net drivers in the current kernel are just earlier versions
> of the Scyld drivers.
Its not quite that simple - they are branches. If the Becker driver works
and the -ac driver doesn't then that is good news and it would be very
interesting to figure out which change mattered.
The -ac kernel on my i810/i815 boxes works reliably providing I dont turn
on the ACPI stuff
Ben Greear wrote:
>
> Jurgen Botz wrote:
>
> > I'm now using the e100 driver from the Intel web site, which works
> > perfectly, and light testing shows the Scyld (Don Becker) driver
> > to work as well. The Intel driver seems to have an incompatible
> > license (noxious advertising clause?), but the Scyld drivers don't...
> > at least there isn't any license mentioned and of course many
> > of the net drivers in the current kernel are just earlier versions
> > of the Scyld drivers.
>
> The Scyld drivers have only recently started working with the 2.4 series,
> and there is some unholly war between Becker and the rest of the kernel
> hackers...so I don't think you'll ever see his drivers in the standard
> kernel again... RH usually tries to load the e100 (Intel's driver)
> instead of the eepro100.
No we do not. eepro100 is the default in Red Hat Linux 7.1 and 7.2 at
least.
I wish Intel would help fix eepro100 for the last few remaining issues
it has....
Arjan van de Ven wrote:
> No we do not. eepro100 is the default in Red Hat Linux 7.1 and 7.2 at
> least.
> I wish Intel would help fix eepro100 for the last few remaining issues
> it has....
Perhaps that was only 7.0, or just my particular NICs... I would
definately prefer a fully functional eepro100 driver in the kernel too...
Ben
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
> > I wish Intel would help fix eepro100 for the last few remaining issues
> > it has....
>
> Perhaps that was only 7.0, or just my particular NICs... I would
> definately prefer a fully functional eepro100 driver in the kernel too...
Older RH used e100 for some chipsets.
> The Scyld drivers have only recently started working with the 2.4 series,
> and there is some unholly war between Becker and the rest of the kernel
Hardly that. Donald does things his way, and then other folks pick up his
changes where good (most of the time in fact) and merge them into the
kernel drivers.
If someone can figure why Don's driver sorts out the 815E hangs then thats
stuff we want in the main stream.
> instead of the eepro100. The e100's license is close to compatible
> with the kernel, and I've heard rumors that the remaining issues may
> be worked out... I've also heard the code is ugly as hell...but it
The patent grant thing got sort of sorted out (last I saw it was seems ok
now ask vendor legal people). Unfortunately it seems the intel people want
to force e100.c into the kernel by refusing to work on eepro100.c.
As anyone can tell you trying to force things on Linux developers generally
works out pretty badly. Other bits of Intel are being quite sane (eg most
of the ACPI stuff except for the speedstop mobile stuff).
Alan
Arjan van de Ven wrote:
> No we do not. eepro100 is the default in Red Hat Linux 7.1 and 7.2 at
> least.
hmm that's odd - when I did a clean install
of 7. 1 on my new system with intel mobo,
I discovered that modules.conf contained
the line "alias eth0 e100"
cu
jjs