* Re: [PATCH v2 1/1] TCP: increase default initial receive window.
From: Nandita Dukkipati @ 2010-12-21 0:23 UTC (permalink / raw)
To: David S. Miller, Stephen Hemminger, Rick Jones
Cc: netdev, Tom Herbert, Laurent Chavey, Yuchung Cheng,
Nandita Dukkipati
In-Reply-To: <1292890556-29904-1-git-send-email-nanditad@google.com>
As per the comments, I have resubmitted the patch with a longer
explanation. Please let me know if the preference is to have a sysctl
for the initial default receive window, as I am ok either way.
Thanks,
-Nandita
On Mon, Dec 20, 2010 at 4:15 PM, Nandita Dukkipati <nanditad@google.com> wrote:
> This patch changes the default initial receive window to 10 mss
> (defined constant). The default window is limited to the maximum
> of 10*1460 and 2*mss (when mss > 1460).
>
> draft-ietf-tcpm-initcwnd-00 is a proposal to the IETF that recommends
> increasing TCP's initial congestion window to 10 mss or about 15KB.
> Leading up to this proposal were several large-scale live Internet
> experiments with an initial congestion window of 10 mss (IW10), where
> we showed that the average latency of HTTP responses improved by
> approximately 10%. This was accompanied by a slight increase in
> retransmission rate (0.5%), most of which is coming from applications
> opening multiple simultaneous connections. To understand the extreme
> worst case scenarios, and fairness issues (IW10 versus IW3), we further
> conducted controlled testbed experiments. We came away finding minimal
> negative impact even under low link bandwidths (dial-ups) and small
> buffers. These results are extremely encouraging to adopting IW10.
>
> However, an initial congestion window of 10 mss is useless unless a TCP
> receiver advertises an initial receive window of at least 10 mss.
> Fortunately, in the large-scale Internet experiments we found that most
> widely used operating systems advertised large initial receive windows
> of 64KB, allowing us to experiment with a wide range of initial
> congestion windows. Linux systems were among the few exceptions that
> advertised a small receive window of 6KB. The purpose of this patch is
> to fix this shortcoming.
>
> References:
> 1. A comprehensive list of all IW10 references to date.
> http://code.google.com/speed/protocols/tcpm-IW10.html
>
> 2. Paper describing results from large-scale Internet experiments with IW10.
> http://ccr.sigcomm.org/drupal/?q=node/621
>
> 3. Controlled testbed experiments under worst case scenarios and a
> fairness study.
> http://www.ietf.org/proceedings/79/slides/tcpm-0.pdf
>
> 4. Raw test data from testbed experiments (Linux senders/receivers)
> with initial congestion and receive windows of both 10 mss.
> http://research.csc.ncsu.edu/netsrv/?q=content/iw10
>
> 5. Internet-Draft. Increasing TCP's Initial Window.
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/
>
> Signed-off-by: Nandita Dukkipati <nanditad@google.com>
> ---
> Changelog since v1:
> - A longer and better commit message.
>
> include/net/tcp.h | 3 +++
> net/ipv4/tcp_output.c | 11 ++++++++---
> 2 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index b448030..38509f0 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -60,6 +60,9 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
> */
> #define MAX_TCP_WINDOW 32767U
>
> +/* Offer an initial receive window of 10 mss. */
> +#define TCP_DEFAULT_INIT_RCVWND 10
> +
> /* Minimal accepted MSS. It is (60+60+8) - (20+20). */
> #define TCP_MIN_MSS 88U
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 2d39066..dc7c096 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -228,10 +228,15 @@ void tcp_select_initial_window(int __space, __u32 mss,
> }
> }
>
> - /* Set initial window to value enough for senders, following RFC5681. */
> + /* Set initial window to a value enough for senders starting with
> + * initial congestion window of TCP_DEFAULT_INIT_RCVWND. Place
> + * a limit on the initial window when mss is larger than 1460.
> + */
> if (mss > (1 << *rcv_wscale)) {
> - int init_cwnd = rfc3390_bytes_to_packets(mss);
> -
> + int init_cwnd = TCP_DEFAULT_INIT_RCVWND;
> + if (mss > 1460)
> + init_cwnd =
> + max_t(u32, (1460 * TCP_DEFAULT_INIT_RCVWND) / mss, 2);
> /* when initializing use the value from init_rcv_wnd
> * rather than the default from above
> */
> --
> 1.7.3.1
>
>
^ permalink raw reply
* Re: e1000e crash with 82574L 2.6.37-0.rc5
From: Brian Neu @ 2010-12-21 1:20 UTC (permalink / raw)
To: Wyborny, Carolyn, netdev@vger.kernel.org
Cc: e1000-devel@lists.sourceforge.net
In-Reply-To: <EDC0E76513226749BFBC9C3FB031318F01238645EB@orsmsx508.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]
> Hello,
Thanks for responding. I really wasn't sure where to report this.
> We have some known issues with 82574L but most have been resolved in the
>latest versions, so I'll need some more information.
>
> What version of e1000e are you using exactly? Are you able to download and
>test the latest version of the driver from SourceForge?
This is the fedora build of kernel 2.6.37.0.rc5 which I downloaded from
koji.fedoraproject.org. I'm not sure which version of e1000e is included, but
if I need to build a new module, just let me know.
I had opened a bugzilla report with redhat which also has more backtraces:
https://bugzilla.redhat.com/show_bug.cgi?id=625776
> Please open an issue at SourceForge.net for easier tracking of debugging
>information.
>
> Please provide an output of lspci -vvv.
Attached.
> What hw platform is this happening on?
It's a Supermicro MB for AMD Socket G34
> How often does it happen and how long does it take to happen after reset or
>reboot?
It usually doesn't happen unless the system has been running for hours or days.
>Is ASPM enabled or disabled on your system. Its possible to disable this in
>the BIOS, but not all BIOS provide the option. If its enabled for some reason,
>please disable it and try the driver again.
I'm going to check on this very soon and reply to the e1000 list only.
[-- Attachment #2: lspci.txt --]
[-- Type: text/plain, Size: 37550 bytes --]
00:00.0 Host bridge: ATI Technologies Inc RD890 PCI to PCI bridge (external gfx0 port A) (rev 02)
Subsystem: Super Micro Computer Inc Device a711
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Capabilities: [f0] HyperTransport: MSI Mapping Enable+ Fixed+
Capabilities: [c4] HyperTransport: Slave or Primary Interface
Command: BaseUnitID=0 UnitCnt=20 MastHost- DefDir- DUL-
Link Control 0: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
Link Config 0: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit DwFcInEn- LWO=16bit DwFcOutEn-
Link Control 1: CFlE- CST- CFE- <LkFail+ Init- EOC+ TXO+ <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
Link Config 1: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=8bit DwFcInEn- LWO=8bit DwFcOutEn-
Revision ID: 3.00
Link Frequency 0: [e]
Link Error 0: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability 0: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA+ UIDRD-
Link Frequency 1: 200MHz
Link Error 1: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability 1: 200MHz- 300MHz- 400MHz- 500MHz- 600MHz- 800MHz- 1.0GHz- 1.2GHz- 1.4GHz- 1.6GHz- Vend-
Error Handling: PFlE- OFlE- PFE- OFE- EOCFE- RFE- CRCFE- SERRFE- CF- RE- PNFE- ONFE- EOCNFE- RNFE- CRCNFE- SERRNFE-
Prefetchable memory behind bridge Upper: 00-00
Bus Number: 00
Capabilities: [40] HyperTransport: Retry Mode
Capabilities: [54] HyperTransport: UnitID Clumping
Capabilities: [9c] HyperTransport: #1a
Capabilities: [70] MSI: Enable- Count=1/4 Maskable- 64bit-
Address: 00000000 Data: 0000
00:04.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port D) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
I/O behind bridge: 0000e000-0000efff
Memory behind bridge: feb00000-febfffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag+ RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x4, ASPM L0s L1, Latency L0 <1us, L1 <8us
ClockPM- Surprise- LLActRep+ BwNot+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #4, PowerLimit 75.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet+ LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ ARIFwd+
DevCtl2: Completion Timeout: 65ms to 210ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee10000 Data: 4051
Capabilities: [b0] Subsystem: Super Micro Computer Inc Device a711
Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+
Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
Capabilities: [190 v1] Access Control Services
ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl- DirectTrans+
ACSCtl: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-
Kernel driver in use: pcieport
Kernel modules: shpchp
00:09.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port H) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: fea00000-feafffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag+ RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #1, Speed 5GT/s, Width x2, ASPM L0s L1, Latency L0 <1us, L1 <8us
ClockPM- Surprise- LLActRep+ BwNot+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #9, PowerLimit 75.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet+ LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ ARIFwd+
DevCtl2: Completion Timeout: 65ms to 210ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -3.5dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee10000 Data: 4059
Capabilities: [b0] Subsystem: Super Micro Computer Inc Device a711
Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+
Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
Capabilities: [190 v1] Access Control Services
ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl- DirectTrans+
ACSCtl: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-
Kernel driver in use: pcieport
Kernel modules: shpchp
00:0a.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (external gfx1 port A) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: fe900000-fe9fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag+ RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #2, Speed 5GT/s, Width x2, ASPM L0s L1, Latency L0 <1us, L1 <8us
ClockPM- Surprise- LLActRep+ BwNot+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #10, PowerLimit 75.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet+ LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ ARIFwd+
DevCtl2: Completion Timeout: 65ms to 210ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -3.5dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee10000 Data: 4061
Capabilities: [b0] Subsystem: Super Micro Computer Inc Device a711
Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+
Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
Capabilities: [190 v1] Access Control Services
ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl- DirectTrans+
ACSCtl: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-
Kernel driver in use: pcieport
Kernel modules: shpchp
00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controller [IDE mode] (prog-if 01 [AHCI 1.0])
Subsystem: Super Micro Computer Inc Device a711
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 22
Region 0: I/O ports at a000 [size=8]
Region 1: I/O ports at 9000 [size=4]
Region 2: I/O ports at 8000 [size=8]
Region 3: I/O ports at 7000 [size=4]
Region 4: I/O ports at 6000 [size=16]
Region 5: Memory at fe8fa400 (32-bit, non-prefetchable) [size=1K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [70] SATA HBA v1.0 InCfgSpace
Kernel driver in use: ahci
00:12.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller (prog-if 10 [OHCI])
Subsystem: Super Micro Computer Inc Device a711
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fe8f6000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd
00:12.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller (prog-if 10 [OHCI])
Subsystem: Super Micro Computer Inc Device a711
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fe8f7000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd
00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller (prog-if 20 [EHCI])
Subsystem: Super Micro Computer Inc Device a711
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 17
Region 0: Memory at fe8fa800 (32-bit, non-prefetchable) [size=256]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Bridge: PM- B3+
Capabilities: [e4] Debug port: BAR=1 offset=00e0
Kernel driver in use: ehci_hcd
00:13.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller (prog-if 10 [OHCI])
Subsystem: Super Micro Computer Inc Device a711
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fe8f8000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd
00:13.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller (prog-if 10 [OHCI])
Subsystem: Super Micro Computer Inc Device a711
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fe8f9000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd
00:13.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller (prog-if 20 [EHCI])
Subsystem: ATI Technologies Inc SB700/SB800 USB EHCI Controller
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin B routed to IRQ 19
Region 0: Memory at fe8fac00 (32-bit, non-prefetchable) [size=256]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME-
Bridge: PM- B3+
Capabilities: [e4] Debug port: BAR=1 offset=00e0
Kernel driver in use: ehci_hcd
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 3d)
Subsystem: Super Micro Computer Inc Device a711
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Capabilities: [b0] HyperTransport: MSI Mapping Enable- Fixed+
Kernel driver in use: piix4_smbus
Kernel modules: i2c-piix4
00:14.1 IDE interface: ATI Technologies Inc SB700/SB800 IDE Controller (prog-if 8a [Master SecP PriP])
Subsystem: Super Micro Computer Inc Device a711
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at 01f0 [size=8]
Region 1: I/O ports at 03f4 [size=1]
Region 2: I/O ports at 0170 [size=8]
Region 3: I/O ports at 0374 [size=1]
Region 4: I/O ports at ff00 [size=16]
Capabilities: [70] MSI: Enable- Count=1/2 Maskable- 64bit-
Address: 00000000 Data: 0000
Kernel driver in use: pata_atiixp
Kernel modules: ata_generic, pata_acpi, pata_atiixp
00:14.3 ISA bridge: ATI Technologies Inc SB700/SB800 LPC host controller
Subsystem: Super Micro Computer Inc Device a711
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge (prog-if 01 [Subtractive decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: 0000b000-0000bfff
Memory behind bridge: fdf00000-fe7fffff
Prefetchable memory behind bridge: fc000000-fcffffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
00:14.5 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI2 Controller (prog-if 10 [OHCI])
Subsystem: ATI Technologies Inc Device 4396
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin C routed to IRQ 18
Region 0: Memory at fe8fb000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd
00:18.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Capabilities: [80] HyperTransport: Host or Secondary Interface
Command: WarmRst+ DblEnd- DevNum=0 ChainSide- HostHide+ Slave- <EOCErr- DUL-
Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0 IsocEn- LSEn+ ExtCTL- 64b-
Link Config: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit DwFcInEn- LWO=16bit DwFcOutEn-
Revision ID: 3.00
Link Frequency: [e]
Link Error: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA+ UIDRD- ExtRS- UCnfE-
Capabilities: [a0] HyperTransport: Host or Secondary Interface
Command: WarmRst+ DblEnd- DevNum=0 ChainSide- HostHide+ Slave- <EOCErr- DUL-
Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0 IsocEn- LSEn+ ExtCTL- 64b-
Link Config: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit DwFcInEn- LWO=16bit DwFcOutEn-
Revision ID: 3.00
Link Frequency: 500MHz
Link Error: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA+ UIDRD- ExtRS- UCnfE-
Capabilities: [c0] HyperTransport: Host or Secondary Interface
Command: WarmRst+ DblEnd- DevNum=0 ChainSide- HostHide+ Slave- <EOCErr- DUL-
Link Control: CFlE- CST- CFE- <LkFail- Init- EOC+ TXO+ <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
Link Config: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=N/C DwFcInEn- LWO=N/C DwFcOutEn-
Revision ID: 3.00
Link Frequency: 200MHz
Link Error: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA+ UIDRD- ExtRS- UCnfE-
Capabilities: [e0] HyperTransport: Host or Secondary Interface
Command: WarmRst+ DblEnd- DevNum=0 ChainSide- HostHide+ Slave- <EOCErr- DUL-
Link Control: CFlE- CST- CFE- <LkFail- Init- EOC+ TXO+ <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
Link Config: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=N/C DwFcInEn- LWO=N/C DwFcOutEn-
Revision ID: 3.00
Link Frequency: 200MHz
Link Error: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA+ UIDRD- ExtRS- UCnfE-
00:18.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:18.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Kernel driver in use: amd64_edac
Kernel modules: amd64_edac_mod
00:18.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Capabilities: [f0] Secure device <?>
Kernel driver in use: k10temp
Kernel modules: k10temp
00:18.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Capabilities: [c0] HyperTransport: Host or Secondary Interface
Command: WarmRst+ DblEnd- DevNum=0 ChainSide- HostHide+ Slave- <EOCErr- DUL-
Link Control: CFlE- CST- CFE- <LkFail- Init- EOC+ TXO+ <CRCErr=0 IsocEn- LSEn+ ExtCTL- 64b-
Link Config: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=8bit DwFcInEn- LWO=8bit DwFcOutEn-
Revision ID: 3.00
Link Frequency: 200MHz
Link Error: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA+ UIDRD- ExtRS- UCnfE-
Capabilities: [e0] HyperTransport: Host or Secondary Interface
Command: WarmRst+ DblEnd- DevNum=0 ChainSide- HostHide+ Slave- <EOCErr- DUL-
Link Control: CFlE- CST- CFE- <LkFail- Init- EOC+ TXO+ <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
Link Config: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=N/C DwFcInEn- LWO=N/C DwFcOutEn-
Revision ID: 3.00
Link Frequency: 200MHz
Link Error: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA+ UIDRD- ExtRS- UCnfE-
00:19.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Capabilities: [80] HyperTransport: Host or Secondary Interface
Command: WarmRst+ DblEnd- DevNum=0 ChainSide- HostHide+ Slave- <EOCErr- DUL-
Link Control: CFlE- CST- CFE- <LkFail- Init- EOC+ TXO+ <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
Link Config: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=N/C DwFcInEn- LWO=N/C DwFcOutEn-
Revision ID: 3.00
Link Frequency: 200MHz
Link Error: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA+ UIDRD- ExtRS- UCnfE-
Capabilities: [a0] HyperTransport: Host or Secondary Interface
Command: WarmRst+ DblEnd- DevNum=0 ChainSide- HostHide+ Slave- <EOCErr- DUL-
Link Control: CFlE- CST- CFE- <LkFail- Init- EOC+ TXO+ <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
Link Config: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=N/C DwFcInEn- LWO=N/C DwFcOutEn-
Revision ID: 3.00
Link Frequency: 200MHz
Link Error: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA+ UIDRD- ExtRS- UCnfE-
Capabilities: [c0] HyperTransport: Host or Secondary Interface
Command: WarmRst+ DblEnd- DevNum=0 ChainSide- HostHide+ Slave- <EOCErr- DUL-
Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0 IsocEn- LSEn+ ExtCTL- 64b-
Link Config: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit DwFcInEn- LWO=16bit DwFcOutEn-
Revision ID: 3.00
Link Frequency: 500MHz
Link Error: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA+ UIDRD- ExtRS- UCnfE-
00:19.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:19.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Kernel driver in use: amd64_edac
Kernel modules: amd64_edac_mod
00:19.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Capabilities: [f0] Secure device <?>
Kernel driver in use: k10temp
Kernel modules: k10temp
00:19.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Capabilities: [80] HyperTransport: Host or Secondary Interface
Command: WarmRst+ DblEnd- DevNum=0 ChainSide- HostHide+ Slave- <EOCErr- DUL-
Link Control: CFlE- CST- CFE- <LkFail- Init- EOC+ TXO+ <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
Link Config: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=N/C DwFcInEn- LWO=N/C DwFcOutEn-
Revision ID: 3.00
Link Frequency: 200MHz
Link Error: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA+ UIDRD- ExtRS- UCnfE-
Capabilities: [a0] HyperTransport: Host or Secondary Interface
Command: WarmRst+ DblEnd- DevNum=0 ChainSide- HostHide+ Slave- <EOCErr- DUL-
Link Control: CFlE- CST- CFE- <LkFail- Init- EOC+ TXO+ <CRCErr=0 IsocEn- LSEn+ ExtCTL- 64b-
Link Config: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=8bit DwFcInEn- LWO=8bit DwFcOutEn-
Revision ID: 3.00
Link Frequency: 200MHz
Link Error: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz+ 1.4GHz- 1.6GHz- Vend-
Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA+ UIDRD- ExtRS- UCnfE-
01:02.0 Mass storage controller: Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02)
Subsystem: Promise Technology, Inc. PDC40718 (SATA 300 TX4)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 72 (1000ns min, 4500ns max), Cache Line Size: 4 bytes
Interrupt: pin A routed to IRQ 22
Region 0: I/O ports at b400 [size=128]
Region 2: I/O ports at b800 [size=256]
Region 3: Memory at fdfaf000 (32-bit, non-prefetchable) [size=4K]
Region 4: Memory at fdfc0000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at fdfb0000 [disabled] [size=32K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: sata_promise
Kernel modules: sata_promise
01:04.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200eW WPCM450 (rev 0a) (prog-if 00 [VGA controller])
Subsystem: Super Micro Computer Inc Device a711
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (4000ns min, 8000ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 10
Region 0: Memory at fc000000 (32-bit, prefetchable) [size=16M]
Region 1: Memory at fdffc000 (32-bit, non-prefetchable) [size=16K]
Region 2: Memory at fe000000 (32-bit, non-prefetchable) [size=8M]
Expansion ROM at <unassigned> [disabled]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
Subsystem: Super Micro Computer Inc Device a711
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fe9e0000 (32-bit, non-prefetchable) [size=128K]
Region 2: I/O ports at c800 [size=32]
Region 3: Memory at fe9dc000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [e0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #2, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <64us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
Vector table: BAR=3 offset=00000000
PBA: BAR=3 offset=00002000
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr+ BadTLP+ BadDLLP+ Rollover- Timeout+ NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number 00-30-48-ff-ff-f5-02-82
Kernel driver in use: e1000e
Kernel modules: e1000e
03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
Subsystem: Super Micro Computer Inc Device a711
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory at feae0000 (32-bit, non-prefetchable) [size=128K]
Region 2: I/O ports at d800 [size=32]
Region 3: Memory at feadc000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [e0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <64us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
Vector table: BAR=3 offset=00000000
PBA: BAR=3 offset=00002000
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr+ BadTLP+ BadDLLP+ Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 14, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number 00-30-48-ff-ff-f5-02-83
Kernel driver in use: e1000e
Kernel modules: e1000e
04:00.0 RAID bus controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01)
Subsystem: Silicon Image, Inc. Device 7132
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at feb7bc00 (64-bit, non-prefetchable) [size=128]
Region 2: Memory at feb7c000 (64-bit, non-prefetchable) [size=16K]
Region 4: I/O ports at e800 [size=128]
Expansion ROM at feb80000 [disabled] [size=512K]
Capabilities: [54] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [5c] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v1) Legacy Endpoint, MSI 00
DevCap: MaxPayload 1024 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Kernel driver in use: sata_sil24
Kernel modules: sata_sil24
^ permalink raw reply
* Re: [PATCH net-2.6 2/3] bonding: Change active slave quietly when bond is down
From: Flavio Leitner @ 2010-12-21 2:46 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, Jay Vosburgh, netdev, linux-net-drivers
In-Reply-To: <1292264396.9860.14.camel@bwh-desktop>
On Mon, Dec 13, 2010 at 06:19:56PM +0000, Ben Hutchings wrote:
> bond_change_active_slave() may be called when a slave is added, even
> if the bond has not been brought up yet. It may then attempt to send
> packets, and further it may use mcast_work which is uninitialised
> before the bond is brought up. Add the necessary checks for
> netif_running(bond->dev).
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> drivers/net/bonding/bond_main.c | 15 +++++++++------
> 1 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index ef370c9..3b16c34 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -1178,11 +1178,13 @@ void bond_change_active_slave(struct bonding *bond, struct slave *new_active)
> bond_do_fail_over_mac(bond, new_active,
> old_active);
>
> - bond->send_grat_arp = bond->params.num_grat_arp;
> - bond_send_gratuitous_arp(bond);
> + if (netif_running(bond->dev)) {
> + bond->send_grat_arp = bond->params.num_grat_arp;
> + bond_send_gratuitous_arp(bond);
>
> - bond->send_unsol_na = bond->params.num_unsol_na;
> - bond_send_unsolicited_na(bond);
> + bond->send_unsol_na = bond->params.num_unsol_na;
> + bond_send_unsolicited_na(bond);
> + }
>
> write_unlock_bh(&bond->curr_slave_lock);
> read_unlock(&bond->lock);
> @@ -1196,8 +1198,9 @@ void bond_change_active_slave(struct bonding *bond, struct slave *new_active)
>
> /* resend IGMP joins since active slave has changed or
> * all were sent on curr_active_slave */
> - if ((USES_PRIMARY(bond->params.mode) && new_active) ||
> - bond->params.mode == BOND_MODE_ROUNDROBIN) {
> + if (((USES_PRIMARY(bond->params.mode) && new_active) ||
> + bond->params.mode == BOND_MODE_ROUNDROBIN) &&
> + netif_running(bond->dev)) {
> bond->igmp_retrans = bond->params.resend_igmp;
> queue_delayed_work(bond->wq, &bond->mcast_work, 0);
> }
> --
> 1.7.3.2
I had a script randomly adding/removing slaves and setting
the bonding device up and down to test that commit, so
I'm surprised that it didn't catch this combination before.
Acked-by: Flavio Leitner <fleitner@redhat.com>
Thanks,
--
Flavio
^ permalink raw reply
* Re: [PATCH net-2.6] net_sched: always clone skbs
From: David Miller @ 2010-12-21 3:55 UTC (permalink / raw)
To: xiaosuo; +Cc: eric.dumazet, jarkao2, netdev, hadi, pstaszewski
In-Reply-To: <AANLkTi=uhQ8R4i+ZqjBZuFb6pduHzDEZT5_o4VA7jhgC@mail.gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Tue, 21 Dec 2010 08:21:41 +0800
> Oops. It is all my fault. Sorry. What can I do to fix this after David
> has applied it and pushed it out?
Don't worry about it, mistakes happen.
^ permalink raw reply
* [PATCH] ppp: allow disabling multilink protocol ID compression
From: Stephen Hemminger @ 2010-12-21 3:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-ppp, netdev
Linux would not connect to other router running old version Cisco IOS (12.0).
This is most likely a bug in that version of IOS, since it is fixed
in later versions. As a workaround this patch allows a module parameter
to be set to disable compressing the protocol ID.
See: https://bugzilla.vyatta.com/show_bug.cgi?id=3979
RFC 1990 allows an implementation to formulate MP fragments as if protocol
compression had been negotiated. This allows us to always send compressed
protocol IDs. But some implementations don't accept MP fragments with
compressed protocol IDs. This parameter allows us to interoperate with
them. The default value of the configurable parameter is the same as the
current behavior: protocol compression is enabled. If protocol compression
is disabled we will not send compressed protocol IDs.
This is based on an earlier patch by Bob Gilligan (using a sysctl).
Module parameter is writable to allow for enabling even if ppp
is already loaded for other uses.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/ppp_generic.c 2010-12-17 10:01:42.004531762 -0800
+++ b/drivers/net/ppp_generic.c 2010-12-20 18:58:16.677310954 -0800
@@ -1283,6 +1283,11 @@ ppp_push(struct ppp *ppp)
}
#ifdef CONFIG_PPP_MULTILINK
+static bool mp_protocol_compress __read_mostly = true;
+module_param(mp_protocol_compress, bool, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(mp_protocol_compress,
+ "compress protocol id in multilink fragments");
+
/*
* Divide a packet to be transmitted into fragments and
* send them out the individual links.
@@ -1345,10 +1350,10 @@ static int ppp_mp_explode(struct ppp *pp
if (nfree == 0 || nfree < navail / 2)
return 0; /* can't take now, leave it in xmit_pending */
- /* Do protocol field compression (XXX this should be optional) */
+ /* Do protocol field compression */
p = skb->data;
len = skb->len;
- if (*p == 0) {
+ if (*p == 0 && mp_protocol_compress) {
++p;
--len;
}
^ permalink raw reply
* RE: [PATCH net-next-2.6 v2 1/1] can: c_can: Added support for Bosch C_CAN controller
From: Bhupesh SHARMA @ 2010-12-21 4:48 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Marc Kleine-Budde
In-Reply-To: <4D0FBEF6.8020207-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Hi Wolfgang,
> Hi Bhupesh,
>
> On 12/20/2010 05:29 AM, Bhupesh SHARMA wrote:
> > Hi Wolfgang,
> >
> > Thanks for the review.
> > Please see my replies in-line:
> >
> >> here comes my first quick preview.
> >> On 12/15/2010 10:58 AM, Bhupesh Sharma wrote:
> >>> Bosch C_CAN controller is a full-CAN implementation which is
> >> compliant
> >>> to CAN protocol version 2.0 part A and B. Bosch C_CAN user manual
> can
> >> be
> >>> obtained from:
> >>> http://www.semiconductors.bosch.de/pdf/Users_Manual_C_CAN.pdf
> >>>
> >>> This patch adds the support for this controller.
> >>> The following are the design choices made while writing the
> >> controller driver:
> >>> 1. Interface Register set IF1 has be used only in the current
> design.
> >>> 2. Out of the 32 Message objects available, 16 are kept aside for
> RX
> >> purposes
> >>> and the rest for TX purposes.
> >>> 3. NAPI implementation is such that both the TX and RX paths
> function
> >> in
> >>> polling mode.
> >>>
> >>> Changes since V1:
> >>> 1. Implemented C_CAN as a platform driver with means of providing
> the
> >>> platform details and register offsets which may vary for
> different
> >> SoCs
> >>> through platform data struct.
> >>> 2. Implemented NAPI.
> >>> 3. Removed memcpy calls globally.
> >>> 4. Implemented CAN_CTRLMODE_*
> >>> 5. Implemented and used priv->can.do_get_berr_counter.
> >>> 6. Implemented c_can registers as a struct instead of enum.
> >>> 7. Improved the TX path by implementing routines to get next Tx and
> >> echo msg
> >>> objects.
> >>>
> >>> Signed-off-by: Bhupesh Sharma <bhupesh.sharma-qxv4g6HH51o@public.gmane.org>
> >>> ---
> >>> drivers/net/can/Kconfig | 7 +
> >>> drivers/net/can/Makefile | 1 +
> >>> drivers/net/can/c_can.c | 1217
> >> ++++++++++++++++++++++++++++++++++++++++++++++
> >>> 3 files changed, 1225 insertions(+), 0 deletions(-)
> >>> create mode 100644 drivers/net/can/c_can.c
> >>>
> >>> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> >>> index 9d9e453..25d9d2e 100644
> >>> --- a/drivers/net/can/Kconfig
> >>> +++ b/drivers/net/can/Kconfig
> >>> @@ -41,6 +41,13 @@ config CAN_AT91
> >>> ---help---
> >>> This is a driver for the SoC CAN controller in Atmel's
> >> AT91SAM9263.
> >>>
> >>> +config CAN_C_CAN
> >>> + tristate "Bosch C_CAN controller"
> >>> + depends on CAN_DEV
> >>> + ---help---
> >>> + If you say yes to this option, support will be included for
> the
> >>> + Bosch C_CAN controller.
> >>> +
> >>> config CAN_TI_HECC
> >>> depends on CAN_DEV && ARCH_OMAP3
> >>> tristate "TI High End CAN Controller"
> >>> diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
> >>> index 0057537..b6cbe74 100644
> >>> --- a/drivers/net/can/Makefile
> >>> +++ b/drivers/net/can/Makefile
> >>> @@ -12,6 +12,7 @@ obj-y += usb/
> >>> obj-$(CONFIG_CAN_SJA1000) += sja1000/
> >>> obj-$(CONFIG_CAN_MSCAN) += mscan/
> >>> obj-$(CONFIG_CAN_AT91) += at91_can.o
> >>> +obj-$(CONFIG_CAN_C_CAN) += c_can.o
> >>> obj-$(CONFIG_CAN_TI_HECC) += ti_hecc.o
> >>> obj-$(CONFIG_CAN_MCP251X) += mcp251x.o
> >>> obj-$(CONFIG_CAN_BFIN) += bfin_can.o
> >>> diff --git a/drivers/net/can/c_can.c b/drivers/net/can/c_can.c
> >>> new file mode 100644
> >>> index 0000000..c281c17
> >>> --- /dev/null
> >>> +++ b/drivers/net/can/c_can.c
> >>> @@ -0,0 +1,1217 @@
> >>> +/*
> >>> + * CAN bus driver for Bosch C_CAN controller
> >>> + *
> >>> + * Copyright (C) 2010 ST Microelectronics
> >>> + * Bhupesh Sharma <bhupesh.sharma-qxv4g6HH51o@public.gmane.org>
> >>> + *
> >>> + * Borrowed heavily from the C_CAN driver originally written by:
> >>> + * Copyright (C) 2007
> >>> + * - Sascha Hauer, Marc Kleine-Budde, Pengutronix
> >> <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >>> + * - Simon Kallweit, intefo AG <simon.kallweit-+G9qxTFKJT/tRgLqZ5aouw@public.gmane.org>
> >>> + *
> >>> + * Bosch C_CAN controller is compliant to CAN protocol version 2.0
> >> part A and B.
> >>> + * Bosch C_CAN user manual can be obtained from:
> >>> + * http://www.semiconductors.bosch.de/pdf/Users_Manual_C_CAN.pdf
> >>> + *
> >>> + * This file is licensed under the terms of the GNU General Public
> >>> + * License version 2. This program is licensed "as is" without any
> >>> + * warranty of any kind, whether express or implied.
> >>> + */
> >>> +
> >>> +#include <linux/kernel.h>
> >>> +#include <linux/version.h>
> >>> +#include <linux/module.h>
> >>> +#include <linux/interrupt.h>
> >>> +#include <linux/delay.h>
> >>> +#include <linux/netdevice.h>
> >>> +#include <linux/if_arp.h>
> >>> +#include <linux/if_ether.h>
> >>> +#include <linux/list.h>
> >>> +#include <linux/delay.h>
> >>> +#include <linux/workqueue.h>
> >>> +#include <linux/io.h>
> >>> +#include <linux/platform_device.h>
> >>> +#include <linux/clk.h>
> >>> +
> >>> +#include <linux/can.h>
> >>> +#include <linux/can/dev.h>
> >>> +#include <linux/can/error.h>
> >>> +
> >>> +#define DRV_NAME "c_can"
> >>> +
> >>> +/* control register */
> >>> +#define CONTROL_TEST (1 << 7)
> >>> +#define CONTROL_CCE (1 << 6)
> >>> +#define CONTROL_DISABLE_AR (1 << 5)
> >>> +#define CONTROL_ENABLE_AR (0 << 5)
> >>> +#define CONTROL_EIE (1 << 3)
> >>> +#define CONTROL_SIE (1 << 2)
> >>> +#define CONTROL_IE (1 << 1)
> >>> +#define CONTROL_INIT (1 << 0)
> >>> +
> >>> +/* test register */
> >>> +#define TEST_RX (1 << 7)
> >>> +#define TEST_TX1 (1 << 6)
> >>> +#define TEST_TX2 (1 << 5)
> >>> +#define TEST_LBACK (1 << 4)
> >>> +#define TEST_SILENT (1 << 3)
> >>> +#define TEST_BASIC (1 << 2)
> >>> +
> >>> +/* status register */
> >>> +#define STATUS_BOFF (1 << 7)
> >>> +#define STATUS_EWARN (1 << 6)
> >>> +#define STATUS_EPASS (1 << 5)
> >>> +#define STATUS_RXOK (1 << 4)
> >>> +#define STATUS_TXOK (1 << 3)
> >>> +#define STATUS_LEC_MASK 0x07
> >>> +#define LEC_STUFF_ERROR 1
> >>> +#define LEC_FORM_ERROR 2
> >>> +#define LEC_ACK_ERROR 3
> >>> +#define LEC_BIT1_ERROR 4
> >>> +#define LEC_BIT0_ERROR 5
> >>> +#define LEC_CRC_ERROR 6
> >>
> >> Could be an enum!?
> >
> > Yes LEC error types can be defined as enum, but #define also
> > seems fine.
>
> If you use it with switch, an anonymous enumeration seems more
> appropriate for me.
Ok, I get your point.
V3 will implement LEC as an enum.
> ...
> >>> +static inline int c_can_object_put(struct net_device *dev,
> >>> + int iface, int objno, int mask)
> >>> +{
> >>> + struct c_can_priv *priv = netdev_priv(dev);
> >>> + int timeout = (6 / priv->can.clock.freq);
> >>
> >> Hm, "timeout = 0" does not look resonable.
> >
> > Let me see if I get your point here.
> > You mean use something like:
> >
> > count = 6 /* non-zero count at start */
> > /* write message object no in IF COMM_REQ reg */
> > while (count) {
> > udelay(timeout);
> > count--;
> > }
> > /* read BUSY status from IF COM reg */
> > if (busy)
> > return -ETIMEDOUT;
>
> Yes, using a larger repeat count with a shorter delay is more
> efficient,
> I think. And an error message would be nice as well, especially if you
> don't handle the return code.
Ok.
> >>> + return -ETIMEDOUT;
> >>> + }
> >>
> >> Is the timeout really needed? If yes, re-trying various times would
> >> more
> >> more safe.
> >
> > Yes timeout is needed as per specs. Please see the approach given
> above.
>
> OK, I just asked because it did work with timeout=0!!!
Oh.. that's strange.
However, if the specs says so we must implement timeout.
I will follow the approach you suggested.
> > If you agree the same can be added in V3.
>
> See above.
Ditto..
> >>> + return 0;
> >>> +}
> ...
>
> >>> + stats->rx_packets++;
> >>> + stats->rx_bytes += frame->can_dlc;
> >>> +
> >>> + return 0;
> >>
> >> The return values are not handled anywhere!
> >
> > Hmm. This is the tricky part. To be honest, a
> > lot of driver's don't handle all the return values.
> > This function is called from an isr / poll-event.
> > Do you think it's useful to handle the return values
> > there?
>
> Well, if you don't handle the return code just use a *void* function
> and
> print an error message instead, if appropriate.
I agree.
> ...
> >>> +
> >>> +/*
> >>> + * Configure C_CAN message objects for Tx and Rx purposes:
> >>> + * C_CAN provides a total of 32 message objects that can be
> >> configured
> >>> + * either for Tx or Rx purposes. Here the first 16 message objects
> >> are used as
> >>> + * a reception FIFO. The end of reception FIFO is signified by the
> >> EoB bit
> >>> + * being SET. The remaining 16 message objects are kept aside for
> Tx
> >> purposes.
> >>> + * See user guide document for further details on configuring
> >> message
> >>> + * objects.
> >>> + */
> >>
> >> Did you verify *in-order* transmisson and reception? You could use
> the
> >> canfdtest program from the can-utils.
> >
> > I will check V3 for the same.
> > I also checked Marc's at91 driver and the
> > approach implemented there for in-order rx
> > object reception seems fine to me. If you and Marc agree I can
> > use the same here. Also I need to add credits for the same :)
>
> In-order-transmission and reception is *mandatory*. You can also have a
> look to the pch_can driver. As already mentioned above, the "canfdtest"
> program from the "can-utils" is useful to validate that requirement.
I understand that in-order-transmission and reception is mandatory.
I will check the implementation of at91 and pch CAN drivers for the same.
V3 will ensure in-order RX and TX :)
> ...
> >>> +/*
> >>> + * Configure C_CAN chip:
> >>> + * - enable/disable auto-retransmission
> >>> + * - set operating mode
> >>> + * - configure message objects
> >>> + */
> >>> +static int c_can_chip_config(struct net_device *dev)
> >>> +{
> >>> + struct c_can_priv *priv = netdev_priv(dev);
> >>> +
> >>> + if (priv->can.ctrlmode & CAN_CTRLMODE_ONE_SHOT)
> >>> + /* disable automatic retransmission */
> >>> + priv->write_reg(priv, &priv->reg_base->control,
> >>> + CONTROL_DISABLE_AR);
> >>> + else
> >>> + /* enable automatic retransmission */
> >>> + priv->write_reg(priv, &priv->reg_base->control,
> >>> + CONTROL_ENABLE_AR);
> >>> +
> >>> + if (priv->can.ctrlmode & CAN_CTRLMODE_LOOPBACK) {
> >>> + /* loopback mode : useful for self-test function */
> >>> + priv->write_reg(priv, &priv->reg_base->control,
> >> (CONTROL_EIE |
> >>> + CONTROL_SIE | CONTROL_IE |
> CONTROL_TEST));
> >>> + priv->write_reg(priv, &priv->reg_base->test,
> TEST_LBACK);
> >>> + } else if (priv->can.ctrlmode & CAN_CTRLMODE_LISTENONLY) {
> >>> + /* silent mode : bus-monitoring mode */
> >>> + priv->write_reg(priv, &priv->reg_base->control,
> >> (CONTROL_EIE |
> >>> + CONTROL_SIE | CONTROL_IE |
> CONTROL_TEST));
> >>> + priv->write_reg(priv, &priv->reg_base->test,
> TEST_SILENT);
> >>> + } else if (priv->can.ctrlmode & (CAN_CTRLMODE_LISTENONLY &
> >>> + CAN_CTRLMODE_LOOPBACK)) {
> >>
> >> As I see it, this case is never entered.
> >
> > You are right. But as we discussed during the review of V1,
> > as the c_can core supports this mode (loopback + listen-only)
> > we should support the same in the driver as well.
>
> Yes, and therefore you need to check the bits first, otherwise it will
> not work.
Ah.. Right.
> >
> >>> + /* loopback + silent mode : useful for hot self-test */
> >>> + priv->write_reg(priv, &priv->reg_base->control,
> >> (CONTROL_EIE |
> >>> + CONTROL_SIE | CONTROL_IE |
> CONTROL_TEST));
> >>> + priv->write_reg(priv, &priv->reg_base->test,
> >>> + (TEST_LBACK | TEST_SILENT));
> >>> + } else
> >>> + /* normal mode*/
> >>> + priv->write_reg(priv, &priv->reg_base->control,
> >>> + (CONTROL_EIE | CONTROL_SIE |
> CONTROL_IE));
> >>> +
> >>> + /* configure message objects */
> >>> + c_can_configure_msg_objects(dev);
> >>> +
> >>> + return 0;
> >>> +}
>
> ...
>
> >>> +/*
> >>> + * c_can_do_rx_poll - read multiple CAN messages from message
> >> objects
> >>> + */
> >>> +static int c_can_do_rx_poll(struct net_device *dev, int quota)
> >>> +{
> >>> + u32 num_rx_pkts = 0;
> >>> + unsigned int msg_obj;
> >>> + struct c_can_priv *priv = netdev_priv(dev);
> >>> + u32 val = c_can_read_reg32(priv, &priv->reg_base->newdat1);
> >>> +
> >>> + while (val & RECEIVE_OBJECT_BITS) {
> >>> + for (msg_obj = C_CAN_MSG_OBJ_RX_FIRST;
> >>> + msg_obj <= C_CAN_MSG_OBJ_RX_LAST;
> msg_obj++) {
> >>> + if (val & (1 << msg_obj)) {
> >>> + c_can_read_msg_object(dev, 0, msg_obj);
> >>> + num_rx_pkts++;
> >>> + quota--;
> >>
> >> Where do you handle quota?
> >
> > Sorry but I didn't get your meaning here.
> > Everytime the rx_poll function is called quota is
> > decremented and num of rx packets received is incremented.
> > Am I missing something here?
>
> You should not handle more than "quota" messages in this function. This
> means that it shoud return if quota==0 is reached.
After writing this comment I realized that quota should be checked
against 0 here. V3 will implement the same.
> ...
>
> >>> + /* check for 'last error code' which tells us the
> >>> + * type of the last error to occur on the CAN bus
> >>> + */
> >>> + if (lec_type) {
> >>> + /* common for all type of bus errors */
> >>> + priv->can.can_stats.bus_error++;
> >>> + stats->rx_errors++;
> >>> + cf->can_id |= CAN_ERR_PROT | CAN_ERR_BUSERROR;
> >>> + cf->data[2] |= CAN_ERR_PROT_UNSPEC;
> >>> +
> >>> + if (lec_type & LEC_STUFF_ERROR) {
> >>> + dev_info(dev->dev.parent, "stuff error\n");
> >>> + cf->data[2] |= CAN_ERR_PROT_STUFF;
> >>> + }
> >>> + if (lec_type & LEC_FORM_ERROR) {
> >>> + dev_info(dev->dev.parent, "form error\n");
> >>> + cf->data[2] |= CAN_ERR_PROT_FORM;
> >>> + }
> >>> + if (lec_type & LEC_ACK_ERROR) {
> >>> + dev_info(dev->dev.parent, "ack error\n");
> >>> + cf->data[2] |= (CAN_ERR_PROT_LOC_ACK |
> >>> + CAN_ERR_PROT_LOC_ACK_DEL);
> >>> + }
> >>> + if (lec_type & LEC_BIT1_ERROR) {
> >>> + dev_info(dev->dev.parent, "bit1 error\n");
> >>> + cf->data[2] |= CAN_ERR_PROT_BIT1;
> >>> + }
> >>> + if (lec_type & LEC_BIT0_ERROR) {
> >>> + dev_info(dev->dev.parent, "bit0 error\n");
> >>> + cf->data[2] |= CAN_ERR_PROT_BIT0;
> >>> + }
> >>> + if (lec_type & LEC_CRC_ERROR) {
> >>> + dev_info(dev->dev.parent, "CRC error\n");
> >>
> >> Please use dev_dbg() here and above
> >
> > Ok.
> >
> >>> + cf->data[2] |= (CAN_ERR_PROT_LOC_CRC_SEQ |
> >>> + CAN_ERR_PROT_LOC_CRC_DEL);
> >>> + }
> >>> + }
> >>
> >> The lec should be handled by a switch statement. Also, please use
> >> dev_dbg in favor of dev_info.
> >
> > But as I have seen on the board, there can be multiple lec bits
> > set at a time (e.g. shorting CAN TX and RX lines). In such cases the
> > multiple-if structure handles the same. Do you agree?
>
> No. Testing the individual bits of an enumeration value does not make
> sense. I just speak about the last error code (lec_type).
Ok.
> >>> + netif_receive_skb(skb);
> >>> + stats->rx_packets++;
> >>> + stats->rx_bytes += cf->can_dlc;
> >>> +
> >>> + return 1;
> >>> +}
> >>> +
> ...
> >>> + priv->can.ctrlmode_supported = CAN_CTRLMODE_ONE_SHOT |
> >>> + CAN_CTRLMODE_LOOPBACK |
> >>> + CAN_CTRLMODE_LISTENONLY |
> >>> + CAN_CTRLMODE_BERR_REPORTING;
> >>
> >> Where is CAN_CTRLMODE_BERR_REPORTING implemented? Note that it has
> >> nothing to do with do_get_berr_counter. Please check the SJA1000
> >> driver:
> >>
> >>
> http://lxr.linux.no/#linux+v2.6.36/drivers/net/can/sja1000/sja1000.c#L1
> >> 46
> >>
> >> Bus error handling can be requested by the user via netlink
> interface.
> >>
> >> # ip link set canX type can ... berr-reporting on
> >>
> >> The driver then usually enables the bus error interrupts. I just
> >> realize
> >> that Documentation/networking/can.txt is not up-to-date. I will
> provide
> >> a patch a.s.a.p.
> >
> > Yes, I have seen the sja1000 implementation before preparing V2.
> > But unfortunately the c_can core does not also only the bus-error-
> reporting
> > to be masked/unmasked. There are three interrupt masks available in
> the
> > Control register:
> >
> > a) Error Interrupt Enable
> > If Enabled - A change in the bits BOff or EWarn in the Status
> Register will
> > generate an interrupt.
> > b) Status Change Interrupt Enable
> > If Enabled - An interrupt will be generated when a message transfer
> is
> > successfully completed or a CAN bus error is detected.
> > c) Module Interrupt Enable
> > If Enabled - Interrupts will set IRQ_B to LOW.
>
> OK, then you should handle it like the flexcan driver. See:
>
> http://lxr.linux.no/#linux+v2.6.36/drivers/net/can/flexcan.c#L533
Ok, I will go through the details give in the flexcan driver
> In the meantime I compared the CAN chapter of the PCH manual with the
> C_CAN manual. The paragraphs I checked are *identical*. This makes
> clear, that the "pch_can" is a clone of the C_CAN CAN controller, with
> a few extensions, though. Therefore it would make sense, to implement a
> bus sensitive interface like for the SJA1000 allowing to handle both
> CAN
> controllers with one driver sooner than later. Therefore, could you
> please implement:
>
> drivers/net/can/c_can/c_can.c
> /c_can_platform.c
>
> Then an interface to the PCI based PCH CAN controller could be added
> easily, e.g. as "pch_pci.c". You already had something similar in your
> RFC version of the patch, IIRC.
This was the approach I initially proposed in my RFC V1 patch :)
But unfortunately we could not agree to it.
So, please let me reiterate what I understood and what was present
in RFC version of the patch. Please add your comments/views:
- drivers/net/can/c_can/c_can.c (similar on lines of sja1000.c)
i.e. a)no *probe* / *remove* functions here,
b)register read/write implemented here.
- drivers/net/can/c_can/c_can_platform.c (similar on lines of sja1000_platform.c)
i.e. *probe* / *remove* implemented here,
Marc and Tomoya can also add their suggestions so that I can finalize V3 a.s.a.p.
> Thanks,
>
> Wolfgang.
Regards,
Bhupesh
^ permalink raw reply
* Re: [PATCH v2 1/1] TCP: increase default initial receive window.
From: Eric Dumazet @ 2010-12-21 5:00 UTC (permalink / raw)
To: Nandita Dukkipati
Cc: David S. Miller, netdev, Tom Herbert, Laurent Chavey,
Yuchung Cheng, Stephen Hemminger, Rick Jones
In-Reply-To: <1292890556-29904-1-git-send-email-nanditad@google.com>
Le lundi 20 décembre 2010 à 16:15 -0800, Nandita Dukkipati a écrit :
> This patch changes the default initial receive window to 10 mss
> (defined constant). The default window is limited to the maximum
> of 10*1460 and 2*mss (when mss > 1460).
>
> draft-ietf-tcpm-initcwnd-00 is a proposal to the IETF that recommends
> increasing TCP's initial congestion window to 10 mss or about 15KB.
> Leading up to this proposal were several large-scale live Internet
> experiments with an initial congestion window of 10 mss (IW10), where
> we showed that the average latency of HTTP responses improved by
> approximately 10%. This was accompanied by a slight increase in
> retransmission rate (0.5%), most of which is coming from applications
> opening multiple simultaneous connections. To understand the extreme
> worst case scenarios, and fairness issues (IW10 versus IW3), we further
> conducted controlled testbed experiments. We came away finding minimal
> negative impact even under low link bandwidths (dial-ups) and small
> buffers. These results are extremely encouraging to adopting IW10.
>
> However, an initial congestion window of 10 mss is useless unless a TCP
> receiver advertises an initial receive window of at least 10 mss.
> Fortunately, in the large-scale Internet experiments we found that most
> widely used operating systems advertised large initial receive windows
> of 64KB, allowing us to experiment with a wide range of initial
> congestion windows. Linux systems were among the few exceptions that
> advertised a small receive window of 6KB. The purpose of this patch is
> to fix this shortcoming.
>
> References:
> 1. A comprehensive list of all IW10 references to date.
> http://code.google.com/speed/protocols/tcpm-IW10.html
>
> 2. Paper describing results from large-scale Internet experiments with IW10.
> http://ccr.sigcomm.org/drupal/?q=node/621
>
> 3. Controlled testbed experiments under worst case scenarios and a
> fairness study.
> http://www.ietf.org/proceedings/79/slides/tcpm-0.pdf
>
> 4. Raw test data from testbed experiments (Linux senders/receivers)
> with initial congestion and receive windows of both 10 mss.
> http://research.csc.ncsu.edu/netsrv/?q=content/iw10
>
> 5. Internet-Draft. Increasing TCP's Initial Window.
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/
>
> Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH v2 1/1] TCP: increase default initial receive window.
From: David Miller @ 2010-12-21 5:33 UTC (permalink / raw)
To: eric.dumazet
Cc: nanditad, netdev, therbert, chavey, ycheng, shemminger,
rick.jones2
In-Reply-To: <1292907606.2627.151.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 21 Dec 2010 06:00:06 +0100
> Le lundi 20 décembre 2010 à 16:15 -0800, Nandita Dukkipati a écrit :
>> Signed-off-by: Nandita Dukkipati <nanditad@google.com>
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH v3 net-next-2.6] net_sched: sch_sfq: better struct layouts
From: David Miller @ 2010-12-21 5:33 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, kaber, jarkao2
In-Reply-To: <1292885698.2627.119.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 20 Dec 2010 23:54:58 +0100
> [PATCH v3 net-next-2.6] net_sched: sch_sfq: better struct layouts
>
> This patch shrinks sizeof(struct sfq_sched_data)
> from 0x14f8 (or more if spinlocks are bigger) to 0x1180 bytes, and
> reduce text size as well.
>
> text data bss dec hex filename
> 4821 152 0 4973 136d old/net/sched/sch_sfq.o
> 4627 136 0 4763 129b new/net/sched/sch_sfq.o
>
>
> All data for a slot/flow is now grouped in a compact and cache friendly
> structure, instead of being spreaded in many different points.
>
> struct sfq_slot {
> struct sk_buff *skblist_next;
> struct sk_buff *skblist_prev;
> sfq_index qlen; /* number of skbs in skblist */
> sfq_index next; /* next slot in sfq chain */
> struct sfq_head dep; /* anchor in dep[] chains */
> unsigned short hash; /* hash value (index in ht[]) */
> short allot; /* credit for this slot */
> };
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ppp: allow disabling multilink protocol ID compression
From: Eric Dumazet @ 2010-12-21 5:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Paul Mackerras, linux-ppp, netdev
In-Reply-To: <20101220195833.26786ec5@nehalam>
Le lundi 20 décembre 2010 à 19:58 -0800, Stephen Hemminger a écrit :
> Linux would not connect to other router running old version Cisco IOS (12.0).
> This is most likely a bug in that version of IOS, since it is fixed
> in later versions. As a workaround this patch allows a module parameter
> to be set to disable compressing the protocol ID.
>
> See: https://bugzilla.vyatta.com/show_bug.cgi?id=3979
>
> RFC 1990 allows an implementation to formulate MP fragments as if protocol
> compression had been negotiated. This allows us to always send compressed
> protocol IDs. But some implementations don't accept MP fragments with
> compressed protocol IDs. This parameter allows us to interoperate with
> them. The default value of the configurable parameter is the same as the
> current behavior: protocol compression is enabled. If protocol compression
> is disabled we will not send compressed protocol IDs.
>
> This is based on an earlier patch by Bob Gilligan (using a sysctl).
> Module parameter is writable to allow for enabling even if ppp
> is already loaded for other uses.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* [patch -next] bnx2x: remove bogus check
From: Dan Carpenter @ 2010-12-21 7:04 UTC (permalink / raw)
To: Eilon Greenstein; +Cc: netdev, kernel-janitors
We dereferenced params on the line before so it's too late to check if
params is NULL. In fact, params can never be NULL and strict_cos is
either 0 or 1 so that part of the check is bogus too. Let's remove it.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/bnx2x/bnx2x_link.c b/drivers/net/bnx2x/bnx2x_link.c
index 97cbee2..43b0de2 100644
--- a/drivers/net/bnx2x/bnx2x_link.c
+++ b/drivers/net/bnx2x/bnx2x_link.c
@@ -354,9 +354,6 @@ u8 bnx2x_ets_strict(const struct link_params *params, const u8 strict_cos)
struct bnx2x *bp = params->bp;
u32 val = 0;
- if ((1 < strict_cos) && (NULL == params))
- return -EINVAL;
-
DP(NETIF_MSG_LINK, "ETS enabled strict configuration\n");
/**
* Bitmap of 5bits length. Each bit specifies whether the entry behaves
^ permalink raw reply related
* [PATCH net-next-2.6] net: timestamp cloned packet in dev_queue_xmit_nit
From: Eric Dumazet @ 2010-12-21 7:22 UTC (permalink / raw)
To: David Miller; +Cc: Changli Gao, netdev, Patrick McHardy, Jarek Poplawski
In-Reply-To: <1292577988.2906.1.camel@edumazet-laptop>
Le vendredi 17 décembre 2010 à 10:26 +0100, Eric Dumazet a écrit :
>
> I think we can add this after latest Changli patch :
>
> He does one skb_clone() before calling the sniffers.
> We could set timestamp on this clone, instead of original skb.
>
> Problem solved.
>
[PATCH net-next-2.6] net: timestamp cloned packet in dev_queue_xmit_nit
Now we do one clone of skb if at least one sniffer might take packet,
we also can do the skb timestamping on the clone and let original packet
unchanged.
This is a generalization of commit 8caf153974f2 (net: sch_netem: Fix an
inconsistency in ingress netem timestamps.)
This way, we can have a good idea when packets are delivered to our
stack (tcpdump -i ifb0), while a tcpdump on original device gives
timestamps right before ingressing.
This also speedup our stack, avoiding taking timestamps if not needed.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Changli Gao <xiaosuo@gmail.com>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Jarek Poplawski <jarkao2@gmail.com>
---
net/core/dev.c | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 5987729..a215269 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1547,13 +1547,6 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
struct sk_buff *skb2 = NULL;
struct packet_type *pt_prev = NULL;
-#ifdef CONFIG_NET_CLS_ACT
- if (!(skb->tstamp.tv64 && (G_TC_FROM(skb->tc_verd) & AT_INGRESS)))
- net_timestamp_set(skb);
-#else
- net_timestamp_set(skb);
-#endif
-
rcu_read_lock();
list_for_each_entry_rcu(ptype, &ptype_all, list) {
/* Never send packets back to the socket
@@ -1572,6 +1565,8 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
if (!skb2)
break;
+ net_timestamp_set(skb2);
+
/* skb->nh should be correctly
set by sender, so that the second statement is
just protection against buggy protocols.
^ permalink raw reply related
* [patch -next] stmmac: unwind properly in stmmac_dvr_probe()
From: Dan Carpenter @ 2010-12-21 7:34 UTC (permalink / raw)
To: Giuseppe Cavallaro; +Cc: netdev, kernel-janitors
The original code had a several problems:
*) It had potential null dereferences of "priv" and "res".
*) It released the memory region before it was aquired.
*) It didn't free "ndev" after it was allocated.
*) It didn't call unregister_netdev() after calling stmmac_probe().
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/stmmac/stmmac_main.c b/drivers/net/stmmac/stmmac_main.c
index 20f803d..34a0af3 100644
--- a/drivers/net/stmmac/stmmac_main.c
+++ b/drivers/net/stmmac/stmmac_main.c
@@ -1647,10 +1647,8 @@ static int stmmac_dvr_probe(struct platform_device *pdev)
pr_info("STMMAC driver:\n\tplatform registration... ");
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- ret = -ENODEV;
- goto out;
- }
+ if (!res)
+ return -ENODEV;
pr_info("\tdone!\n");
if (!request_mem_region(res->start, resource_size(res),
@@ -1658,22 +1656,21 @@ static int stmmac_dvr_probe(struct platform_device *pdev)
pr_err("%s: ERROR: memory allocation failed"
"cannot get the I/O addr 0x%x\n",
__func__, (unsigned int)res->start);
- ret = -EBUSY;
- goto out;
+ return -EBUSY;
}
addr = ioremap(res->start, resource_size(res));
if (!addr) {
pr_err("%s: ERROR: memory mapping failed\n", __func__);
ret = -ENOMEM;
- goto out;
+ goto out_release_region;
}
ndev = alloc_etherdev(sizeof(struct stmmac_priv));
if (!ndev) {
pr_err("%s: ERROR: allocating the device\n", __func__);
ret = -ENOMEM;
- goto out;
+ goto out_unmap;
}
SET_NETDEV_DEV(ndev, &pdev->dev);
@@ -1683,8 +1680,8 @@ static int stmmac_dvr_probe(struct platform_device *pdev)
if (ndev->irq == -ENXIO) {
pr_err("%s: ERROR: MAC IRQ configuration "
"information not found\n", __func__);
- ret = -ENODEV;
- goto out;
+ ret = -ENXIO;
+ goto out_free_ndev;
}
priv = netdev_priv(ndev);
@@ -1711,18 +1708,18 @@ static int stmmac_dvr_probe(struct platform_device *pdev)
if (priv->plat->init) {
ret = priv->plat->init(pdev);
if (unlikely(ret))
- goto out;
+ goto out_free_ndev;
}
/* MAC HW revice detection */
ret = stmmac_mac_device_setup(ndev);
if (ret < 0)
- goto out;
+ goto out_plat_exit;
/* Network Device Registration */
ret = stmmac_probe(ndev);
if (ret < 0)
- goto out;
+ goto out_plat_exit;
/* associate a PHY - it is provided by another platform bus */
if (!driver_for_each_device
@@ -1730,7 +1727,7 @@ static int stmmac_dvr_probe(struct platform_device *pdev)
stmmac_associate_phy)) {
pr_err("No PHY device is associated with this MAC!\n");
ret = -ENODEV;
- goto out;
+ goto out_unregister;
}
pr_info("\t%s - (dev. name: %s - id: %d, IRQ #%d\n"
@@ -1741,19 +1738,22 @@ static int stmmac_dvr_probe(struct platform_device *pdev)
pr_debug("\tMDIO bus (id: %d)...", priv->plat->bus_id);
ret = stmmac_mdio_register(ndev);
if (ret < 0)
- goto out;
+ goto out_unregister;
pr_debug("registered!\n");
+ return 0;
-out:
- if (ret < 0) {
- if (priv->plat->exit)
- priv->plat->exit(pdev);
-
- platform_set_drvdata(pdev, NULL);
- release_mem_region(res->start, resource_size(res));
- if (addr != NULL)
- iounmap(addr);
- }
+out_unregister:
+ unregister_netdev(ndev);
+out_plat_exit:
+ if (priv->plat->exit)
+ priv->plat->exit(pdev);
+out_free_ndev:
+ free_netdev(ndev);
+ platform_set_drvdata(pdev, NULL);
+out_unmap:
+ iounmap(addr);
+out_release_region:
+ release_mem_region(res->start, resource_size(res));
return ret;
}
^ permalink raw reply related
* Re: [PATCH V7 1/8] ntp: add ADJ_SETOFFSET mode bit
From: Richard Cochran @ 2010-12-21 7:56 UTC (permalink / raw)
To: Kuwahara,T.
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Alan Cox, Arnd Bergmann, Christoph Lameter, David Miller,
John Stultz, Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <AANLkTi=yGoFwYt4p_LeHtAQyYgmURspO-p57UdL0sUEZ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sat, Dec 18, 2010 at 05:16:52AM +0900, Kuwahara,T. wrote:
> On 12/17/10, Richard Cochran <richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > This patch adds a new mode bit into the timex structure. When set, the bit
> > instructs the kernel to add the given time value to the current time.
> >
>
> The proposed new control mode, ADJ_SETOFFSET, is logically the same as
> ADJ_OFFSET with timex.constant == -INFINITY. So it is possible to do
> the same thing without risking forward compatibility. (I mean by "risking
> forward compatibility" that the mode bit 0x0040 may be defined differently
> by the upstream maintainer anytime in the future.)
Can you please elaborate?
I don't see any way to use timex.constant with ADJ_OFFSET in order to
correct a time offset. The 'time_constant' in kernel/time/ntp.c is
restricted to the interval [0..MAXTC], and MAXTC is 10 in timex.h.
Richard
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: timestamp cloned packet in dev_queue_xmit_nit
From: Changli Gao @ 2010-12-21 7:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Patrick McHardy, Jarek Poplawski
In-Reply-To: <1292916171.2627.184.camel@edumazet-laptop>
On Tue, Dec 21, 2010 at 3:22 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 17 décembre 2010 à 10:26 +0100, Eric Dumazet a écrit :
>
>>
>> I think we can add this after latest Changli patch :
>>
>> He does one skb_clone() before calling the sniffers.
>> We could set timestamp on this clone, instead of original skb.
>>
>> Problem solved.
>>
>
> [PATCH net-next-2.6] net: timestamp cloned packet in dev_queue_xmit_nit
>
> Now we do one clone of skb if at least one sniffer might take packet,
> we also can do the skb timestamping on the clone and let original packet
> unchanged.
>
> This is a generalization of commit 8caf153974f2 (net: sch_netem: Fix an
> inconsistency in ingress netem timestamps.)
>
> This way, we can have a good idea when packets are delivered to our
> stack (tcpdump -i ifb0), while a tcpdump on original device gives
> timestamps right before ingressing.
>
> This also speedup our stack, avoiding taking timestamps if not needed.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Changli Gao <xiaosuo@gmail.com>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: Jarek Poplawski <jarkao2@gmail.com>
Acked-by: Changli Gao <xiaosuo@gmail.com>
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH V7 4/8] posix clocks: hook dynamic clocks into system calls
From: Richard Cochran @ 2010-12-21 8:00 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-kernel, linux-api, netdev, Alan Cox, Arnd Bergmann,
Christoph Lameter, David Miller, John Stultz, Krzysztof Halasa,
Peter Zijlstra, Rodolfo Giometti
In-Reply-To: <alpine.LFD.2.00.1012171010160.12146@localhost6.localdomain6>
On Fri, Dec 17, 2010 at 11:03:46AM +0100, Thomas Gleixner wrote:
>
> Doesn't the same problem exist for the file operations of patch 3? I
> think you want the very same protection there unless you want to do
> the same magic in your USB driver as well.
Yes, you are right. I overlooked that.
> So you could do the following:
...
> So your fops would call get_fd_clk() and put_fd_clk() and the pc_timer
> ones get_posix_clock() and put_posix_clock() or whatever sensible
> function names you come up with.
>
> Thoughts ?
It is a good, concrete suggestion. I will try it that way.
Thanks,
Richard
^ permalink raw reply
* Using ethernet device as efficient small packet generator
From: juice @ 2010-12-21 9:56 UTC (permalink / raw)
To: netdev
Hi net-devvers.
I am involved in telecom equipment R&D, and I need to do some network
performance benchmarking. We need to generate streams of Ethernet/IP/UDP
traffic that consists of different sized payloads ranging from smallest
AMR payload to ethernet MTU.
We have various tools including for example Spirent traffic generators
as well as in-house made software generating 3GPP specified protocol
streams. Now, the problem with the off-the-shelf generators is the
inflexibility in our needs and the unavailability to R&D personnel to
have the generator available at any given time.
For larger packet sizes our linux-based generator is quite sufficent,
as I can use it to fully saturate GE link with packet sizes around 1kB.
However, as packet sizes get smalles ethernet performance suffers.
I did some benchmarking using pktgen with 64B packets against AX4000 and
confirmed that the maximun throughput is only around 25% of GE capacity.
I managed to get to about same speeds using own custom module that writes
skbuffs directly to kernel *xmit of the netdev.
Now, it is evident that something is not optimized to the maximum here
as PCI bus allows for way higher transfer speeds. If large packets can
fully saturate the ethernet link same should apply for minimum sized
packets too, unless there is some overhead I am unaware of.
I have couple of questions here:
1.) Is it possible to enhance the "normal" behaving network driver so
that the device would still work as an ethernet device (ethxx)?
Currently the test stream is generated in userland process that
writes to RAW_SOCK, but it is OK for me if I need to write the
packet generating part as a kernel module that is configured
from the userland part to send the prepared stream out.
2.) If it is not possible to get the needed performance from normal
network architecture, is it possible to make a "generate only"
ethernet device that I can use to replace the network card driver?
For example, RX is not really needed at all by my application, so
just optimizing the driver to send out packets from memory as fast
as possible is enough.
Are there notable differences between ethernet chipsets/cards
regarding to the raw output speed they are capable?
I have benchmarked e1000, r8169 ang tg3 based cards and with all
of those I get about same throughput of 64byte ethernet frames.
For my purpose, it would be OK, for example, to remove the normal
r8169 driver and replace it with a custom TX-only driver, and use
some other normal driver tied to another card to access the box.
I appreciate your comments and any pointers to existing projects that
have similar implementation that I require.
Yours, Jussi Ohenoja
^ permalink raw reply
* Re: [PATCH net-next-2.6] sch_sfq: allow big packets and be fair
From: Jarek Poplawski @ 2010-12-21 10:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Patrick McHardy, netdev
In-Reply-To: <1292886976.2627.146.camel@edumazet-laptop>
On 2010-12-21 00:16, Eric Dumazet wrote:
> SFQ is currently 'limited' to small packets, because it uses a 16bit
> allotment number per flow. Switch it to 18bit, and use appropriate
> handling to make sure this allotment is in [1 .. quantum] range before a
> new packet is dequeued, so that fairness is respected.
Well, such two important changes should be in separate patches.
The change of allotment limit looks OK (but I would try scaling, e.g.
in 16-byte chunks, btw).
The change in fair treatment looks dubious. A flow which uses exactly
it's quantum in one round will be skipped in the next round. A flow
which uses a bit more than its quantum in one round, will be skipped
too, while we should only give it less this time to keep the sum up to
2 quantums. (The usual algorithm is to check if a flow has enough
"tickets" for sending its next packet.)
Jarek P.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Jarek Poplawski <jarkao2@gmail.com>
> Cc: Patrick McHardy <kaber@trash.net>
> ---
> net/sched/sch_sfq.c | 24 ++++++++++++++++--------
> 1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
> index c474b4b..878704a 100644
> --- a/net/sched/sch_sfq.c
> +++ b/net/sched/sch_sfq.c
> @@ -67,7 +67,7 @@
>
> IMPLEMENTATION:
> This implementation limits maximal queue length to 128;
> - maximal mtu to 2^15-1; max 128 flows, number of hash buckets to 1024.
> + maximal mtu to 2^16-1; max 128 flows, number of hash buckets to 1024.
> The only goal of this restrictions was that all data
> fit into one 4K page on 32bit arches.
>
> @@ -99,9 +99,10 @@ struct sfq_slot {
> sfq_index qlen; /* number of skbs in skblist */
> sfq_index next; /* next slot in sfq chain */
> struct sfq_head dep; /* anchor in dep[] chains */
> - unsigned short hash; /* hash value (index in ht[]) */
> - short allot; /* credit for this slot */
> + unsigned int hash:14; /* hash value (index in ht[]) */
> + unsigned int allot:18; /* credit for this slot */
> };
> +#define ALLOT_ZERO (1 << 16)
>
> struct sfq_sched_data
> {
> @@ -394,7 +395,7 @@ sfq_enqueue(struct sk_buff *skb, struct Qdisc *sch)
> q->tail->next = x;
> }
> q->tail = slot;
> - slot->allot = q->quantum;
> + slot->allot = ALLOT_ZERO + q->quantum;
> }
> if (++sch->q.qlen <= q->limit) {
> sch->bstats.bytes += qdisc_pkt_len(skb);
> @@ -430,8 +431,14 @@ sfq_dequeue(struct Qdisc *sch)
> if (q->tail == NULL)
> return NULL;
>
> +next:
> a = q->tail->next;
> slot = &q->slots[a];
> + if (slot->allot <= ALLOT_ZERO) {
> + q->tail = slot;
> + slot->allot += q->quantum;
> + goto next;
> + }
> skb = slot_dequeue_head(slot);
> sfq_dec(q, a);
> sch->q.qlen--;
> @@ -446,9 +453,8 @@ sfq_dequeue(struct Qdisc *sch)
> return skb;
> }
> q->tail->next = next_a;
> - } else if ((slot->allot -= qdisc_pkt_len(skb)) <= 0) {
> - q->tail = slot;
> - slot->allot += q->quantum;
> + } else {
> + slot->allot -= qdisc_pkt_len(skb);
> }
> return skb;
> }
> @@ -610,7 +616,9 @@ static int sfq_dump_class_stats(struct Qdisc *sch, unsigned long cl,
> struct sfq_sched_data *q = qdisc_priv(sch);
> const struct sfq_slot *slot = &q->slots[q->ht[cl - 1]];
> struct gnet_stats_queue qs = { .qlen = slot->qlen };
> - struct tc_sfq_xstats xstats = { .allot = slot->allot };
> + struct tc_sfq_xstats xstats = {
> + .allot = slot->allot - ALLOT_ZERO
> + };
> struct sk_buff *skb;
>
> slot_queue_walk(slot, skb)
>
>
> --
^ permalink raw reply
* request-pull: Use static const
From: Joe Perches @ 2010-12-21 10:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Resubmitting the remnants of an earlier discrete patchset.
https://lkml.org/lkml/2010/11/20/209
Consolidated into smaller patches.
The following changes since commit d9993be65a77f500ae926176baa264816bfe3816:
Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 (2010-12-20 13:24:14 -0800)
are available in the git repository at:
git://repo.or.cz/linux-2.6/trivial-mods.git 20101221_static_const
Joe Perches (5):
tg3: Use DEFINE_PCI_DEVICE_TABLE
drivers/net/*.c: Use static const
usb: Use static const, consolidate code
tulip: Use DEFINE_PCI_DEVICE_TABLE and static const
drivers/net/*/: Use static const
drivers/net/3c501.c | 4 +-
drivers/net/3c503.c | 4 +-
drivers/net/3c507.c | 4 +-
drivers/net/3c527.c | 6 ++--
drivers/net/at1700.c | 6 ++--
drivers/net/benet/be_ethtool.c | 4 ++-
drivers/net/benet/be_main.c | 10 ++++----
drivers/net/bnx2.c | 46 ++++++++++++++++++-----------------
drivers/net/bnx2x/bnx2x_main.c | 6 +++-
drivers/net/can/sja1000/plx_pci.c | 2 +-
drivers/net/chelsio/sge.c | 10 +++----
drivers/net/cxgb3/ael1002.c | 24 +++++++++---------
drivers/net/cxgb3/t3_hw.c | 2 +-
drivers/net/cxgb4vf/t4vf_hw.c | 2 +-
drivers/net/e2100.c | 2 +-
drivers/net/eepro.c | 9 ++++---
drivers/net/eexpress.c | 2 +-
drivers/net/gianfar.c | 10 ++++---
drivers/net/hp.c | 6 ++--
drivers/net/irda/act200l-sir.c | 2 +-
drivers/net/irda/donauboe.c | 4 +-
drivers/net/jme.c | 4 +-
drivers/net/ksz884x.c | 20 ++++++++--------
drivers/net/netxen/netxen_nic_hw.c | 16 ++++++++----
drivers/net/ni52.c | 4 +-
drivers/net/ni65.c | 4 +-
drivers/net/pcmcia/nmclan_cs.c | 2 +-
drivers/net/qlcnic/qlcnic_hw.c | 15 +++++++----
drivers/net/qlge/qlge_main.c | 13 +++++----
drivers/net/r8169.c | 2 +-
drivers/net/skfp/smt.c | 4 +-
drivers/net/skge.c | 4 +-
drivers/net/smc-ultra.c | 8 ++++-
drivers/net/tg3.c | 26 +++++++++-----------
drivers/net/tokenring/ibmtr.c | 5 ++-
drivers/net/tulip/de2104x.c | 18 +++++++++----
drivers/net/tulip/tulip_core.c | 15 +++++++----
drivers/net/usb/hso.c | 39 ++++++++++++------------------
drivers/net/vmxnet3/vmxnet3_drv.c | 4 ++-
drivers/net/wan/dscc4.c | 6 ++--
drivers/net/wd.c | 2 +-
41 files changed, 199 insertions(+), 177 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next-2.6] sch_sfq: allow big packets and be fair
From: Jarek Poplawski @ 2010-12-21 10:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Patrick McHardy, netdev
In-Reply-To: <20101221101506.GA8149@ff.dom.local>
On Tue, Dec 21, 2010 at 10:15:06AM +0000, Jarek Poplawski wrote:
> The change of allotment limit looks OK [...]
Hmm... but maybe s/ALLOT_ZERO/SFQ_ALLOT_ZERO/? ;-)
Jarek P.
^ permalink raw reply
* (unknown)
From: Richard Scheffenegger @ 2010-12-21 10:35 UTC (permalink / raw)
To: netdev
Hi guys,
You may be interested in this draft I recently posted:
http://tools.ietf.org/html/draft-scheffenegger-tcpm-sack-loss-recovery-00
It addresses a minor nit-pick fix in the SACK specs, and is a sender-only modification.
Basically, with SACK a sender following RFC3517 will ignore partial ACKs as signal that some segments running up to the end-of-stream are lost. SACK will only recover "known" holes - which means that at least one segment after the lost segment has to be received (and the ACK/SACK for this has to get to the sender).
Under certain circumstances - when the sender is regularly limited in the amount of data to send, either by the application, network (cwnd) or receiver (rwnd), loss of the last segment before RecoveryPoint leads to avoidable RTOs - if the sender would use the partial ack (ACK without any SACK entries, but below RP / snd.max) also as loss indication just as NewReno does. In comparison, using NewReno (disabling SACK), one can get improved delivery latencies, as partial ACKs trigger a retransmission with NewReno.
For the public internet, I received reports by a major player indicating a shift between 0.1 and 0.8% from RTOs to fast retransmission (at a overall RTO vs. FastRetransmit ratio of ~60%)
For private LANs, which run different applications such as NFS and very often stall until one such transaction finishes, I can not provide solid data, but it appears that the impact is more pronounced - but the RTO/FR ratio there is typically only 20-40%.
Please let me know what you think about this change.
Richard Scheffenegger
--
GMX.at - Österreichs FreeMail-Dienst mit über 2 Mio Mitgliedern
E-Mail, SMS & mehr! Kostenlos: http://portal.gmx.net/de/go/atfreemail
^ permalink raw reply
* Linux SACK - lost retransmission detection
From: Richard Scheffenegger @ 2010-12-21 10:42 UTC (permalink / raw)
To: netdev
In-Reply-To: <20101221103539.137960@gmx.net>
Hi,
One more, generic, question:
I found that Linux added SACK with kernel version 2.1.91, but I wasn’t able to track down when lost retransmission detection (LRD) was added. The only research paper I found which appears to describe approximately what linux does is from an Korean researcher, who claims to have not contributed any code to the linux kernel. Do you happen to have more pointers?
I’m currently looking into ways of how to make lost retransmissions detection work also at end-of-stream (alleviating RTOs even with small windows at least partially).
Best regards,
Richard
--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
^ permalink raw reply
* Re: [PATCH net-next-2.6] sch_sfq: allow big packets and be fair
From: Eric Dumazet @ 2010-12-21 10:44 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: David Miller, Patrick McHardy, netdev
In-Reply-To: <20101221103026.GA8622@ff.dom.local>
Le mardi 21 décembre 2010 à 10:30 +0000, Jarek Poplawski a écrit :
> On Tue, Dec 21, 2010 at 10:15:06AM +0000, Jarek Poplawski wrote:
> > The change of allotment limit looks OK [...]
>
> Hmm... but maybe s/ALLOT_ZERO/SFQ_ALLOT_ZERO/? ;-)
Its a local symbol, its not like it being in an include file ;)
^ permalink raw reply
* Re: [PATCH net-next-2.6] bnx2: remove cancel_work_sync() from remove_one
From: Tejun Heo @ 2010-12-21 10:51 UTC (permalink / raw)
To: David Miller; +Cc: mchan, netdev, linux-kernel
In-Reply-To: <20101220.131146.115941299.davem@davemloft.net>
Hello, David.
On Mon, Dec 20, 2010 at 01:11:46PM -0800, David Miller wrote:
> It would but we can't just make the change over to del_timer_sync()
> otherwise we'd deadlock on netif_tx_lock().
>
> But I think things might be OK as-is.
>
> The timer is deleted by dev_deactivate_many() which resets the qdisc
> to the no-op qdisc. Then it deletes the timer.
>
> Any running timer will complete or see the no-op qdisc attached and
> return immediately.
>
> synchronize_rcu() is then executed which guarentees completion.
>
> Since both the watchdog timer itself and the del_timer() call run
> with netif_tx_lock() held, this makes sure the timer, once deleted,
> will only see the no-op qdisc and return immediately if it is
> amidst running, else it has already returned when the timer delete
> completes.
>
> So we might be OK here.
Yeah, I agree the synchronize_rcu() there would guarantee the actual
timer completion but as it currently stands it looks a bit too subtle.
Maybe it's a good idea to add a big fat comment explaining that the
the timer is guaranteed to stop after close() and how it's guaranteed
through synchronize_rcu() at the moment? Also, it might be better to
use synchronize_sched() there as timer synchronization through
synchronize_rcu() is more of a happy accident.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH net-next-2.6] sch_sfq: allow big packets and be fair
From: Jarek Poplawski @ 2010-12-21 10:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Patrick McHardy, netdev
In-Reply-To: <1292928269.2720.0.camel@edumazet-laptop>
On Tue, Dec 21, 2010 at 11:44:29AM +0100, Eric Dumazet wrote:
> Le mardi 21 décembre 2010 ?? 10:30 +0000, Jarek Poplawski a écrit :
> > On Tue, Dec 21, 2010 at 10:15:06AM +0000, Jarek Poplawski wrote:
> > > The change of allotment limit looks OK [...]
> >
> > Hmm... but maybe s/ALLOT_ZERO/SFQ_ALLOT_ZERO/? ;-)
>
> Its a local symbol, its not like it being in an include file ;)
Sure, but why this one has to be different than others in this file?
(Plus, if you don't remember all this code it's a good hint.)
Jarek P.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox