d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Modify the xl_reset() routine slightly so that, if we're using memory

Browse Source 
mapped I/O mode, we pause for .1 seconds after issuing the reset command
before trying to poll the 'command busy' bit in the status register.
With my 3c575C cardbus NIC, my Sony Picturebook locks up when it tries
to read the status register immediately after the reset. This appears
to be a problem only with certain NICs on certain hardware, but the
added delay should not hurt cards that already work.

This bug seems to have been brought to light by the fact that the xl
driver now defaults to memory mapped I/O mode instead of programmed
I/O mode like it used to. With PIO mode, the delay isn't needed and
everything works (which is why this NIC worked with 5.0-RELEASE but
not 5.1). I suspect that what's happening is that when the chip is
reset, it takes a little while for the memory-mapped decoding logic
to recover. Trying to access the chip's registers during this period
causes an error condition of some kind that wedges the system.
This commit is contained in:
wpaul 2003-06-29 01:38:57 +00:00
parent 5c2c3d8274
commit 8647884841
1 changed files with 10 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
sys/pci/if_xl.c
View File

@ -1079,6 +1079,16 @@ xl_reset(sc)
((sc->xl_flags & XL_FLAG_WEIRDRESET) ?
XL_RESETOPT_DISADVFD:0));
/*
* If we're using memory mapped register mode, pause briefly
* after issuing the reset command before trying to access any
* other registers. With my 3c575C cardbus card, failing to do
* this results in the system locking up while trying to poll
* the command busy bit in the status register.
*/
if (sc->xl_flags & XL_FLAG_USE_MMIO)
DELAY(100000);
for (i = 0; i < XL_TIMEOUT; i++) {
DELAY(10);
if (!(CSR_READ_2(sc, XL_STATUS) & XL_STAT_CMDBUSY))