generations of 802.11abg chipsets from Ralink Technology.
Get rid of the pccard front-end while I'm here since all adapters are
cardbus ones.
Obtained from: OpenBSD
into a separate module. Accordingly, convert the option into a device
named similarly.
Note for MFC: Perhaps the option should stay in RELENG_6 for POLA reasons.
Suggested by: scottl
Reviewed by: cokane
MFC after: 5 days
to call back for completition and something else is holding the taskqueue
waiting for ATA to return data.
This should clear up the "semaphore timeout !! DANGER Will Robinson !!"
in most situations, and log "taskqueue timeout - completing request directly"
instead, with a delayed "WARNING - freeing taskqueue zombie request" when
the taskqueue finally calls us back with the now stale request.
(It would have been nice if there was a way to remove a scheduled item from
a taskqueue, but that is not currently implemented in the kernel).
A real fix for this is in the works but wont make it to 6.1RELEASE
definite MFC candidate.
- Don't use a common buffer in the softc to store per-command data. Reserve
a buffer in the command itself.
- Don't allocate DMA memory for the kernel command structures when all you
really need is DMA memory for the scratch buffer embedded in them. Instead
allocate a slab for the scratch buffers and divide it up as needed.
- Call bus_dmamap_unload() at the completion of commands.
- Preserve and clear the CAM CCB status flags at completion.
- Reorder some low-level command operations to try to close races.
- Limit the simq to 32 commands for now. There are some serious problems
with the driver under load that are not well understood, so keeping the
simq lower helps avoid this. It has been tested at a higher value, but
this is a safe value that doesn't show much performance degredation.
These changes allow the driver to work reliably with >4GB of memory on i386
and amd64, and also work around deadlocks seen under very high load in
certain situations. The work-around is far from ideal, but without and
documentation it is hard to know what the right fix is.
MFC candidate
By default syscons(4) will look for the kbdmux(4) keyboard first, and then,
if not found, look for any keyboard.
Current kbd code is modified so if kbdmux(4) is the current keyboard, all
new keyboards are automatically added to the kbdmux(4).
Switch to kbdmux(4) can be done at boot time, by loading kbdmux module at
the loader prompt, or at runtime, by kldload'ing the kbdmux module and
releasing current active keyboard.
If, for whatever reason, kbdmux(4) is not required/desired then just do
not load it and everything should work as before. It is also possible to
kldunload kbdmux at runtime and syscons(4) will automatically switch to
the first available keyboard.
No response from: freebsd-current@
MFC after: 1 day
mpt_soft_reset more than once. And to wait for MPT_DB_STATE_READY
twice. I mean, this is crucial- give the IOC a chance to get
ready.
If mpt_reset is called to reinit things, and we succeed, make
sure to re-enable interrupts. This is what has mostly led to
system lockup after having to hard reset the chip. Also, if
we think that interrupts aren't function in mpt_cam_timeout,
for goodness sake, turn them on again.
In read_cfg_header, return distinguishing errnos so the caller
can decide what's an error. It's *not* an error to fail to
read a RAID page from a non-RAID capable device like the FC929X.
Some whitespace fixes (removing spaces from ends of lines).
Developed with: Norbert Koch < NKoch at demig dot de >
No response from: freebsd-current@
Tested by: Norbert Koch < NKoch at demig dot de >
MFC after: 1 day
not hang the system for 5 seconds. If a TMF doesn't complete within,
oh, say 500ms, that's enough.
Put in a printout to catch mpt_recover_commands being activated with
no commands.
*both* SAS and FC, not just SAS.
b) Don't tell the chip we want it to do FIFO signalling if we actually
don't set up the address where the FIFO signal is supposed to be written
(oops).
is closed and then reopened. This appears to be necessary now that
we no longer clear endpoint stalls every time a pipe is opened.
Previously we could assume an initial toggle value of zero because
the clear-stall operation resets the device's toggle state.
Reported by: Holger Kipp
MFC after: 3 days
(atkbd(4)) and PS/2 mouse (psm(4)) are used together.
Turns out that atkbd(4) check_char() method may return "true" while
read_char() method returns NOKEY. When this happens kbdmux(4) was
simply stuck in the dead loop. Avoid dead loop in kbdmux(4) by breaking
out of the loop if read_char() method returns NOKEY.
It almost seems like a bug in atkkbd(4), atkbd_check_char() calls
kbdc_data_ready(), and, the later will return "true" if there are
pending data in either kbd or aux queue. However, because both aux
and kbd are on the same controller, I'm not sure if this is a bug
or feature.
Tested by: markus
MFC after: 1 day
is finished with it; this may only occur when the tx queue is setup as
dba-gated but since the fix is cheap apply it to all queues
while here make the queue depth signed for use in assertions
Reviewed by: apatti
MFC after: 2 weeks
Return BUS_PROBE_LOW_PRIORITY for a successful probe. This is in
preparation of the introduction of scc(4), which is going to handle
SCCs in the near future.
