(UTC) rather than the archaic (GMT) in comments. Except where the
comments are making fun of people doing this (and pedants who insist
on the new terms).
to awake transition as well as handle waking up a VAP in STA powersave
mode if it's in bgscan.
This was a reasonably hairy bug to try and figure out and it became
more obvious because of stuff I've done.
Specifically:
* a NIC would go into bgscan mode - either because of a bgscan timer
or wpa_supplicant asked it to;
* the AP would indicate there's traffic for the STA by setting the TIM
bitmap bit for it;
* mindwell would be met during scan, so it'd wake up and break out of
the scan loop in scan_task(), but
* because the scan wasn't completed, it wouldn't bring the VAP out of
STA mode powersave (so it wouldn't tell the AP about it and it would
block VAP TX);
* .. but because we kept seeing the TIM bit set, ic->ic_lastdata was
being constantly updated, and ..
* bgscancont() would thus never say "yes we can continue a bgscan"
so the bgscan would hang and never make progress.
Now, I do see this particular state occur on iwn(4) - /however/ -
this NIC has the firmware call ieee80211_scan_next() once the firmware
scan for that channel has completed. This has the effect of moving
the scan along to the next channel. I do see the debug that I'm adding
where we see a beacon with a TIM bit set whilst we're in bgscan, so
the condition about waking up to receive traffic is triggering.
It just won't cause a hang.
For other NICs - all of the USB ones and at least ath(4) -
ieee80211_scan_next() / ieee80211_scan_done() isn't called.
So it relies upon the mindwell timer, the beacon receive and the
beacon / probe response -> ieee80211_add_scan() to move along
the scan state.
In the above case, mindwell triggered, there's no beacons triggering
the scan_add code to move things along, and we weren't waking things
up when seeing the TIM set for us. So it just hung until the interface
was dropped.
So, the short-term fix here is to do what the comment in scan_task()
says - if we are in bgscan mode and we see our TIM bit set, just wake
up the VAP. If it's already awake then it's a nop. If we're awake
then we transition to awake and handle the traffic. Once there's no
TX or RX traffic going on, ic->ic_lastdata won't be updated anymore
and bgscancont() will continue.
This was triggered more often after my initial SLEEP state handling
for software sleep states - because now I update ic->ic_lastdata
upon seeing a TIM bit set, not just the RX of the subsequent traffic.
That's needed so the thing doesn't ping-pong up and down between
seeing the TIM bit set, sending the "I'm awake" NULL data frame, and
starting to receive data from the AP.
I'd like to subsequently split ic_lastdata into two - one for TX and
one for RX - so it becomes easier to use the correct one (or both!)
when making decisions like whether to scan, go to sleep, etc.
I'd appreciate this getting some further testing.
Tested:
* rsu(4), STA mode, bgscan on
* iwn(4), STA mode, bgscan on
that indicates we have traffic" bit and a "do something if we have
traffic bit."
I'm going to be fleshing out this stuff more over time and it'll make
more sense to have it broken out into two pieces here.
why there could appear a zero-sized mbufs in socket buffers.
A proper fix would be to divorce record socket buffers and stream
socket buffers, and divorce pru_send that accepts normal data from
pru_send that accepts control data.
deal/log a warning if the scan flags change during one of those race
windows.
It's highly likely that I need to actually sit down and replace this
scan infrastructure at some point. It has some other side effects too -
the scan task is a blocking task scheduled in the net80211 taskqueue;
so drivers that use this taskqueue have other things not run. Eek.
If you see this printf happen then please let me know!
in sbappend_locked() and sbappendrecord_locked().
This is a quick fix to the panic introduced by r274712.
A proper solution should be to make sosend_generic() avoid calling
pru_send() with NULL mbuf for the protocols that do not understand
control messages. Those protocols that understand control messages,
should be able to receive NULL mbuf, if control is non-NULL.
- implement 8259 "polled" mode.
- set 'atpic->sfn' if bit 4 in ICW4 is set during master initialization.
- report error if guest tries to enable the "special mask" mode.
Differential Revision: https://reviews.freebsd.org/D1328
Reviewed by: tychon
Reported by: grehan
Tested by: grehan
MFC after: 1 week
such as timeouts while probing a bus or testing for a feature, is
squelched. Also, error reporting is limited to 5 events per second,
because when an sdcard goes bad on a low-end embedded board, flooding
the console at high speed isn't helpful.
Original logging code contributed by Michal Meloun, but then I fancied
it up with squelching and ppsratecheck.
TI OMAP controllers which will return the reset-in-progress bit as zero if
you read the status register too fast after setting the reset bit.
The zero is apparently from a stale snapshot of the internal state presented
in the interface register, and leads to a false indication that the reset
is complete when it either hasn't started yet or is in-progress. The
workaround is to first loop until the bit is seen as asserted, then do the
normal loop waiting to see it de-asserted.
Submitted by: Michal Meloun <meloun@miracle.cz>
have been in the base for a while, so the gymnastics here aren't
needed. In addition, the bugs in subr_disk.c have been fixed since
2009, so there's no need for an identical copy of it in the tree
anymore. There's really no need to binary patch g_io_request, so let's
get rid of the code (not compiled in anymore) lest others think it is
a good idea.
This assertion was added in r246213 as a guard against corrupted mbufs
arriving from drivers, the key distinguishing factor of said mbufs being
that they had a negative length. Given we're in a while loop specifically
designed to skip over zero-length mbufs, panicking on a zero-length mbuf
seems incorrect.
No objection from: kib
kernel does not panic with zfs_panic_recover.
Illumos issue:
5438 zfs_blkptr_verify should continue after zfs_panic_recover
Reported by: Coverity
CID: 1232014
As of r270383, the dbuf_compare comparator compares the dbuf
attributes in the following order:
db_level (indirect level)
db_blkid (block number)
db_state (current state)
the address of the element
Because db_state is being considered before the element's state,
changing of db_state would affect balancedness of the AVL tree,
even when the address of element compares differently. For
instance, in dbuf_create, db_state may be altered after the
node is inserted into the AVL tree and may break AVL tree
balancedness.
Instead of using db_state as a comparision critera (introduced
in r270383), consider it only when we are doing a lookup, that
is one of the two dbuf pointers contains DB_SEARCH.
Illumos issue:
5422 preserve AVL invariants in dn_dbufs
MFC after: 2 weeks
function parameters, the card has to be in transfer state. If it is in
the idle state, the commands are ignored. This caused us not to set
the proper parameters that we later assume to be present, leading to
downstream failures of the card / interface as our state machine
mismatches the card's.
Submitted by: Svatopluk Kraus <onwahe at gmail.com>, Michal Meloun
<meloun at miracle.cz>
we import it along with utilities in elftoolchain.
Differential Revision: https://reviews.freebsd.org/D1330
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
into namecache, to avoid cache trashing when doing large operations.
E.g., tar archive extraction is not usually followed by access to many
of the files created.
Right now, each VOP_LOOKUP() implementation explicitely knowns about
this quirk and tests for both MAKEENTRY flag presence and op != CREATE
to make the call to cache_enter(). Centralize the handling of the
quirk into VFS, by deciding to cache only by MAKEENTRY flag in VOP.
VFS now sets NOCACHE flag for CREATE namei() calls.
Note that the change in semantic is backward-compatible and could be
merged to the stable branch, and is compatible with non-changed
third-party filesystems which correctly handle MAKEENTRY.
Suggested by: Chris Torek <torek@pi-coral.com>
Reviewed by: mckusick
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
it's not just 11b/11g.
The following was happening, and it's quite .. annoyingly grr-y.
* create vap, setup wpa_supplicant with no bgscanning, etc - there's
no call to ieee80211_media_change, so vap->iv_des_mode is
IEEE80211_MODE_AUTO;
* do ifconfig wlan0 scan - same thing, media_change doesn't get called,
iv_des_mode stays as auto.
* But then, run wpa_cli and do 'scan' - it'll do a media change.
* if you're on 11ng, vap->iv_des_mode gets changed to IEEE80211_MODE_11NG
* Then makescanlist() is called. There's a block of code that gets
called if iv_des_mode != IEEE80211_MODE_AUTO, and it does this:
if (vap->iv_des_mode != IEEE80211_MODE_11G ||
mode != IEEE80211_MODE_11B)
continue;
mode = IEEE80211_MODE_11G; /* upgrade */
* .. now, iv_des_mode is not IEEE80211_MODE_11G, so it always runs
'continue'
* .. and thus the scan list stays empty and no further channel
scans occur. Ever.(1)
If you then disassociate and try associating to something, your
scan table has likely been purged / aged out and you'll never
see anything in the scan list.
(1) You need to do 'ifconfig wlan0 mode auto' or just destroy/re-create
the VAP to get working wireless again.
Tested:
* iwn(4) - intel 5300 wifi; STA mode; using wpa_supplicant; bgscan
enabled -and- wpa_supplicant scanning.
Thanks to:
* Everyone who kept poking me about this and wondering why the hell
their wifi would eventually stop seeing scan lists. Grr.
I eventually snapped this evening and dug back into this code.
While in most cases CTL should correctly fetch those values from backing
storages, there are some initiators (like MS SQL), that may not like large
physical block sizes, even if they are true. For such cases allow override
fetched values with supported ones (like 4K).
MFC after: 1 week
While we don't support MCS, hole in received sequence numbers may mean
only PDU loss. While we don't support lost PDU recovery, terminate the
connection to avoid stuck commands.
While there, improve handling of sequence numbers wrap after 2^32 PDUs.
MFC after: 2 weeks
