* 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
* Re: [PATCH] isdn: Return -EINTR in gigaset_start() if locking attempts fails.
From: santosh prasad nayak @ 2012-03-17 15:56 UTC (permalink / raw)
To: David Miller
Cc: hjlipp, tilman, isdn, gigaset307x-common, netdev, linux-media,
kernel-janitors
In-Reply-To: <20120316.231856.1071253468993560433.davem@davemloft.net>
Yes. You are right.
Caller is interpreting 0 in opposite way of normal sequence.
Thats why I misunderstood it.
In general, 0 means success and on error we return -ve.
Here its opposite.
regards
Santosh
On Sat, Mar 17, 2012 at 11:48 AM, David Miller <davem@davemloft.net> wrote:
> From: santosh nayak <santoshprasadnayak@gmail.com>
> Date: Fri, 16 Mar 2012 18:40:13 +0530
>
>> We have 3 callers: gigaset_probe(), gigaset_tty_open() and
>> gigaset_probe(). Each caller tries to free allocated memory
>> if lock fails. This is possible if we returns -EINTR.
>
> Look again at the callers.
>
> They interpret "0" as an error, so your patch would break the driver.
^ permalink raw reply
* [PATCH net-next v3] ipv6: Allocate unique metrics for icmp6 packets to prevent tainting dst metrics
From: Nick Jones @ 2012-03-17 15:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120316.230245.1004014834159539357.davem@davemloft.net>
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: Take care of destroy side, that was neglected in the previous
version, by setting a flag on the dst to indicate its metrics are
unique, thus should be destroyed along with the dst.
v3: declare metrics pointer variable at function top
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..1f217cb 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, 0);
dst_metric_set(&rt->dst, RTAX_HOPLIMIT, 255);
spin_lock_bh(&icmp6_dst_lock);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v14 01/13] sk_run_filter: add BPF_S_ANC_SECCOMP_LD_W
From: Eric Dumazet @ 2012-03-17 13:49 UTC (permalink / raw)
To: Indan Zupancic
Cc: Will Drewry, linux-kernel, linux-arch, linux-doc,
kernel-hardening, netdev, x86, arnd, davem, hpa, mingo, oleg,
peterz, rdunlap, mcgrathr, tglx, luto, eparis, serge.hallyn, djm,
scarybeasts, pmoore, akpm, corbet, markus, coreyb, keescook
In-Reply-To: <7a1c4974e8fbc3b82ead0bfb18224d5b.squirrel@webmail.greenhost.nl>
Le samedi 17 mars 2012 à 21:14 +1100, Indan Zupancic a écrit :
> On Wed, March 14, 2012 19:05, Eric Dumazet wrote:
> > Le mercredi 14 mars 2012 à 08:59 +0100, Indan Zupancic a écrit :
> >
> >> The only remaining question is, is it worth the extra code to release
> >> up to 32kB of unused memory? It seems a waste to not free it, but if
> >> people think it's not worth it then let's just leave it around.
> >
> > Quite frankly its not an issue, given JIT BPF is not yet default
> > enabled.
>
> And what if assuming JIT BPF would be default enabled?
>
OK, so here are the reasons why I chose not doing this :
---------------------------------------------------------
1) When I wrote this code, I _wanted_ keeping the original BPF around
for post morterm analysis. When we are 100% confident code is bug free,
we might remove the "BPF source code", but I am not convinced.
2) Most filters are less than 1 Kbytes, and who run thousands of BPF
network filters on a machine ? Do you have real cases ? Because in these
cases, the vmalloc() PAGE granularity might be a problem anyway.
Some filters are setup for a very short period of time...
(tcpdump for example setup a "ret 0" at the very beginning of a capture
). Doing the extra kmalloc()/copy/kfree() is a loss.
tcpdump -n -s 0 -c 1000 arp
[29211.083449] JIT code: ffffffffa0cbe000: 31 c0 c3
[29211.083481] flen=4 proglen=55 pass=3 image=ffffffffa0cc0000
[29211.083487] JIT code: ffffffffa0cc0000: 55 48 89 e5 48 83 ec 60 48 89 5d f8 44 8b 4f 68
[29211.083494] JIT code: ffffffffa0cc0010: 44 2b 4f 6c 4c 8b 87 e0 00 00 00 be 0c 00 00 00
[29211.083500] JIT code: ffffffffa0cc0020: e8 04 32 38 e0 3d 06 08 00 00 75 07 b8 ff ff 00
[29211.083506] JIT code: ffffffffa0cc0030: 00 eb 02 31 c0 c9 c3
> The current JIT doesn't handle negative offsets: The stuff that's handled
> by __load_pointer(). Easiest solution would be to make it non-static and
> call it instead of doing bpf_error. I guess __load_pointer was added later
> and the JIT code didn't get updated.
I dont think so, check git history if you want :)
>
> But gcc refuses to inline load_pointer, instead it inlines __load_pointer
> and does the important checks first. Considering the current assembly code
> does a call too, it could as well call load_pointer() directly. That would
> save a lot of assembly code, handle all negative cases too and be pretty
> much the same speed. The only question is if this slow down some other
> archs than x86. What do you think?
You miss the point : 99.999 % of offsets are positive in filters.
Best is to not call load_pointer() and only call skb_copy_bits() if the
data is not in skb head, but in some fragment.
I dont know, I never had to use negative offsets in my own filters.
So in the BPF JIT I said : If we have a negative offset in a filter,
just disable JIT code completely for this filter (lines 478-479).
Same for fancy instructions like BPF_S_ANC_NLATTR /
BPF_S_ANC_NLATTR_NEST
Show me a real use first.
I am pragmatic : I spend time coding stuff if there is a real need.
>
> The EMIT_COND_JMP(f_op, f_offset); should be in an else case, otherwise
> it's superfluous. It's a harmless bug though. I haven't spotted anything
> else yet.
Its not superflous, see my comment at the end of this mail.
>
> You can get rid of all the "if (is_imm8(offsetof(struct sk_buff, len)))"
> code by making sure everything is near: Somewhere at the start, just
> add 127 to %rdi and a BUILD_BUG_ON(sizeof(struct sk_buff) > 255).
>
This code is optimized away by the compiler, you know that ?
Adding "add 127 to rdi" is one more instruction, adding dependencies and
making out slow path code more complex (calls to skb_copy_bits() in
bpf_jit.S ...). Thats a bad idea.
> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index 7c1b765..7e0f575 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -581,8 +581,9 @@ cond_branch: f_offset = addrs[i + filter[i].jf] - addrs[i];
> if (filter[i].jf)
> EMIT_JMP(f_offset);
> break;
> + } else {
> + EMIT_COND_JMP(f_op, f_offset);
> }
> - EMIT_COND_JMP(f_op, f_offset);
> break;
> default:
> /* hmm, too complex filter, give up with jit compiler */
>
>
>
I see no change in your patch in the code generation.
if (filter[i].jt == 0), we want to EMIT_COND_JMP(f_op, f_offset);
because we know at this point that filter[i].jf != 0) [ line 536 ]
if (filter[i].jt != 0), the break; in line 583 prevents the
EMIT_COND_JMP(f_op, f_offset);
Thanks !
^ permalink raw reply
* [PATCH RFC 8/8] davinci_emac: Support the get_ts_info ethtool method.
From: Richard Cochran @ 2012-03-17 12:12 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Ben Hutchings
In-Reply-To: <cover.1331983685.git.richardcochran@gmail.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
drivers/net/ethernet/ti/davinci_emac.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 174a334..155a178 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -613,6 +613,15 @@ static int emac_set_coalesce(struct net_device *ndev,
}
+static int emac_get_ts_info(struct net_device *nd, struct ethtool_ts_info *info)
+{
+ info->so_timestamping =
+ SOF_TIMESTAMPING_TX_SOFTWARE |
+ SOF_TIMESTAMPING_RX_SOFTWARE |
+ SOF_TIMESTAMPING_SOFTWARE;
+ info->phc_index = -1;
+ return 0;
+}
/**
* ethtool_ops: DaVinci EMAC Ethtool structure
@@ -627,6 +636,7 @@ static const struct ethtool_ops ethtool_ops = {
.get_link = ethtool_op_get_link,
.get_coalesce = emac_get_coalesce,
.set_coalesce = emac_set_coalesce,
+ .get_ts_info = emac_get_ts_info,
};
/**
--
1.7.2.5
^ permalink raw reply related
* [PATCH RFC 7/8] dp83640: Support the get_ts_info ethtool method.
From: Richard Cochran @ 2012-03-17 12:12 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Ben Hutchings
In-Reply-To: <cover.1331983685.git.richardcochran@gmail.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
drivers/net/phy/dp83640.c | 31 +++++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index dd7ae19..940b290 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -1215,6 +1215,36 @@ static void dp83640_txtstamp(struct phy_device *phydev,
}
}
+static int dp83640_ts_info(struct phy_device *dev, struct ethtool_ts_info *info)
+{
+ struct dp83640_private *dp83640 = dev->priv;
+
+ info->so_timestamping =
+ SOF_TIMESTAMPING_TX_HARDWARE |
+ SOF_TIMESTAMPING_RX_HARDWARE |
+ SOF_TIMESTAMPING_RAW_HARDWARE;
+ info->phc_index = ptp_clock_index(dp83640->clock->ptp_clock);
+ info->tx_types =
+ (1 << HWTSTAMP_TX_OFF) |
+ (1 << HWTSTAMP_TX_ON) |
+ (1 << HWTSTAMP_TX_ONESTEP_SYNC);
+ info->rx_filters =
+ (1 << HWTSTAMP_FILTER_NONE) |
+ (1 << HWTSTAMP_FILTER_PTP_V1_L4_EVENT) |
+ (1 << HWTSTAMP_FILTER_PTP_V1_L4_SYNC) |
+ (1 << HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) |
+ (1 << HWTSTAMP_FILTER_PTP_V2_L4_EVENT) |
+ (1 << HWTSTAMP_FILTER_PTP_V2_L4_SYNC) |
+ (1 << HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) |
+ (1 << HWTSTAMP_FILTER_PTP_V2_L2_EVENT) |
+ (1 << HWTSTAMP_FILTER_PTP_V2_L2_SYNC) |
+ (1 << HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) |
+ (1 << HWTSTAMP_FILTER_PTP_V2_EVENT) |
+ (1 << HWTSTAMP_FILTER_PTP_V2_SYNC) |
+ (1 << HWTSTAMP_FILTER_PTP_V2_DELAY_REQ);
+ return 0;
+}
+
static struct phy_driver dp83640_driver = {
.phy_id = DP83640_PHY_ID,
.phy_id_mask = 0xfffffff0,
@@ -1225,6 +1255,7 @@ static struct phy_driver dp83640_driver = {
.remove = dp83640_remove,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
+ .ts_info = dp83640_ts_info,
.hwtstamp = dp83640_hwtstamp,
.rxtstamp = dp83640_rxtstamp,
.txtstamp = dp83640_txtstamp,
--
1.7.2.5
^ permalink raw reply related
* [PATCH RFC 6/8] ixp4xx_eth: Support the get_ts_info ethtool method.
From: Richard Cochran @ 2012-03-17 12:12 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Ben Hutchings
In-Reply-To: <cover.1331983685.git.richardcochran@gmail.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
arch/arm/mach-ixp4xx/include/mach/ixp46x_ts.h | 3 ++
drivers/net/ethernet/xscale/ixp4xx_eth.c | 29 +++++++++++++++++++++++++
drivers/ptp/ptp_ixp46x.c | 3 ++
3 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-ixp4xx/include/mach/ixp46x_ts.h b/arch/arm/mach-ixp4xx/include/mach/ixp46x_ts.h
index 292d55e..cf03614 100644
--- a/arch/arm/mach-ixp4xx/include/mach/ixp46x_ts.h
+++ b/arch/arm/mach-ixp4xx/include/mach/ixp46x_ts.h
@@ -75,4 +75,7 @@ struct ixp46x_ts_regs {
#define TX_SNAPSHOT_LOCKED (1<<0)
#define RX_SNAPSHOT_LOCKED (1<<1)
+/* The ptp_ixp46x module will set this variable */
+extern int ixp46x_phc_index;
+
#endif
diff --git a/drivers/net/ethernet/xscale/ixp4xx_eth.c b/drivers/net/ethernet/xscale/ixp4xx_eth.c
index 41a8b5a..482648f 100644
--- a/drivers/net/ethernet/xscale/ixp4xx_eth.c
+++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c
@@ -1002,12 +1002,41 @@ static int ixp4xx_nway_reset(struct net_device *dev)
return phy_start_aneg(port->phydev);
}
+int ixp46x_phc_index = -1;
+
+static int ixp4xx_get_ts_info(struct net_device *dev,
+ struct ethtool_ts_info *info)
+{
+ if (!cpu_is_ixp46x()) {
+ info->so_timestamping =
+ SOF_TIMESTAMPING_TX_SOFTWARE |
+ SOF_TIMESTAMPING_RX_SOFTWARE |
+ SOF_TIMESTAMPING_SOFTWARE;
+ info->phc_index = -1;
+ return 0;
+ }
+ info->so_timestamping =
+ SOF_TIMESTAMPING_TX_HARDWARE |
+ SOF_TIMESTAMPING_RX_HARDWARE |
+ SOF_TIMESTAMPING_RAW_HARDWARE;
+ info->phc_index = ixp46x_phc_index;
+ info->tx_types =
+ (1 << HWTSTAMP_TX_OFF) |
+ (1 << HWTSTAMP_TX_ON);
+ info->rx_filters =
+ (1 << HWTSTAMP_FILTER_NONE) |
+ (1 << HWTSTAMP_FILTER_PTP_V1_L4_SYNC) |
+ (1 << HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ);
+ return 0;
+}
+
static const struct ethtool_ops ixp4xx_ethtool_ops = {
.get_drvinfo = ixp4xx_get_drvinfo,
.get_settings = ixp4xx_get_settings,
.set_settings = ixp4xx_set_settings,
.nway_reset = ixp4xx_nway_reset,
.get_link = ethtool_op_get_link,
+ .get_ts_info = ixp4xx_get_ts_info,
};
diff --git a/drivers/ptp/ptp_ixp46x.c b/drivers/ptp/ptp_ixp46x.c
index 6f2782b..9d13a71 100644
--- a/drivers/ptp/ptp_ixp46x.c
+++ b/drivers/ptp/ptp_ixp46x.c
@@ -284,6 +284,7 @@ static void __exit ptp_ixp_exit(void)
{
free_irq(MASTER_IRQ, &ixp_clock);
free_irq(SLAVE_IRQ, &ixp_clock);
+ ixp46x_phc_clock = -1;
ptp_clock_unregister(ixp_clock.ptp_clock);
}
@@ -302,6 +303,8 @@ static int __init ptp_ixp_init(void)
if (IS_ERR(ixp_clock.ptp_clock))
return PTR_ERR(ixp_clock.ptp_clock);
+ ixp46x_phc_clock = ptp_clock_index(ixp_clock.ptp_clock);
+
__raw_writel(DEFAULT_ADDEND, &ixp_clock.regs->addend);
__raw_writel(1, &ixp_clock.regs->trgt_lo);
__raw_writel(0, &ixp_clock.regs->trgt_hi);
--
1.7.2.5
^ permalink raw reply related
* [PATCH RFC 5/8] gianfar: Support the get_ts_info ethtool method.
From: Richard Cochran @ 2012-03-17 12:12 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Ben Hutchings
In-Reply-To: <cover.1331983685.git.richardcochran@gmail.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
drivers/net/ethernet/freescale/gianfar.h | 3 ++
drivers/net/ethernet/freescale/gianfar_ethtool.c | 29 ++++++++++++++++++++++
drivers/net/ethernet/freescale/gianfar_ptp.c | 2 +
3 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.h b/drivers/net/ethernet/freescale/gianfar.h
index 4fe0f34..e1829e2 100644
--- a/drivers/net/ethernet/freescale/gianfar.h
+++ b/drivers/net/ethernet/freescale/gianfar.h
@@ -1213,4 +1213,7 @@ struct filer_table {
struct gfar_filer_entry fe[MAX_FILER_CACHE_IDX + 20];
};
+/* The gianfar_ptp module will set this variable */
+extern int gfar_phc_index;
+
#endif /* __GIANFAR_H */
diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c
index 5a78d55..3115c4a 100644
--- a/drivers/net/ethernet/freescale/gianfar_ethtool.c
+++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c
@@ -1739,6 +1739,34 @@ static int gfar_get_nfc(struct net_device *dev, struct ethtool_rxnfc *cmd,
return ret;
}
+int gfar_phc_index = -1;
+
+static int gfar_get_ts_info(struct net_device *dev,
+ struct ethtool_ts_info *info)
+{
+ struct gfar_private *priv = netdev_priv(dev);
+
+ if (!(priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER)) {
+ info->so_timestamping =
+ SOF_TIMESTAMPING_RX_SOFTWARE |
+ SOF_TIMESTAMPING_SOFTWARE;
+ info->phc_index = -1;
+ return 0;
+ }
+ info->so_timestamping =
+ SOF_TIMESTAMPING_TX_HARDWARE |
+ SOF_TIMESTAMPING_RX_HARDWARE |
+ SOF_TIMESTAMPING_RAW_HARDWARE;
+ info->phc_index = gfar_phc_index;
+ info->tx_types =
+ (1 << HWTSTAMP_TX_OFF) |
+ (1 << HWTSTAMP_TX_ON);
+ info->rx_filters =
+ (1 << HWTSTAMP_FILTER_NONE) |
+ (1 << HWTSTAMP_FILTER_ALL);
+ return 0;
+}
+
const struct ethtool_ops gfar_ethtool_ops = {
.get_settings = gfar_gsettings,
.set_settings = gfar_ssettings,
@@ -1761,4 +1789,5 @@ const struct ethtool_ops gfar_ethtool_ops = {
#endif
.set_rxnfc = gfar_set_nfc,
.get_rxnfc = gfar_get_nfc,
+ .get_ts_info = gfar_get_ts_info,
};
diff --git a/drivers/net/ethernet/freescale/gianfar_ptp.c b/drivers/net/ethernet/freescale/gianfar_ptp.c
index 5fd620b..c08e5d4 100644
--- a/drivers/net/ethernet/freescale/gianfar_ptp.c
+++ b/drivers/net/ethernet/freescale/gianfar_ptp.c
@@ -515,6 +515,7 @@ static int gianfar_ptp_probe(struct platform_device *dev)
err = PTR_ERR(etsects->clock);
goto no_clock;
}
+ gfar_phc_clock = ptp_clock_index(etsects->clock);
dev_set_drvdata(&dev->dev, etsects);
@@ -538,6 +539,7 @@ static int gianfar_ptp_remove(struct platform_device *dev)
gfar_write(&etsects->regs->tmr_temask, 0);
gfar_write(&etsects->regs->tmr_ctrl, 0);
+ gfar_phc_clock = -1;
ptp_clock_unregister(etsects->clock);
iounmap(etsects->regs);
release_resource(etsects->rsrc);
--
1.7.2.5
^ permalink raw reply related
* [PATCH RFC 4/8] igb: Support the get_ts_info ethtool method.
From: Richard Cochran @ 2012-03-17 12:12 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Ben Hutchings
In-Reply-To: <cover.1331983685.git.richardcochran@gmail.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
drivers/net/ethernet/intel/igb/igb_ethtool.c | 31 ++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index e10821a..245fec0 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -2182,6 +2182,36 @@ static void igb_ethtool_complete(struct net_device *netdev)
pm_runtime_put(&adapter->pdev->dev);
}
+static int igb_ethtool_get_ts_info(struct net_device *dev,
+ struct ethtool_ts_info *info)
+{
+ struct igb_adapter *adapter = netdev_priv(dev);
+
+ info->so_timestamping =
+ SOF_TIMESTAMPING_TX_HARDWARE |
+ SOF_TIMESTAMPING_RX_HARDWARE |
+ SOF_TIMESTAMPING_RAW_HARDWARE;
+
+ if (adapter->ptp_clock)
+ info->phc_index = ptp_clock_index(adapter->ptp_clock);
+ else
+ info->phc_index = -1;
+
+ info->tx_types =
+ (1 << HWTSTAMP_TX_OFF) |
+ (1 << HWTSTAMP_TX_ON);
+
+ info->rx_filters =
+ (1 << HWTSTAMP_FILTER_NONE) |
+ (1 << HWTSTAMP_FILTER_ALL) |
+ (1 << HWTSTAMP_FILTER_SOME) |
+ (1 << HWTSTAMP_FILTER_PTP_V1_L4_SYNC) |
+ (1 << HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) |
+ (1 << HWTSTAMP_FILTER_PTP_V2_EVENT);
+
+ return 0;
+}
+
static const struct ethtool_ops igb_ethtool_ops = {
.get_settings = igb_get_settings,
.set_settings = igb_set_settings,
@@ -2210,6 +2240,7 @@ static const struct ethtool_ops igb_ethtool_ops = {
.set_coalesce = igb_set_coalesce,
.begin = igb_ethtool_begin,
.complete = igb_ethtool_complete,
+ .get_ts_info = igb_ethtool_get_ts_info,
};
void igb_set_ethtool_ops(struct net_device *netdev)
--
1.7.2.5
^ permalink raw reply related
* [PATCH RFC 3/8] bfin_mac: Support the get_ts_info ethtool method.
From: Richard Cochran @ 2012-03-17 12:12 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Ben Hutchings
In-Reply-To: <cover.1331983685.git.richardcochran@gmail.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
drivers/net/ethernet/adi/bfin_mac.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/adi/bfin_mac.c b/drivers/net/ethernet/adi/bfin_mac.c
index ab4daec..db22278 100644
--- a/drivers/net/ethernet/adi/bfin_mac.c
+++ b/drivers/net/ethernet/adi/bfin_mac.c
@@ -548,6 +548,25 @@ static int bfin_mac_ethtool_setwol(struct net_device *dev,
return 0;
}
+static int bfin_mac_ethtool_get_ts_info(struct net_device *dev,
+ struct ethtool_ts_info *info);
+{
+ info->so_timestamping =
+ SOF_TIMESTAMPING_TX_HARDWARE |
+ SOF_TIMESTAMPING_RX_HARDWARE |
+ SOF_TIMESTAMPING_SYS_HARDWARE;
+ info->phc_index = -1;
+ info->tx_types =
+ (1 << HWTSTAMP_TX_OFF) |
+ (1 << HWTSTAMP_TX_ON);
+ info->rx_filters =
+ (1 << HWTSTAMP_FILTER_NONE) |
+ (1 << HWTSTAMP_FILTER_PTP_V1_L4_EVENT) |
+ (1 << HWTSTAMP_FILTER_PTP_V2_L2_EVENT) |
+ (1 << HWTSTAMP_FILTER_PTP_V2_L4_EVENT);
+ return 0;
+}
+
static const struct ethtool_ops bfin_mac_ethtool_ops = {
.get_settings = bfin_mac_ethtool_getsettings,
.set_settings = bfin_mac_ethtool_setsettings,
@@ -555,6 +574,7 @@ static const struct ethtool_ops bfin_mac_ethtool_ops = {
.get_drvinfo = bfin_mac_ethtool_getdrvinfo,
.get_wol = bfin_mac_ethtool_getwol,
.set_wol = bfin_mac_ethtool_setwol,
+ .get_ts_info = bfin_mac_ethtool_get_ts_info,
};
/**************************************************************************/
--
1.7.2.5
^ permalink raw reply related
* [PATCH RFC 2/8] ethtool: Introduce a method for getting time stamping capabilities.
From: Richard Cochran @ 2012-03-17 12:12 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Ben Hutchings
In-Reply-To: <cover.1331983685.git.richardcochran@gmail.com>
This commit adds a new ethtool ioctl that exposes the SO_TIMESTAMPING
capabilities of a network interface. In addition, user space programs
can use this ioctl to discover the PTP Hardware Clock (PHC) device
associated with the interface.
Since software receive time stamps are handled by the stack, the generic
ethtool code can answer the query correctly in case the MAC or PHY
drivers lack special time stamping features.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
include/linux/ethtool.h | 20 ++++++++++++++++++++
include/linux/phy.h | 3 +++
net/core/ethtool.c | 36 ++++++++++++++++++++++++++++++++++++
3 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index e1d9e0e..72ffda9 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -726,6 +726,24 @@ struct ethtool_sfeatures {
struct ethtool_set_features_block features[0];
};
+/**
+ * struct ethtool_ts_info - holds a device's timestamping and PHC association
+ * @cmd: command number = %ETHTOOL_GET_TS_INFO
+ * @so_timestamping: bit mask of SO_TIMESTAMPING modes supported by the device
+ * @phc_index: device index of the associated PHC, or -1 if there is none
+ * @tx_types: bit mask of hwtstamp_tx_types modes supported by the device
+ * @rx_filters: bit mask of hwtstamp_rx_filters modes supported by the device
+ */
+struct ethtool_ts_info {
+ __u32 cmd;
+ __u32 so_timestamping;
+ __s32 phc_index;
+ __u32 tx_types;
+ __u32 tx_reserved[3];
+ __u32 rx_filters;
+ __u32 rx_reserved[3];
+};
+
/*
* %ETHTOOL_SFEATURES changes features present in features[].valid to the
* values of corresponding bits in features[].requested. Bits in .requested
@@ -955,6 +973,7 @@ struct ethtool_ops {
int (*get_dump_data)(struct net_device *,
struct ethtool_dump *, void *);
int (*set_dump)(struct net_device *, struct ethtool_dump *);
+ int (*get_ts_info)(struct net_device *, struct ethtool_ts_info *);
};
#endif /* __KERNEL__ */
@@ -1029,6 +1048,7 @@ struct ethtool_ops {
#define ETHTOOL_SET_DUMP 0x0000003e /* Set dump settings */
#define ETHTOOL_GET_DUMP_FLAG 0x0000003f /* Get dump settings */
#define ETHTOOL_GET_DUMP_DATA 0x00000040 /* Get dump data */
+#define ETHTOOL_GET_TS_INFO 0x00000041 /* Get time stamping and PHC info */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/include/linux/phy.h b/include/linux/phy.h
index c599f7ec..497b5c0 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -411,6 +411,9 @@ struct phy_driver {
/* Clears up any memory if needed */
void (*remove)(struct phy_device *phydev);
+ /* Handles ethtool queries for hardware time stamping. */
+ int (*ts_info)(struct phy_device *phydev, struct ethtool_ts_info *ti);
+
/* Handles SIOCSHWTSTAMP ioctl for hardware time stamping. */
int (*hwtstamp)(struct phy_device *phydev, struct ifreq *ifr);
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 6d6d7d2..d6eff4b 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -17,6 +17,8 @@
#include <linux/errno.h>
#include <linux/ethtool.h>
#include <linux/netdevice.h>
+#include <linux/net_tstamp.h>
+#include <linux/phy.h>
#include <linux/bitops.h>
#include <linux/uaccess.h>
#include <linux/vmalloc.h>
@@ -1278,6 +1280,37 @@ out:
return ret;
}
+static int ethtool_get_ts_info(struct net_device *dev, void __user *useraddr)
+{
+ int err = 0;
+ struct ethtool_ts_info info;
+ const struct ethtool_ops *ops = dev->ethtool_ops;
+ struct phy_device *phydev = dev->phydev;
+
+ memset(&info, 0, sizeof(info));
+ info.cmd = ETHTOOL_GET_TS_INFO;
+
+ if (phydev && phydev->drv && phydev->drv->ts_info)
+ err = phydev->drv->ts_info(phydev, &info);
+
+ else if (dev->ethtool_ops->get_ts_info)
+ err = ops->get_ts_info(dev, &info);
+ else {
+ info.so_timestamping =
+ SOF_TIMESTAMPING_RX_SOFTWARE |
+ SOF_TIMESTAMPING_SOFTWARE;
+ info.phc_index = -1;
+ }
+
+ if (err)
+ return err;
+
+ if (copy_to_user(useraddr, &info, sizeof(info)))
+ err = -EFAULT;
+
+ return err;
+}
+
/* The main entry point in this file. Called from net/core/dev.c */
int dev_ethtool(struct net *net, struct ifreq *ifr)
@@ -1496,6 +1529,9 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
case ETHTOOL_GET_DUMP_DATA:
rc = ethtool_get_dump_data(dev, useraddr);
break;
+ case ETHTOOL_GET_TS_INFO:
+ rc = ethtool_get_ts_info(dev, useraddr);
+ break;
default:
rc = -EOPNOTSUPP;
}
--
1.7.2.5
^ permalink raw reply related
* [PATCH RFC 1/8] phc: Add a method for obtaining the device index.
From: Richard Cochran @ 2012-03-17 12:12 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Ben Hutchings
In-Reply-To: <cover.1331983685.git.richardcochran@gmail.com>
This commit adds a method that MAC drivers may call in order to find out
the device number of their associated PTP Hardware Clock.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
drivers/ptp/ptp_clock.c | 6 ++++++
include/linux/ptp_clock_kernel.h | 9 +++++++++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
index f519a13..1e528b5 100644
--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -304,6 +304,12 @@ void ptp_clock_event(struct ptp_clock *ptp, struct ptp_clock_event *event)
}
EXPORT_SYMBOL(ptp_clock_event);
+int ptp_clock_index(struct ptp_clock *ptp)
+{
+ return ptp->index;
+}
+EXPORT_SYMBOL(ptp_clock_index);
+
/* module operations */
static void __exit ptp_exit(void)
diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h
index dd2e44f..58008a2 100644
--- a/include/linux/ptp_clock_kernel.h
+++ b/include/linux/ptp_clock_kernel.h
@@ -136,4 +136,13 @@ struct ptp_clock_event {
extern void ptp_clock_event(struct ptp_clock *ptp,
struct ptp_clock_event *event);
+/**
+ * ptp_clock_index() - obtain the device index of a PTP clock
+ *
+ * @ptp: The clock obtained from ptp_clock_register().
+ * @event: Message structure describing the event.
+ */
+
+extern int ptp_clock_index(struct ptp_clock *ptp);
+
#endif
--
1.7.2.5
^ permalink raw reply related
* [PATCH RFC 0/8] ethtool: support time stamping and phc clocks
From: Richard Cochran @ 2012-03-17 12:12 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Ben Hutchings
* Warning - for discussion only, not tested, barely compiled!
Support for SO_TIMESTAMPING of network packets and PTP Hardware Clocks
has been expanding over the last year or two. In an ideal world,
every host would have exactly one PTP hardware clock, and every
Ethernet MAC would support SO_TIMESTAMPING on both the transmit and
receive paths.
However, since we do not yet have full coverage for these features,
user space programs need a way to discover what a given interface
supports in these two areas:
* PTP Hardware Clocks
The relationship between the network interfaces and the (possibly
multiple) PHC devices is not discoverable except by knowing what
hardware you have got and carefully looking into the kernel log.
* SO_TIMESTAMPING
- Receive software time stamps are implemented in the stack
and thus work for all MAC hardware.
- Transmit software time stamps are only supported by a dozen
drivers or so.
- Some special devices support Tx/Rx time stamping in hardware.
- None of this is discoverable except by looking into the kernel
sources.
This series is a draft idea of how to make the hardware and driver
capabilities known to user space via ethtool. Since the PHC code was
first merged, this has become the number one requested new feature.
Patch number 4 applies on top of my recent two igb/phc patches.
Thanks in advance for your comments,
Richard
Richard Cochran (8):
phc: Add a method for obtaining the device index.
ethtool: Introduce a method for getting time stamping capabilities.
bfin_mac: Support the get_ts_info ethtool method.
igb: Support the get_ts_info ethtool method.
gianfar: Support the get_ts_info ethtool method.
ixp4xx_eth: Support the get_ts_info ethtool method.
dp83640: Support the get_ts_info ethtool method.
davinci_emac: Support the get_ts_info ethtool method.
arch/arm/mach-ixp4xx/include/mach/ixp46x_ts.h | 3 ++
drivers/net/ethernet/adi/bfin_mac.c | 20 ++++++++++++
drivers/net/ethernet/freescale/gianfar.h | 3 ++
drivers/net/ethernet/freescale/gianfar_ethtool.c | 29 +++++++++++++++++
drivers/net/ethernet/freescale/gianfar_ptp.c | 2 +
drivers/net/ethernet/intel/igb/igb_ethtool.c | 31 +++++++++++++++++++
drivers/net/ethernet/ti/davinci_emac.c | 10 ++++++
drivers/net/ethernet/xscale/ixp4xx_eth.c | 29 +++++++++++++++++
drivers/net/phy/dp83640.c | 31 +++++++++++++++++++
drivers/ptp/ptp_clock.c | 6 ++++
drivers/ptp/ptp_ixp46x.c | 3 ++
include/linux/ethtool.h | 20 ++++++++++++
include/linux/phy.h | 3 ++
include/linux/ptp_clock_kernel.h | 9 +++++
net/core/ethtool.c | 36 ++++++++++++++++++++++
15 files changed, 235 insertions(+), 0 deletions(-)
--
1.7.2.5
^ permalink raw reply
* Re: linux-3.0.18+r8169+ipv4/tcp forwarding = tso/gso weirdness and performance degration
From: Francois Romieu @ 2012-03-17 11:35 UTC (permalink / raw)
To: Timo Teras; +Cc: Eric Dumazet, Ben Hutchings, netdev
In-Reply-To: <20120317115625.3fc04de4@vostro>
Timo Teras <timo.teras@iki.fi> :
> On Fri, 16 Mar 2012 22:15:57 +0200 Timo Teras <timo.teras@iki.fi> wrote:
[...]
> > Additional pointer to this direction is that one of the "broken" boxes
> > has different PCI ID for the "broken NIC" of the three. The hardware
> > is Jetway daughter board with the three NICs on single board. So it
> > sounds really weird that one of those NICs chips would be from
> > different series. I wonder if the PCI ID and other stuff could have
> > got corrupted in EEPROM or something similar.
Some of my old PCI 8169 show an unpleasant trend to lose config bits and
they can turn into unavailable devices (i.e. all 0xff registers) when
things go really wrong.
> It seems that we have working eeprom reading code in commit 6709fe9a27e4
> "r8169: read MAC address from EEPROM on init (2nd attempt)" which later
> got reverted due to problems. I'm now wondering if those problems were
> actually caused by unrelated issues that got later fixed in 78f1cd02457
> "r8169: fix broken register writes".
I have not tried working with the eeprom again since 024a07bac.
> I wonder if it'd be worth to do the eeprom reading and expose it via
> ethtool so I can compare those.
Yes.
> 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 should have some unfinished VPD stuff somewhere. Will have to dig...
> And maybe re-introduce the reading of the MAC from there on reboot. Or
> if could just do:
> - Cfg9346_Lock = 0x00,
> + Cfg9346_Lock = 0x40,
>
> The 0x40 apparently means "Auto-load: the EEPROM contents will be
> reloaded when PCI RSTB signal is asserted, and will automatically
> resume to normal 0x00 mode after the load".
It's a bit early to tell but I agree it may make some sense with
adequate conditions. I do not want to immediately break platforms
where bios / firmware plays itself games with eeprom reload or such.
See some resurrected r8169 eeprom patch below. I have to leave for work so
it is done in a hurry. It does not seem to crash immediately though:
# for d in 8168d-vb-gr 8102e-vb-gr 8168b-lom netgear; do ethtool -e $d; done
Offset Values
------ ------
0x0000 29 81 ec 10 68 81 ec 10 68 81 04 01 9c 62 00 e0
0x0010 4c 68 00 2c 05 cf c3 ff 04 02 c0 8c 80 02 00 00
0x0020 11 3c 07 00 10 20 76 00 63 01 01 ff 00 27 aa 03
0x0030 02 20 89 7a 80 02 00 20 04 40 20 00 04 40 20 20
0x0040 00 00 20 e1 22 b5 60 00 0a 00 e0 00 68 4c 00 00
0x0050 30 00 00 00 b2 73 75 ea 87 75 7a 39 ca 98 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
Offset Values
------ ------
0x0000 29 81 ec 10 36 81 ec 10 36 81 04 01 3c 62 00 e0
0x0010 4c 36 00 07 05 0f c3 ff 02 14 c1 86 80 02 00 00
0x0020 11 3c 07 00 10 20 76 00 63 01 01 ff 00 27 aa 03
0x0030 02 20 4e 86 80 02 00 20 10 00 21 00 10 00 21 20
0x0040 00 00 80 70 22 1d 80 00 20 00 e0 00 36 4c 00 00
0x0050 07 00 00 00 af eb b5 35 00 00 00 00 00 00 00 00
0x0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Offset Values
------ ------
0x0000 29 81 ec 10 68 81 49 18 68 81 04 01 00 20 00 13
0x0010 8f ea b1 5d 05 df c2 f7 42 00 23 7f 00 10 04 03
0x0020 68 81 ec 10 00 00 00 1a ff ff ff ff ff ff 1f 00
0x0030 00 47 ee 79 10 f0 f0 01 bf 01 00 00 60 00 00 01
0x0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Offset Values
------ ------
0x0000 29 81 ec 10 69 81 85 13 1a 31 20 40 00 a1 00 09
0x0010 5b bd c1 a5 15 0d c2 f7 00 80 00 00 00 00 00 13
0x0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20
0x0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
"netgear" is PCI but its XID is 04000000. I'll swap it this evening.
diff --git a/drivers/net/ethernet/realtek/Kconfig b/drivers/net/ethernet/realtek/Kconfig
index 5821966..039fcc6 100644
--- a/drivers/net/ethernet/realtek/Kconfig
+++ b/drivers/net/ethernet/realtek/Kconfig
@@ -109,6 +109,7 @@ config R8169
select CRC32
select NET_CORE
select MII
+ select EEPROM_93CX6
---help---
Say Y here if you have a Realtek 8169 PCI Gigabit Ethernet adapter.
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 27c358c..b909475 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -28,6 +28,7 @@
#include <linux/firmware.h>
#include <linux/pci-aspm.h>
#include <linux/prefetch.h>
+#include <linux/eeprom_93cx6.h>
#include <asm/system.h>
#include <asm/io.h>
@@ -310,6 +311,7 @@ enum rtl_registers {
#define RXCFG_DMA_SHIFT 8
/* Unlimited maximum PCI burst. */
#define RX_DMA_BURST (7 << RXCFG_DMA_SHIFT)
+#define EEPROM_9356_SELECT (1 << 6)
RxMissed = 0x4c,
Cfg9346 = 0x50,
@@ -450,9 +452,16 @@ enum rtl_register_content {
NPQ = 0x40, /* Poll cmd on the low prio queue */
FSWInt = 0x01, /* Forced software interrupt */
- /* Cfg9346Bits */
- Cfg9346_Lock = 0x00,
+ /* Cfg9346 operating mode register p.23 */
Cfg9346_Unlock = 0xc0,
+ Cfg9346_Prog = 0x80,
+ Cfg9346_Auto = 0x80,
+ Cfg9346_Lock = 0x00,
+ /* Sub-mode bits in Programming or Auto-load mode. */
+ Cfg9346_CS = 0x08, /* Chip Select */
+ Cfg9346_SK = 0x04, /* Serial Data Clock */
+ Cfg9346_DI = 0x02, /* Data In (going into the eeprom) */
+ Cfg9346_DO = 0x01, /* Data Out (coming from the eeprom) */
/* rx_mode_bits */
AcceptErr = 0x20,
@@ -751,6 +760,8 @@ struct rtl8169_private {
} phy_action;
} *rtl_fw;
#define RTL_FIRMWARE_UNKNOWN ERR_PTR(-EAGAIN)
+
+ struct eeprom_93cx6 eeprom;
};
MODULE_AUTHOR("Realtek and the Linux r8169 crew <netdev@vger.kernel.org>");
@@ -1702,6 +1713,58 @@ static int rtl8169_gset_xmii(struct net_device *dev, struct ethtool_cmd *cmd)
return mii_ethtool_gset(&tp->mii, cmd);
}
+static int rtl_get_eeprom_len(struct net_device *dev)
+{
+ struct rtl8169_private *tp = netdev_priv(dev);
+
+ return tp->eeprom.size;
+}
+
+static void eeprom_cmd_start(void __iomem *ioaddr)
+{
+ RTL_W8(Cfg9346, Cfg9346_Prog);
+}
+
+static void eeprom_cmd_end(void __iomem *ioaddr)
+{
+ RTL_W8(Cfg9346, Cfg9346_Lock);
+}
+
+static int rtl_get_eeprom(struct net_device *dev, struct ethtool_eeprom *ee,
+ u8 *data)
+{
+ struct rtl8169_private *tp = netdev_priv(dev);
+ struct eeprom_93cx6 *eeprom = &tp->eeprom;
+ void __iomem *ioaddr = tp->mmio_addr;
+ u32 offset = ee->offset;
+ u32 len = ee->len;
+ u16 reg;
+
+ rtl_lock_work(tp);
+
+ eeprom_cmd_start(ioaddr);
+
+ if (offset & 0x1) {
+ eeprom_93cx6_read(eeprom, offset >> 1, ®);
+ *data++ = reg >> 8;
+ offset++;
+ len--;
+ }
+
+ eeprom_93cx6_multiread(eeprom, offset >> 1, (__le16 *)data, len >> 1);
+
+ if (len & 0x1) {
+ eeprom_93cx6_read(eeprom, (offset >> 1) + (len >> 1) + 1, ®);
+ data[len] = reg;
+ }
+
+ eeprom_cmd_end(ioaddr);
+
+ rtl_unlock_work(tp);
+
+ return 0;
+}
+
static int rtl8169_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{
struct rtl8169_private *tp = netdev_priv(dev);
@@ -1844,6 +1907,8 @@ static const struct ethtool_ops rtl8169_ethtool_ops = {
.get_drvinfo = rtl8169_get_drvinfo,
.get_regs_len = rtl8169_get_regs_len,
.get_link = ethtool_op_get_link,
+ .get_eeprom_len = rtl_get_eeprom_len,
+ .get_eeprom = rtl_get_eeprom,
.get_settings = rtl8169_get_settings,
.set_settings = rtl8169_set_settings,
.get_msglevel = rtl8169_get_msglevel,
@@ -5803,6 +5868,63 @@ static int rtl8169_suspend(struct device *device)
return 0;
}
+static void rtl_93cx6_register_read(struct eeprom_93cx6 *eeprom)
+{
+ struct net_device *dev = eeprom->data;
+ struct rtl8169_private *tp = netdev_priv(dev);
+ void __iomem *ioaddr = tp->mmio_addr;
+ u8 reg;
+
+ reg = RTL_R8(Cfg9346);
+
+ eeprom->reg_data_in = reg & Cfg9346_DI;
+ eeprom->reg_data_out = reg & Cfg9346_DO;
+ eeprom->reg_data_clock = reg & Cfg9346_SK;
+ eeprom->reg_chip_select = reg & Cfg9346_CS;
+}
+
+static void rtl_93cx6_register_write(struct eeprom_93cx6 *eeprom)
+{
+ struct net_device *dev = eeprom->data;
+ struct rtl8169_private *tp = netdev_priv(dev);
+ void __iomem *ioaddr = tp->mmio_addr;
+ u8 reg = Cfg9346_Prog;
+
+ if (eeprom->reg_data_in)
+ reg |= Cfg9346_DI;
+ if (eeprom->reg_data_out)
+ reg |= Cfg9346_DO;
+ if (eeprom->reg_data_clock)
+ reg |= Cfg9346_SK;
+ if (eeprom->reg_chip_select)
+ reg |= Cfg9346_CS;
+
+ RTL_W8(Cfg9346, reg);
+ /* PCI commit */
+ RTL_R8(ChipCmd);
+ /* This is not a posting bug band-aid: the eeprom wants ~250 ns. */
+ ndelay(250);
+}
+
+static void rtl_init_eeprom(struct net_device *dev, struct rtl8169_private *tp)
+{
+ struct eeprom_93cx6 *eeprom = &tp->eeprom;
+ void __iomem *ioaddr = tp->mmio_addr;
+
+ eeprom->data = dev;
+
+ eeprom->register_read = rtl_93cx6_register_read;
+ eeprom->register_write = rtl_93cx6_register_write;
+
+ if (RTL_R32(RxConfig) & EEPROM_9356_SELECT) {
+ eeprom->width = PCI_EEPROM_WIDTH_93C56;
+ eeprom->size = 256;
+ } else {
+ eeprom->width = PCI_EEPROM_WIDTH_93C46;
+ eeprom->size = 128;
+ }
+}
+
static void __rtl8169_resume(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
@@ -6243,6 +6365,8 @@ rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
tp->opts1_mask = (tp->mac_version != RTL_GIGA_MAC_VER_01) ?
~(RxBOVF | RxFOVF) : ~0;
+ rtl_init_eeprom(dev, tp);
+
init_timer(&tp->timer);
tp->timer.data = (unsigned long) dev;
tp->timer.function = rtl8169_phy_timer;
diff --git a/include/linux/eeprom_93cx6.h b/include/linux/eeprom_93cx6.h
index e50f98b..d6e9cef 100644
--- a/include/linux/eeprom_93cx6.h
+++ b/include/linux/eeprom_93cx6.h
@@ -63,6 +63,7 @@ struct eeprom_93cx6 {
void (*register_write)(struct eeprom_93cx6 *eeprom);
int width;
+ int size;
char drive_data;
char reg_data_in;
--
Ueimor
^ permalink raw reply related
* Re: [PATCH net-next 33/34] dmfe: stop using net_device.{base_addr, irq} and convert to __iomem.
From: Francois Romieu @ 2012-03-17 11:31 UTC (permalink / raw)
To: Grant Grundler; +Cc: netdev, David Miller, Grant Grundler
In-Reply-To: <CANEJEGuoaTP1Pjs1yzRkx2uoC6VW2UV2n0Wgspbc38d6qdRBrQ@mail.gmail.com>
Grant Grundler <grantgrundler@gmail.com> :
[...]
> is there any reason you didn't want to directly use iowrite/ioread routines?
I wanted to keep this patch small and easy to review. David suggested doing
the right thing from the start. I'll send an updated version.
> There is a semantic difference between outl and iowrite. Having
> "outl()" source but instead generate an MMIO transaction could lead to
> misunderstanding/bugs about posted MMIO writes. So I'd rather see a
> direct transition to iowrite and just ditch all the inb/outb stuff.
Ok.
> I'm still suffering from jetlag right now and am not able to review
> the rest of the patch now. I'll try to take a look at it tomorrow.
Thanks. No need to hurry until I send an update though.
--
Ueimor
^ permalink raw reply
* Re: [PATCH] net/irda: add clk_prepare/clk_unprepare to pxaficp_ir
From: Philipp Zabel @ 2012-03-17 10:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev, eric.y.miao, haojian.zhuang, samuel
In-Reply-To: <20120316.231047.1919840752101978309.davem@davemloft.net>
On Sat, Mar 17, 2012 at 7:10 AM, David Miller <davem@davemloft.net> wrote:
> From: Philipp Zabel <philipp.zabel@gmail.com>
> Date: Thu, 15 Mar 2012 19:19:29 +0100
>
>> This patch adds clk_prepare/clk_unprepare calls to the pxaficp_ir
>> driver by using the helper functions clk_prepare_enable and
>> clk_disable_unprepare.
>>
>> Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
>
> This is terrible.
>
> So the problem was that clk_enable can't be invoked from atomic
> context, because it wants to take a mutex for some implementation.
>
> Therefore an existing routine with well defined semantics,
> clk_enable(), was turned into a NOP.
>
> And this silently breaks drivers.
>
> Instead of silently breaking things, make direct
> clk_enable()/clk_disable() invocations either result in a compile
> error or a run-time BUG_ON().
I expect that anybody who turns clk_enable/clk_disable into
no-ops for their platform will be sensible enough to take care of this.
The common struct clk framework already keeps a prepare_count
variable and clk_enable does WARN_ON(clk->prepare_count == 0).
In case of PXA, it's the clk_prepare/clk_unprepare calls that are the
no-ops anyway, so thanks for applying.
regards
Philipp
^ permalink raw reply
* Re: [PATCH] isdn: Return -EINTR in gigaset_start() if locking attempts fails.
From: Tilman Schmidt @ 2012-03-17 10:31 UTC (permalink / raw)
To: santosh nayak
Cc: hjlipp, isdn, gigaset307x-common, netdev, linux-media,
kernel-janitors
In-Reply-To: <1331903413-11426-1-git-send-email-santoshprasadnayak@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 745 bytes --]
Am 16.03.2012 14:10, schrieb santosh nayak:
> From: Santosh Nayak <santoshprasadnayak@gmail.com>
>
> If locking attempt was interrupted by a signal then we should
> return -EINTR so that caller can take appropriate action.
NACK.
The return value of gigaset_start(), as documented in its
header comment, is:
* 1 - success, 0 - error
Its callers rely on this. If you want to change it, you must
also change the documentation and the callers accordingly.
In its current form the patch would just break the driver.
Thanks,
Tilman
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: [PATCH v14 01/13] sk_run_filter: add BPF_S_ANC_SECCOMP_LD_W
From: Indan Zupancic @ 2012-03-17 10:14 UTC (permalink / raw)
To: Eric Dumazet
Cc: Will Drewry, linux-kernel, linux-arch, linux-doc,
kernel-hardening, netdev, x86, arnd, davem, hpa, mingo, oleg,
peterz, rdunlap, mcgrathr, tglx, luto, eparis, serge.hallyn, djm,
scarybeasts, pmoore, akpm, corbet, markus, coreyb, keescook
In-Reply-To: <1331712357.2456.58.camel@edumazet-laptop>
On Wed, March 14, 2012 19:05, Eric Dumazet wrote:
> Le mercredi 14 mars 2012 à 08:59 +0100, Indan Zupancic a écrit :
>
>> The only remaining question is, is it worth the extra code to release
>> up to 32kB of unused memory? It seems a waste to not free it, but if
>> people think it's not worth it then let's just leave it around.
>
> Quite frankly its not an issue, given JIT BPF is not yet default
> enabled.
And what if assuming JIT BPF would be default enabled?
> I am not sure all bugs were found and fixed. I would warn users before
> considering using it in production.
>
> If you have time, I would appreciate if you could double check and find
> last bugs in it.
I'll do my best.
The current JIT doesn't handle negative offsets: The stuff that's handled
by __load_pointer(). Easiest solution would be to make it non-static and
call it instead of doing bpf_error. I guess __load_pointer was added later
and the JIT code didn't get updated.
But gcc refuses to inline load_pointer, instead it inlines __load_pointer
and does the important checks first. Considering the current assembly code
does a call too, it could as well call load_pointer() directly. That would
save a lot of assembly code, handle all negative cases too and be pretty
much the same speed. The only question is if this slow down some other
archs than x86. What do you think?
The EMIT_COND_JMP(f_op, f_offset); should be in an else case, otherwise
it's superfluous. It's a harmless bug though. I haven't spotted anything
else yet.
You can get rid of all the "if (is_imm8(offsetof(struct sk_buff, len)))"
code by making sure everything is near: Somewhere at the start, just
add 127 to %rdi and a BUILD_BUG_ON(sizeof(struct sk_buff) > 255).
I'll write some more patches tomorrow.
Greetings,
Indan
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 7c1b765..7e0f575 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -581,8 +581,9 @@ cond_branch: f_offset = addrs[i + filter[i].jf] - addrs[i];
if (filter[i].jf)
EMIT_JMP(f_offset);
break;
+ } else {
+ EMIT_COND_JMP(f_op, f_offset);
}
- EMIT_COND_JMP(f_op, f_offset);
break;
default:
/* hmm, too complex filter, give up with jit compiler */
^ permalink raw reply related
* Partner Needed
From: C Y Ling @ 2012-03-17 7:09 UTC (permalink / raw)
Goodday,
I am Mr. C.Y. Ling, Executive Vice President of CITIC Bank
International, China. I
have a proposal for you in tune of 105 Million Euro, Please reply to
this email
(l_cy@kimo.com) for specific DETAILS.
Warmest,
Mr. C.Y. Ling
----------------------------------------------------------------
Universidade Federal da Bahia - http://www.portal.ufba.br
^ permalink raw reply
* Re: linux-3.0.18+r8169+ipv4/tcp forwarding = tso/gso weirdness and performance degration
From: Timo Teras @ 2012-03-17 9:56 UTC (permalink / raw)
To: Francois Romieu; +Cc: Eric Dumazet, Ben Hutchings, netdev
In-Reply-To: <20120316221557.235f5ffd@vostro>
On Fri, 16 Mar 2012 22:15:57 +0200 Timo Teras <timo.teras@iki.fi> wrote:
> On Thu, 15 Mar 2012 20:11:18 +0100 Francois Romieu
> <romieu@fr.zoreil.com> wrote:
>
> > Timo Teras <timo.teras@iki.fi> :
> > [...]
> > > The other broken box is connected to a HP ProCurve 4202vl-48G, and
> > > the switch is reporting drops due to FCS Rx errors.
> > [...]
> > > So I have two broken pieces of hardware, or there is a driver bug.
> >
> > I'll take blame for any bug in the driver. However many ethernet
> > controllers are and the PCI 8169 is no exception.
>
> Ok.
>
> As a side though, all these devices suffered from the bug I fixed
> earlier. See commit 024a07bac (r8169: fix random mdio_write failures).
> Also, all these devices probably got garbage written to their PHY. So
> I'm wondering if it is possible that it caused some permanent damage?
>
> Would it be possible to dump/compare the related things?
>
> Additional pointer to this direction is that one of the "broken" boxes
> has different PCI ID for the "broken NIC" of the three. The hardware
> is Jetway daughter board with the three NICs on single board. So it
> sounds really weird that one of those NICs chips would be from
> different series. I wonder if the PCI ID and other stuff could have
> got corrupted in EEPROM or something similar.
It seems that we have working eeprom reading code in commit 6709fe9a27e4
"r8169: read MAC address from EEPROM on init (2nd attempt)" which later
got reverted due to problems. I'm now wondering if those problems were
actually caused by unrelated issues that got later fixed in 78f1cd02457
"r8169: fix broken register writes".
I wonder if it'd be worth to do the eeprom reading and expose it via
ethtool so I can compare those. 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?
And maybe re-introduce the reading of the MAC from there on reboot. Or
if could just do:
- Cfg9346_Lock = 0x00,
+ Cfg9346_Lock = 0x40,
The 0x40 apparently means "Auto-load: the EEPROM contents will be
reloaded when PCI RSTB signal is asserted, and will automatically
resume to normal 0x00 mode after the load".
^ permalink raw reply
* [net 3/3] fcoe: use CHECKSUM_UNNECESSARY instead of CHECKSUM_PARTIAL on tx
From: Jeff Kirsher @ 2012-03-17 9:08 UTC (permalink / raw)
To: davem
Cc: Yi Zou, netdev, gospo, sassmann, James E.J. Bottomley,
Robert Love, Jeff Kirsher
In-Reply-To: <1331975292-19521-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Yi Zou <yi.zou@intel.com>
Fix a bug when using 'ethtool -K ethx tx off' to turn off tx ip checksum,
FCoE CRC offload should not be impacte. The skb_checksum_help() is needed
only if it's not FCoE traffic for ip checksum, regardless of ethtool toggling
the tx ip checksum on or off. Instead of using CHECKSUM_PARTIAL, we will
use CHECKSUM_UNNECESSARY as a proper indication to avoid sw ip checksum
on FCoE frames.
Ref. to original discussion thread:
http://patchwork.ozlabs.org/patch/146567/
CC: "James E.J. Bottomley" <JBottomley@parallels.com>
CC: Robert Love <robert.w.love@intel.com>
Signed-off-by: Yi Zou <yi.zou@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/scsi/fcoe/fcoe.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
index e959960..c164890 100644
--- a/drivers/scsi/fcoe/fcoe.c
+++ b/drivers/scsi/fcoe/fcoe.c
@@ -1498,7 +1498,7 @@ static int fcoe_xmit(struct fc_lport *lport, struct fc_frame *fp)
/* crc offload */
if (likely(lport->crc_offload)) {
- skb->ip_summed = CHECKSUM_PARTIAL;
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
skb->csum_start = skb_headroom(skb);
skb->csum_offset = skb->len;
crc = 0;
--
1.7.7.6
^ permalink raw reply related
* [net 2/3] net: do not do gso for CHECKSUM_UNNECESSARY in netif_needs_gso
From: Jeff Kirsher @ 2012-03-17 9:08 UTC (permalink / raw)
To: davem; +Cc: Yi Zou, netdev, gospo, sassmann, Jeff Kirsher
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.
Ref. to original discussion thread:
http://patchwork.ozlabs.org/patch/146567/
Signed-off-by: Yi Zou <yi.zou@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
include/linux/netdevice.h | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 0eac07c..c1b2b5f 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2636,7 +2636,8 @@ static inline int netif_needs_gso(struct sk_buff *skb,
netdev_features_t features)
{
return skb_is_gso(skb) && (!skb_gso_ok(skb, features) ||
- unlikely(skb->ip_summed != CHECKSUM_PARTIAL));
+ unlikely((skb->ip_summed != CHECKSUM_PARTIAL) &&
+ (skb->ip_summed != CHECKSUM_UNNECESSARY)));
}
static inline void netif_set_gso_max_size(struct net_device *dev,
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH v2 2/4] mac80211: Support getting sta_info stats via ethtool.
From: Johannes Berg @ 2012-03-17 9:07 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, netdev
In-Reply-To: <1331927952-8706-2-git-send-email-greearb@candelatech.com>
On Fri, 2012-03-16 at 12:59 -0700, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> This lets ethtool print out stats related to station
> interfaces.
That's kinda misleading -- it makes it print out "stats related to
stations connected to the interface" :-)
johannes
^ permalink raw reply
* [net 1/3] ixgbe: Fix issues with SR-IOV loopback when flow control is disabled
From: Jeff Kirsher @ 2012-03-17 9:07 UTC (permalink / raw)
To: davem; +Cc: Alexander Duyck, netdev, gospo, sassmann, Jeff Kirsher
From: Alexander Duyck <alexander.h.duyck@intel.com>
This patch allows us to avoid a Tx hang when SR-IOV is enabled. This hang
can be triggered by sending small packets at a rate that was triggering Rx
missed errors from the adapter while the internal Tx switch and at least
one VF are enabled.
This was all due to the fact that under heavy stress the Rx FIFO never
drained below the flow control high water mark. This resulted in the Tx
FIFO being head of line blocked due to the fact that it relies on the flow
control high water mark to determine when it is acceptable for the Tx to
place a packet in the Rx FIFO.
The resolution for this is to set the FCRTH value to the RXPBSIZE - 32 so
that even if the ring is almost completely full we can still place Tx
packets on the Rx ring and drop incoming Rx traffic if we do not have
sufficient space available in the Rx FIFO.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index 383b941..7d81bee 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -2011,13 +2011,20 @@ s32 ixgbe_fc_enable_generic(struct ixgbe_hw *hw, s32 packetbuf_num)
IXGBE_WRITE_REG(hw, IXGBE_MFLCN, mflcn_reg);
IXGBE_WRITE_REG(hw, IXGBE_FCCFG, fccfg_reg);
- fcrth = hw->fc.high_water[packetbuf_num] << 10;
fcrtl = hw->fc.low_water << 10;
if (hw->fc.current_mode & ixgbe_fc_tx_pause) {
+ fcrth = hw->fc.high_water[packetbuf_num] << 10;
fcrth |= IXGBE_FCRTH_FCEN;
if (hw->fc.send_xon)
fcrtl |= IXGBE_FCRTL_XONE;
+ } else {
+ /*
+ * If Tx flow control is disabled, set our high water mark
+ * to Rx FIFO size minus 32 in order prevent Tx switch
+ * loopback from stalling on DMA.
+ */
+ fcrth = IXGBE_READ_REG(hw, IXGBE_RXPBSIZE(packetbuf_num)) - 32;
}
IXGBE_WRITE_REG(hw, IXGBE_FCRTH_82599(packetbuf_num), fcrth);
--
1.7.7.6
^ permalink raw reply related
* Re: [net-next 00/12][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-03-17 9:06 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1331974260-6383-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 17 Mar 2012 01:50:48 -0700
> This series of patches contains additions/cleanups to igb and ixgbe.
> There 2 patches for igb & ixgbe which add FX-ALL feature flag and
> sending of custom Ethernet FCS from Ben Greear.
>
> The remaining patches in the series is part three of three to update
> ixgbe. Although it looks like there will be at least one follow on
> patch series complete the update/cleanup of ixgbe.
>
> The following are changes since commit 126a3fd251b244eabd9ab9dcb32b8b6f999c1b91:
> eni: fix driver remove function and driver probe error path.
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Pulled, thanks Jeff.
^ 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