* Re: e1000e interface hang on 82574L
From: Chris Boot @ 2012-03-17 15:59 UTC (permalink / raw)
To: Wyborny, Carolyn; +Cc: netdev, lkml, e1000-devel@lists.sourceforge.net
In-Reply-To: <4F144A76.3050703@bootc.net>
On 16/01/2012 16:04, Chris Boot wrote:
> On 16/01/2012 15:56, Wyborny, Carolyn wrote:
>>
>>
>>> -----Original Message-----
>>> From: Chris Boot [mailto:bootc@bootc.net]
>>> Sent: Sunday, January 15, 2012 3:11 AM
>>> To: Wyborny, Carolyn
>>> Cc: netdev; lkml; e1000-devel@lists.sourceforge.net
>>> Subject: Re: e1000e interface hang on 82574L
>>>
>>> On 04/01/2012 17:12, Chris Boot wrote:
>>>> On 03/01/2012 00:02, Wyborny, Carolyn wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>>> owner@vger.kernel.org]
>>>>>> On Behalf Of Chris Boot
>>>>>> Sent: Saturday, December 31, 2011 1:32 AM
>>>>>> To: netdev; lkml; e1000-devel@lists.sourceforge.net
>>>>>> Subject: Re: e1000e interface hang on 82574L
>>>>>>
>>>>>> On 27 Dec 2011, at 22:01, Chris Boot wrote:
>>>>>>
>>>>>>> Hi folks,
>>>>>>>
>>>>>>> Another networking issue I've run into, this time with e1000e
>>> (Intel
>>>>>> Corporation 82574L Gigabit). My new VM cluster appears to drop a NIC
>>> -
>>>>>> the port stops responding within Linux and shows the link as being
>>> down
>>>>>> with ethtool. My ISP says 'Ports running Half Duplex or reduced
>>> speed'
>>>>>> on the port.
>>>>>>>
>>>>>>> When the port stops working I see this in dmesg:
>>>>>>>
>>>>>>> [35481.659629] ------------[ cut here ]------------
>>>>>>> [35481.667837] WARNING: at net/sched/sch_generic.c:255
>>>>>> dev_watchdog+0xe9/0x148()
>>>>>>> [35481.676370] Hardware name: X9SCL/X9SCM
>>>>>>> [35481.684793] NETDEV WATCHDOG: eth2 (e1000e): transmit queue 0
>>> timed
>>>>>> out
>>>>>>> [35481.684795] Modules linked in: hmac sha256_generic dlm configfs
>>>>>> ebtable_nat ebtables acpi_cpufreq mperf cpufreq_stats
>>>>>> cpufreq_conservative cpufreq_userspace cpufreq_powersave microcode
>>>>>> xt_NOTRACK ip_set_hash_net act_police cls_basic cls_flow cls_fw
>>> cls_u32
>>>>>> sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_connlimit
>>>>>> xt_realm xt_addrtype ip_set_hash_ip iptable_raw xt_comment xt_recent
>>>>>> ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN
>>>>>> ipt_ecn ipt_CLUSTERIP ipt_ah nf_nat_tftp nf_nat_snmp_basic
>>>>>> nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc
>>>>>> nf_nat_h323 nf_nat_ftp ip6_queue nf_nat_amanda xt_set ip_set
>>>>>> nf_conntrack_tftp nf_conntrack_sip nf_conntrack_sane
>>>>>> nf_conntrack_proto_udplite nf_conntrack_proto_sctp nf_conntrack_pptp
>>>>>> nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns
>>>>>> nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323
>>>>>> nf_conntrack_ftp ts_kmp nf_conntrack_amanda xt_TPROXY xt_NFLOG
>>>>>> nfnetlink_log nf_tproxy_core xt_time xt_TCPMSS xt_tcpmss xt_sctp
>>>>>> xt_policy xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_multiport
>>> xt_mark
>>>>>> xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP
>>>>>> xt_dscp xt_dccp xt_connmark xt_CLASSIFY xt_AUDIT ip6t_LOG
>>> ip6t_REJECT
>>>>>> nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack ip6table_raw ipt_LOG
>>>>>> xt_tcpudp ip6table_mangle xt_state iptable_nat nf_nat
>>> nf_conntrack_ipv4
>>>>>> nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink iptable_filter
>>>>>> ip_tables ip6table_filter ip6_tables x_tables bridge stp bonding
>>>>>> w83627ehf hwmon_vid coretemp sha1_ssse3 sha1_generic crc32c_intel
>>>>>> aesni_intel cryptd aes_x86_64 aes_generic ipmi_poweroff ipmi_devintf
>>>>>> ipmi_si ipmi_msghandler vhost_net macvtap macvlan tun drbd lru_cache
>>> cn
>>>>>> loop kvm_intel kvm snd_pcm snd_timer snd iTCO_wdt soundcore psmouse
>>>>>> snd_page_alloc i2c_i801 i2c_core cdc_acm iTCO_vendor_support joydev
>>>>>> evdev serio_raw processor button pcspkr thermal_sys ext4 mbcache
>>> jbd2
>>>>>> crc16 dm_mod raid1 md_mod sd_mod crc_t10dif usb_storage uas usbhid
>>> hid
>>>>>> ahci libahci libata igb ehci_hcd scsi_mod usbcore e1000e dca
>>> usb_common
>>>>>> [last unloaded: scsi_wait_scan]
>>>>>>> [35481.685740] Pid: 0, comm: swapper/4 Not tainted 3.2.0-rc6+ #4
>>>>>>> [35481.685744] Call Trace:
>>>>>>> [35481.685746]<IRQ> [<ffffffff810467ed>] ?
>>>>>> warn_slowpath_common+0x78/0x8c
>>>>>>> [35481.685849] [<ffffffff81046899>] ? warn_slowpath_fmt+0x45/0x4a
>>>>>>> [35481.685875] [<ffffffff810aeaa0>] ?
>>>>>> perf_event_task_tick+0x166/0x1ab
>>>>>>> [35481.686018] [<ffffffff81294219>] ? netif_tx_lock+0x40/0x72
>>>>>>> [35481.686090] [<ffffffff8129437a>] ? dev_watchdog+0xe9/0x148
>>>>>>> [35481.686136] [<ffffffff81051e58>] ? run_timer_softirq+0x19a/0x261
>>>>>>> [35481.686176] [<ffffffff81294291>] ? netif_tx_unlock+0x46/0x46
>>>>>>> [35481.686215] [<ffffffff810659bb>] ? timekeeping_get_ns+0xd/0x2a
>>>>>>> [35481.686286] [<ffffffff8104bdd4>] ? __do_softirq+0xb9/0x177
>>>>>>> [35481.686365] [<ffffffff81341d6c>] ? call_softirq+0x1c/0x30
>>>>>>> [35481.686530] [<ffffffff8100f841>] ? do_softirq+0x3c/0x7b
>>>>>>> [35481.686580] [<ffffffff8104c03c>] ? irq_exit+0x3c/0x9a
>>>>>>> [35481.686742] [<ffffffff81023e58>] ?
>>>>>> smp_apic_timer_interrupt+0x74/0x82
>>>>>>> [35481.686820] [<ffffffff813405de>] ?
>>> apic_timer_interrupt+0x6e/0x80
>>>>>>> [35481.686826]<EOI> [<ffffffff811ddf49>] ? intel_idle+0xea/0x119
>>>>>>> [35481.686991] [<ffffffff811ddf28>] ? intel_idle+0xc9/0x119
>>>>>>> [35481.687051] [<ffffffff8125dce3>] ? cpuidle_idle_call+0xec/0x179
>>>>>>> [35481.687089] [<ffffffff8100d255>] ? cpu_idle+0xa1/0xe8
>>>>>>> [35481.687143] [<ffffffff810706ee>] ?
>>> arch_local_irq_restore+0x2/0x8
>>>>>>> [35481.687189] [<ffffffff8132d191>] ? start_secondary+0x1d5/0x1db
>>>>>>> [35481.687234] ---[ end trace 01e9907674757948 ]---
>>>>>>> [35481.687817] e1000e 0000:05:00.0: eth2: Reset adapter
>>>>>>>
>>>>>>> To try to regain connectivity I bring down the bond and the
>>> interface
>>>>>> (eth2), then unload e1000e. Upon loading the module again:
>>>>>>>
>>>>>>> [36021.888962] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k
>>>>>>> [36021.900258] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
>>>>>>> [36021.911446] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level,
>>> low) -
>>>>>>> IRQ 20
>>>>>>> [36021.923204] e1000e 0000:00:19.0: setting latency timer to 64
>>>>>>> [36021.923372] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
>>>>>>> [36022.202737] e1000e 0000:00:19.0: eth2: (PCI
>>> Express:2.5GT/s:Width
>>>>>> x1) 00:25:90:56:ac:75
>>>>>>> [36022.214480] e1000e 0000:00:19.0: eth3: Intel(R) PRO/1000 Network
>>>>>> Connection
>>>>>>> [36022.227506] e1000e 0000:00:19.0: eth3: MAC: 10, PHY: 11, PBA No:
>>>>>> FFFFFF-0FF
>>>>>>> [36022.239789] e1000e 0000:05:00.0: Disabling ASPM L0s
>>>>>>> [36022.239805] e1000e 0000:05:00.0: enabling device (0000 -> 0002)
>>>>>>> [36022.239829] e1000e 0000:05:00.0: PCI INT A -> GSI 16 (level,
>>> low) -
>>>>>>> IRQ 16
>>>>>>> [36022.239921] e1000e 0000:05:00.0: setting latency timer to 64
>>>>>>> [36022.240963] e1000e 0000:05:00.0: irq 64 for MSI/MSI-X
>>>>>>> [36022.240995] e1000e 0000:05:00.0: irq 65 for MSI/MSI-X
>>>>>>> [36022.241028] e1000e 0000:05:00.0: irq 66 for MSI/MSI-X
>>>>>>> [36022.241596] e1000e 0000:05:00.0: PCI INT A disabled
>>>>>>> [36022.241606] e1000e: probe of 0000:05:00.0 failed with error -2
>>>>>>> [36022.304706] udevd[3634]: renamed network interface eth2 to eth3
>>>>>>>
>>>>>>> I then don't get an eth2 interface. Only a reboot brings the
>>> interface
>>>>>> back. This has happened twice so far on this server in the past
>>> week,
>>>>>> both times using v3.2-rc7-3-g4962516.
>>>>>>>
>>>>>>> lspci -vnn shows:
>>>>>>>
>>>>>>> 05:00.0 Ethernet controller [0200]: Intel Corporation 82574L
>>> Gigabit
>>>>>> Network Connection [8086:10d3]
>>>>>>> Subsystem: Super Micro Computer Inc Device [15d9:0000]
>>>>>>> Flags: bus master, fast devsel, latency 0, IRQ 16
>>>>>>> Memory at fbd00000 (32-bit, non-prefetchable) [size=128K]
>>>>>>> I/O ports at e000 [size=32]
>>>>>>> Memory at fbd20000 (32-bit, non-prefetchable) [size=16K]
>>>>>>> Capabilities: [c8] Power Management version 2
>>>>>>> Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
>>>>>>> Capabilities: [e0] Express Endpoint, MSI 00
>>>>>>> Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
>>>>>>> Capabilities: [100] Advanced Error Reporting
>>>>>>> Capabilities: [140] Device Serial Number 00-25-90-ff-ff-56-ac-
>>>>>> 74
>>>>>>> Kernel driver in use: e1000e
>>>>>>
>>>>>> I've just had this happen on my other (identical) server with a
>>> nearly
>>>>>> identical trace. Is there anything I can do do avoid this at all or
>>> at
>>>>>> least help narrow down the problem?
>>>>>>
>>>>>> Cheers,
>>>>>> Chris
>>>>>>
>>>>>> --
>>>>>> Chris Boot
>>>>>> bootc@bootc.net
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>
>>>>> Hello,
>>>>>
>>>>> Sorry for the delay in responding. We have seen some hang issues
>>> using
>>>>> MSI-X on 82574 parts. Can you try reloading the driver the IntMode
>>>>> module parameter. IntMode=1 (you'll need a setting for each device in
>>>>> the system so two adapters would be IntMode=1,1) See if that changes
>>>>> the symptom you are seeing with this part. That setting will make
>>> sure
>>>>> the adapter uses MSI interrupts instead of MSI-X.
>>>>
>>>> Carolyn,
>>>>
>>>> I'll give this a go next time I reproduce it. I built a new kernel
>>> with
>>>> more debugging and so far it hasn't yet triggered again...
>>>
>>> Upgrading to a more recent 3.2-rc snapshot seems to have cured the
>>> problem - I haven't had an interface stop responding since. Must have
>>> been some seemingly unrelated patch that I can't seem to locate.
>>>
>>> Cheers,
>>> Chris
>>>
>>> --
>>> Chris Boot
>>> bootc@bootc.net
>> Thanks for letting me know Chris. For my own edification, are you
>> still configured with MSI-X?
>
> Carolyn,
>
> I have made no changes to my configuration to change the interrupt
> format. I see the following in dmesg at boot:
>
> [ 3.276819] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k
> [ 3.288193] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
>
> [ 3.299842] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low)
> -> IRQ 20
> [ 3.299909] e1000e 0000:00:19.0: setting latency timer to 64
> [ 3.352929] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
> [ 3.710080] e1000e 0000:00:19.0: eth2: (PCI Express:2.5GT/s:Width
> x1) 00:25:90:56:ac:75
> [ 3.710082] e1000e 0000:00:19.0: eth2: Intel(R) PRO/1000 Network
> Connection
> [ 3.710670] e1000e 0000:00:19.0: eth2: MAC: 10, PHY: 11, PBA No:
> FFFFFF-0FF
>
> [ 3.710678] e1000e 0000:05:00.0: Disabling ASPM L0s
> [ 3.710850] e1000e 0000:05:00.0: PCI INT A -> GSI 16 (level, low)
> -> IRQ 16
> [ 3.710951] e1000e 0000:05:00.0: setting latency timer to 64
> [ 3.712757] e1000e 0000:05:00.0: irq 64 for MSI/MSI-X
> [ 3.712787] e1000e 0000:05:00.0: irq 65 for MSI/MSI-X
> [ 3.712805] e1000e 0000:05:00.0: irq 66 for MSI/MSI-X
> [ 3.830364] e1000e 0000:05:00.0: eth3: (PCI Express:2.5GT/s:Width
> x1) 00:25:90:56:ac:74
> [ 3.830366] e1000e 0000:05:00.0: eth3: Intel(R) PRO/1000 Network
> Connection
> [ 3.830510] e1000e 0000:05:00.0: eth3: MAC: 3, PHY: 8, PBA No:
> FFFFFF-0FF
>
> /proc/interrupts shows:
>
> 45: 615958 0 0 0 0 0
> 0 0 IR-PCI-MSI-edge eth3
> 64: 65126106 0 0 0 0 0
> 0 0 IR-PCI-MSI-edge eth2-rx-0
> 65: 52700392 0 0 0 0 0
> 0 0 IR-PCI-MSI-edge eth2-tx-0
> 66: 2 0 0 0 0 0
> 0 0 IR-PCI-MSI-edge eth2
Carolyn,
I've just had the opportunity to upgrade to a 3.2.9 kernel on these
systems and have made sure e1000e is loaded with IntMode=1,1. One of the
servers was only up 5.5 hours before the NIC has crashed/stopped working
again.
Here is the latest dmesg after the failure:
[ 3.254553] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k
[ 3.265852] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
[ 3.266034] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) ->
IRQ 20
[ 3.266067] e1000e 0000:00:19.0: setting latency timer to 64
[ 3.266460] e1000e 0000:00:19.0: (unregistered net_device): Interrupt
Mode set to 1
[ 3.266800] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
[ 3.611840] e1000e 0000:00:19.0: eth2: (PCI Express:2.5GT/s:Width x1)
00:25:90:56:ac:75
[ 3.611855] e1000e 0000:00:19.0: eth2: Intel(R) PRO/1000 Network
Connection
[ 3.612303] e1000e 0000:00:19.0: eth2: MAC: 10, PHY: 11, PBA No:
FFFFFF-0FF
[ 3.612350] e1000e 0000:05:00.0: Disabling ASPM L0s
[ 3.612594] e1000e 0000:05:00.0: PCI INT A -> GSI 16 (level, low) ->
IRQ 16
[ 3.612812] e1000e 0000:05:00.0: setting latency timer to 64
[ 3.613582] e1000e 0000:05:00.0: (unregistered net_device): Interrupt
Mode set to 1
[ 3.614156] e1000e 0000:05:00.0: irq 64 for MSI/MSI-X
[ 3.734442] e1000e 0000:05:00.0: eth3: (PCI Express:2.5GT/s:Width x1)
00:25:90:56:ac:74
[ 3.734465] e1000e 0000:05:00.0: eth3: Intel(R) PRO/1000 Network
Connection
[ 3.734689] e1000e 0000:05:00.0: eth3: MAC: 3, PHY: 8, PBA No: FFFFFF-0FF
[ 13.799848] e1000e 0000:05:00.0: irq 64 for MSI/MSI-X
[ 13.855646] e1000e 0000:05:00.0: irq 64 for MSI/MSI-X
[ 14.031739] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
[ 14.087566] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
[ 16.112504] e1000e: eth2 NIC Link is Up 100 Mbps Full Duplex, Flow
Control: None
[ 16.124129] e1000e 0000:05:00.0: eth2: 10/100 speed: disabling TSO
And here is the output just as it hangs:
[19745.327241] ------------[ cut here ]------------
[19745.334501] WARNING: at
/build/buildd-linux-2.6_3.2.9-1-amd64-KTPapN/linux-2.6-3.2.9/debian/build/source_amd64_none/net/sched/sch_generic.c:255
dev_watchdog+0xe9/0x148()
[19745.350441] Hardware name: X9SCL/X9SCM
[19745.358859] NETDEV WATCHDOG: eth2 (e1000e): transmit queue 0 timed out
[19745.367287] Modules linked in: hmac sha256_generic dlm configfs
ebtable_nat ebtables acpi_cpufreq mperf cpufreq_stats
cpufreq_conservative cpufreq_userspace cpufreq_powersave microcode
ip6_queue xt_TCPMSS xt_sctp ip6t_LOG ip6t_REJECT nf_conntrack_ipv6
ip6table_raw ip6table_mangle ip6table_filter xt_NOTRACK ip_set_hash_net
act_police cls_basic cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_htb
sch_hfsc sch_ingress sch_sfq xt_statistic xt_CT xt_time xt_connlimit
xt_realm xt_addrtype ip_set_hash_ip iptable_raw xt_comment xt_recent
xt_policy ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE
ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah xt_set ip_set nf_nat_tftp
nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp
nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp
nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip
nf_conntrack_proto_udplite nf_conntrack_proto_sctp nf_conntrack_pptp
nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns
nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323
nf_conntrack_ftp xt_TPROXY nf_tproxy_core ip6_tables nf_defrag_ipv6
xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG
nfnetlink_log xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange
xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_conntrack xt_connmark
xt_CLASSIFY xt_AUDIT ipt_LOG xt_tcpudp xt_state iptable_nat nf_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink
iptable_filter ip_tables x_tables kvm_intel kvm bridge stp bonding
w83627ehf hwmon_vid coretemp sha1_ssse3 sha1_generic crc32c_intel
aesni_intel cryptd aes_x86_64 aes_generic ipmi_poweroff ipmi_devintf
ipmi_si ipmi_msghandler vhost_net macvtap macvlan tun drbd lru_cache cn
loop snd_pcm snd_timer snd soundcore snd_page_alloc iTCO_wdt i2c_i801
psmouse cdc_acm processor i2c_core iTCO_vendor_support serio_raw pcspkr
thermal_sys button evdev joydev ext4 mbcache jbd2 crc16 dm_mod raid1
md_mod sd_mod crc_t10dif usb_storage uas usbhid hid ahci libahci libata
ehci_hcd usbcore igb scsi_mod e1000e usb_common dca [last unloaded:
scsi_wait_scan]
[19745.502559] Pid: 0, comm: swapper/0 Not tainted 3.2.0-2-amd64 #1
[19745.502561] Call Trace:
[19745.502562] <IRQ> [<ffffffff81046879>] ? warn_slowpath_common+0x78/0x8c
[19745.502570] [<ffffffff81046925>] ? warn_slowpath_fmt+0x45/0x4a
[19745.502574] [<ffffffff8129aa11>] ? netif_tx_lock+0x40/0x72
[19745.502588] [<ffffffff8129ab72>] ? dev_watchdog+0xe9/0x148
[19745.502601] [<ffffffff81051f38>] ? run_timer_softirq+0x19a/0x261
[19745.502603] [<ffffffff8129aa89>] ? netif_tx_unlock+0x46/0x46
[19745.502606] [<ffffffff81065a73>] ? timekeeping_get_ns+0xd/0x2a
[19745.502609] [<ffffffff8104be98>] ? __do_softirq+0xb9/0x177
[19745.502612] [<ffffffff8134892c>] ? call_softirq+0x1c/0x30
[19745.502615] [<ffffffff8100f8e5>] ? do_softirq+0x3c/0x7b
[19745.502617] [<ffffffff8104c100>] ? irq_exit+0x3c/0x9a
[19745.502621] [<ffffffff81023f18>] ? smp_apic_timer_interrupt+0x74/0x82
[19745.502624] [<ffffffff8134719e>] ? apic_timer_interrupt+0x6e/0x80
[19745.502625] <EOI> [<ffffffff81070761>] ? arch_local_irq_save+0x11/0x17
[19745.502631] [<ffffffff811e45d9>] ? intel_idle+0xea/0x119
[19745.502633] [<ffffffff811e45b8>] ? intel_idle+0xc9/0x119
[19745.502637] [<ffffffff812643f7>] ? cpuidle_idle_call+0xec/0x179
[19745.502639] [<ffffffff8100d248>] ? cpu_idle+0xa5/0xf2
[19745.502641] [<ffffffff816aab3d>] ? start_kernel+0x3bd/0x3c8
[19745.502643] [<ffffffff816aa140>] ? early_idt_handlers+0x140/0x140
[19745.502645] [<ffffffff816aa3c4>] ? x86_64_start_kernel+0x104/0x111
[19745.502646] ---[ end trace 10e791a6f31603fa ]---
[19745.503125] e1000e 0000:05:00.0: eth2: Reset adapter
Once again, rmmod e1000e followed by modprobe e1000e does not fix the
problem:
[20508.158919] e1000e 0000:05:00.0: PCI INT A disabled
[20508.194927] e1000e 0000:00:19.0: PCI INT A disabled
[20511.119765] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k
[20511.130711] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
[20511.141206] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) ->
IRQ 20
[20511.151797] e1000e 0000:00:19.0: setting latency timer to 64
[20511.151921] e1000e 0000:00:19.0: (unregistered net_device): Interrupt
Mode set to 1
[20511.162853] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
[20511.528436] e1000e 0000:00:19.0: eth2: (PCI Express:2.5GT/s:Width x1)
00:25:90:56:ac:75
[20511.539261] e1000e 0000:00:19.0: eth3: Intel(R) PRO/1000 Network
Connection
[20511.550066] e1000e 0000:00:19.0: eth3: MAC: 10, PHY: 11, PBA No:
FFFFFF-0FF
[20511.561027] e1000e 0000:05:00.0: Disabling ASPM L0s
[20511.571883] e1000e 0000:05:00.0: enabling device (0000 -> 0002)
[20511.575224] udevd[5449]: renamed network interface eth2 to eth3
[20511.594234] e1000e 0000:05:00.0: PCI INT A -> GSI 16 (level, low) ->
IRQ 16
[20511.605703] e1000e 0000:05:00.0: setting latency timer to 64
[20511.605871] e1000e 0000:05:00.0: (unregistered net_device): Interrupt
Mode set to 1
[20511.617706] e1000e 0000:05:00.0: irq 64 for MSI/MSI-X
[20511.617828] e1000e 0000:05:00.0: PCI INT A disabled
[20511.629565] e1000e: probe of 0000:05:00.0 failed with error -2
Please let me know if/how I can debug this further.
Many thanks,
Chris
--
Chris Boot
bootc@bootc.net.
^ permalink raw reply
* [PATCH] wl12xx: fix DMA-API-related warnings
From: Mircea Gherzan @ 2012-03-17 16:26 UTC (permalink / raw)
To: Luciano Coelho
Cc: Mircea Gherzan, John W. Linville, linux-wireless, netdev,
linux-kernel
On the PandaBoard (omap_hsmmc + wl12xx_sdio) with DMA_API_DEBUG:
WARNING: at lib/dma-debug.c:930 check_for_stack.part.8+0x7c/0xe0()
omap_hsmmc omap_hsmmc.4: DMA-API: device driver maps memory fromstack
Signed-off-by: Mircea Gherzan <mgherzan@gmail.com>
---
drivers/net/wireless/wl12xx/boot.c | 14 +++++++++++---
drivers/net/wireless/wl12xx/cmd.c | 25 ++++++++++++++++---------
drivers/net/wireless/wl12xx/event.c | 18 +++++++++++-------
3 files changed, 38 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/boot.c b/drivers/net/wireless/wl12xx/boot.c
index 8f9cf5a..89c78d1 100644
--- a/drivers/net/wireless/wl12xx/boot.c
+++ b/drivers/net/wireless/wl12xx/boot.c
@@ -142,14 +142,22 @@ static void wl1271_parse_fw_ver(struct wl1271 *wl)
static void wl1271_boot_fw_version(struct wl1271 *wl)
{
- struct wl1271_static_data static_data;
+ struct wl1271_static_data *static_data;
- wl1271_read(wl, wl->cmd_box_addr, &static_data, sizeof(static_data),
+ static_data = kmalloc(sizeof(*static_data), GFP_DMA);
+ if (!static_data) {
+ __WARN();
+ return;
+ }
+
+ wl1271_read(wl, wl->cmd_box_addr, static_data, sizeof(*static_data),
false);
- strncpy(wl->chip.fw_ver_str, static_data.fw_version,
+ strncpy(wl->chip.fw_ver_str, static_data->fw_version,
sizeof(wl->chip.fw_ver_str));
+ kfree(static_data);
+
/* make sure the string is NULL-terminated */
wl->chip.fw_ver_str[sizeof(wl->chip.fw_ver_str) - 1] = '\0';
diff --git a/drivers/net/wireless/wl12xx/cmd.c b/drivers/net/wireless/wl12xx/cmd.c
index 25990bd..a5c8800 100644
--- a/drivers/net/wireless/wl12xx/cmd.c
+++ b/drivers/net/wireless/wl12xx/cmd.c
@@ -342,8 +342,12 @@ int wl1271_cmd_ext_radio_parms(struct wl1271 *wl)
*/
static int wl1271_cmd_wait_for_event_or_timeout(struct wl1271 *wl, u32 mask)
{
- u32 events_vector, event;
+ u32 *events_vector;
+ u32 event;
unsigned long timeout;
+ int ret = 0;
+
+ events_vector = kmalloc(sizeof(*events_vector), GFP_DMA);
timeout = jiffies + msecs_to_jiffies(WL1271_EVENT_TIMEOUT);
@@ -351,21 +355,24 @@ static int wl1271_cmd_wait_for_event_or_timeout(struct wl1271 *wl, u32 mask)
if (time_after(jiffies, timeout)) {
wl1271_debug(DEBUG_CMD, "timeout waiting for event %d",
(int)mask);
- return -ETIMEDOUT;
+ ret = -ETIMEDOUT;
+ goto out;
}
msleep(1);
/* read from both event fields */
- wl1271_read(wl, wl->mbox_ptr[0], &events_vector,
- sizeof(events_vector), false);
- event = events_vector & mask;
- wl1271_read(wl, wl->mbox_ptr[1], &events_vector,
- sizeof(events_vector), false);
- event |= events_vector & mask;
+ wl1271_read(wl, wl->mbox_ptr[0], events_vector,
+ sizeof(*events_vector), false);
+ event = *events_vector & mask;
+ wl1271_read(wl, wl->mbox_ptr[1], events_vector,
+ sizeof(*events_vector), false);
+ event |= *events_vector & mask;
} while (!event);
- return 0;
+out:
+ kfree(events_vector);
+ return ret;
}
static int wl1271_cmd_wait_for_event(struct wl1271 *wl, u32 mask)
diff --git a/drivers/net/wireless/wl12xx/event.c b/drivers/net/wireless/wl12xx/event.c
index d3280df68..bcd0c93 100644
--- a/drivers/net/wireless/wl12xx/event.c
+++ b/drivers/net/wireless/wl12xx/event.c
@@ -439,25 +439,29 @@ void wl1271_event_mbox_config(struct wl1271 *wl)
int wl1271_event_handle(struct wl1271 *wl, u8 mbox_num)
{
- struct event_mailbox mbox;
- int ret;
+ struct event_mailbox *mbox;
+ int ret = 0;
wl1271_debug(DEBUG_EVENT, "EVENT on mbox %d", mbox_num);
if (mbox_num > 1)
return -EINVAL;
+ /* no GFP_ATOMIC: we're called from the threaded IRQ handler */
+ mbox = kmalloc(sizeof(*mbox), GFP_DMA);
+
/* first we read the mbox descriptor */
- wl1271_read(wl, wl->mbox_ptr[mbox_num], &mbox,
- sizeof(struct event_mailbox), false);
+ wl1271_read(wl, wl->mbox_ptr[mbox_num], mbox, sizeof(*mbox), false);
/* process the descriptor */
- ret = wl1271_event_process(wl, &mbox);
+ ret = wl1271_event_process(wl, mbox);
if (ret < 0)
- return ret;
+ goto out;
/* then we let the firmware know it can go on...*/
wl1271_write32(wl, ACX_REG_INTERRUPT_TRIG, INTR_TRIG_EVENT_ACK);
- return 0;
+out:
+ kfree(mbox);
+ return ret;
}
--
1.7.9.1
^ permalink raw reply related
* Re: [PATCH net-next v3] ipv6: Allocate unique metrics for icmp6 packets to prevent tainting dst metrics
From: Eric Dumazet @ 2012-03-17 16:36 UTC (permalink / raw)
To: Nick Jones; +Cc: David Miller, netdev
In-Reply-To: <4F64B203.40307@network-box.com>
On Sat, 2012-03-17 at 23:47 +0800, Nick Jones wrote:
> The generation of an icmp6 packet, targeted to a specific desination
> address, will cause the shared metrics of the ip6_dst and inetpeer
> of that address to be tainted with the hoplimit value 255.
> All packets, icmp6 or otherwise, will have this hoplimit value, and
> if the destination is a router, not even advertisements specifying a
> new hoplimit value will have any effect due to the way
> ip6_dst_hoplimit works.
>
> By allocating a unique metrics array for the icmp6 packet, the shared
> metrics will not be tainted. A ip6_dst flag is added to indicate that
> the metrics for the dst don't belong to the peer, thus are not unique
> and should be freed when the dst is freed.
>
> Signed-off-by: Nick Jones <nick.jones@network-box.com>
> ---
> + }
> + dst_init_metrics(&rt->dst, metrics, 0);
Dont be fooled by 8e2ec639 precedent, third argument is a bool, so
please use 'false' instead of 0
^ permalink raw reply
* Re: [PATCH] wl12xx: fix DMA-API-related warnings
From: Arnd Bergmann @ 2012-03-17 16:44 UTC (permalink / raw)
To: Mircea Gherzan
Cc: Luciano Coelho, John W. Linville,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1332001592-17074-1-git-send-email-mgherzan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Saturday 17 March 2012, Mircea Gherzan wrote:
> int wl1271_event_handle(struct wl1271 *wl, u8 mbox_num)
> {
> - struct event_mailbox mbox;
> - int ret;
> + struct event_mailbox *mbox;
> + int ret = 0;
>
> wl1271_debug(DEBUG_EVENT, "EVENT on mbox %d", mbox_num);
>
> if (mbox_num > 1)
> return -EINVAL;
>
> + /* no GFP_ATOMIC: we're called from the threaded IRQ handler */
> + mbox = kmalloc(sizeof(*mbox), GFP_DMA);
> +
> /* first we read the mbox descriptor */
> - wl1271_read(wl, wl->mbox_ptr[mbox_num], &mbox,
> - sizeof(struct event_mailbox), false);
> + wl1271_read(wl, wl->mbox_ptr[mbox_num], mbox, sizeof(*mbox), false);
>
> /* process the descriptor */
> - ret = wl1271_event_process(wl, &mbox);
> + ret = wl1271_event_process(wl, mbox);
> if (ret < 0)
> - return ret;
> + goto out;
>
> /* then we let the firmware know it can go on...*/
> wl1271_write32(wl, ACX_REG_INTERRUPT_TRIG, INTR_TRIG_EVENT_ACK);
>
> - return 0;
> +out:
> + kfree(mbox);
> + return ret;
> }
I think it would be better here to put another field into struct wl1271 to hold
the mailbox. There is no point allocating and freeing the field every time
you get into the interrupt handler.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] wl12xx: fix DMA-API-related warnings
From: Mircea Gherzan @ 2012-03-17 17:41 UTC (permalink / raw)
To: Luciano Coelho
Cc: Mircea Gherzan, John W. Linville, linux-wireless, netdev,
linux-kernel
On the PandaBoard (omap_hsmmc + wl12xx_sdio) with DMA_API_DEBUG:
WARNING: at lib/dma-debug.c:930 check_for_stack.part.8+0x7c/0xe0()
omap_hsmmc omap_hsmmc.4: DMA-API: device driver maps memory fromstack
Signed-off-by: Mircea Gherzan <mgherzan@gmail.com>
---
drivers/net/wireless/wl12xx/boot.c | 14 +++++++++++---
drivers/net/wireless/wl12xx/cmd.c | 25 ++++++++++++++++---------
drivers/net/wireless/wl12xx/event.c | 10 +++++-----
drivers/net/wireless/wl12xx/event.h | 2 ++
drivers/net/wireless/wl12xx/main.c | 9 +++++++++
drivers/net/wireless/wl12xx/wl12xx.h | 3 +++
6 files changed, 46 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/boot.c b/drivers/net/wireless/wl12xx/boot.c
index 8f9cf5a..89c78d1 100644
--- a/drivers/net/wireless/wl12xx/boot.c
+++ b/drivers/net/wireless/wl12xx/boot.c
@@ -142,14 +142,22 @@ static void wl1271_parse_fw_ver(struct wl1271 *wl)
static void wl1271_boot_fw_version(struct wl1271 *wl)
{
- struct wl1271_static_data static_data;
+ struct wl1271_static_data *static_data;
- wl1271_read(wl, wl->cmd_box_addr, &static_data, sizeof(static_data),
+ static_data = kmalloc(sizeof(*static_data), GFP_DMA);
+ if (!static_data) {
+ __WARN();
+ return;
+ }
+
+ wl1271_read(wl, wl->cmd_box_addr, static_data, sizeof(*static_data),
false);
- strncpy(wl->chip.fw_ver_str, static_data.fw_version,
+ strncpy(wl->chip.fw_ver_str, static_data->fw_version,
sizeof(wl->chip.fw_ver_str));
+ kfree(static_data);
+
/* make sure the string is NULL-terminated */
wl->chip.fw_ver_str[sizeof(wl->chip.fw_ver_str) - 1] = '\0';
diff --git a/drivers/net/wireless/wl12xx/cmd.c b/drivers/net/wireless/wl12xx/cmd.c
index 25990bd..a5c8800 100644
--- a/drivers/net/wireless/wl12xx/cmd.c
+++ b/drivers/net/wireless/wl12xx/cmd.c
@@ -342,8 +342,12 @@ int wl1271_cmd_ext_radio_parms(struct wl1271 *wl)
*/
static int wl1271_cmd_wait_for_event_or_timeout(struct wl1271 *wl, u32 mask)
{
- u32 events_vector, event;
+ u32 *events_vector;
+ u32 event;
unsigned long timeout;
+ int ret = 0;
+
+ events_vector = kmalloc(sizeof(*events_vector), GFP_DMA);
timeout = jiffies + msecs_to_jiffies(WL1271_EVENT_TIMEOUT);
@@ -351,21 +355,24 @@ static int wl1271_cmd_wait_for_event_or_timeout(struct wl1271 *wl, u32 mask)
if (time_after(jiffies, timeout)) {
wl1271_debug(DEBUG_CMD, "timeout waiting for event %d",
(int)mask);
- return -ETIMEDOUT;
+ ret = -ETIMEDOUT;
+ goto out;
}
msleep(1);
/* read from both event fields */
- wl1271_read(wl, wl->mbox_ptr[0], &events_vector,
- sizeof(events_vector), false);
- event = events_vector & mask;
- wl1271_read(wl, wl->mbox_ptr[1], &events_vector,
- sizeof(events_vector), false);
- event |= events_vector & mask;
+ wl1271_read(wl, wl->mbox_ptr[0], events_vector,
+ sizeof(*events_vector), false);
+ event = *events_vector & mask;
+ wl1271_read(wl, wl->mbox_ptr[1], events_vector,
+ sizeof(*events_vector), false);
+ event |= *events_vector & mask;
} while (!event);
- return 0;
+out:
+ kfree(events_vector);
+ return ret;
}
static int wl1271_cmd_wait_for_event(struct wl1271 *wl, u32 mask)
diff --git a/drivers/net/wireless/wl12xx/event.c b/drivers/net/wireless/wl12xx/event.c
index d3280df68..10007f5 100644
--- a/drivers/net/wireless/wl12xx/event.c
+++ b/drivers/net/wireless/wl12xx/event.c
@@ -233,8 +233,9 @@ static void wl1271_event_mbox_dump(struct event_mailbox *mbox)
wl1271_debug(DEBUG_EVENT, "\tmask: 0x%x", mbox->events_mask);
}
-static int wl1271_event_process(struct wl1271 *wl, struct event_mailbox *mbox)
+static int wl1271_event_process(struct wl1271 *wl)
{
+ struct event_mailbox *mbox = wl->mbox;
struct ieee80211_vif *vif;
struct wl12xx_vif *wlvif;
int ret;
@@ -439,7 +440,6 @@ void wl1271_event_mbox_config(struct wl1271 *wl)
int wl1271_event_handle(struct wl1271 *wl, u8 mbox_num)
{
- struct event_mailbox mbox;
int ret;
wl1271_debug(DEBUG_EVENT, "EVENT on mbox %d", mbox_num);
@@ -448,11 +448,11 @@ int wl1271_event_handle(struct wl1271 *wl, u8 mbox_num)
return -EINVAL;
/* first we read the mbox descriptor */
- wl1271_read(wl, wl->mbox_ptr[mbox_num], &mbox,
- sizeof(struct event_mailbox), false);
+ wl1271_read(wl, wl->mbox_ptr[mbox_num], wl->mbox,
+ sizeof(*wl->mbox), false);
/* process the descriptor */
- ret = wl1271_event_process(wl, &mbox);
+ ret = wl1271_event_process(wl);
if (ret < 0)
return ret;
diff --git a/drivers/net/wireless/wl12xx/event.h b/drivers/net/wireless/wl12xx/event.h
index 1d878ba..7a6b18b 100644
--- a/drivers/net/wireless/wl12xx/event.h
+++ b/drivers/net/wireless/wl12xx/event.h
@@ -127,6 +127,8 @@ struct event_mailbox {
u8 reserved_7[12];
} __packed;
+struct wl1271;
+
int wl1271_event_unmask(struct wl1271 *wl);
void wl1271_event_mbox_config(struct wl1271 *wl);
int wl1271_event_handle(struct wl1271 *wl, u8 mbox);
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index d5f55a1..f63fde4 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -5071,8 +5071,17 @@ static struct ieee80211_hw *wl1271_alloc_hw(void)
goto err_dummy_packet;
}
+ wl->mbox = kmalloc(sizeof(*wl->mbox), GFP_DMA);
+ if (!wl->mbox) {
+ ret = -ENOMEM;
+ goto err_fwlog;
+ }
+
return hw;
+err_fwlog:
+ free_page((unsigned long)wl->fwlog);
+
err_dummy_packet:
dev_kfree_skb(wl->dummy_packet);
diff --git a/drivers/net/wireless/wl12xx/wl12xx.h b/drivers/net/wireless/wl12xx/wl12xx.h
index b2b09cd..0d02c7a 100644
--- a/drivers/net/wireless/wl12xx/wl12xx.h
+++ b/drivers/net/wireless/wl12xx/wl12xx.h
@@ -34,6 +34,7 @@
#include "conf.h"
#include "ini.h"
+#include "event.h"
#define WL127X_FW_NAME "ti-connectivity/wl127x-fw-3.bin"
#define WL128X_FW_NAME "ti-connectivity/wl128x-fw-3.bin"
@@ -394,6 +395,8 @@ struct wl1271 {
/* Hardware recovery work */
struct work_struct recovery_work;
+ struct event_mailbox *mbox;
+
/* The mbox event mask */
u32 event_mask;
--
1.7.9.1
^ permalink raw reply related
* [PATCH net-next v4] ipv6: Allocate unique metrics for icmp6 packets to prevent tainting dst metrics
From: Nick Jones @ 2012-03-17 17:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1332002201.19406.25.camel@edumazet-glaptop>
The generation of an icmp6 packet, targeted to a specific desination
address, will cause the shared metrics of the ip6_dst and inetpeer
of that address to be tainted with the hoplimit value 255.
All packets, icmp6 or otherwise, will have this hoplimit value, and
if the destination is a router, not even advertisements specifying a
new hoplimit value will have any effect due to the way
ip6_dst_hoplimit works.
By allocating a unique metrics array for the icmp6 packet, the shared
metrics will not be tainted. A ip6_dst flag is added to indicate that
the metrics for the dst don't belong to the peer, thus are not unique
and should be freed when the dst is freed.
Signed-off-by: Nick Jones <nick.jones@network-box.com>
---
v2: Forgot to handle destroy side, as pointed out by David Miller.
Achieved by setting a flag on the dst to indicate its metrics are
unique, thus should be destroyed along with the dst.
v3: David Miller reminds that metrics pointer should be declared at
function top.
v4: Eric Dumazet suggest argument of dst_init_metrics change to from
literal 0 to keyword 'false'.
include/net/dst.h | 1 +
net/ipv6/route.c | 13 +++++++++++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst.h
index 344c8dd..ee7a781 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -54,6 +54,7 @@ struct dst_entry {
#define DST_NOCACHE 0x0010
#define DST_NOCOUNT 0x0020
#define DST_NOPEER 0x0040
+#define DST_NOPEERMETRICS 0x0080
short error;
short obsolete;
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 92be12b..d96ccc5 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -278,7 +278,7 @@ static void ip6_dst_destroy(struct dst_entry *dst)
struct inet6_dev *idev = rt->rt6i_idev;
struct inet_peer *peer = rt->rt6i_peer;
- if (!(rt->dst.flags & DST_HOST))
+ if (!(rt->dst.flags & DST_HOST) || (rt->dst.flags & DST_NOPEERMETRICS))
dst_destroy_metrics_generic(dst);
if (idev) {
@@ -1088,6 +1088,7 @@ struct dst_entry *icmp6_dst_alloc(struct net_device *dev,
struct rt6_info *rt;
struct inet6_dev *idev = in6_dev_get(dev);
struct net *net = dev_net(dev);
+ u32 *metrics;
if (unlikely(!idev))
return NULL;
@@ -1110,13 +1111,21 @@ struct dst_entry *icmp6_dst_alloc(struct net_device *dev,
}
}
- rt->dst.flags |= DST_HOST;
+ rt->dst.flags |= (DST_HOST | DST_NOPEERMETRICS);
rt->dst.output = ip6_output;
dst_set_neighbour(&rt->dst, neigh);
atomic_set(&rt->dst.__refcnt, 1);
rt->rt6i_dst.addr = fl6->daddr;
rt->rt6i_dst.plen = 128;
rt->rt6i_idev = idev;
+
+ metrics = kzalloc(sizeof(u32) * RTAX_MAX, GFP_ATOMIC);
+ if (unlikely(!metrics)) {
+ in6_dev_put(idev);
+ dst_free(&rt->dst);
+ return ERR_CAST(-ENOMEM);
+ }
+ dst_init_metrics(&rt->dst, metrics, false);
dst_metric_set(&rt->dst, RTAX_HOPLIMIT, 255);
spin_lock_bh(&icmp6_dst_lock);
--
1.7.1
^ permalink raw reply related
* Re: e1000e interface hang on 82574L
From: Chris Boot @ 2012-03-17 17:54 UTC (permalink / raw)
To: Wyborny, Carolyn; +Cc: e1000-devel@lists.sourceforge.net, netdev, lkml
In-Reply-To: <4F64B4E2.20208@bootc.net>
On 17/03/2012 15:59, Chris Boot wrote:
> On 16/01/2012 16:04, Chris Boot wrote:
>> On 16/01/2012 15:56, Wyborny, Carolyn wrote:
>>>
>>>> -----Original Message-----
>>>> From: Chris Boot [mailto:bootc@bootc.net]
>>>> Sent: Sunday, January 15, 2012 3:11 AM
>>>> To: Wyborny, Carolyn
>>>> Cc: netdev; lkml; e1000-devel@lists.sourceforge.net
>>>> Subject: Re: e1000e interface hang on 82574L
>>>>
>>>> On 04/01/2012 17:12, Chris Boot wrote:
>>>>> On 03/01/2012 00:02, Wyborny, Carolyn wrote:
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>>>> owner@vger.kernel.org]
>>>>>>> On Behalf Of Chris Boot
>>>>>>> Sent: Saturday, December 31, 2011 1:32 AM
>>>>>>> To: netdev; lkml; e1000-devel@lists.sourceforge.net
>>>>>>> Subject: Re: e1000e interface hang on 82574L
>>>>>>>
>>>>>>> On 27 Dec 2011, at 22:01, Chris Boot wrote:
>>>>>>>
>>>>>>>> Hi folks,
>>>>>>>>
>>>>>>>> Another networking issue I've run into, this time with e1000e
>>>> (Intel
>>>>>>> Corporation 82574L Gigabit). My new VM cluster appears to drop a NIC
>>>> -
>>>>>>> the port stops responding within Linux and shows the link as being
>>>> down
>>>>>>> with ethtool. My ISP says 'Ports running Half Duplex or reduced
>>>> speed'
>>>>>>> on the port.
>>>>>>>> When the port stops working I see this in dmesg:
>>>>>>>>
>>>>>>>> [35481.659629] ------------[ cut here ]------------
>>>>>>>> [35481.667837] WARNING: at net/sched/sch_generic.c:255
>>>>>>> dev_watchdog+0xe9/0x148()
>>>>>>>> [35481.676370] Hardware name: X9SCL/X9SCM
>>>>>>>> [35481.684793] NETDEV WATCHDOG: eth2 (e1000e): transmit queue 0
>>>> timed
>>>>>>> out
>>>>>>>> [35481.684795] Modules linked in: hmac sha256_generic dlm configfs
>>>>>>> ebtable_nat ebtables acpi_cpufreq mperf cpufreq_stats
>>>>>>> cpufreq_conservative cpufreq_userspace cpufreq_powersave microcode
>>>>>>> xt_NOTRACK ip_set_hash_net act_police cls_basic cls_flow cls_fw
>>>> cls_u32
>>>>>>> sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_connlimit
>>>>>>> xt_realm xt_addrtype ip_set_hash_ip iptable_raw xt_comment xt_recent
>>>>>>> ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN
>>>>>>> ipt_ecn ipt_CLUSTERIP ipt_ah nf_nat_tftp nf_nat_snmp_basic
>>>>>>> nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc
>>>>>>> nf_nat_h323 nf_nat_ftp ip6_queue nf_nat_amanda xt_set ip_set
>>>>>>> nf_conntrack_tftp nf_conntrack_sip nf_conntrack_sane
>>>>>>> nf_conntrack_proto_udplite nf_conntrack_proto_sctp nf_conntrack_pptp
>>>>>>> nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns
>>>>>>> nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323
>>>>>>> nf_conntrack_ftp ts_kmp nf_conntrack_amanda xt_TPROXY xt_NFLOG
>>>>>>> nfnetlink_log nf_tproxy_core xt_time xt_TCPMSS xt_tcpmss xt_sctp
>>>>>>> xt_policy xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_multiport
>>>> xt_mark
>>>>>>> xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP
>>>>>>> xt_dscp xt_dccp xt_connmark xt_CLASSIFY xt_AUDIT ip6t_LOG
>>>> ip6t_REJECT
>>>>>>> nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack ip6table_raw ipt_LOG
>>>>>>> xt_tcpudp ip6table_mangle xt_state iptable_nat nf_nat
>>>> nf_conntrack_ipv4
>>>>>>> nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink iptable_filter
>>>>>>> ip_tables ip6table_filter ip6_tables x_tables bridge stp bonding
>>>>>>> w83627ehf hwmon_vid coretemp sha1_ssse3 sha1_generic crc32c_intel
>>>>>>> aesni_intel cryptd aes_x86_64 aes_generic ipmi_poweroff ipmi_devintf
>>>>>>> ipmi_si ipmi_msghandler vhost_net macvtap macvlan tun drbd lru_cache
>>>> cn
>>>>>>> loop kvm_intel kvm snd_pcm snd_timer snd iTCO_wdt soundcore psmouse
>>>>>>> snd_page_alloc i2c_i801 i2c_core cdc_acm iTCO_vendor_support joydev
>>>>>>> evdev serio_raw processor button pcspkr thermal_sys ext4 mbcache
>>>> jbd2
>>>>>>> crc16 dm_mod raid1 md_mod sd_mod crc_t10dif usb_storage uas usbhid
>>>> hid
>>>>>>> ahci libahci libata igb ehci_hcd scsi_mod usbcore e1000e dca
>>>> usb_common
>>>>>>> [last unloaded: scsi_wait_scan]
>>>>>>>> [35481.685740] Pid: 0, comm: swapper/4 Not tainted 3.2.0-rc6+ #4
>>>>>>>> [35481.685744] Call Trace:
>>>>>>>> [35481.685746]<IRQ> [<ffffffff810467ed>] ?
>>>>>>> warn_slowpath_common+0x78/0x8c
>>>>>>>> [35481.685849] [<ffffffff81046899>] ? warn_slowpath_fmt+0x45/0x4a
>>>>>>>> [35481.685875] [<ffffffff810aeaa0>] ?
>>>>>>> perf_event_task_tick+0x166/0x1ab
>>>>>>>> [35481.686018] [<ffffffff81294219>] ? netif_tx_lock+0x40/0x72
>>>>>>>> [35481.686090] [<ffffffff8129437a>] ? dev_watchdog+0xe9/0x148
>>>>>>>> [35481.686136] [<ffffffff81051e58>] ? run_timer_softirq+0x19a/0x261
>>>>>>>> [35481.686176] [<ffffffff81294291>] ? netif_tx_unlock+0x46/0x46
>>>>>>>> [35481.686215] [<ffffffff810659bb>] ? timekeeping_get_ns+0xd/0x2a
>>>>>>>> [35481.686286] [<ffffffff8104bdd4>] ? __do_softirq+0xb9/0x177
>>>>>>>> [35481.686365] [<ffffffff81341d6c>] ? call_softirq+0x1c/0x30
>>>>>>>> [35481.686530] [<ffffffff8100f841>] ? do_softirq+0x3c/0x7b
>>>>>>>> [35481.686580] [<ffffffff8104c03c>] ? irq_exit+0x3c/0x9a
>>>>>>>> [35481.686742] [<ffffffff81023e58>] ?
>>>>>>> smp_apic_timer_interrupt+0x74/0x82
>>>>>>>> [35481.686820] [<ffffffff813405de>] ?
>>>> apic_timer_interrupt+0x6e/0x80
>>>>>>>> [35481.686826]<EOI> [<ffffffff811ddf49>] ? intel_idle+0xea/0x119
>>>>>>>> [35481.686991] [<ffffffff811ddf28>] ? intel_idle+0xc9/0x119
>>>>>>>> [35481.687051] [<ffffffff8125dce3>] ? cpuidle_idle_call+0xec/0x179
>>>>>>>> [35481.687089] [<ffffffff8100d255>] ? cpu_idle+0xa1/0xe8
>>>>>>>> [35481.687143] [<ffffffff810706ee>] ?
>>>> arch_local_irq_restore+0x2/0x8
>>>>>>>> [35481.687189] [<ffffffff8132d191>] ? start_secondary+0x1d5/0x1db
>>>>>>>> [35481.687234] ---[ end trace 01e9907674757948 ]---
>>>>>>>> [35481.687817] e1000e 0000:05:00.0: eth2: Reset adapter
>>>>>>>>
>>>>>>>> To try to regain connectivity I bring down the bond and the
>>>> interface
>>>>>>> (eth2), then unload e1000e. Upon loading the module again:
>>>>>>>> [36021.888962] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k
>>>>>>>> [36021.900258] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
>>>>>>>> [36021.911446] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level,
>>>> low) -
>>>>>>>> IRQ 20
>>>>>>>> [36021.923204] e1000e 0000:00:19.0: setting latency timer to 64
>>>>>>>> [36021.923372] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
>>>>>>>> [36022.202737] e1000e 0000:00:19.0: eth2: (PCI
>>>> Express:2.5GT/s:Width
>>>>>>> x1) 00:25:90:56:ac:75
>>>>>>>> [36022.214480] e1000e 0000:00:19.0: eth3: Intel(R) PRO/1000 Network
>>>>>>> Connection
>>>>>>>> [36022.227506] e1000e 0000:00:19.0: eth3: MAC: 10, PHY: 11, PBA No:
>>>>>>> FFFFFF-0FF
>>>>>>>> [36022.239789] e1000e 0000:05:00.0: Disabling ASPM L0s
>>>>>>>> [36022.239805] e1000e 0000:05:00.0: enabling device (0000 -> 0002)
>>>>>>>> [36022.239829] e1000e 0000:05:00.0: PCI INT A -> GSI 16 (level,
>>>> low) -
>>>>>>>> IRQ 16
>>>>>>>> [36022.239921] e1000e 0000:05:00.0: setting latency timer to 64
>>>>>>>> [36022.240963] e1000e 0000:05:00.0: irq 64 for MSI/MSI-X
>>>>>>>> [36022.240995] e1000e 0000:05:00.0: irq 65 for MSI/MSI-X
>>>>>>>> [36022.241028] e1000e 0000:05:00.0: irq 66 for MSI/MSI-X
>>>>>>>> [36022.241596] e1000e 0000:05:00.0: PCI INT A disabled
>>>>>>>> [36022.241606] e1000e: probe of 0000:05:00.0 failed with error -2
>>>>>>>> [36022.304706] udevd[3634]: renamed network interface eth2 to eth3
>>>>>>>>
>>>>>>>> I then don't get an eth2 interface. Only a reboot brings the
>>>> interface
>>>>>>> back. This has happened twice so far on this server in the past
>>>> week,
>>>>>>> both times using v3.2-rc7-3-g4962516.
>>>>>>>> lspci -vnn shows:
>>>>>>>>
>>>>>>>> 05:00.0 Ethernet controller [0200]: Intel Corporation 82574L
>>>> Gigabit
>>>>>>> Network Connection [8086:10d3]
>>>>>>>> Subsystem: Super Micro Computer Inc Device [15d9:0000]
>>>>>>>> Flags: bus master, fast devsel, latency 0, IRQ 16
>>>>>>>> Memory at fbd00000 (32-bit, non-prefetchable) [size=128K]
>>>>>>>> I/O ports at e000 [size=32]
>>>>>>>> Memory at fbd20000 (32-bit, non-prefetchable) [size=16K]
>>>>>>>> Capabilities: [c8] Power Management version 2
>>>>>>>> Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
>>>>>>>> Capabilities: [e0] Express Endpoint, MSI 00
>>>>>>>> Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
>>>>>>>> Capabilities: [100] Advanced Error Reporting
>>>>>>>> Capabilities: [140] Device Serial Number 00-25-90-ff-ff-56-ac-
>>>>>>> 74
>>>>>>>> Kernel driver in use: e1000e
>>>>>>> I've just had this happen on my other (identical) server with a
>>>> nearly
>>>>>>> identical trace. Is there anything I can do do avoid this at all or
>>>> at
>>>>>>> least help narrow down the problem?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Chris
>>>>>>>
>>>>>>> --
>>>>>>> Chris Boot
>>>>>>> bootc@bootc.net
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>> Hello,
>>>>>>
>>>>>> Sorry for the delay in responding. We have seen some hang issues
>>>> using
>>>>>> MSI-X on 82574 parts. Can you try reloading the driver the IntMode
>>>>>> module parameter. IntMode=1 (you'll need a setting for each device in
>>>>>> the system so two adapters would be IntMode=1,1) See if that changes
>>>>>> the symptom you are seeing with this part. That setting will make
>>>> sure
>>>>>> the adapter uses MSI interrupts instead of MSI-X.
>>>>> Carolyn,
>>>>>
>>>>> I'll give this a go next time I reproduce it. I built a new kernel
>>>> with
>>>>> more debugging and so far it hasn't yet triggered again...
>>>> Upgrading to a more recent 3.2-rc snapshot seems to have cured the
>>>> problem - I haven't had an interface stop responding since. Must have
>>>> been some seemingly unrelated patch that I can't seem to locate.
>>>>
>>>> Cheers,
>>>> Chris
>>>>
>>>> --
>>>> Chris Boot
>>>> bootc@bootc.net
>>> Thanks for letting me know Chris. For my own edification, are you
>>> still configured with MSI-X?
>> Carolyn,
>>
>> I have made no changes to my configuration to change the interrupt
>> format. I see the following in dmesg at boot:
>>
>> [ 3.276819] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k
>> [ 3.288193] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
>>
>> [ 3.299842] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low)
>> -> IRQ 20
>> [ 3.299909] e1000e 0000:00:19.0: setting latency timer to 64
>> [ 3.352929] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
>> [ 3.710080] e1000e 0000:00:19.0: eth2: (PCI Express:2.5GT/s:Width
>> x1) 00:25:90:56:ac:75
>> [ 3.710082] e1000e 0000:00:19.0: eth2: Intel(R) PRO/1000 Network
>> Connection
>> [ 3.710670] e1000e 0000:00:19.0: eth2: MAC: 10, PHY: 11, PBA No:
>> FFFFFF-0FF
>>
>> [ 3.710678] e1000e 0000:05:00.0: Disabling ASPM L0s
>> [ 3.710850] e1000e 0000:05:00.0: PCI INT A -> GSI 16 (level, low)
>> -> IRQ 16
>> [ 3.710951] e1000e 0000:05:00.0: setting latency timer to 64
>> [ 3.712757] e1000e 0000:05:00.0: irq 64 for MSI/MSI-X
>> [ 3.712787] e1000e 0000:05:00.0: irq 65 for MSI/MSI-X
>> [ 3.712805] e1000e 0000:05:00.0: irq 66 for MSI/MSI-X
>> [ 3.830364] e1000e 0000:05:00.0: eth3: (PCI Express:2.5GT/s:Width
>> x1) 00:25:90:56:ac:74
>> [ 3.830366] e1000e 0000:05:00.0: eth3: Intel(R) PRO/1000 Network
>> Connection
>> [ 3.830510] e1000e 0000:05:00.0: eth3: MAC: 3, PHY: 8, PBA No:
>> FFFFFF-0FF
>>
>> /proc/interrupts shows:
>>
>> 45: 615958 0 0 0 0 0
>> 0 0 IR-PCI-MSI-edge eth3
>> 64: 65126106 0 0 0 0 0
>> 0 0 IR-PCI-MSI-edge eth2-rx-0
>> 65: 52700392 0 0 0 0 0
>> 0 0 IR-PCI-MSI-edge eth2-tx-0
>> 66: 2 0 0 0 0 0
>> 0 0 IR-PCI-MSI-edge eth2
> Carolyn,
>
> I've just had the opportunity to upgrade to a 3.2.9 kernel on these
> systems and have made sure e1000e is loaded with IntMode=1,1. One of the
> servers was only up 5.5 hours before the NIC has crashed/stopped working
> again.
>
> Here is the latest dmesg after the failure:
>
> [ 3.254553] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k
> [ 3.265852] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
> [ 3.266034] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) ->
> IRQ 20
> [ 3.266067] e1000e 0000:00:19.0: setting latency timer to 64
> [ 3.266460] e1000e 0000:00:19.0: (unregistered net_device): Interrupt
> Mode set to 1
> [ 3.266800] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
> [ 3.611840] e1000e 0000:00:19.0: eth2: (PCI Express:2.5GT/s:Width x1)
> 00:25:90:56:ac:75
> [ 3.611855] e1000e 0000:00:19.0: eth2: Intel(R) PRO/1000 Network
> Connection
> [ 3.612303] e1000e 0000:00:19.0: eth2: MAC: 10, PHY: 11, PBA No:
> FFFFFF-0FF
> [ 3.612350] e1000e 0000:05:00.0: Disabling ASPM L0s
> [ 3.612594] e1000e 0000:05:00.0: PCI INT A -> GSI 16 (level, low) ->
> IRQ 16
> [ 3.612812] e1000e 0000:05:00.0: setting latency timer to 64
> [ 3.613582] e1000e 0000:05:00.0: (unregistered net_device): Interrupt
> Mode set to 1
> [ 3.614156] e1000e 0000:05:00.0: irq 64 for MSI/MSI-X
> [ 3.734442] e1000e 0000:05:00.0: eth3: (PCI Express:2.5GT/s:Width x1)
> 00:25:90:56:ac:74
> [ 3.734465] e1000e 0000:05:00.0: eth3: Intel(R) PRO/1000 Network
> Connection
> [ 3.734689] e1000e 0000:05:00.0: eth3: MAC: 3, PHY: 8, PBA No: FFFFFF-0FF
> [ 13.799848] e1000e 0000:05:00.0: irq 64 for MSI/MSI-X
> [ 13.855646] e1000e 0000:05:00.0: irq 64 for MSI/MSI-X
> [ 14.031739] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
> [ 14.087566] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
> [ 16.112504] e1000e: eth2 NIC Link is Up 100 Mbps Full Duplex, Flow
> Control: None
> [ 16.124129] e1000e 0000:05:00.0: eth2: 10/100 speed: disabling TSO
>
> And here is the output just as it hangs:
>
> [19745.327241] ------------[ cut here ]------------
> [19745.334501] WARNING: at
> /build/buildd-linux-2.6_3.2.9-1-amd64-KTPapN/linux-2.6-3.2.9/debian/build/source_amd64_none/net/sched/sch_generic.c:255
> dev_watchdog+0xe9/0x148()
> [19745.350441] Hardware name: X9SCL/X9SCM
> [19745.358859] NETDEV WATCHDOG: eth2 (e1000e): transmit queue 0 timed out
> [19745.367287] Modules linked in: hmac sha256_generic dlm configfs
> ebtable_nat ebtables acpi_cpufreq mperf cpufreq_stats
> cpufreq_conservative cpufreq_userspace cpufreq_powersave microcode
> ip6_queue xt_TCPMSS xt_sctp ip6t_LOG ip6t_REJECT nf_conntrack_ipv6
> ip6table_raw ip6table_mangle ip6table_filter xt_NOTRACK ip_set_hash_net
> act_police cls_basic cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_htb
> sch_hfsc sch_ingress sch_sfq xt_statistic xt_CT xt_time xt_connlimit
> xt_realm xt_addrtype ip_set_hash_ip iptable_raw xt_comment xt_recent
> xt_policy ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE
> ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah xt_set ip_set nf_nat_tftp
> nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp
> nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp
> nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip
> nf_conntrack_proto_udplite nf_conntrack_proto_sctp nf_conntrack_pptp
> nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns
> nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323
> nf_conntrack_ftp xt_TPROXY nf_tproxy_core ip6_tables nf_defrag_ipv6
> xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG
> nfnetlink_log xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange
> xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_conntrack xt_connmark
> xt_CLASSIFY xt_AUDIT ipt_LOG xt_tcpudp xt_state iptable_nat nf_nat
> nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink
> iptable_filter ip_tables x_tables kvm_intel kvm bridge stp bonding
> w83627ehf hwmon_vid coretemp sha1_ssse3 sha1_generic crc32c_intel
> aesni_intel cryptd aes_x86_64 aes_generic ipmi_poweroff ipmi_devintf
> ipmi_si ipmi_msghandler vhost_net macvtap macvlan tun drbd lru_cache cn
> loop snd_pcm snd_timer snd soundcore snd_page_alloc iTCO_wdt i2c_i801
> psmouse cdc_acm processor i2c_core iTCO_vendor_support serio_raw pcspkr
> thermal_sys button evdev joydev ext4 mbcache jbd2 crc16 dm_mod raid1
> md_mod sd_mod crc_t10dif usb_storage uas usbhid hid ahci libahci libata
> ehci_hcd usbcore igb scsi_mod e1000e usb_common dca [last unloaded:
> scsi_wait_scan]
> [19745.502559] Pid: 0, comm: swapper/0 Not tainted 3.2.0-2-amd64 #1
> [19745.502561] Call Trace:
> [19745.502562]<IRQ> [<ffffffff81046879>] ? warn_slowpath_common+0x78/0x8c
> [19745.502570] [<ffffffff81046925>] ? warn_slowpath_fmt+0x45/0x4a
> [19745.502574] [<ffffffff8129aa11>] ? netif_tx_lock+0x40/0x72
> [19745.502588] [<ffffffff8129ab72>] ? dev_watchdog+0xe9/0x148
> [19745.502601] [<ffffffff81051f38>] ? run_timer_softirq+0x19a/0x261
> [19745.502603] [<ffffffff8129aa89>] ? netif_tx_unlock+0x46/0x46
> [19745.502606] [<ffffffff81065a73>] ? timekeeping_get_ns+0xd/0x2a
> [19745.502609] [<ffffffff8104be98>] ? __do_softirq+0xb9/0x177
> [19745.502612] [<ffffffff8134892c>] ? call_softirq+0x1c/0x30
> [19745.502615] [<ffffffff8100f8e5>] ? do_softirq+0x3c/0x7b
> [19745.502617] [<ffffffff8104c100>] ? irq_exit+0x3c/0x9a
> [19745.502621] [<ffffffff81023f18>] ? smp_apic_timer_interrupt+0x74/0x82
> [19745.502624] [<ffffffff8134719e>] ? apic_timer_interrupt+0x6e/0x80
> [19745.502625]<EOI> [<ffffffff81070761>] ? arch_local_irq_save+0x11/0x17
> [19745.502631] [<ffffffff811e45d9>] ? intel_idle+0xea/0x119
> [19745.502633] [<ffffffff811e45b8>] ? intel_idle+0xc9/0x119
> [19745.502637] [<ffffffff812643f7>] ? cpuidle_idle_call+0xec/0x179
> [19745.502639] [<ffffffff8100d248>] ? cpu_idle+0xa5/0xf2
> [19745.502641] [<ffffffff816aab3d>] ? start_kernel+0x3bd/0x3c8
> [19745.502643] [<ffffffff816aa140>] ? early_idt_handlers+0x140/0x140
> [19745.502645] [<ffffffff816aa3c4>] ? x86_64_start_kernel+0x104/0x111
> [19745.502646] ---[ end trace 10e791a6f31603fa ]---
> [19745.503125] e1000e 0000:05:00.0: eth2: Reset adapter
>
> Once again, rmmod e1000e followed by modprobe e1000e does not fix the
> problem:
>
> [20508.158919] e1000e 0000:05:00.0: PCI INT A disabled
> [20508.194927] e1000e 0000:00:19.0: PCI INT A disabled
> [20511.119765] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k
> [20511.130711] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
> [20511.141206] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) ->
> IRQ 20
> [20511.151797] e1000e 0000:00:19.0: setting latency timer to 64
> [20511.151921] e1000e 0000:00:19.0: (unregistered net_device): Interrupt
> Mode set to 1
> [20511.162853] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
> [20511.528436] e1000e 0000:00:19.0: eth2: (PCI Express:2.5GT/s:Width x1)
> 00:25:90:56:ac:75
> [20511.539261] e1000e 0000:00:19.0: eth3: Intel(R) PRO/1000 Network
> Connection
> [20511.550066] e1000e 0000:00:19.0: eth3: MAC: 10, PHY: 11, PBA No:
> FFFFFF-0FF
> [20511.561027] e1000e 0000:05:00.0: Disabling ASPM L0s
> [20511.571883] e1000e 0000:05:00.0: enabling device (0000 -> 0002)
> [20511.575224] udevd[5449]: renamed network interface eth2 to eth3
> [20511.594234] e1000e 0000:05:00.0: PCI INT A -> GSI 16 (level, low) ->
> IRQ 16
> [20511.605703] e1000e 0000:05:00.0: setting latency timer to 64
> [20511.605871] e1000e 0000:05:00.0: (unregistered net_device): Interrupt
> Mode set to 1
> [20511.617706] e1000e 0000:05:00.0: irq 64 for MSI/MSI-X
> [20511.617828] e1000e 0000:05:00.0: PCI INT A disabled
> [20511.629565] e1000e: probe of 0000:05:00.0 failed with error -2
>
> Please let me know if/how I can debug this further.
As further information, I have a machine with the same NIC and chipset
(Intel S1200BTL motherboard) but with quite different lspci -vvv
outputs. Both are pasted below.
First, from the working S1200BTL:
03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
Connection
Subsystem: Intel Corporation Device 3578
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at c1300000 (32-bit, non-prefetchable) [size=128K]
Region 2: I/O ports at 2000 [size=32]
Region 3: Memory at c1320000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [e0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
<512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+
Unsupported+
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq-
AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
Latency L0 <128ns, L1 <64us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
Vector table: BAR=3 offset=00000000
PBA: BAR=3 offset=00002000
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UESvrt: DLP+ SDES- TLP+ FCP+ CmpltTO+ CmpltAbrt+
UnxCmplt+ RxOF+ MalfTLP+ ECRC- UnsupReq+ ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn-
ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number 00-1e-67-ff-ff-14-69-f4
Kernel driver in use: e1000e
And from the Supermicro server, where the NIC hangs:
05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
Connection
Subsystem: Super Micro Computer Inc Device 0000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 65
Region 0: Memory at fbd00000 (32-bit, non-prefetchable) [size=128K]
Region 2: I/O ports at e000 [size=32]
Region 3: Memory at fbd20000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee00858 Data: 0000
Capabilities: [e0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
<512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+
Unsupported+
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+
AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
Latency L0 <128ns, L1 <64us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled-
Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Capabilities: [a0] MSI-X: Enable- Count=5 Masked-
Vector table: BAR=3 offset=00000000
PBA: BAR=3 offset=00002000
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt-
UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr+ BadTLP+ BadDLLP+ Rollover- Timeout-
NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr+
AERCap: First Error Pointer: 14, GenCap- CGenEn-
ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number 00-25-90-ff-ff-56-ac-74
Kernel driver in use: e1000e
Most notably it appears as though MSI-X is not enabled on the
Supermicro, and ASPM L1 is. There appears to be no difference on the
Supermicro as to the MSI-X status when booting with IntMode=1,1 compared
to without it.
Thanks,
Chris
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [net 2/3] net: do not do gso for CHECKSUM_UNNECESSARY in netif_needs_gso
From: Ben Hutchings @ 2012-03-17 18:41 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Yi Zou, netdev, gospo, sassmann
In-Reply-To: <1331975292-19521-1-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, 2012-03-17 at 02:08 -0700, Jeff Kirsher wrote:
> From: Yi Zou <yi.zou@intel.com>
>
> This is related to fixing the bug of dropping FCoE frames when disabling tx ip
> checksum by 'ethtool -K ethx tx off'. The FCoE protocol stack driver would
> use CHECKSUM_UNNECESSARY on tx path instead of CHECKSUM_PARTIAL (as indicated in
> the 2/2 of this series). To do so, netif_needs_gso() has to be changed here to
> not do gso for both CHECKSUM_PARTIAL and CHECKSUM_UNNECESSARY.
[...]
This should also be documented as valid in include/linux/skbuff.h,
though I don't think the fix should be held up for that.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] gianfar: Fix possible overrun and simplify interrupt name field creation
From: Joe Perches @ 2012-03-17 19:05 UTC (permalink / raw)
To: netdev, linux-kernel; +Cc: Sandeep Gopalpet
Space allocated for int_name_<foo> is unsufficient for
maximal device name, expand it.
Code to create int_name_<foo> is obscure, simplify it
by using sprintf.
Found by looking for unnecessary \ line continuations.
Uncompiled, untested.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/ethernet/freescale/gianfar.c | 39 +++++------------------------
drivers/net/ethernet/freescale/gianfar.h | 2 +-
2 files changed, 8 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index adb0ae4..770b8cf 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -971,7 +971,6 @@ static int gfar_probe(struct platform_device *ofdev)
struct gfar_private *priv = NULL;
struct gfar __iomem *regs = NULL;
int err = 0, i, grp_idx = 0;
- int len_devname;
u32 rstat = 0, tstat = 0, rqueue = 0, tqueue = 0;
u32 isrg = 0;
u32 __iomem *baddr;
@@ -1172,40 +1171,16 @@ static int gfar_probe(struct platform_device *ofdev)
priv->device_flags & FSL_GIANFAR_DEV_HAS_MAGIC_PACKET);
/* fill out IRQ number and name fields */
- len_devname = strlen(dev->name);
for (i = 0; i < priv->num_grps; i++) {
- strncpy(&priv->gfargrp[i].int_name_tx[0], dev->name,
- len_devname);
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_MULTI_INTR) {
- strncpy(&priv->gfargrp[i].int_name_tx[len_devname],
- "_g", sizeof("_g"));
- priv->gfargrp[i].int_name_tx[
- strlen(priv->gfargrp[i].int_name_tx)] = i+48;
- strncpy(&priv->gfargrp[i].int_name_tx[strlen(
- priv->gfargrp[i].int_name_tx)],
- "_tx", sizeof("_tx") + 1);
-
- strncpy(&priv->gfargrp[i].int_name_rx[0], dev->name,
- len_devname);
- strncpy(&priv->gfargrp[i].int_name_rx[len_devname],
- "_g", sizeof("_g"));
- priv->gfargrp[i].int_name_rx[
- strlen(priv->gfargrp[i].int_name_rx)] = i+48;
- strncpy(&priv->gfargrp[i].int_name_rx[strlen(
- priv->gfargrp[i].int_name_rx)],
- "_rx", sizeof("_rx") + 1);
-
- strncpy(&priv->gfargrp[i].int_name_er[0], dev->name,
- len_devname);
- strncpy(&priv->gfargrp[i].int_name_er[len_devname],
- "_g", sizeof("_g"));
- priv->gfargrp[i].int_name_er[strlen(
- priv->gfargrp[i].int_name_er)] = i+48;
- strncpy(&priv->gfargrp[i].int_name_er[strlen(\
- priv->gfargrp[i].int_name_er)],
- "_er", sizeof("_er") + 1);
+ sprintf(priv->gfargrp[i].int_name_tx, "%s%s%c%s",
+ dev->name, "_g", '0' + i, "_tx");
+ sprintf(priv->gfargrp[i].int_name_rx, "%s%s%c%s",
+ dev->name, "_g", '0' + i, "_rx");
+ sprintf(priv->gfargrp[i].int_name_er, "%s%s%c%s",
+ dev->name, "_g", '0' + i, "_er");
} else
- priv->gfargrp[i].int_name_tx[len_devname] = '\0';
+ strcpy(priv->gfargrp[i].int_name_tx, dev->name);
}
/* Initialize the filer table */
diff --git a/drivers/net/ethernet/freescale/gianfar.h b/drivers/net/ethernet/freescale/gianfar.h
index 4fe0f34..e537d81 100644
--- a/drivers/net/ethernet/freescale/gianfar.h
+++ b/drivers/net/ethernet/freescale/gianfar.h
@@ -520,7 +520,7 @@ extern const char gfar_driver_version[];
#define RXFCB_PERR_MASK 0x000c
#define RXFCB_PERR_BADL3 0x0008
-#define GFAR_INT_NAME_MAX IFNAMSIZ + 4
+#define GFAR_INT_NAME_MAX (IFNAMSIZ + 6) /* '_g#_xx' */
struct txbd8
{
--
1.7.8.111.gad25c.dirty
^ permalink raw reply related
* [PATCH 1/2] rtlwifi: Use is_zero_ether_addr, remove line continuation
From: Joe Perches @ 2012-03-17 19:13 UTC (permalink / raw)
To: Larry Finger, Chaoming Li
Cc: John W. Linville, linux-wireless, netdev, linux-kernel
Use the normal kernel facilities and use %pM
to print the all zero mac address.
Remove unnecessary line continuation.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/wireless/rtlwifi/cam.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/cam.c b/drivers/net/wireless/rtlwifi/cam.c
index 5c7d579..3d8cc4a 100644
--- a/drivers/net/wireless/rtlwifi/cam.c
+++ b/drivers/net/wireless/rtlwifi/cam.c
@@ -328,10 +328,9 @@ void rtl_cam_del_entry(struct ieee80211_hw *hw, u8 *sta_addr)
RT_TRACE(rtlpriv, COMP_SEC, DBG_EMERG, "sta_addr is NULL\n");
}
- if ((sta_addr[0]|sta_addr[1]|sta_addr[2]|sta_addr[3]|\
- sta_addr[4]|sta_addr[5]) == 0) {
+ if (is_zero_ether_addr(sta_addr)) {
RT_TRACE(rtlpriv, COMP_SEC, DBG_EMERG,
- "sta_addr is 00:00:00:00:00:00\n");
+ "sta_addr is %pM\n", sta_addr);
return;
}
/* Does STA already exist? */
--
1.7.8.111.gad25c.dirty
^ permalink raw reply related
* [PATCH 2/2] drivers: net: Remove unnecessary line continuations
From: Joe Perches @ 2012-03-17 19:14 UTC (permalink / raw)
To: Geoff Levand, Ishizaki Kou, Jens Osterkamp, Samuel Ortiz
Cc: Wolfgang Grandegger, Marc Kleine-Budde, linux-can, netdev,
linux-kernel, cbe-oss-dev
In-Reply-To: <1d738d4a4dd61978f969ed4a43f2dd3717f51a19.1332011552.git.joe@perches.com>
Line continuations are error prone so just remove them.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 4 ++--
drivers/net/ethernet/micrel/ks8695net.c | 4 ++--
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 3 +--
drivers/net/ethernet/toshiba/spider_net.c | 4 ++--
drivers/net/irda/bfin_sir.c | 4 ++--
drivers/net/phy/et1011c.c | 9 +++++----
6 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_pro.c b/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
index 5234586..68f4e12 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
@@ -304,8 +304,8 @@ static int pcan_usb_pro_wait_rsp(struct peak_usb_device *dev,
pr->data_type);
/* check if channel in response corresponds too */
- else if ((req_channel != 0xff) && \
- (pr->bus_act.channel != req_channel))
+ else if ((req_channel != 0xff) &&
+ (pr->bus_act.channel != req_channel))
netdev_err(dev->netdev,
"got rsp %xh but on chan%u: ignored\n",
req_data_type, pr->bus_act.channel);
diff --git a/drivers/net/ethernet/micrel/ks8695net.c b/drivers/net/ethernet/micrel/ks8695net.c
index dccae1d..012e66d 100644
--- a/drivers/net/ethernet/micrel/ks8695net.c
+++ b/drivers/net/ethernet/micrel/ks8695net.c
@@ -1180,8 +1180,8 @@ ks8695_start_xmit(struct sk_buff *skb, struct net_device *ndev)
if (unlikely(dma_mapping_error(ksp->dev, dmap))) {
/* Failed to DMA map this SKB, give it back for now */
spin_unlock_irq(&ksp->txq_lock);
- dev_dbg(ksp->dev, "%s: Could not map DMA memory for "\
- "transmission, trying later\n", ndev->name);
+ dev_dbg(ksp->dev, "%s: Could not map DMA memory for transmission, trying later\n",
+ ndev->name);
return NETDEV_TX_BUSY;
}
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
index 5ee82a7..f707b0b 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
@@ -508,8 +508,7 @@ static void gelic_card_release_tx_chain(struct gelic_card *card, int stop)
case GELIC_DESCR_DMA_FORCE_END:
if (printk_ratelimit())
dev_info(ctodev(card),
- "%s: forcing end of tx descriptor " \
- "with status %x\n",
+ "%s: forcing end of tx descriptor with status %x\n",
__func__, status);
netdev->stats.tx_dropped++;
break;
diff --git a/drivers/net/ethernet/toshiba/spider_net.c b/drivers/net/ethernet/toshiba/spider_net.c
index 6199f6b..9039ddf 100644
--- a/drivers/net/ethernet/toshiba/spider_net.c
+++ b/drivers/net/ethernet/toshiba/spider_net.c
@@ -53,8 +53,8 @@
#include "spider_net.h"
-MODULE_AUTHOR("Utz Bacher <utz.bacher@de.ibm.com> and Jens Osterkamp " \
- "<Jens.Osterkamp@de.ibm.com>");
+MODULE_AUTHOR("Utz Bacher <utz.bacher@de.ibm.com> and "
+ "Jens Osterkamp <Jens.Osterkamp@de.ibm.com>");
MODULE_DESCRIPTION("Spider Southbridge Gigabit Ethernet driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(VERSION);
diff --git a/drivers/net/irda/bfin_sir.c b/drivers/net/irda/bfin_sir.c
index a561ae4..089b7e8 100644
--- a/drivers/net/irda/bfin_sir.c
+++ b/drivers/net/irda/bfin_sir.c
@@ -696,8 +696,8 @@ static int __devinit bfin_sir_probe(struct platform_device *pdev)
struct bfin_sir_port *sir_port;
int err;
- if (pdev->id >= 0 && pdev->id < ARRAY_SIZE(per) && \
- per[pdev->id][3] == pdev->id) {
+ if (pdev->id >= 0 && pdev->id < ARRAY_SIZE(per) &&
+ per[pdev->id][3] == pdev->id) {
err = peripheral_request_list(per[pdev->id], DRIVER_NAME);
if (err)
return err;
diff --git a/drivers/net/phy/et1011c.c b/drivers/net/phy/et1011c.c
index a8eb19e..edbccf7 100644
--- a/drivers/net/phy/et1011c.c
+++ b/drivers/net/phy/et1011c.c
@@ -77,10 +77,11 @@ static int et1011c_read_status(struct phy_device *phydev)
ET1011C_GIGABIT_SPEED) {
val = phy_read(phydev, ET1011C_CONFIG_REG);
val &= ~ET1011C_TX_FIFO_MASK;
- phy_write(phydev, ET1011C_CONFIG_REG, val\
- | ET1011C_GMII_INTERFACE\
- | ET1011C_SYS_CLK_EN\
- | ET1011C_TX_FIFO_DEPTH_16);
+ phy_write(phydev, ET1011C_CONFIG_REG,
+ (val |
+ ET1011C_GMII_INTERFACE |
+ ET1011C_SYS_CLK_EN |
+ ET1011C_TX_FIFO_DEPTH_16));
}
}
--
1.7.8.111.gad25c.dirty
^ permalink raw reply related
* Re: [PATCH 2/2] drivers: net: Remove unnecessary line continuations
From: Marc Kleine-Budde @ 2012-03-17 19:21 UTC (permalink / raw)
To: Joe Perches
Cc: Geoff Levand, Ishizaki Kou, Jens Osterkamp, Samuel Ortiz,
Wolfgang Grandegger, linux-can, netdev, linux-kernel, cbe-oss-dev
In-Reply-To: <67ad900b6f6451b5b28b004def471c9a41b1ee24.1332011552.git.joe@perches.com>
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]
On 03/17/2012 08:14 PM, Joe Perches wrote:
> Line continuations are error prone so just remove them.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 4 ++--
> drivers/net/ethernet/micrel/ks8695net.c | 4 ++--
> drivers/net/ethernet/toshiba/ps3_gelic_net.c | 3 +--
> drivers/net/ethernet/toshiba/spider_net.c | 4 ++--
> drivers/net/irda/bfin_sir.c | 4 ++--
> drivers/net/phy/et1011c.c | 9 +++++----
> 6 files changed, 14 insertions(+), 14 deletions(-)
For the peak_usb:
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
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: 262 bytes --]
^ permalink raw reply
* [PATCH] rtlwifi: Simplify rtl_get/set inline functions
From: Joe Perches @ 2012-03-17 20:36 UTC (permalink / raw)
To: Larry Finger, Chaoming Li
Cc: John W. Linville, linux-wireless, netdev, linux-kernel
Use a temporary to make the code a bit neater.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/wireless/rtlwifi/wifi.h | 24 +++++++++++-------------
1 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/wifi.h b/drivers/net/wireless/rtlwifi/wifi.h
index b591614..0f1d211 100644
--- a/drivers/net/wireless/rtlwifi/wifi.h
+++ b/drivers/net/wireless/rtlwifi/wifi.h
@@ -1954,37 +1954,35 @@ static inline void rtl_write_dword(struct rtl_priv *rtlpriv,
static inline u32 rtl_get_bbreg(struct ieee80211_hw *hw,
u32 regaddr, u32 bitmask)
{
- return ((struct rtl_priv *)(hw)->priv)->cfg->ops->get_bbreg(hw,
- regaddr,
- bitmask);
+ struct rtl_priv *rtlpriv = hw->priv;
+
+ return rtlpriv->cfg->ops->get_bbreg(hw, regaddr, bitmask);
}
static inline void rtl_set_bbreg(struct ieee80211_hw *hw, u32 regaddr,
u32 bitmask, u32 data)
{
- ((struct rtl_priv *)(hw)->priv)->cfg->ops->set_bbreg(hw,
- regaddr, bitmask,
- data);
+ struct rtl_priv *rtlpriv = hw->priv;
+ rtlpriv->cfg->ops->set_bbreg(hw, regaddr, bitmask, data);
}
static inline u32 rtl_get_rfreg(struct ieee80211_hw *hw,
enum radio_path rfpath, u32 regaddr,
u32 bitmask)
{
- return ((struct rtl_priv *)(hw)->priv)->cfg->ops->get_rfreg(hw,
- rfpath,
- regaddr,
- bitmask);
+ struct rtl_priv *rtlpriv = hw->priv;
+
+ return rtlpriv->cfg->ops->get_rfreg(hw, rfpath, regaddr, bitmask);
}
static inline void rtl_set_rfreg(struct ieee80211_hw *hw,
enum radio_path rfpath, u32 regaddr,
u32 bitmask, u32 data)
{
- ((struct rtl_priv *)(hw)->priv)->cfg->ops->set_rfreg(hw,
- rfpath, regaddr,
- bitmask, data);
+ struct rtl_priv *rtlpriv = hw->priv;
+
+ rtlpriv->cfg->ops->set_rfreg(hw, rfpath, regaddr, bitmask, data);
}
static inline bool is_hal_stop(struct rtl_hal *rtlhal)
--
1.7.8.111.gad25c.dirty
^ permalink raw reply related
* Re: [PATCH] isdn: Return -EINTR in gigaset_start() if locking attempts fails.
From: David Miller @ 2012-03-17 20:58 UTC (permalink / raw)
To: santoshprasadnayak
Cc: hjlipp, tilman, isdn, gigaset307x-common, netdev, linux-media,
kernel-janitors
In-Reply-To: <CAOD=uF6JJiiGjQwybzwdU3Zw9pC8YbDPxm_Pg9E9WNAXbfTiUQ@mail.gmail.com>
From: santosh prasad nayak <santoshprasadnayak@gmail.com>
Date: Sat, 17 Mar 2012 21:26:14 +0530
> Caller is interpreting 0 in opposite way of normal sequence.
> Thats why I misunderstood it.
The simple fact is that you didn't even look at the code at the call
sites when you wrote this patch, and that's the first thing anyone is
going to do when reviewing it.
Therefore your laziness results in more useless work for other people.
I just wanted to point out how selfish and anti-social this kind of
behavior is.
^ permalink raw reply
* Re: [PATCH 1/2] rtlwifi: Use is_zero_ether_addr, remove line continuation
From: Larry Finger @ 2012-03-17 21:14 UTC (permalink / raw)
To: Joe Perches
Cc: Chaoming Li, John W. Linville, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1d738d4a4dd61978f969ed4a43f2dd3717f51a19.1332011552.git.joe@perches.com>
On 03/17/2012 02:13 PM, Joe Perches wrote:
> Use the normal kernel facilities and use %pM
> to print the all zero mac address.
>
> Remove unnecessary line continuation.
>
> Signed-off-by: Joe Perches<joe@perches.com>
> ---
> drivers/net/wireless/rtlwifi/cam.c | 5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
ACKed-by: Larry.Finger@lwfinger.net
Is there a PATCH 2/2? I did not receive it.
Larry
>
> diff --git a/drivers/net/wireless/rtlwifi/cam.c b/drivers/net/wireless/rtlwifi/cam.c
> index 5c7d579..3d8cc4a 100644
> --- a/drivers/net/wireless/rtlwifi/cam.c
> +++ b/drivers/net/wireless/rtlwifi/cam.c
> @@ -328,10 +328,9 @@ void rtl_cam_del_entry(struct ieee80211_hw *hw, u8 *sta_addr)
> RT_TRACE(rtlpriv, COMP_SEC, DBG_EMERG, "sta_addr is NULL\n");
> }
>
> - if ((sta_addr[0]|sta_addr[1]|sta_addr[2]|sta_addr[3]|\
> - sta_addr[4]|sta_addr[5]) == 0) {
> + if (is_zero_ether_addr(sta_addr)) {
> RT_TRACE(rtlpriv, COMP_SEC, DBG_EMERG,
> - "sta_addr is 00:00:00:00:00:00\n");
> + "sta_addr is %pM\n", sta_addr);
> return;
> }
> /* Does STA already exist? */
^ permalink raw reply
* Re: [PATCH 1/2] rtlwifi: Use is_zero_ether_addr, remove line continuation
From: Joe Perches @ 2012-03-17 21:18 UTC (permalink / raw)
To: Larry Finger
Cc: Chaoming Li, John W. Linville,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4F64FECD.9000802-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On Sat, 2012-03-17 at 16:14 -0500, Larry Finger wrote:
> Is there a PATCH 2/2? I did not receive it.
Yes.
It's a line continuation removal patch to other files.
https://lkml.org/lkml/2012/3/17/72
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] rtlwifi: Use is_zero_ether_addr, remove line continuation
From: David Miller @ 2012-03-17 21:18 UTC (permalink / raw)
To: Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ
Cc: joe-6d6DIl74uiNBDgjK7y7TUQ, chaoming_li-kXabqFNEczNtrwSWzY7KCg,
linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4F64FECD.9000802-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
From: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date: Sat, 17 Mar 2012 16:14:53 -0500
> On 03/17/2012 02:13 PM, Joe Perches wrote:
>> Use the normal kernel facilities and use %pM
>> to print the all zero mac address.
>>
>> Remove unnecessary line continuation.
>>
>> Signed-off-by: Joe Perches<joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
>> ---
>> drivers/net/wireless/rtlwifi/cam.c | 5 ++---
>> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> ACKed-by: Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org
>
> Is there a PATCH 2/2? I did not receive it.
It went to netdev only and was only for non-wireless networking
drivers.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] isdn: Return -EINTR in gigaset_start() if locking attempts fails.
From: Julia Lawall @ 2012-03-17 21:28 UTC (permalink / raw)
To: David Miller
Cc: santoshprasadnayak, hjlipp, tilman, isdn, gigaset307x-common,
netdev, linux-media, kernel-janitors
In-Reply-To: <20120317.135854.570143927282385505.davem@davemloft.net>
On Sat, 17 Mar 2012, David Miller wrote:
> From: santosh prasad nayak <santoshprasadnayak@gmail.com>
> Date: Sat, 17 Mar 2012 21:26:14 +0530
>
>> Caller is interpreting 0 in opposite way of normal sequence.
>> Thats why I misunderstood it.
>
> The simple fact is that you didn't even look at the code at the call
> sites when you wrote this patch, and that's the first thing anyone is
> going to do when reviewing it.
>
> Therefore your laziness results in more useless work for other people.
> I just wanted to point out how selfish and anti-social this kind of
> behavior is.
Not to pour too much salt on a wound, but just 5 lines above the patch
site is the comment:
* Return value:
* 1 - success, 0 - error
And the error label also returns 0. So there is a lot of local
information that one can use to see what protocol the function follows.
That said, it's a bit too bad that two protocols have to coexist.
julia
^ permalink raw reply
* Re: linux-3.0.18+r8169+ipv4/tcp forwarding = tso/gso weirdness and performance degration
From: Francois Romieu @ 2012-03-17 22:20 UTC (permalink / raw)
To: Timo Teras; +Cc: Eric Dumazet, Ben Hutchings, netdev
In-Reply-To: <20120317113501.GC20532@electric-eye.fr.zoreil.com>
Francois Romieu <romieu@fr.zoreil.com> :
[...]
> > Or as easy alternative, enabling the VPD bit in Config1 should allow me
> > to read the EEPROM contents using the PCI /sys/.../vpd interface, right?
>
> In theory, yes. I have not tested it. Imho both access methods will be
> useful.
I tried vpd and got the eeprom content, duplicated 256 times.
The eeprom content is fairly boring:
# ethtool -e 8169sc-1
Offset Values
------ ------
0x0000 29 81 ec 10 67 81 ec 10 67 81 20 40 01 a1 00 e0
0x0010 4c 67 00 01 15 cd c2 f7 ff 80 ff ff ff ff ff 13
0x0020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0030 ff ff fa d6 ff ff ff ff ff ff ff ff ff ff ff 20
0x0040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
--
Ueimor
^ permalink raw reply
* Re: [PATCH 2/2] drivers: net: Remove unnecessary line continuations
From: David Miller @ 2012-03-17 22:41 UTC (permalink / raw)
To: joe
Cc: geoff, kou.ishizaki, jens, samuel, wg, mkl, linux-can, netdev,
linux-kernel, cbe-oss-dev
In-Reply-To: <67ad900b6f6451b5b28b004def471c9a41b1ee24.1332011552.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sat, 17 Mar 2012 12:14:03 -0700
> Line continuations are error prone so just remove them.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH] adjust __net_exit
From: Sam Ravnborg @ 2012-03-17 23:03 UTC (permalink / raw)
To: David Miller; +Cc: JBeulich, netdev, netfilter-devel, xemul, ebiederm
In-Reply-To: <20120316.221813.236130733754848615.davem@davemloft.net>
On Fri, Mar 16, 2012 at 10:18:13PM -0700, David Miller wrote:
> From: "Jan Beulich" <JBeulich@suse.com>
> Date: Thu, 08 Mar 2012 09:37:32 +0000
>
> > __net_exit, judging by the majority of its uses, was intended to serve
> > as an abstraction to allow calling such annotated functions from both
> > __init and __exit functions. Using the (bogus and unused elsewhere)
> > __exit_refok to implement this is inefficient - any non-modular code
> > really can reside in __init (as non-modular __exit code is never used).
> >
> > Therefore, adjust __net_exit to resolve to nothing (i.e. normal .text)
> > in modules, and __init in the core kernel.
> >
> > A few other adjustments are necessary/possible with this done - those
> > were likely just oversights when added originally.
> >
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> [ I have been waiting for more than a week for a netns developer
> to review this patch, I guess I'm too optimistic these days. :-( ]
>
> The only reason you think __exit_refok is "bogus" is because it's
> semantics got changed by Sam Ravnborg in commit
> 312b1485fb509c9bc32eda28ad29537896658cb8 ("Introduce new section
> reference annotations tags: __ref, __refdata, __refconst")
>
> Beforehand the __exit_refok was a real .exit section, so it got
> completely discarded AT LINK TIME. Now it sits together with
> __init_refok which is an unremovable kernel image section, which
> neither gets removed at compile time nor boot time.
Some misunderstanding is going on here.
The *ref* annotation is used to teach modpost that this function (or data)
may reference functions (or data) which is annotated __init*.
And the *ref* annotation never caused the annotated code to be discarded.
This was true before the above mentioned patch - and it is still true.
Before the path ("Introduce new section reference ....") the __exit_refok
annotation moved functions to the section named ".exit.text.refok"
which was explicit part of .text (TEXT_TEXT in vmlinux).
So __exit_refok does exactly what it is intended to do:
It puts the function in a section so modpost does not warn about
references to __init or __exit sections.
As Jan points out there is only a single user left - so
this would be a good time to kill it. It is even documented
in init.h that this is a backward compatibility define.
The intention with Jan's patch is to move functions annotated
__net_exit to a discardable section in the core kernel.
Then at least __exit should be used - there is no logic
using __init for exit code.
I suggest to:
1) fix the patch to use __exit
2) fix up the bogus commit message
Then it should be OK - iff the assumption hold that the functions
can be discarded in the core kernel.
I have grepped a little and saw no uses where this did not hold true.
So based on this I assume the assumption is OK.
Sam
^ permalink raw reply
* [PATCH net-next] fs_enet: Add MPC5125 FEC support and PHY interface selection
From: Anatolij Gustschin @ 2012-03-17 23:10 UTC (permalink / raw)
To: netdev, davem; +Cc: Pantelis Antoniou, Vitaly Bordug, Vladimir Ermakov
From: Vladimir Ermakov <vooon341@gmail.com>
Add compatible string for MPC5125 FEC. The FEC on MPC5125 additionally
supports RMII PHY interface. Configure controller/PHY interface type
according to the optional phy-connection-type property in the ethernet
node. This property should be either "rmii" or "mii".
Signed-off-by: Vladimir Ermakov <vooon341@gmail.com>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
drivers/net/ethernet/freescale/fs_enet/fec.h | 6 ++++--
.../net/ethernet/freescale/fs_enet/fs_enet-main.c | 20 ++++++++++++++++++--
drivers/net/ethernet/freescale/fs_enet/mac-fec.c | 9 ++++++---
3 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fs_enet/fec.h b/drivers/net/ethernet/freescale/fs_enet/fec.h
index e980527..b9fe5bd 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fec.h
+++ b/drivers/net/ethernet/freescale/fs_enet/fec.h
@@ -23,6 +23,10 @@
#define FEC_ECNTRL_ETHER_EN 0x00000002
#define FEC_ECNTRL_RESET 0x00000001
+/* RMII mode enabled only when MII_MODE bit is set too. */
+#define FEC_RCNTRL_RMII_MODE (0x00000100 | \
+ FEC_RCNTRL_MII_MODE | FEC_RCNTRL_FCE)
+#define FEC_RCNTRL_FCE 0x00000020
#define FEC_RCNTRL_BC_REJ 0x00000010
#define FEC_RCNTRL_PROM 0x00000008
#define FEC_RCNTRL_MII_MODE 0x00000004
@@ -33,8 +37,6 @@
#define FEC_TCNTRL_HBC 0x00000002
#define FEC_TCNTRL_GTS 0x00000001
-
-
/*
* Delay to wait for FEC reset command to complete (in us)
*/
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index 910a8e1..3fc103f 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -790,16 +790,20 @@ static int fs_init_phy(struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
struct phy_device *phydev;
+ phy_interface_t iface;
fep->oldlink = 0;
fep->oldspeed = 0;
fep->oldduplex = -1;
+ iface = fep->fpi->use_rmii ?
+ PHY_INTERFACE_MODE_RMII : PHY_INTERFACE_MODE_MII;
+
phydev = of_phy_connect(dev, fep->fpi->phy_node, &fs_adjust_link, 0,
- PHY_INTERFACE_MODE_MII);
+ iface);
if (!phydev) {
phydev = of_phy_connect_fixed_link(dev, &fs_adjust_link,
- PHY_INTERFACE_MODE_MII);
+ iface);
}
if (!phydev) {
dev_err(&dev->dev, "Could not attach to PHY\n");
@@ -1007,6 +1011,7 @@ static int __devinit fs_enet_probe(struct platform_device *ofdev)
struct fs_platform_info *fpi;
const u32 *data;
const u8 *mac_addr;
+ const char *phy_connection_type;
int privsize, len, ret = -ENODEV;
match = of_match_device(fs_enet_match, &ofdev->dev);
@@ -1035,6 +1040,13 @@ static int __devinit fs_enet_probe(struct platform_device *ofdev)
NULL)))
goto out_free_fpi;
+ if (of_device_is_compatible(ofdev->dev.of_node, "fsl,mpc5125-fec")) {
+ phy_connection_type = of_get_property(ofdev->dev.of_node,
+ "phy-connection-type", NULL);
+ if (phy_connection_type && !strcmp("rmii", phy_connection_type))
+ fpi->use_rmii = 1;
+ }
+
privsize = sizeof(*fep) +
sizeof(struct sk_buff **) *
(fpi->rx_ring + fpi->tx_ring);
@@ -1150,6 +1162,10 @@ static struct of_device_id fs_enet_match[] = {
.compatible = "fsl,mpc5121-fec",
.data = (void *)&fs_fec_ops,
},
+ {
+ .compatible = "fsl,mpc5125-fec",
+ .data = (void *)&fs_fec_ops,
+ },
#else
{
.compatible = "fsl,pq1-fec-enet",
diff --git a/drivers/net/ethernet/freescale/fs_enet/mac-fec.c b/drivers/net/ethernet/freescale/fs_enet/mac-fec.c
index b9fbc83..9ae6cdb 100644
--- a/drivers/net/ethernet/freescale/fs_enet/mac-fec.c
+++ b/drivers/net/ethernet/freescale/fs_enet/mac-fec.c
@@ -322,10 +322,11 @@ static void restart(struct net_device *dev)
FW(fecp, r_cntrl, FEC_RCNTRL_MII_MODE); /* MII enable */
#else
/*
- * Only set MII mode - do not touch maximum frame length
+ * Only set MII/RMII mode - do not touch maximum frame length
* configured before.
*/
- FS(fecp, r_cntrl, FEC_RCNTRL_MII_MODE);
+ FS(fecp, r_cntrl, fpi->use_rmii ?
+ FEC_RCNTRL_RMII_MODE : FEC_RCNTRL_MII_MODE);
#endif
/*
* adjust to duplex mode
@@ -381,7 +382,9 @@ static void stop(struct net_device *dev)
/* shut down FEC1? that's where the mii bus is */
if (fpi->has_phy) {
- FS(fecp, r_cntrl, FEC_RCNTRL_MII_MODE); /* MII enable */
+ FS(fecp, r_cntrl, fpi->use_rmii ?
+ FEC_RCNTRL_RMII_MODE :
+ FEC_RCNTRL_MII_MODE); /* MII/RMII enable */
FS(fecp, ecntrl, FEC_ECNTRL_PINMUX | FEC_ECNTRL_ETHER_EN);
FW(fecp, ievent, FEC_ENET_MII);
FW(fecp, mii_speed, feci->mii_speed);
--
1.7.7.6
^ permalink raw reply related
* Re: e1000e interface hang on 82574L
From: Nix @ 2012-03-17 23:50 UTC (permalink / raw)
To: Chris Boot; +Cc: e1000-devel@lists.sourceforge.net, netdev, lkml
In-Reply-To: <4F64CFCB.7060702@bootc.net>
On 17 Mar 2012, Chris Boot verbalised:
> Most notably it appears as though MSI-X is not enabled on the
> Supermicro, and ASPM L1 is. There appears to be no difference on the
> Supermicro as to the MSI-X status when booting with IntMode=1,1 compared
> to without it.
This bug is an ASPM bug, not an MSI bug, and has been present in the
in-kernel drivers since something like 2.6.36. I reported it a rather
long time ago to the e1000e bugzilla:
<http://sourceforge.net/tracker/index.php?func=detail&aid=3170405&group_id=42302&atid=447449>
but then I got a severe attack of forgetfulness and forgot what bz it
was on until this post prodded me into finding it again. (And then
kernel.org was penetrated and I didn't even bother looking, because of
course I reported it to the offlined kernel bz, right? No, I didn't.)
I really should follow up on it now and ask the kernel PCI hackers to
suggest reasons why ASPM might be getting magically re-enabled at around
the same time as the interface is brought up. (Disabling ASPM via setpci
at boot doesn't help if the interface hasn't stabilized before that
point.)
I haven't done much printf()-scattering to try to track it down because
rebooting this machine is quite annoying: it's the heart of my network,
my damn-near-everything-server and the machine on which all my work
virtual machines run, so rebooting it means disappearing from work for
some time while the reboot happens... (but of course this is a really
pathetic excuse because I could have devoted a weekend to it or
something. So add laziness to my sins.)
So currently I'm doing
setpci -s 02:00.0 CAP_EXP+10.b=40
setpci -s 03:00.0 CAP_EXP+10.b=40
in a root shell to force ASPM off on my two 82574Ls after every boot. It
is quite annoying, but 'solves' the problem (for a very crap value of
'solves').
--
NULL && (void)
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2012-03-18 0:53 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) icmp6_dst_alloc() returns NULL instead of ERR_PTR() leading to
crashes, particularly during shutdown. Reported by Dave
Jones and fixed by Eric Dumazet.
2) hyperv and wimax/i2400m return NETDEV_TX_BUSY when they have
already freed the SKB, which causes crashes as to the caller
this means requeue the packet. Fixes from Eric Dumazet.
3) usbnet driver doesn't allocate the right amount of headroom
on fresh RX SKBs, fix from Eric Dumazet.
4) Fix regression in ip6_mc_find_dev_rcu(), as an RCU lookup it
abolutely should not take a reference to 'dev', this leads
to leaks. Fix from RonQing Li.
5) Fix netfilter ctnetlink race between delete and timeout
expiration. From Pablo Neira Ayuso.
6) Revert SFQ change which causes regressions, specifically queueing
to tail can lead to unavoidable flow starvation. From Eric
Dumazet.
7) Fix a memory leak and a crash on corrupt firmware files in bnx2x,
from Michal Schmidt.
Please pull, thanks a lot!
The following changes since commit cb1ecf25a84aec8c9d1fc6ad0c78adf4fd8335de:
Merge branch 'akpm' (more patches from Andrew) (2012-03-16 17:14:55 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
Eric Dumazet (5):
ipv6: fix icmp6_dst_alloc()
sch_sfq: revert dont put new flow at the end of flows
net/usbnet: reserve headroom on rx skbs
net/hyperv: fix erroneous NETDEV_TX_BUSY use
wimax/i2400m: fix erroneous NETDEV_TX_BUSY use
Michal Schmidt (2):
bnx2x: fix a crash on corrupt firmware file
bnx2x: fix memory leak in bnx2x_init_firmware()
Pablo Neira Ayuso (1):
netfilter: ctnetlink: fix race between delete and timeout expiration
RongQing.Li (1):
ipv6: Don't dev_hold(dev) in ip6_mc_find_dev_rcu.
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 51 +++++++++++-----------
drivers/net/hyperv/netvsc_drv.c | 4 +-
drivers/net/usb/usbnet.c | 4 +-
drivers/net/wimax/i2400m/netdev.c | 30 ++++--------
net/ipv6/mcast.c | 1 -
net/ipv6/route.c | 2 +-
net/netfilter/nf_conntrack_netlink.c | 23 +++++-----
net/sched/sch_sfq.c | 6 ++-
8 files changed, 57 insertions(+), 64 deletions(-)
^ permalink raw reply
* Re: [PATCH 2/2] drivers: net: Remove unnecessary line continuations
From: Geoff Levand @ 2012-03-18 1:57 UTC (permalink / raw)
To: Joe Perches
Cc: Ishizaki Kou, Jens Osterkamp, Samuel Ortiz, Wolfgang Grandegger,
Marc Kleine-Budde, linux-can, netdev, linux-kernel, cbe-oss-dev
In-Reply-To: <67ad900b6f6451b5b28b004def471c9a41b1ee24.1332011552.git.joe@perches.com>
On Sat, 2012-03-17 at 12:14 -0700, Joe Perches wrote:
> Line continuations are error prone so just remove them.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/net/ethernet/toshiba/ps3_gelic_net.c | 3 +--
Looks OK for ps3_gelic_net. Thanks.
Acked-by: Geoff Levand <geoff@infradead.org>
^ 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