History log of /freebsd/sys/dev/sis/if_sis.c (Results 101 – 125 of 126)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: release/7.3.0_cvs, release/7.3.0, release/8.0.0_cvs, release/8.0.0
# 10b3b545 17-Sep-2009 Dag-Erling Smørgrav <des@FreeBSD.org>

Merge from head


# 7d4b968b 17-Sep-2009 Dag-Erling Smørgrav <des@FreeBSD.org>

Merge from head up to r188941 (last revision before the USB stack switch)


# 09c817ba 03-Jul-2009 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

- MFC


# eb956cd0 26-Jun-2009 Robert Watson <rwatson@FreeBSD.org>

Use if_maddr_rlock()/if_maddr_runlock() rather than IF_ADDR_LOCK()/
IF_ADDR_UNLOCK() across network device drivers when accessing the
per-interface multicast address list, if_multiaddrs. This will
a

Use if_maddr_rlock()/if_maddr_runlock() rather than IF_ADDR_LOCK()/
IF_ADDR_UNLOCK() across network device drivers when accessing the
per-interface multicast address list, if_multiaddrs. This will
allow us to change the locking strategy without affecting our driver
programming interface or binary interface.

For two wireless drivers, remove unnecessary locking, since they
don't actually access the multicast address list.

Approved by: re (kib)
MFC after: 6 weeks

show more ...


# 7e857dd1 12-Jun-2009 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

- Merge from HEAD


# 1abcdbd1 30-May-2009 Attilio Rao <attilio@FreeBSD.org>

When user_frac in the polling subsystem is low it is going to busy the
CPU for too long period than necessary. Additively, interfaces are kept
polled (in the tick) even if no more packets are availa

When user_frac in the polling subsystem is low it is going to busy the
CPU for too long period than necessary. Additively, interfaces are kept
polled (in the tick) even if no more packets are available.
In order to avoid such situations a new generic mechanism can be
implemented in proactive way, keeping track of the time spent on any
packet and fragmenting the time for any tick, stopping the processing
as soon as possible.

In order to implement such mechanism, the polling handler needs to
change, returning the number of packets processed.
While the intended logic is not part of this patch, the polling KPI is
broken by this commit, adding an int return value and the new flag
IFCAP_POLLING_NOCOUNT (which will signal that the return value is
meaningless for the installed handler and checking should be skipped).

Bump __FreeBSD_version in order to signal such situation.

Reviewed by: emaste
Sponsored by: Sandvine Incorporated

show more ...


Revision tags: release/7.2.0_cvs, release/7.2.0
# 1829d5da 12-Mar-2009 Warner Losh <imp@FreeBSD.org>

Update the projects tree to a newer FreeBSD current.


# 53414a48 13-Feb-2009 Pyun YongHyeon <yongari@FreeBSD.org>

Receving VLAN oversized frames raise SIS_ISR_RX_ERR interrupt, so
make sis_rxeof() handle that too. Previously it used to receive the
frame and reset controller.

PR: kern/131414


# e436c382 11-Feb-2009 Warner Losh <imp@FreeBSD.org>

Fix shutdown prototypes.


Revision tags: release/7.1.0_cvs, release/7.1.0
# 92483efa 09-Dec-2008 Pyun YongHyeon <yongari@FreeBSD.org>

Fix a long standing VLAN tagged frame handling bug.
When VLAN tagged frame is received the hardware sets 'LONG' bit of
Rx status word. It is always set when the size of received frame
exceeded 1518 b

Fix a long standing VLAN tagged frame handling bug.
When VLAN tagged frame is received the hardware sets 'LONG' bit of
Rx status word. It is always set when the size of received frame
exceeded 1518 bytes, including CRC. This VLAN tagged frame clears
'OK' bit of Rx status word such that driver should not rely on 'OK'
bit of Rx status word to pass the VLAN tagged frame to upper stack.

To fix the bug, don't use SIS_CMDSTS_PKT_OK for Rx error check and
introduce SIS_RXSTAT_ERROR macro that checks Rx errors. If we are
configured to accept VLAN tagged frames and the received frame size
is less than or equal to maximum allowed length of VLAN tagged
frame, clear 'LONG' bit of Rx status word before checking Rx
errors.

Reported by: Vladimir Ermako < samflanker <> gmail DOT com >
Tested by: Vladimir Ermako < samflanker <> gmail DOT com >

show more ...


Revision tags: release/6.4.0_cvs, release/6.4.0
# 31063462 23-Aug-2008 Warner Losh <imp@FreeBSD.org>

There actually were bugs in the original handling that I missed last
night.

Free the children after each pci bus that is searched. Otherwise we
leak them. With free in the new place, we also have

There actually were bugs in the original handling that I missed last
night.

Free the children after each pci bus that is searched. Otherwise we
leak them. With free in the new place, we also have to free children
before going to done when we find the device we're looking for.

Also, if we can't get the children of a device, just ignore that bus.

show more ...


# 83bda63e 23-Aug-2008 Warner Losh <imp@FreeBSD.org>

Actually revert last... Upon closer inspection the code works in the
face of errors already... A bit unorthodox, but none-the-less valid.


