* Re: [Bugme-new] [Bug 42132] New: Support BCM5750M in tg3
From: Matt Carlson @ 2011-09-02 1:25 UTC (permalink / raw)
To: Francesco Piccinno
Cc: Matthew Carlson, Andrew Morton, netdev@vger.kernel.org,
bugme-daemon@bugzilla.kernel.org, Benjamin Li, Michael Chan
In-Reply-To: <CAA7bCn7Au+-QEa7hTwO_P_mnL1w5TiGPz4Wsm0CxtoqT3FDBbQ@mail.gmail.com>
Yes. Sorry. Please revert that patch. If you really had a bcm5750,
you'd need to revert another patch too, but let's see where we stand
before going down that road.
On Thu, Sep 01, 2011 at 06:14:57PM -0700, Francesco Piccinno wrote:
> The only message I get regarding the firmware is the following:
>
> [51503.038205] pci 0000:08:00.0: vpd r/w failed. This is likely a
> firmware bug on this device. Contact the card vendor for a firmware
> update.
>
> Unfortunately I can not post the output of ethtool since the interface
> is not available. Shall I recompile the tg3 module with the proper
> patch and post the output?
>
> --
> Best regards,
> Francesco Piccinno
>
> On Fri, Sep 2, 2011 at 3:04 AM, Matt Carlson <mcarlson@broadcom.com> wrote:
> > It's showing up on lspci as a PCIe device, so it can't be the 5750M.
> > The bcm5750M is a pci device.
> >
> > I'm wondering if bootcode is failing. ??Do you see any messages in your
> > syslogs that say "No firmware running"?
> >
> > Can you post the output of 'ethtool -i ethX'?
> >
> > On Thu, Sep 01, 2011 at 05:48:50PM -0700, Francesco Piccinno wrote:
> >> Yes sure.
> >>
> >> # lspci -vvv -s 08:00.0
> >> 08:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5750M
> >> Gigabit Ethernet
> >> ?? ?? ?? Subsystem: Broadcom Corporation NetXtreme BCM5750M Gigabit Ethernet
> >> ?? ?? ?? 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 10
> >> ?? ?? ?? Region 0: Memory at f4100000 (64-bit, non-prefetchable) [size=64K]
> >> ?? ?? ?? Capabilities: [48] 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: [50] Vital Product Data
> >> pcilib: sysfs_read_vpd: read failed: Connection timed out
> >> ?? ?? ?? ?? ?? ?? ?? Not readable
> >> ?? ?? ?? Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
> >> ?? ?? ?? ?? ?? ?? ?? Address: 5149526521410124 ??Data: 8b60
> >> ?? ?? ?? Capabilities: [d0] Express (v1) Endpoint, MSI 00
> >> ?? ?? ?? ?? ?? ?? ?? DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 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 #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <4us, 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: [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: [13c v1] Virtual Channel
> >> ?? ?? ?? ?? ?? ?? ?? Caps: ?? LPEVC=0 RefClk=100ns PATEntryBits=1
> >> ?? ?? ?? ?? ?? ?? ?? Arb: ?? ??Fixed- WRR32- WRR64- WRR128-
> >> ?? ?? ?? ?? ?? ?? ?? Ctrl: ?? ArbSelect=Fixed
> >> ?? ?? ?? ?? ?? ?? ?? Status: InProgress-
> >> ?? ?? ?? ?? ?? ?? ?? VC0: ?? ??Caps: ?? PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Arb: ?? ??Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Ctrl: ?? Enable+ ID=0 ArbSelect=Fixed TC/VC=01
> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Status: NegoPending- InProgress-
> >> ?? ?? ?? Capabilities: [160 v1] Device Serial Number 00-00-00-ff-fe-00-00-00
> >>
> >> Serial number is CND71700K6.
> >> --
> >> Best regards,
> >> Francesco Piccinno
> >>
> >>
> >>
> >> On Fri, Sep 2, 2011 at 2:06 AM, Matt Carlson <mcarlson@broadcom.com> wrote:
> >> > On Thu, Sep 01, 2011 at 04:40:11PM -0700, Andrew Morton wrote:
> >> >>
> >> >> (switched to email. ??Please respond via emailed reply-to-all, not via the
> >> >> bugzilla web interface).
> >> >>
> >> >> On Wed, 31 Aug 2011 18:18:40 GMT
> >> >> bugzilla-daemon@bugzilla.kernel.org wrote:
> >> >>
> >> >> > https://bugzilla.kernel.org/show_bug.cgi?id=42132
> >> >> >
> >> >> > ?? ?? ?? ?? ?? ??Summary: Support BCM5750M in tg3
> >> >> > ?? ?? ?? ?? ?? ??Product: Drivers
> >> >> > ?? ?? ?? ?? ?? ??Version: 2.5
> >> >> > ?? ?? Kernel Version: 3.0.3
> >> >> > ?? ?? ?? ?? ?? Platform: All
> >> >> > ?? ?? ?? ?? OS/Version: Linux
> >> >> > ?? ?? ?? ?? ?? ?? ?? Tree: Mainline
> >> >> > ?? ?? ?? ?? ?? ?? Status: NEW
> >> >> > ?? ?? ?? ?? ?? Severity: normal
> >> >> > ?? ?? ?? ?? ?? Priority: P1
> >> >> > ?? ?? ?? ?? ??Component: Network
> >> >> > ?? ?? ?? ?? AssignedTo: drivers_network@kernel-bugs.osdl.org
> >> >> > ?? ?? ?? ?? ReportedBy: stack.box@gmail.com
> >> >> > ?? ?? ?? ?? Regression: Yes
> >> >> >
> >> >> >
> >> >> > I have a notebook (HP TC4400) which has a BCM5750 ethernet card inside. The
> >> >> > ouput of lspci is:
> >> >> >
> >> >> > 08:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5750M
> >> >> > Gigabit Ethernet [14e4:167c]
> >> >> >
> >> >> > Commit 67b284d476bcb3d100e946da23d6cf9acfd0465c removed the support for this
> >> >> > device.
> >> >> >
> >> >>
> >> >> 67b284d476bcb3d100 says "These devices were never released to the public".
> >> >>
> >> >> > I wish to have the support for this network card back again. Thanks!
> >> >>
> >> >> oops ;)
> >> >
> >> > Really? ??All the TC4400 documentation I find says it uses a bcm5753M on a
> >> > PCIe bus. ??Can you post the full output of 'lspci -vvv -s 08:00.0' ?
> >> >
> >> >
> >>
> >
> >
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 42132] New: Support BCM5750M in tg3
From: Francesco Piccinno @ 2011-09-02 1:14 UTC (permalink / raw)
To: Matt Carlson
Cc: Andrew Morton, netdev@vger.kernel.org,
bugme-daemon@bugzilla.kernel.org, Benjamin Li, Michael Chan
In-Reply-To: <20110902010431.GA5105@mcarlson.broadcom.com>
The only message I get regarding the firmware is the following:
[51503.038205] pci 0000:08:00.0: vpd r/w failed. This is likely a
firmware bug on this device. Contact the card vendor for a firmware
update.
Unfortunately I can not post the output of ethtool since the interface
is not available. Shall I recompile the tg3 module with the proper
patch and post the output?
--
Best regards,
Francesco Piccinno
On Fri, Sep 2, 2011 at 3:04 AM, Matt Carlson <mcarlson@broadcom.com> wrote:
> It's showing up on lspci as a PCIe device, so it can't be the 5750M.
> The bcm5750M is a pci device.
>
> I'm wondering if bootcode is failing. Do you see any messages in your
> syslogs that say "No firmware running"?
>
> Can you post the output of 'ethtool -i ethX'?
>
> On Thu, Sep 01, 2011 at 05:48:50PM -0700, Francesco Piccinno wrote:
>> Yes sure.
>>
>> # lspci -vvv -s 08:00.0
>> 08:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5750M
>> Gigabit Ethernet
>> Subsystem: Broadcom Corporation NetXtreme BCM5750M Gigabit Ethernet
>> 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 10
>> Region 0: Memory at f4100000 (64-bit, non-prefetchable) [size=64K]
>> Capabilities: [48] 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: [50] Vital Product Data
>> pcilib: sysfs_read_vpd: read failed: Connection timed out
>> Not readable
>> Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
>> Address: 5149526521410124 Data: 8b60
>> Capabilities: [d0] Express (v1) Endpoint, MSI 00
>> DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
>> 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 #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <4us, 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: [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: [13c v1] Virtual Channel
>> Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
>> Arb: Fixed- WRR32- WRR64- WRR128-
>> Ctrl: ArbSelect=Fixed
>> Status: InProgress-
>> VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
>> Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
>> Status: NegoPending- InProgress-
>> Capabilities: [160 v1] Device Serial Number 00-00-00-ff-fe-00-00-00
>>
>> Serial number is CND71700K6.
>> --
>> Best regards,
>> Francesco Piccinno
>>
>>
>>
>> On Fri, Sep 2, 2011 at 2:06 AM, Matt Carlson <mcarlson@broadcom.com> wrote:
>> > On Thu, Sep 01, 2011 at 04:40:11PM -0700, Andrew Morton wrote:
>> >>
>> >> (switched to email. ??Please respond via emailed reply-to-all, not via the
>> >> bugzilla web interface).
>> >>
>> >> On Wed, 31 Aug 2011 18:18:40 GMT
>> >> bugzilla-daemon@bugzilla.kernel.org wrote:
>> >>
>> >> > https://bugzilla.kernel.org/show_bug.cgi?id=42132
>> >> >
>> >> > ?? ?? ?? ?? ?? ??Summary: Support BCM5750M in tg3
>> >> > ?? ?? ?? ?? ?? ??Product: Drivers
>> >> > ?? ?? ?? ?? ?? ??Version: 2.5
>> >> > ?? ?? Kernel Version: 3.0.3
>> >> > ?? ?? ?? ?? ?? Platform: All
>> >> > ?? ?? ?? ?? OS/Version: Linux
>> >> > ?? ?? ?? ?? ?? ?? ?? Tree: Mainline
>> >> > ?? ?? ?? ?? ?? ?? Status: NEW
>> >> > ?? ?? ?? ?? ?? Severity: normal
>> >> > ?? ?? ?? ?? ?? Priority: P1
>> >> > ?? ?? ?? ?? ??Component: Network
>> >> > ?? ?? ?? ?? AssignedTo: drivers_network@kernel-bugs.osdl.org
>> >> > ?? ?? ?? ?? ReportedBy: stack.box@gmail.com
>> >> > ?? ?? ?? ?? Regression: Yes
>> >> >
>> >> >
>> >> > I have a notebook (HP TC4400) which has a BCM5750 ethernet card inside. The
>> >> > ouput of lspci is:
>> >> >
>> >> > 08:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5750M
>> >> > Gigabit Ethernet [14e4:167c]
>> >> >
>> >> > Commit 67b284d476bcb3d100e946da23d6cf9acfd0465c removed the support for this
>> >> > device.
>> >> >
>> >>
>> >> 67b284d476bcb3d100 says "These devices were never released to the public".
>> >>
>> >> > I wish to have the support for this network card back again. Thanks!
>> >>
>> >> oops ;)
>> >
>> > Really? ??All the TC4400 documentation I find says it uses a bcm5753M on a
>> > PCIe bus. ??Can you post the full output of 'lspci -vvv -s 08:00.0' ?
>> >
>> >
>>
>
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 42132] New: Support BCM5750M in tg3
From: Matt Carlson @ 2011-09-02 1:04 UTC (permalink / raw)
To: Francesco Piccinno
Cc: Matthew Carlson, Andrew Morton, netdev@vger.kernel.org,
bugme-daemon@bugzilla.kernel.org, Benjamin Li, Michael Chan
In-Reply-To: <CAA7bCn6DRmoqhHGBOAkaDqCdiYwrjPGuaYcck7n4+o3Lm10w2g@mail.gmail.com>
It's showing up on lspci as a PCIe device, so it can't be the 5750M.
The bcm5750M is a pci device.
I'm wondering if bootcode is failing. Do you see any messages in your
syslogs that say "No firmware running"?
Can you post the output of 'ethtool -i ethX'?
On Thu, Sep 01, 2011 at 05:48:50PM -0700, Francesco Piccinno wrote:
> Yes sure.
>
> # lspci -vvv -s 08:00.0
> 08:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5750M
> Gigabit Ethernet
> Subsystem: Broadcom Corporation NetXtreme BCM5750M Gigabit Ethernet
> 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 10
> Region 0: Memory at f4100000 (64-bit, non-prefetchable) [size=64K]
> Capabilities: [48] 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: [50] Vital Product Data
> pcilib: sysfs_read_vpd: read failed: Connection timed out
> Not readable
> Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
> Address: 5149526521410124 Data: 8b60
> Capabilities: [d0] Express (v1) Endpoint, MSI 00
> DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
> 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 #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <4us, 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: [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: [13c v1] Virtual Channel
> Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
> Arb: Fixed- WRR32- WRR64- WRR128-
> Ctrl: ArbSelect=Fixed
> Status: InProgress-
> VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
> Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
> Status: NegoPending- InProgress-
> Capabilities: [160 v1] Device Serial Number 00-00-00-ff-fe-00-00-00
>
> Serial number is CND71700K6.
> --
> Best regards,
> Francesco Piccinno
>
>
>
> On Fri, Sep 2, 2011 at 2:06 AM, Matt Carlson <mcarlson@broadcom.com> wrote:
> > On Thu, Sep 01, 2011 at 04:40:11PM -0700, Andrew Morton wrote:
> >>
> >> (switched to email. ??Please respond via emailed reply-to-all, not via the
> >> bugzilla web interface).
> >>
> >> On Wed, 31 Aug 2011 18:18:40 GMT
> >> bugzilla-daemon@bugzilla.kernel.org wrote:
> >>
> >> > https://bugzilla.kernel.org/show_bug.cgi?id=42132
> >> >
> >> > ?? ?? ?? ?? ?? ??Summary: Support BCM5750M in tg3
> >> > ?? ?? ?? ?? ?? ??Product: Drivers
> >> > ?? ?? ?? ?? ?? ??Version: 2.5
> >> > ?? ?? Kernel Version: 3.0.3
> >> > ?? ?? ?? ?? ?? Platform: All
> >> > ?? ?? ?? ?? OS/Version: Linux
> >> > ?? ?? ?? ?? ?? ?? ?? Tree: Mainline
> >> > ?? ?? ?? ?? ?? ?? Status: NEW
> >> > ?? ?? ?? ?? ?? Severity: normal
> >> > ?? ?? ?? ?? ?? Priority: P1
> >> > ?? ?? ?? ?? ??Component: Network
> >> > ?? ?? ?? ?? AssignedTo: drivers_network@kernel-bugs.osdl.org
> >> > ?? ?? ?? ?? ReportedBy: stack.box@gmail.com
> >> > ?? ?? ?? ?? Regression: Yes
> >> >
> >> >
> >> > I have a notebook (HP TC4400) which has a BCM5750 ethernet card inside. The
> >> > ouput of lspci is:
> >> >
> >> > 08:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5750M
> >> > Gigabit Ethernet [14e4:167c]
> >> >
> >> > Commit 67b284d476bcb3d100e946da23d6cf9acfd0465c removed the support for this
> >> > device.
> >> >
> >>
> >> 67b284d476bcb3d100 says "These devices were never released to the public".
> >>
> >> > I wish to have the support for this network card back again. Thanks!
> >>
> >> oops ;)
> >
> > Really? ??All the TC4400 documentation I find says it uses a bcm5753M on a
> > PCIe bus. ??Can you post the full output of 'lspci -vvv -s 08:00.0' ?
> >
> >
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 42132] New: Support BCM5750M in tg3
From: Francesco Piccinno @ 2011-09-02 0:48 UTC (permalink / raw)
To: Matt Carlson
Cc: Andrew Morton, netdev@vger.kernel.org,
bugme-daemon@bugzilla.kernel.org, Benjamin Li, Michael Chan
In-Reply-To: <20110902000646.GA4910@mcarlson.broadcom.com>
Yes sure.
# lspci -vvv -s 08:00.0
08:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5750M
Gigabit Ethernet
Subsystem: Broadcom Corporation NetXtreme BCM5750M Gigabit Ethernet
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 10
Region 0: Memory at f4100000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [48] 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: [50] Vital Product Data
pcilib: sysfs_read_vpd: read failed: Connection timed out
Not readable
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: 5149526521410124 Data: 8b60
Capabilities: [d0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
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 #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <4us, 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: [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: [13c v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 00-00-00-ff-fe-00-00-00
Serial number is CND71700K6.
--
Best regards,
Francesco Piccinno
On Fri, Sep 2, 2011 at 2:06 AM, Matt Carlson <mcarlson@broadcom.com> wrote:
> On Thu, Sep 01, 2011 at 04:40:11PM -0700, Andrew Morton wrote:
>>
>> (switched to email. Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Wed, 31 Aug 2011 18:18:40 GMT
>> bugzilla-daemon@bugzilla.kernel.org wrote:
>>
>> > https://bugzilla.kernel.org/show_bug.cgi?id=42132
>> >
>> > Summary: Support BCM5750M in tg3
>> > Product: Drivers
>> > Version: 2.5
>> > Kernel Version: 3.0.3
>> > Platform: All
>> > OS/Version: Linux
>> > Tree: Mainline
>> > Status: NEW
>> > Severity: normal
>> > Priority: P1
>> > Component: Network
>> > AssignedTo: drivers_network@kernel-bugs.osdl.org
>> > ReportedBy: stack.box@gmail.com
>> > Regression: Yes
>> >
>> >
>> > I have a notebook (HP TC4400) which has a BCM5750 ethernet card inside. The
>> > ouput of lspci is:
>> >
>> > 08:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5750M
>> > Gigabit Ethernet [14e4:167c]
>> >
>> > Commit 67b284d476bcb3d100e946da23d6cf9acfd0465c removed the support for this
>> > device.
>> >
>>
>> 67b284d476bcb3d100 says "These devices were never released to the public".
>>
>> > I wish to have the support for this network card back again. Thanks!
>>
>> oops ;)
>
> Really? All the TC4400 documentation I find says it uses a bcm5753M on a
> PCIe bus. Can you post the full output of 'lspci -vvv -s 08:00.0' ?
>
>
^ permalink raw reply
* Re: [next] unix stream crashes
From: Valdis.Kletnieks @ 2011-09-02 0:49 UTC (permalink / raw)
To: Jiri Slaby; +Cc: tim.c.chen, David S. Miller, ML netdev, LKML
In-Reply-To: <4E5FEF28.60406@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 714 bytes --]
On Thu, 01 Sep 2011 22:46:32 +0200, Jiri Slaby said:
> Hi,
>
> my box 100% crashes when booting. It's both in unix socket recv and send
> paths. I've reverted 0856a30409 (Scm: Remove unnecessary pid &
> credential references in Unix socket's send and receive path) and it
> seems to help.
>
> The oops:
> http://www.fi.muni.cz/~xslaby/sklad/panics/af_unix_crash.png
I was seeing a 100% repeatable crash with the X server starting as well, but
wasn't able to get a traceback because my X server was doing the modeset before
it crashed (so all I got was a black screen) and netconsole is busticated for
me. I can confirm that reverting that one commit allows my box to boot and get
X up and running as well.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* [PATCH 2/3] pch_gbe: added the process of FIFO over run error
From: Toshiharu Okada @ 2011-09-02 0:20 UTC (permalink / raw)
To: netdev, linux-kernel, eric.dumazet, davem
Cc: qi.wang, yong.y.wang, joel.clark, kok.howg.ewe, tomoya-linux,
Toshiharu Okada
In-Reply-To: <1314922809-4041-1-git-send-email-toshiharu-linux@dsn.okisemi.com>
This patch added the processing which should be done to hardware,
when a FIFO over run error occurred.
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
---
drivers/net/pch_gbe/pch_gbe.h | 12 ++-
drivers/net/pch_gbe/pch_gbe_main.c | 273 ++++++++++++++++++++++--------------
2 files changed, 180 insertions(+), 105 deletions(-)
diff --git a/drivers/net/pch_gbe/pch_gbe.h b/drivers/net/pch_gbe/pch_gbe.h
index 59fac77..a09a071 100644
--- a/drivers/net/pch_gbe/pch_gbe.h
+++ b/drivers/net/pch_gbe/pch_gbe.h
@@ -127,8 +127,8 @@ struct pch_gbe_regs {
/* Reset */
#define PCH_GBE_ALL_RST 0x80000000 /* All reset */
-#define PCH_GBE_TX_RST 0x40000000 /* TX MAC, TX FIFO, TX DMA reset */
-#define PCH_GBE_RX_RST 0x04000000 /* RX MAC, RX FIFO, RX DMA reset */
+#define PCH_GBE_TX_RST 0x00008000 /* TX MAC, TX FIFO, TX DMA reset */
+#define PCH_GBE_RX_RST 0x00004000 /* RX MAC, RX FIFO, RX DMA reset */
/* TCP/IP Accelerator Control */
#define PCH_GBE_EX_LIST_EN 0x00000008 /* External List Enable */
@@ -276,6 +276,9 @@ struct pch_gbe_regs {
#define PCH_GBE_RX_DMA_EN 0x00000002 /* Enables Receive DMA */
#define PCH_GBE_TX_DMA_EN 0x00000001 /* Enables Transmission DMA */
+/* RX DMA STATUS */
+#define PCH_GBE_IDLE_CHECK 0xFFFFFFFE
+
/* Wake On LAN Status */
#define PCH_GBE_WLS_BR 0x00000008 /* Broadcas Address */
#define PCH_GBE_WLS_MLT 0x00000004 /* Multicast Address */
@@ -471,6 +474,7 @@ struct pch_gbe_tx_desc {
struct pch_gbe_buffer {
struct sk_buff *skb;
dma_addr_t dma;
+ unsigned char *rx_buffer;
unsigned long time_stamp;
u16 length;
bool mapped;
@@ -511,6 +515,9 @@ struct pch_gbe_tx_ring {
struct pch_gbe_rx_ring {
struct pch_gbe_rx_desc *desc;
dma_addr_t dma;
+ unsigned char *rx_buff_pool;
+ dma_addr_t rx_buff_pool_logic;
+ unsigned int rx_buff_pool_size;
unsigned int size;
unsigned int count;
unsigned int next_to_use;
@@ -622,6 +629,7 @@ struct pch_gbe_adapter {
unsigned long rx_buffer_len;
unsigned long tx_queue_len;
bool have_msi;
+ bool rx_stop_flag;
};
extern const char pch_driver_version[];
diff --git a/drivers/net/pch_gbe/pch_gbe_main.c b/drivers/net/pch_gbe/pch_gbe_main.c
index 48ff87c..39ce0ee 100644
--- a/drivers/net/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/pch_gbe/pch_gbe_main.c
@@ -20,7 +20,6 @@
#include "pch_gbe.h"
#include "pch_gbe_api.h"
-#include <linux/prefetch.h>
#define DRV_VERSION "1.00"
const char pch_driver_version[] = DRV_VERSION;
@@ -34,6 +33,7 @@ const char pch_driver_version[] = DRV_VERSION;
#define PCH_GBE_WATCHDOG_PERIOD (1 * HZ) /* watchdog time */
#define PCH_GBE_COPYBREAK_DEFAULT 256
#define PCH_GBE_PCI_BAR 1
+#define PCH_GBE_RESERVE_MEMORY 0x200000 /* 2MB */
/* Macros for ML7223 */
#define PCI_VENDOR_ID_ROHM 0x10db
@@ -52,6 +52,7 @@ const char pch_driver_version[] = DRV_VERSION;
)
/* Ethertype field values */
+#define PCH_GBE_MAX_RX_BUFFER_SIZE 0x2880
#define PCH_GBE_MAX_JUMBO_FRAME_SIZE 10318
#define PCH_GBE_FRAME_SIZE_2048 2048
#define PCH_GBE_FRAME_SIZE_4096 4096
@@ -83,10 +84,12 @@ const char pch_driver_version[] = DRV_VERSION;
#define PCH_GBE_INT_ENABLE_MASK ( \
PCH_GBE_INT_RX_DMA_CMPLT | \
PCH_GBE_INT_RX_DSC_EMP | \
+ PCH_GBE_INT_RX_FIFO_ERR | \
PCH_GBE_INT_WOL_DET | \
PCH_GBE_INT_TX_CMPLT \
)
+#define PCH_GBE_INT_DISABLE_ALL 0
static unsigned int copybreak __read_mostly = PCH_GBE_COPYBREAK_DEFAULT;
@@ -138,6 +141,27 @@ static void pch_gbe_wait_clr_bit(void *reg, u32 bit)
if (!tmp)
pr_err("Error: busy bit is not cleared\n");
}
+
+/**
+ * pch_gbe_wait_clr_bit_irq - Wait to clear a bit for interrupt context
+ * @reg: Pointer of register
+ * @busy: Busy bit
+ */
+static int pch_gbe_wait_clr_bit_irq(void *reg, u32 bit)
+{
+ u32 tmp;
+ int ret = -1;
+ /* wait busy */
+ tmp = 20;
+ while ((ioread32(reg) & bit) && --tmp)
+ udelay(5);
+ if (!tmp)
+ pr_err("Error: busy bit is not cleared\n");
+ else
+ ret = 0;
+ return ret;
+}
+
/**
* pch_gbe_mac_mar_set - Set MAC address register
* @hw: Pointer to the HW structure
@@ -189,6 +213,17 @@ static void pch_gbe_mac_reset_hw(struct pch_gbe_hw *hw)
return;
}
+static void pch_gbe_mac_reset_rx(struct pch_gbe_hw *hw)
+{
+ /* Read the MAC address. and store to the private data */
+ pch_gbe_mac_read_mac_addr(hw);
+ iowrite32(PCH_GBE_RX_RST, &hw->reg->RESET);
+ pch_gbe_wait_clr_bit_irq(&hw->reg->RESET, PCH_GBE_RX_RST);
+ /* Setup the MAC address */
+ pch_gbe_mac_mar_set(hw, hw->mac.addr, 0);
+ return;
+}
+
/**
* pch_gbe_mac_init_rx_addrs - Initialize receive address's
* @hw: Pointer to the HW structure
@@ -671,13 +706,8 @@ static void pch_gbe_setup_rctl(struct pch_gbe_adapter *adapter)
tcpip = ioread32(&hw->reg->TCPIP_ACC);
- if (netdev->features & NETIF_F_RXCSUM) {
- tcpip &= ~PCH_GBE_RX_TCPIPACC_OFF;
- tcpip |= PCH_GBE_RX_TCPIPACC_EN;
- } else {
- tcpip |= PCH_GBE_RX_TCPIPACC_OFF;
- tcpip &= ~PCH_GBE_RX_TCPIPACC_EN;
- }
+ tcpip |= PCH_GBE_RX_TCPIPACC_OFF;
+ tcpip &= ~PCH_GBE_RX_TCPIPACC_EN;
iowrite32(tcpip, &hw->reg->TCPIP_ACC);
return;
}
@@ -1090,6 +1120,35 @@ void pch_gbe_update_stats(struct pch_gbe_adapter *adapter)
spin_unlock_irqrestore(&adapter->stats_lock, flags);
}
+static void pch_gbe_stop_receive(struct pch_gbe_adapter *adapter)
+{
+ struct pch_gbe_hw *hw = &adapter->hw;
+ u32 rxdma;
+ u16 value;
+ int ret;
+
+ /* Disable Receive DMA */
+ rxdma = ioread32(&hw->reg->DMA_CTRL);
+ rxdma &= ~PCH_GBE_RX_DMA_EN;
+ iowrite32(rxdma, &hw->reg->DMA_CTRL);
+ /* Wait Rx DMA BUS is IDLE */
+ ret = pch_gbe_wait_clr_bit_irq(&hw->reg->RX_DMA_ST, PCH_GBE_IDLE_CHECK);
+ if (ret) {
+ /* Disable Bus master */
+ pci_read_config_word(adapter->pdev, PCI_COMMAND, &value);
+ value &= ~PCI_COMMAND_MASTER;
+ pci_write_config_word(adapter->pdev, PCI_COMMAND, value);
+ /* Stop Receive */
+ pch_gbe_mac_reset_rx(hw);
+ /* Enable Bus master */
+ value |= PCI_COMMAND_MASTER;
+ pci_write_config_word(adapter->pdev, PCI_COMMAND, value);
+ } else {
+ /* Stop Receive */
+ pch_gbe_mac_reset_rx(hw);
+ }
+}
+
static void pch_gbe_start_receive(struct pch_gbe_hw *hw)
{
u32 rxdma;
@@ -1129,7 +1188,15 @@ static irqreturn_t pch_gbe_intr(int irq, void *data)
if (int_st & PCH_GBE_INT_RX_FRAME_ERR)
adapter->stats.intr_rx_frame_err_count++;
if (int_st & PCH_GBE_INT_RX_FIFO_ERR)
- adapter->stats.intr_rx_fifo_err_count++;
+ if (!adapter->rx_stop_flag) {
+ adapter->stats.intr_rx_fifo_err_count++;
+ pr_debug("Rx fifo over run\n");
+ adapter->rx_stop_flag = true;
+ int_en = ioread32(&hw->reg->INT_EN);
+ iowrite32((int_en & ~PCH_GBE_INT_RX_FIFO_ERR),
+ &hw->reg->INT_EN);
+ pch_gbe_stop_receive(adapter);
+ }
if (int_st & PCH_GBE_INT_RX_DMA_ERR)
adapter->stats.intr_rx_dma_err_count++;
if (int_st & PCH_GBE_INT_TX_FIFO_ERR)
@@ -1141,7 +1208,7 @@ static irqreturn_t pch_gbe_intr(int irq, void *data)
/* When Rx descriptor is empty */
if ((int_st & PCH_GBE_INT_RX_DSC_EMP)) {
adapter->stats.intr_rx_dsc_empty_count++;
- pr_err("Rx descriptor is empty\n");
+ pr_debug("Rx descriptor is empty\n");
int_en = ioread32(&hw->reg->INT_EN);
iowrite32((int_en & ~PCH_GBE_INT_RX_DSC_EMP), &hw->reg->INT_EN);
if (hw->mac.tx_fc_enable) {
@@ -1191,29 +1258,23 @@ pch_gbe_alloc_rx_buffers(struct pch_gbe_adapter *adapter,
unsigned int i;
unsigned int bufsz;
- bufsz = adapter->rx_buffer_len + PCH_GBE_DMA_ALIGN;
+ bufsz = adapter->rx_buffer_len + NET_IP_ALIGN;
i = rx_ring->next_to_use;
while ((cleaned_count--)) {
buffer_info = &rx_ring->buffer_info[i];
- skb = buffer_info->skb;
- if (skb) {
- skb_trim(skb, 0);
- } else {
- skb = netdev_alloc_skb(netdev, bufsz);
- if (unlikely(!skb)) {
- /* Better luck next round */
- adapter->stats.rx_alloc_buff_failed++;
- break;
- }
- /* 64byte align */
- skb_reserve(skb, PCH_GBE_DMA_ALIGN);
-
- buffer_info->skb = skb;
- buffer_info->length = adapter->rx_buffer_len;
+ skb = netdev_alloc_skb(netdev, bufsz);
+ if (unlikely(!skb)) {
+ /* Better luck next round */
+ adapter->stats.rx_alloc_buff_failed++;
+ break;
}
+ /* align */
+ skb_reserve(skb, NET_IP_ALIGN);
+ buffer_info->skb = skb;
+
buffer_info->dma = dma_map_single(&pdev->dev,
- skb->data,
+ buffer_info->rx_buffer,
buffer_info->length,
DMA_FROM_DEVICE);
if (dma_mapping_error(&adapter->pdev->dev, buffer_info->dma)) {
@@ -1246,6 +1307,36 @@ pch_gbe_alloc_rx_buffers(struct pch_gbe_adapter *adapter,
return;
}
+static int
+pch_gbe_alloc_rx_buffers_pool(struct pch_gbe_adapter *adapter,
+ struct pch_gbe_rx_ring *rx_ring, int cleaned_count)
+{
+ struct pci_dev *pdev = adapter->pdev;
+ struct pch_gbe_buffer *buffer_info;
+ unsigned int i;
+ unsigned int bufsz;
+ unsigned int size;
+
+ bufsz = adapter->rx_buffer_len;
+
+ size = rx_ring->count * bufsz + PCH_GBE_RESERVE_MEMORY;
+ rx_ring->rx_buff_pool = dma_alloc_coherent(&pdev->dev, size,
+ &rx_ring->rx_buff_pool_logic,
+ GFP_KERNEL);
+ if (!rx_ring->rx_buff_pool) {
+ pr_err("Unable to allocate memory for the receive poll buffer\n");
+ return -ENOMEM;
+ }
+ memset(rx_ring->rx_buff_pool, 0, size);
+ rx_ring->rx_buff_pool_size = size;
+ for (i = 0; i < rx_ring->count; i++) {
+ buffer_info = &rx_ring->buffer_info[i];
+ buffer_info->rx_buffer = rx_ring->rx_buff_pool + bufsz * i;
+ buffer_info->length = bufsz;
+ }
+ return 0;
+}
+
/**
* pch_gbe_alloc_tx_buffers - Allocate transmit buffers
* @adapter: Board private structure
@@ -1386,7 +1477,7 @@ pch_gbe_clean_rx(struct pch_gbe_adapter *adapter,
unsigned int i;
unsigned int cleaned_count = 0;
bool cleaned = false;
- struct sk_buff *skb, *new_skb;
+ struct sk_buff *skb;
u8 dma_status;
u16 gbec_status;
u32 tcp_ip_status;
@@ -1407,13 +1498,12 @@ pch_gbe_clean_rx(struct pch_gbe_adapter *adapter,
rx_desc->gbec_status = DSC_INIT16;
buffer_info = &rx_ring->buffer_info[i];
skb = buffer_info->skb;
+ buffer_info->skb = NULL;
/* unmap dma */
dma_unmap_single(&pdev->dev, buffer_info->dma,
buffer_info->length, DMA_FROM_DEVICE);
buffer_info->mapped = false;
- /* Prefetch the packet */
- prefetch(skb->data);
pr_debug("RxDecNo = 0x%04x Status[DMA:0x%02x GBE:0x%04x "
"TCP:0x%08x] BufInf = 0x%p\n",
@@ -1433,70 +1523,16 @@ pch_gbe_clean_rx(struct pch_gbe_adapter *adapter,
pr_err("Receive CRC Error\n");
} else {
/* get receive length */
- /* length convert[-3] */
- length = (rx_desc->rx_words_eob) - 3;
-
- /* Decide the data conversion method */
- if (!(netdev->features & NETIF_F_RXCSUM)) {
- /* [Header:14][payload] */
- if (NET_IP_ALIGN) {
- /* Because alignment differs,
- * the new_skb is newly allocated,
- * and data is copied to new_skb.*/
- new_skb = netdev_alloc_skb(netdev,
- length + NET_IP_ALIGN);
- if (!new_skb) {
- /* dorrop error */
- pr_err("New skb allocation "
- "Error\n");
- goto dorrop;
- }
- skb_reserve(new_skb, NET_IP_ALIGN);
- memcpy(new_skb->data, skb->data,
- length);
- skb = new_skb;
- } else {
- /* DMA buffer is used as SKB as it is.*/
- buffer_info->skb = NULL;
- }
- } else {
- /* [Header:14][padding:2][payload] */
- /* The length includes padding length */
- length = length - PCH_GBE_DMA_PADDING;
- if ((length < copybreak) ||
- (NET_IP_ALIGN != PCH_GBE_DMA_PADDING)) {
- /* Because alignment differs,
- * the new_skb is newly allocated,
- * and data is copied to new_skb.
- * Padding data is deleted
- * at the time of a copy.*/
- new_skb = netdev_alloc_skb(netdev,
- length + NET_IP_ALIGN);
- if (!new_skb) {
- /* dorrop error */
- pr_err("New skb allocation "
- "Error\n");
- goto dorrop;
- }
- skb_reserve(new_skb, NET_IP_ALIGN);
- memcpy(new_skb->data, skb->data,
- ETH_HLEN);
- memcpy(&new_skb->data[ETH_HLEN],
- &skb->data[ETH_HLEN +
- PCH_GBE_DMA_PADDING],
- length - ETH_HLEN);
- skb = new_skb;
- } else {
- /* Padding data is deleted
- * by moving header data.*/
- memmove(&skb->data[PCH_GBE_DMA_PADDING],
- &skb->data[0], ETH_HLEN);
- skb_reserve(skb, NET_IP_ALIGN);
- buffer_info->skb = NULL;
- }
- }
- /* The length includes FCS length */
- length = length - ETH_FCS_LEN;
+ /* length convert[-3], length includes FCS length */
+ length = (rx_desc->rx_words_eob) - 3 - ETH_FCS_LEN;
+ if (rx_desc->rx_words_eob & 0x02)
+ length = length - 4;
+ /*
+ * buffer_info->rx_buffer: [Header:14][payload]
+ * skb->data: [Reserve:2][Header:14][payload]
+ */
+ memcpy(skb->data, buffer_info->rx_buffer, length);
+
/* update status of driver */
adapter->stats.rx_bytes += length;
adapter->stats.rx_packets++;
@@ -1515,7 +1551,6 @@ pch_gbe_clean_rx(struct pch_gbe_adapter *adapter,
pr_debug("Receive skb->ip_summed: %d length: %d\n",
skb->ip_summed, length);
}
-dorrop:
/* return some buffers to hardware, one at a time is too slow */
if (unlikely(cleaned_count >= PCH_GBE_RX_BUFFER_WRITE)) {
pch_gbe_alloc_rx_buffers(adapter, rx_ring,
@@ -1720,6 +1755,11 @@ int pch_gbe_up(struct pch_gbe_adapter *adapter)
pr_err("Error: can't bring device up\n");
return err;
}
+ err = pch_gbe_alloc_rx_buffers_pool(adapter, rx_ring, rx_ring->count);
+ if (err) {
+ pr_err("Error: can't bring device up\n");
+ return err;
+ }
pch_gbe_alloc_tx_buffers(adapter, tx_ring);
pch_gbe_alloc_rx_buffers(adapter, rx_ring, rx_ring->count);
adapter->tx_queue_len = netdev->tx_queue_len;
@@ -1741,6 +1781,7 @@ int pch_gbe_up(struct pch_gbe_adapter *adapter)
void pch_gbe_down(struct pch_gbe_adapter *adapter)
{
struct net_device *netdev = adapter->netdev;
+ struct pch_gbe_rx_ring *rx_ring = adapter->rx_ring;
/* signal that we're down so the interrupt handler does not
* reschedule our watchdog timer */
@@ -1759,6 +1800,12 @@ void pch_gbe_down(struct pch_gbe_adapter *adapter)
pch_gbe_reset(adapter);
pch_gbe_clean_tx_ring(adapter, adapter->tx_ring);
pch_gbe_clean_rx_ring(adapter, adapter->rx_ring);
+
+ pci_free_consistent(adapter->pdev, rx_ring->rx_buff_pool_size,
+ rx_ring->rx_buff_pool, rx_ring->rx_buff_pool_logic);
+ rx_ring->rx_buff_pool_logic = 0;
+ rx_ring->rx_buff_pool_size = 0;
+ rx_ring->rx_buff_pool = NULL;
}
/**
@@ -2011,6 +2058,8 @@ static int pch_gbe_change_mtu(struct net_device *netdev, int new_mtu)
{
struct pch_gbe_adapter *adapter = netdev_priv(netdev);
int max_frame;
+ unsigned long old_rx_buffer_len = adapter->rx_buffer_len;
+ int err;
max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
if ((max_frame < ETH_ZLEN + ETH_FCS_LEN) ||
@@ -2025,14 +2074,24 @@ static int pch_gbe_change_mtu(struct net_device *netdev, int new_mtu)
else if (max_frame <= PCH_GBE_FRAME_SIZE_8192)
adapter->rx_buffer_len = PCH_GBE_FRAME_SIZE_8192;
else
- adapter->rx_buffer_len = PCH_GBE_MAX_JUMBO_FRAME_SIZE;
- netdev->mtu = new_mtu;
- adapter->hw.mac.max_frame_size = max_frame;
+ adapter->rx_buffer_len = PCH_GBE_MAX_RX_BUFFER_SIZE;
- if (netif_running(netdev))
- pch_gbe_reinit_locked(adapter);
- else
+ if (netif_running(netdev)) {
+ pch_gbe_down(adapter);
+ err = pch_gbe_up(adapter);
+ if (err) {
+ adapter->rx_buffer_len = old_rx_buffer_len;
+ pch_gbe_up(adapter);
+ return -ENOMEM;
+ } else {
+ netdev->mtu = new_mtu;
+ adapter->hw.mac.max_frame_size = max_frame;
+ }
+ } else {
pch_gbe_reset(adapter);
+ netdev->mtu = new_mtu;
+ adapter->hw.mac.max_frame_size = max_frame;
+ }
pr_debug("max_frame : %d rx_buffer_len : %d mtu : %d max_frame_size : %d\n",
max_frame, (u32) adapter->rx_buffer_len, netdev->mtu,
@@ -2110,6 +2169,7 @@ static int pch_gbe_napi_poll(struct napi_struct *napi, int budget)
int work_done = 0;
bool poll_end_flag = false;
bool cleaned = false;
+ u32 int_en;
pr_debug("budget : %d\n", budget);
@@ -2117,8 +2177,15 @@ static int pch_gbe_napi_poll(struct napi_struct *napi, int budget)
if (!netif_carrier_ok(netdev)) {
poll_end_flag = true;
} else {
- cleaned = pch_gbe_clean_tx(adapter, adapter->tx_ring);
pch_gbe_clean_rx(adapter, adapter->rx_ring, &work_done, budget);
+ if (adapter->rx_stop_flag) {
+ adapter->rx_stop_flag = false;
+ pch_gbe_start_receive(&adapter->hw);
+ int_en = ioread32(&adapter->hw.reg->INT_EN);
+ iowrite32((int_en | PCH_GBE_INT_RX_FIFO_ERR),
+ &adapter->hw.reg->INT_EN);
+ }
+ cleaned = pch_gbe_clean_tx(adapter, adapter->tx_ring);
if (cleaned)
work_done = budget;
--
1.7.4.4
^ permalink raw reply related
* [PATCH 3/3] pch_gbe: support ML7831 IOH
From: Toshiharu Okada @ 2011-09-02 0:20 UTC (permalink / raw)
To: netdev, linux-kernel, eric.dumazet, davem
Cc: qi.wang, yong.y.wang, joel.clark, kok.howg.ewe, tomoya-linux,
Toshiharu Okada
In-Reply-To: <1314922809-4041-1-git-send-email-toshiharu-linux@dsn.okisemi.com>
Support new device OKI SEMICONDUCTOR ML7831 IOH(Input/Output Hub)
ML7831 is for general purpose use.
ML7831 is companion chip for Intel Atom E6xx series.
ML7831 is completely compatible for Intel EG20T PCH.
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
---
drivers/net/Kconfig | 11 ++++++-----
drivers/net/pch_gbe/pch_gbe_main.c | 10 ++++++++++
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 8d0314d..a44874e 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2535,7 +2535,7 @@ config S6GMAC
source "drivers/net/stmmac/Kconfig"
config PCH_GBE
- tristate "Intel EG20T PCH / OKI SEMICONDUCTOR ML7223 IOH GbE"
+ tristate "Intel EG20T PCH/OKI SEMICONDUCTOR IOH(ML7223/ML7831) GbE"
depends on PCI
select MII
---help---
@@ -2548,10 +2548,11 @@ config PCH_GBE
This driver enables Gigabit Ethernet function.
This driver also can be used for OKI SEMICONDUCTOR IOH(Input/
- Output Hub), ML7223.
- ML7223 IOH is for MP(Media Phone) use.
- ML7223 is companion chip for Intel Atom E6xx series.
- ML7223 is completely compatible for Intel EG20T PCH.
+ Output Hub), ML7223/ML7831.
+ ML7223 IOH is for MP(Media Phone) use. ML7831 IOH is for general
+ purpose use.
+ ML7223/ML7831 is companion chip for Intel Atom E6xx series.
+ ML7223/ML7831 is completely compatible for Intel EG20T PCH.
config FTGMAC100
tristate "Faraday FTGMAC100 Gigabit Ethernet support"
diff --git a/drivers/net/pch_gbe/pch_gbe_main.c b/drivers/net/pch_gbe/pch_gbe_main.c
index 39ce0ee..567ff10 100644
--- a/drivers/net/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/pch_gbe/pch_gbe_main.c
@@ -39,6 +39,9 @@ const char pch_driver_version[] = DRV_VERSION;
#define PCI_VENDOR_ID_ROHM 0x10db
#define PCI_DEVICE_ID_ROHM_ML7223_GBE 0x8013
+/* Macros for ML7831 */
+#define PCI_DEVICE_ID_ROHM_ML7831_GBE 0x8802
+
#define PCH_GBE_TX_WEIGHT 64
#define PCH_GBE_RX_WEIGHT 64
#define PCH_GBE_RX_BUFFER_WRITE 16
@@ -2526,6 +2529,13 @@ static DEFINE_PCI_DEVICE_TABLE(pch_gbe_pcidev_id) = {
.class = (PCI_CLASS_NETWORK_ETHERNET << 8),
.class_mask = (0xFFFF00)
},
+ {.vendor = PCI_VENDOR_ID_ROHM,
+ .device = PCI_DEVICE_ID_ROHM_ML7831_GBE,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .class = (PCI_CLASS_NETWORK_ETHERNET << 8),
+ .class_mask = (0xFFFF00)
+ },
/* required last entry */
{0}
};
--
1.7.4.4
^ permalink raw reply related
* [PATCH 1/3] pch_gbe: fixed the issue which receives an unnecessary packet.
From: Toshiharu Okada @ 2011-09-02 0:20 UTC (permalink / raw)
To: netdev, linux-kernel, eric.dumazet, davem
Cc: qi.wang, yong.y.wang, joel.clark, kok.howg.ewe, tomoya-linux,
Toshiharu Okada
This patch fixed the issue which receives an unnecessary packet before link
When using PHY of GMII, an unnecessary packet is received,
And it becomes impossible to receive a packet after link up.
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
---
drivers/net/pch_gbe/pch_gbe_main.c | 21 ++++++++++++++-------
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/net/pch_gbe/pch_gbe_main.c b/drivers/net/pch_gbe/pch_gbe_main.c
index eac3c5c..48ff87c 100644
--- a/drivers/net/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/pch_gbe/pch_gbe_main.c
@@ -717,13 +717,6 @@ static void pch_gbe_configure_rx(struct pch_gbe_adapter *adapter)
iowrite32(rdba, &hw->reg->RX_DSC_BASE);
iowrite32(rdlen, &hw->reg->RX_DSC_SIZE);
iowrite32((rdba + rdlen), &hw->reg->RX_DSC_SW_P);
-
- /* Enables Receive DMA */
- rxdma = ioread32(&hw->reg->DMA_CTRL);
- rxdma |= PCH_GBE_RX_DMA_EN;
- iowrite32(rxdma, &hw->reg->DMA_CTRL);
- /* Enables Receive */
- iowrite32(PCH_GBE_MRE_MAC_RX_EN, &hw->reg->MAC_RX_EN);
}
/**
@@ -1097,6 +1090,19 @@ void pch_gbe_update_stats(struct pch_gbe_adapter *adapter)
spin_unlock_irqrestore(&adapter->stats_lock, flags);
}
+static void pch_gbe_start_receive(struct pch_gbe_hw *hw)
+{
+ u32 rxdma;
+
+ /* Enables Receive DMA */
+ rxdma = ioread32(&hw->reg->DMA_CTRL);
+ rxdma |= PCH_GBE_RX_DMA_EN;
+ iowrite32(rxdma, &hw->reg->DMA_CTRL);
+ /* Enables Receive */
+ iowrite32(PCH_GBE_MRE_MAC_RX_EN, &hw->reg->MAC_RX_EN);
+ return;
+}
+
/**
* pch_gbe_intr - Interrupt Handler
* @irq: Interrupt number
@@ -1717,6 +1723,7 @@ int pch_gbe_up(struct pch_gbe_adapter *adapter)
pch_gbe_alloc_tx_buffers(adapter, tx_ring);
pch_gbe_alloc_rx_buffers(adapter, rx_ring, rx_ring->count);
adapter->tx_queue_len = netdev->tx_queue_len;
+ pch_gbe_start_receive(&adapter->hw);
mod_timer(&adapter->watchdog_timer, jiffies);
--
1.7.4.4
^ permalink raw reply related
* Re: interface information for recvd packet
From: Viral Mehta @ 2011-09-02 0:07 UTC (permalink / raw)
To: netdev
In-Reply-To: <CANX6Dan5bdA-3wSiyAaQmOV6DHArxjknUFpR-s8coA9Yjx2N8A@mail.gmail.com>
Hi,
On Thu, Sep 1, 2011 at 3:40 PM, Viral Mehta <viral.vkm@gmail.com> wrote:
> On Tue, Aug 30, 2011 at 11:55 AM, Viral Mehta <viral.vkm@gmail.com> wrote:
>> 2. I was looking at net/ipv4/tcp.c and in function tcp_recvmsg(); I am
>> trying to get interface name by accessing sk_buff->dev->name
>
> I tried printing address of SKBs, but it gives different address in
> NIC driver and tcp.c
> My understanding is, struct sk_buff* remains same through out all
> layers i.e., NIC driver allocates it after receving frame
> and same is passed till TCP layer. But, apparently looks I am wrong
> from the prints that I have put.
>
> Can someone shed some light ?
>
Sorry for the noise. Also I got why nobody replied to my question :-)
Anyway, I was doing silly mistake while debugging the things; my
printks were at wrong place.
And everything works as expected and as per my understanding....
^ permalink raw reply
* Re: [Bugme-new] [Bug 42132] New: Support BCM5750M in tg3
From: Matt Carlson @ 2011-09-02 0:06 UTC (permalink / raw)
To: Andrew Morton
Cc: netdev@vger.kernel.org, Matthew Carlson,
bugme-daemon@bugzilla.kernel.org, Benjamin Li, Michael Chan,
stack.box@gmail.com
In-Reply-To: <20110901164011.baa9a8b8.akpm@linux-foundation.org>
On Thu, Sep 01, 2011 at 04:40:11PM -0700, Andrew Morton wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Wed, 31 Aug 2011 18:18:40 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
> > https://bugzilla.kernel.org/show_bug.cgi?id=42132
> >
> > Summary: Support BCM5750M in tg3
> > Product: Drivers
> > Version: 2.5
> > Kernel Version: 3.0.3
> > Platform: All
> > OS/Version: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: normal
> > Priority: P1
> > Component: Network
> > AssignedTo: drivers_network@kernel-bugs.osdl.org
> > ReportedBy: stack.box@gmail.com
> > Regression: Yes
> >
> >
> > I have a notebook (HP TC4400) which has a BCM5750 ethernet card inside. The
> > ouput of lspci is:
> >
> > 08:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5750M
> > Gigabit Ethernet [14e4:167c]
> >
> > Commit 67b284d476bcb3d100e946da23d6cf9acfd0465c removed the support for this
> > device.
> >
>
> 67b284d476bcb3d100 says "These devices were never released to the public".
>
> > I wish to have the support for this network card back again. Thanks!
>
> oops ;)
Really? All the TC4400 documentation I find says it uses a bcm5753M on a
PCIe bus. Can you post the full output of 'lspci -vvv -s 08:00.0' ?
^ permalink raw reply
* Re: [Bugme-new] [Bug 42132] New: Support BCM5750M in tg3
From: Francesco Piccinno @ 2011-09-02 0:02 UTC (permalink / raw)
To: Andrew Morton
Cc: netdev, Matt Carlson, bugme-daemon, Benjamin Li, Michael Chan
In-Reply-To: <20110901164011.baa9a8b8.akpm@linux-foundation.org>
I know but apparently my laptop was lucky enough :)
Any chance to have the support for this card back?
On Fri, Sep 2, 2011 at 1:40 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Wed, 31 Aug 2011 18:18:40 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=42132
>>
>> Summary: Support BCM5750M in tg3
>> Product: Drivers
>> Version: 2.5
>> Kernel Version: 3.0.3
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: Network
>> AssignedTo: drivers_network@kernel-bugs.osdl.org
>> ReportedBy: stack.box@gmail.com
>> Regression: Yes
>>
>>
>> I have a notebook (HP TC4400) which has a BCM5750 ethernet card inside. The
>> ouput of lspci is:
>>
>> 08:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5750M
>> Gigabit Ethernet [14e4:167c]
>>
>> Commit 67b284d476bcb3d100e946da23d6cf9acfd0465c removed the support for this
>> device.
>>
>
> 67b284d476bcb3d100 says "These devices were never released to the public".
>
>> I wish to have the support for this network card back again. Thanks!
>
> oops ;)
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 42132] New: Support BCM5750M in tg3
From: Andrew Morton @ 2011-09-01 23:40 UTC (permalink / raw)
To: netdev, Matt Carlson; +Cc: bugme-daemon, Benjamin Li, Michael Chan, stack.box
In-Reply-To: <bug-42132-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 31 Aug 2011 18:18:40 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=42132
>
> Summary: Support BCM5750M in tg3
> Product: Drivers
> Version: 2.5
> Kernel Version: 3.0.3
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: stack.box@gmail.com
> Regression: Yes
>
>
> I have a notebook (HP TC4400) which has a BCM5750 ethernet card inside. The
> ouput of lspci is:
>
> 08:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5750M
> Gigabit Ethernet [14e4:167c]
>
> Commit 67b284d476bcb3d100e946da23d6cf9acfd0465c removed the support for this
> device.
>
67b284d476bcb3d100 says "These devices were never released to the public".
> I wish to have the support for this network card back again. Thanks!
oops ;)
^ permalink raw reply
* Re: [PATCH] iPhone 4 Verizon CDMA USB Product ID add
From: David Miller @ 2011-09-01 22:10 UTC (permalink / raw)
To: kavansmith82-Re5JQEeQqe8AvxtiuMwx3w
Cc: gregkh-l3A5Bk7waGM, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1314914492-11542-1-git-send-email-kavansmith82-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Kavan Smith <kavansmith82-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 1 Sep 2011 15:01:32 -0700
> Add USB product ID for iPhone 4 CDMA Verizon
> Tested on at least 2 devices
>
> Signed-off-by: Kavan Smith <kavansmith82-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
I've seen your previous submission already, you don't need
to send this again.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net 2/2] sfc: Use 64-bit writes for TX push where possible
From: Ben Hutchings @ 2011-09-01 22:09 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
This was originally done as part of commit
65f0b417dee94f779ce9b77102b7d73c93723b39 ("sfc: Use write-combining to
reduce TX latency"), but that had to be reverted.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/io.h | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/sfc/io.h b/drivers/net/sfc/io.h
index dc45110..751d1ec 100644
--- a/drivers/net/sfc/io.h
+++ b/drivers/net/sfc/io.h
@@ -48,9 +48,9 @@
* replacing the low 96 bits with zero does not affect functionality.
* - If the host writes to the last dword address of such a register
* (i.e. the high 32 bits) the underlying register will always be
- * written. If the collector does not hold values for the low 96
- * bits of the register, they will be written as zero. Writing to
- * the last qword does not have this effect and must not be done.
+ * written. If the collector and the current write together do not
+ * provide values for all 128 bits of the register, the low 96 bits
+ * will be written as zero.
* - If the host writes to the address of any other part of such a
* register while the collector already holds values for some other
* register, the write is discarded and the collector maintains its
@@ -237,12 +237,13 @@ static inline void _efx_writeo_page(struct efx_nic *efx, efx_oword_t *value,
#ifdef EFX_USE_QWORD_IO
_efx_writeq(efx, value->u64[0], reg + 0);
+ _efx_writeq(efx, value->u64[1], reg + 8);
#else
_efx_writed(efx, value->u32[0], reg + 0);
_efx_writed(efx, value->u32[1], reg + 4);
-#endif
_efx_writed(efx, value->u32[2], reg + 8);
_efx_writed(efx, value->u32[3], reg + 12);
+#endif
}
#define efx_writeo_page(efx, value, reg, page) \
_efx_writeo_page(efx, value, \
--
1.7.4.4
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: [PATCH] net: Prefer non link-local source addresses
From: Julian Anastasov @ 2011-09-01 22:14 UTC (permalink / raw)
To: Jeff Harris
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <1314908454-14359-1-git-send-email-jeff_harris@kentrox.com>
Hello,
On Thu, 1 Sep 2011, Jeff Harris wrote:
> Section 2.6.1 of RFC 3927 specifies that if link-local and routable addresses
> are available on an interface, a routable address is preferred. Update the
> IPv4 source address selection algorithm to use a 169.254.x.x address only if
> another matching address is not found.
>
> Tested combinations of configured IP addresses with and without link-local to
> verify a link-local address was chosen only if no routable address was
> present.
As David Lamparter already said, isn't the scope value
suitable for this purpose? Eg.
ip addr add 169.254.5.5/16 brd + dev eth0 scope link
iproute2 already has function default_scope() in
ip/ipaddress.c that assigns scope if it is not specified
while adding address. May be we can add RT_SCOPE_LINK for
169.254 there?
Another such place is inet_set_ifa() in
net/ipv4/devinet.c where we can assign scope, so that
ifconfig works too.
I see also that net/ipv6/addrconf.c (sit_add_v4_addrs)
avoids link-local addresses. What I mean is that the scope
can be checked at many places and it is a mechanism that
already works.
As result, we will not complicate inet_select_addr.
> Signed-off-by: Jeff Harris <jeff_harris@kentrox.com>
> ---
> net/ipv4/devinet.c | 18 ++++++++++++++++--
> 1 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
> index bc19bd0..70ddf37 100644
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@ -965,6 +965,8 @@ out:
> __be32 inet_select_addr(const struct net_device *dev, __be32 dst, int scope)
> {
> __be32 addr = 0;
> + __be32 lladdr = 0;
> + __be32 firstaddr = 0;
> struct in_device *in_dev;
> struct net *net = dev_net(dev);
>
> @@ -977,15 +979,27 @@ __be32 inet_select_addr(const struct net_device *dev, __be32 dst, int scope)
> if (ifa->ifa_scope > scope)
> continue;
> if (!dst || inet_ifa_match(dst, ifa)) {
> + if (ipv4_is_linklocal_169(ifa->ifa_address)) {
> + lladdr = ifa->ifa_local;
> + continue;
> + }
> addr = ifa->ifa_local;
> break;
> }
> - if (!addr)
> - addr = ifa->ifa_local;
> + if (!firstaddr)
> + firstaddr = ifa->ifa_local;
> } endfor_ifa(in_dev);
>
> if (addr)
> goto out_unlock;
> + if (lladdr) {
> + addr = lladdr;
> + goto out_unlock;
> + }
> + if (firstaddr) {
> + addr = firstaddr;
> + goto out_unlock;
> + }
> no_in_dev:
>
> /* Not loopback addresses on loopback should be preferred
> --
> 1.7.0.5
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [PATCH net 1/2] Revert "sfc: Use write-combining to reduce TX latency" and follow-ups
From: Ben Hutchings @ 2011-09-01 22:09 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
This reverts commits 65f0b417dee94f779ce9b77102b7d73c93723b39,
d88d6b05fee3cc78e5b0273eb58c31201dcc6b76,
fcfa060468a4edcf776f0c1211d826d5de1668c1,
747df2258b1b9a2e25929ef496262c339c380009 and
867955f5682f7157fdafe8670804b9f8ea077bc7.
Depending on the processor model, write-combining may result in
reordering that the NIC will not tolerate. This typically results
in a DMA error event and reset by the driver, logged as:
sfc 0000:0e:00.0: eth2: TX DMA Q reports TX_EV_PKT_ERR.
sfc 0000:0e:00.0: eth2: resetting (ALL)
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
Please queue this for 3.0.y as well.
Ben.
drivers/net/sfc/efx.c | 18 +--------------
drivers/net/sfc/io.h | 15 +++---------
drivers/net/sfc/mcdi.c | 46 +++++++++++++++-------------------------
drivers/net/sfc/nic.c | 7 ------
drivers/net/sfc/nic.h | 2 -
drivers/net/sfc/siena.c | 25 +++------------------
drivers/net/sfc/workarounds.h | 2 -
7 files changed, 27 insertions(+), 88 deletions(-)
diff --git a/drivers/net/sfc/efx.c b/drivers/net/sfc/efx.c
index faca764..b59abc7 100644
--- a/drivers/net/sfc/efx.c
+++ b/drivers/net/sfc/efx.c
@@ -1050,7 +1050,6 @@ static int efx_init_io(struct efx_nic *efx)
{
struct pci_dev *pci_dev = efx->pci_dev;
dma_addr_t dma_mask = efx->type->max_dma_mask;
- bool use_wc;
int rc;
netif_dbg(efx, probe, efx->net_dev, "initialising I/O\n");
@@ -1101,21 +1100,8 @@ static int efx_init_io(struct efx_nic *efx)
rc = -EIO;
goto fail3;
}
-
- /* bug22643: If SR-IOV is enabled then tx push over a write combined
- * mapping is unsafe. We need to disable write combining in this case.
- * MSI is unsupported when SR-IOV is enabled, and the firmware will
- * have removed the MSI capability. So write combining is safe if
- * there is an MSI capability.
- */
- use_wc = (!EFX_WORKAROUND_22643(efx) ||
- pci_find_capability(pci_dev, PCI_CAP_ID_MSI));
- if (use_wc)
- efx->membase = ioremap_wc(efx->membase_phys,
- efx->type->mem_map_size);
- else
- efx->membase = ioremap_nocache(efx->membase_phys,
- efx->type->mem_map_size);
+ efx->membase = ioremap_nocache(efx->membase_phys,
+ efx->type->mem_map_size);
if (!efx->membase) {
netif_err(efx, probe, efx->net_dev,
"could not map memory BAR at %llx+%x\n",
diff --git a/drivers/net/sfc/io.h b/drivers/net/sfc/io.h
index cc97880..dc45110 100644
--- a/drivers/net/sfc/io.h
+++ b/drivers/net/sfc/io.h
@@ -48,9 +48,9 @@
* replacing the low 96 bits with zero does not affect functionality.
* - If the host writes to the last dword address of such a register
* (i.e. the high 32 bits) the underlying register will always be
- * written. If the collector and the current write together do not
- * provide values for all 128 bits of the register, the low 96 bits
- * will be written as zero.
+ * written. If the collector does not hold values for the low 96
+ * bits of the register, they will be written as zero. Writing to
+ * the last qword does not have this effect and must not be done.
* - If the host writes to the address of any other part of such a
* register while the collector already holds values for some other
* register, the write is discarded and the collector maintains its
@@ -103,7 +103,6 @@ static inline void efx_writeo(struct efx_nic *efx, efx_oword_t *value,
_efx_writed(efx, value->u32[2], reg + 8);
_efx_writed(efx, value->u32[3], reg + 12);
#endif
- wmb();
mmiowb();
spin_unlock_irqrestore(&efx->biu_lock, flags);
}
@@ -126,7 +125,6 @@ static inline void efx_sram_writeq(struct efx_nic *efx, void __iomem *membase,
__raw_writel((__force u32)value->u32[0], membase + addr);
__raw_writel((__force u32)value->u32[1], membase + addr + 4);
#endif
- wmb();
mmiowb();
spin_unlock_irqrestore(&efx->biu_lock, flags);
}
@@ -141,7 +139,6 @@ static inline void efx_writed(struct efx_nic *efx, efx_dword_t *value,
/* No lock required */
_efx_writed(efx, value->u32[0], reg);
- wmb();
}
/* Read a 128-bit CSR, locking as appropriate. */
@@ -152,7 +149,6 @@ static inline void efx_reado(struct efx_nic *efx, efx_oword_t *value,
spin_lock_irqsave(&efx->biu_lock, flags);
value->u32[0] = _efx_readd(efx, reg + 0);
- rmb();
value->u32[1] = _efx_readd(efx, reg + 4);
value->u32[2] = _efx_readd(efx, reg + 8);
value->u32[3] = _efx_readd(efx, reg + 12);
@@ -175,7 +171,6 @@ static inline void efx_sram_readq(struct efx_nic *efx, void __iomem *membase,
value->u64[0] = (__force __le64)__raw_readq(membase + addr);
#else
value->u32[0] = (__force __le32)__raw_readl(membase + addr);
- rmb();
value->u32[1] = (__force __le32)__raw_readl(membase + addr + 4);
#endif
spin_unlock_irqrestore(&efx->biu_lock, flags);
@@ -242,14 +237,12 @@ static inline void _efx_writeo_page(struct efx_nic *efx, efx_oword_t *value,
#ifdef EFX_USE_QWORD_IO
_efx_writeq(efx, value->u64[0], reg + 0);
- _efx_writeq(efx, value->u64[1], reg + 8);
#else
_efx_writed(efx, value->u32[0], reg + 0);
_efx_writed(efx, value->u32[1], reg + 4);
+#endif
_efx_writed(efx, value->u32[2], reg + 8);
_efx_writed(efx, value->u32[3], reg + 12);
-#endif
- wmb();
}
#define efx_writeo_page(efx, value, reg, page) \
_efx_writeo_page(efx, value, \
diff --git a/drivers/net/sfc/mcdi.c b/drivers/net/sfc/mcdi.c
index 3dd45ed..81a4253 100644
--- a/drivers/net/sfc/mcdi.c
+++ b/drivers/net/sfc/mcdi.c
@@ -50,20 +50,6 @@ static inline struct efx_mcdi_iface *efx_mcdi(struct efx_nic *efx)
return &nic_data->mcdi;
}
-static inline void
-efx_mcdi_readd(struct efx_nic *efx, efx_dword_t *value, unsigned reg)
-{
- struct siena_nic_data *nic_data = efx->nic_data;
- value->u32[0] = (__force __le32)__raw_readl(nic_data->mcdi_smem + reg);
-}
-
-static inline void
-efx_mcdi_writed(struct efx_nic *efx, const efx_dword_t *value, unsigned reg)
-{
- struct siena_nic_data *nic_data = efx->nic_data;
- __raw_writel((__force u32)value->u32[0], nic_data->mcdi_smem + reg);
-}
-
void efx_mcdi_init(struct efx_nic *efx)
{
struct efx_mcdi_iface *mcdi;
@@ -84,8 +70,8 @@ static void efx_mcdi_copyin(struct efx_nic *efx, unsigned cmd,
const u8 *inbuf, size_t inlen)
{
struct efx_mcdi_iface *mcdi = efx_mcdi(efx);
- unsigned pdu = MCDI_PDU(efx);
- unsigned doorbell = MCDI_DOORBELL(efx);
+ unsigned pdu = FR_CZ_MC_TREG_SMEM + MCDI_PDU(efx);
+ unsigned doorbell = FR_CZ_MC_TREG_SMEM + MCDI_DOORBELL(efx);
unsigned int i;
efx_dword_t hdr;
u32 xflags, seqno;
@@ -106,28 +92,29 @@ static void efx_mcdi_copyin(struct efx_nic *efx, unsigned cmd,
MCDI_HEADER_SEQ, seqno,
MCDI_HEADER_XFLAGS, xflags);
- efx_mcdi_writed(efx, &hdr, pdu);
+ efx_writed(efx, &hdr, pdu);
for (i = 0; i < inlen; i += 4)
- efx_mcdi_writed(efx, (const efx_dword_t *)(inbuf + i),
- pdu + 4 + i);
+ _efx_writed(efx, *((__le32 *)(inbuf + i)), pdu + 4 + i);
+
+ /* Ensure the payload is written out before the header */
+ wmb();
/* ring the doorbell with a distinctive value */
- EFX_POPULATE_DWORD_1(hdr, EFX_DWORD_0, 0x45789abc);
- efx_mcdi_writed(efx, &hdr, doorbell);
+ _efx_writed(efx, (__force __le32) 0x45789abc, doorbell);
}
static void efx_mcdi_copyout(struct efx_nic *efx, u8 *outbuf, size_t outlen)
{
struct efx_mcdi_iface *mcdi = efx_mcdi(efx);
- unsigned int pdu = MCDI_PDU(efx);
+ unsigned int pdu = FR_CZ_MC_TREG_SMEM + MCDI_PDU(efx);
int i;
BUG_ON(atomic_read(&mcdi->state) == MCDI_STATE_QUIESCENT);
BUG_ON(outlen & 3 || outlen >= 0x100);
for (i = 0; i < outlen; i += 4)
- efx_mcdi_readd(efx, (efx_dword_t *)(outbuf + i), pdu + 4 + i);
+ *((__le32 *)(outbuf + i)) = _efx_readd(efx, pdu + 4 + i);
}
static int efx_mcdi_poll(struct efx_nic *efx)
@@ -135,7 +122,7 @@ static int efx_mcdi_poll(struct efx_nic *efx)
struct efx_mcdi_iface *mcdi = efx_mcdi(efx);
unsigned int time, finish;
unsigned int respseq, respcmd, error;
- unsigned int pdu = MCDI_PDU(efx);
+ unsigned int pdu = FR_CZ_MC_TREG_SMEM + MCDI_PDU(efx);
unsigned int rc, spins;
efx_dword_t reg;
@@ -161,7 +148,8 @@ static int efx_mcdi_poll(struct efx_nic *efx)
time = get_seconds();
- efx_mcdi_readd(efx, ®, pdu);
+ rmb();
+ efx_readd(efx, ®, pdu);
/* All 1's indicates that shared memory is in reset (and is
* not a valid header). Wait for it to come out reset before
@@ -188,7 +176,7 @@ static int efx_mcdi_poll(struct efx_nic *efx)
respseq, mcdi->seqno);
rc = EIO;
} else if (error) {
- efx_mcdi_readd(efx, ®, pdu + 4);
+ efx_readd(efx, ®, pdu + 4);
switch (EFX_DWORD_FIELD(reg, EFX_DWORD_0)) {
#define TRANSLATE_ERROR(name) \
case MC_CMD_ERR_ ## name: \
@@ -222,21 +210,21 @@ out:
/* Test and clear MC-rebooted flag for this port/function */
int efx_mcdi_poll_reboot(struct efx_nic *efx)
{
- unsigned int addr = MCDI_REBOOT_FLAG(efx);
+ unsigned int addr = FR_CZ_MC_TREG_SMEM + MCDI_REBOOT_FLAG(efx);
efx_dword_t reg;
uint32_t value;
if (efx_nic_rev(efx) < EFX_REV_SIENA_A0)
return false;
- efx_mcdi_readd(efx, ®, addr);
+ efx_readd(efx, ®, addr);
value = EFX_DWORD_FIELD(reg, EFX_DWORD_0);
if (value == 0)
return 0;
EFX_ZERO_DWORD(reg);
- efx_mcdi_writed(efx, ®, addr);
+ efx_writed(efx, ®, addr);
if (value == MC_STATUS_DWORD_ASSERT)
return -EINTR;
diff --git a/drivers/net/sfc/nic.c b/drivers/net/sfc/nic.c
index bafa23a..3edfbaf 100644
--- a/drivers/net/sfc/nic.c
+++ b/drivers/net/sfc/nic.c
@@ -1936,13 +1936,6 @@ void efx_nic_get_regs(struct efx_nic *efx, void *buf)
size = min_t(size_t, table->step, 16);
- if (table->offset >= efx->type->mem_map_size) {
- /* No longer mapped; return dummy data */
- memcpy(buf, "\xde\xc0\xad\xde", 4);
- buf += table->rows * size;
- continue;
- }
-
for (i = 0; i < table->rows; i++) {
switch (table->step) {
case 4: /* 32-bit register or SRAM */
diff --git a/drivers/net/sfc/nic.h b/drivers/net/sfc/nic.h
index 4bd1f28..7443f99 100644
--- a/drivers/net/sfc/nic.h
+++ b/drivers/net/sfc/nic.h
@@ -143,12 +143,10 @@ static inline struct falcon_board *falcon_board(struct efx_nic *efx)
/**
* struct siena_nic_data - Siena NIC state
* @mcdi: Management-Controller-to-Driver Interface
- * @mcdi_smem: MCDI shared memory mapping. The mapping is always uncacheable.
* @wol_filter_id: Wake-on-LAN packet filter id
*/
struct siena_nic_data {
struct efx_mcdi_iface mcdi;
- void __iomem *mcdi_smem;
int wol_filter_id;
};
diff --git a/drivers/net/sfc/siena.c b/drivers/net/sfc/siena.c
index 5735e84..2c3bd93 100644
--- a/drivers/net/sfc/siena.c
+++ b/drivers/net/sfc/siena.c
@@ -250,26 +250,12 @@ static int siena_probe_nic(struct efx_nic *efx)
efx_reado(efx, ®, FR_AZ_CS_DEBUG);
efx->net_dev->dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1;
- /* Initialise MCDI */
- nic_data->mcdi_smem = ioremap_nocache(efx->membase_phys +
- FR_CZ_MC_TREG_SMEM,
- FR_CZ_MC_TREG_SMEM_STEP *
- FR_CZ_MC_TREG_SMEM_ROWS);
- if (!nic_data->mcdi_smem) {
- netif_err(efx, probe, efx->net_dev,
- "could not map MCDI at %llx+%x\n",
- (unsigned long long)efx->membase_phys +
- FR_CZ_MC_TREG_SMEM,
- FR_CZ_MC_TREG_SMEM_STEP * FR_CZ_MC_TREG_SMEM_ROWS);
- rc = -ENOMEM;
- goto fail1;
- }
efx_mcdi_init(efx);
/* Recover from a failed assertion before probing */
rc = efx_mcdi_handle_assertion(efx);
if (rc)
- goto fail2;
+ goto fail1;
/* Let the BMC know that the driver is now in charge of link and
* filter settings. We must do this before we reset the NIC */
@@ -324,7 +310,6 @@ fail4:
fail3:
efx_mcdi_drv_attach(efx, false, NULL);
fail2:
- iounmap(nic_data->mcdi_smem);
fail1:
kfree(efx->nic_data);
return rc;
@@ -404,8 +389,6 @@ static int siena_init_nic(struct efx_nic *efx)
static void siena_remove_nic(struct efx_nic *efx)
{
- struct siena_nic_data *nic_data = efx->nic_data;
-
efx_nic_free_buffer(efx, &efx->irq_status);
siena_reset_hw(efx, RESET_TYPE_ALL);
@@ -415,8 +398,7 @@ static void siena_remove_nic(struct efx_nic *efx)
efx_mcdi_drv_attach(efx, false, NULL);
/* Tear down the private nic state */
- iounmap(nic_data->mcdi_smem);
- kfree(nic_data);
+ kfree(efx->nic_data);
efx->nic_data = NULL;
}
@@ -656,7 +638,8 @@ const struct efx_nic_type siena_a0_nic_type = {
.default_mac_ops = &efx_mcdi_mac_operations,
.revision = EFX_REV_SIENA_A0,
- .mem_map_size = FR_CZ_MC_TREG_SMEM, /* MC_TREG_SMEM mapped separately */
+ .mem_map_size = (FR_CZ_MC_TREG_SMEM +
+ FR_CZ_MC_TREG_SMEM_STEP * FR_CZ_MC_TREG_SMEM_ROWS),
.txd_ptr_tbl_base = FR_BZ_TX_DESC_PTR_TBL,
.rxd_ptr_tbl_base = FR_BZ_RX_DESC_PTR_TBL,
.buf_tbl_base = FR_BZ_BUF_FULL_TBL,
diff --git a/drivers/net/sfc/workarounds.h b/drivers/net/sfc/workarounds.h
index 99ff114..e4dd3a7 100644
--- a/drivers/net/sfc/workarounds.h
+++ b/drivers/net/sfc/workarounds.h
@@ -38,8 +38,6 @@
#define EFX_WORKAROUND_15783 EFX_WORKAROUND_ALWAYS
/* Legacy interrupt storm when interrupt fifo fills */
#define EFX_WORKAROUND_17213 EFX_WORKAROUND_SIENA
-/* Write combining and sriov=enabled are incompatible */
-#define EFX_WORKAROUND_22643 EFX_WORKAROUND_SIENA
/* Spurious parity errors in TSORT buffers */
#define EFX_WORKAROUND_5129 EFX_WORKAROUND_FALCON_A
--
1.7.4.4
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH] iPhone 4 Verizon CDMA USB Product ID add
From: Kavan Smith @ 2011-09-01 22:01 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-usb-u79uwXL29TY76Z2rM5mHXA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Kavan Smith
Add USB product ID for iPhone 4 CDMA Verizon
Tested on at least 2 devices
Signed-off-by: Kavan Smith <kavansmith82-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/usb/ipheth.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c
index 15772b1..13c1f04 100644
--- a/drivers/net/usb/ipheth.c
+++ b/drivers/net/usb/ipheth.c
@@ -59,6 +59,7 @@
#define USB_PRODUCT_IPHONE_3G 0x1292
#define USB_PRODUCT_IPHONE_3GS 0x1294
#define USB_PRODUCT_IPHONE_4 0x1297
+#define USB_PRODUCT_IPHONE_4_VZW 0x129c
#define IPHETH_USBINTF_CLASS 255
#define IPHETH_USBINTF_SUBCLASS 253
@@ -98,6 +99,10 @@ static struct usb_device_id ipheth_table[] = {
USB_VENDOR_APPLE, USB_PRODUCT_IPHONE_4,
IPHETH_USBINTF_CLASS, IPHETH_USBINTF_SUBCLASS,
IPHETH_USBINTF_PROTO) },
+ { USB_DEVICE_AND_INTERFACE_INFO(
+ USB_VENDOR_APPLE, USB_PRODUCT_IPHONE_4_VZW,
+ IPHETH_USBINTF_CLASS, IPHETH_USBINTF_SUBCLASS,
+ IPHETH_USBINTF_PROTO) },
{ }
};
MODULE_DEVICE_TABLE(usb, ipheth_table);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] dev_ioctl should return -EINVAL for unknown ioctl instead of -ENOTTY
From: Wang Sheng-Hui @ 2011-09-01 22:00 UTC (permalink / raw)
To: Ben Hutchings; +Cc: davem, netdev, linux-kernel
In-Reply-To: <1314891670.2733.12.camel@bwh-desktop>
On 2011年09月01日 23:41, Ben Hutchings wrote:
> On Thu, 2011-09-01 at 22:52 +0800, Wang Sheng-Hui wrote:
>> The patch is against 3.1-rc3.
>>
>> Signed-off-by: Wang Sheng-Hui <shhuiw@gmail.com>
>> ---
>> net/core/dev.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 17d67b5..de6033c 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -5092,7 +5092,7 @@ int dev_ioctl(struct net *net, unsigned int cmd, void __user *arg)
>> /* Take care of Wireless Extensions */
>> if (cmd >= SIOCIWFIRST && cmd <= SIOCIWLAST)
>> return wext_handle_ioctl(net, &ifr, cmd, arg);
>> - return -ENOTTY;
>> + return -EINVAL;
>> }
>> }
>>
>
> Whereas, Linus Torvalds wrote in
> <BANLkTin=PTbTwBR2s+owMLy+GmKigeoYvg@mail.gmail.com>:
> [...]
>> The correct error code for "I don't understand this ioctl" is ENOTTY.
>> The naming may be odd, but you should think of that error value as a
>> "unrecognized ioctl number, you're feeding me random numbers that I
>> don't understand and I assume for historical reasons that you tried to
>> do some tty operation on me".
> [...]
>
> (Not that we are consistent about using ENOTTY in networking now.)
>
> Ben.
>
Got it. Thanks.
^ permalink raw reply
* Re: [PATCH] net: Prefer non link-local source addresses
From: David Lamparter @ 2011-09-01 21:56 UTC (permalink / raw)
To: Jeff Harris
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <1314908454-14359-1-git-send-email-jeff_harris@kentrox.com>
On Thu, Sep 01, 2011 at 04:20:54PM -0400, Jeff Harris wrote:
> Section 2.6.1 of RFC 3927 specifies that if link-local and routable addresses
> are available on an interface, a routable address is preferred. Update the
> IPv4 source address selection algorithm to use a 169.254.x.x address only if
> another matching address is not found.
> + if (ipv4_is_linklocal_169(ifa->ifa_address)) {
> + lladdr = ifa->ifa_local;
> + continue;
> + }
IP addresses have a scope field:
# ip -4 a l eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
inet 10.0.0.1/24 brd 10.0.0.255 scope link eth0
inet 172.22.80.50/25 brd 172.22.80.127 scope global eth0
would it not make sense to use to use that field instead?
-David
^ permalink raw reply
* possible routing table cache bug for mtu/advmss attributes in Linux 3.0.4
From: David Madore @ 2011-09-01 21:46 UTC (permalink / raw)
To: Linux Netdev Mailing-List
Hi,
I believe I've found a bug in the routing cache (perhaps only for
IPv6) in Linux 3.0.4. Since I'm uncertain about the diagnosis, I'm
posting here for guidance as to how to proceed.
In a nutshell, the problem is this: my (manually entered) routing
tables specify an explicit MTU/MSS for certain IPv6 routes, and after
upgrading from 2.6.38.7 to 3.0.4, I found that this MTU/MSS setting is
sometimes ignored. More precisely, it seems that connecting to a host
through the route in question causes a routing cache entry to be
created, and it is when this cache entry expires that the route
forgets the MTU/MSS setting. (It may also be relevant that in my case
the route belongs to a routing table other than "main".)
In more details: my routing tables contains the following:
vega david ~ $ sudo ip -6 rule show
0: from all lookup local
32766: from all lookup main
40000: from 2002::/16 lookup 2002
40100: from all lookup 2001
vega david ~ $ sudo ip -6 route show table 2001
2002::/16 via ::192.88.99.1 dev tun6to4 metric 512 mtu 1466 advmss 1406
2000::/3 dev ppp0 metric 64 mtu 1466 advmss 1406
Initially, trying to get the route to 2001:41d0:1:a431::1 correctly
returns route with the mtu and advmss values I entered:
vega david ~ $ sudo ip route get 2001:41d0:1:a431::1
2001:41d0:1:a431::1 from :: via 2001:41d0:1:a431::1 dev ppp0 src 2001:7a8:78ae::1 metric 0
cache mtu 1466 advmss 1406
Now I start an ssh connection to 2001:41d0:1:a431::1, close it
immediately, and fetch the route again:
vega david ~ $ sudo ip route get 2001:41d0:1:a431::1
2001:41d0:1:a431::1 from :: via 2001:41d0:1:a431::1 dev ppp0 src 2001:7a8:78ae::1 metric 0
cache mtu 1466 rtt 37ms rttvar 37ms cwnd 10 advmss 1406
This is still correct. But if I wait a few seconds (doing nothing)
for these data to expire, they seems to take the mtu and advmss values
away with them:
vega david ~ $ sudo ip route get 2001:41d0:1:a431::1
2001:41d0:1:a431::1 from :: via 2001:41d0:1:a431::1 dev ppp0 src 2001:7a8:78ae::1 metric 0
cache
(note the empty "cache" line and the absence of mtu/advmss settings).
This is not just wrongly reported: the route really is wrong, and
opening a TCP connection at this stage will use a wrong MSS (and
freeze on large packets, because my Internet provider is worthless,
but that's another story). At some point the route seems to return to
normal, but I couldn't figure out what causes this exactly.
In case it's uesful, my kernel config is on <URL:
http://www.madore.org/~david/.tmp/config-3.0.4-vega
>.
Any thoughts?
--
David A. Madore
( http://www.madore.org/~david/ )
^ permalink raw reply
* Re: IP_TRANSPARENT requires CAP_NET_ADMIN - why?
From: Maciej Żenczykowski @ 2011-09-01 21:25 UTC (permalink / raw)
To: Linux NetDev
Cc: David Miller, Balazs Scheidler, Patrick McHardy, KOVACS Krisztian,
YOSHIFUJI Hideaki
In-Reply-To: <CAHo-Ooz-0wt4-3oXZBeEmLTSom5qUxhXhP4MDUrSz322OTGa9A@mail.gmail.com>
> I'm curious why transparent sockets [setsockopt(IP{,V6}_TRANSPARENT),
> ie. inet_sk(sk)->transparent bit] require CAP_NET_ADMIN privileges.
>
> Wouldn't CAP_NET_RAW be more appropriate?
>
> Looks to me like CAP_NET_RAW is all about raw sockets.
> Transparent sockets are dangerous because they effectively allow spoofing.
> But this seems to be the same sort of thing that CAP_NET_RAW protects
> against.
>
> Is there something I'm missing?
> Is there any reason why having CAP_NET_RAW privs shouldn't allow one
> to set the transparent bit on a socket?
>
> Would people be opposed to relaxing the check on setting sk->transparent
> to be either CAP_NET_ADMIN or CAP_NET_RAW?
Why am I even interested? I have a couple of apps (dns servers, web
servers, load balancers, web crawlers) that
don't require any special permissions except the ability to use any ip
as the source ip for a listening tcp, outgoing tcp, and/or udp socket.
For example machines may receive arbitrary traffic over a tunnel (with
absolutely any ip as the destination ip within the tunneled payload)
and need to respond to it, hence they need to be able to respond with
any ip as the source ip. This can be achieved with combinations of
routing tricks and/or ip non local bind and/or ip_transparent.
The way I see it there are a couple possibilities.
a) Leave as is: IP{,V6}_TRANSPARENT requires CAP_NET_ADMIN
This seems like the least desirable solution, we end up requiring a
much more powerful privilege then necessary.
b) Backward compatible: Make it require one of CAP_NET_ADMIN or CAP_NET_RAW
Better, but kind of ugly in there being two permissions that allow this.
c) Not-backward compatible: Make it require CAP_NET_RAW instead of CAP_NET_ADMIN
Better, in that a less powerful privilege is required, but *does*
break non-root software which uses CAP_NET_ADMIN to get TRANSPARENT
sockets.
Also the gain isn't that great, in that we are still using a
privilege which is a little too powerful.
d) Add a new capability: Make it require CAP_NET_ADMIN or CAP_NET_TRANSPARENT
Again backward compatible - ugly.
e) Add a new capability: Make it require CAP_NET_ADMIN or CAP_NET_RAW
or CAP_NET_TRANSPARENT
Again backward compatible - ugly. The reason for allowing
CAP_NET_RAW is that it effectively already allows this to be done with
raw sockets in a less useful way. ie. AFAICT CAP_NET_TRANSPARENT is a
subset of CAP_NET_RAW
f) Add a new capability: Make it require CAP_NET_TRANSPARENT instead
of CAP_NET_ADMIN
Not backward compatible, introduces a new capability, however, long
term this is probably the cleanest.
My personal vote is for (f). I figure the number of non-root-apps
that have CAP_NET_ADMIN in order to get IP{,V6}_TRANSPARENT support is
very low, and they should be easy to fix to request
CAP_NET_TRANSPARENT instead.
Any opinions?
Maciej
^ permalink raw reply
* Re: divide error: 0000, in bictcp_cong_avoid, kernel 2.6.39
From: TB @ 2011-09-01 20:30 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <4E1369FA.1090008@techboom.com>
On 11-07-05 03:46 PM, TB wrote:
> On 11-07-05 01:16 PM, Stephen Hemminger wrote:
>> On Mon, 04 Jul 2011 14:10:16 -0400
>> TB <lkml@techboom.com> wrote:
>>
>>> On 11-07-04 01:36 PM, Stephen Hemminger wrote:
>>>> Any data about the type of connection, kernel configuration or other
>>>> information that might be useful in reproducing the problem?
>>>>
>>>> Also please try 2.6.39.2
>>>
>>> We haven't found a sure way of reproducing it.
>>> It happened on 1.2% of our servers over the weekend and seems random.
>>> Both are connected with 2 gigabit ports using bonding. Traffic tends to
>>> be heavy, but doesn't seem to be a factor.
>>>
>>> Would a .config help ?
>>>
>>> Only the very basic filter module for iptables is compiled in.
>>>
>>> We will try 2.6.39.2 soon
>>
>> Kernel config (and compiler version) would help in identifying which
>> of the three divides is getting divide by zero.
>
> # gcc --version
> gcc (Debian 4.3.2-1.1) 4.3.2
>
>
> # as --version
> GNU assembler (GNU Binutils for Debian) 2.18.0.20080103
> This assembler was configured for a target of `x86_64-linux-gnu'.
We have tried 3.0.4 and the bug is still present, however we have still
been unable to get a proper backtrace. It seems a lot of times the
netlog isn't working.
^ permalink raw reply
* [next] unix stream crashes
From: Jiri Slaby @ 2011-09-01 20:46 UTC (permalink / raw)
To: tim.c.chen; +Cc: David S. Miller, ML netdev, LKML
Hi,
my box 100% crashes when booting. It's both in unix socket recv and send
paths. I've reverted 0856a30409 (Scm: Remove unnecessary pid &
credential references in Unix socket's send and receive path) and it
seems to help.
The oops:
http://www.fi.muni.cz/~xslaby/sklad/panics/af_unix_crash.png
regards,
--
js
^ permalink raw reply
* Hello
From: Jianguo @ 2011-09-01 19:25 UTC (permalink / raw)
My name is Z. Jianguo, I have a transaction of $21,830,000.00 to bring to your attention, if interested for more details, do kindly respond back to me at (juguoz@yahoo.com.hk) for further explanation on the said transaction.
I would appreciate your kind response.
Sincerely,
Z. Jianguo
^ permalink raw reply
* [PATCH] net: Prefer non link-local source addresses
From: Jeff Harris @ 2011-09-01 20:20 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy <kabe
Cc: Jeff Harris
Section 2.6.1 of RFC 3927 specifies that if link-local and routable addresses
are available on an interface, a routable address is preferred. Update the
IPv4 source address selection algorithm to use a 169.254.x.x address only if
another matching address is not found.
Tested combinations of configured IP addresses with and without link-local to
verify a link-local address was chosen only if no routable address was
present.
Signed-off-by: Jeff Harris <jeff_harris@kentrox.com>
---
net/ipv4/devinet.c | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index bc19bd0..70ddf37 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -965,6 +965,8 @@ out:
__be32 inet_select_addr(const struct net_device *dev, __be32 dst, int scope)
{
__be32 addr = 0;
+ __be32 lladdr = 0;
+ __be32 firstaddr = 0;
struct in_device *in_dev;
struct net *net = dev_net(dev);
@@ -977,15 +979,27 @@ __be32 inet_select_addr(const struct net_device *dev, __be32 dst, int scope)
if (ifa->ifa_scope > scope)
continue;
if (!dst || inet_ifa_match(dst, ifa)) {
+ if (ipv4_is_linklocal_169(ifa->ifa_address)) {
+ lladdr = ifa->ifa_local;
+ continue;
+ }
addr = ifa->ifa_local;
break;
}
- if (!addr)
- addr = ifa->ifa_local;
+ if (!firstaddr)
+ firstaddr = ifa->ifa_local;
} endfor_ifa(in_dev);
if (addr)
goto out_unlock;
+ if (lladdr) {
+ addr = lladdr;
+ goto out_unlock;
+ }
+ if (firstaddr) {
+ addr = firstaddr;
+ goto out_unlock;
+ }
no_in_dev:
/* Not loopback addresses on loopback should be preferred
--
1.7.0.5
^ permalink raw reply related
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