* Re: dynamic TCP algorithms switching
From: Stephen Hemminger @ 2013-11-24 0:42 UTC (permalink / raw)
To: yan cui; +Cc: netdev
In-Reply-To: <CAAVq3rmgzL4Hg__dSkmEM75ZHuEsebE1D4ko-viSEggcYdrPjw@mail.gmail.com>
On Fri, 22 Nov 2013 22:56:10 -0500
yan cui <ccuiyyan@gmail.com> wrote:
> Thanks for the quick reply!
> Do you have the real-world workload results that demonstrate
> that cubic has the best performance among all the available congestion
> algorithms? If so, could you please post some?
>
>
> Thanks, Yan
>
>
> 2013/11/22 Stephen Hemminger <stephen@networkplumber.org>:
> > On Fri, 22 Nov 2013 18:21:12 -0500
> > yan cui <ccuiyyan@gmail.com> wrote:
> >
> >> Then, why include so many (current Linux has 10+ TCP congestion algorithms)
> >> algorithms? For users who want to deploy their application on Linux
> >> and if the applications
> >> are system resource intensive, they always want to tune the
> >> configurations of the operating systems for the last piece of
> >> performance. If they do so, maybe they are confused
> >> about which TCP congestion algorithm to use for their environment. So,
> >> the only way is to try each algorithm one by one. I understand the
> >> setting of the default TCP congestion
> >> algorithm to be Cubic means that it works well for most environments.
> >> But if others
> >> are seldom used, or can be replace with another implementation.
> >> Why not just remove from the kernel?
> >>
> >> Yan
> >
> > Most are intended for research and testing only.
> > Only a few are worth considering in a production environment.
> > That is also why there so many qdisc algorithms as well.
> >
>
>
>
If you did a little searching around, you would find that there has been extensive
research in this area. http://netsrv.csc.ncsu.edu/wiki/index.php/TCP_Testing
is a good place to start.
^ permalink raw reply
* Re: r8169 - it's dead jim
From: Francois Romieu @ 2013-11-24 0:50 UTC (permalink / raw)
To: James Feeney; +Cc: Realtek and the Linux r8169 crew
In-Reply-To: <529105F8.9030901@nurealm.net>
James Feeney <james@nurealm.net> :
[...]
> Going from 3.12.0-1-ARCH to 3.12.1-1-ARCH, the r8169 module is having the
> "link detect" problem again.
$ grep james@nurealm.net ~/Mail/linux/netdev/201[123]?? | grep -v 201311
Which one exactly ?
> Initially, "ethtool -s <blah> autoneg off" gives "invalid argument".
blah ?
[...]
> After some time, Auto-negotiation will spontaneously go on, and a 100Mb/s full
> duplex connection will come up, on a 1Gb/s interface. Subsequent unplugging and
> plugging the cable gives a 1Gb/s full duplex connection.
>
> This problem has been recurring for so many years, I hope the solution is
> something obvious, perhaps a recent change to the kernel?
The r8169 driver is the same in v3.12 and v3.12.1. Either some userspace
application works in your back or your device experienced a runtime
suspend / resume cycle where it previously didn't.
You can try the genuinely untested hack below if you don't like current
runtime suspend / resume behavior.
What do you want exactly ? 10 Mb/s, 100 Mb/s ? Limited / no advertising ?
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 7280d5d..701ca00 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -812,6 +812,13 @@ struct rtl8169_private {
#define RTL_FIRMWARE_UNKNOWN ERR_PTR(-EAGAIN)
u32 ocp_base;
+
+ struct {
+ u32 adv;
+ u16 speed;
+ u8 duplex;
+ u8 autoneg;
+ } rtl_settings;
};
MODULE_AUTHOR("Realtek and the Linux r8169 crew <netdev@vger.kernel.org>");
@@ -1755,6 +1762,11 @@ static int rtl8169_set_speed(struct net_device *dev,
if (ret < 0)
goto out;
+ tp->autoneg = autoneg;
+ tp->speed = speed;
+ tp->duplex = duplex;
+ tp->adv = advertising;
+
if (netif_running(dev) && (autoneg == AUTONEG_ENABLE) &&
(advertising & ADVERTISED_1000baseT_Full)) {
mod_timer(&tp->timer, jiffies + RTL8169_PHY_TIMEOUT);
@@ -3778,6 +3790,14 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
netif_info(tp, link, dev, "TBI auto-negotiating\n");
}
+static void rtl_resume_phy(struct net_device *dev, struct rtl8169_private *tp)
+{
+ rtl8169_init_phy(dev, tp);
+
+ if (tp->speed)
+ tp->set_speed(dev, tp->autoneg, tp->speed, tp->duplex, tp->adv);
+}
+
static void rtl_rar_set(struct rtl8169_private *tp, u8 *addr)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -6661,7 +6681,7 @@ static int rtl8169_resume(struct device *device)
struct net_device *dev = pci_get_drvdata(pdev);
struct rtl8169_private *tp = netdev_priv(dev);
- rtl8169_init_phy(dev, tp);
+ rtl_resume_phy(dev, tp);
if (netif_running(dev))
__rtl8169_resume(dev);
@@ -6702,7 +6722,7 @@ static int rtl8169_runtime_resume(struct device *device)
tp->saved_wolopts = 0;
rtl_unlock_work(tp);
- rtl8169_init_phy(dev, tp);
+ rtl_resume_phy(dev, tp);
__rtl8169_resume(dev);
^ permalink raw reply related
* Re: FEC performance degradation on iMX28 with forced link media
From: Marek Vasut @ 2013-11-24 4:40 UTC (permalink / raw)
To: Hector Palacios; +Cc: netdev@vger.kernel.org, fabio.estevam@freescale.com
In-Reply-To: <528F50AE.3030804@digi.com>
Hi Hector,
> Hello,
>
> When forcing the Ethernet PHY link media with ethtool/mii-tool on the
> i.MX28 I've seen important performance degradation as the packet size
> increases.
>
> On the target:
> # mii-tool eth0 -F 10baseT-FD
> # netpipe
>
> On the host:
> # netpipe -h <target-ip> -n 1
> ...
> 44: 1024 bytes 1 times --> 6.56 Mbps in 1191.00 usec
> 45: 1027 bytes 1 times --> 6.56 Mbps in 1193.52 usec
> 46: 1533 bytes 1 times --> 0.60 Mbps in 19600.54 usec
> 47: 1536 bytes 1 times --> 0.46 Mbps in 25262.52 usec
> 48: 1539 bytes 1 times --> 0.57 Mbps in 20745.54 usec
> 49: 2045 bytes 1 times --> 0.74 Mbps in 20971.95 usec
> ...
> On loop 46, as the packet size exceeds the MTU (1500) performance falls
> from 6.56Mbps to 0.60Mbps.
>
> Going back to 100baseTX-FD, but still forced (autonegotiation off), the
> same occurs: On the target:
> # mii-tool eth0 -F 100baseTx-FD
> # netpipe
>
> On the host:
> # netpipe -h <target-ip> -n 1
> ...
> 58: 6141 bytes 1 times --> 39.74 Mbps in 1179.03 usec
> 59: 6144 bytes 1 times --> 41.83 Mbps in 1120.51 usec
> 60: 6147 bytes 1 times --> 41.39 Mbps in 1133.03 usec
> 61: 8189 bytes 1 times --> 6.36 Mbps in 9823.94 usec
> 62: 8192 bytes 1 times --> 6.56 Mbps in 9521.46 usec
> 63: 8195 bytes 1 times --> 6.56 Mbps in 9532.99 usec
> ...
> only this time it happens with a larger packet size (8189 bytes).
>
> With autonegotiation on, performance is ok and does not suffer these drops.
>
> I've reproduced this on the mx28evk board but it also happens in my
> hardware, with different PHY on v3.10.
> I also tried on an old v2.6.35 kernel and the issue was reproducible as
> well, though it happened with larger packet sizes than it happens with
> v3.10:
> ...
> 75: 32771 bytes 1 times --> 49.64 Mbps in 5036.50 usec
> 76: 49149 bytes 1 times --> 46.18 Mbps in 8120.48 usec
> 77: 49152 bytes 1 times --> 43.30 Mbps in 8660.46 usec
> 78: 49155 bytes 1 times --> 40.10 Mbps in 9351.46 usec
> 79: 65533 bytes 1 times --> 2.03 Mbps in 246061.04 usec
> 80: 65536 bytes 1 times --> 2.21 Mbps in 226516.50 usec
> 81: 65539 bytes 1 times --> 1.45 Mbps in 344196.46 usec
> ...
>
> Could there be any issue with packet fragmentation?
> I tried the same on imx6sabresd but here the issue is not reproducible. I
> don't know if the higher CPU frequency might be hiding the problem,
> though.
>
> Any idea about what can make the difference between forcing media vs
> autonegotiation?
Let me ask, this might be unrelated, but I will still go ahead. Do you also
observe packetloss? You can check with iperf:
On host machine (PC): iperf -u -s -l 4M -i 60
On target: iperf -u -c <hostip> -t 3600 -B 100M -i 60
Best regards,
Marek Vasut
^ permalink raw reply
* wakeonlan fails if pm-hibernate used
From: Ken Sharp @ 2013-11-24 7:09 UTC (permalink / raw)
To: netdev; +Cc: 1074110
In-Reply-To: <52039A0D.1000906@o2.co.uk>
Forwarding as per https://bugzilla.kernel.org/show_bug.cgi?id=65361#c1
On 08/08/13 14:15, Ken Sharp wrote:
> wakeonlan fails if pm-hibernate used
>
> After issuing halt -p, wakeonlan works fine. after issuing pm-hibernate,
> the machine will not wake up.
>
> interfaces:
> auto eth0
> iface eth0 inet dhcp
> up ethtool -s eth0 wol g
> down ethtool -s eth0 wol g
>
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Supported pause frame use: No
> Supports auto-negotiation: Yes
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Advertised pause frame use: No
> Advertised auto-negotiation: Yes
> Link partner advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Link partner advertised pause frame use: Symmetric
> Link partner advertised auto-negotiation: Yes
> Speed: 100Mb/s
> Duplex: Full
> Port: MII
> PHYAD: 32
> Transceiver: internal
> Auto-negotiation: on
> Supports Wake-on: pumbg
> Wake-on: g
> Current message level: 0x00000007 (7)
> drv probe link
> Link detected: yes
>
> 01:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10
>
> Reported on Launchpad
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1074110
>
> $ cat /proc/version
> Linux version 3.11.0-999-generic (apw@gomeisa) (gcc version 4.6.3
> (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201308070514 SMP Wed Aug 7 09:24:40
> UTC 2013
>
> $ lsb_release -rd
> Description: Ubuntu 12.04.2 LTS
> Release: 12.04
>
> $ ./ver_linux
> If some fields are empty or look unusual you may have an old version.
> Compare to the current minimal requirements in Documentation/Changes.
>
> Linux oldhomeserver 3.11.0-999-generic #201308070514 SMP Wed Aug 7
> 09:24:40 UTC 2013 i686 i686 i386 GNU/Linux
>
> Gnu C 4.6
> Gnu make 3.81
> binutils 2.22
> util-linux 2.20.1
> mount support
> module-init-tools 3.16
> e2fsprogs 1.42
> pcmciautils 018
> Linux C Library 2.15
> Dynamic linker (ldd) 2.15
> Procps 3.2.8
> Net-tools 1.60
> Kbd 1.15.2
> Sh-utils 8.13
> Modules Loaded zram dm_crypt nfsd nfs_acl auth_rpcgss nfs
> fscache lockd binfmt_misc sunrpc gpio_ich lpc_ich serio_raw shpchp
> intel_rng mac_hid hwmon_vid lp parport 8139too 8139cp mii
>
> $ cat /proc/cpuinfo
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 8
> model name : Pentium III (Coppermine)
> stepping : 3
> microcode : 0x10
> cpu MHz : 734.956
> cache size : 256 KB
> fdiv_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 2
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
> pse36 mmx fxsr sse
> bogomips : 1469.91
> clflush size : 32
> cache_alignment : 32
> address sizes : 36 bits physical, 32 bits virtual
> power management:
>
> $ cat /proc/modules
> zram 18166 1 - Live 0x00000000 (C)
> dm_crypt 22524 0 - Live 0x00000000
> nfsd 246709 13 - Live 0x00000000
> nfs_acl 12771 1 nfsd, Live 0x00000000
> auth_rpcgss 49253 1 nfsd, Live 0x00000000
> nfs 162863 0 - Live 0x00000000
> fscache 52016 1 nfs, Live 0x00000000
> lockd 79198 2 nfsd,nfs, Live 0x00000000
> binfmt_misc 17268 1 - Live 0x00000000
> sunrpc 236600 23 nfsd,nfs_acl,auth_rpcgss,nfs,lockd, Live 0x00000000
> gpio_ich 13278 0 - Live 0x00000000
> lpc_ich 16987 0 - Live 0x00000000
> serio_raw 13189 0 - Live 0x00000000
> shpchp 32265 0 - Live 0x00000000
> intel_rng 12700 0 - Live 0x00000000
> mac_hid 13077 0 - Live 0x00000000
> hwmon_vid 12723 0 - Live 0x00000000
> lp 13359 0 - Live 0x00000000
> parport 40930 1 lp, Live 0x00000000
> 8139too 32770 0 - Live 0x00000000
> 8139cp 27168 0 - Live 0x00000000
> mii 13693 2 8139too,8139cp, Live 0x00000000
>
> $ cat /proc/ioports
> 0000-001f : dma1
> 0020-0021 : pic1
> 0040-0043 : timer0
> 0050-0053 : timer1
> 0060-0060 : keyboard
> 0064-0064 : keyboard
> 0070-0071 : rtc0
> 0080-008f : dma page reg
> 00a0-00a1 : pic2
> 00c0-00df : dma2
> 00f0-00ff : fpu
> 0170-0177 : 0000:00:1f.1
> 0170-0177 : ata_piix
> 01f0-01f7 : 0000:00:1f.1
> 01f0-01f7 : ata_piix
> 0376-0376 : 0000:00:1f.1
> 0376-0376 : ata_piix
> 03c0-03df : vga+
> 03f6-03f6 : 0000:00:1f.1
> 03f6-03f6 : ata_piix
> 0400-0403 : ACPI PM1a_EVT_BLK
> 0404-0405 : ACPI PM1a_CNT_BLK
> 0408-040b : ACPI PM_TMR
> 0410-0415 : ACPI CPU throttle
> 0428-042b : ACPI GPE0_BLK
> 042c-042f : ACPI GPE1_BLK
> 0430-0433 : iTCO_wdt
> 0460-047f : iTCO_wdt
> 0480-04bf : gpio_ich
> 0480-04bf : 0000:00:1f.0
> 04c0-04cf : 0000:00:1f.3
> 0cf8-0cff : PCI conf1
> c000-cfff : PCI Bus 0000:01
> cc00-ccff : 0000:01:03.0
> cc00-ccff : 8139too
> de00-de1f : 0000:00:1f.2
> de00-de1f : uhci_hcd
> ff00-ff0f : 0000:00:1f.1
> ff00-ff0f : ata_piix
>
> $ cat /proc/iomem
> 00000000-00000fff : reserved
> 00001000-0009fbff : System RAM
> 0009fc00-0009ffff : reserved
> 000a0000-000bffff : Video RAM area
> 000c0000-000c7fff : Video ROM
> 000e0000-000fffff : reserved
> 000f0000-000fffff : System ROM
> 00100000-0beeffff : System RAM
> 01000000-016680a2 : Kernel code
> 016680a3-019bd17f : Kernel data
> 01aa1000-01b94fff : Kernel bss
> 0bef0000-0bef7fff : ACPI Tables
> 0bef8000-0befffff : ACPI Non-volatile Storage
> 0bf00000-0bffffff : reserved
> dfc00000-dfcfffff : PCI Bus 0000:01
> e0000000-e3ffffff : 0000:00:01.0
> e7e00000-ebefffff : PCI Bus 0000:01
> e8000000-e80000ff : 0000:01:03.0
> e8000000-e80000ff : 8139too
> ee000000-ee07ffff : 0000:00:01.0
> fff80000-ffffffff : reserved
>
> $ sudo lspci -vvv
> 00:00.0 Host bridge: Intel Corporation 82810E DC-133 (GMCH) Graphics
> Memory Controller Hub (rev 03)
> Subsystem: Intel Corporation 82810E DC-133 (GMCH) Graphics Memory
> Controller Hub
> 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
> Kernel driver in use: agpgart-intel
>
> 00:01.0 VGA compatible controller: Intel Corporation 82810E DC-133 (CGC)
> Chipset Graphics Controller (rev 03) (prog-if 00 [VGA controller])
> Subsystem: Giga-byte Technology Device 0200
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin A routed to IRQ 11
> Region 0: Memory at e0000000 (32-bit, prefetchable) [size=64M]
> Region 1: Memory at ee000000 (32-bit, non-prefetchable) [size=512K]
> Expansion ROM at <unassigned> [disabled]
> Capabilities: [dc] Power Management version 1
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>
> 00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02)
> (prog-if 00 [Normal decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
> I/O behind bridge: 0000c000-0000cfff
> Memory behind bridge: e7e00000-ebefffff
> Prefetchable memory behind bridge: dfc00000-dfcfffff
> Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- <SERR- <PERR-
> BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> Kernel modules: shpchp
>
> 00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02)
> Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Kernel driver in use: lpc_ich
> Kernel modules: lpc_ich, intel-rng
>
> 00:1f.1 IDE interface: Intel Corporation 82801AA IDE Controller (rev 02)
> (prog-if 80 [Master])
> Subsystem: Intel Corporation 82801AA IDE Controller
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable)
> [size=8]
> Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable)
> [size=1]
> Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable)
> [size=8]
> Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable)
> [size=1]
> Region 4: I/O ports at ff00 [size=16]
> Kernel driver in use: ata_piix
>
> 00:1f.2 USB controller: Intel Corporation 82801AA USB Controller (rev
> 02) (prog-if 00 [UHCI])
> Subsystem: Intel Corporation 82801AA USB Controller
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin D routed to IRQ 10
> Region 4: I/O ports at de00 [size=32]
> Kernel driver in use: uhci_hcd
>
> 00:1f.3 SMBus: Intel Corporation 82801AA SMBus Controller (rev 02)
> Subsystem: Intel Corporation 82801AA SMBus Controller
> Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Interrupt: pin B routed to IRQ 0
> Region 4: I/O ports at 04c0 [size=16]
> Kernel modules: i2c-i801
>
> 01:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
> Subsystem: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 64 (8000ns min, 16000ns max)
> Interrupt: pin A routed to IRQ 11
> Region 0: I/O ports at cc00 [size=256]
> Region 1: Memory at e8000000 (32-bit, non-prefetchable) [size=256]
> Capabilities: [50] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
> PME(D0-,D1+,D2+,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Kernel driver in use: 8139too
> Kernel modules: 8139too, 8139cp
>
> $ cat /proc/scsi/scsi
> Attached devices:
> Host: scsi0 Channel: 00 Id: 01 Lun: 00
> Vendor: ATA Model: QUANTUM FIREBALL Rev: A01.
> Type: Direct-Access ANSI SCSI revision: 05
> Host: scsi1 Channel: 00 Id: 00 Lun: 00
> Vendor: GoldStar Model: CD-RW CED-8080B Rev: 1.02
> Type: CD-ROM
>
> $ ls /proc
> 1 1026 1406 1471 16 19 25 42 6 695 9 cpuinfo
> fs kpagecount mounts slabinfo tty
> 10 11 1461 1472 1641 2 26 44 619 7 986 crypto
> interrupts kpageflags mtrr softirqs uptime
> 1005 1110 1462 1473 1642 20 27 45 64 709 991 devices
> iomem latency_stats net stat version
> 1006 12 1463 1477 17 21 28 467 65 731 acpi diskstats
> ioports loadavg pagetypeinfo swaps vmallocinfo
> 1008 13 1466 1499 18 22 3 468 654 793 buddyinfo dma
> irq locks partitions sys vmstat
> 1013 1373 1467 15 1844 224 324 5 657 797 bus driver
> kallsyms mdstat sched_debug sysrq-trigger zoneinfo
> 1014 14 1468 1515 1859 225 326 579 666 8 cgroups
> execdomains kcore meminfo schedstat sysvipc
> 1021 1401 1469 1535 1867 23 39 584 67 856 cmdline fb
> key-users misc scsi timer_list
> 1023 1405 1470 1541 1868 24 41 586 694 895 consoles
> filesystems kmsg modules self timer_stats
>
> $ sudo ethtool eth0
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Supported pause frame use: No
> Supports auto-negotiation: Yes
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Advertised pause frame use: No
> Advertised auto-negotiation: Yes
> Link partner advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Link partner advertised pause frame use: Symmetric
> Link partner advertised auto-negotiation: Yes
> Speed: 100Mb/s
> Duplex: Full
> Port: MII
> PHYAD: 32
> Transceiver: internal
> Auto-negotiation: on
> Supports Wake-on: pumbg
> Wake-on: g
> Current message level: 0x00000007 (7)
> drv probe link
> Link detected: yes
>
> Taken as a guide to report this:
> https://wiki.ubuntu.com/Bugs/Upstream/kernel
>
> Apologies if this is too much or not enough information, this is the
> first time I have attempted to report a problem with the kernel.
>
> I looked through https://www.kernel.org/doc/Documentation/power/ but the
> processes either didn't seem relevant or I simply didn't understand. If
> you need me to run through the processes then please let me know.
>
> Specifically
> https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt
> suggests that the debugging would test the wake/resume cycle, which I
> don't think is relevant in this case. But I could be wrong!
>
> Thanks for your help,
>
> Ken
^ permalink raw reply
* Re: [PATCH net v3 1/2] net: sched: tbf: fix calculation of max_size
From: Yang Yingliang @ 2013-11-24 7:28 UTC (permalink / raw)
To: Eric Dumazet, Yang Yingliang; +Cc: davem, netdev, brouer, jpirko, jbrouer
In-Reply-To: <1385233579.10637.95.camel@edumazet-glaptop2.roam.corp.google.com>
On 2013/11/24 3:06, Eric Dumazet wrote:
> On Tue, 2013-11-19 at 15:25 +0800, Yang Yingliang wrote:
>> commit b757c9336d63f94c6b57532(tbf: improved accuracy at high rates)
>> introduce a regression.
>>
>> With the follow command:
>> tc qdisc add dev eth1 root handle 1: tbf latency 50ms burst 10KB rate 30gbit mtu 64k
>>
>> Without this patch, the max_size value is 10751(bytes).
>> But, in fact, the real max_size value should be smaller than 7440(bytes).
>> Or a packet whose length is bigger than 7440 will cause network congestion.
>> Because the packet is so big that can't get enough tokens. Even all the tokens
>> in the buffer is given to the packet.
>>
>> With this patch, the max_size value is 7440(bytes).
>> The packets whose length is bigger than 7440(bytes) will be dropped or reshape
>> in tbf_enqueue().
> This changelog makes no sense.
>
> If userland asks 'burst 10KB', then burst is 10KB, not 7440.
>
Ideally burst should be 10KB in kernel space.
But at hight rates, when burst is converted to
time in tick in userland, it gets much more loss
than low rates. So the burst can't actually
reach 10KB in kernel.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: BCM5720 transmit queue 1 timed out
From: Atif Faheem @ 2013-11-24 8:44 UTC (permalink / raw)
To: Nithin Nayak Sujir; +Cc: netdev@vger.kernel.org
In-Reply-To: <52812764.5090803@broadcom.com>
Hi Nithin. I can get the RDMA change to trigger / resolve, however, I have one Q. Are the RDMA length registers 16 bit or 32 bit? The code seems to imply they are 32-bit, however, my understanding is that the length registers are 16-bit at 4be0, 4be2, 4be4, 4be6.
if (tr32(TG3_RDMA_LENGTH + (i << 2)) > TG3_MAX_MTU(tp))
The change gets executed when the value of 0x4be0 is e.g., 0x00960096, or 0x00a200a2. Just wanted to confirm that the lengths are indeed 32-bit in the register map.
Thanks.
- Atif
On Nov 11, 2013, at 1:52 PM, Nithin Nayak Sujir <nsujir@broadcom.com> wrote:
>
>
> On 11/08/2013 09:24 PM, Atif Faheem wrote:
>> Hi. I need some help with transmit Q timeouts on the 5720. We are using Linux kernel 3.4.34, with channel bonding on 5720 on embedded. Occasionally immediately after a reboot or a power cycle we get a lockup on the 5720, which looks like given below; the problem seems to happen on some 5720’s more often. Recently there has been a lot of discussion on this issue on the list and based on that I have incorporated the following 2 patches from upstream into the driver, but the problem still continues to happen.
>>
> Hi Atif,
>
> The symptom you're describing matches the fixes that went in for the DMA workaround.
>
>> -- After Power-on-reset, the 5719's TX DMA length registers may contain
>> uninitialized values and cause TX DMA to stall. Check for invalid
>> values and set a register bit to flush the TX channels. The bit
>> needs to be turned off after the DMA channels have been flushed.
>>
>> -- There was a subsequent fix (06/13) that applies the patch above to the 5720. Commit 091f0ea30074bc43f9250961b3247af713024bc6.
>>
>
> This commit id is for the 5719 fix. The 5720 fix is
> 9bc297ea0622bb2a6b3abfa2fa84f0a3b86ef8c8.
>
>
>> Is there anything else that might be missing from 3.4.34 as far as the transmit lockups are concerned? Any ideas will be great.
>>
>
> No, these two patches should fix the issue. Are you certain both patches are
> applied and being used? Also, would you mind trying the latest stable 3.11.x kernel?
>
> Please make sure to *power cycle* the system after a previous timeout. A reboot
> may not be enough once the hardware is already in a bad state for this issue.
> Pull the plug and power down and wait a few seconds before powering on.
>
> Thanks,
> Nithin.
>
>
>
>> Thanks.
>> Atif Faheem
>> BTI Systems
>> net
>>
>> ------------[ cut here ]------------
>> WARNING: at /home/jenkins/jobs/r102-os/workspace/opt/os/wrlinux/builds/atom64/bitbake_build/tmp/work/intel_atom_64-wrs-linux/linux-windriver-3.4-r0/linux/net/sched/sch_generic.c:256 dev_watchdog+0x277/0x280()
>> Hardware name: To be filled by O.E.M.
>> NETDEV WATCHDOG: eth1 (tg3): transmit queue 1 timed out
>> Modules linked in: firmware_class libphy tg3 bonding
>> Pid: 0, comm: swapper/0 Not tainted 3.4.34-WR5.0.1.3_standard #1
>> Call Trace:
>> <IRQ> [<ffffffff81030c84>] warn_slowpath_common+0x84/0xc0
>> [<ffffffff81030d77>] warn_slowpath_fmt+0x47/0x50
>> [<ffffffff816799f7>] dev_watchdog+0x277/0x280
>> [<ffffffff81040784>] run_timer_softirq+0x134/0x420
>> [<ffffffff8134f5ee>] ? timerqueue_add+0x6e/0xc0
>> [<ffffffff81679780>] ? qdisc_reset+0x50/0x50
>> [<ffffffff8103811d>] __do_softirq+0xbd/0x280
>> [<ffffffff81079375>] ? clockevents_program_event+0x75/0xf0
>> [<ffffffff8107a7b4>] ? tick_program_event+0x24/0x30
>> [<ffffffff81777b8c>] call_softirq+0x1c/0x30
>> [<ffffffff810037b5>] do_softirq+0x55/0x90
>> [<ffffffff810385ee>] irq_exit+0x8e/0xb0
>> [<ffffffff817781e9>] smp_apic_timer_interrupt+0x99/0x1cd
>> [<ffffffff817773c7>] apic_timer_interrupt+0x67/0x70
>> <EOI> [<ffffffff813c2689>] ? acpi_idle_enter_bm+0x240/0x281
>> [<ffffffff813c2684>] ? acpi_idle_enter_bm+0x23b/0x281
>> [<ffffffff815cc58f>] ? menu_select+0xff/0x3c0
>> [<ffffffff815ca8d8>] cpuidle_enter+0x18/0x20
>> [<ffffffff815caf59>] cpuidle_idle_call+0xc9/0x3b0
>> [<ffffffff8100b59f>] cpu_idle+0x7f/0xd0
>> [<ffffffff8174b3a7>] rest_init+0x7b/0x84
>> [<ffffffff81cd3b76>] start_kernel+0x35b/0x369
>> [<ffffffff81cd3616>] ? repair_env_string+0x5a/0x5a
>> [<ffffffff81cd3321>] x86_64_start_reservations+0x131/0x135
>> [<ffffffff81cd3416>] x86_64_start_kernel+0xf1/0xf9
>> ---[ end trace b625d70ff7be1bd7 ]—
>> kernel: tg3 0000:03:00.1: eth1: transmit timed out, resetting
>> kernel: tg3 0000:03:00.1: eth1: 0x00000000: 0x165f14e4, 0x00100406, 0x02000000, 0x00800010
>> kernel: tg3 0000:03:00.1: eth1: 0x00000010: 0xbc14000c, 0x00000000, 0xbc13000c, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000020: 0xbc12000c, 0x00000000, 0x00000000, 0x165f14e4
>> kernel: tg3 0000:03:00.1: eth1: 0x00000030: 0x00000000, 0x00000048, 0x00000000, 0x0000020b
>> kernel: tg3 0000:03:00.1: eth1: 0x00000040: 0x00000000, 0x03000000, 0xc8035001, 0x64002008
>> kernel: tg3 0000:03:00.1: eth1: 0x00000050: 0x00005803, 0x00000000, 0x0086a005, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000060: 0x00000000, 0x00000000, 0xf0000298, 0x00380081
>> kernel: tg3 0000:03:00.1: eth1: 0x00000070: 0x00071090, 0xffffe0ff, 0x00000438, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000080: 0x0000024c, 0x40000040, 0x00000000, 0x0000000c
>> kernel: tg3 0000:03:00.1: eth1: 0x00000090: 0x00000000, 0x00000000, 0x00000000, 0x000000e8
>> kernel: tg3 0000:03:00.1: eth1: 0x000000a0: 0x8010ac11, 0x00000004, 0x00001004, 0x00020010
>> kernel: tg3 0000:03:00.1: eth1: 0x000000b0: 0x15048d81, 0x00102400, 0x0004cc22, 0x10110040
>> kernel: tg3 0000:03:00.1: eth1: 0x000000d0: 0x0000001f, 0x00000000, 0x00000000, 0x00010000
>> kernel: tg3 0000:03:00.1: eth1: 0x000000f0: 0x00000000, 0x05720000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000100: 0x13c10001, 0x00000000, 0x00000000, 0x00062030
>> kernel: tg3 0000:03:00.1: eth1: 0x00000110: 0x00002080, 0x00002000, 0x000000a0, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000130: 0x00000000, 0x00000000, 0x00000000, 0x15010003
>> kernel: tg3 0000:03:00.1: eth1: 0x00000140: 0xd0400c65, 0x00000014, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000150: 0x16010004, 0x00000000, 0x0007811b, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000160: 0x00010002, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000170: 0x00000000, 0x800000ff, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000200: 0x00000000, 0x03000000, 0x00000000, 0x0d000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000210: 0x00000000, 0x07000000, 0x00000000, 0x0b000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000220: 0x00000000, 0x04000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000260: 0x00000000, 0x00000000, 0x00000000, 0x000000e8
>> kernel: tg3 0000:03:00.1: eth1: 0x00000280: 0x00000000, 0x0000000c, 0x00000000, 0x00000006
>> kernel: tg3 0000:03:00.1: eth1: 0x00000290: 0x00000000, 0x0000000a, 0x00000000, 0x00000004
>> kernel: tg3 0000:03:00.1: eth1: 0x00000300: 0x00000001, 0x00000000, 0x00000000, 0x00000001
>> kernel: tg3 0000:03:00.1: eth1: 0x00000400: 0x18e04808, 0x00400000, 0x00001000, 0x00000880
>> kernel: tg3 0000:03:00.1: eth1: 0x00000410: 0x00000014, 0xd0400c64, 0x00000014, 0xd0400c64
>> kernel: tg3 0000:03:00.1: eth1: 0x00000420: 0x00000014, 0xd0400c64, 0x00000014, 0xd0400c64
>> kernel: tg3 0000:03:00.1: eth1: 0x00000430: 0x00000400, 0x00000000, 0x000002dd, 0x000005f2
>> kernel: tg3 0000:03:00.1: eth1: 0x00000440: 0x00000000, 0x00000000, 0x00000000, 0x04584400
>> kernel: tg3 0000:03:00.1: eth1: 0x00000450: 0x00000001, 0x00008000, 0x00000000, 0x00000102
>> kernel: tg3 0000:03:00.1: eth1: 0x00000460: 0x00000008, 0x00002620, 0x01ff0002, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000470: 0x80000000, 0x00000080, 0x00000000, 0x40200000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000480: 0x42000000, 0x7fffffff, 0x06000004, 0x7fffffff
>> kernel: tg3 0000:03:00.1: eth1: 0x00000500: 0x00000008, 0x00000002, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000540: 0x00000014, 0xd0400c66, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000590: 0x00e00000, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000005b0: 0x00000000, 0x00000008, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000005c0: 0xb26ff6f0, 0xa1d5ff82, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000600: 0xffffffff, 0x00f80011, 0x00000000, 0x00001f04
>> kernel: tg3 0000:03:00.1: eth1: 0x00000610: 0xffffffff, 0x00000000, 0x07c00004, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000620: 0x00000040, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000630: 0x01230123, 0x01230123, 0x01230123, 0x01230123
>> kernel: tg3 0000:03:00.1: eth1: 0x00000640: 0x01230123, 0x01230123, 0x01230123, 0x01230123
>> kernel: tg3 0000:03:00.1: eth1: 0x00000650: 0x01230123, 0x01230123, 0x01230123, 0x01230123
>> kernel: tg3 0000:03:00.1: eth1: 0x00000660: 0x01230123, 0x01230123, 0x01230123, 0x01230123
>> kernel: tg3 0000:03:00.1: eth1: 0x00000670: 0x5f865437, 0xe4ac62cc, 0x50103a45, 0x36621985
>> kernel: tg3 0000:03:00.1: eth1: 0x00000680: 0xbf14c0e8, 0x1bc27a1e, 0x84f4b556, 0x094ea6fe
>> kernel: tg3 0000:03:00.1: eth1: 0x00000690: 0x7dda01e7, 0xc04d7481, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000006c0: 0x00000000, 0x00000000, 0x04000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000006d0: 0x00000001, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000800: 0x00000000, 0xffffffff, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000810: 0x00000000, 0xffffffff, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000820: 0x00000000, 0x00000000, 0xffffffff, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000830: 0x00000000, 0xffffffff, 0xffffffff, 0xffffffff
>> kernel: tg3 0000:03:00.1: eth1: 0x00000840: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
>> kernel: tg3 0000:03:00.1: eth1: 0x00000850: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
>> kernel: tg3 0000:03:00.1: eth1: 0x00000860: 0xffffffff, 0xffffffff, 0xffffffff, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000880: 0x00000108, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000890: 0x00000002, 0x00000001, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000008f0: 0x00000001, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000900: 0x00000000, 0xffffffff, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000910: 0x00000000, 0xffffffff, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000920: 0x00000000, 0x00000000, 0xffffffff, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000930: 0x00000000, 0xffffffff, 0xffffffff, 0xffffffff
>> kernel: tg3 0000:03:00.1: eth1: 0x00000940: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
>> kernel: tg3 0000:03:00.1: eth1: 0x00000950: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
>> kernel: tg3 0000:03:00.1: eth1: 0x00000960: 0xffffffff, 0xffffffff, 0xffffffff, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000980: 0x00000108, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000990: 0x0000000a, 0x00000020, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000c00: 0x0000000a, 0x00000000, 0x00000003, 0x00000001
>> kernel: tg3 0000:03:00.1: eth1: 0x00000c10: 0x00000000, 0x00000000, 0x00000000, 0x01420000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000c80: 0x00000002, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00000ce0: 0x79fa6c02, 0x00000001, 0x00000142, 0x00040028
>> kernel: tg3 0000:03:00.1: eth1: 0x00000cf0: 0x00000000, 0x50000001, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00001000: 0x00000002, 0x00000000, 0xa0000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00001400: 0x00000006, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00001440: 0x00000000, 0x00000001, 0x00000001, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00001480: 0x00003321, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00001800: 0x00000036, 0x00000000, 0x00000000, 0x00000001
>> kernel: tg3 0000:03:00.1: eth1: 0x00001810: 0x00000001, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00001830: 0x00000000, 0x00000000, 0x00000000, 0x74218000
>> kernel: tg3 0000:03:00.1: eth1: 0x00001840: 0x79012000, 0x00000001, 0x00000204, 0xc0000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00001850: 0x0000001f, 0x00000000, 0x00004800, 0x00000001
>> kernel: tg3 0000:03:00.1: eth1: 0x00001860: 0x01000100, 0x00000000, 0x78f2e000, 0x00000001
>> kernel: tg3 0000:03:00.1: eth1: 0x00001c00: 0x00000002, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002000: 0x00000002, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002010: 0x00000181, 0x00000001, 0x00780003, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002100: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002110: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002120: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002130: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002140: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002150: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002160: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002170: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002180: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002190: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000021a0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000021b0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000021c0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000021d0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000021e0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000021f0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002200: 0x0000002a, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002250: 0x0000000a, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002400: 0x00010012, 0x00000000, 0x00204001, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002410: 0x0000000f, 0x00005d00, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002440: 0x00000000, 0x00000000, 0x00000002, 0x00044400
>> kernel: tg3 0000:03:00.1: eth1: 0x00002450: 0x00000001, 0x73a10000, 0x08001800, 0x00040000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002470: 0x00000000, 0x00000020, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002500: 0x00000000, 0x00000000, 0x00000002, 0x00044800
>> kernel: tg3 0000:03:00.1: eth1: 0x00002510: 0x00000000, 0x00000000, 0x00000002, 0x00040400
>> kernel: tg3 0000:03:00.1: eth1: 0x00002520: 0x00000000, 0x00000000, 0x00000002, 0x00044c00
>> kernel: tg3 0000:03:00.1: eth1: 0x00002530: 0x00000000, 0x00000000, 0x00000002, 0x00040800
>> kernel: tg3 0000:03:00.1: eth1: 0x00002540: 0x00000000, 0x00000000, 0x00000002, 0x00045000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002550: 0x00000000, 0x00000000, 0x00000002, 0x00040c00
>> kernel: tg3 0000:03:00.1: eth1: 0x00002560: 0x00000000, 0x00000000, 0x00000002, 0x00045400
>> kernel: tg3 0000:03:00.1: eth1: 0x00002570: 0x00000000, 0x00000000, 0x00000002, 0x00041000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002580: 0x00000000, 0x00000000, 0x00000002, 0x00045800
>> kernel: tg3 0000:03:00.1: eth1: 0x00002590: 0x00000000, 0x00000000, 0x00000002, 0x00041400
>> kernel: tg3 0000:03:00.1: eth1: 0x000025a0: 0x00000000, 0x00000000, 0x00000002, 0x00045c00
>> kernel: tg3 0000:03:00.1: eth1: 0x000025b0: 0x00000000, 0x00000000, 0x00000002, 0x00041800
>> kernel: tg3 0000:03:00.1: eth1: 0x000025c0: 0x00000000, 0x00000000, 0x00000002, 0x00046000
>> kernel: tg3 0000:03:00.1: eth1: 0x000025d0: 0x00000000, 0x00000000, 0x00000002, 0x00041c00
>> kernel: tg3 0000:03:00.1: eth1: 0x000025e0: 0x00000000, 0x00000000, 0x00000002, 0x00046400
>> kernel: tg3 0000:03:00.1: eth1: 0x000025f0: 0x00000000, 0x00000000, 0x00000002, 0x00042000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002600: 0x00000000, 0x00000000, 0x00000002, 0x00046800
>> kernel: tg3 0000:03:00.1: eth1: 0x00002610: 0x00000000, 0x00000000, 0x00000002, 0x00042400
>> kernel: tg3 0000:03:00.1: eth1: 0x00002620: 0x00000000, 0x00000000, 0x00000002, 0x00046c00
>> kernel: tg3 0000:03:00.1: eth1: 0x00002630: 0x00000000, 0x00000000, 0x00000002, 0x00042800
>> kernel: tg3 0000:03:00.1: eth1: 0x00002640: 0x00000000, 0x00000000, 0x00000002, 0x00047000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002650: 0x00000000, 0x00000000, 0x00000002, 0x00042c00
>> kernel: tg3 0000:03:00.1: eth1: 0x00002660: 0x00000000, 0x00000000, 0x00000002, 0x00047400
>> kernel: tg3 0000:03:00.1: eth1: 0x00002670: 0x00000000, 0x00000000, 0x00000002, 0x00043000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002680: 0x00000000, 0x00000000, 0x00000002, 0x00047800
>> kernel: tg3 0000:03:00.1: eth1: 0x00002690: 0x00000000, 0x00000000, 0x00000002, 0x00043400
>> kernel: tg3 0000:03:00.1: eth1: 0x000026a0: 0x00000000, 0x00000000, 0x00000002, 0x00047c00
>> kernel: tg3 0000:03:00.1: eth1: 0x000026b0: 0x00000000, 0x00000000, 0x00000002, 0x00043800
>> kernel: tg3 0000:03:00.1: eth1: 0x000026c0: 0x00000000, 0x00000000, 0x00000002, 0x00048000
>> kernel: tg3 0000:03:00.1: eth1: 0x000026d0: 0x00000000, 0x00000000, 0x00000002, 0x00043c00
>> kernel: tg3 0000:03:00.1: eth1: 0x000026e0: 0x00000000, 0x00000000, 0x00000002, 0x00048400
>> kernel: tg3 0000:03:00.1: eth1: 0x000026f0: 0x00000000, 0x00000000, 0x00000002, 0x00044000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002800: 0x00000006, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002c00: 0x00000006, 0x00000000, 0x00000000, 0x000000a0
>> kernel: tg3 0000:03:00.1: eth1: 0x00002c10: 0x00000000, 0x00000000, 0x00000019, 0x0000000c
>> kernel: tg3 0000:03:00.1: eth1: 0x00002c20: 0x00000001, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00002d00: 0x00000080, 0x00000040, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00003000: 0x00000006, 0x00000000, 0x00000000, 0x000000a0
>> kernel: tg3 0000:03:00.1: eth1: 0x00003440: 0x00000000, 0x00000000, 0x00000000, 0x00000110
>> kernel: tg3 0000:03:00.1: eth1: 0x00003600: 0x00000600, 0x00170000, 0x00110000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00003610: 0x00170000, 0x00000000, 0x00130000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00003620: 0x00110011, 0x00000000, 0x00000000, 0x40032080
>> kernel: tg3 0000:03:00.1: eth1: 0x00003630: 0x00800000, 0x87748774, 0x02c01000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00003640: 0x00000000, 0x00000000, 0x00000020, 0x00000019
>> kernel: tg3 0000:03:00.1: eth1: 0x00003650: 0x00000171, 0x000f03ff, 0x05720000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00003660: 0x00000000, 0x00000000, 0x02000000, 0x00000202
>> kernel: tg3 0000:03:00.1: eth1: 0x00003670: 0x00000000, 0xfeffbff7, 0x00000000, 0x00000020
>> kernel: tg3 0000:03:00.1: eth1: 0x00003680: 0x30018010, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000036a0: 0x000001a0, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000036b0: 0x0010034c, 0x07ff07ff, 0x07ff07ff, 0x01000004
>> kernel: tg3 0000:03:00.1: eth1: 0x000036c0: 0xffffffff, 0x00000000, 0x00000000, 0x000001c6
>> kernel: tg3 0000:03:00.1: eth1: 0x000036d0: 0x0000019d, 0x00000000, 0x00000000, 0x0000485f
>> kernel: tg3 0000:03:00.1: eth1: 0x000036f0: 0x00000000, 0x00000000, 0x00000000, 0x00013301
>> kernel: tg3 0000:03:00.1: eth1: 0x00003800: 0x00000001, 0x00000000, 0x0000000e, 0x0516028b
>> kernel: tg3 0000:03:00.1: eth1: 0x00003810: 0x000001f6, 0x00000052, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00003c00: 0x00000306, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00003c30: 0x00000000, 0x00000000, 0x00000001, 0x74320000
>> kernel: tg3 0000:03:00.1: eth1: 0x00003c40: 0x00000000, 0x00000b00, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00003c50: 0x00000000, 0x00000020, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00003c80: 0x0000000c, 0x00000006, 0x0000000a, 0x00000004
>> kernel: tg3 0000:03:00.1: eth1: 0x00003cd0: 0x00000000, 0x0000000f, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00003d00: 0x00000001, 0x790b7000, 0x00000001, 0x7429d000
>> kernel: tg3 0000:03:00.1: eth1: 0x00003d10: 0x00000001, 0x76be5000, 0x00000001, 0x79abb000
>> kernel: tg3 0000:03:00.1: eth1: 0x00003d80: 0x00000014, 0x00000048, 0x00000005, 0x00000035
>> kernel: tg3 0000:03:00.1: eth1: 0x00003d90: 0x00000005, 0x00000005, 0x00000014, 0x00000048
>> kernel: tg3 0000:03:00.1: eth1: 0x00003da0: 0x00000005, 0x00000035, 0x00000005, 0x00000005
>> kernel: tg3 0000:03:00.1: eth1: 0x00003db0: 0x00000014, 0x00000048, 0x00000005, 0x00000035
>> kernel: tg3 0000:03:00.1: eth1: 0x00003dc0: 0x00000005, 0x00000005, 0x00000014, 0x00000048
>> kernel: tg3 0000:03:00.1: eth1: 0x00003dd0: 0x00000005, 0x00000035, 0x00000005, 0x00000005
>> kernel: tg3 0000:03:00.1: eth1: 0x00003fc0: 0x00000026, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004000: 0x00000002, 0x00000000, 0x0003afe9, 0x0014654c
>> kernel: tg3 0000:03:00.1: eth1: 0x00004010: 0x00000000, 0x00261012, 0x00000480, 0x00848042
>> kernel: tg3 0000:03:00.1: eth1: 0x00004020: 0x00000000, 0x00000000, 0x00000010, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004030: 0x00000010, 0x00000050, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004040: 0x00000000, 0x00000000, 0x01090020, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004050: 0x00000000, 0x00000000, 0x0025d010, 0x00000002
>> kernel: tg3 0000:03:00.1: eth1: 0x00004060: 0x00400000, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004400: 0x00000016, 0x00000000, 0x00010000, 0x0000a000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004410: 0x00000000, 0x0000002a, 0x000000a0, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004420: 0x0000003d, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004440: 0x00000000, 0x00000000, 0x00000000, 0x00000001
>> kernel: tg3 0000:03:00.1: eth1: 0x00004450: 0x0002033f, 0x00620063, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004800: 0x380303fe, 0x00000000, 0x00000000, 0x00000100
>> kernel: tg3 0000:03:00.1: eth1: 0x00004810: 0x00000000, 0x00000004, 0x00009c80, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004820: 0x737c0014, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004840: 0x00000000, 0x00000000, 0x00d73500, 0x00fd175d
>> kernel: tg3 0000:03:00.1: eth1: 0x00004850: 0xe58e042e, 0xd1927a2c, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004860: 0x00000014, 0x11548788, 0x00100800, 0x00040000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004870: 0x05ea0000, 0x003e1820, 0x003e1820, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004880: 0x00000014, 0xd0400c66, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004900: 0x28190404, 0x00305407, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004910: 0x000f001c, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004a00: 0x180303fe, 0x00200000, 0x00200020, 0x00210000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004a10: 0x73a113a0, 0x008ca924, 0x00200012, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004a20: 0x00000000, 0x00000000, 0xf02c0000, 0x73a11400
>> kernel: tg3 0000:03:00.1: eth1: 0x00004a30: 0x00000000, 0x00000084, 0x00000084, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004a40: 0x73a11380, 0x73a113a0, 0x73a11340, 0x73a11360
>> kernel: tg3 0000:03:00.1: eth1: 0x00004a50: 0x00200020, 0x00200020, 0x00200020, 0x00200020
>> kernel: tg3 0000:03:00.1: eth1: 0x00004a70: 0x28190404, 0x00305407, 0x000f001c, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004b00: 0x180303fe, 0x005a0003, 0x30000000, 0x01420160
>> kernel: tg3 0000:03:00.1: eth1: 0x00004b10: 0xe01a0000, 0x00000003, 0x005adc88, 0x00001692
>> kernel: tg3 0000:03:00.1: eth1: 0x00004b20: 0x00000000, 0x02000000, 0x00000000, 0x005a0000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004b30: 0x00000000, 0x00420000, 0x00000000, 0x001a0000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004b50: 0x00000000, 0x00000000, 0x88000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004b60: 0x00000000, 0x00000000, 0x88000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004b70: 0x00000000, 0x00000000, 0x88000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004b80: 0x00000000, 0x11548788, 0x00100800, 0x00040000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004b90: 0x05ea0000, 0x28190404, 0x00305407, 0x000f001c
>> kernel: tg3 0000:03:00.1: eth1: 0x00004ba0: 0x330c3000, 0x00000000, 0x11548788, 0x000f001c
>> kernel: tg3 0000:03:00.1: eth1: 0x00004bc0: 0x738e8002, 0x79fa6c02, 0x1ce29ebe, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004bd0: 0x79fa6402, 0x746ed002, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004be0: 0x0142005a, 0x0000e01a, 0x00460142, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004bf0: 0x00000000, 0x00000000, 0x88000000, 0x00003333
>> kernel: tg3 0000:03:00.1: eth1: 0x00004c00: 0x200003fe, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004c10: 0x0000002a, 0x00000000, 0x00000006, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004c20: 0x00000000, 0x00000000, 0x00000000, 0x00000006
>> kernel: tg3 0000:03:00.1: eth1: 0x00004c30: 0x00000000, 0x00018000, 0x00108000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00004c40: 0x00000020, 0x00000000, 0x001d0020, 0x00040020
>> kernel: tg3 0000:03:00.1: eth1: 0x00004c50: 0x0900500b, 0x0000b003, 0x0400a006, 0x00200303
>> kernel: tg3 0000:03:00.1: eth1: 0x00004c60: 0x00000020, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005000: 0x00009800, 0x80004000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005010: 0x00000000, 0x00000000, 0x00000000, 0x08002c9c
>> kernel: tg3 0000:03:00.1: eth1: 0x00005020: 0x0e000b25, 0x00000000, 0x00000000, 0x40000020
>> kernel: tg3 0000:03:00.1: eth1: 0x00005030: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005040: 0x00000000, 0x00000000, 0x080019d2, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005080: 0x00009800, 0x80000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005090: 0x00000000, 0x00000000, 0x00000000, 0x08001fac
>> kernel: tg3 0000:03:00.1: eth1: 0x000050a0: 0x30422000, 0x00000000, 0x00000000, 0x40000020
>> kernel: tg3 0000:03:00.1: eth1: 0x000050b0: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000050c0: 0x00000000, 0x00000000, 0x08000088, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005100: 0x00009800, 0x80000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005110: 0x00000000, 0x00000000, 0x00000000, 0x080019c4
>> kernel: tg3 0000:03:00.1: eth1: 0x00005120: 0x30422000, 0x00000000, 0x00000000, 0x40000020
>> kernel: tg3 0000:03:00.1: eth1: 0x00005130: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005140: 0x00000000, 0x00000000, 0x08002cd4, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005180: 0x00009800, 0x80004000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005190: 0x00000000, 0x00000000, 0x00000000, 0x08002ca0
>> kernel: tg3 0000:03:00.1: eth1: 0x000051a0: 0x00621024, 0x00000000, 0x00000000, 0x40000020
>> kernel: tg3 0000:03:00.1: eth1: 0x000051b0: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000051c0: 0x00000000, 0x00000000, 0x08000088, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005200: 0x14600027, 0x144001e2, 0x144001e2, 0x3c038000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005210: 0x01020000, 0x01020000, 0xc0000000, 0xdeaddead
>> kernel: tg3 0000:03:00.1: eth1: 0x00005220: 0xdeaddead, 0x3c038000, 0xc0000000, 0x01020000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005230: 0x14600027, 0x00000000, 0xc0000000, 0x14600027
>> kernel: tg3 0000:03:00.1: eth1: 0x00005240: 0xb49a89ab, 0x144001e2, 0x144001e2, 0x14600027
>> kernel: tg3 0000:03:00.1: eth1: 0x00005250: 0x00000b50, 0x144001e2, 0x3c038000, 0xc0010000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005260: 0x00000000, 0x00000b50, 0x01020000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005270: 0x00000000, 0x14600027, 0xb49a89ab, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005280: 0x00009800, 0x80000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005290: 0x00000000, 0x00000000, 0x00000000, 0x08002c9c
>> kernel: tg3 0000:03:00.1: eth1: 0x000052a0: 0x30422000, 0x00000000, 0x00000000, 0x40000020
>> kernel: tg3 0000:03:00.1: eth1: 0x000052b0: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000052c0: 0x00000000, 0x00000000, 0x080027fc, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005300: 0x00009800, 0x80004000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005310: 0x00000000, 0x00000000, 0x00000000, 0x08001fc0
>> kernel: tg3 0000:03:00.1: eth1: 0x00005320: 0x00831824, 0x00000000, 0x00000000, 0x40000020
>> kernel: tg3 0000:03:00.1: eth1: 0x00005330: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005340: 0x00000000, 0x00000000, 0x08002cb6, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005380: 0x00009800, 0x80004000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005390: 0x00000000, 0x00000000, 0x00000000, 0x08002068
>> kernel: tg3 0000:03:00.1: eth1: 0x000053a0: 0x8c434014, 0x00000000, 0x00000000, 0x40000020
>> kernel: tg3 0000:03:00.1: eth1: 0x000053b0: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000053c0: 0x00000000, 0x00000000, 0x080027fc, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005800: 0x03000000, 0x03000000, 0x0d000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005810: 0x07000000, 0x00000000, 0x0b000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005820: 0x04000000, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005860: 0x00000000, 0x00000000, 0x000000e8, 0x000000e8
>> kernel: tg3 0000:03:00.1: eth1: 0x00005880: 0x0000000c, 0x0000000c, 0x00000006, 0x00000006
>> kernel: tg3 0000:03:00.1: eth1: 0x00005890: 0x0000000a, 0x0000000a, 0x00000004, 0x00000004
>> kernel: tg3 0000:03:00.1: eth1: 0x00005900: 0x00000000, 0x00000000, 0x00000001, 0x00000001
>> kernel: tg3 0000:03:00.1: eth1: 0x00005980: 0x00000000, 0x00000001, 0x00000001, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00005a00: 0x000f601f, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00006000: 0x00010082, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00006400: 0x00000000, 0x00000000, 0x00010091, 0xc0000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00006410: 0x0a000064, 0x0a000064, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00006430: 0x00000000, 0x14e4165f, 0x165f14e4, 0x00020000
>> kernel: tg3 0000:03:00.1: eth1: 0x00006440: 0x0000304f, 0x000002e4, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000064c0: 0x00000010, 0x00000004, 0x00001004, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000064d0: 0x00000000, 0x10008d81, 0x00000000, 0x00315e22
>> kernel: tg3 0000:03:00.1: eth1: 0x000064e0: 0x00000031, 0x0000001f, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000064f0: 0x00000002, 0x00000031, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00006500: 0x01e10003, 0xd0400c65, 0x00000014, 0x00000003
>> kernel: tg3 0000:03:00.1: eth1: 0x00006510: 0x0007811b, 0x00058116, 0x00046113, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00006550: 0x00000000, 0x02800000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000065f0: 0x00000000, 0x00000109, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00006800: 0x14130034, 0x20099082, 0x01000008, 0x00a16dd0
>> kernel: tg3 0000:03:00.1: eth1: 0x00006810: 0x01020000, 0xffffffff, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00006830: 0xffffffff, 0xffffffff, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00006840: 0x00000000, 0x00000001, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00006890: 0x00000000, 0x88003800, 0x00000000, 0x04102040
>> kernel: tg3 0000:03:00.1: eth1: 0x000068a0: 0x00000020, 0x00000001, 0x03ff03ff, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000068b0: 0xe0011514, 0x00000000, 0x00000000, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x000068f0: 0x00ff000e, 0x00ff0000, 0x00000000, 0x04444444
>> kernel: tg3 0000:03:00.1: eth1: 0x00006920: 0x00000000, 0x00000000, 0x00000001, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0x00007000: 0x00000008, 0x00000000, 0x00000000, 0x00004868
>> kernel: tg3 0000:03:00.1: eth1: 0x00007010: 0x1a5876c2, 0x01c080f3, 0x00d70081, 0x03008200
>> kernel: tg3 0000:03:00.1: eth1: 0x00007020: 0x00000000, 0x00000000, 0x00000406, 0x10004000
>> kernel: tg3 0000:03:00.1: eth1: 0x00007030: 0x000e0000, 0x0000486c, 0x00170030, 0x00000000
>> kernel: tg3 0000:03:00.1: eth1: 0: Host status block [00000005:00000003:(0000:0000:0000):(0000:0000)]
>> kernel: tg3 0000:03:00.1: eth1: 0: NAPI info [00000003:00000003:(0000:0000:01ff):0000:(00f2:0000:0000:0000)]
>> kernel: tg3 0000:03:00.1: eth1: 1: Host status block [00000001:00000013:(0000:0000:0000):(0012:0000)]
>> kernel: tg3 0000:03:00.1: eth1: 1: NAPI info [00000013:00000013:(0000:0000:01ff):0012:(0012:0012:0000:0000)]
>> kernel: tg3 0000:03:00.1: eth1: 2: Host status block [00000001:00000007:(0006:0000:0000):(0000:0000)]
>> kernel: tg3 0000:03:00.1: eth1: 2: NAPI info [00000007:00000007:(0001:0000:01ff):0006:(0006:0006:0000:0000)]
>> kernel: tg3 0000:03:00.1: eth1: 3: Host status block [00000001:0000000b:(0000:0000:0000):(0000:0000)]
>> kernel: tg3 0000:03:00.1: eth1: 3: NAPI info [0000000b:0000000b:(0001:0000:01ff):000a:(000a:000a:0000:0000)]
>> kernel: tg3 0000:03:00.1: eth1: 4: Host status block [00000001:00000007:(0000:0000:0008):(0000:0000)]
>> kernel: tg3 0000:03:00.1: eth1: 4: NAPI info [00000007:00000007:(0000:0000:01ff):0008:(0008:0008:0000:0000)]
>> kernel: tg3 0000:03:00.1: eth1: Link is down
>>
>>
>> 03:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet PCIe
>> Subsystem: Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet PCIe
>> 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 B routed to IRQ 19
>> Region 0: Memory at bc140000 (64-bit, prefetchable) [size=64K]
>> Region 2: Memory at bc130000 (64-bit, prefetchable) [size=64K]
>> Region 4: Memory at bc120000 (64-bit, prefetchable) [size=64K]
>> Capabilities: [48] Power Management version 3
>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
>> Capabilities: [50] Vital Product Data
>> Product Name: Broadcom NetXtreme Gigabit Ethernet Controller
>> Read-only fields:
>> [PN] Part number: BCM95720
>> [EC] Engineering changes: 106679-15
>> [MN] Manufacture ID: 31 34 65 34
>> [RV] Reserved: checksum good, 28 byte(s) reserved
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* BCM5720 'no firmware running'
From: Atif Faheem @ 2013-11-24 9:39 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi. I am observing a strange problem with the 5720. Sometimes during the boot up of the 5720, after both interfaces have been added to a bond, tg3 throws the error ‘no firmware running’ and all registers are -1. This happens on both interfaces. A power cycle is needed in order to recover the device. We are using kernel 3.4.34 - I haven’t tried to build the driver from the latest kernel (I will have to back-port). Any input will be great.
Thanks - Atif
---
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off
----
2013-11-20T02:06:02.659773-05:00 pld0112 kernel: bonding: bond0: enslaving eth0 as an active interface with a down link.
2013-11-20T02:06:02.659806-05:00 pld0112 kernel: bonding: bond0: enslaving eth1 as an active interface with a down link.
2013-11-20T02:06:02.659809-05:00 pld0112 kernel: tg3 0000:03:00.0: eth0: Link is up at 1000 Mbps, full duplex
2013-11-20T02:06:02.659812-05:00 pld0112 kernel: tg3 0000:03:00.0: eth0: Flow control is off for TX and off for RX
2013-11-20T02:06:02.659815-05:00 pld0112 kernel: tg3 0000:03:00.0: eth0: EEE is disabled
2013-11-20T02:06:02.659818-05:00 pld0112 kernel: bonding: bond0: link status definitely up for interface eth0, 1000 Mbps full duplex.
2013-11-20T02:06:02.659821-05:00 pld0112 kernel: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
2013-11-20T02:06:02.659832-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: Link is up at 1000 Mbps, full duplex
2013-11-20T02:06:02.659837-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: Flow control is off for TX and off for RX
2013-11-20T02:06:02.659840-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: EEE is disabled
2013-11-20T02:06:02.659843-05:00 pld0112 kernel: bonding: bond0: link status definitely up for interface eth1, 1000 Mbps full duplex.
2013-11-20T02:06:22.465353-05:00 pld0112 kernel: nfs: server 100.100.0.6 not responding, still trying
2013-11-20T02:06:25.937609-05:00 pld0112 kernel: ------------[ cut here ]------------
2013-11-20T02:06:25.937642-05:00 pld0112 kernel: WARNING: at /home/jenkins/jobs/r102-os/workspace/opt/os/wrlinux/builds/atom64/bitbake_build/tmp/work/intel_atom_64-wrs-linux/linux-windriver-3.4-r0/linux/net/sched/sch_generic.c:256 dev_watchdog+0x277/0x280()
2013-11-20T02:06:25.937649-05:00 pld0112 kernel: Hardware name: To be filled by O.E.M.
2013-11-20T02:06:25.937653-05:00 pld0112 kernel: NETDEV WATCHDOG: eth1 (tg3): transmit queue 1 timed out
2013-11-20T02:06:25.937657-05:00 pld0112 kernel: Modules linked in: firmware_class hwmon libphy tg3 x_tables ip_tables iptable_filter exportfs coretemp minix ipmi_devintf bonding nfsd ipmi_msghandler ipmi_si [last unloaded: bonding]
2013-11-20T02:06:25.937662-05:00 pld0112 kernel: Pid: 0, comm: swapper/0 Not tainted 3.4.34-WR5.0.1.3_standard #1
2013-11-20T02:06:25.937668-05:00 pld0112 kernel: Call Trace:
2013-11-20T02:06:25.937728-05:00 pld0112 kernel: <IRQ> [<ffffffff81030c84>] warn_slowpath_common+0x84/0xc0
2013-11-20T02:06:25.937734-05:00 pld0112 kernel: [<ffffffff81030d77>] warn_slowpath_fmt+0x47/0x50
2013-11-20T02:06:25.937739-05:00 pld0112 kernel: [<ffffffff816799f7>] dev_watchdog+0x277/0x280
2013-11-20T02:06:25.937744-05:00 pld0112 kernel: [<ffffffff81040784>] run_timer_softirq+0x134/0x420
2013-11-20T02:06:25.937747-05:00 pld0112 kernel: [<ffffffff8134f5ee>] ? timerqueue_add+0x6e/0xc0
2013-11-20T02:06:25.937751-05:00 pld0112 kernel: [<ffffffff81679780>] ? qdisc_reset+0x50/0x50
2013-11-20T02:06:25.937756-05:00 pld0112 kernel: [<ffffffff8103811d>] __do_softirq+0xbd/0x280
2013-11-20T02:06:25.937760-05:00 pld0112 kernel: [<ffffffff81079375>] ? clockevents_program_event+0x75/0xf0
2013-11-20T02:06:25.937765-05:00 pld0112 kernel: [<ffffffff8107a7b4>] ? tick_program_event+0x24/0x30
2013-11-20T02:06:25.937769-05:00 pld0112 kernel: [<ffffffff81777b8c>] call_softirq+0x1c/0x30
2013-11-20T02:06:25.937773-05:00 pld0112 kernel: [<ffffffff810037b5>] do_softirq+0x55/0x90
2013-11-20T02:06:25.937778-05:00 pld0112 kernel: [<ffffffff810385ee>] irq_exit+0x8e/0xb0
2013-11-20T02:06:25.937783-05:00 pld0112 kernel: [<ffffffff817781e9>] smp_apic_timer_interrupt+0x99/0x1cd
2013-11-20T02:06:25.937788-05:00 pld0112 kernel: [<ffffffff817773c7>] apic_timer_interrupt+0x67/0x70
2013-11-20T02:06:25.937791-05:00 pld0112 kernel: <EOI> [<ffffffff813c2689>] ? acpi_idle_enter_bm+0x240/0x281
2013-11-20T02:06:25.937796-05:00 pld0112 kernel: [<ffffffff813c2684>] ? acpi_idle_enter_bm+0x23b/0x281
2013-11-20T02:06:25.937800-05:00 pld0112 kernel: [<ffffffff815cc58f>] ? menu_select+0xff/0x3c0
2013-11-20T02:06:25.937804-05:00 pld0112 kernel: [<ffffffff815ca8d8>] cpuidle_enter+0x18/0x20
2013-11-20T02:06:25.937808-05:00 pld0112 kernel: [<ffffffff815caf59>] cpuidle_idle_call+0xc9/0x3b0
2013-11-20T02:06:25.937813-05:00 pld0112 kernel: [<ffffffff8100b59f>] cpu_idle+0x7f/0xd0
2013-11-20T02:06:25.937817-05:00 pld0112 kernel: [<ffffffff8174b3a7>] rest_init+0x7b/0x84
2013-11-20T02:06:25.937821-05:00 pld0112 kernel: [<ffffffff81cd3b76>] start_kernel+0x35b/0x369
2013-11-20T02:06:25.937826-05:00 pld0112 kernel: [<ffffffff81cd3616>] ? repair_env_string+0x5a/0x5a
2013-11-20T02:06:25.937830-05:00 pld0112 kernel: [<ffffffff81cd3321>] x86_64_start_reservations+0x131/0x135
2013-11-20T02:06:25.937834-05:00 pld0112 kernel: [<ffffffff81cd3416>] x86_64_start_kernel+0xf1/0xf9
2013-11-20T02:06:25.937839-05:00 pld0112 kernel: ---[ end trace e28305a78a341f61 ]---
2013-11-20T02:06:25.937843-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: transmit timed out, resetting
2013-11-20T02:06:25.960660-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 0x00000000: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
2013-11-20T02:06:25.960689-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 0x00000010: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
2013-11-20T02:06:25.960698-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 0x00000020: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
2013-11-20T02:06:25.960703-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 0x00000030: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
2013-11-20T02:06:25.960707-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 0x00000040: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
2013-11-20T02:06:25.960712-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 0x00000050: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
….
….
2013-11-20T02:06:26.081578-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 0: Host status block [00000005:00000003:(0000:0000:0000):(0000:0000)]
2013-11-20T02:06:26.081583-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 0: NAPI info [00000003:00000003:(0000:0000:01ff):0000:(0402:0000:0000:0000)]
2013-11-20T02:06:26.081588-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 1: Host status block [00000001:00000097:(0000:0000:0000):(01f9:0007)]
2013-11-20T02:06:26.081606-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 1: NAPI info [00000097:00000097:(0007:0007:01ff):01f9:(01f9:01f9:0000:0000)]
2013-11-20T02:06:26.081613-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 2: Host status block [00000001:000000e2:(0028:0000:0000):(0000:00f5)]
2013-11-20T02:06:26.081618-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 2: NAPI info [000000e2:000000e2:(0101:00f5:01ff):0028:(0028:0028:0000:0000)]
2013-11-20T02:06:26.081623-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 3: Host status block [00000001:000000f0:(0000:0000:0000):(0000:0066)]
2013-11-20T02:06:26.081627-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 3: NAPI info [000000f0:000000f0:(0069:0066:01ff):08b6:(00b6:00b6:0000:0000)]
2013-11-20T02:06:26.081632-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 4: Host status block [00000001:0000004b:(0000:0000:0063):(0000:0002)]
2013-11-20T02:06:26.081638-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: 4: NAPI info [0000004b:0000004b:(0002:0002:01ff):0063:(0063:0063:0000:0000)]
2013-11-20T02:06:26.095286-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=2c00 enable_bit=2
2013-11-20T02:06:26.197287-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=2000 enable_bit=2
2013-11-20T02:06:26.300286-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=2400 enable_bit=2
2013-11-20T02:06:26.402277-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=2800 enable_bit=2
2013-11-20T02:06:26.504264-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=3000 enable_bit=2
2013-11-20T02:06:26.606267-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=1400 enable_bit=2
2013-11-20T02:06:26.708264-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=1800 enable_bit=2
2013-11-20T02:06:26.810264-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=c00 enable_bit=2
2013-11-20T02:06:26.912259-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=4800 enable_bit=2
2013-11-20T02:06:27.014273-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=1000 enable_bit=2
2013-11-20T02:06:27.116264-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=1c00 enable_bit=2
2013-11-20T02:06:27.218282-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_abort_hw timed out, TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff
2013-11-20T02:06:27.320264-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=3c00 enable_bit=2
2013-11-20T02:06:27.422240-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_stop_block timed out, ofs=4c00 enable_bit=2
2013-11-20T02:06:28.964261-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: No firmware running
2013-11-20T02:06:30.188256-05:00 pld0112 kernel: tg3 0000:03:00.1: tg3_abort_hw timed out, TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff
2013-11-20T02:06:44.447246-05:00 pld0112 kernel: tg3 0000:03:00.1: eth1: Link is down
2013-11-20T02:06:44.458245-05:00 pld0112 kernel: bonding: bond0: link status definitely down for interface eth1, disabling it
2013-11-20T02:06:44.507338-05:00 pld0112 kernel: tg3 0000:03:00.0: eth0: transmit timed out, resetting
2013-11-20T02:06:44.507375-05:00 pld0112 kernel: nfs: server 100.100.0.6 not responding, still trying
^ permalink raw reply
* Re: [PATCH net v3] vti: fix spd lookup: match plaintext pkt, not ipsec pkt
From: Fan Du @ 2013-11-24 10:21 UTC (permalink / raw)
To: Saurabh Mohan
Cc: Christophe Gouault, Steffen Klassert, David S. Miller, Herbert Xu,
netdev@vger.kernel.org, Sergei Shtylyov, Eric Dumazet
In-Reply-To: <1902752B0C92F943AB7EA9EE13E2DEEC1273BA9ACD@HQ1-EXCH02.corp.brocade.com>
On 2013年11月22日 02:39, Saurabh Mohan wrote:
>
>
>> -----Original Message-----
>> From: Fan Du [mailto:fan.du@windriver.com]
>> Sent: Tuesday, November 19, 2013 1:17 AM
>> To: Saurabh Mohan
>> Cc: Christophe Gouault; Steffen Klassert; David S. Miller; Herbert Xu;
>> netdev@vger.kernel.org; Sergei Shtylyov; Eric Dumazet
>> Subject: Re: [PATCH net v3] vti: fix spd lookup: match plaintext pkt, not ipsec
>> pkt
>>
>> Hi, Saurabh
>>
>> On 2013年11月19日 05:38, Saurabh Mohan wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Christophe Gouault [mailto:christophe.gouault@6wind.com]
>>>> Sent: Thursday, November 07, 2013 4:56 AM
>>>> To: Steffen Klassert
>>>> Cc: David S. Miller; Herbert Xu; netdev@vger.kernel.org; Saurabh Mohan;
>>>> Sergei Shtylyov; Eric Dumazet
>>>> Subject: Re: [PATCH net v3] vti: fix spd lookup: match plaintext pkt, not
>> ipsec
>>>> pkt
>>>>
>>>> Hello Steffen,
>>>>
>>>> I am also interested in knowing Saurabh's intentions regarding the
>>>> behavior of policies bound to vti interfaces.
>>>>
>>> The semantics is to match the policy "src 0.0.0.0/0 dst 0.0.0.0/0 proto any"
>>> That is the only policy that VTI should use. The mark is needed to
>>> distinguish and limit the policy to a specific vti tunnel interface only.
>>> There is no other policy that may be applied to a vti interface.
>>> The fact that traffic is going over the tunnel interface implies that it
>>> must be encrypted/decrypted. Applying the above policy is a way
>>> to achieve that.
>>
>> I'm not much experienced with VTI usage practical production usage
>> scenario, but
>> I have one question about the necessity of policy checking on VTI receiving
>> part.
>> - A VTI tunnel is hashed by destination address and i_key when creating
>> them;
>> - After each tunneled IP packet delivered to vti_rcv, the first step is looking
>> for the right tunnel, this is done by using tunneled IP packet outer source
>> and
>> destination address without any key matching rule involved.
>>
>> If there are any other tunnel with the same source/destination address, but
>> not
>> the same mark in place, the tunnel lookup in the vti_rcv will properly not hit
>> VTI tunnel, but the non-VTI tunnel. So the VTI net device statistics will not be
>> accurate, and what's the point of checking policy for the wrong tunnel
>> interface?
>
> So far this is not supported. If it were needed then we'd have to use another
> key on the tunnel(s) to distinguish between tunnel with same src and dst.
> In such a case there would be two keys on the tunnel (one for vti mark
> and the other one to separate out tunnels with same src and dst).
>
That's indeed what I am pointing, one vti tunnel with mark_a,
another tunnel sharing same VTI tunnel's src/dst address with
only different mark_b/wildcard mark. This configuration probably
cause vti_rcv using the non-VTI tunnel for the policy checking.
So after b2942004fb5c9f3304b77e187b8a1977b3626c9b ("ipv4/ip_vti.c:
VTI fix post-decryption forwarding"), no other non-VTI tunnel
should be mingled with VTI tunnel, otherwise, the forward process
will be malfunctional.
--
浮沉随浪只记今朝笑
--fan fan
^ permalink raw reply
* Re: Possible bit/byte conversion mistake in xfrm_state.c
From: Fan Du @ 2013-11-24 11:54 UTC (permalink / raw)
To: Marksteiner, Stefan; +Cc: netdev
In-Reply-To: <528F7009.4080303@joanneum.at>
Please wrap the line in shorter length ;)
On 2013年11月22日 22:54, Marksteiner, Stefan wrote:
> Hi folks,
>
> I might have found a little bit/byte mistake in xfrm_state.c of iproute2-3.11.0 (and also lower versions).
>
> In line 169 the algorithm length is set correctly ("alg->alg_key_len = len * 8;") in bits (as it is supposed by /usr/include/linux/xfrm.h, line 101), but later in line 496 the same value is read and added to a length value in bytes ("len += alg.u.alg.alg_key_len;").
>
> I'm not completetly sure, but I'm wondering if this might lead to errors for algorithms with big key sizes (>2048 bits) for the key buffer ("char buf[RTA_BUF_SIZE]" in line 274) reserves only 2048 bytes of memory (RTA_BUF_SIZE=2048). So taking bits for bytes, the following memcopy operation may overwrite adjacent memory areas.
>
> Can somebody verify if this is in fact an issue? Maybe I'm reading this whole stuff wrong.
You are totally right about this bit/byte mistake here.
Normally the aes key len is 128bits, and 160bits for sha1, and
the key buf defined here is XFRM_ALGO_KEY_BUF_SIZE 512 bytes,
so there are stale data append after each key content, although
is not used by key interface anyway, which means the IPsec
communication goes well after all.
--
浮沉随浪只记今朝笑
--fan fan
^ permalink raw reply
* Re: [PATCH 3/3] xfrm: Fix null pointer dereference when decoding sessions
From: Matthias Schiffer @ 2013-11-24 14:27 UTC (permalink / raw)
To: Steffen Klassert, David Miller; +Cc: Herbert Xu, netdev
In-Reply-To: <1383294107-7509-4-git-send-email-steffen.klassert@secunet.com>
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]
On 11/01/2013 09:21 AM, Steffen Klassert wrote:
> On some codepaths the skb does not have a dst entry
> when xfrm_decode_session() is called. So check for
> a valid skb_dst() before dereferencing the device
> interface index. We use 0 as the device index if
> there is no valid skb_dst(), or at reverse decoding
> we use skb_iif as device interface index.
>
> Bug was introduced with git commit bafd4bd4dc
> ("xfrm: Decode sessions with output interface.").
>
> Reported-by: Meelis Roos <mroos@linux.ee>
> Tested-by: Meelis Roos <mroos@linux.ee>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Please queue this for 3.12-stable, I've seen this bug trigger a panic
when heavily using Bittorrent (screenshot:
http://i.imgur.com/OIKVccM.jpg )
Thanks,
Matthias
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* AF_ALG does not work with sendfile()
From: Shawn Landden @ 2013-11-24 17:12 UTC (permalink / raw)
To: Linux Kernel Mailing List, netdev, linux-crypto, herbert
If I use sendfile() to send to a accept()ed AF_ALG socket set up for
"hash", I get the wrong
answer, if I read() and then write() I get the right answer. None of
the system calls return an error.
---
Shawn Landden
+1 360 389 3001 (SMS preferred)
^ permalink raw reply
* AF_ALG buggy with sendfile
From: Shawn Landden @ 2013-11-24 17:21 UTC (permalink / raw)
To: Linux Kernel Mailing List, netdev, herbert, linux-crypto
[-- Attachment #1: Type: text/plain, Size: 273 bytes --]
If I use sendfile() to send to a accept()ed AF_ALG socket set up for
"hash", I get the wrong
answer, if I read() and then write() I get the right answer. None of
the system calls return an error.
test case attached.
--
---
Shawn Landden
+1 360 389 3001 (SMS preferred)
[-- Attachment #2: af_alg.c --]
[-- Type: text/x-csrc, Size: 976 bytes --]
#include <sys/sendfile.h>
#include <sys/socket.h>
#include <linux/if_alg.h>
#include <stdio.h>
#include <sys/stat.h>
#include <fcntl.h>
int main(void)
{
int opfd;
int tfmfd;
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "hash",
.salg_name = "sha1"
};
char buf2[10000000];
char buf[20];
int i;
struct stat st;
tfmfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(tfmfd, (struct sockaddr *)&sa, sizeof(sa));
opfd = accept(tfmfd, NULL, 0);
int true = open("/bin/true", O_RDONLY);
fstat(true, &st);
sendfile(opfd, true, NULL, st.st_size);
read(opfd, &buf, 20);
for (i = 0; i < 20; i++) {
printf("%02x", (unsigned char)buf[i]);
}
printf("\n");
lseek(true, 0, SEEK_SET);
read(true, &buf2, st.st_size);
write(opfd, &buf2, st.st_size);
read(opfd, &buf, 20);
for (i = 0; i < 20; i++) {
printf("%02x", (unsigned char)buf[i]);
}
printf("\n");
close(opfd);
close(tfmfd);
return 0;
}
^ permalink raw reply
* Re: [PATCH net v3 1/2] net: sched: tbf: fix calculation of max_size
From: Eric Dumazet @ 2013-11-24 18:40 UTC (permalink / raw)
To: Yang Yingliang; +Cc: Yang Yingliang, davem, netdev, brouer, jpirko, jbrouer
In-Reply-To: <5291AA8D.6060108@gmail.com>
On Sun, 2013-11-24 at 15:28 +0800, Yang Yingliang wrote:
> O>
> >> With the follow command:
> >> tc qdisc add dev eth1 root handle 1: tbf latency 50ms burst 10KB rate 30gbit mtu 64k
> >>
> >
> Ideally burst should be 10KB in kernel space.
> But at hight rates, when burst is converted to
> time in tick in userland, it gets much more loss
> than low rates. So the burst can't actually
> reach 10KB in kernel.
If you think tc can help to fix user choices, please provide an
iproute2 patch.
Quite frankly, using a burst of 10KB and a rate of 30gbit is simply a
user error. It cannot possibly work. At all.
As stated in many tbf docs, burst must be larger than device mtu (1514)
By extension, with GRO/GSO, burst should be larger than 68130, otherwise
we need to segment the packets, and this is horribly expensive for high
rates.
I personally tc/tbf needs some changes, because the logical way would be
to use the 1514 value for low rates, but if we use this value, the
kernel gets a value of 1511, which doesn't work.
^ permalink raw reply
* [PATCH 3.13] genetlink/pmcraid: use proper genetlink multicast API
From: Johannes Berg @ 2013-11-24 20:09 UTC (permalink / raw)
To: netdev; +Cc: Anil Ravindranath, James E.J. Bottomley, linux-scsi,
Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
The pmcraid driver is abusing the genetlink API and is using its
family ID as the multicast group ID, which is invalid and may
belong to somebody else (and likely will.)
Make it use the correct API, but since this may already be used
as-is by userspace, reserve a family ID for this code and also
reserve that group ID to not break userspace assumptions.
My previous patch broke event delivery in the driver as I missed
that it wasn't using the right API and forgot to update it later
in my series.
While changing this, I noticed that the genetlink code could use
the static group ID instead of a strcmp(), so also do that for
the VFS_DQUOT family.
Cc: Anil Ravindranath <anil_ravindranath@pmc-sierra.com>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/scsi/pmcraid.c | 20 +++++++++++++++-----
include/uapi/linux/genetlink.h | 1 +
net/netlink/genetlink.c | 11 +++++++++--
3 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index bd6f743..892ea61 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -1404,11 +1404,22 @@ enum {
};
#define PMCRAID_AEN_CMD_MAX (__PMCRAID_AEN_CMD_MAX - 1)
+static struct genl_multicast_group pmcraid_mcgrps[] = {
+ { .name = "events", /* not really used - see ID discussion below */ },
+};
+
static struct genl_family pmcraid_event_family = {
- .id = GENL_ID_GENERATE,
+ /*
+ * Due to prior multicast group abuse (the code having assumed that
+ * the family ID can be used as a multicast group ID) we need to
+ * statically allocate a family (and thus group) ID.
+ */
+ .id = GENL_ID_PMCRAID,
.name = "pmcraid",
.version = 1,
- .maxattr = PMCRAID_AEN_ATTR_MAX
+ .maxattr = PMCRAID_AEN_ATTR_MAX,
+ .mcgrps = pmcraid_mcgrps,
+ .n_mcgrps = ARRAY_SIZE(pmcraid_mcgrps),
};
/**
@@ -1511,9 +1522,8 @@ static int pmcraid_notify_aen(
return result;
}
- result =
- genlmsg_multicast(&pmcraid_event_family, skb, 0,
- pmcraid_event_family.id, GFP_ATOMIC);
+ result = genlmsg_multicast(&pmcraid_event_family, skb,
+ 0, 0, GFP_ATOMIC);
/* If there are no listeners, genlmsg_multicast may return non-zero
* value.
diff --git a/include/uapi/linux/genetlink.h b/include/uapi/linux/genetlink.h
index 1af72d82..c3363ba 100644
--- a/include/uapi/linux/genetlink.h
+++ b/include/uapi/linux/genetlink.h
@@ -28,6 +28,7 @@ struct genlmsghdr {
#define GENL_ID_GENERATE 0
#define GENL_ID_CTRL NLMSG_MIN_TYPE
#define GENL_ID_VFS_DQUOT (NLMSG_MIN_TYPE + 1)
+#define GENL_ID_PMCRAID (NLMSG_MIN_TYPE + 2)
/**************************************************************************
* Controller
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 4518a57..1e393aa 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -74,9 +74,12 @@ static struct list_head family_ht[GENL_FAM_TAB_SIZE];
* Bit 17 is marked as already used since the VFS quota code
* also abused this API and relied on family == group ID, we
* cater to that by giving it a static family and group ID.
+ * Bit 18 is marked as already used since the PMCRAID driver
+ * did the same thing as the VFS quota code (maybe copied?)
*/
static unsigned long mc_group_start = 0x3 | BIT(GENL_ID_CTRL) |
- BIT(GENL_ID_VFS_DQUOT);
+ BIT(GENL_ID_VFS_DQUOT) |
+ BIT(GENL_ID_PMCRAID);
static unsigned long *mc_groups = &mc_group_start;
static unsigned long mc_groups_longs = 1;
@@ -139,6 +142,7 @@ static u16 genl_generate_id(void)
for (i = 0; i <= GENL_MAX_ID - GENL_MIN_ID; i++) {
if (id_gen_idx != GENL_ID_VFS_DQUOT &&
+ id_gen_idx != GENL_ID_PMCRAID &&
!genl_family_find_byid(id_gen_idx))
return id_gen_idx;
if (++id_gen_idx > GENL_MAX_ID)
@@ -236,9 +240,12 @@ static int genl_validate_assign_mc_groups(struct genl_family *family)
} else if (strcmp(family->name, "NET_DM") == 0) {
first_id = 1;
BUG_ON(n_groups != 1);
- } else if (strcmp(family->name, "VFS_DQUOT") == 0) {
+ } else if (family->id == GENL_ID_VFS_DQUOT) {
first_id = GENL_ID_VFS_DQUOT;
BUG_ON(n_groups != 1);
+ } else if (family->id == GENL_ID_PMCRAID) {
+ first_id = GENL_ID_PMCRAID;
+ BUG_ON(n_groups != 1);
} else {
groups_allocated = true;
err = genl_allocate_reserve_groups(n_groups, &first_id);
--
1.8.4.rc3
^ permalink raw reply related
* Re: AF_ALG buggy with sendfile
From: Shawn Landden @ 2013-11-24 22:00 UTC (permalink / raw)
To: Linux Kernel Mailing List, netdev, herbert, linux-crypto
In-Reply-To: <CAJusiZVq3O1rok20HyYaoJDWxjtBdvMbDtjCif+sCyKPzpXMNA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
heres a version of the test case that builds.....
Sorry about that.
On Sun, Nov 24, 2013 at 9:21 AM, Shawn Landden <shawnlandden@gmail.com> wrote:
> If I use sendfile() to send to a accept()ed AF_ALG socket set up for
> "hash", I get the wrong
> answer, if I read() and then write() I get the right answer. None of
> the system calls return an error.
>
> test case attached.
>
> --
>
> ---
> Shawn Landden
> +1 360 389 3001 (SMS preferred)
--
---
Shawn Landden
+1 360 389 3001 (SMS preferred)
[-- Attachment #2: af_alg.c --]
[-- Type: text/x-csrc, Size: 1123 bytes --]
#include <sys/sendfile.h>
#include <sys/socket.h>
#include <linux/if_alg.h>
#include <stdio.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdlib.h>
#include <unistd.h>
int main(void)
{
int opfd;
int tfmfd;
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "hash",
.salg_name = "sha1"
};
char *buf2;
char buf[20];
int i;
struct stat st;
ssize_t size;
tfmfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(tfmfd, (struct sockaddr *)&sa, sizeof(sa));
opfd = accept(tfmfd, NULL, 0);
int t = open("/bin/true", O_RDONLY);
fstat(t, &st);
size = sendfile(opfd, t, NULL, st.st_size);
if (size != st.st_size)
exit(1);
read(opfd, &buf, 20);
for (i = 0; i < 20; i++) {
printf("%02x", (unsigned char)buf[i]);
}
printf("\n");
lseek(t, 0, SEEK_SET);
buf2 = malloc(st.st_size + 1);
read(t, buf2, st.st_size);
write(opfd, buf2, st.st_size);
read(opfd, &buf, 20);
for (i = 0; i < 20; i++) {
printf("%02x", (unsigned char)buf[i]);
}
printf("\n");
close(opfd);
close(tfmfd);
return 0;
}
^ permalink raw reply
* Re: AF_ALG buggy with sendfile
From: Shawn Landden @ 2013-11-24 22:04 UTC (permalink / raw)
To: Linux Kernel Mailing List, netdev, Herbert Xu, linux-crypto
In-Reply-To: <CAJusiZXN4dOxg9S4ZiCziVXfNZ+=yu7a=84vUikV2RhbhYU7QA@mail.gmail.com>
If you build https://kernel.googlesource.com/pub/scm/network/connman/connman/+/0.80/tools/alg-test.c
from the connman source code and compare the output to coreutils
sha1sum you can see the problem.
shawn@debian-T61:~/git/test$ make connman_afalg
cc connman_afalg.c -o connman_afalg
shawn@debian-T61:~/git/test$ ./connman_afalg /bin/true
send 27080 bytes
recv 20 bytes
45384483cf9cd0d82eba164131795b4807c6d39d /bin/true
shawn@debian-T61:~/git/test$ sha1sum /bin/true
82667ba2ec681d8e55b0ee3b6db2970f9911680d /bin/true
On Sun, Nov 24, 2013 at 2:00 PM, Shawn Landden <shawnlandden@gmail.com> wrote:
> heres a version of the test case that builds.....
>
> Sorry about that.
>
> On Sun, Nov 24, 2013 at 9:21 AM, Shawn Landden <shawnlandden@gmail.com> wrote:
>> If I use sendfile() to send to a accept()ed AF_ALG socket set up for
>> "hash", I get the wrong
>> answer, if I read() and then write() I get the right answer. None of
>> the system calls return an error.
>>
>> test case attached.
>>
>> --
>>
>> ---
>> Shawn Landden
>> +1 360 389 3001 (SMS preferred)
>
>
>
> --
>
> ---
> Shawn Landden
> +1 360 389 3001 (SMS preferred)
--
---
Shawn Landden
+1 360 389 3001 (SMS preferred)
^ permalink raw reply
* request to queue "5d0f801 can: c_can: Fix RX message handling, handle lost message before EOB" for stable
From: Marc Kleine-Budde @ 2013-11-24 22:15 UTC (permalink / raw)
To: Linux Netdev List
Cc: linux-can@vger.kernel.org, David Miller, kernel@pengutronix.de,
Holger.Bechtold
[-- Attachment #1: Type: text/plain, Size: 842 bytes --]
Hello David,
usually all relevant patches find their way (from my point of view,
magically :) to the stable trees, however in my last pull request to
net/master, which was merged in
e9b51a1 Merge branch 'fixes-for-3.12' of
git://gitorious.org/linux-can/linux-can
there were two patches, both had stable on Cc. So far one has been added
to the stable queue, the other:
5d0f801 can: c_can: Fix RX message handling, handle lost message
before EOB
is missing. Can you please queue, if not happened so far, that patch, too?
cheers,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: request to queue "5d0f801 can: c_can: Fix RX message handling, handle lost message before EOB" for stable
From: Marc Kleine-Budde @ 2013-11-24 22:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-can, kernel, Holger Bechtold
In-Reply-To: <20131124.144800.211193209202819326.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 732 bytes --]
On 11/24/2013 11:48 PM, David Miller wrote:
> From: Marc Kleine-Budde <mkl@pengutronix.de>
> Date: Sun, 24 Nov 2013 23:15:51 +0100
>
>> 5d0f801 can: c_can: Fix RX message handling, handle lost message
>> before EOB
>>
>> is missing. Can you please queue, if not happened so far, that patch, too?
>
> I'm busy travelling, so can you help me out by submitting it
> yourself?
Sure, just a mail to stable@vger.kernel.org (and Greg)?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: request to queue "5d0f801 can: c_can: Fix RX message handling, handle lost message before EOB" for stable
From: David Miller @ 2013-11-24 22:48 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel, Holger.Bechtold
In-Reply-To: <52927A97.2060601@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Sun, 24 Nov 2013 23:15:51 +0100
> 5d0f801 can: c_can: Fix RX message handling, handle lost message
> before EOB
>
> is missing. Can you please queue, if not happened so far, that patch, too?
I'm busy travelling, so can you help me out by submitting it
yourself?
Thanks.
^ permalink raw reply
* request to queue "5d0f801 can: c_can: Fix RX message handling, handle lost message before EOB" for stable
From: Marc Kleine-Budde @ 2013-11-24 22:58 UTC (permalink / raw)
To: stable
Cc: linux-can@vger.kernel.org, Greg KH, kernel@pengutronix.de,
Holger.Bechtold, Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 687 bytes --]
Hello Greg,
can you please queue
5d0f801 can: c_can: Fix RX message handling, handle lost message before EOB
for the stable trees.
This patch was part of a two-patches pull request to David's net/master
tree, which was merged in:
e9b51a1 Merge branch 'fixes-for-3.12' of git://gitorious.org/linux-can/linux-can
One patch has already been queued, the other not.
Thanks,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: request to queue "5d0f801 can: c_can: Fix RX message handling, handle lost message before EOB" for stable
From: David Miller @ 2013-11-24 23:00 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel, Holger.Bechtold
In-Reply-To: <5292809E.1080103@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Sun, 24 Nov 2013 23:41:34 +0100
> On 11/24/2013 11:48 PM, David Miller wrote:
>> From: Marc Kleine-Budde <mkl@pengutronix.de>
>> Date: Sun, 24 Nov 2013 23:15:51 +0100
>>
>>> 5d0f801 can: c_can: Fix RX message handling, handle lost message
>>> before EOB
>>>
>>> is missing. Can you please queue, if not happened so far, that patch, too?
>>
>> I'm busy travelling, so can you help me out by submitting it
>> yourself?
>
> Sure, just a mail to stable@vger.kernel.org (and Greg)?
Yes.
^ permalink raw reply
* [PATCH] pipe_to_sendpage: Ensure that MSG_MORE is set if we set MSG_SENDPAGE_NOTLAST
From: Richard Weinberger @ 2013-11-24 23:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-fsdevel, viro, shawnlandden, linux-crypto, netdev, herbert,
Richard Weinberger, Tom Herbert, Eric Dumazet, David S. Miller,
stable
In-Reply-To: <CAJusiZXN4dOxg9S4ZiCziVXfNZ+=yu7a=84vUikV2RhbhYU7QA@mail.gmail.com>
Commit 35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once)
added an internal flag MSG_SENDPAGE_NOTLAST.
We have to ensure that MSG_MORE is also set if we set MSG_SENDPAGE_NOTLAST.
Otherwise users that check against MSG_MORE will not see it.
This fixes sendfile() on AF_ALG.
Cc: Tom Herbert <therbert@google.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: <stable@vger.kernel.org> # 3.4.x
Reported-and-tested-by: Shawn Landden <shawnlandden@gmail.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
---
fs/splice.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/splice.c b/fs/splice.c
index 3b7ee65..b93f1b8 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -701,7 +701,7 @@ static int pipe_to_sendpage(struct pipe_inode_info *pipe,
more = (sd->flags & SPLICE_F_MORE) ? MSG_MORE : 0;
if (sd->len < sd->total_len && pipe->nrbufs > 1)
- more |= MSG_SENDPAGE_NOTLAST;
+ more |= MSG_SENDPAGE_NOTLAST | MSG_MORE;
return file->f_op->sendpage(file, buf->page, buf->offset,
sd->len, &pos, more);
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH] pipe_to_sendpage: Ensure that MSG_MORE is set if we set MSG_SENDPAGE_NOTLAST
From: Shawn Landden @ 2013-11-25 0:03 UTC (permalink / raw)
To: Richard Weinberger
Cc: Linux Kernel Mailing List, linux-fsdevel, viro, linux-crypto,
netdev, Herbert Xu, Tom Herbert, Eric Dumazet, David S. Miller,
stable
In-Reply-To: <1385336527-27304-1-git-send-email-richard@nod.at>
On Sun, Nov 24, 2013 at 3:42 PM, Richard Weinberger <richard@nod.at> wrote:
> Commit 35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once)
> added an internal flag MSG_SENDPAGE_NOTLAST.
> We have to ensure that MSG_MORE is also set if we set MSG_SENDPAGE_NOTLAST.
> Otherwise users that check against MSG_MORE will not see it.
>
> This fixes sendfile() on AF_ALG.
>
> Cc: Tom Herbert <therbert@google.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: <stable@vger.kernel.org> # 3.4.x
The offending commit also got backported to the 3.2 stable kernel, so
we need this fix there as well.
---
Shawn Landden
+1 360 389 3001 (SMS preferred)
^ permalink raw reply
* Re: [PATCH] pipe_to_sendpage: Ensure that MSG_MORE is set if we set MSG_SENDPAGE_NOTLAST
From: Eric Dumazet @ 2013-11-25 1:25 UTC (permalink / raw)
To: Richard Weinberger
Cc: linux-kernel, linux-fsdevel, viro, shawnlandden, linux-crypto,
netdev, herbert, Tom Herbert, David S. Miller, stable
In-Reply-To: <1385336527-27304-1-git-send-email-richard@nod.at>
On Mon, 2013-11-25 at 00:42 +0100, Richard Weinberger wrote:
> Commit 35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once)
> added an internal flag MSG_SENDPAGE_NOTLAST.
> We have to ensure that MSG_MORE is also set if we set MSG_SENDPAGE_NOTLAST.
> Otherwise users that check against MSG_MORE will not see it.
>
> This fixes sendfile() on AF_ALG.
>
> Cc: Tom Herbert <therbert@google.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: <stable@vger.kernel.org> # 3.4.x
> Reported-and-tested-by: Shawn Landden <shawnlandden@gmail.com>
> Signed-off-by: Richard Weinberger <richard@nod.at>
> ---
> fs/splice.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/splice.c b/fs/splice.c
> index 3b7ee65..b93f1b8 100644
> --- a/fs/splice.c
> +++ b/fs/splice.c
> @@ -701,7 +701,7 @@ static int pipe_to_sendpage(struct pipe_inode_info *pipe,
> more = (sd->flags & SPLICE_F_MORE) ? MSG_MORE : 0;
>
> if (sd->len < sd->total_len && pipe->nrbufs > 1)
> - more |= MSG_SENDPAGE_NOTLAST;
> + more |= MSG_SENDPAGE_NOTLAST | MSG_MORE;
>
> return file->f_op->sendpage(file, buf->page, buf->offset,
> sd->len, &pos, more);
I do not think this patch is right. It looks like a revert of a useful
patch for TCP zero copy. Given the time it took to discover this
regression, I bet tcp zero copy has more users than AF_ALG, by 5 or 6
order of magnitude ;)
Here we want to make the difference between the two flags, not merge
them.
If AF_ALG do not care of the difference, try instead :
diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index ef5356cd280a..850246206b12 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -114,6 +114,9 @@ static ssize_t hash_sendpage(struct socket *sock, struct page *page,
struct hash_ctx *ctx = ask->private;
int err;
+ if (flags & MSG_SENDPAGE_NOTLAST)
+ flags |= MSG_MORE;
+
lock_sock(sk);
sg_init_table(ctx->sgl.sg, 1);
sg_set_page(ctx->sgl.sg, page, size, offset);
^ permalink raw reply related
* Re: [PATCH] sctp: Restore 'resent' bit to avoid retransmitted chunks for RTT measurements
From: Xufeng Zhang @ 2013-11-25 1:37 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: nhorman, davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <528F67A1.60306@gmail.com>
On 11/22/2013 10:18 PM, Vlad Yasevich wrote:
> On 11/22/2013 03:30 AM, Xufeng Zhang wrote:
>
>> From: Signed-off-by: Xufeng Zhang<xufeng.zhang@windriver.com>
>>
>> Currently retransmitted DATA chunks could also be used for
>> RTT measurements since there are no flag to identify whether
>> the transmitted DATA chunk is a new one or a retransmitted one.
>> This problem is introduced by commit ae19c5486 ("sctp: remove
>> 'resent' bit from the chunk") which inappropriately removed the
>> 'resent' bit completely, instead of doing this, we should set
>> the resent bit only for the retransmitted DATA chunks.
>>
>> Signed-off-by: Xufeng Zhang<xufeng.zhang@windriver.com>
>> ---
>> include/net/sctp/structs.h | 1 +
>> net/sctp/output.c | 23 +++++++++++++----------
>> net/sctp/outqueue.c | 3 +++
>> net/sctp/sm_make_chunk.c | 1 +
>> 4 files changed, 18 insertions(+), 10 deletions(-)
>>
>> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
>> index 2174d8d..ea0ca5f 100644
>> --- a/include/net/sctp/structs.h
>> +++ b/include/net/sctp/structs.h
>> @@ -629,6 +629,7 @@ struct sctp_chunk {
>> #define SCTP_NEED_FRTX 0x1
>> #define SCTP_DONT_FRTX 0x2
>> __u16 rtt_in_progress:1, /* This chunk used for RTT calc? */
>> + resent:1, /* Has this chunk ever been resent. */
>> has_tsn:1, /* Does this chunk have a TSN yet? */
>> has_ssn:1, /* Does this chunk have a SSN yet? */
>> singleton:1, /* Only chunk in the packet? */
>> diff --git a/net/sctp/output.c b/net/sctp/output.c
>> index e650978..32c214d 100644
>> --- a/net/sctp/output.c
>> +++ b/net/sctp/output.c
>> @@ -467,17 +467,20 @@ int sctp_packet_transmit(struct sctp_packet *packet)
>> list_for_each_entry_safe(chunk, tmp,&packet->chunk_list, list) {
>> list_del_init(&chunk->list);
>> if (sctp_chunk_is_data(chunk)) {
>> - /* 6.3.1 C4) When data is in flight and when allowed
>> - * by rule C5, a new RTT measurement MUST be made each
>> - * round trip. Furthermore, new RTT measurements
>> - * SHOULD be made no more than once per round-trip
>> - * for a given destination transport address.
>> - */
>> -
>> - if (!tp->rto_pending) {
>> - chunk->rtt_in_progress = 1;
>> - tp->rto_pending = 1;
>> + if (!chunk->resent) {
>> + /* 6.3.1 C4) When data is in flight and when allowed
>> + * by rule C5, a new RTT measurement MUST be made each
>> + * round trip. Furthermore, new RTT measurements
>> + * SHOULD be made no more than once per round-trip
>> + * for a given destination transport address.
>> + */
>> +
>> + if (!tp->rto_pending) {
>>
> Could be combined as
> if (!chunk->resent&& !tp->rto_pending) {
>
Got it!
>
>> + chunk->rtt_in_progress = 1;
>> + tp->rto_pending = 1;
>> + }
>> }
>> +
>> has_data = 1;
>> }
>>
>> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
>> index 94df758..70f4f56 100644
>> --- a/net/sctp/outqueue.c
>> +++ b/net/sctp/outqueue.c
>> @@ -446,6 +446,8 @@ void sctp_retransmit_mark(struct sctp_outq *q,
>> transport->rto_pending = 0;
>> }
>>
>> + chunk->resent = 1;
>> +
>> /* Move the chunk to the retransmit queue. The chunks
>> * on the retransmit queue are always kept in order.
>> */
>> @@ -1375,6 +1377,7 @@ static void sctp_check_transmitted(struct sctp_outq *q,
>> * instance).
>> */
>> if (!tchunk->tsn_gap_acked&&
>> + !tchunk->resent&&
>> tchunk->rtt_in_progress) {
>> tchunk->rtt_in_progress = 0;
>> rtt = jiffies - tchunk->sent_at;
>> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
>> index fe69032..8fe89f8 100644
>> --- a/net/sctp/sm_make_chunk.c
>> +++ b/net/sctp/sm_make_chunk.c
>> @@ -1321,6 +1321,7 @@ struct sctp_chunk *sctp_chunkify(struct sk_buff *skb,
>> INIT_LIST_HEAD(&retval->list);
>> retval->skb = skb;
>> retval->asoc = (struct sctp_association *)asoc;
>> + retval->resent = 0;
>>
> Not needed due to zeroed out malloc.
>
Thank you!
Will send V2 later.
Thanks,
Xufeng
> -vlad
>
>
>> retval->singleton = 1;
>>
>> retval->fast_retransmit = SCTP_CAN_FRTX;
>>
>>
>
>
^ 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