# b52943f0 23-Aug-2008 Warner Losh <imp@FreeBSD.org>

Handle errors in device_get_children gracefully.


# d2155f2f 10-Aug-2008 Warner Losh <imp@FreeBSD.org>

Move sis to sys/dev/sis for consistency.


# 09c817ba 03-Jul-2009 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

- MFC


# eb956cd0 26-Jun-2009 Robert Watson <rwatson@FreeBSD.org>

Use if_maddr_rlock()/if_maddr_runlock() rather than IF_ADDR_LOCK()/
IF_ADDR_UNLOCK() across network device drivers when accessing the
per-interface multicast address list, if_multiaddrs. This will
a

Use if_maddr_rlock()/if_maddr_runlock() rather than IF_ADDR_LOCK()/
IF_ADDR_UNLOCK() across network device drivers when accessing the
per-interface multicast address list, if_multiaddrs. This will
allow us to change the locking strategy without affecting our driver
programming interface or binary interface.

For two wireless drivers, remove unnecessary locking, since they
don't actually access the multicast address list.

Approved by: re (kib)
MFC after: 6 weeks

show more ...


# 7e857dd1 12-Jun-2009 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

- Merge from HEAD


# 1abcdbd1 30-May-2009 Attilio Rao <attilio@FreeBSD.org>

When user_frac in the polling subsystem is low it is going to busy the
CPU for too long period than necessary. Additively, interfaces are kept
polled (in the tick) even if no more packets are availa

When user_frac in the polling subsystem is low it is going to busy the
CPU for too long period than necessary. Additively, interfaces are kept
polled (in the tick) even if no more packets are available.
In order to avoid such situations a new generic mechanism can be
implemented in proactive way, keeping track of the time spent on any
packet and fragmenting the time for any tick, stopping the processing
as soon as possible.

In order to implement such mechanism, the polling handler needs to
change, returning the number of packets processed.
While the intended logic is not part of this patch, the polling KPI is
broken by this commit, adding an int return value and the new flag
IFCAP_POLLING_NOCOUNT (which will signal that the return value is
meaningless for the installed handler and checking should be skipped).

Bump __FreeBSD_version in order to signal such situation.

Reviewed by: emaste
Sponsored by: Sandvine Incorporated

show more ...


Revision tags: release/7.2.0_cvs, release/7.2.0
# 1829d5da 12-Mar-2009 Warner Losh <imp@FreeBSD.org>

Update the projects tree to a newer FreeBSD current.


# 53414a48 13-Feb-2009 Pyun YongHyeon <yongari@FreeBSD.org>

Receving VLAN oversized frames raise SIS_ISR_RX_ERR interrupt, so
make sis_rxeof() handle that too. Previously it used to receive the
frame and reset controller.

PR: kern/131414


# e436c382 11-Feb-2009 Warner Losh <imp@FreeBSD.org>

Fix shutdown prototypes.


Revision tags: release/7.1.0_cvs, release/7.1.0
# 92483efa 09-Dec-2008 Pyun YongHyeon <yongari@FreeBSD.org>

Fix a long standing VLAN tagged frame handling bug.
When VLAN tagged frame is received the hardware sets 'LONG' bit of
Rx status word. It is always set when the size of received frame
exceeded 1518 b

Fix a long standing VLAN tagged frame handling bug.
When VLAN tagged frame is received the hardware sets 'LONG' bit of
Rx status word. It is always set when the size of received frame
exceeded 1518 bytes, including CRC. This VLAN tagged frame clears
'OK' bit of Rx status word such that driver should not rely on 'OK'
bit of Rx status word to pass the VLAN tagged frame to upper stack.

To fix the bug, don't use SIS_CMDSTS_PKT_OK for Rx error check and
introduce SIS_RXSTAT_ERROR macro that checks Rx errors. If we are
configured to accept VLAN tagged frames and the received frame size
is less than or equal to maximum allowed length of VLAN tagged
frame, clear 'LONG' bit of Rx status word before checking Rx
errors.

Reported by: Vladimir Ermako < samflanker <> gmail DOT com >
Tested by: Vladimir Ermako < samflanker <> gmail DOT com >

show more ...


Revision tags: release/6.4.0_cvs, release/6.4.0
# 31063462 23-Aug-2008 Warner Losh <imp@FreeBSD.org>

There actually were bugs in the original handling that I missed last
night.

Free the children after each pci bus that is searched. Otherwise we
leak them. With free in the new place, we also have

There actually were bugs in the original handling that I missed last
night.

Free the children after each pci bus that is searched. Otherwise we
leak them. With free in the new place, we also have to free children
before going to done when we find the device we're looking for.

Also, if we can't get the children of a device, just ignore that bus.

show more ...


# 83bda63e 23-Aug-2008 Warner Losh <imp@FreeBSD.org>

Actually revert last... Upon closer inspection the code works in the
face of errors already... A bit unorthodox, but none-the-less valid.


# b52943f0 23-Aug-2008 Warner Losh <imp@FreeBSD.org>

Handle errors in device_get_children gracefully.


123456