frame and if we get a beacon miss interrupt ignore it if we've received
a frame within the beacon miss interval. This should never trigger
and the handling at the net80211 layer should likewise deal with this
but it doesn't hurt and can suppress extranous probe request frames.
Note that we can legtimately get a bmiss when under heavy load.
MFC after: 2 weeks
- Restart watchdog if we *did* processed any descriptors. [1]
- Log the watchdog event if the link is *up*. [2]
PR: kern/92948 [1]
Submitted by: Mihail Balikov <mihail.balikov interbgc.com> [1]
PR: kern/92895 [2]
Submitted by: Vladimir Ivanov <wawa yandex-team.ru> [2]
than just deleting them. Also add comments about why we do this.
Given the current behavior of delete_child, I don't think this changes
anything. It just feels cleaner.
dereferencing) since a NULL value would be a bug here.
Note: Both affected functions look very similar. A refactoring may
be beneficial.
CID: 483, 485
Found with: Coverity Prevent(tm)
Discussed with: ariff
MFC after: 5 days
needed here, except there's a bug which results in detaching the device
twice.
Move the NULL pointer check to the beginning of the function and convert
it into a KASSERT.
CID: 420
Found with: Coverity Prevent(tm)
Discussed with: ariff
MFC after: 5 days
Control) devices as console. These are microcontrollers which are either
on-board or part of an add-on card and provide terminal server, remote
power switch and monitoring functionality. For console usage these are
connected to the rest of the system via a SCC or an UART. This commit adds
support for the following variants (corresponds to what 'input-device' and
'output-device' have to be set to):
rsc found on-board in E250 and supposedly some Netra, connected
via a SAB82532, com. parameters can be determined via OFW
rsc-console RSC card found in E280R, Fire V4x0, Fire V8x0, connected
via a NS16550, hardwired to 115200 8N1
lom-console LOMlite2 card found in Netra 20/T4, connected via a NS16550,
hardwired to 9600 8N1
- Add my copyright to uart_cpu_sparc64.c as I've rewritten about one third
of that file over time.
Tested on: E250, E280R
Thanks to: dwhite@ for providing access to an E280R
OK'ed by: marcel
MFC after: 1 week
casting a structure to a uint32_t *. Many drivers in the tree do this, but
I'll not update them until these changes can be reviewed by the pedantic
standards folks.
in order to query the underlying Windows driver for the station address
and some other properties. There is a slim chance that the card may
receive a packet and indicate it up to us before ndis_attach() can call
ndis_halt_nic(). This is bad, because both the softc structure and
the ifnet structure aren't fully initialized yet: many pointers are
still NULL, so if we make it into ndis_rxeof(), we will panic.
To fix this, we need to do the following:
- Move the calls to IoAllocateWorkItem() to before the call to ndis_init_nic().
- Move the initialization of the RX DPC and status callback function pointers
to before ndis_init_nic() as well.
- Modify ndis_rxeof() to check if the IFF_DRV_RUNNING flag is set. If it
isn't, we return any supplied NDIS_PACKETs to the NIC without processing
them.
This fixes a crash than can occur when activating a wireless NIC in
close proximity to a very busy wireless network, reported by Ryan
Beasley (ryan%^$!ATgoddamnbastard-****!!!DOTorg.
MFC after: 3 days
are bus_addr_t, not bus_size_t.
In any case, turn off DAC support entirely until it is revamped to actually
work *correctly* for 64 bit platforms (not using a PAE definition and for
both initiator and target mode).
Treat SIOCADDMULTI and SIOCDELMULTI the same, since they had the same code
Remove redundant assignment to error
Convert to using the altq interface completely.
to sbus_mdvec.dv_clock as sbus_mdvec.dv_clock is meant to be specified
in MHz. While this was a bug it shouldn't have affected FreeBSD/sparc64
as sbus_mdvec.dv_clock is used to limit the clock rate of chips when
a machine isn't able to support them at maximum speed which isn't the
case for sun4u machines.
- Remove the code that checks whether the clock frequency returned by
sbus_get_clockfreq() is 0 and falls back to 25MHz if it is as that's
already done in sbus(4).
Approved by: mjacob
MFC after: 3 days
