Make sure not to requeue freed mbuf in sge_start_locked(). This
should fix NULL pointer dereference panic.
Reported by: Nikolay Denev <ndenev <> gmail dot com>
Submitted by: jhb
hardware tag insertion/stripping. Remove conditional code that
disables these hardware features on SiS190. Also nuke RX fixup code
which is no more required on strict-alignment architectures because
SiS190 supports RX 10 bytes padding.
Now all hardware features except jumbo frame and WOL are supported.
Thanks to Masa Murayama who confirmed SiS190 also has the same
hardware features of SiS191.
I guess the only difference between SiS191 and SiS190 would be
jumbo frame support. It will be implemented in near future.
fragmentation of mbuf chain to 32 from 16 because TSO can send 64KB
sized packet which in turn requires long list of mbuf chain. Due to
lack of documentation, I'm not sure whether driver have to pull up
ethernet/IP/TCP header with options to make controller work but
driver have to parse TCP header to update pseudo TCP checksum
anyway. The controller expects pseudo TCP checksum computed by
upper stack and the checksum should follow the MS NDIS
specification to make TSO work.
Tested by: xclin <xclin <> cs dot nctu dot edu dot tw >
is no more need to defragment mbufs. After transmitting the
multi-fragmented frame, the controller updates only the first
descriptor of multi-descriptor transmission so it's driver's
responsibility to clear OWN bits of remaining descriptor of
multi-descriptor transmission. It seems the controller behaves much
like jme(4) controllers in descriptor handling.
Tested by: xclin <xclin <> cs dot nctu dot edu dot tw >
controller, I'm not sure whether this is also applicable to SiS190
so this feature is only activated on SiS191 controller.
In theory, controller reinitialization is not needed when VLAN tag
configuration is changed, but xclin said controller was not stable
whenever toggling VLAN tag bit. To address that, sge(4)
reinitialize controller for VLAN configuration which seems to work
as expected. VLAN tag information for TX/RX descriptor and
configure bit of RxMacControl register was found by xclin.
Submitted by: xclin <xclin <> cs dot nctu dot edu dot tw > (initial version)
Tested by: xclin <xclin <> cs dot nctu dot edu dot tw >
register. Due to lack of SiS190 controller, I'm not sure whether
this is also applicable to SiS190 so this feature is only activated
on SiS191 controller.
The controller can pad 10 bytes before DMAing a received frame to
RX buffer and received bytes include the padded bytes. This padding
is very useful on strict-alignment architectures because driver
does not have to copy received frame to align IP header on 4 bytes
boundary. It also gives better RX performance on non-strict
alignment architectures. Special thanks to xclin to give me
valuable register information. Without his enthusiastic trial and
errors this wouldn't be even possible.
While I'm here tighten validity check of received frame. Controller
clears RDS_CRCOK bit when it received bad CRC frames. xclin found
that using loop back testing.
Tested by: xclin <xclin <> cs dot nctu dot edu dot tw >
programs RX filter configuration. It seems RX MAC control register
is one of key registers to get various offloading features as well
as performance. Blindly clearing unrelated bits can result in
unexpected results.
Tested by: xclin <xclin <> cs dot nctu dot edu dot tw >
was chosen by lots of trial and errors. The chosen value shows
good interrupt moderation without additional latency.
Without this change, controller can generate more than 140k
interrupts per second under high network load.
Submitted by: xclin <xclin <> cs dot nctu dot edu dot tw >
This driver was written by Alexander Pohoyda and greatly enhanced
by Nikolay Denev. I don't have these hardwares but this driver was
tested by Nikolay Denev and xclin.
Because SiS didn't release data sheet for this controller, programming
information came from Linux driver and OpenSolaris. Unlike other open
source driver for SiS190/191, sge(4) takes full advantage of TX/RX
checksum offloading and does not require additional copy operation in
RX handler.
The controller seems to have advanced offloading features like VLAN
hardware tag insertion/stripping, TCP segmentation offload(TSO) as
well as jumbo frame support but these features are not available
yet. Special thanks to xclin <xclin<> cs dot nctu dot edu dot tw>
who sent fix for receiving VLAN oversized frames.