1.186: onoe; Sony's PEGA-WL110 CF WLAN (which strangely has fujitsu's
vendor id)
1.185: ichiro; Quatech Inc, PCMCIA Enhanced Parallel Port Card
Also:
o update $NetBSD$
o minor tweaks to FUJITSU. We've tried to keep the CIS only entries seprate
from vendor id/product id.
Fix to the messages output under CAM_DEBUG_CCB: the summary sense
information (error bits and sense key) is in the error field, not
in the result field, of struct ata_request. No other functional change.
device to access 64-bit addresses from a 32-bit PCI bus. While the
RealTek manual says you can set this bit and the chip will perform
DAC only if you give it a DMA address with any of the upper 32
bits set, this appears not to be the case. If I turn on the DAC
bit, the chip sets the 'system error' bit in the status register
when I to do a DMA on my Athlon test box with 32-bit PCI bus (VIA
chipset) even though I only have 128MB of physical memory, and thus
can never give the chip a 64-bit address.
Obviously, I can't just set it and forget it, so until I figure
out the right rule for when it's safe/necessary to enable it, keep
it turned off.
Tested at 100Mbit only, using Asus P4P800 onboard 3C940.
The -stable version of this patch I have in use for ~2 weeks now, and works
just fine for me.
Based on: Nathan L. Binkert's patch for OpenBSD
Patch submitted by and thanks to: Jung-uk Kim <jkim@niksun.com>
MFC after: 2 weeks
IF_HANDOFF() does it for us behind the scenes. Remove the extra call
to re_start() otherwise we try to transmit twice.
In re_encap(), fix the code that guards against consuming too many
descriptors in the TX ring so that it actually works. With the
new 8169S chip, I was able to hit a corner case that drained the
free descriptor count all the way to 0. This is not supposed to
be possible.
COM_NOFIFO() and COM_ESP cases are supposed to be a subsets of the
plain 16550A case, but 16650-related changes made the former fall into
the latter and then both fall into general code for printing the tx
fifo size. This mainly caused hard to parse boot messages like:
"sio0: type 16550A fifo disabled lookalike with 1 bytes FIFO".
COM_NOFIFO() on an ESP port gave a larger mess whose extent is not
clear.
Fixed some nearby style bugs.
defined values instead of hard-coded values. Don't repeat the register
access part of the code 4 times times or triple-space statements. This
fixes half of the style bugs in rev.1.172.
Hardware flow control of 16650As is still officially unsupported. I
was mistaken about it being broken. It is broken in 16650s but is
fixed in 16650As except for the maximum trigger level (which is no
longer used). Testing of the 16650's broken hardware flow control
watermarks by programming them on 16950s showed that their effects are
not too bad if the fifo size and trigger level are reasonably large
(16 is much better than 8).
an UART interface could get stuck when a new interrupt condition
arose while servicing a previous interrupt. Since an interrupt was
already pending, no new interrupt would be triggered.
Avoid infinite recursion by flushing the Rx FIFO and marking an
overrun condition when we could not move the data from the Rx
FIFO to the receive buffer in toto. Failure to flush the Rx FIFO
would leave the Rx ready condition pending.
Note that the SAB 82532 already did this due to the nature of the
chip.
precisely where locking would be needed before adding it, but it
seems uart(4) draws slightly too much attention to have it without
locking for too long.
The lock added is a spinlock that protects access to the underlying
hardware. As a first and obvious stab at this, each method of the
hardware interface grabs the lock. Roughly speaking this serializes
the methods. Exceptions are the probe, attach and detach methods.
a problem for command responses since we rarely ever filled the queue.
However, adapter-initiated commands have a much smaller queue and could
tickle this bug. It's possible that this might fix the recently reported
problems with the aac-2120s, though I haven't been able to reproduce the
problem locally.
MFC-After: 1 day
