2010/2/15 John W. Linville linvi...@tuxdriver.com:
On Wed, Feb 10, 2010 at 12:02:11AM +0100, Michael Buesch wrote:
On Tuesday 09 February 2010 21:04:33 Rafał Miłecki wrote:
+#define B43_MMIO_PSM_PHY_HDR 0x492 /* programmable state
machine */
The comment doesn't make a lot
Some of the N PHYs need a revision in the handling of the PMU.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
John,
This will be needed for some of the N PHY devices - 2.6.34 amterial.
Larry
---
Index: wireless-testing/drivers/ssb/driver_chipcommon_pmu.c
On Friday 19 February 2010 16:40:40 Larry Finger wrote:
[8018c2d4] skb_put+0x74/0x90
[80c9a8e4] b43_dma_rx+0x338/0x444 [b43]
[80c87420] b43_controller_restart+0x7a0/0x974 [b43]
The traceback indicates a controller restart. Does your log show any reason
for
that event? That may help
On Friday 19 February 2010 16:40:40 Larry Finger wrote:
[8018c2d4] skb_put+0x74/0x90
[80c9a8e4] b43_dma_rx+0x338/0x444 [b43]
[80c87420] b43_controller_restart+0x7a0/0x974 [b43]
The traceback indicates a controller restart. Does your log show any reason
for
that event? That may help me
On Friday 19 February 2010 21:28:01 Stefan Wahren wrote:
@Michael: Okay, is there any method to get more reliable information
about the kernel panic (strace, ...) or a idea to faster reproduce the
kernel panic than waiting?
I think the backtrace is pretty good as-is, if you ignore the
I think the backtrace is pretty good as-is, if you ignore the
controller_restart
line. It's pretty obvious that this is an skb overflow panic caused by a
received packet. There's nothing in the trace that falsifies this, as far as I
can see.
So what if you set up another device in monitor
