ensure that building on a host without makeinfo (i.e. a host where
make delete-old -DWITHOUT_INFO was run), then building with MK_INFO == yes
doesn't manifest in build errors when building info pages
This manifested itself like the following when I was build testing an MFC
change on stable/10:
makeinfo --no-split -I /usr/src/gnu/lib/libregex/doc -I /usr/src/gnu/lib/libregex/doc regex.texi -o regex.info
makeinfo: not found
*** [regex.info] Error code 127
make[6]: stopped in /usr/src/gnu/lib/libregex/doc
1 error
Tested on a head VM without makeinfo installed and by building with MK_INFO=yes
MFC after: 1 week
This will result in __ARM_ARCH_7A__ being defined during the compile.
When compiling with gcc, it will still only generate armv6 opcodes itself,
but should pass the arch to gas so that inline asm can use v7 opcodes.
EXP_REDIR was supposed to generate pathnames in redirection if exactly one
file matches, as permitted but not required by POSIX in interactive mode. It
is unlikely this will be implemented.
No functional change is intended.
MFC after: 1 week
exception. In this case no registers will be updated but the link register
will be copied to the program counter to be used to find the calling
function. In this case the program counter may be updated and we should
continue with the trace.
Previously we used gnop(8) to fake 4K sector size disks but ZFS now has a
sysctl to control this when creating new top level vdev's so use that
instead.
Differential Revision: D566
MFC after: 1 month
Sponsored by: Multiplay
Previously ahci_attach returned a hard coded ENXIO instead of the value
from ahci_setup_interrupt. This is effectively a NOOP change as currently
ahci_setup_interrupt only ever returns 0 or ENXIO, so just there to protect
against any future changes to that.
Differential Revision: D838
MFC after: 2 weeks
Sponsored by: Multiplay
This prevents the possiblity of any overruns on the statically allocated
struct irqs field.
Differential Revision: D838
MFC after: 2 weeks
X-MFC-With: r276012
Sponsored by: Multiplay
the created file name was cached. Use the flag for core dumps.
Requested by: rpaulo
Tested by: pho (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
(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.
