[lug] Network card errors due to Windoze
Glenn Murray
gmurray at Mines.EDU
Mon Jun 3 16:24:11 MDT 2002
Dan and George, thanks!
There seems to be consensus that the card needs to be reinitialized
when Linux boots. This makes a lot of sense as the LED's on the back
of the card keep flashing even when the computer is "off", and I have
to turn off the power strip to make them stop (and reset the card).
See the relevant quote below. As it does not seem to be possible to
reset the card from the BIOS, is it possible to reset it by the
driver? I understand that the tulip driver works as well as the
manufacturer-supplied dmfe driver. The latter takes no parameters.
Relevant quote from http://www.scyld.com/expert/modules.html
**************************************************
Quick summary: restore operation by unplugging the machine after
running an OS that disables the card. Merely using the "soft-off"
pushbutton on a ATX case is not sufficient.
Many modern PCI chips have ACPI power management capability. Some
include a mode known as "D3-cold", where the chip can power itself
off. When in this mode the chip uses only the tiny amount of stand-by
power always available when an ATX power supply is plugged in. In the
D3-cold mode the chip can be turned on only by writing a PCI
configuration space register. This works great if you have a
ACPI-aware BIOS that knows how to re-enable the chip on a warm boot,
but older BIOS don't know that the chip cannot retain configuration
information. When the machine is warm booted the chip has only invalid
configuration information.
The PnP OS problem occurs because Microsoft has convinced BIOS makers
to modify their PCI device configuration from the previous rational
standard, to one that works well only with Microsoft operating
systems. Where previously the BIOS allocated resources for and enabled
the PCI device by default, it now does so only for boot devices and
audio devices. (Why are audio devices specifically an exception?
Because MS-Windows can't handle the resource allocation for them!)
The solution is to either update to the latest driver, (the drivers
are being re-worked to enable the devices) or to disable the "PnP OS"
setting in the machine's BIOS setup.
The reason Microsoft had to have this change implemented for them was
that MS-Windows still handles some devices with "real-mode" drivers,
and this change makes it easier to mix real-mode and protected-mode
device drivers. This is an excellent example of Microsoft using its
dominant position in the software industry force a technical change
that is detrimental to other operating systems.
**************************************************** end of quote
Thanks,
Glenn Murray
http://www.mines.edu/~gmurray
On Fri, 31 May 2002, D. Stimits wrote:
> "Sexton, George" wrote:
> >
> > My guess would be that as part of the shutdown of the card, Windows is
> > setting the state of the card to something that the driver doesn't know how
> > to handle. I don't believe it's a BIOS problem.
> >
> > The one thing that Windows may be doing to the card at shutdown is enabling
> > WAKE-ON-LAN. I believe win2k has an option at the card level to turn this
> > on or off.
> >
> > Regardless, the issue is almost certainly that Windows is setting the
> > registers and configuration of the card to something that the Linux driver
> > doesn't handle.
> ...
>
> This is one of the reasons why setting the BIOS to not pnp aware is
> good, in theory it would initialize the card at each reboot, even a soft
> reboot, and set default values consistently. While it is not the card or
> bios causing the problem (in the case of windows changing its values), a
> bios that does a full reset via "not pnp aware" would solve the problem,
> and any manufacturer of motherboards with pci slots that doesn't allow
> this setting has fools for engineers.
>
> D. Stimits, stimits at idcomm.com
> _______________________________________________
> Web Page: http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug
>
More information about the LUG
mailing list