Age | Commit message (Collapse) | Author |
|
theyve been used, in particular the mfi header flags which has a bit
that specifies if a command should be completed via the interrupt path.
if we use a ccb during boot we set that bit, but it isnt necessarily
cleared by things that use it later on. this means a ccb we expected to
complete via an interrupt never actually generates an interrupt or appears
in the reply queue. this obviously stalls the io.
|
|
enough to get the device unstuck. OK mglocker@
|
|
between instances, saving space in the kernel. feedback from many (some
incorporated, some left for future work).
ok deraadt, kettenis, "why not" miod.
|
|
|
|
|
|
mark the xs as done and call scsi_done for it rather than just returning
COMPLETE.
|
|
the sleep waiting for the completion. it is possible to get the interrupt
completing the command just before the tsleep, which will never get a
wakeup because the interrupt with the wakeup has already happened.
|
|
ok dlg@
|
|
ok dlg@, jsg@
|
|
"If it works for you, commit it. The diff looks right." claudio@
"Seems to work here with ACX111 CardBus" jsg@
|
|
ok claudio@
|
|
|
|
NO_CCB is in place and the I/O is retried rather than discarded.
So move the message inside a #ifdef CAC_DEBUG.
Noticed by jbg@.
|
|
similar fix to osiop.
|
|
Tested by apelsin.
ok deraadt@
|
|
ok marco@
|
|
chipset.
ok deraadt@
|
|
With the current code, a fast command could complete between splx and
the timeout being triggered, we'd then happily return COMPLETE, reuse
the scsi_xfer, schedule the timeout again, causing a nice cycle in the
timeout wheels.
(I know, I know, I have to inspect all other scsi drivers now, but I'm
really tired after spending three hours on this)
|
|
Amendment to fix for PR6089. Patch by mglocker@
"good night guys!" mglocker@, "hurry up" deraadt@
|
|
generating worrying error messages. Or possibly losing i/o's.
tested by jbg@ ok deraadt@
|
|
as additional argument. This will allow intermediate layers between
scsi devices such as sd and scsi host adapters to take appropriate
action if necessary.
|
|
with help from miod@
ok miod@ oga@
|
|
|
|
realteks start to behave badly if we do. this should fix the widely
reported re(4) issue. makes my RTL8101E usable, fixes Thomas'
RTL8168C, and PR6023. tested by many
this is a more conservative version of my diff from kettenis@ (does
not clear PHY register 0x0b)
ok kettenis@
|
|
anymore but make reading the code harder.
ok sthen@ miod@ krw@
|
|
information. This is preliminary work to help eventually supporting the
dual-head ELK model.
Also split the initialization code in several routines, this makes the
code easier to read, and makes it easier to release resources upon failure.
Finally, don't forget to clear the text planes on non-console displays
when initializing.
|
|
with only one font (such as many 712 onboard graphics). Oops again (poukram).
|
|
that may confuse gcc with a simple boolean expression.
ok reyk@
|
|
resulting in unaligned IP headers (because it aligns the ethernet header).
Found the hard way by landry@ on sparc64.
|
|
switching consoles or when X11 exits. Almost all other operating systems
do this, and thus do not suffer from palette bugs in some X11 drivers.
From FreeBSD.
|
|
|
|
it's a can't happen situation.
|
|
From Jim Giannoules <gortag@gmail.com>
|
|
display resolution, and if one is found, pick the built-in font it points
to, instead of the first font from the list. If the index is wrong and the
font list is shorter, revert to the previous behaviour of using the first
ROM font.
This fixes the font discrepency on my B132L (INTERNAL_EG_1280) where PDC
would use the 10x20 font, which is third in the list, and OpenBSD would
use the 8x16 font instead.
Tested on byte- and word- roms, gsc and pci cards.
|
|
to prevent the hwm growing beyond that. this allows the livelock mitigation
to do something where the hwm used to grow beyond twice the rx rings size.
ok kettenis@ claudio@
|
|
with other net80211 flags (we no longer need to shift.)
|
|
- implement A-MPDU frames buffering and reordering
- implement A-MSDU decapsulation
- process/send ADDBA Request, ADDBA Response and DELBA action frames
- process Block Ack Request control frames (including MTBAR)
- implement PBAC support (Protected Block Ack)
- add some incomplete HT Capabilities and HT Operation IEs parsing
Add more Management Frame Protection bits based on 802.11w Draft 7.0:
- implement SA Query procedure (both AP and STA)
- cleanup BIP
Fix some bugs:
- fix check for WEP key length that otherwise caused a stack smash in
ieee80211_wep_encrypt (pointed out by Xavier Santolaria on macppc)
- properly stop EAPOL timeout: fixes a panic that occured in HostAP mode
when turning the interface down while a 4-way handshake is in progress
(pointed out by Doughertys)
Did some code cleanup too.
The HT bits are currently not compiled in (IEEE80211_NO_HT is defined)
because they won't be ready until after the next release and I didn't
want to grow the kernel or to inadvertently introduce new bugs.
They are here such that other people can look at the code.
Notice that I had to add an extra parameter to ic_send_mgmt() for
action frames, that is why there are small changes in drivers defining
their own ic_send_mgmt() handler.
Sorry for the not very incremental diff but this has been sitting in
my tree for too long now.
|
|
No functional changes.
ok krw@ miod@
|
|
data buffer.
|
|
to issue a command.
|
|
ok niklas@ otto@
|
|
conversions.
ok kettenis@
ok krw@ (possibly for the second time :)
|
|
|
|
anywhere speed critical and the libkern one is perfectly fine.
|
|
instead of an EEPROM.)
- fix default LEDs and RF settings (when info is missing from EEPROM.)
- gracefully stop Tx in run_stop().
|
|
filled and that the IEEE80211_RADIOTAP_F_SHORTPRE flag is set properly.
- fix set_chan() for RT3070.
- add some crazy BBP/RF registers tweaks for RT3070 (mostly HW bugs
workarounds extrapolated from the Ralink Linux driver.)
|
|
|
|
add some definitions for RT2870/RT3070.
|
|
|
|
m_defrag() does not work. It seems to assume that if the length of
the mbuf passed as parameter is less than MHLEN, then it is an mbuf
header and not a cluster (or something like that.)
It thus fails miserably in the bcopy path.
I don't have the time to investigate further into this.
Thanks to Okan Demirmen for reporting the issue on a ral(4) RT2560.
The RT2560 chipset does not support TX scatter and thus m_defrag()
was called much more often than in other drivers using m_defrag()
where it was less noticeable.
|