don't activate any quirks for VM_6 variant
problem reported by Lars Heidieker on current-users
also don't activate any quirks for VM_3 - VM_5 variants, neither
VE_2 - VE_4, in anticipation that the more modern variants don't need
the quirks
so make driver match it
while here, also make the driver match 'Intel PRO/100 VM with
82562EM/EX (CNR) PHY', with anticipation it would work fine too
activate the resume and dynamic standby bug workaround for these; might
not be necessary (not confirmed to be needed), but better safe than sorry
Adresses PR kern/20689
The ICH on-board Ethernet and some i82559 chips have a bug which
will cause a PCI protocol violation if the chip receives a CU_RESUME
command as it is entering the IDLE state by deasserting #CLKRUN.
(This is the so-called "resume bug" that we previously had an incomplete
work-around for on ICH chipsets.)
The work-around is to disable Dynamic Standby Mode, such that the
chip will never deasert #CLKRUN. Dynamic Standby Mode is disabled
by clearing a bit in the EEPROM and updating the EEPROM (and EEPROM
checksum).
Unfortunately, the chip will only consult the EEPROM setting after
a PCI bus reset, so a system reboot is required once the EEPROM
has been updated (the EEPROM update only needs to happen once,
and the driver usses a warning instructing the user to reboot the
system once the work-around has been applied).
Issue pointed out by David Brownlee, and code more-or-less lifted
from FreeBSD.
capability, using D3 and D0 power states. This saves me quite a bit
of battery when not using the built-in Ethernet on my IBM T-20 during
long IETF meetings.
pci_attach_args *" instead of from four separate parameters which in
all cases were extracted from the same "struct pci_attach_args".
This both simplifies the driver api, and allows for alternate PCI
interrupt mapping schemes, such as one using the tables described in
the Intel Multiprocessor Spec which describe interrupt wirings for
devices behind pci-pci bridges based on the device's location rather
the bridge's location.
Tested on alpha and i386; welcome to 1.5Q
this could result in garbage being written to the PCI status register,
which is unlikely to have had a serious effect. This was with us from
an #if 0 added in rev 1.6.
Address kern/9370, kern/9548, kern/9571, and kern/9573.
Save and restore critical PCI configuration registers because they are
sometimes bashed.
Add a powerhook to restore said PCI registers after APM events.
The fxp now works across a warm boot from windows (vaio).
The fxp now works across an apm suspend/resume or hibernate/resume cycle.
