to config_found()
(after some cleanup we might be able to kill SCSIPI_BUSTYPE_*)
-remove scsipiprint() -- the parts which make it differ from
scsiprint()/atapiprint() were unreachable anyway
back out my change to ieee80211_crypto_encap that made it free its
mbuf argument on error. I had thought it was a bug. It was not.
It's the drivers that are broken. Make an(4), atw(4), ipw(4),
iwi(4), ral(4), rtw(4), ural(4), and wi(4) free the mbuf when
ieee80211_crypto_encap returns NULL. Also, return ath(4) to the
way it was---i.e., free the mbuf.
Thanks to Sam Leffler to pointing out my mistake.
returns EINVAL, indicating that DMA cannot be done for this transfer.
Fall back to PIO in this case.
- Add a geodeide_dma_init() routine that checks to make sure that transfers
start on a 16 byte boundary, returning EINVAL if not. Works around a chip
bug that causes a hard system hang.
Problem reported and patch tested by Erik Fair.
+ Synchronize ath_calibrate() with ATH_LOCK()/ATH_UNLOCK(). Thanks
to Steve Woodford for suggesting this fix. This patch stops
ath(4) from generating messages "hardware error; resetting" while
Steve's D-Link DWL-AG650 card is operating (kern/28385). The
MiniPCI wireless adapter on one of my Soekris boards also operates
more reliably following this patch.
+ Use ATH_LOCK_IMPL() and family to synchronize access to the
transmit queue, also.
rate, with short preamble turned *off*. Fixes IBSS operation,
where multicast frames were sent at the highest possible rate with
short preamble turned *on*, so the likelihood of reception was
relatively low, and there was no chance for stations w/o short
preamble capability to receive the frames.
XXX This is a quick fix that I will revisit very soon. Multicast
data frames are eligible to be sent with short preamble in
IEEE80211_M_STA, IEEE80211_M_HOSTAP modes. An AP knows who all of
its peers are at all times, so it can make an intelligent decision.
Ditto the AP client.
XXX The rate adaptation should be involved in choosing short/long
preamble. Also, we can make a reasonable choice of a higher
multicast data rate based on statistics gathered by the rate
adaptation module.
system hangs whenever a read or write request to sector 0xfffffff occurs.
The hang appears to happen when:
status = bus_space_read_1(wdr->cmd_iot, wdr->cmd_iohs[wd_status], 0);
is executed in __wdcwait(), and it is not possible to enter the debugger or
make the system respond at all after this point.
Whilst not necessarily the most prudent solution to handling the large number
of drives that exhibit this problem, it is currently the popular workaround.
[An alternative approach is to just always drop to LBA48 if the request
happens to pass by sector 0xfffffff and the drive reported as larger than
0xfffffff sectors. My understanding is that the 32 bit addressing below
0x10000000 is purely there as a performance booster, not to resolve a
compatibility issue.]
Damien Bergamini, ported and submitted by FUKAUMI Naoki per PR kern/30449
I've modified the USB "ural" driver for recent changes to the NetBSD
ieee80211 framework, possibly not completely, but with an ASUS wireless
adapter I'm getting some signs of life.
Didn't care about pci/cardbus for now, hopefully someone with hardware
will do it.
