On Fri, Oct 29, 2010 at 11:06 PM, Rupjyoti Sarmah [off-list ref] wrote:
Hi ,
APM boards Canyonlands/Kilauea/Glacier/Katmai/Sequoia are all failing
during booting.
What kernel version? What config? Have you tried a git bisect to see
when it broke? Etc, etc.
Also, CC'ing linuxppc-dev would have been a good idea. Not many on
lkml are even going to know what you're talking about with such sparse
details.
josh
Call trace is same for all
Call Trace:
[df835d70] [c02d27cc] emac_probe+0xf28/0x12a8 (unreliable)
[df835e50] [c023c7cc] platform_driver_probe_shim+0x40/0x54
[df835e60] [c01bf354] platform_drv_probe+0x20/0x30
[df835e70] [c01bde68] driver_probe_device+0x148/0x1ac
[df835e90] [c01be17c] __driver_attach+0xa4/0xa8
[df835eb0] [c01bcfa4] bus_for_each_dev+0x60/0x9c
[df835ee0] [c01bdbbc] driver_attach+0x24/0x34
[df835ef0] [c01bd94c] bus_add_driver+0x1b8/0x274
[df835f20] [c01be3d8] driver_register+0x6c/0x160
[df835f40] [c01bf6c4] platform_driver_register+0x68/0x78
[df835f50] [c023c998] of_register_platform_driver+0xa8/0xc4
[df835f60] [c0393e88] emac_init+0x1ac/0x1dc
[df835fa0] [c0001574] do_one_initcall+0x160/0x1a8
[df835fd0] [c037a1e8] kernel_init+0xcc/0x174
[df835ff0] [c000c5b0] kernel_thread+0x4c/0x68
Instruction dump:
419e016c 2f800007 419e0164 38130774 901a00d0 381306b0 901a00d4 7f43d378
4bf91d89 817a01a0 39200001 380b0008 <7d400028> 7d4a4b78 7d40012d 40a2fff4
---[ end trace dac0cf4779f83901 ]---
Regards,
Rup
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i=
A git bisect between 2.6.36 (working) and Linus tip (traceback) points to:
e6484930d7c73d324bccda7d43d131088da697b9 net: allocate tx queues in
register_netdevice
as causing this. I'm not entirely sure why yet, but the commit
message seems slightly off to me. It claims to make TX queue
allocation identical to RX, but from what I can tell, most of the RX
queue logic is hidden behind CONFIG_RPS, which is not set in my config
at all (and can't be due to a dep on CONFIG_SMP). This change doesn't
guard anything behind that.
A few hints would be appreciated.
josh
From: Stephen Rothwell <hidden> Date: 2010-11-01 15:37:07
Hi Josh,
On Mon, 1 Nov 2010 11:05:53 -0400 Josh Boyer [off-list ref] wrote:
A few hints would be appreciated.
Remove the call to netif_stop_queue() from emac_probe(). Apparently,
calling this before register_netdev() is now wrong (maybe always was).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
On Mon, Nov 1, 2010 at 11:36 AM, Stephen Rothwell [off-list ref] wr=
ote:
Hi Josh,
On Mon, 1 Nov 2010 11:05:53 -0400 Josh Boyer [off-list ref] wrote:
quoted
A few hints would be appreciated.
Remove the call to netif_stop_queue() from emac_probe(). =A0Apparently,
calling this before register_netdev() is now wrong (maybe always was).
Yeah, I just discovered that myself. I'm wondering
1) why we do that in that function?
2) If it needs to be removed entirely, or moved to after the
register_netdev call
3) If the call to netif_carrier_off also needs similar attention.
I can whip up a patch to remove those calls or move them after the
register, but I don't want to do that without knowing which one is
"right".
josh
From: David Miller <davem@davemloft.net> Date: 2010-11-01 15:50:09
From: Stephen Rothwell <redacted>
Date: Tue, 2 Nov 2010 02:36:50 +1100
Hi Josh,
On Mon, 1 Nov 2010 11:05:53 -0400 Josh Boyer [off-list ref] wrote:
quoted
A few hints would be appreciated.
Remove the call to netif_stop_queue() from emac_probe(). Apparently,
calling this before register_netdev() is now wrong (maybe always was).
Right.
I'll add this to net-2.6
--------------------
ibm_newemac: Remove netif_stop_queue() in emac_probe().
Touching the queue state before register_netdev is not
allowed, and besides the queue state before ->open()
is "don't care"
Reported-by: Josh Boyer <redacted>
Reported-by: Stephen Rothwell <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/ibm_newemac/core.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)