* [PATCH 8/9] stmmac: update the doc with new info about the driver's debug (v3)
From: Giuseppe CAVALLARO @ 2011-09-02 7:51 UTC (permalink / raw)
To: netdev; +Cc: bhutchings, davem, Giuseppe Cavallaro
In-Reply-To: <1314949903-26137-1-git-send-email-peppe.cavallaro@st.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
Documentation/networking/stmmac.txt | 33 ++++++++++++++++++++++++++++++++-
1 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt
index 57a2410..40ec92c 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -235,7 +235,38 @@ reset procedure etc).
o enh_desc.c: functions for handling enhanced descriptors
o norm_desc.c: functions for handling normal descriptors
-5) TODO:
+5) Debug Information
+
+The driver exports many information i.e. internal statistics,
+debug information, MAC and DMA registers etc.
+
+These can be read in several ways depending on the
+type of the information actually needed.
+
+For example a user can be use the ethtool support
+to get statistics: e.g. using: ethtool -S ethX
+(that shows the Management counters (MMC) if supported)
+or sees the MAC/DMA registers: e.g. using: ethtool -d ethX
+
+Compiling the Kernel with CONFIG_DEBUG_FS and enabling the
+STMMAC_DEBUG_FS option the driver will export the following
+debugfs entries:
+
+/sys/kernel/debug/stmmaceth/descriptors_status
+ To show the DMA TX/RX descriptor rings
+
+Developer can also use the "debug" module parameter to get
+further debug information.
+
+In the end, there are other macros (that cannot be enabled
+via menuconfig) to turn-on the RX/TX DMA debugging,
+specific MAC core debug printk etc. Others to enable the
+debug in the TX and RX processes.
+All these are only useful during the developing stage
+and should never enabled inside the code for general usage.
+In fact, these can generate an huge amount of debug messages.
+
+6) TODO:
o XGMAC is not supported.
o Review the timer optimisation code to use an embedded device that will be
available in new chip generations.
--
1.7.4.4
^ permalink raw reply related
* [PATCH 9/9] stmmac: update the driver version (Aug_2011) (v3)
From: Giuseppe CAVALLARO @ 2011-09-02 7:51 UTC (permalink / raw)
To: netdev; +Cc: bhutchings, davem, Giuseppe Cavallaro
In-Reply-To: <1314949903-26137-1-git-send-email-peppe.cavallaro@st.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/stmmac/stmmac.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/stmmac/stmmac.h b/drivers/net/stmmac/stmmac.h
index c3a2da7..1434bdb 100644
--- a/drivers/net/stmmac/stmmac.h
+++ b/drivers/net/stmmac/stmmac.h
@@ -20,7 +20,7 @@
Author: Giuseppe Cavallaro <peppe.cavallaro@st.com>
*******************************************************************************/
-#define DRV_MODULE_VERSION "July_2011"
+#define DRV_MODULE_VERSION "Aug_2011"
#include <linux/stmmac.h>
#include "common.h"
--
1.7.4.4
^ permalink raw reply related
* [patch -next] caif: add error handling for allocation
From: Dan Carpenter @ 2011-09-02 8:07 UTC (permalink / raw)
To: Sjur Braendeland
Cc: David S. Miller, open list:CAIF NETWORK LAYER, kernel-janitors
The allocation could fail so we should check, or other errors could
happen and we should free the "phyinfo" variable.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/net/caif/cfcnfg.c b/net/caif/cfcnfg.c
index f07ab8c..b213b53 100644
--- a/net/caif/cfcnfg.c
+++ b/net/caif/cfcnfg.c
@@ -467,7 +467,7 @@ cfcnfg_add_phy_layer(struct cfcnfg *cnfg, enum cfcnfg_phy_type phy_type,
{
struct cflayer *frml;
struct cflayer *phy_driver = NULL;
- struct cfcnfg_phyinfo *phyinfo;
+ struct cfcnfg_phyinfo *phyinfo = NULL;
int i;
u8 phyid;
@@ -482,23 +482,25 @@ cfcnfg_add_phy_layer(struct cfcnfg *cnfg, enum cfcnfg_phy_type phy_type,
goto got_phyid;
}
pr_warn("Too many CAIF Link Layers (max 6)\n");
- goto out;
+ goto out_err;
got_phyid:
phyinfo = kzalloc(sizeof(struct cfcnfg_phyinfo), GFP_ATOMIC);
+ if (!phyinfo)
+ goto out_err;
switch (phy_type) {
case CFPHYTYPE_FRAG:
phy_driver =
cfserl_create(CFPHYTYPE_FRAG, phyid, stx);
if (!phy_driver)
- goto out;
+ goto out_err;
break;
case CFPHYTYPE_CAIF:
phy_driver = NULL;
break;
default:
- goto out;
+ goto out_err;
}
phy_layer->id = phyid;
phyinfo->pref = pref;
@@ -512,10 +514,8 @@ got_phyid:
frml = cffrml_create(phyid, fcs);
- if (!frml) {
- kfree(phyinfo);
- goto out;
- }
+ if (!frml)
+ goto out_err;
phyinfo->frm_layer = frml;
layer_set_up(frml, cnfg->mux);
@@ -531,7 +531,11 @@ got_phyid:
}
list_add_rcu(&phyinfo->node, &cnfg->phys);
-out:
+ mutex_unlock(&cnfg->lock);
+ return;
+
+out_err:
+ kfree(phyinfo);
mutex_unlock(&cnfg->lock);
}
EXPORT_SYMBOL(cfcnfg_add_phy_layer);
^ permalink raw reply related
* Re: IP_TRANSPARENT requires CAP_NET_ADMIN - why?
From: Balazs Scheidler @ 2011-09-02 8:43 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: Linux NetDev, David Miller, Patrick McHardy, KOVACS Krisztian,
YOSHIFUJI Hideaki
In-Reply-To: <CAHo-OozTNa8gtCuhSZm+aBqK-J0-eGMyr5rJBfTV6SmPZNhQVw@mail.gmail.com>
Hi,
On Thu, 2011-09-01 at 14:25 -0700, Maciej Żenczykowski wrote:
> > 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?
Well, the reason for choosing CAP_NET_ADMIN is that the original tproxy
functionality in Linux 2.2 required that cap, and we never questioned
it. Also, earlier the bits in the capability mask was a scarce resource
earlier. But see more info at the end of this email.
>
> 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.
I was a bit involved in a capability change earlier, in the syslog-ng
context. It is quite ugly, but doable.
For a new capability to work correctly the following changes must
trickle down to distributions:
1) new kernel
2) very recent glibc
3) new libcap (both devel & runtime)
4) patched applications (compiled against a new libcap)
If any of those is not yet patched, it won't work. Users tend to upgrade
the kernel and applications but rarely do so with the rest of the
userspace stack, e.g. libcap, which has caused some pain with syslog-ng.
The way that it was did for CAP_SYSLOG is that for a time CAP_SYSLOG
already worked, and the older cap CAP_SYS_ADMIN works too, but displays
an ugly oops-like kernel warning.
Certainly all of these can be worked around:
1) kernel
well, it's up to the user, but if the kernel is older than the one which
supports CAP_NET_TRANSPARENT, there's no issue.
2) glibc
The only way to detect if the kernel supports cap is to read the
capability bounding set, which uses a prctl() option that is defined by
a very new glibc (and kernel 2.6.25)
In syslog-ng, we had to define the value for PR_CAPBSET_READ in case it
wasn't defined.
3) libcap
The value for CAP_NET_TRANSPARENT is in the header file (e.g. devel
package), but that's not enough. We've seen distros, where the header
did contain the capability, but the runtime didn't know about the new
cap. I'm not sure why that happens, but it did on Fedora 15
https://bugzilla.balabit.com/show_bug.cgi?id=108#c24
The runtime needs to know about the new capability when transforming a
string representation to a bitset.
4) new apps
Well, the solution is not very easy to get right, and there's still some
problems with syslog-ng even after a couple of rounds. (see the end of
the quoted bugzilla ticket).
All this described to say that it is certainly doable, but requires
effort to get right and will definitely need to define a grace period
for which it is backward compatible.
Somewhat less effort is needed if we reuse CAP_NET_RAW though, since
that is already in all kernels/libcap/glibc versions.
All that much said, I would vote for CAP_NET_RAW, and a grace period of
a couple of kernel releases, until the kernel displays a warning, like
it did with the CAP_SYSLOG case.
I'm a bit overwhelmed with stuff though, and would be happy if someone
else could prepare the necessary changes. But if someone does, I'd
recommend reading the CAP_SYSLOG related changes in kernel history to
avoid repeating the same mistakes.
--
Bazsi
^ permalink raw reply
* Re: [Bugme-new] [Bug 42132] New: Support BCM5750M in tg3
From: Francesco Piccinno @ 2011-09-02 9:20 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: <20110902012514.GA5595@mcarlson.broadcom.com>
The patch did not apply cleanly. BTW I have figured out an alternative
method. I modified by hand pci_ids.h and tg3.c files. The device seems
to work now.
The output of ethtool -i eth0 gives me:
driver: tg3
version: 3.119
firmware-version:
bus-info: 0000:08:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
Messages produced by the driver:
[ 728.741487] tg3 0000:08:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 728.741498] tg3 0000:08:00.0: setting latency timer to 64
[ 728.819963] tg3 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.
[ 728.879960] tg3 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.
[ 728.939957] tg3 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.
[ 728.942680] tg3 0000:08:00.0: eth0: Tigon3 [partno(none) rev 4201]
(PCI Express) MAC address 00:1b:38:38:c6:60
[ 728.942685] tg3 0000:08:00.0: eth0: attached PHY is 5750
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[ 728.942689] tg3 0000:08:00.0: eth0: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[0] TSOcap[1]
[ 728.942692] tg3 0000:08:00.0: eth0: dma_rwctrl[76180000] dma_mask[64-bit]
[ 728.949503] tg3 0000:08:00.0: irq 45 for MSI/MSI-X
[ 730.633610] tg3 0000:08:00.0: eth0: No firmware running
[ 730.650658] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 811.811298] tg3 0000:08:00.0: eth0: Link is up at 100 Mbps, full duplex
[ 811.811306] tg3 0000:08:00.0: eth0: Flow control is on for TX and on for RX
--
Best regards,
Francesco Piccinno
On Fri, Sep 2, 2011 at 3:25 AM, Matt Carlson <mcarlson@broadcom.com> wrote:
> 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: [patch -next] caif: add error handling for allocation
From: Sjur Brændeland @ 2011-09-02 9:40 UTC (permalink / raw)
To: Dan Carpenter
Cc: David S. Miller, open list:CAIF NETWORK LAYER, kernel-janitors
In-Reply-To: <20110902080716.GF2430@shale.localdomain>
Hi Dan,
...
> switch (phy_type) {
> case CFPHYTYPE_FRAG:
> phy_driver =
> cfserl_create(CFPHYTYPE_FRAG, phyid, stx);
> if (!phy_driver)
> - goto out;
> + goto out_err;
> break;
...
> -out:
> + mutex_unlock(&cnfg->lock);
> + return;
> +
> +out_err:
> + kfree(phyinfo);
> mutex_unlock(&cnfg->lock);
Thank you for your patch.
When reviewing this I found another potential memory leak as well.
If cffrml_create fails, we might be leaking the phy_driver.
So perhaps you could do kfree(phy_driver) in out_err: as well, while
you are at it?
Regards,
Sjur
^ permalink raw reply
* [PATCH net-next v4 1/4] r8169: fix WOL setting for 8105 and 8111EVL
From: Hayes Wang @ 2011-09-02 9:49 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
rtl8105, rtl8111E, and rtl8111evl need enable RxConfig bit 1 ~ 3
for supporting wake on lan.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 1cf8c3c..aaae43e 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3319,9 +3319,16 @@ static void r810x_phy_power_up(struct rtl8169_private *tp)
static void r810x_pll_power_down(struct rtl8169_private *tp)
{
+ void __iomem *ioaddr = tp->mmio_addr;
+
if (__rtl8169_get_wol(tp) & WAKE_ANY) {
rtl_writephy(tp, 0x1f, 0x0000);
rtl_writephy(tp, MII_BMCR, 0x0000);
+
+ if (tp->mac_version == RTL_GIGA_MAC_VER_29 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_30)
+ RTL_W32(RxConfig, RTL_R32(RxConfig) | AcceptBroadcast |
+ AcceptMulticast | AcceptMyPhys);
return;
}
@@ -3417,7 +3424,8 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
rtl_writephy(tp, MII_BMCR, 0x0000);
if (tp->mac_version == RTL_GIGA_MAC_VER_32 ||
- tp->mac_version == RTL_GIGA_MAC_VER_33)
+ tp->mac_version == RTL_GIGA_MAC_VER_33 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_34)
RTL_W32(RxConfig, RTL_R32(RxConfig) | AcceptBroadcast |
AcceptMulticast | AcceptMyPhys);
return;
--
1.7.6
^ permalink raw reply related
* [PATCH net-next v4 4/4] r8169: support new chips of RTL8111F
From: Hayes Wang @ 2011-09-02 9:49 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1314956953-1568-1-git-send-email-hayeswang@realtek.com>
Support new chips of RTL8111F.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 181 +++++++++++++++++++++++++++++++++-
1 files changed, 179 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 175c769..8e6a200 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -42,6 +42,8 @@
#define FIRMWARE_8168E_1 "rtl_nic/rtl8168e-1.fw"
#define FIRMWARE_8168E_2 "rtl_nic/rtl8168e-2.fw"
#define FIRMWARE_8168E_3 "rtl_nic/rtl8168e-3.fw"
+#define FIRMWARE_8168F_1 "rtl_nic/rtl8168f-1.fw"
+#define FIRMWARE_8168F_2 "rtl_nic/rtl8168f-2.fw"
#define FIRMWARE_8105E_1 "rtl_nic/rtl8105e-1.fw"
#ifdef RTL8169_DEBUG
@@ -133,6 +135,8 @@ enum mac_version {
RTL_GIGA_MAC_VER_32,
RTL_GIGA_MAC_VER_33,
RTL_GIGA_MAC_VER_34,
+ RTL_GIGA_MAC_VER_35,
+ RTL_GIGA_MAC_VER_36,
RTL_GIGA_MAC_NONE = 0xff,
};
@@ -218,7 +222,11 @@ static const struct {
[RTL_GIGA_MAC_VER_33] =
_R("RTL8168e/8111e", RTL_TD_1, FIRMWARE_8168E_2),
[RTL_GIGA_MAC_VER_34] =
- _R("RTL8168evl/8111evl",RTL_TD_1, FIRMWARE_8168E_3)
+ _R("RTL8168evl/8111evl",RTL_TD_1, FIRMWARE_8168E_3),
+ [RTL_GIGA_MAC_VER_35] =
+ _R("RTL8168f/8111f", RTL_TD_1, FIRMWARE_8168F_1),
+ [RTL_GIGA_MAC_VER_36] =
+ _R("RTL8168f/8111f", RTL_TD_1, FIRMWARE_8168F_2)
};
#undef _R
@@ -711,7 +719,10 @@ MODULE_FIRMWARE(FIRMWARE_8168D_1);
MODULE_FIRMWARE(FIRMWARE_8168D_2);
MODULE_FIRMWARE(FIRMWARE_8168E_1);
MODULE_FIRMWARE(FIRMWARE_8168E_2);
+MODULE_FIRMWARE(FIRMWARE_8168E_3);
MODULE_FIRMWARE(FIRMWARE_8105E_1);
+MODULE_FIRMWARE(FIRMWARE_8168F_1);
+MODULE_FIRMWARE(FIRMWARE_8168F_2);
static int rtl8169_open(struct net_device *dev);
static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
@@ -1200,6 +1211,19 @@ static void rtl_link_chg_patch(struct rtl8169_private *tp)
ERIAR_EXGMAC);
rtl_w1w0_eri(ioaddr, 0xdc, ERIAR_MASK_0001, 0x01, 0x00,
ERIAR_EXGMAC);
+ } else if (tp->mac_version == RTL_GIGA_MAC_VER_35 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_36) {
+ if (RTL_R8(PHYstatus) & _1000bpsF) {
+ rtl_eri_write(ioaddr, 0x1bc, ERIAR_MASK_1111,
+ 0x00000011, ERIAR_EXGMAC);
+ rtl_eri_write(ioaddr, 0x1dc, ERIAR_MASK_1111,
+ 0x00000005, ERIAR_EXGMAC);
+ } else {
+ rtl_eri_write(ioaddr, 0x1bc, ERIAR_MASK_1111,
+ 0x0000001f, ERIAR_EXGMAC);
+ rtl_eri_write(ioaddr, 0x1dc, ERIAR_MASK_1111,
+ 0x0000003f, ERIAR_EXGMAC);
+ }
}
}
@@ -1739,6 +1763,10 @@ static void rtl8169_get_mac_version(struct rtl8169_private *tp,
u32 val;
int mac_version;
} mac_info[] = {
+ /* 8168F family. */
+ { 0x7cf00000, 0x48100000, RTL_GIGA_MAC_VER_36 },
+ { 0x7cf00000, 0x48000000, RTL_GIGA_MAC_VER_35 },
+
/* 8168E family. */
{ 0x7c800000, 0x2c800000, RTL_GIGA_MAC_VER_34 },
{ 0x7cf00000, 0x2c200000, RTL_GIGA_MAC_VER_33 },
@@ -2873,6 +2901,97 @@ static void rtl8168e_2_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy(tp, 0x1f, 0x0000);
}
+static void rtl8168f_1_hw_phy_config(struct rtl8169_private *tp)
+{
+ static const struct phy_reg phy_reg_init[] = {
+ /* Channel estimation fine tune */
+ { 0x1f, 0x0003 },
+ { 0x09, 0xa20f },
+ { 0x1f, 0x0000 },
+
+ /* Modify green table for giga & fnet */
+ { 0x1f, 0x0005 },
+ { 0x05, 0x8b55 },
+ { 0x06, 0x0000 },
+ { 0x05, 0x8b5e },
+ { 0x06, 0x0000 },
+ { 0x05, 0x8b67 },
+ { 0x06, 0x0000 },
+ { 0x05, 0x8b70 },
+ { 0x06, 0x0000 },
+ { 0x1f, 0x0000 },
+ { 0x1f, 0x0007 },
+ { 0x1e, 0x0078 },
+ { 0x17, 0x0000 },
+ { 0x19, 0x00fb },
+ { 0x1f, 0x0000 },
+
+ /* Modify green table for 10M */
+ { 0x1f, 0x0005 },
+ { 0x05, 0x8b79 },
+ { 0x06, 0xaa00 },
+ { 0x1f, 0x0000 },
+
+ /* Disable hiimpedance detection (RTCT) */
+ { 0x1f, 0x0003 },
+ { 0x01, 0x328a },
+ { 0x1f, 0x0000 }
+ };
+
+ rtl_apply_firmware(tp);
+
+ rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
+
+ /* For 4-corner performance improve */
+ rtl_writephy(tp, 0x1f, 0x0005);
+ rtl_writephy(tp, 0x05, 0x8b80);
+ rtl_w1w0_phy(tp, 0x06, 0x0006, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+
+ /* PHY auto speed down */
+ rtl_writephy(tp, 0x1f, 0x0007);
+ rtl_writephy(tp, 0x1e, 0x002d);
+ rtl_w1w0_phy(tp, 0x18, 0x0010, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+ rtl_w1w0_phy(tp, 0x14, 0x8000, 0x0000);
+
+ /* improve 10M EEE waveform */
+ rtl_writephy(tp, 0x1f, 0x0005);
+ rtl_writephy(tp, 0x05, 0x8b86);
+ rtl_w1w0_phy(tp, 0x06, 0x0001, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+
+ /* Improve 2-pair detection performance */
+ rtl_writephy(tp, 0x1f, 0x0005);
+ rtl_writephy(tp, 0x05, 0x8b85);
+ rtl_w1w0_phy(tp, 0x06, 0x4000, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+}
+
+static void rtl8168f_2_hw_phy_config(struct rtl8169_private *tp)
+{
+ rtl_apply_firmware(tp);
+
+ /* For 4-corner performance improve */
+ rtl_writephy(tp, 0x1f, 0x0005);
+ rtl_writephy(tp, 0x05, 0x8b80);
+ rtl_w1w0_phy(tp, 0x06, 0x0006, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+
+ /* PHY auto speed down */
+ rtl_writephy(tp, 0x1f, 0x0007);
+ rtl_writephy(tp, 0x1e, 0x002d);
+ rtl_w1w0_phy(tp, 0x18, 0x0010, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+ rtl_w1w0_phy(tp, 0x14, 0x8000, 0x0000);
+
+ /* improve 10M EEE waveform */
+ rtl_writephy(tp, 0x1f, 0x0005);
+ rtl_writephy(tp, 0x05, 0x8b86);
+ rtl_w1w0_phy(tp, 0x06, 0x0001, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+}
+
static void rtl8102e_hw_phy_config(struct rtl8169_private *tp)
{
static const struct phy_reg phy_reg_init[] = {
@@ -2997,6 +3116,12 @@ static void rtl_hw_phy_config(struct net_device *dev)
case RTL_GIGA_MAC_VER_34:
rtl8168e_2_hw_phy_config(tp);
break;
+ case RTL_GIGA_MAC_VER_35:
+ rtl8168f_1_hw_phy_config(tp);
+ break;
+ case RTL_GIGA_MAC_VER_36:
+ rtl8168f_2_hw_phy_config(tp);
+ break;
default:
break;
@@ -3524,6 +3649,8 @@ static void __devinit rtl_init_pll_power_ops(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_32:
case RTL_GIGA_MAC_VER_33:
case RTL_GIGA_MAC_VER_34:
+ case RTL_GIGA_MAC_VER_35:
+ case RTL_GIGA_MAC_VER_36:
ops->down = r8168_pll_power_down;
ops->up = r8168_pll_power_up;
break;
@@ -3996,7 +4123,9 @@ static void rtl8169_hw_reset(struct rtl8169_private *tp)
tp->mac_version == RTL_GIGA_MAC_VER_31) {
while (RTL_R8(TxPoll) & NPQ)
udelay(20);
- } else if (tp->mac_version == RTL_GIGA_MAC_VER_34) {
+ } else if (tp->mac_version == RTL_GIGA_MAC_VER_34 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_35 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_36) {
RTL_W8(ChipCmd, RTL_R8(ChipCmd) | StopReq);
while (!(RTL_R32(TxConfig) & TXCFG_EMPTY))
udelay(100);
@@ -4482,6 +4611,49 @@ static void rtl_hw_start_8168e_2(void __iomem *ioaddr, struct pci_dev *pdev)
RTL_W8(Config5, RTL_R8(Config5) & ~Spi_en);
}
+static void rtl_hw_start_8168f_1(void __iomem *ioaddr, struct pci_dev *pdev)
+{
+ static const struct ephy_info e_info_8168f_1[] = {
+ { 0x06, 0x00c0, 0x0020 },
+ { 0x08, 0x0001, 0x0002 },
+ { 0x09, 0x0000, 0x0080 },
+ { 0x19, 0x0000, 0x0224 }
+ };
+
+ rtl_csi_access_enable_1(ioaddr);
+
+ rtl_ephy_init(ioaddr, e_info_8168f_1, ARRAY_SIZE(e_info_8168f_1));
+
+ rtl_tx_performance_tweak(pdev, 0x5 << MAX_READ_REQUEST_SHIFT);
+
+ rtl_eri_write(ioaddr, 0xc0, ERIAR_MASK_0011, 0x0000, ERIAR_EXGMAC);
+ rtl_eri_write(ioaddr, 0xb8, ERIAR_MASK_0011, 0x0000, ERIAR_EXGMAC);
+ rtl_eri_write(ioaddr, 0xc8, ERIAR_MASK_1111, 0x00100002, ERIAR_EXGMAC);
+ rtl_eri_write(ioaddr, 0xe8, ERIAR_MASK_1111, 0x00100006, ERIAR_EXGMAC);
+ rtl_w1w0_eri(ioaddr, 0xdc, ERIAR_MASK_0001, 0x00, 0x01, ERIAR_EXGMAC);
+ rtl_w1w0_eri(ioaddr, 0xdc, ERIAR_MASK_0001, 0x01, 0x00, ERIAR_EXGMAC);
+ rtl_w1w0_eri(ioaddr, 0x1b0, ERIAR_MASK_0001, 0x10, 0x00, ERIAR_EXGMAC);
+ rtl_w1w0_eri(ioaddr, 0x1d0, ERIAR_MASK_0001, 0x10, 0x00, ERIAR_EXGMAC);
+ rtl_eri_write(ioaddr, 0xcc, ERIAR_MASK_1111, 0x00000050, ERIAR_EXGMAC);
+ rtl_eri_write(ioaddr, 0xd0, ERIAR_MASK_1111, 0x00000060, ERIAR_EXGMAC);
+ rtl_w1w0_eri(ioaddr, 0x0d4, ERIAR_MASK_0011, 0x0c00, 0xff00,
+ ERIAR_EXGMAC);
+
+ RTL_W8(MaxTxPacketSize, EarlySize);
+
+ rtl_disable_clock_request(pdev);
+
+ RTL_W32(TxConfig, RTL_R32(TxConfig) | TXCFG_AUTO_FIFO);
+ RTL_W8(MCU, RTL_R8(MCU) & ~NOW_IS_OOB);
+
+ /* Adjust EEE LED frequency */
+ RTL_W8(EEE_LED, RTL_R8(EEE_LED) & ~0x07);
+
+ RTL_W8(DLLPR, RTL_R8(DLLPR) | PFM_EN);
+ RTL_W32(MISC, RTL_R32(MISC) | PWM_EN);
+ RTL_W8(Config5, RTL_R8(Config5) & ~Spi_en);
+}
+
static void rtl_hw_start_8168(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
@@ -4576,6 +4748,11 @@ static void rtl_hw_start_8168(struct net_device *dev)
rtl_hw_start_8168e_2(ioaddr, pdev);
break;
+ case RTL_GIGA_MAC_VER_35:
+ case RTL_GIGA_MAC_VER_36:
+ rtl_hw_start_8168f_1(ioaddr, pdev);
+ break;
+
default:
printk(KERN_ERR PFX "%s: unknown chipset (mac_version = %d).\n",
dev->name, tp->mac_version);
--
1.7.6
^ permalink raw reply related
* [PATCH net-next v4 2/4] r8169: define the early size for 8111evl
From: Hayes Wang @ 2011-09-02 9:49 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1314956953-1568-1-git-send-email-hayeswang@realtek.com>
For RTL8111EVL, the register of MaxTxPacketSize doesn't acctually
limit the tx size. It influnces the feature of early tx.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index aaae43e..db5ab2c 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -311,6 +311,7 @@ enum rtl_registers {
MaxTxPacketSize = 0xec, /* 8101/8168. Unit of 128 bytes. */
#define TxPacketMax (8064 >> 7)
+#define EarlySize 0x27
FuncEvent = 0xf0,
FuncEventMask = 0xf4,
@@ -4465,7 +4466,7 @@ static void rtl_hw_start_8168e_2(void __iomem *ioaddr, struct pci_dev *pdev)
rtl_w1w0_eri(ioaddr, 0x0d4, ERIAR_MASK_0011, 0x0c00, 0xff00,
ERIAR_EXGMAC);
- RTL_W8(MaxTxPacketSize, 0x27);
+ RTL_W8(MaxTxPacketSize, EarlySize);
rtl_disable_clock_request(pdev);
--
1.7.6
^ permalink raw reply related
* [PATCH net-next v4 3/4] r8169: fix the reset setting for 8111evl
From: Hayes Wang @ 2011-09-02 9:49 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1314956953-1568-1-git-send-email-hayeswang@realtek.com>
rtl8111evl should stop any TLP requirement before resetting by
enabling register 0x37 bit 7.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index db5ab2c..175c769 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3997,6 +3997,7 @@ static void rtl8169_hw_reset(struct rtl8169_private *tp)
while (RTL_R8(TxPoll) & NPQ)
udelay(20);
} else if (tp->mac_version == RTL_GIGA_MAC_VER_34) {
+ RTL_W8(ChipCmd, RTL_R8(ChipCmd) | StopReq);
while (!(RTL_R32(TxConfig) & TXCFG_EMPTY))
udelay(100);
} else {
--
1.7.6
^ permalink raw reply related
* [PATCH] af_packet: flush complete kernel cache in packet_sendmsg
From: Phil Sutter @ 2011-09-02 11:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: netdev, Russell King, David S. Miller
In-Reply-To: <20110505141107.GC30443@orbit.nwl.cc>
This flushes the cache before and after accessing the mmapped packet
buffer. It seems like the call to flush_dcache_page from inside
__packet_get_status is not enough on Kirkwood (or ARM in general).
---
I know this is far from an optimal solution, but it's in fact the only working
one I found. And it shouldn't interfere with unaffected target systems. So
anyone relying on a working TX_RING on Kirkwood may refer to this patch. Any
ARM/cache/Marvell/Kirkwood experts out there feel free to improve this.
---
net/packet/af_packet.c | 24 ++++++++++++++++++++----
1 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 243946d..d7b5c2e 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -87,6 +87,14 @@
#include <net/inet_common.h>
#endif
+/* whether we need additional cacheflushing between user- and kernel-space */
+#ifdef CONFIG_ARCH_KIRKWOOD
+# define ENABLE_CACHEPROB_WORKAROUND
+# define kw_extra_cache_flush() flush_cache_all()
+#else
+# define kw_extra_cache_flush() /* nothing */
+#endif
+
/*
Assumptions:
- if device has no dev->hard_header routine, it adds and removes ll header
@@ -1239,10 +1247,13 @@ static int packet_sendmsg(struct kiocb *iocb, struct socket *sock,
{
struct sock *sk = sock->sk;
struct packet_sock *po = pkt_sk(sk);
- if (po->tx_ring.pg_vec)
- return tpacket_snd(po, msg);
- else
- return packet_snd(sock, msg, len);
+ int rc;
+
+ kw_extra_cache_flush();
+ rc = po->tx_ring.pg_vec ? tpacket_snd(po, msg) :
+ packet_snd(sock, msg, len);
+ kw_extra_cache_flush();
+ return rc;
}
/*
@@ -2622,6 +2633,11 @@ static int __init packet_init(void)
sock_register(&packet_family_ops);
register_pernet_subsys(&packet_net_ops);
register_netdevice_notifier(&packet_netdev_notifier);
+
+#ifdef ENABLE_CACHEPROB_WORKAROUND
+ printk(KERN_INFO "af_packet: cache coherency workaround for kirkwood is active!\n");
+#endif
+
out:
return rc;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH] caif: fix a potential NULL dereference
From: Eric Dumazet @ 2011-09-02 12:19 UTC (permalink / raw)
To: Sjur Brændeland, David Miller; +Cc: netdev
In-Reply-To: <CAJK669Yb6V=xr9ZvQGOKGEvmzO1JGhrHD+sR69b04EQxUjOOrQ@mail.gmail.com>
Commit bd30ce4bc0b7 (caif: Use RCU instead of spin-lock in caif_dev.c)
added a potential NULL dereference in case alloc_percpu() fails.
caif_device_alloc() can also use GFP_KERNEL instead of GFP_ATOMIC.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Sjur Brændeland <sjur.brandeland@stericsson.com>
---
net/caif/caif_dev.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/caif/caif_dev.c b/net/caif/caif_dev.c
index 7c2fa0a..7f9ac07 100644
--- a/net/caif/caif_dev.c
+++ b/net/caif/caif_dev.c
@@ -93,10 +93,14 @@ static struct caif_device_entry *caif_device_alloc(struct net_device *dev)
caifdevs = caif_device_list(dev_net(dev));
BUG_ON(!caifdevs);
- caifd = kzalloc(sizeof(*caifd), GFP_ATOMIC);
+ caifd = kzalloc(sizeof(*caifd), GFP_KERNEL);
if (!caifd)
return NULL;
caifd->pcpu_refcnt = alloc_percpu(int);
+ if (!caifd->pcpu_refcnt) {
+ kfree(caifd);
+ return NULL;
+ }
caifd->netdev = dev;
dev_hold(dev);
return caifd;
^ permalink raw reply related
* [patch net-next-2.6 v2] net: consolidate and fix ethtool_ops->get_settings calling
From: Jiri Pirko @ 2011-09-02 12:26 UTC (permalink / raw)
To: netdev
Cc: ralf, fubar, andy, kaber, bprakash, JBottomley, robert.w.love,
davem, shemminger, decot, bhutchings, mirq-linux,
alexander.h.duyck, amit.salecha, eric.dumazet, therbert, paulmck,
laijs, xiaosuo, greearb, loke.chetan, linux-mips, linux-scsi,
devel, bridge
In-Reply-To: <1314905304-16485-1-git-send-email-jpirko@redhat.com>
This patch does several things:
- introduces __ethtool_get_settings which is called from ethtool code and
from dev_ethtool_get_settings() as well.
- dev_ethtool_get_settings() becomes rtnl wrapper for
__ethtool_get_settings()
- changes calling in drivers so rtnl locking is respected. In
iboe_get_rate was previously ->get_settings() called unlocked. This
fixes it
- introduces rtnl_lock in bnx2fc_vport_create() and fcoe_vport_create()
so bnx2fc_if_create() and fcoe_if_create() are called locked as they
are from other places.
- prb_calc_retire_blk_tmo() in af_packet.c was not calling get_settings
with rntl_lock. So use dev_ethtool_get_settings here.
- use __ethtool_get_settings() in bonding code
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
v1->v2:
add missing export_symbol
---
arch/mips/txx9/generic/setup_tx4939.c | 2 +-
drivers/net/bonding/bond_main.c | 13 ++++------
drivers/net/macvlan.c | 3 +-
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 4 ++-
drivers/scsi/fcoe/fcoe.c | 4 ++-
include/linux/ethtool.h | 3 ++
net/8021q/vlan_dev.c | 3 +-
net/bridge/br_if.c | 2 +-
net/core/dev.c | 17 +++++---------
net/core/ethtool.c | 18 ++++++++++----
net/core/net-sysfs.c | 4 +-
net/packet/af_packet.c | 41 +++++++++++++++-----------------
12 files changed, 60 insertions(+), 54 deletions(-)
diff --git a/arch/mips/txx9/generic/setup_tx4939.c b/arch/mips/txx9/generic/setup_tx4939.c
index e9f95dc..ba3cec3 100644
--- a/arch/mips/txx9/generic/setup_tx4939.c
+++ b/arch/mips/txx9/generic/setup_tx4939.c
@@ -321,7 +321,7 @@ void __init tx4939_sio_init(unsigned int sclk, unsigned int cts_mask)
static u32 tx4939_get_eth_speed(struct net_device *dev)
{
struct ethtool_cmd cmd;
- if (dev_ethtool_get_settings(dev, &cmd))
+ if (__ethtool_get_settings(dev, &cmd))
return 100; /* default 100Mbps */
return ethtool_cmd_speed(&cmd);
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 8cb75a6..1dcb07c 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -557,7 +557,7 @@ down:
static int bond_update_speed_duplex(struct slave *slave)
{
struct net_device *slave_dev = slave->dev;
- struct ethtool_cmd etool = { .cmd = ETHTOOL_GSET };
+ struct ethtool_cmd ecmd;
u32 slave_speed;
int res;
@@ -565,18 +565,15 @@ static int bond_update_speed_duplex(struct slave *slave)
slave->speed = SPEED_100;
slave->duplex = DUPLEX_FULL;
- if (!slave_dev->ethtool_ops || !slave_dev->ethtool_ops->get_settings)
- return -1;
-
- res = slave_dev->ethtool_ops->get_settings(slave_dev, &etool);
+ res = __ethtool_get_settings(slave_dev, &ecmd);
if (res < 0)
return -1;
- slave_speed = ethtool_cmd_speed(&etool);
+ slave_speed = ethtool_cmd_speed(&ecmd);
if (slave_speed == 0 || slave_speed == ((__u32) -1))
return -1;
- switch (etool.duplex) {
+ switch (ecmd.duplex) {
case DUPLEX_FULL:
case DUPLEX_HALF:
break;
@@ -585,7 +582,7 @@ static int bond_update_speed_duplex(struct slave *slave)
}
slave->speed = slave_speed;
- slave->duplex = etool.duplex;
+ slave->duplex = ecmd.duplex;
return 0;
}
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 836e13f..b100c90 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -543,7 +543,8 @@ static int macvlan_ethtool_get_settings(struct net_device *dev,
struct ethtool_cmd *cmd)
{
const struct macvlan_dev *vlan = netdev_priv(dev);
- return dev_ethtool_get_settings(vlan->lowerdev, cmd);
+
+ return __ethtool_get_settings(vlan->lowerdev, cmd);
}
static const struct ethtool_ops macvlan_ethtool_ops = {
diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index 2c780a7..820a184 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -673,7 +673,7 @@ static void bnx2fc_link_speed_update(struct fc_lport *lport)
struct net_device *netdev = interface->netdev;
struct ethtool_cmd ecmd;
- if (!dev_ethtool_get_settings(netdev, &ecmd)) {
+ if (!__ethtool_get_settings(netdev, &ecmd)) {
lport->link_supported_speeds &=
~(FC_PORTSPEED_1GBIT | FC_PORTSPEED_10GBIT);
if (ecmd.supported & (SUPPORTED_1000baseT_Half |
@@ -1001,9 +1001,11 @@ static int bnx2fc_vport_create(struct fc_vport *vport, bool disabled)
"this interface\n");
return -EIO;
}
+ rtnl_lock();
mutex_lock(&bnx2fc_dev_lock);
vn_port = bnx2fc_if_create(interface, &vport->dev, 1);
mutex_unlock(&bnx2fc_dev_lock);
+ rtnl_unlock();
if (IS_ERR(vn_port)) {
printk(KERN_ERR PFX "bnx2fc_vport_create (%s) failed\n",
diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
index 3416ab6..83aa3ac 100644
--- a/drivers/scsi/fcoe/fcoe.c
+++ b/drivers/scsi/fcoe/fcoe.c
@@ -2043,7 +2043,7 @@ int fcoe_link_speed_update(struct fc_lport *lport)
struct net_device *netdev = fcoe_netdev(lport);
struct ethtool_cmd ecmd;
- if (!dev_ethtool_get_settings(netdev, &ecmd)) {
+ if (!__ethtool_get_settings(netdev, &ecmd)) {
lport->link_supported_speeds &=
~(FC_PORTSPEED_1GBIT | FC_PORTSPEED_10GBIT);
if (ecmd.supported & (SUPPORTED_1000baseT_Half |
@@ -2452,7 +2452,9 @@ static int fcoe_vport_create(struct fc_vport *vport, bool disabled)
}
mutex_lock(&fcoe_config_mutex);
+ rtnl_lock();
vn_port = fcoe_if_create(fcoe, &vport->dev, 1);
+ rtnl_unlock();
mutex_unlock(&fcoe_config_mutex);
if (IS_ERR(vn_port)) {
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 3829712..8571f18 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -728,6 +728,9 @@ enum ethtool_sfeatures_retval_bits {
/* needed by dev_disable_lro() */
extern int __ethtool_set_flags(struct net_device *dev, u32 flags);
+extern int __ethtool_get_settings(struct net_device *dev,
+ struct ethtool_cmd *cmd);
+
/**
* enum ethtool_phys_id_state - indicator state for physical identification
* @ETHTOOL_ID_INACTIVE: Physical ID indicator should be deactivated
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index eba705b..c8cf939 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -610,7 +610,8 @@ static int vlan_ethtool_get_settings(struct net_device *dev,
struct ethtool_cmd *cmd)
{
const struct vlan_dev_info *vlan = vlan_dev_info(dev);
- return dev_ethtool_get_settings(vlan->real_dev, cmd);
+
+ return __ethtool_get_settings(vlan->real_dev, cmd);
}
static void vlan_ethtool_get_drvinfo(struct net_device *dev,
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index b365bba..043a5eb 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -35,7 +35,7 @@ static int port_cost(struct net_device *dev)
{
struct ethtool_cmd ecmd;
- if (!dev_ethtool_get_settings(dev, &ecmd)) {
+ if (!__ethtool_get_settings(dev, &ecmd)) {
switch (ethtool_cmd_speed(&ecmd)) {
case SPEED_10000:
return 2;
diff --git a/net/core/dev.c b/net/core/dev.c
index 11b0fc7..abdc0e3 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4570,22 +4570,17 @@ void dev_set_rx_mode(struct net_device *dev)
* @dev: device
* @cmd: memory area for ethtool_ops::get_settings() result
*
- * The cmd arg is initialized properly (cleared and
- * ethtool_cmd::cmd field set to ETHTOOL_GSET).
- *
- * Return device's ethtool_ops::get_settings() result value or
- * -EOPNOTSUPP when device doesn't expose
- * ethtool_ops::get_settings() operation.
+ * This is wrapper taking rtnl lock for __ethtool_get_settings()
*/
int dev_ethtool_get_settings(struct net_device *dev,
struct ethtool_cmd *cmd)
{
- if (!dev->ethtool_ops || !dev->ethtool_ops->get_settings)
- return -EOPNOTSUPP;
+ int ret;
- memset(cmd, 0, sizeof(struct ethtool_cmd));
- cmd->cmd = ETHTOOL_GSET;
- return dev->ethtool_ops->get_settings(dev, cmd);
+ rtnl_lock();
+ ret = __ethtool_get_settings(dev, cmd);
+ rtnl_unlock();
+ return ret;
}
EXPORT_SYMBOL(dev_ethtool_get_settings);
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 6cdba5f..307297c 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -569,15 +569,23 @@ int __ethtool_set_flags(struct net_device *dev, u32 data)
return 0;
}
+int __ethtool_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+ if (!dev->ethtool_ops || !dev->ethtool_ops->get_settings)
+ return -EOPNOTSUPP;
+
+ memset(cmd, 0, sizeof(struct ethtool_cmd));
+ cmd->cmd = ETHTOOL_GSET;
+ return dev->ethtool_ops->get_settings(dev, cmd);
+}
+EXPORT_SYMBOL(__ethtool_get_settings);
+
static int ethtool_get_settings(struct net_device *dev, void __user *useraddr)
{
- struct ethtool_cmd cmd = { .cmd = ETHTOOL_GSET };
int err;
+ struct ethtool_cmd cmd;
- if (!dev->ethtool_ops->get_settings)
- return -EOPNOTSUPP;
-
- err = dev->ethtool_ops->get_settings(dev, &cmd);
+ err = __ethtool_get_settings(dev, &cmd);
if (err < 0)
return err;
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 90fdb46..48e6279 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -172,7 +172,7 @@ static ssize_t show_speed(struct device *dev,
if (netif_running(netdev)) {
struct ethtool_cmd cmd;
- if (!dev_ethtool_get_settings(netdev, &cmd))
+ if (!__ethtool_get_settings(netdev, &cmd))
ret = sprintf(buf, fmt_udec, ethtool_cmd_speed(&cmd));
}
rtnl_unlock();
@@ -190,7 +190,7 @@ static ssize_t show_duplex(struct device *dev,
if (netif_running(netdev)) {
struct ethtool_cmd cmd;
- if (!dev_ethtool_get_settings(netdev, &cmd))
+ if (!__ethtool_get_settings(netdev, &cmd))
ret = sprintf(buf, "%s\n",
cmd.duplex ? "full" : "half");
}
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 2ea3d63..1bcc794 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -530,33 +530,30 @@ static int prb_calc_retire_blk_tmo(struct packet_sock *po,
{
struct net_device *dev;
unsigned int mbits = 0, msec = 0, div = 0, tmo = 0;
+ struct ethtool_cmd ecmd;
dev = dev_get_by_index(sock_net(&po->sk), po->ifindex);
if (unlikely(dev == NULL))
return DEFAULT_PRB_RETIRE_TOV;
- if (dev->ethtool_ops && dev->ethtool_ops->get_settings) {
- struct ethtool_cmd ecmd = { .cmd = ETHTOOL_GSET, };
-
- if (!dev->ethtool_ops->get_settings(dev, &ecmd)) {
- switch (ecmd.speed) {
- case SPEED_10000:
- msec = 1;
- div = 10000/1000;
- break;
- case SPEED_1000:
- msec = 1;
- div = 1000/1000;
- break;
- /*
- * If the link speed is so slow you don't really
- * need to worry about perf anyways
- */
- case SPEED_100:
- case SPEED_10:
- default:
- return DEFAULT_PRB_RETIRE_TOV;
- }
+ if (!dev_ethtool_get_settings(dev, &ecmd)) {
+ switch (ecmd.speed) {
+ case SPEED_10000:
+ msec = 1;
+ div = 10000/1000;
+ break;
+ case SPEED_1000:
+ msec = 1;
+ div = 1000/1000;
+ break;
+ /*
+ * If the link speed is so slow you don't really
+ * need to worry about perf anyways
+ */
+ case SPEED_100:
+ case SPEED_10:
+ default:
+ return DEFAULT_PRB_RETIRE_TOV;
}
}
--
1.7.6
^ permalink raw reply related
* Re: [linux-firmware v4 1/2] rtl_nic: update firmware for RTL8111E-VL
From: Ben Hutchings @ 2011-09-02 13:15 UTC (permalink / raw)
To: Hayes Wang; +Cc: dwmw2, romieu, netdev
In-Reply-To: <1314860833-4000-1-git-send-email-hayeswang@realtek.com>
[-- Attachment #1: Type: text/plain, Size: 143 bytes --]
On Thu, 2011-09-01 at 15:07 +0800, Hayes Wang wrote:
> Updated firmware with stability fixes.
> Version: 0.0.2
[...]
Applied.
Ben.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [linux-firmware v4 2/2] rtl_nic: add new firmware for RTL8111F
From: Ben Hutchings @ 2011-09-02 13:16 UTC (permalink / raw)
To: Hayes Wang; +Cc: dwmw2, romieu, netdev
In-Reply-To: <1314860833-4000-2-git-send-email-hayeswang@realtek.com>
[-- Attachment #1: Type: text/plain, Size: 306 bytes --]
On Thu, 2011-09-01 at 15:07 +0800, Hayes Wang wrote:
> Add new firmware:
> 1. rtl_nic/rtl8168f-1.fw
> version: 0.0.2
> 2. rtl_nic/rtl8168f-2.fw
> version: 0.0.2
[...]
Applied. (And please do send firmware files to me as well as David; we
can both commit to linux-firmware.git.)
Ben.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] caif: fix a potential NULL dereference
From: Sjur Brændeland @ 2011-09-02 13:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1314965963.2573.23.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Eric Dumazet wrote:
> Commit bd30ce4bc0b7 (caif: Use RCU instead of spin-lock in caif_dev.c)
> added a potential NULL dereference in case alloc_percpu() fails.
>
> caif_device_alloc() can also use GFP_KERNEL instead of GFP_ATOMIC.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Looks good thanks,
Acked-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
^ permalink raw reply
* Re: [PATCH] af_packet: flush complete kernel cache in packet_sendmsg
From: Ben Hutchings @ 2011-09-02 13:46 UTC (permalink / raw)
To: Phil Sutter; +Cc: linux-arm-kernel, netdev, Russell King, David S. Miller
In-Reply-To: <1314961686-30870-1-git-send-email-phil.sutter@viprinet.com>
On Fri, 2011-09-02 at 13:08 +0200, Phil Sutter wrote:
> This flushes the cache before and after accessing the mmapped packet
> buffer. It seems like the call to flush_dcache_page from inside
> __packet_get_status is not enough on Kirkwood (or ARM in general).
> ---
> I know this is far from an optimal solution, but it's in fact the only working
> one I found.
[...]
This is ridiculous. If flush_dcache_page() isn't doing everything it
should, you need to fix that.
Ben.
--
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
* Re: [PATCH] af_packet: flush complete kernel cache in packet_sendmsg
From: Phil Sutter @ 2011-09-02 13:59 UTC (permalink / raw)
To: Ben Hutchings; +Cc: linux-arm-kernel, netdev, Russell King, David S. Miller
In-Reply-To: <1314971179.3092.159.camel@deadeye>
On Fri, Sep 02, 2011 at 02:46:17PM +0100, Ben Hutchings wrote:
> On Fri, 2011-09-02 at 13:08 +0200, Phil Sutter wrote:
> > This flushes the cache before and after accessing the mmapped packet
> > buffer. It seems like the call to flush_dcache_page from inside
> > __packet_get_status is not enough on Kirkwood (or ARM in general).
> > ---
> > I know this is far from an optimal solution, but it's in fact the only working
> > one I found.
> [...]
>
> This is ridiculous. If flush_dcache_page() isn't doing everything it
> should, you need to fix that.
You're absolutely correct. But in fact this problem goes way too deep
for me to find it's cause. And since my time is finite, I doubt this
will change in the near future. So I asked for help, a pointer in
whatever direction or anything I could try to help further analyzing -
without any response (unless I missed it, in which case I apologize).
Please don't get me wrong. I have no intend in this patch becoming
mainline, just want to give others with the same problem a starting
point.
Greetings, Phil
--
Viprinet GmbH
Mainzer Str. 43
55411 Bingen am Rhein
Germany
Zentrale: +49-6721-49030-0
Durchwahl: +49-6721-49030-134
Fax: +49-6721-49030-209
phil.sutter@viprinet.com
http://www.viprinet.com
Sitz der Gesellschaft: Bingen am Rhein
Handelsregister: Amtsgericht Mainz HRB40380
Geschäftsführer: Simon Kissel
^ permalink raw reply
* Re: FW: [PATCH] af_packet: flush complete kernel cache in packet_sendmsg
From: chetan loke @ 2011-09-02 14:00 UTC (permalink / raw)
To: phil.sutter, linux-arm-kernel; +Cc: netdev, linux, davem
In-Reply-To: <D3F292ADF945FB49B35E96C94C2061B90A239361@nsmail.netscout.com>
>
> This flushes the cache before and after accessing the mmapped packet
> buffer. It seems like the call to flush_dcache_page from inside
> __packet_get_status is not enough on Kirkwood (or ARM in general).
> + kw_extra_cache_flush();
> + rc = po->tx_ring.pg_vec ? tpacket_snd(po, msg) :
> + packet_snd(sock, msg, len);
> + kw_extra_cache_flush();
> + return rc;
> }
If a workaround is needed for mmap, then why not change tpacket_snd?
Also, is this workaround actually working for all the cases? Because
packet_get_status is not being touched in your patch.
Also, I don't see any changes for the Rx-path. Is that working ok?
Chetan Loke
^ permalink raw reply
* [PATCH] ixgbe: drop zero length frame segments during a packet split rx
From: Neil Horman @ 2011-09-02 14:03 UTC (permalink / raw)
To: netdev
Cc: Neil Horman, Thadeu Lima de Souza Cascardo, Jesse Brandeburg,
Alexander Duyck, John Fastabend, Jeff Kirsher, David S. Miller
This oops was reported recently no ppc64 hardware:
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc0000000004dda0c
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
iptable_fi
lter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state
nf_conntrack ip6table_filter ip6_tables ipv6 jsm ses enclosure sg ixgbe
mdio e1000 ehea ext4 jbd2 mbcache sd_mod crc_t10dif ipr dm_mod
NIP: c0000000004dda0c LR: c0000000004e3e50 CTR: c0000000004e3e20
REGS: c0000001bffeb8d0 TRAP: 0300 Not tainted (3.1.0-rc2-10121-gab7e2db)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 28002042 XER: 20000000
CFAR: c000000000004d70
DAR: 0000000000000000, DSISR: 40000000
TASK = c000000000d548e0[0] 'swapper' THREAD: c000000000dfc000 CPU: 0
GPR04: c0000000010f4d80 c0000001bffebd80 0000000000000000 c0000001b18a8200
GPR08: 0000000000000280 c0000001bcc517a8 c0000001b18a7f80 0000000000000000
GPR12: d0000000047e5bb0 c000000001f10000 c0000001b19c8700 0000000000000000
GPR16: c0000001bffebd80 0000000000000083 c00000018f2447a0 0000000000000002
GPR20: 0000000000000000 c0000001ba860010 c0000001ba860000 d000000003d40000
GPR24: 0000000000000000 0000000000000083 d000000003d40000 0000000000000001
GPR28: c00000018f244780 c0000001b2b94310 c000000000da95f0 c0000001bcc51780
NIP [c0000000004dda0c] .skb_gro_reset_offset+0x5c/0xe0
LR [c0000000004e3e50] .napi_gro_receive+0x30/0x120
Call Trace:
[c0000001bffebb50] [c000000000da95f0] perf_callchain_user+0x0/0x10 (unreliable)
[c0000001bffebbf0] [d0000000047bd118] .ixgbe_clean_rx_irq+0x7a8/0x8a0 [ixgbe]
[c0000001bffebd10] [d0000000047bd414] .ixgbe_poll+0x64/0x160 [ixgbe]
[c0000001bffebdd0] [c0000000004e3358] .net_rx_action+0x108/0x2a0
[c0000001bffebea0] [c00000000009b220] .__do_softirq+0x110/0x2a0
[c0000001bffebf90] [c000000000023798] .call_do_softirq+0x14/0x24
[c000000000dff830] [c000000000011148] .do_softirq+0xf8/0x130
[c000000000dff8d0] [c00000000009aeb4] .irq_exit+0xb4/0xc0
[c000000000dff950] [c000000000011254] .do_IRQ+0xd4/0x300
[c000000000dffa10] [c000000000005024] hardware_interrupt_entry+0x18/0x74
--- Exception: 501 at .pseries_dedicated_idle_sleep+0xe4/0x210
LR = .pseries_dedicated_idle_sleep+0x8c/0x210
[c000000000dffd00] [c00000000005b194] .pseries_dedicated_idle_sleep+0x194/0x210
(unreliable)
[c000000000dffdc0] [c000000000018c84] .cpu_idle+0x164/0x210
[c000000000dffe70] [c00000000000b0d0] .rest_init+0x90/0xb0
[c000000000dffef0] [c000000000830bc0] .start_kernel+0x54c/0x56c
[c000000000dfff90] [c00000000000953c] .start_here_common+0x1c/0x60
Its caused when skb_gro_reset_offset attempts to call PageHighMem on
skb_shinfo(skb)->frags[0].page, when the frags array was left uninitalized.
This can happen in the ixgbe driver if the hardware reports a zero length rx
descriptor ni the middle of a packet split receive transaction. I've consulted
with Jesse Brandeburg on this, who is attempting to root cause the issue at
Intel, but it seems prudent to add this check to the driver to discard frames of
that encounter this error to avoid the opps
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: Alexander Duyck <alexander.h.duyck@intel.com>
CC: John Fastabend <john.r.fastabend@intel.com>
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
CC: David S. Miller <davem@davemloft.net>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index d20e804..6d59185 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1326,6 +1326,13 @@ static void ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
rx_buffer_info = &rx_ring->rx_buffer_info[i];
+ i++;
+ if (i == rx_ring->count)
+ i = 0;
+
+ next_rxd = IXGBE_RX_DESC_ADV(rx_ring, i);
+ prefetch(next_rxd);
+
skb = rx_buffer_info->skb;
rx_buffer_info->skb = NULL;
prefetch(skb->data);
@@ -1367,6 +1374,10 @@ static void ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
} else {
/* assume packet split since header is unmapped */
upper_len = le16_to_cpu(rx_desc->wb.upper.length);
+ if (!upper_len) {
+ rx_buffer_info->skb = skb;
+ goto next_desc;
+ }
}
if (upper_len) {
@@ -1391,12 +1402,6 @@ static void ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
skb->truesize += upper_len;
}
- i++;
- if (i == rx_ring->count)
- i = 0;
-
- next_rxd = IXGBE_RX_DESC_ADV(rx_ring, i);
- prefetch(next_rxd);
cleaned_count++;
if (pkt_is_rsc) {
--
1.7.6
^ permalink raw reply related
* Re: FW: [PATCH] af_packet: flush complete kernel cache in packet_sendmsg
From: Phil Sutter @ 2011-09-02 15:31 UTC (permalink / raw)
To: chetan loke; +Cc: linux-arm-kernel, netdev, linux, davem
In-Reply-To: <CAAsGZS6Tt9FLXfanH1+DgKt_9gR_YPJ8kX_pryhnzWTQVkNkNw@mail.gmail.com>
On Fri, Sep 02, 2011 at 10:00:16AM -0400, chetan loke wrote:
> >
> > This flushes the cache before and after accessing the mmapped packet
> > buffer. It seems like the call to flush_dcache_page from inside
> > __packet_get_status is not enough on Kirkwood (or ARM in general).
>
>
>
> > + kw_extra_cache_flush();
> > + rc = po->tx_ring.pg_vec ? tpacket_snd(po, msg) :
> > + packet_snd(sock, msg, len);
> > + kw_extra_cache_flush();
> > + return rc;
> > }
>
> If a workaround is needed for mmap, then why not change tpacket_snd?
I did not verify that packet_snd() is not affected. OTOH, adding it
there was quite "intuitive".
> Also, is this workaround actually working for all the cases? Because
> packet_get_status is not being touched in your patch.
>
> Also, I don't see any changes for the Rx-path. Is that working ok?
So far we haven't noticed problems in that direction. I just tried some
explicit test: having tcpdump print local timestamps (not the pcap-ones)
on every received packet, activating icmp_echo_ignore_all and pinging
the host on a dedicated line. I expected to sometimes see a second
difference between the two timestamps, as like with sending from time to
time a packet should get "lost" in the cache, and then occur to
userspace after the next one arrived. Maybe my test is broken, or RX is
indeed unaffected.
Greetings and thanks for the hints, Phil
--
Viprinet GmbH
Mainzer Str. 43
55411 Bingen am Rhein
Germany
Zentrale: +49-6721-49030-0
Durchwahl: +49-6721-49030-134
Fax: +49-6721-49030-209
phil.sutter@viprinet.com
http://www.viprinet.com
Sitz der Gesellschaft: Bingen am Rhein
Handelsregister: Amtsgericht Mainz HRB40380
Geschäftsführer: Simon Kissel
^ permalink raw reply
* Re: [patch -next] caif: add error handling for allocation
From: Dan Carpenter @ 2011-09-02 15:51 UTC (permalink / raw)
To: Sjur Brændeland
Cc: David S. Miller, open list:CAIF NETWORK LAYER, kernel-janitors
In-Reply-To: <CAJK669Yb6V=xr9ZvQGOKGEvmzO1JGhrHD+sR69b04EQxUjOOrQ@mail.gmail.com>
On Fri, Sep 02, 2011 at 11:40:23AM +0200, Sjur Brændeland wrote:
> Thank you for your patch.
> When reviewing this I found another potential memory leak as well.
> If cffrml_create fails, we might be leaking the phy_driver.
> So perhaps you could do kfree(phy_driver) in out_err: as well, while
> you are at it?
>
Good point. A kfree(phy_driver) would fix the leak. But why does
cfserl_create() return &this->layer; instead of just "return this;"
Their equivalent now, but if you change the cfserl struct it will
break the kfree().
I'll be travelling for a while, so I may be out of reach until
Wednessday.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] ixgbe: drop zero length frame segments during a packet split rx
From: Jeff Kirsher @ 2011-09-02 16:04 UTC (permalink / raw)
To: Neil Horman
Cc: netdev@vger.kernel.org, Thadeu Lima de Souza Cascardo,
Brandeburg, Jesse, Duyck, Alexander H, Fastabend, John R,
David S. Miller
In-Reply-To: <1314972197-31557-1-git-send-email-nhorman@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 4094 bytes --]
On Fri, 2011-09-02 at 07:03 -0700, Neil Horman wrote:
> This oops was reported recently no ppc64 hardware:
> Unable to handle kernel paging request for data at address 0x00000000
> Faulting instruction address: 0xc0000000004dda0c
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=1024 NUMA pSeries
> Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
> iptable_fi
> lter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state
> nf_conntrack ip6table_filter ip6_tables ipv6 jsm ses enclosure sg
> ixgbe
> mdio e1000 ehea ext4 jbd2 mbcache sd_mod crc_t10dif ipr dm_mod
> NIP: c0000000004dda0c LR: c0000000004e3e50 CTR: c0000000004e3e20
> REGS: c0000001bffeb8d0 TRAP: 0300 Not tainted
> (3.1.0-rc2-10121-gab7e2db)
> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 28002042 XER: 20000000
> CFAR: c000000000004d70
> DAR: 0000000000000000, DSISR: 40000000
> TASK = c000000000d548e0[0] 'swapper' THREAD: c000000000dfc000 CPU: 0
> GPR04: c0000000010f4d80 c0000001bffebd80 0000000000000000
> c0000001b18a8200
> GPR08: 0000000000000280 c0000001bcc517a8 c0000001b18a7f80
> 0000000000000000
> GPR12: d0000000047e5bb0 c000000001f10000 c0000001b19c8700
> 0000000000000000
> GPR16: c0000001bffebd80 0000000000000083 c00000018f2447a0
> 0000000000000002
> GPR20: 0000000000000000 c0000001ba860010 c0000001ba860000
> d000000003d40000
> GPR24: 0000000000000000 0000000000000083 d000000003d40000
> 0000000000000001
> GPR28: c00000018f244780 c0000001b2b94310 c000000000da95f0
> c0000001bcc51780
> NIP [c0000000004dda0c] .skb_gro_reset_offset+0x5c/0xe0
> LR [c0000000004e3e50] .napi_gro_receive+0x30/0x120
> Call Trace:
> [c0000001bffebb50] [c000000000da95f0] perf_callchain_user+0x0/0x10
> (unreliable)
> [c0000001bffebbf0] [d0000000047bd118] .ixgbe_clean_rx_irq+0x7a8/0x8a0
> [ixgbe]
> [c0000001bffebd10] [d0000000047bd414] .ixgbe_poll+0x64/0x160 [ixgbe]
> [c0000001bffebdd0] [c0000000004e3358] .net_rx_action+0x108/0x2a0
> [c0000001bffebea0] [c00000000009b220] .__do_softirq+0x110/0x2a0
> [c0000001bffebf90] [c000000000023798] .call_do_softirq+0x14/0x24
> [c000000000dff830] [c000000000011148] .do_softirq+0xf8/0x130
> [c000000000dff8d0] [c00000000009aeb4] .irq_exit+0xb4/0xc0
> [c000000000dff950] [c000000000011254] .do_IRQ+0xd4/0x300
> [c000000000dffa10] [c000000000005024] hardware_interrupt_entry
> +0x18/0x74
> --- Exception: 501 at .pseries_dedicated_idle_sleep+0xe4/0x210
> LR = .pseries_dedicated_idle_sleep+0x8c/0x210
> [c000000000dffd00] [c00000000005b194] .pseries_dedicated_idle_sleep
> +0x194/0x210
> (unreliable)
> [c000000000dffdc0] [c000000000018c84] .cpu_idle+0x164/0x210
> [c000000000dffe70] [c00000000000b0d0] .rest_init+0x90/0xb0
> [c000000000dffef0] [c000000000830bc0] .start_kernel+0x54c/0x56c
> [c000000000dfff90] [c00000000000953c] .start_here_common+0x1c/0x60
>
> Its caused when skb_gro_reset_offset attempts to call PageHighMem on
> skb_shinfo(skb)->frags[0].page, when the frags array was left
> uninitalized.
> This can happen in the ixgbe driver if the hardware reports a zero
> length rx
> descriptor ni the middle of a packet split receive transaction. I've
> consulted
> with Jesse Brandeburg on this, who is attempting to root cause the
> issue at
> Intel, but it seems prudent to add this check to the driver to discard
> frames of
> that encounter this error to avoid the opps
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Signed-off-by: Thadeu Lima de Souza Cascardo
> <cascardo@linux.vnet.ibm.com>
> CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
> CC: Alexander Duyck <alexander.h.duyck@intel.com>
> CC: John Fastabend <john.r.fastabend@intel.com>
> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> CC: David S. Miller <davem@davemloft.net>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 17
> +++++++++++------
> 1 files changed, 11 insertions(+), 6 deletions(-)
Thanks Neil, I have added the patch to my queue of ixgbe patches.
This patch was made against net-next, was this issue only seen on the
net-next kernel?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [next] unix stream crashes
From: Valdis.Kletnieks @ 2011-09-02 16:12 UTC (permalink / raw)
To: Tim Chen; +Cc: Jiri Slaby, David S. Miller, ML netdev, LKML
In-Reply-To: <1314927645.2576.2939.camel@schen9-DESK>
[-- Attachment #1.1: Type: text/plain, Size: 750 bytes --]
On Thu, 01 Sep 2011 18:40:45 PDT, Tim Chen said:
> Yes, Jiri's log does indicate that something went wrong when releasing
> the skb, most likely due to changes in the pid and credentials ref
> count. Unfortunately, I cannot duplicate the problem on my system. Any
> info on your system to help me debug will be appreciated. I'll try to
> take another look at the patch tomorrow.
Dell Latitude E6500, Core2 T8700 processor, x86_64 kernel, a slightly mangled
Fedora Rawhide userspace. I'd not be surprised if there's an idiocyncratic
setting in my .config that makes the bug crawl out of the woodwork on my box,
so I'm attaching the .config in case it provides some enlightenment.
If you want me to try a debugging or test patch, let me know...
[-- Attachment #1.2: config.gz --]
[-- Type: application/x-gzip , Size: 18974 bytes --]
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [PATCH] ixgbe: drop zero length frame segments during a packet split rx
From: Alexander Duyck @ 2011-09-02 16:17 UTC (permalink / raw)
To: Neil Horman
Cc: netdev, Thadeu Lima de Souza Cascardo, Jesse Brandeburg,
John Fastabend, Jeff Kirsher, David S. Miller
In-Reply-To: <1314972197-31557-1-git-send-email-nhorman@tuxdriver.com>
This kind of fix just opens up a whole can of security related worms.
If you are going to discard a packet you should do it after we have
reached the EOP in the series. My advice would be to determine what
traits identify this packet and add those to the check for the
IXGBE_RXDADV_ERR_FRAME_ERR_MASK check further down in the code. Likely
what you are seeing is skb_headlen(skb) will be equal to 0.
I'm suspecting this is some sort of read corruption. It looks like in
order to trigger it you have to either be reading rx_buffer_info->dma as
0, or the header length is being read as 0. Do you know if you actually
have header split enabled when this is occuring? Are you running with
jumbo frames enabled to see the issue? If not then packet split
wouldn't be enabled.
Is this occurring on net-next or on an older kernel? I just want to be
sure since we added a read memory barrier in 2.6.34 to address the fact
that the length and descriptor DD bits were being read in the wrong
order resulting in the length being corrupted on PowerPC systems. The
fact that we are now seeing another length error on PowerPC seems very odd.
Thanks,
Alex
On 09/02/2011 07:03 AM, Neil Horman wrote:
> This oops was reported recently no ppc64 hardware:
> Unable to handle kernel paging request for data at address 0x00000000
> Faulting instruction address: 0xc0000000004dda0c
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=1024 NUMA pSeries
> Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
> iptable_fi
> lter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state
> nf_conntrack ip6table_filter ip6_tables ipv6 jsm ses enclosure sg ixgbe
> mdio e1000 ehea ext4 jbd2 mbcache sd_mod crc_t10dif ipr dm_mod
> NIP: c0000000004dda0c LR: c0000000004e3e50 CTR: c0000000004e3e20
> REGS: c0000001bffeb8d0 TRAP: 0300 Not tainted (3.1.0-rc2-10121-gab7e2db)
> MSR: 8000000000009032<EE,ME,IR,DR> CR: 28002042 XER: 20000000
> CFAR: c000000000004d70
> DAR: 0000000000000000, DSISR: 40000000
> TASK = c000000000d548e0[0] 'swapper' THREAD: c000000000dfc000 CPU: 0
> GPR04: c0000000010f4d80 c0000001bffebd80 0000000000000000 c0000001b18a8200
> GPR08: 0000000000000280 c0000001bcc517a8 c0000001b18a7f80 0000000000000000
> GPR12: d0000000047e5bb0 c000000001f10000 c0000001b19c8700 0000000000000000
> GPR16: c0000001bffebd80 0000000000000083 c00000018f2447a0 0000000000000002
> GPR20: 0000000000000000 c0000001ba860010 c0000001ba860000 d000000003d40000
> GPR24: 0000000000000000 0000000000000083 d000000003d40000 0000000000000001
> GPR28: c00000018f244780 c0000001b2b94310 c000000000da95f0 c0000001bcc51780
> NIP [c0000000004dda0c] .skb_gro_reset_offset+0x5c/0xe0
> LR [c0000000004e3e50] .napi_gro_receive+0x30/0x120
> Call Trace:
> [c0000001bffebb50] [c000000000da95f0] perf_callchain_user+0x0/0x10 (unreliable)
> [c0000001bffebbf0] [d0000000047bd118] .ixgbe_clean_rx_irq+0x7a8/0x8a0 [ixgbe]
> [c0000001bffebd10] [d0000000047bd414] .ixgbe_poll+0x64/0x160 [ixgbe]
> [c0000001bffebdd0] [c0000000004e3358] .net_rx_action+0x108/0x2a0
> [c0000001bffebea0] [c00000000009b220] .__do_softirq+0x110/0x2a0
> [c0000001bffebf90] [c000000000023798] .call_do_softirq+0x14/0x24
> [c000000000dff830] [c000000000011148] .do_softirq+0xf8/0x130
> [c000000000dff8d0] [c00000000009aeb4] .irq_exit+0xb4/0xc0
> [c000000000dff950] [c000000000011254] .do_IRQ+0xd4/0x300
> [c000000000dffa10] [c000000000005024] hardware_interrupt_entry+0x18/0x74
> --- Exception: 501 at .pseries_dedicated_idle_sleep+0xe4/0x210
> LR = .pseries_dedicated_idle_sleep+0x8c/0x210
> [c000000000dffd00] [c00000000005b194] .pseries_dedicated_idle_sleep+0x194/0x210
> (unreliable)
> [c000000000dffdc0] [c000000000018c84] .cpu_idle+0x164/0x210
> [c000000000dffe70] [c00000000000b0d0] .rest_init+0x90/0xb0
> [c000000000dffef0] [c000000000830bc0] .start_kernel+0x54c/0x56c
> [c000000000dfff90] [c00000000000953c] .start_here_common+0x1c/0x60
>
> Its caused when skb_gro_reset_offset attempts to call PageHighMem on
> skb_shinfo(skb)->frags[0].page, when the frags array was left uninitalized.
> This can happen in the ixgbe driver if the hardware reports a zero length rx
> descriptor ni the middle of a packet split receive transaction. I've consulted
> with Jesse Brandeburg on this, who is attempting to root cause the issue at
> Intel, but it seems prudent to add this check to the driver to discard frames of
> that encounter this error to avoid the opps
>
> Signed-off-by: Neil Horman<nhorman@tuxdriver.com>
> Signed-off-by: Thadeu Lima de Souza Cascardo<cascardo@linux.vnet.ibm.com>
> CC: Jesse Brandeburg<jesse.brandeburg@intel.com>
> CC: Alexander Duyck<alexander.h.duyck@intel.com>
> CC: John Fastabend<john.r.fastabend@intel.com>
> CC: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
> CC: David S. Miller<davem@davemloft.net>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 17 +++++++++++------
> 1 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index d20e804..6d59185 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -1326,6 +1326,13 @@ static void ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
>
> rx_buffer_info =&rx_ring->rx_buffer_info[i];
>
> + i++;
> + if (i == rx_ring->count)
> + i = 0;
> +
> + next_rxd = IXGBE_RX_DESC_ADV(rx_ring, i);
> + prefetch(next_rxd);
> +
> skb = rx_buffer_info->skb;
> rx_buffer_info->skb = NULL;
> prefetch(skb->data);
> @@ -1367,6 +1374,10 @@ static void ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
> } else {
> /* assume packet split since header is unmapped */
> upper_len = le16_to_cpu(rx_desc->wb.upper.length);
> + if (!upper_len) {
> + rx_buffer_info->skb = skb;
> + goto next_desc;
> + }
> }
>
> if (upper_len) {
> @@ -1391,12 +1402,6 @@ static void ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
> skb->truesize += upper_len;
> }
>
> - i++;
> - if (i == rx_ring->count)
> - i = 0;
> -
> - next_rxd = IXGBE_RX_DESC_ADV(rx_ring, i);
> - prefetch(next_rxd);
> cleaned_count++;
>
> if (pkt_is_rsc) {
^ 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