* Re: [PATCH] net/rds: using strlcpy instead of strncpy
From: Ben Hutchings @ 2013-03-05 3:16 UTC (permalink / raw)
To: Chen Gang
Cc: David Laight, venkat.x.venkatsubra, David Miller, rds-devel,
netdev
In-Reply-To: <51355936.3060307@asianux.com>
On Tue, 2013-03-05 at 10:32 +0800, Chen Gang wrote:
> 于 2013年03月05日 02:34, Ben Hutchings 写道:
> > On Mon, 2013-03-04 at 18:32 +0000, Ben Hutchings wrote:
> >> > On Thu, 2013-02-28 at 09:36 +0000, David Laight wrote:
> >>> > >
> >>> > > If the target buffer ends up being copied to userspace that
> >>> > > might lead to random kernel memory being leaked.
> >> >
> >> > Seems it is. The last byte of 'name' is not currently initialised and
> >> > therefore is already leaked to userland.
> >> >
> >> > But it's OK because rds_info_copy() uses memcpy() not __copy_to_user(),
> >> > so SMAP will block this leak. :-)
> > Or not, as kmap() presumably evades that.
>
> is this patch ok, or need improving ?
I think it is wrong, and the code should be changed to do either:
1. Zero-initialise the whole of the name, then use strlcpy().
2. Keep using strncpy(), and also set the last byte of name to 0.
> BTW:
> excuse me, maybe my reply will be late during this week.
> the reason:
> my father had a serious heart disease, and is in hospital.
> during these days, most of my time has to be in hospital.
> (God Bless, and thank Jesus Christ, my father is safe, now).
> within my company (Asianux), I also have something to do.
Best wishes to you both.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net/rds: using strlcpy instead of strncpy
From: Chen Gang @ 2013-03-05 3:32 UTC (permalink / raw)
To: Ben Hutchings
Cc: David Laight, venkat.x.venkatsubra, David Miller, rds-devel,
netdev
In-Reply-To: <1362453419.3768.380.camel@deadeye.wl.decadent.org.uk>
于 2013年03月05日 11:16, Ben Hutchings 写道:
> I think it is wrong, and the code should be changed to do either:
>
> 1. Zero-initialise the whole of the name, then use strlcpy().
> 2. Keep using strncpy(), and also set the last byte of name to 0.
>
I think what I have done is just like your choice "2."
for me, I think they are equal:
- strncpy(ctr.name, names[i], sizeof(ctr.name) - 1);
+ strlcpy(ctr.name, names[i], sizeof(ctr.name));
strncpy(ctr.name, names[i], sizeof(ctr.name) - 1);
+ ctr.name[sizeof(ctr.name) - 1] = '\0';
>> > BTW:
>> > excuse me, maybe my reply will be late during this week.
>> > the reason:
>> > my father had a serious heart disease, and is in hospital.
>> > during these days, most of my time has to be in hospital.
>> > (God Bless, and thank Jesus Christ, my father is safe, now).
>> > within my company (Asianux), I also have something to do.
> Best wishes to you both.
thank you.
:-)
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [PATCH] net/rds: using strlcpy instead of strncpy
From: Ben Hutchings @ 2013-03-05 3:37 UTC (permalink / raw)
To: Chen Gang
Cc: David Laight, venkat.x.venkatsubra, David Miller, rds-devel,
netdev
In-Reply-To: <51356735.4020405@asianux.com>
On Tue, 2013-03-05 at 11:32 +0800, Chen Gang wrote:
> 于 2013年03月05日 11:16, Ben Hutchings 写道:
> > I think it is wrong, and the code should be changed to do either:
> >
> > 1. Zero-initialise the whole of the name, then use strlcpy().
> > 2. Keep using strncpy(), and also set the last byte of name to 0.
> >
>
> I think what I have done is just like your choice "2."
> for me, I think they are equal:
>
> - strncpy(ctr.name, names[i], sizeof(ctr.name) - 1);
> + strlcpy(ctr.name, names[i], sizeof(ctr.name));
>
>
> strncpy(ctr.name, names[i], sizeof(ctr.name) - 1);
> + ctr.name[sizeof(ctr.name) - 1] = '\0';
They are not. strncpy() pads with zeroes to the end of the given buffer
whereas strlcpy() adds only a single zero byte (and truncates if
necessary to fit the zero byte).
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: BUG: IPv4: Attempt to release TCP socket in state 1
From: Cong Wang @ 2013-03-05 3:47 UTC (permalink / raw)
To: dormando; +Cc: linux-kernel, netdev
In-Reply-To: <alpine.DEB.2.02.1303041547080.7811@localhost6.localdomain6>
(Cc'ing the right netdev mailing list...)
On 03/05/2013 08:01 AM, dormando wrote:
> Hi!
>
> I have a (core lockup?) with 3.7.6+ and 3.8.2 which appears to be under
> ixgbe. The machine appears to still be up but network stays in a severely
> hobbled state. Either lagging or not responding to the network at all.
>
> On a new box the hang happens within 8-24 hours of giving it production
> network traffic. On an older machine (6 cores instead of 8, etc) it can
> run for a week or more before hanging.
>
> The hang from 3.7 might be slightly different than 3.8. They seem to be
> mostly the same aside from 3.8 hanging in the GRO path. Don't see anything
> obvious in 3.9-rc1 that would fix it, and haven't tried 3.9-rc1.
>
> I've not yet figured out how to reproduce outside of production (as
> always, sigh). This doesn't seem to happen with 3.6.6, but we have
> different and less frequent kernel panics there.
>
> From 3.7:
>
> [21934.669780] IPv4: Attempt to release TCP socket in state 1
> ffff882785e3db00
> [21969.265883] ------------[ cut here ]------------
> [21969.265898] WARNING: at net/sched/sch_generic.c:255
> dev_watchdog+0x258/0x270()
> [21969.265900] Hardware name: X9DR3-F
> [21969.265902] NETDEV WATCHDOG: eth2 (ixgbe): transmit queue 11 timed out
> [21969.265903] Modules linked in: macvlan bridge ipmi_watchdog
> ipmi_devintf coretemp ghash_clmulni_intel gpio_ich microcode ixgbe sb_edac
> mdio lpc_ich edac_core mei mfd_core ipmi_si ipmi_msghandler isci libsas
> igb
> [21969.265930] Pid: 0, comm: swapper/10 Not tainted 3.7.8 #1
> [21969.265931] Call Trace:
> [21969.265933] <IRQ> [<ffffffff810484ff>] warn_slowpath_common+0x7f/0xc0
> [21969.265945] [<ffffffff815a712e>] ? ip_local_deliver_finish+0xde/0x290
> [21969.265948] [<ffffffff810485f6>] warn_slowpath_fmt+0x46/0x50
> [21969.265950] [<ffffffff815a69b9>] ? ip_rcv_finish+0x119/0x360
> [21969.265953] [<ffffffff8157d538>] dev_watchdog+0x258/0x270
> [21969.265956] [<ffffffff8157d2e0>] ? __netdev_watchdog_up+0x80/0x80
> [21969.265960] [<ffffffff81058349>] call_timer_fn+0x49/0x130
> [21969.265963] [<ffffffff81078f9f>] ? scheduler_tick+0x15f/0x190
> [21969.265965] [<ffffffff81058944>] run_timer_softirq+0x224/0x290
> [21969.265967] [<ffffffff81058066>] ? update_process_times+0x76/0x90
> [21969.265969] [<ffffffff8157d2e0>] ? __netdev_watchdog_up+0x80/0x80
> [21969.265974] [<ffffffff8108b4f4>] ? ktime_get+0x54/0xe0
> [21969.265977] [<ffffffff810509c7>] __do_softirq+0xc7/0x230
> [21969.265990] [<ffffffff816757cc>] call_softirq+0x1c/0x30
> [21969.265995] [<ffffffff81004475>] do_softirq+0x55/0x90
> [21969.265997] [<ffffffff810507c5>] irq_exit+0x85/0xa0
> [21969.265999] [<ffffffff81675dfe>] smp_apic_timer_interrupt+0x6e/0x99
> [21969.266002] [<ffffffff816751ca>] apic_timer_interrupt+0x6a/0x70
> [21969.266003] <EOI> [<ffffffff8166b17a>] ? __schedule+0x3aa/0x750
> [21969.266011] [<ffffffff8100b2ed>] ? mwait_idle+0xad/0x1f0
> [21969.266013] [<ffffffff8100a7a3>] cpu_idle+0xb3/0x100
> [21969.266017] [<ffffffff816632e3>] start_secondary+0x1c9/0x1d0
> [21969.266019] ---[ end trace 0739ad788910e77e ]---
> [21969.266059] ixgbe 0000:83:00.0 eth2: Reset adapter
> [22019.676899] INFO: rcu_sched self-detected stall on CPU { 30} (t=15001
> jiffies)
> [22019.676963] Pid: 0, comm: swapper/30 Tainted: G W 3.7.8 #1
> [22019.676966] Call Trace:
> [22019.676968] <IRQ> [<ffffffff810bb144>]
> rcu_check_callbacks+0x1b4/0x600
> [22019.676985] [<ffffffff8107e1b8>] ? account_system_time+0xe8/0x1e0
> [22019.676988] [<ffffffff81058038>] update_process_times+0x48/0x90
> [22019.676993] [<ffffffff81092aa7>] tick_sched_timer+0x77/0x160
> [22019.677006] [<ffffffff8106f66d>] __run_hrtimer+0x7d/0x1c0
> [22019.677008] [<ffffffff81092a30>] ? tick_setup_sched_timer+0x110/0x110
> [22019.677010] [<ffffffff8106fa26>] hrtimer_interrupt+0xf6/0x230
> [22019.677015] [<ffffffff81675df9>] smp_apic_timer_interrupt+0x69/0x99
> [22019.677018] [<ffffffff816751ca>] apic_timer_interrupt+0x6a/0x70
> [22019.677023] [<ffffffff815afaa0>] ?
> __inet_lookup_established+0xc0/0x280
> [22019.677026] [<ffffffff815a68a0>] ? inet_del_protocol+0x40/0x40
> [22019.677030] [<ffffffff815cc383>] tcp_v4_early_demux+0xa3/0x170
> [22019.677033] [<ffffffff815a69ed>] ip_rcv_finish+0x14d/0x360
> [22019.677035] [<ffffffff815a6f66>] ip_rcv+0x226/0x310
> [22019.677041] [<ffffffff815609f2>] __netif_receive_skb+0x492/0x640
> [22019.677043] [<ffffffff81074209>] ? __wake_up_common+0x59/0x90
> [22019.677051] [<ffffffffa00f284b>] ? ixgbe_poll+0xe3b/0x1140 [ixgbe]
> [22019.677054] [<ffffffff81560c94>] process_backlog+0xf4/0x1e0
> [22019.677056] [<ffffffff815619c5>] net_rx_action+0xf5/0x260
> [22019.677070] [<ffffffff810509c7>] __do_softirq+0xc7/0x230
> [22019.677072] [<ffffffff816757cc>] call_softirq+0x1c/0x30
> [22019.677076] [<ffffffff81004475>] do_softirq+0x55/0x90
> [22019.677078] [<ffffffff810507c5>] irq_exit+0x85/0xa0
> [22019.677080] [<ffffffff81675d16>] do_IRQ+0x66/0xe0
> [22019.677084] [<ffffffff8166c8aa>] common_interrupt+0x6a/0x6a
> [22019.677085] <EOI> [<ffffffff8166b17a>] ? __schedule+0x3aa/0x750
> [22019.677090] [<ffffffff8100b2ed>] ? mwait_idle+0xad/0x1f0
> [22019.677092] [<ffffffff8100a7a3>] cpu_idle+0xb3/0x100
> [22019.677096] [<ffffffff816632e3>] start_secondary+0x1c9/0x1d0
> [22188.695704] INFO: task kworker/10:2:676 blocked for more than 120
> seconds.
> [22188.695750] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message.
> [22188.695807] kworker/10:2 D ffffffff81806e40 0 676 2
> 0x00000000
> [22188.695813] ffff882ff9dadad8 0000000000000046 ffff882ff9082d80
> 00000000000126c0
> [22188.695816] ffff882ff9dadfd8 ffff882ff9dac010 00000000000126c0
> 00000000000126c0
> [22188.695818] ffff882ff9dadfd8 00000000000126c0 ffff882ffb185b00
> ffff882ff9082d80
> [22188.695820] Call Trace:
> [22188.695830] [<ffffffff8166b5e9>] schedule+0x29/0x70
> [22188.695833] [<ffffffff816698e5>] schedule_timeout+0x165/0x200
> [22188.695838] [<ffffffff810796b5>] ? ttwu_do_wakeup+0x45/0x100
> [22188.695840] [<ffffffff810797b9>] ? T.1871+0x49/0x60
> [22188.695843] [<ffffffff8107c28e>] ? try_to_wake_up+0x23e/0x2b0
> [22188.695845] [<ffffffff8166ac58>] wait_for_common+0xc8/0x160
> [22188.695847] [<ffffffff8107c300>] ? try_to_wake_up+0x2b0/0x2b0
> [22188.695852] [<ffffffff810b90c0>] ? rcu_cpu_stall_reset+0x60/0x60
> [22188.695854] [<ffffffff8166adcd>] wait_for_completion+0x1d/0x20
> [22188.695859] [<ffffffff810aed96>] __stop_cpus+0x56/0x80
> [22188.695861] [<ffffffff810b90c0>] ? rcu_cpu_stall_reset+0x60/0x60
> [22188.695864] [<ffffffff810aee0d>] try_stop_cpus+0x4d/0x80
> [22188.695867] [<ffffffff810bb62a>]
> synchronize_sched_expedited+0x9a/0x120
> [22188.695869] [<ffffffff810bb6be>] synchronize_rcu_expedited+0xe/0x10
> [22188.695874] [<ffffffff8155a8e5>] synchronize_net+0x25/0x30
> [22188.695880] [<ffffffff8157dbb4>] dev_deactivate_many+0x254/0x260
> [22188.695882] [<ffffffff8157dbed>] dev_deactivate+0x2d/0x40
> [22188.695886] [<ffffffff8156fff4>] linkwatch_do_dev+0x34/0x60
> [22188.695888] [<ffffffff815701d3>] __linkwatch_run_queue+0xf3/0x1e0
> [22188.695891] [<ffffffff815702e5>] linkwatch_event+0x25/0x30
> [22188.695894] [<ffffffff81064180>] process_one_work+0x160/0x460
> [22188.695896] [<ffffffff815702c0>] ? __linkwatch_run_queue+0x1e0/0x1e0
> [22188.695899] [<ffffffff8106631b>] worker_thread+0x12b/0x3d0
> [22188.695901] [<ffffffff810661f0>] ? manage_workers+0x300/0x300
> [22188.695904] [<ffffffff8106b26e>] kthread+0xce/0xe0
> [22188.695907] [<ffffffff8106b1a0>] ?
> kthread_freezable_should_stop+0x70/0x70
> [22188.695911] [<ffffffff8167475c>] ret_from_fork+0x7c/0xb0
> [22188.695913] [<ffffffff8106b1a0>] ?
> kthread_freezable_should_stop+0x70/0x70
>
> [tons of processes hung in a similar way]
>
> Then every few hundred seconds swapper bails:
>
> [22919.239167] INFO: rcu_sched self-detected stall on CPU { 30} (t=240021
> jiffies)
> [22919.239409] Pid: 0, comm: swapper/30 Tainted: G W 3.7.8 #1
> [22919.239411] Call Trace:
> [22919.239413] <IRQ> [<ffffffff810bb144>]
> rcu_check_callbacks+0x1b4/0x600
> [22919.239430] [<ffffffff8107e1b8>] ? account_system_time+0xe8/0x1e0
> [22919.239434] [<ffffffff81058038>] update_process_times+0x48/0x90
> [22919.239439] [<ffffffff81092aa7>] tick_sched_timer+0x77/0x160
> [22919.239442] [<ffffffff8106f66d>] __run_hrtimer+0x7d/0x1c0
> [22919.239445] [<ffffffff81092a30>] ? tick_setup_sched_timer+0x110/0x110
> [22919.239447] [<ffffffff8106fa26>] hrtimer_interrupt+0xf6/0x230
> [22919.239453] [<ffffffff81675df9>] smp_apic_timer_interrupt+0x69/0x99
> [22919.239455] [<ffffffff816751ca>] apic_timer_interrupt+0x6a/0x70
> [22919.239461] [<ffffffff815afaab>] ?
> __inet_lookup_established+0xcb/0x280
> [22919.239463] [<ffffffff815a68a0>] ? inet_del_protocol+0x40/0x40
> [22919.239468] [<ffffffff815cc383>] tcp_v4_early_demux+0xa3/0x170
> [22919.239470] [<ffffffff815a69ed>] ip_rcv_finish+0x14d/0x360
> [22919.239472] [<ffffffff815a6f66>] ip_rcv+0x226/0x310
> [22919.239478] [<ffffffff815609f2>] __netif_receive_skb+0x492/0x640
> [22919.239481] [<ffffffff81074209>] ? __wake_up_common+0x59/0x90
> [22919.239490] [<ffffffffa00f284b>] ? ixgbe_poll+0xe3b/0x1140 [ixgbe]
> [22919.239493] [<ffffffff81560c94>] process_backlog+0xf4/0x1e0
> [22919.239495] [<ffffffff815619c5>] net_rx_action+0xf5/0x260
> [22919.239499] [<ffffffff810509c7>] __do_softirq+0xc7/0x230
> [22919.239501] [<ffffffff816757cc>] call_softirq+0x1c/0x30
> [22919.239505] [<ffffffff81004475>] do_softirq+0x55/0x90
> [22919.239507] [<ffffffff810507c5>] irq_exit+0x85/0xa0
> [22919.239509] [<ffffffff81675d16>] do_IRQ+0x66/0xe0
> [22919.239513] [<ffffffff8166c8aa>] common_interrupt+0x6a/0x6a
> [22919.239514] <EOI> [<ffffffff8166b17a>] ? __schedule+0x3aa/0x750
> [22919.239520] [<ffffffff8100b2ed>] ? mwait_idle+0xad/0x1f0
> [22919.239522] [<ffffffff8100a7a3>] cpu_idle+0xb3/0x100
> [22919.239526] [<ffffffff816632e3>] start_secondary+0x1c9/0x1d0
> [23099.151590] INFO: rcu_sched self-detected stall on CPU { 30} (t=285025
> jiffies)
> [23099.151823] Pid: 0, comm: swapper/30 Tainted: G W
> [23099.151825] Call Trace:
> [23099.151827] <IRQ> [<ffffffff810bb144>]
> rcu_check_callbacks+0x1b4/0x600
> [23099.151841] [<ffffffff8107e1b8>] ? account_system_time+0xe8/0x1e0
> [23099.151845] [<ffffffff81058038>] update_process_times+0x48/0x90
> [23099.151849] [<ffffffff81092aa7>] tick_sched_timer+0x77/0x160
> [23099.151853] [<ffffffff8106f66d>] __run_hrtimer+0x7d/0x1c0
> [23099.151856] [<ffffffff81092a30>] ? tick_setup_sched_timer+0x110/0x110
> [23099.151857] [<ffffffff8106fa26>] hrtimer_interrupt+0xf6/0x230
> [23099.151863] [<ffffffff81675df9>] smp_apic_timer_interrupt+0x69/0x99
> [23099.151865] [<ffffffff816751ca>] apic_timer_interrupt+0x6a/0x70
> [23099.151870] [<ffffffff815afb53>] ?
> __inet_lookup_established+0x173/0x280
> [23099.151873] [<ffffffff815a68a0>] ? inet_del_protocol+0x40/0x40
> [23099.151877] [<ffffffff815cc383>] tcp_v4_early_demux+0xa3/0x170
> [23099.151880] [<ffffffff815a69ed>] ip_rcv_finish+0x14d/0x360
> [23099.151882] [<ffffffff815a6f66>] ip_rcv+0x226/0x310
> [23099.151887] [<ffffffff815609f2>] __netif_receive_skb+0x492/0x640
> [23099.151890] [<ffffffff81074209>] ? __wake_up_common+0x59/0x90
> [23099.151897] [<ffffffffa00f284b>] ? ixgbe_poll+0xe3b/0x1140 [ixgbe]
> [23099.151900] [<ffffffff81560c94>] process_backlog+0xf4/0x1e0
> [23099.151902] [<ffffffff815619c5>] net_rx_action+0xf5/0x260
> [23099.151906] [<ffffffff810509c7>] __do_softirq+0xc7/0x230
> [23099.151908] [<ffffffff816757cc>] call_softirq+0x1c/0x30
> [23099.151912] [<ffffffff81004475>] do_softirq+0x55/0x90
> [23099.151914] [<ffffffff810507c5>] irq_exit+0x85/0xa0
> [23099.151916] [<ffffffff81675d16>] do_IRQ+0x66/0xe0
> [23099.151920] [<ffffffff8166c8aa>] common_interrupt+0x6a/0x6a
> [23099.151920] <EOI> [<ffffffff8166b17a>] ? __schedule+0x3aa/0x750
> [23099.151926] [<ffffffff8100b2ed>] ? mwait_idle+0xad/0x1f0
> [23099.151928] [<ffffffff8100a7a3>] cpu_idle+0xb3/0x100
> [23099.151931] [<ffffffff816632e3>] start_secondary+0x1c9/0x1d0
>
> Under 3.8.2:
>
> [33486.326977] IPv4: Attempt to release TCP socket in state 1
> ffff883269ea2300
> [33486.342971] IPv4: Attempt to release TCP socket in state 1
> ffff8835efccbf00
> [33505.595925] ------------[ cut here ]------------
> [33505.595934] WARNING: at net/sched/sch_generic.c:254
> dev_watchdog+0x258/0x270()
> [33505.595935] Hardware name: X9DR3-F
> [33505.595937] NETDEV WATCHDOG: eth2 (ixgbe): transmit queue 0 timed out
> [33505.595938] Modules linked in: macvlan iptable_nat nf_nat_ipv4 nf_nat
> bridge coretemp ghash_clmulni_intel gpio_ich ixgbe microcode sb_edac mei
> lpc_ich edac_core mfd_core mdio isci libsas igb ptp pps_core
> [33505.595951] Pid: 0, comm: swapper/4 Not tainted 3.8.2 #2
> [33505.595952] Call Trace:
> [33505.595954] <IRQ> [<ffffffff8104964f>] warn_slowpath_common+0x7f/0xc0
> [33505.595960] [<ffffffff81049746>] warn_slowpath_fmt+0x46/0x50
> [33505.595962] [<ffffffff815a1548>] dev_watchdog+0x258/0x270
> [33505.595965] [<ffffffff815a12f0>] ? __netdev_watchdog_up+0x80/0x80
> [33505.595968] [<ffffffff81059259>] call_timer_fn+0x49/0x130
> [33505.595972] [<ffffffff8107a07f>] ? scheduler_tick+0x15f/0x190
> [33505.595974] [<ffffffff81059854>] run_timer_softirq+0x224/0x290
> [33505.595976] [<ffffffff81058f76>] ? update_process_times+0x76/0x90
> [33505.595978] [<ffffffff815a12f0>] ? __netdev_watchdog_up+0x80/0x80
> [33505.595981] [<ffffffff8108ebd4>] ? ktime_get+0x54/0xe0
> [33505.595983] [<ffffffff810518a7>] __do_softirq+0xc7/0x230
> [33505.595987] [<ffffffff8168fe0c>] call_softirq+0x1c/0x30
> [33505.595990] [<ffffffff81004415>] do_softirq+0x55/0x90
> [33505.595993] [<ffffffff810516a5>] irq_exit+0x85/0xa0
> [33505.595996] [<ffffffff8169042e>] smp_apic_timer_interrupt+0x6e/0x99
> [33505.596000] [<ffffffff8168f80a>] apic_timer_interrupt+0x6a/0x70
> [33505.596002] <EOI> [<ffffffff8168567c>] ? __schedule+0x3ac/0x750
> [33505.596009] [<ffffffff8100b1fd>] ? mwait_idle+0xad/0x1f0
> [33505.596011] [<ffffffff8100a743>] cpu_idle+0xb3/0x100
> [33505.596014] [<ffffffff8167d7d2>] start_secondary+0x1d7/0x1de
> [33505.596015] ---[ end trace 3d817d7c7ae67386 ]---
> [33505.596064] ixgbe 0000:83:00.0 eth2: Reset adapter
> [33556.011932] INFO: rcu_sched self-detected stall on CPU { 24} (t=15001
> jiffies g=1985385 c=1985384 q=270786)
> [33556.011968] Pid: 0, comm: swapper/24 Tainted: G W 3.8.2 #2
> [33556.011970] Call Trace:
> [33556.011972] <IRQ> [<ffffffff810bea1e>]
> rcu_check_callbacks+0x21e/0x7c0
> [33556.011986] [<ffffffff8107f518>] ? account_system_time+0xe8/0x1e0
> [33556.011992] [<ffffffff81058f48>] update_process_times+0x48/0x90
> [33556.011996] [<ffffffff81095e06>] tick_sched_timer+0x56/0x130
> [33556.012000] [<ffffffff8107099d>] __run_hrtimer+0x7d/0x1c0
> [33556.012002] [<ffffffff81095db0>] ? tick_setup_sched_timer+0x110/0x110
> [33556.012004] [<ffffffff81070d56>] hrtimer_interrupt+0xf6/0x230
> [33556.012010] [<ffffffff81690429>] smp_apic_timer_interrupt+0x69/0x99
> [33556.012013] [<ffffffff8168f80a>] apic_timer_interrupt+0x6a/0x70
> [33556.012017] [<ffffffff815d3deb>] ?
> __inet_lookup_established+0xcb/0x2d0
> [33556.012020] [<ffffffff815cab80>] ? inet_del_protocol+0x40/0x40
> [33556.012024] [<ffffffff815f078c>] tcp_v4_early_demux+0xac/0x170
> [33556.012025] [<ffffffff815caccd>] ip_rcv_finish+0x14d/0x360
> [33556.012027] [<ffffffff815cb246>] ip_rcv+0x226/0x310
> [33556.012032] [<ffffffff815841a2>] __netif_receive_skb+0x492/0x640
> [33556.012034] [<ffffffff8158455d>] netif_receive_skb+0x2d/0x90
> [33556.012036] [<ffffffff815ed450>] ? tcp4_gro_receive+0xb0/0x130
> [33556.012038] [<ffffffff81584655>] napi_gro_complete+0x95/0xe0
> [33556.012040] [<ffffffff81584956>] dev_gro_receive+0x2b6/0x3b0
> [33556.012043] [<ffffffff8158508b>] napi_gro_receive+0x5b/0x130
> [33556.012051] [<ffffffffa01db04a>] ixgbe_poll+0x54a/0x1180 [ixgbe]
> [33556.012054] [<ffffffff810792fa>] ? enqueue_task+0x6a/0x80
> [33556.012056] [<ffffffff81584c15>] net_rx_action+0xf5/0x260
> [33556.012058] [<ffffffff810518a7>] __do_softirq+0xc7/0x230
> [33556.012061] [<ffffffff8168fe0c>] call_softirq+0x1c/0x30
> [33556.012064] [<ffffffff81004415>] do_softirq+0x55/0x90
> [33556.012066] [<ffffffff810516a5>] irq_exit+0x85/0xa0
> [33556.012068] [<ffffffff81690346>] do_IRQ+0x66/0xe0
> [33556.012071] [<ffffffff81686daa>] common_interrupt+0x6a/0x6a
> [33556.012073] <EOI> [<ffffffff8168567c>] ? __schedule+0x3ac/0x750
> [33556.012078] [<ffffffff8100b1fd>] ? mwait_idle+0xad/0x1f0
> [33556.012080] [<ffffffff8100a743>] cpu_idle+0xb3/0x100
> [33556.012082] [<ffffffff8167d7d2>] start_secondary+0x1d7/0x1de
> [33716.090584] INFO: task kworker/4:2:882 blocked for more than 120
> seconds.
> [33716.090602] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message.
> [33716.090618] kworker/4:2 D ffffffff81807160 0 882 2
> 0x00000000
> [33716.090622] ffff881fd2547ad8 0000000000000046 ffff881fd0ac2dc0
> 0000000000012700
> [33716.090624] ffff881fd2547fd8 ffff881fd2546010 0000000000012700
> 0000000000012700
> [33716.090626] ffff881fd2547fd8 0000000000012700 ffff881fd3655b80
> ffff881fd0ac2dc0
> [33716.090628] Call Trace:
> [33716.090639] [<ffffffff81685ae9>] schedule+0x29/0x70
> [33716.090642] [<ffffffff81683de5>] schedule_timeout+0x165/0x200
> [33716.090647] [<ffffffff810283fe>] ? physflat_send_IPI_mask+0xe/0x10
> [33716.090650] [<ffffffff8107d02e>] ? try_to_wake_up+0x23e/0x2b0
> [33716.090653] [<ffffffff81685158>] wait_for_common+0xc8/0x160
> [33716.090654] [<ffffffff8107d0a0>] ? try_to_wake_up+0x2b0/0x2b0
> [33716.090660] [<ffffffff810bc890>] ? rcu_cpu_stall_reset+0x60/0x60
> [33716.090662] [<ffffffff816852cd>] wait_for_completion+0x1d/0x20
> [33716.090665] [<ffffffff810b2536>] __stop_cpus+0x56/0x80
> [33716.090667] [<ffffffff810bc890>] ? rcu_cpu_stall_reset+0x60/0x60
> [33716.090669] [<ffffffff810b25ad>] try_stop_cpus+0x4d/0x80
> [33716.090672] [<ffffffff810bf0bb>]
> synchronize_sched_expedited+0xfb/0x1d0
> [33716.090674] [<ffffffff810bf19e>] synchronize_rcu_expedited+0xe/0x10
> [33716.090678] [<ffffffff8157e1f5>] synchronize_net+0x25/0x30
> [33716.090683] [<ffffffff815a1bc4>] dev_deactivate_many+0x254/0x260
> [33716.090685] [<ffffffff815a1bfd>] dev_deactivate+0x2d/0x40
> [33716.090688] [<ffffffff81593dc4>] linkwatch_do_dev+0x34/0x60
> [33716.090690] [<ffffffff81593fa3>] __linkwatch_run_queue+0xf3/0x1e0
> [33716.090692] [<ffffffff815940b5>] linkwatch_event+0x25/0x30
> [33716.090696] [<ffffffff810653f8>] process_one_work+0x168/0x450
> [33716.090699] [<ffffffff8106757b>] worker_thread+0x12b/0x3d0
> [33716.090702] [<ffffffff81067450>] ? manage_workers+0x300/0x300
> [33716.090704] [<ffffffff8106c5ee>] kthread+0xce/0xe0
> [33716.090706] [<ffffffff8106c520>] ?
> kthread_freezable_should_stop+0x70/0x70
> [33716.090709] [<ffffffff8168ec5c>] ret_from_fork+0x7c/0xb0
> [33716.090711] [<ffffffff8106c520>] ?
> kthread_freezable_should_stop+0x70/0x70
>
> [more hung processes bailing]
>
> [37335.739761] INFO: rcu_sched self-detected stall on CPU { 24} (t=960083
> jiffies g=1985385 c=1985384 q=19390495)
> [37335.739828] Pid: 0, comm: swapper/24 Tainted: G W 3.8.2 #2
> [37335.739830] Call Trace:
> [37335.739832] <IRQ> [<ffffffff810bea1e>]
> rcu_check_callbacks+0x21e/0x7c0
> [37335.739847] [<ffffffff8107f518>] ? account_system_time+0xe8/0x1e0
> [37335.739853] [<ffffffff81058f48>] update_process_times+0x48/0x90
> [37335.739857] [<ffffffff81095e06>] tick_sched_timer+0x56/0x130
> [37335.739860] [<ffffffff8107099d>] __run_hrtimer+0x7d/0x1c0
> [37335.739863] [<ffffffff81095db0>] ? tick_setup_sched_timer+0x110/0x110
> [37335.739865] [<ffffffff81070d56>] hrtimer_interrupt+0xf6/0x230
> [37335.739871] [<ffffffff81690429>] smp_apic_timer_interrupt+0x69/0x99
> [37335.739874] [<ffffffff8168f80a>] apic_timer_interrupt+0x6a/0x70
> [37335.739878] [<ffffffff815d3def>] ?
> __inet_lookup_established+0xcf/0x2d0
> [37335.739880] [<ffffffff815cab80>] ? inet_del_protocol+0x40/0x40
> [37335.739884] [<ffffffff815f078c>] tcp_v4_early_demux+0xac/0x170
> [37335.739886] [<ffffffff815caccd>] ip_rcv_finish+0x14d/0x360
> [37335.739888] [<ffffffff815cb246>] ip_rcv+0x226/0x310
> [37335.739892] [<ffffffff815841a2>] __netif_receive_skb+0x492/0x640
> [37335.739895] [<ffffffff8158455d>] netif_receive_skb+0x2d/0x90
> [37335.739897] [<ffffffff815ed450>] ? tcp4_gro_receive+0xb0/0x130
> [37335.739899] [<ffffffff81584655>] napi_gro_complete+0x95/0xe0
> [37335.739901] [<ffffffff81584956>] dev_gro_receive+0x2b6/0x3b0
> [37335.739903] [<ffffffff8158508b>] napi_gro_receive+0x5b/0x130
> [37335.739911] [<ffffffffa01db04a>] ixgbe_poll+0x54a/0x1180 [ixgbe]
> [37335.739915] [<ffffffff810792fa>] ? enqueue_task+0x6a/0x80
> [37335.739917] [<ffffffff81584c15>] net_rx_action+0xf5/0x260
> [37335.739919] [<ffffffff810518a7>] __do_softirq+0xc7/0x230
> [37335.739922] [<ffffffff8168fe0c>] call_softirq+0x1c/0x30
> [37335.739927] [<ffffffff81004415>] do_softirq+0x55/0x90
> [37335.739928] [<ffffffff810516a5>] irq_exit+0x85/0xa0
> [37335.739931] [<ffffffff81690346>] do_IRQ+0x66/0xe0
> [37335.739937] [<ffffffff81686daa>] common_interrupt+0x6a/0x6a
> [37335.739938] <EOI> [<ffffffff8168567c>] ? __schedule+0x3ac/0x750
> [37335.739943] [<ffffffff8100b1fd>] ? mwait_idle+0xad/0x1f0
> [37335.739945] [<ffffffff8100a743>] cpu_idle+0xb3/0x100
> [37335.739948] [<ffffffff8167d7d2>] start_secondary+0x1d7/0x1de
> [37515.727179] INFO: rcu_sched self-detected stall on CPU { 24}
> (t=1005087 jiffies g=1985385 c=1985384 q=20855557)
> [37515.727246] Pid: 0, comm: swapper/24 Tainted: G W 3.8.2 #2
> [37515.727249] Call Trace:
> [37515.727251] <IRQ> [<ffffffff810bea1e>]
> rcu_check_callbacks+0x21e/0x7c0
> [37515.727265] [<ffffffff8107f518>] ? account_system_time+0xe8/0x1e0
> [37515.727271] [<ffffffff81058f48>] update_process_times+0x48/0x90
> [37515.727275] [<ffffffff81095e06>] tick_sched_timer+0x56/0x130
> [37515.727279] [<ffffffff8107099d>] __run_hrtimer+0x7d/0x1c0
> [37515.727281] [<ffffffff81095db0>] ? tick_setup_sched_timer+0x110/0x110
> [37515.727283] [<ffffffff81070d56>] hrtimer_interrupt+0xf6/0x230
> [37515.727289] [<ffffffff81690429>] smp_apic_timer_interrupt+0x69/0x99
> [37515.727292] [<ffffffff8168f80a>] apic_timer_interrupt+0x6a/0x70
> [37515.727296] [<ffffffff815d3deb>] ?
> __inet_lookup_established+0xcb/0x2d0
> [37515.727298] [<ffffffff815cab80>] ? inet_del_protocol+0x40/0x40
> [37515.727302] [<ffffffff815f078c>] tcp_v4_early_demux+0xac/0x170
> [37515.727304] [<ffffffff815caccd>] ip_rcv_finish+0x14d/0x360
> [37515.727306] [<ffffffff815cb246>] ip_rcv+0x226/0x310
> [37515.727310] [<ffffffff815841a2>] __netif_receive_skb+0x492/0x640
> [37515.727312] [<ffffffff8158455d>] netif_receive_skb+0x2d/0x90
> [37515.727315] [<ffffffff815ed450>] ? tcp4_gro_receive+0xb0/0x130
> [37515.727317] [<ffffffff81584655>] napi_gro_complete+0x95/0xe0
> [37515.727319] [<ffffffff81584956>] dev_gro_receive+0x2b6/0x3b0
> [37515.727322] [<ffffffff8158508b>] napi_gro_receive+0x5b/0x130
> [37515.727330] [<ffffffffa01db04a>] ixgbe_poll+0x54a/0x1180 [ixgbe]
> [37515.727334] [<ffffffff810792fa>] ? enqueue_task+0x6a/0x80
> [37515.727336] [<ffffffff81584c15>] net_rx_action+0xf5/0x260
> [37515.727338] [<ffffffff810518a7>] __do_softirq+0xc7/0x230
> [37515.727341] [<ffffffff8168fe0c>] call_softirq+0x1c/0x30
> [37515.727345] [<ffffffff81004415>] do_softirq+0x55/0x90
> [37515.727346] [<ffffffff810516a5>] irq_exit+0x85/0xa0
> [37515.727349] [<ffffffff81690346>] do_IRQ+0x66/0xe0
> [37515.727354] [<ffffffff81686daa>] common_interrupt+0x6a/0x6a
> [37515.727355] <EOI> [<ffffffff8168567c>] ? __schedule+0x3ac/0x750
> [37515.727360] [<ffffffff8100b1fd>] ? mwait_idle+0xad/0x1f0
> [37515.727362] [<ffffffff8100a743>] cpu_idle+0xb3/0x100
> [37515.727365] [<ffffffff8167d7d2>] start_secondary+0x1d7/0x1de
>
> ... then swapped just does this until someone reboots the box.
>
> Apologies for the ugly paste.
>
> Thanks,
> -Dormando
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* [PATCH 1/7] USB: adds comment on suspend callback
From: Ming Lei @ 2013-03-05 4:01 UTC (permalink / raw)
To: David S. Miller, Greg Kroah-Hartman, Jiri Kosina
Cc: Alan Stern, Oliver Neukum, netdev, linux-usb, linux-input,
Ming Lei
In-Reply-To: <1362456103-24956-1-git-send-email-ming.lei@canonical.com>
This patch adds comments on interface driver suspend callback
to emphasize that the failure return value is ignored by
USB core in system sleep context, so do not try to recover
device for this case.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
include/linux/usb.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 4d22d0f..ea9d7cb 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -978,7 +978,10 @@ struct usbdrv_wrap {
* the "usbfs" filesystem. This lets devices provide ways to
* expose information to user space regardless of where they
* do (or don't) show up otherwise in the filesystem.
- * @suspend: Called when the device is going to be suspended by the system.
+ * @suspend: Called when the device is going to be suspended by the
+ * system either from system sleep or runtime suspend context, and
+ * its failed return value will be ignored in system sleep context,
+ * so do NOT try to recover device for this case.
* @resume: Called when the device is being resumed by the system.
* @reset_resume: Called when the suspended device has been reset instead
* of being resumed.
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/7] USB: serial: handle suspend failure path correctly
From: Ming Lei @ 2013-03-05 4:01 UTC (permalink / raw)
To: David S. Miller, Greg Kroah-Hartman, Jiri Kosina
Cc: Alan Stern, Oliver Neukum, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA, Ming Lei, Johan Hovold
In-Reply-To: <1362456103-24956-1-git-send-email-ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
This patch kills traffic even though type->suspend returns
failure inside usb_serial_suspend from system sleep context
because USB core ignores the failiure and lets system sleep
go ahread, so the serial URB traffic need to be killed
in this case.
Cc: Johan Hovold <jhovold-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
---
drivers/usb/serial/usb-serial.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index a19ed74..04ad3d5 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -1144,7 +1144,8 @@ int usb_serial_suspend(struct usb_interface *intf, pm_message_t message)
r = serial->type->suspend(serial, message);
if (r < 0) {
serial->suspending = 0;
- goto err_out;
+ if (PMSG_IS_AUTO(msg))
+ goto err_out;
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 5/7] usbnet: smsc95xx: don't recover device if suspend fails in system sleep
From: Ming Lei @ 2013-03-05 4:01 UTC (permalink / raw)
To: David S. Miller, Greg Kroah-Hartman, Jiri Kosina
Cc: Alan Stern, Oliver Neukum, netdev, linux-usb, linux-input,
Ming Lei, Steve Glendinning
In-Reply-To: <1362456103-24956-1-git-send-email-ming.lei@canonical.com>
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.
Cc: Steve Glendinning <steve.glendinning@shawell.net>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
drivers/net/usb/smsc95xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index e6d2dea..a0c5478 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -1660,7 +1660,7 @@ static int smsc95xx_suspend(struct usb_interface *intf, pm_message_t message)
ret = smsc95xx_enter_suspend0(dev);
done:
- if (ret)
+ if (ret && PMSG_IS_AUTO(msg))
usbnet_resume(intf);
return ret;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 6/7] usbnet: smsc75xx: don't recover device if suspend fails in system sleep
From: Ming Lei @ 2013-03-05 4:01 UTC (permalink / raw)
To: David S. Miller, Greg Kroah-Hartman, Jiri Kosina
Cc: Alan Stern, Oliver Neukum, netdev, linux-usb, linux-input,
Ming Lei, Steve Glendinning
In-Reply-To: <1362456103-24956-1-git-send-email-ming.lei@canonical.com>
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.
Cc: Steve Glendinning <steve.glendinning@shawell.net>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
drivers/net/usb/smsc75xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 9abe517..f65c506 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -2011,7 +2011,7 @@ static int smsc75xx_suspend(struct usb_interface *intf, pm_message_t message)
ret = smsc75xx_enter_suspend0(dev);
done:
- if (ret)
+ if (ret && PMSG_IS_AUTO(msg))
usbnet_resume(intf);
return ret;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 7/7] usbnet: qmi_wwan: don't recover device if suspend fails in system sleep
From: Ming Lei @ 2013-03-05 4:01 UTC (permalink / raw)
To: David S. Miller, Greg Kroah-Hartman, Jiri Kosina
Cc: Alan Stern, Oliver Neukum, netdev, linux-usb, linux-input,
Ming Lei, Bjørn Mork
In-Reply-To: <1362456103-24956-1-git-send-email-ming.lei@canonical.com>
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.
Cc: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
drivers/net/usb/qmi_wwan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index efb5c7c..fce18be 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -294,7 +294,7 @@ static int qmi_wwan_suspend(struct usb_interface *intf, pm_message_t message)
if (intf == info->control && info->subdriver && info->subdriver->suspend)
ret = info->subdriver->suspend(intf, message);
- if (ret < 0)
+ if (ret < 0 && PMSG_IS_AUTO(msg))
usbnet_resume(intf);
err:
return ret;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/7] USB: don't recover device if suspend fails in system sleep
From: Ming Lei @ 2013-03-05 4:01 UTC (permalink / raw)
To: David S. Miller, Greg Kroah-Hartman, Jiri Kosina
Cc: Alan Stern, Oliver Neukum, netdev, linux-usb, linux-input
Hi,
This patch adds comments on interface driver suspend callback
to emphasize that the failure return value is ignored by
USB core in system sleep context, so do not try to recover
device for this case, otherwise the URB traffic scheduled
in recovery of failure path may cross system sleep, and may
cause problems.
Also fixes the USB serial, HID and several usbnet drivers
which may recover device in suspend failure path of system sleep.
Thanks,
--
Ming Lei
^ permalink raw reply
* [PATCH 3/7] USBHID: don't recover device if suspend fails in system sleep
From: Ming Lei @ 2013-03-05 4:01 UTC (permalink / raw)
To: David S. Miller, Greg Kroah-Hartman, Jiri Kosina
Cc: Alan Stern, Oliver Neukum, netdev, linux-usb, linux-input,
Ming Lei
In-Reply-To: <1362456103-24956-1-git-send-email-ming.lei@canonical.com>
If suspend callback fails in system sleep context, usb core will
ignore the failure and let the system sleep go ahead further, so this
patch doesn't recover device under this situation.
Cc: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
drivers/hid/usbhid/hid-core.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 8e0c4bf94..a15ec29 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -1493,7 +1493,7 @@ static int hid_suspend(struct usb_interface *intf, pm_message_t message)
{
struct hid_device *hid = usb_get_intfdata(intf);
struct usbhid_device *usbhid = hid->driver_data;
- int status;
+ int status = 0;
bool driver_suspended = false;
if (PMSG_IS_AUTO(message)) {
@@ -1520,19 +1520,15 @@ static int hid_suspend(struct usb_interface *intf, pm_message_t message)
}
} else {
- if (hid->driver && hid->driver->suspend) {
+ /* Ignore failure return value in system sleep */
+ if (hid->driver && hid->driver->suspend)
status = hid->driver->suspend(hid, message);
- if (status < 0)
- return status;
- }
driver_suspended = true;
spin_lock_irq(&usbhid->lock);
set_bit(HID_SUSPENDED, &usbhid->iofl);
spin_unlock_irq(&usbhid->lock);
- if (usbhid_wait_io(hid) < 0) {
+ if (usbhid_wait_io(hid) < 0)
status = -EIO;
- goto failed;
- }
}
hid_cancel_delayed_stuff(usbhid);
@@ -1544,7 +1540,7 @@ static int hid_suspend(struct usb_interface *intf, pm_message_t message)
goto failed;
}
dev_dbg(&intf->dev, "suspend\n");
- return 0;
+ return status;
failed:
hid_resume_common(hid, driver_suspended);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/7] usbnet: cdc_mbim: don't recover device if suspend fails in system sleep
From: Ming Lei @ 2013-03-05 4:01 UTC (permalink / raw)
To: David S. Miller, Greg Kroah-Hartman, Jiri Kosina
Cc: Alan Stern, Oliver Neukum, netdev, linux-usb, linux-input,
Ming Lei, Bjørn Mork
In-Reply-To: <1362456103-24956-1-git-send-email-ming.lei@canonical.com>
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.
Cc: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
drivers/net/usb/cdc_mbim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
index 248d2dc..da83546 100644
--- a/drivers/net/usb/cdc_mbim.c
+++ b/drivers/net/usb/cdc_mbim.c
@@ -338,7 +338,7 @@ static int cdc_mbim_suspend(struct usb_interface *intf, pm_message_t message)
if (intf == ctx->control && info->subdriver && info->subdriver->suspend)
ret = info->subdriver->suspend(intf, message);
- if (ret < 0)
+ if (ret < 0 && PMSG_IS_AUTO(msg))
usbnet_resume(intf);
error:
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] net/wireless/brcm80211: remove PCI_BUS define from defs.h to fix warnings
From: Shuah Khan @ 2013-03-05 4:08 UTC (permalink / raw)
To: Larry Finger
Cc: shuah.khan, brudley, arend, frankyl, linville, seth.forshee,
pieterpg, linux-wireless, brcm80211-dev-list, netdev, LKML
In-Reply-To: <51354A28.3040607@lwfinger.net>
On Mon, Mar 4, 2013 at 6:28 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 03/04/2013 07:02 PM, Shuah Khan wrote:
>>
>> PCI_BUS defined in defs.h results in warnings from all brcm80211 source
>> files
>> including defs.h. This define is not used in brcm80211. Removing this
>> define
>> fixes the warning.
>>
>> In file included from
>> drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c:35:0:
>> drivers/net/wireless/brcm80211/include/defs.h:23:0: warning: "PCI_BUS"
>> redefined [enabled by default]
>> include/uapi/linux/pci.h:36:0: note: this is the location of the previous
>> definition
>> CC [M] drivers/net/wireless/b43legacy/dma.o
>> CC [M] drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.o
>> CC [M] drivers/net/wireless/b43legacy/pio.o
>> In file included from
>> drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c:29:0:
>> drivers/net/wireless/brcm80211/include/defs.h:23:0: warning: "PCI_BUS"
>> redefined [enabled by default]
>> include/uapi/linux/pci.h:36:0: note: this is the location of the previous
>> definition
>> In file included from
>> drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c:29:0:
>> drivers/net/wireless/brcm80211/include/defs.h:23:0: warning: "PCI_BUS"
>> redefined [enabled by default]
>> include/uapi/linux/pci.h:36:0: note: this is the location of the previous
>> definition
>
>
> Strange, I do not see PCI_BUS defined anywhere in the include/ branch in
> either 3.8 or 3.9. In addition, I don't get these warnings. What is
> different in your system?
>
> Larry
I am sorry. Please ignore this patch. I had a old commit for a change
I was working on
and I thought I undid the changes. My apologies for the noise.
-- Shuah
^ permalink raw reply
* Re: [PATCH] net/rds: using strlcpy instead of strncpy
From: Chen Gang @ 2013-03-05 4:09 UTC (permalink / raw)
To: Ben Hutchings
Cc: David Laight, venkat.x.venkatsubra, David Miller, rds-devel,
netdev
In-Reply-To: <1362454672.3768.383.camel@deadeye.wl.decadent.org.uk>
于 2013年03月05日 11:37, Ben Hutchings 写道:
>> I think what I have done is just like your choice "2."
>> > for me, I think they are equal:
>> >
>> > - strncpy(ctr.name, names[i], sizeof(ctr.name) - 1);
>> > + strlcpy(ctr.name, names[i], sizeof(ctr.name));
>> >
>> >
>> > strncpy(ctr.name, names[i], sizeof(ctr.name) - 1);
>> > + ctr.name[sizeof(ctr.name) - 1] = '\0';
> They are not. strncpy() pads with zeroes to the end of the given buffer
> whereas strlcpy() adds only a single zero byte (and truncates if
> necessary to fit the zero byte).
ok, thank you. they are really not the same (originally, I did not
notice it)
could you supply the reason:
why need we zero all of ctr.name ?
(for me, I think, keeping ctr.name just a zero-based string is ok)
thanks.
:-)
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* [PATCH 1/3] cirrus: cs89x0: Use module_platform_driver_probe macro
From: Sachin Kamat @ 2013-03-05 4:31 UTC (permalink / raw)
To: netdev; +Cc: davem, sachin.kamat
module_platform_driver_probe() eliminates the boilerplate and simplifies
the code.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/net/ethernet/cirrus/cs89x0.c | 14 +-------------
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/cirrus/cs89x0.c b/drivers/net/ethernet/cirrus/cs89x0.c
index 1384469..73c1c8c 100644
--- a/drivers/net/ethernet/cirrus/cs89x0.c
+++ b/drivers/net/ethernet/cirrus/cs89x0.c
@@ -1978,18 +1978,6 @@ static struct platform_driver cs89x0_driver = {
.remove = cs89x0_platform_remove,
};
-static int __init cs89x0_init(void)
-{
- return platform_driver_probe(&cs89x0_driver, cs89x0_platform_probe);
-}
-
-module_init(cs89x0_init);
-
-static void __exit cs89x0_cleanup(void)
-{
- platform_driver_unregister(&cs89x0_driver);
-}
-
-module_exit(cs89x0_cleanup);
+module_platform_driver_probe(cs89x0_driver, cs89x0_platform_probe);
#endif /* CONFIG_CS89x0_PLATFORM */
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/3] net: at91_ether: Use module_platform_driver_probe macro
From: Sachin Kamat @ 2013-03-05 4:31 UTC (permalink / raw)
To: netdev; +Cc: davem, sachin.kamat, Nicolas Ferre
In-Reply-To: <1362457882-12892-1-git-send-email-sachin.kamat@linaro.org>
module_platform_driver_probe() eliminates the boilerplate and simplifies
the code.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/net/ethernet/cadence/at91_ether.c | 13 +------------
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
index 3becdb2..1a57e16 100644
--- a/drivers/net/ethernet/cadence/at91_ether.c
+++ b/drivers/net/ethernet/cadence/at91_ether.c
@@ -519,18 +519,7 @@ static struct platform_driver at91ether_driver = {
},
};
-static int __init at91ether_init(void)
-{
- return platform_driver_probe(&at91ether_driver, at91ether_probe);
-}
-
-static void __exit at91ether_exit(void)
-{
- platform_driver_unregister(&at91ether_driver);
-}
-
-module_init(at91ether_init)
-module_exit(at91ether_exit)
+module_platform_driver_probe(at91ether_driver, at91ether_probe);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("AT91RM9200 EMAC Ethernet driver");
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/3] net: macb: Use module_platform_driver_probe macro
From: Sachin Kamat @ 2013-03-05 4:31 UTC (permalink / raw)
To: netdev; +Cc: davem, sachin.kamat, Nicolas Ferre
In-Reply-To: <1362457882-12892-1-git-send-email-sachin.kamat@linaro.org>
module_platform_driver_probe() eliminates the boilerplate and simplifies
the code.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/net/ethernet/cadence/macb.c | 13 +------------
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 7903943..3a5d680 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -1737,18 +1737,7 @@ static struct platform_driver macb_driver = {
},
};
-static int __init macb_init(void)
-{
- return platform_driver_probe(&macb_driver, macb_probe);
-}
-
-static void __exit macb_exit(void)
-{
- platform_driver_unregister(&macb_driver);
-}
-
-module_init(macb_init);
-module_exit(macb_exit);
+module_platform_driver_probe(macb_driver, macb_probe);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Cadence MACB/GEM Ethernet driver");
--
1.7.4.1
^ permalink raw reply related
* Re: BUG: IPv4: Attempt to release TCP socket in state 1
From: Eric Dumazet @ 2013-03-05 5:07 UTC (permalink / raw)
To: Cong Wang; +Cc: dormando, linux-kernel, netdev
In-Reply-To: <51356AC1.4090302@gmail.com>
On Tue, 2013-03-05 at 11:47 +0800, Cong Wang wrote:
> (Cc'ing the right netdev mailing list...)
>
> On 03/05/2013 08:01 AM, dormando wrote:
> > Hi!
> >
> > I have a (core lockup?) with 3.7.6+ and 3.8.2 which appears to be under
> > ixgbe. The machine appears to still be up but network stays in a severely
> > hobbled state. Either lagging or not responding to the network at all.
> >
> > On a new box the hang happens within 8-24 hours of giving it production
> > network traffic. On an older machine (6 cores instead of 8, etc) it can
> > run for a week or more before hanging.
> >
> > The hang from 3.7 might be slightly different than 3.8. They seem to be
> > mostly the same aside from 3.8 hanging in the GRO path. Don't see anything
> > obvious in 3.9-rc1 that would fix it, and haven't tried 3.9-rc1.
> >
> > I've not yet figured out how to reproduce outside of production (as
> > always, sigh). This doesn't seem to happen with 3.6.6, but we have
> > different and less frequent kernel panics there.
> >
Dornando, do you use any kind of special setup, external modules,
or netfilter ? (iptables-save output would help)
Is it a pristine kernel, or a modified one ?
^ permalink raw reply
* Re: [PATCH 0/7] USB: don't recover device if suspend fails in system sleep
From: Ming Lei @ 2013-03-05 5:14 UTC (permalink / raw)
To: David S. Miller, Greg Kroah-Hartman, Jiri Kosina
Cc: Alan Stern, Oliver Neukum, netdev, linux-usb, linux-input
In-Reply-To: <1362456103-24956-1-git-send-email-ming.lei@canonical.com>
On Tue, Mar 5, 2013 at 12:01 PM, Ming Lei <ming.lei@canonical.com> wrote:
> Hi,
>
> This patch adds comments on interface driver suspend callback
> to emphasize that the failure return value is ignored by
> USB core in system sleep context, so do not try to recover
> device for this case, otherwise the URB traffic scheduled
> in recovery of failure path may cross system sleep, and may
> cause problems.
>
> Also fixes the USB serial, HID and several usbnet drivers
> which may recover device in suspend failure path of system sleep.
Sorry, this patches have compile problem, so please don't apply them,
and I will send v1 later.
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: BUG: IPv4: Attempt to release TCP socket in state 1
From: dormando @ 2013-03-05 5:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Cong Wang, linux-kernel, netdev
In-Reply-To: <1362460046.15793.111.camel@edumazet-glaptop>
On Mon, 4 Mar 2013, Eric Dumazet wrote:
> On Tue, 2013-03-05 at 11:47 +0800, Cong Wang wrote:
> > (Cc'ing the right netdev mailing list...)
> >
> > On 03/05/2013 08:01 AM, dormando wrote:
> > > Hi!
> > >
> > > I have a (core lockup?) with 3.7.6+ and 3.8.2 which appears to be under
> > > ixgbe. The machine appears to still be up but network stays in a severely
> > > hobbled state. Either lagging or not responding to the network at all.
> > >
> > > On a new box the hang happens within 8-24 hours of giving it production
> > > network traffic. On an older machine (6 cores instead of 8, etc) it can
> > > run for a week or more before hanging.
> > >
> > > The hang from 3.7 might be slightly different than 3.8. They seem to be
> > > mostly the same aside from 3.8 hanging in the GRO path. Don't see anything
> > > obvious in 3.9-rc1 that would fix it, and haven't tried 3.9-rc1.
> > >
> > > I've not yet figured out how to reproduce outside of production (as
> > > always, sigh). This doesn't seem to happen with 3.6.6, but we have
> > > different and less frequent kernel panics there.
> > >
>
> Dornando, do you use any kind of special setup, external modules,
> or netfilter ? (iptables-save output would help)
>
> Is it a pristine kernel, or a modified one ?
>
(Sigh. sorry for the misfire, thanks for fixing cc).
No 3rd party modules. There's a tiny patch for controlling initcwnd from
userspace and another one for the extra_free_kbytes tunable that I brought
up in another thread. We've had the initcwnd patch in for a long time
without trouble. The extra_free_kbytes tunable isn't even being used yet,
so all that's doing is adding a 0 somewhere.
Only two iptables rules loaded: global NOTRACK rules for PREROUTING/OUTPUT
in raw.
Kernel's as close to pristine as I can make it. We had the 10g patch in
but I've dropped it.
^ permalink raw reply
* Re: [PATCH 0/7] USB: don't recover device if suspend fails in system sleep
From: Bjørn Mork @ 2013-03-05 7:03 UTC (permalink / raw)
To: Ming Lei
Cc: David S. Miller, Greg Kroah-Hartman, Jiri Kosina, Alan Stern,
Oliver Neukum, netdev, linux-usb, linux-input
In-Reply-To: <1362456103-24956-1-git-send-email-ming.lei@canonical.com>
Ming Lei <ming.lei@canonical.com> writes:
> Hi,
>
> This patch adds comments on interface driver suspend callback
> to emphasize that the failure return value is ignored by
> USB core in system sleep context, so do not try to recover
> device for this case, otherwise the URB traffic scheduled
> in recovery of failure path may cross system sleep, and may
> cause problems.
Well, an unexpected error did happen so problems are to be expected,
yes.
> Also fixes the USB serial, HID and several usbnet drivers
> which may recover device in suspend failure path of system sleep.
I believe all of these are wrong unless you have any real bug which is
fixed by this.
All these drivers suspend in multiple steps, where each step can
fail. If a later step fails then they revert any previously successful
step before returning the failure, thereby ensuring that the
device/driver state when suspend returns is consistently either
suspended or resumed.
The error recovery they do in suspend is not about preventing suspend at
all. It is about ensuring that that the driver and device is in a
consistent state, which is "resumed" if suspend fails.
Your patch set make the drivers return from suspend in some intermediate
state, where the device and/or driver is neither suspended nor resumed.
This is wrong. You still did not necessarily kill all URBs, but you
killed some of them. What is resume() going to do then?
I am going to NAK the cdc_mbim and qmi_wwan pacthes unless you can
convince me that we need to add a "partly-suspended" state for the
system suspend error case. In which case the patch will need to include
the corresponding resume fix for the "partly-suspended" state.
Bjørn
^ permalink raw reply
* Re: [PATCH 4/7] usbnet: cdc_mbim: don't recover device if suspend fails in system sleep
From: Bjørn Mork @ 2013-03-05 7:09 UTC (permalink / raw)
To: Ming Lei
Cc: David S. Miller, Greg Kroah-Hartman, Jiri Kosina, Alan Stern,
Oliver Neukum, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1362456103-24956-5-git-send-email-ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> writes:
> If suspend callback fails in system sleep context, usb core will
> ignore the failure and let system sleep go ahead further, so
> this patch doesn't recover device under this situation.
>
> Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> Signed-off-by: Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> ---
> drivers/net/usb/cdc_mbim.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
> index 248d2dc..da83546 100644
> --- a/drivers/net/usb/cdc_mbim.c
> +++ b/drivers/net/usb/cdc_mbim.c
> @@ -338,7 +338,7 @@ static int cdc_mbim_suspend(struct usb_interface *intf, pm_message_t message)
>
> if (intf == ctx->control && info->subdriver && info->subdriver->suspend)
> ret = info->subdriver->suspend(intf, message);
> - if (ret < 0)
> + if (ret < 0 && PMSG_IS_AUTO(msg))
> usbnet_resume(intf);
>
> error:
NAK. We if the device cannot suspend, then it cannot do suspend halfways
either. Whether the caller will ignore the error or not, is irrelevant.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 7/7] usbnet: qmi_wwan: don't recover device if suspend fails in system sleep
From: Bjørn Mork @ 2013-03-05 7:09 UTC (permalink / raw)
To: Ming Lei
Cc: David S. Miller, Greg Kroah-Hartman, Jiri Kosina, Alan Stern,
Oliver Neukum, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1362456103-24956-8-git-send-email-ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> writes:
> If suspend callback fails in system sleep context, usb core will
> ignore the failure and let system sleep go ahead further, so
> this patch doesn't recover device under this situation.
>
> Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> Signed-off-by: Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> ---
> drivers/net/usb/qmi_wwan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index efb5c7c..fce18be 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -294,7 +294,7 @@ static int qmi_wwan_suspend(struct usb_interface *intf, pm_message_t message)
>
> if (intf == info->control && info->subdriver && info->subdriver->suspend)
> ret = info->subdriver->suspend(intf, message);
> - if (ret < 0)
> + if (ret < 0 && PMSG_IS_AUTO(msg))
> usbnet_resume(intf);
> err:
> return ret;
NAK. We if the device cannot suspend, then it cannot do suspend halfways
either. Whether the caller will ignore the error or not, is irrelevant.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 2/2] benet: Wait I/O while resuming device
From: Perla, Sathya @ 2013-03-05 7:59 UTC (permalink / raw)
To: Gavin Shan; +Cc: netdev@vger.kernel.org
In-Reply-To: <20130305072126.GA19947@shangw.(null)>
> -----Original Message-----
> From: Gavin Shan [mailto:shangw@linux.vnet.ibm.com]
>
> On Mon, Mar 04, 2013 at 11:11:21AM +0000, Perla, Sathya wrote:
> >> >> After resetting the adapter, the config space register (0x7c)
> >> >> might give fake information to indicate the f/w is ready. In turn,
> >> >> 0xFF's is always returned while accessing on I/O space registers.
> >> >> The patch adds more check to make sure the I/O space is ready for
> >> >> access before
> >> accessing that region.
> >> >>
> >> >...
> >> >>
....
> >> >
> >>
> >> I don't think 0xffffffff here indicates a new EEH error and the
> >> adapter was recovering from EEH error, which already happened before.
> >
> >>
> >> Actually, I'm developing new feature to support EEH for PowerNV (PPC)
> >> platform. While the benet adapter detected EEH error and tried to
> >> resume, the I/O access always returned 0xffffffff even through I
> >> could get correct values from the config space. Since I don't have
> >> the specification, I would guess the config space becomes ready prior
> >> to I/O space after resetting the adapter and its firmware.
> >
> >The root-cause here is that the config-space/0x7c register is
> >incorrectly reflecting the POST state to be FW_READY. This causes the
> >driver to go ahead and read I/O space "prematurely" causing a 0xffffffff read.
> >The config-space/0x7c register reflects the correct value a little
> >later. This happens only for BE2/3 chips.
> >
>
> Yes, Sathya. It's exactly the case happened on BE3.
>
> >I propose to fix this by polling instead on CSR-BAR/0xac register for
> >POST status for BE2/3 chips.
> >
>
> Do you mean to poll CSR-BAR/0xac (adapter->db + 0xac) for POST status? I just
> had one experiment. It seems that CSR-BAR/0xac always returns 0x0 even
> though the firmware have been ready completely. Could you please double-
> check on it?
Gavin, The CSR-BAR is not being mapped in the current code.
That should be done as a part of the fix....
Would it be possible for you to test this patch.
I have it working on my setup but I feel it still needs some regression testing...
---
drivers/net/ethernet/emulex/benet/be.h | 1 +
drivers/net/ethernet/emulex/benet/be_cmds.c | 10 ++++++----
drivers/net/ethernet/emulex/benet/be_hw.h | 4 ++--
drivers/net/ethernet/emulex/benet/be_main.c | 9 +++++++++
4 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index 28ceb84..03c638f 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -349,6 +349,7 @@ struct be_adapter {
struct pci_dev *pdev;
struct net_device *netdev;
+ u8 __iomem *csr;
u8 __iomem *db; /* Door Bell */
struct mutex mbox_lock; /* For serializing mbox cmds to BE card */
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 071aea7..91b4f88 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -476,12 +476,14 @@ static int be_mbox_notify_wait(struct be_adapter *adapter)
static int be_POST_stage_get(struct be_adapter *adapter, u16 *stage)
{
u32 sem;
- u32 reg = skyhawk_chip(adapter) ? SLIPORT_SEMAPHORE_OFFSET_SH :
- SLIPORT_SEMAPHORE_OFFSET_BE;
- pci_read_config_dword(adapter->pdev, reg, &sem);
- *stage = sem & POST_STAGE_MASK;
+ if (BEx_chip(adapter))
+ sem = ioread32(adapter->csr + SLIPORT_SEMAPHORE_OFFSET_BEx);
+ else
+ pci_read_config_dword(adapter->pdev,
+ SLIPORT_SEMAPHORE_OFFSET_SH, &sem);
+ *stage = sem & POST_STAGE_MASK;
if ((sem >> POST_ERR_SHIFT) & POST_ERR_MASK)
return -1;
else
diff --git a/drivers/net/ethernet/emulex/benet/be_hw.h b/drivers/net/ethernet/emulex/benet/be_hw.h
index 541d453..62dc220 100644
--- a/drivers/net/ethernet/emulex/benet/be_hw.h
+++ b/drivers/net/ethernet/emulex/benet/be_hw.h
@@ -32,8 +32,8 @@
#define MPU_EP_CONTROL 0
/********** MPU semphore: used for SH & BE *************/
-#define SLIPORT_SEMAPHORE_OFFSET_BE 0x7c
-#define SLIPORT_SEMAPHORE_OFFSET_SH 0x94
+#define SLIPORT_SEMAPHORE_OFFSET_BEx 0xac /* CSR BAR offset */
+#define SLIPORT_SEMAPHORE_OFFSET_SH 0x94 /* PCI-CFG offset */
#define POST_STAGE_MASK 0x0000FFFF
#define POST_ERR_MASK 0x1
#define POST_ERR_SHIFT 31
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 3860888..bd0d56f 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -3688,6 +3688,8 @@ static void be_netdev_init(struct net_device *netdev)
static void be_unmap_pci_bars(struct be_adapter *adapter)
{
+ if (adapter->csr)
+ pci_iounmap(adapter->pdev, adapter->csr);
if (adapter->db)
pci_iounmap(adapter->pdev, adapter->db);
}
@@ -3721,6 +3723,13 @@ static int be_map_pci_bars(struct be_adapter *adapter)
adapter->if_type = (sli_intf & SLI_INTF_IF_TYPE_MASK) >>
SLI_INTF_IF_TYPE_SHIFT;
+ if (be_physfn(adapter) && BEx_chip(adapter)) {
+ addr = pci_iomap(adapter->pdev, 2, 0);
+ if (addr == NULL)
+ return -ENOMEM;
+ adapter->csr = addr;
+ }
+
addr = pci_iomap(adapter->pdev, db_bar(adapter), 0);
if (addr == NULL)
goto pci_map_err;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 3/5] wl1251: call pm_runtime_put_sync in pm_runtime_get_sync failed case
From: Luciano Coelho @ 2013-03-05 8:51 UTC (permalink / raw)
To: Li Fei
Cc: linville, wfp5p, gregkh, notasas, rjw, linux-wireless, netdev,
linux-kernel, chuansheng.liu
In-Reply-To: <1362037892.6212.13.camel@fli24-HP-Compaq-8100-Elite-CMT-PC>
On Thu, 2013-02-28 at 15:51 +0800, Li Fei wrote:
> Even in failed case of pm_runtime_get_sync, the usage_count
> is incremented. In order to keep the usage_count with correct
> value and runtime power management to behave correctly, call
> pm_runtime_put(_sync) in such case.
>
> Signed-off-by Liu Chuansheng <chuansheng.liu@intel.com>
> Signed-off-by: Li Fei <fei.li@intel.com>
> ---
Applied, thanks!
--
Luca.
^ 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