and voltage sensor, TWSI is used to get sensor data. msk(4) does
not monitor these sensors and interrupt for TWSI completion is
disabled by default.
However, due to unknown reason, the TWSI completion interrupt fires
and it resulted in interrupt storm. To fix it, acknowledges the
TWSI completion interrupt if driver see the event. Given that not
all Yukon II controllers show the issue it could be a silicon bug
which does not honor interrupt masking.
Probably the right way to address the issue is disabling automatic
TWSI cycle initiation against these sensors. It would be even
better to implement reading voltage/temperature from the NIC but it
requires access to National LM80 through TWSI and documentation to
do that is not available yet(probably will never happen).
Reported by: jhb
Tested by: jhb
MFC after: 2 weeks
which will be needed for AR7010 and AR9287 USB access.
The names differ slightly from Linux and Atheros, for the sake of
consistency.
A lot more work is required in order to convert the 11n HAL support to
fully support USB.
header will make the data go over the 64k limits announced to busdma as
maxsize and the transaction will fail.
With TSO this can result in a TCP regression due to the lost packet.
According to the data sheets ixgbe(4) 82598 and 82599 can handle up to
256k so increase the maximum.
Reported by: Jon Kåre Hellan, UNINETT (jon.kare.hellan uninett.no)
Tested by: Jon Kåre Hellan, UNINETT (jon.kare.hellan uninett.no)
MFC after: 1 week
sys/dev/dpt/dpt_scsi.c:612:18: error: implicit truncation from 'int' to bitfield changes value from -2 to 2 [-Werror,-Wconstant-conversion]
dpt->cache_type = DPT_CACHE_WRITEBACK;
^ ~~~~~~~~~~~~~~~~~~~
by defining DPT_CACHE_WRITEBACK as 2, since dpt_softc::cache_type is an
unsigned bitfield. No binary change.
MFC after: 1 week
- When switching to 4-bit operation, send a SET_CLR_CARD_DETECT command
to disconnect the card-detect pull-up resistor from the DAT3 line before
sending the SET_BUS_WIDTH command.
- Add the missing "reserved" zero entry to the mantissa table used to
decode various CSD fields. This was causing SD cards to report that they
could run at 30 MHz instead of the maximum 25 MHz mandated in the spec.
o Enhancements:
- At the MMC layer, format various info from the CID into a string that
uniquely identifies the card instance (manufacturer number, serial
number, product name and revision, etc). Export it as an instance
variable.
- At the MMCSD layer, display the formatted card ID string, and also
report the clock speed of the hardware (not the card's max speed), and
the number of bits and number of blocks per transfer. It comes out like
this now:
mmcsd0: 968MB <SD SD01G 8.0 SN 276886905 MFG 08/2008 by 3 SD> at mmc0
22.5MHz/4bit/128-block
o Use DEVMETHOD_END.
o Use NULL instead of 0 for pointers.
PR: 156496
Submitted by: Ian Lepore
MFC after: 1 week
sys/dev/nxge/if_nxge.c:1276:11: error: case value not in enumerated type 'xge_hal_event_e' (aka 'enum xge_hal_event_e') [-Werror,-Wswitch]
case XGE_LL_EVENT_TRY_XMIT_AGAIN:
^
sys/dev/nxge/if_nxge.c:1289:11: error: case value not in enumerated type 'xge_hal_event_e' (aka 'enum xge_hal_event_e') [-Werror,-Wswitch]
case XGE_LL_EVENT_DEVICE_RESETTING:
^
This is because the switch uses xge_queue_item_t::event_type, which is
an enum xge_hal_event_e, while the XGE_LL_EVENT_xx values are of the
enum xge_event_e.
Since messing around with the enum definitions is too disruptive, the
simplest fix is to cast the argument of the switch to int.
Reviewed by: gnn
MFC after: 1 week
STAILQ(). While here, fix another clang warning about a switch which
tests an enum type for a regular integer value.
Submitted by: jhb
MFC after: 1 week
assumes for small buffers (< 64k) that the OS driver is actually using
a buffer rounded up to the next power of 2. It also assumes that the
buffer is at least 4k in size. Furthermore, there is at least one
known instance of megarc sending a request with a 12k buffer where the
firmware writes out a 24k-ish reply.
To workaround the data corruption triggered by this "feature", ensure
that buffers for user commands use a minimum size of 32k, and that
buffers between 32k and 64k use a 64k buffer.
PR: kern/155658
Submitted by: Andreas Longwitz longwitz incore de
Reviewed by: scottl
MFC after: 1 week
at least until I can root cause what's going on.
The only platform I've seen this on is the AR9220 when attached to
the AR71xx CPUs. I get immediate PCIe bus errors and all subsequent
accesses cause further MIPS bus exceptions. I don't have any other
big-endian platforms to test this on.
If I get a chance (or two), I'll try to whack this on a bus analyser
and see exactly what happens.
I'd rather leave this on, especially for slower, embedded platforms.
But the #ifdef hell is something I'm trying to avoid.
even in the face of errors.
If the RX descriptor list fails, the RX lock won't be initialised, but
then the DMA free path wil try freeing it.
This commit is brought to you by a working mwl(4).
This may result in a bit of a throughput drop. However, any throughput
drop at this point should be investigated and root caused, as it's likely
because TX scheduling (all the way down to how preemption, scheduler work,
etc) is happening in a sub-optimal fashion.
This also makes it much more likely to be reloadable on a live machine.
Allocating 5120 TX ath_buf entries via contigmalloc is very unlikely
after a few hours of using X/Chromium.
dirty and murky past.
* Override the default cache line size to be something reasonable if
it's set to 0. Some NICs initialise with '0' (eg embedded ones)
and there are comments in the driver stating that various OSes (eg
older Linux ones) would incorrectly program things and 0 out this
register.
* Just default to overriding the latency timer. Every other driver
does this.
* Use a default cache line size of 32 bytes. It should be "reasonable
enough".
Obtained from: Linux ath9k, Atheros
a8af6270bd96be6ccd86f70b60fa6512b710e4f0
virtio_blk: Include function name in panic string
cbdb03a694b76c5253d7ae3a59b9995b9afbb67a
virtio_balloon: Do the notify outside of the lock
By the time we return from virtqueue_notify(), the descriptor
will be in the used ring so we shouldn't have to sleep.
10ba392e60692529a5cbc1e9987e4064e0128447
virtio: Use DEVMETHOD_END
80cbcc4d6552cac758be67f0c99c36f23ce62110
virtqueue: Add support for VIRTIO_F_RING_EVENT_IDX
This can be used to reduce the number of guest/host and
host/guest interrupts by delaying the interrupt until a
certain index value is reached.
Actual use by the network driver will come along later.
8fc465969acc0c58477153e4c3530390db436c02
virtqueue: Simplify virtqueue_nused()
Since the values just wrap naturally at UINT16_MAX, we
can just subtract the two values directly, rather than
doing 2's complement math.
a8aa22f25959e2767d006cd621b69050e7ffb0ae
virtio_blk: Remove debugging crud from 75dd732a
There seems to be an issue with Qemu (or FreeBSD VirtIO) that sets
the PCI register space for the device config to bogus values. This
only seems to happen after unloading and reloading the module.
d404800661cb2a9769c033f8a50b2133934501aa
virtio_blk: Use better variable name
75dd732a97743d96e7c63f7ced3c2169696dadd3
virtio_blk: Partially revert 92ba40e65
Just use the virtqueue to determine if any requests are
still inflight.
06661ed66b7a9efaea240f99f414c368f1bbcdc7
virtio_blk: error if allowed too few segments
Should never happen unless the host provides use with a
bogus seg_max value.
4b33e5085bc87a818433d7e664a0a2c8f56a1a89
virtio_blk: Sort function declarations
426b9f5cac892c9c64cc7631966461514f7e08c6
virtio_blk: Cleanup whitespace
617c23e12c61e3c2233d942db713c6b8ff0bd112
virtio_blk: Call disk_err() on error'd completed requests
081a5712d4b2e0abf273be4d26affcf3870263a9
virtio_blk: ASSERT the ready and inflight request queues are empty
a9be2631a4f770a84145c18ee03a3f103bed4ca8
virtio_blk: Simplify check for too many segments
At the cost of a small style violation.
e00ec09da014f2e60cc75542d0ab78898672d521
virtio_blk: Add beginnings of suspend/resume
Still not sure if we need to virtio_stop()/virtio_reinit()
the device before/after a suspend.
Don't start additional IO when marked as suspending.
47c71dc6ce8c238aa59ce8afd4bda5aa294bc884
virtio_blk: Panic when dealt an unhandled BIO cmd
1055544f90fb8c0cc6a2395f5b6104039606aafe
virtio_blk: Add VQ enqueue/dequeue wrappers
Wrapper functions managed the added/removing to the in-flight
list of requests.
Normally biodone() any completed IO when draining the virtqueue.
92ba40e65b3bb5e4acb9300ece711f1ea8f3f7f4
virtio_blk: Add in-flight list of requests
74f6d260e075443544522c0833dc2712dd93f49b
virtio_blk: Rename VTBLK_FLAG_DETACHING to VTBLK_FLAG_DETACH
7aa549050f6fc6551c09c6362ed6b2a0728956ef
virtio_blk: Finish all BIOs through vtblk_finish_bio()
Also properly set bio_resid in the case of errors. Most geom_disk
providers seem to do the same.
9eef6d0e6f7e5dd362f71ba097f2e2e4c3744882
Added function to translate VirtIO status to error code
ef06adc337f31e1129d6d5f26de6d8d1be27bcd2
Reset dumping flag when given unexpected parameters
393b3e390c644193a2e392220dcc6a6c50b212d9
Added missing VTBLK_LOCK() in dump handler
Obtained from: Bryan Venteicher bryanv at daemoninthecloset dot org
Contrarily to what i wrote in my previous commit, the 82599
does include the CRC in the length. The operating mode is
reset in ixgbe_init_locked() and so we need to hook into
the places where the two registers (HLREG0 and RDRXCTL) are
modified.
interface.
* Introduce a device hint, 'eeprom_firmware', which is the name of firmware
to lookup.
* If the lookup succeeds, take a copy of it and use it as the eeprom data.
This isn't enabled by default - you have to define ATH_EEPROM_FIRMWARE.
I'll add it to the configuration variables in a later commit.
TODO:
* just keep a firmware reference in ath_softc, and remove the need to
waste the extra memory in having sc_eepromdata be a malloc()ed block.
used in polled-mode. The callout invokes uart_intr, which rearms the timeout.
Implemented for bhyve, but generically useful for e.g. embedded bringup
when the interrupt controller hasn't been setup, or if it's not deemed
worthy to wire an interrupt line from a serial port.
Submitted by: neel
Reviewed by: marcel
Obtained from: NetApp
MFC after: 3 weeks
does not include the CRC irrespective of the setting
of CRCSTRIP. The 82599 data sheets (sec. 7.1.6) say differently.
Very strange. Need to check what happens on legacy descriptors,
but for the time being this restores functionality.
and make it easier to replace it with a different implementation.
On passing, also fix indentation.
NOTE: I know that #include "foo.c" is ugly, but the alternative
(add another entry to sys/conf/files, add a separate header with
structs and prototypes, and expose functions that are meant to
be private) looks even worse to me.
We need a more modular way to specify dependencies and build options.
portions were already reapplied in r233708:
- Use a dedicated task to handle deferred transmits from the if_transmit
method instead of reusing the existing per-queue interrupt task.
Reusing the per-queue interrupt task could result in both an interrupt
thread and the taskqueue thread trying to handle received packets on a
single queue resulting in out-of-order packet processing.
- Call ether_ifdetach() earlier in igb_detach().
- Drain tasks and free taskqueues during igb_detach().
MFC after: 1 week
- add a sysctl, dev.netmap.ix_crcstrip, to control whether ixgbe should
strip the CRC on received frames. Defaults to 0, which keeps the CRC.
and improves performance when receiving min-sized (64-byte) frames.
This matters because min-sized frames is one of the standard
benchmarks for switches and routers, some chipsets seem to issue
read-modify-write cycles for PCIe transactions that are not a
full cache line, and a min-sized frame triggers the bug, resulting
in reduced throughput -- 9.7 instead of 14.88 Mpps -- and heavy
bus load.
- for the time being, always look for incoming packets on a select/poll
even if there has not been an interrupt in the meantime. This is
only a temporary workaround for a probable race condition in keeping
track of rx interrupts.
Add a couple of diagnostic vars to help studying the problem.
values as in the Intel driver 3.8.21 for linux. The fact that it
is standard in the above driver suggests that it has no bad side
effects.
But of course there must be a reason for enabling features, not
just "it does not harm", so here it is a good one:
Prefetching enables full line rate even using a single queue (14.88
Mpps, compared to ~12 Mpps without prefetch). This in turn is
terribly useful when one wants to schedule traffic.
For obvious reasons the difference is only visible with netmap
or other high speed solutions, but presumably the advantage
should be in the order of a fraction of a microsecond when
starting transmission on an empty queue.
Discussed with Jack Vogel.
MFC after: 1 week
r228476 fixed superfluous link UP/DOWN messages but broke IPMI
access during boot. It's not clear why r228476 breaks IPMI and
should be revisited.
Reported by: Paul Guyot <paulguyot <> ieee dot org >
MFC after: 1 week
identical now that the bus spaces are unified under sys/x86.
Replace them with a single uart_cpu_x86.c.
o delete uart_cpu_i386.c
o move uart_cpu_amd64.c to uart_cpu_x86.c
o update files.amd64 and files.i386 accordingly.
