bit in the PCI command register for the device. Otherwise, device drivers
that look at this register to see which types of BARs are usable will think
that none of them are.
This allows my Adaptec 1480A cardbus card to finally work.
Reviewed by: imp
alpha. This will take the file out of sync with the private version
that we maintain, but alpha tinderbox has been broken for too long.
Tested on: i386, sparc64, alpha
- Fix some especially bad style in the CIS BAR tuple parsing code.
- activate Option ROMS correctly.
- de-obfuscate the Option ROM image selection code.
- Fix mis-interpretation of the PCI spec that prevented Option ROMs whose
CIS section wasn't in the first image from working.
- Fix mis-interpretation of the PCI spec that prevented CIS's mapped into
MEMIO space from working at all.
- Reject invalid CIS pointers.
Reviewed by: imp
- Set RDTR to zero by default instead of 28.
- Fixed a problem with TX hangs with jumbo frames when number of fragments in the mbuf chain
is large.
- Added support for 82540EP based cards.
MFC after: 3 days
is not long long on all archs. (They happen to be long's on 64-bit arch's
and gcc considers that significant enough to warn about it.) These should
probably be uintmax_t but I didn't feel like adding all the extra includes.
these were cosmetic. However, at least two of these changes fix bugs
where a (fake) pointer to a RX descriptor was added to the physical
memory start address with the cast in the wrong place resulting in
rxdesc[pmem_start] instead of (uintptr_t)rxdesc + pmem_start.
just limited to the DEVICE_POLLING case. This removes the FXP_RFA_RNRMARK
hack, and replaces it with a softc flag that is used to record when
the handling of a no-resource condition was deferred due to running
out of DEVICE_POLLING cycles. This was tested on -stable, but the
code is essentially the same as in -current. It should only affect
the case where DEVICE_POLLING is defined.
The details of the mechanism behind the crashes are still uncertain
but the most likely cause seems to be some kind of hardware confusion
when the no-resource recovery code is accidentally invoked while
the receiver is still active. This could have happened if the
hardware left the 0x4000 bit of the RFA status word set. The comments
in the commit log for revision 1.142 stating that the driver could
clash with the hardware writing to this status word were not correct.
Tested by: Guy Helmer <ghelmer@palisadesys.com>
