* bcma problem on x86_64
@ 2013-09-05 12:32 Arend van Spriel
2013-09-06 8:05 ` Rafał Miłecki
0 siblings, 1 reply; 6+ messages in thread
From: Arend van Spriel @ 2013-09-05 12:32 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 271 bytes --]
Hi Rafał,
Since 3.11-rc4 I am seeing a problem with bcma on x64 (see attached
log). I thought I misconfigured my setup, but just upgraded to 3.11 and
I am still seeing the same issue. Did you have any reports like this?
I will double check my setup.
Regards,
Arend
[-- Attachment #2: bcma-rcu-stall.log --]
[-- Type: text/plain, Size: 14907 bytes --]
Sep 4 20:19:13 lb-bun-21 kernel: [17177.377932] bcma: bus0: Found chip with id 0xA8D8, rev 0x01 and package 0x0A
Sep 4 20:20:13 lb-bun-21 kernel: [17237.438967] INFO: rcu_sched self-detected stall on CPU { 0} (t=15000 jiffies g=7908 c=7907 q=37423)
Sep 4 20:20:13 lb-bun-21 kernel: [17237.438979] sending NMI to all CPUs:
Sep 4 20:20:13 lb-bun-21 kernel: [17237.438986] NMI backtrace for cpu 0
Sep 4 20:20:13 lb-bun-21 kernel: [17237.438994] CPU: 0 PID: 6340 Comm: insmod Tainted: G O 3.11.0-rc5-wl-testing-x64-00002-g079f98c-dirty #1
Sep 4 20:20:13 lb-bun-21 kernel: [17237.438997] Hardware name: Dell Inc. Latitude E6410/07XJP9, BIOS A07 02/15/2011
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439002] task: ffff880123b18000 ti: ffff880125006000 task.ti: ffff880125006000
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439006] RIP: 0010:[<ffffffff812f4152>] [<ffffffff812f4152>] __const_udelay+0x22/0x30
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439019] RSP: 0018:ffff88012bc03d88 EFLAGS: 00000807
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439023] RAX: 0000000041ca2400 RBX: 0000000000002710 RCX: 000000000154f0a0
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439027] RDX: 00000000002a46e1 RSI: 0000000000000007 RDI: 0000000000418958
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439031] RBP: ffff88012bc03d88 R08: 000000000000000a R09: 0000000000000000
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439034] R10: 0000000000000329 R11: 0000000000000328 R12: ffffffff81a389c0
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439038] R13: ffffffff81a389c0 R14: 0000000000000000 R15: ffffffff81aab808
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439042] FS: 00007fd6a460c700(0000) GS:ffff88012bc00000(0000) knlGS:0000000000000000
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439046] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439050] CR2: 00007fd6a41383d0 CR3: 00000001262aa000 CR4: 00000000000007f0
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439053] Stack:
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439056] ffff88012bc03da8 ffffffff8102f85a 000000000000922f ffff88012bc0db80
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439063] ffff88012bc03e18 ffffffff810dc99a ffff88012bc03dc8 ffffffff810e044c
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439068] 0000000000000092 0000000000000000 0000000000000000 ffff880125006000
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439074] Call Trace:
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439077] <IRQ>
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439081] [<ffffffff8102f85a>] arch_trigger_all_cpu_backtrace+0x6a/0x90
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439098] [<ffffffff810dc99a>] rcu_check_callbacks+0x21a/0x660
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439106] [<ffffffff810e044c>] ? acct_account_cputime+0x1c/0x20
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439113] [<ffffffff81053ee8>] update_process_times+0x48/0x80
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439122] [<ffffffff8109f2f6>] tick_sched_handle.isra.10+0x36/0x50
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439128] [<ffffffff8109f3fc>] tick_sched_timer+0x4c/0x80
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439136] [<ffffffff8106b01d>] __run_hrtimer+0x7d/0x220
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439142] [<ffffffff8109f3b0>] ? tick_nohz_handler+0xa0/0xa0
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439148] [<ffffffff8106b90f>] hrtimer_interrupt+0xff/0x240
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439155] [<ffffffff8102dd0b>] local_apic_timer_interrupt+0x3b/0x60
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439166] [<ffffffff815973e5>] smp_apic_timer_interrupt+0x45/0x60
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439172] [<ffffffff815961ca>] apic_timer_interrupt+0x6a/0x70
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439175] <EOI>
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439179] [<ffffffffa008ab0f>] ? bcma_erom_get_addr_desc.isra.7+0xf/0x90 [bcma]
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439200] [<ffffffffa008ae3c>] bcma_get_next_core+0x2ac/0x370 [bcma]
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439210] [<ffffffffa008b05b>] bcma_bus_scan+0xbb/0x310 [bcma]
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439221] [<ffffffffa008a40c>] bcma_bus_register+0x4c/0x4b0 [bcma]
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439232] [<ffffffffa008e8d4>] bcma_host_pci_probe+0x134/0x1d0 [bcma]
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439240] [<ffffffff813153f9>] pci_device_probe+0x99/0xe0
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439249] [<ffffffff813bfb2b>] driver_probe_device+0x7b/0x240
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439255] [<ffffffff813bfd9b>] __driver_attach+0xab/0xb0
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439262] [<ffffffff813bfcf0>] ? driver_probe_device+0x240/0x240
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439268] [<ffffffff813bde5e>] bus_for_each_dev+0x5e/0x90
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439274] [<ffffffff813bf62e>] driver_attach+0x1e/0x20
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439280] [<ffffffff813bf124>] bus_add_driver+0x104/0x270
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439286] [<ffffffff813c02dd>] driver_register+0x7d/0x160
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439293] [<ffffffff8131441b>] __pci_register_driver+0x4b/0x50
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439302] [<ffffffffa00a83e6>] bcma_host_pci_init+0x1e/0x20 [bcma]
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439311] [<ffffffffa00a8185>] bcma_modinit+0x1d/0x35 [bcma]
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439320] [<ffffffffa00a8168>] ? bcma_bus_early_register+0x168/0x168 [bcma]
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439328] [<ffffffff8100024e>] do_one_initcall+0x4e/0x170
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439336] [<ffffffff8106d393>] ? __blocking_notifier_call_chain+0x63/0x80
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439344] [<ffffffff810aaae8>] load_module+0x1308/0x1a50
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439350] [<ffffffff810a7d40>] ? show_initstate+0x50/0x50
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439357] [<ffffffff811464af>] ? alloc_vmap_area.isra.19+0x25f/0x310
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439365] [<ffffffff810ab2dc>] SyS_init_module+0xac/0xd0
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439372] [<ffffffff81595602>] system_call_fastpath+0x16/0x1b
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439375] Code: 2e 0f 1f 84 00 00 00 00 00 55 48 8d 04 bd 00 00 00 00 65 48 8b 14 25 a0 25 01 00 48 8d 0c 12 48 c1 e2 06 48 89 e5 48 29 ca f7 e2 <48> 8d 7a 01 ff 15 7c 60 77 00 5d c3 66 90 66 66 66 66 90 55 65
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439434] NMI backtrace for cpu 2
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439442] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G O 3.11.0-rc5-wl-testing-x64-00002-g079f98c-dirty #1
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439446] Hardware name: Dell Inc. Latitude E6410/07XJP9, BIOS A07 02/15/2011
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439449] task: ffff880127138000 ti: ffff880127132000 task.ti: ffff880127132000
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439453] RIP: 0010:[<ffffffff81342e27>] [<ffffffff81342e27>] intel_idle+0xa7/0x100
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439463] RSP: 0018:ffff880127133db8 EFLAGS: 00000046
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439466] RAX: 0000000000000020 RBX: 0000000000000008 RCX: 0000000000000001
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439470] RDX: 0000000000000000 RSI: ffff880127133fd8 RDI: 0000000000000002
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439473] RBP: ffff880127133de8 R08: 0000000000000009 R09: 0000000000000019
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439476] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000004
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439480] R13: 0000000000000020 R14: 0000000000000003 R15: 0000000000000004
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439484] FS: 0000000000000000(0000) GS:ffff88012bc80000(0000) knlGS:0000000000000000
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439488] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439491] CR2: 0000000000be46f0 CR3: 0000000001a0b000 CR4: 00000000000007e0
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439494] Stack:
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439496] ffff880127133de8 00000002810967e4 ffff88012bc99800 00000fa97738ebfe
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439502] ffffffff81a6cbb8 ffffffff81a6ca40 ffff880127133e48 ffffffff8147749f
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439508] 0000000000000000 0000000000f2b044 0000000000000000 0000000000f2b044
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439513] Call Trace:
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439523] [<ffffffff8147749f>] cpuidle_enter_state+0x4f/0xe0
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439529] [<ffffffff814775fe>] cpuidle_idle_call+0xce/0x230
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439538] [<ffffffff8100b1de>] arch_cpu_idle+0xe/0x30
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439545] [<ffffffff81094ede>] cpu_startup_entry+0xce/0x290
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439552] [<ffffffff8102c57d>] start_secondary+0x1cd/0x230
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439555] Code: 28 e0 ff ff 83 e2 08 75 22 31 d2 48 83 c0 10 48 89 d1 0f 01 c8 0f ae f0 48 8b 86 38 e0 ff ff a8 08 75 08 b1 01 4c 89 e8 0f 01 c9 <85> 1d ab 9f 72 00 75 0e 48 8d 75 dc bf 05 00 00 00 e8 93 a4 d5
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439612] NMI backtrace for cpu 1
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439621] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G O 3.11.0-rc5-wl-testing-x64-00002-g079f98c-dirty #1
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439625] Hardware name: Dell Inc. Latitude E6410/07XJP9, BIOS A07 02/15/2011
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439638] task: ffff880127105b40 ti: ffff880127130000 task.ti: ffff880127130000
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439649] RIP: 0010:[<ffffffff81342e27>] [<ffffffff81342e27>] intel_idle+0xa7/0x100
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439674] RSP: 0018:ffff880127131db8 EFLAGS: 00000046
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439687] RAX: 0000000000000020 RBX: 0000000000000008 RCX: 0000000000000001
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439697] RDX: 0000000000000000 RSI: ffff880127131fd8 RDI: 0000000000000001
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439710] RBP: ffff880127131de8 R08: 0000000000000019 R09: 00000000000000c4
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439721] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000004
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439733] R13: 0000000000000020 R14: 0000000000000003 R15: 0000000000000004
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439746] FS: 0000000000000000(0000) GS:ffff88012bc40000(0000) knlGS:0000000000000000
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439759] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439771] CR2: 00007f5ec7d9b000 CR3: 0000000001a0b000 CR4: 00000000000007e0
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439780] Stack:
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439787] ffff880127131de8 00000001810967e4 ffff88012bc59800 00000fa97738f6ca
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439793] ffffffff81a6cbb8 ffffffff81a6ca40 ffff880127131e48 ffffffff8147749f
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439799] 0000000000000000 0000000000f29705 0000000000000000 0000000000f29705
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439805] Call Trace:
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439814] [<ffffffff8147749f>] cpuidle_enter_state+0x4f/0xe0
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439822] [<ffffffff814775fe>] cpuidle_idle_call+0xce/0x230
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439829] [<ffffffff8100b1de>] arch_cpu_idle+0xe/0x30
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439836] [<ffffffff81094ede>] cpu_startup_entry+0xce/0x290
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439843] [<ffffffff8102c57d>] start_secondary+0x1cd/0x230
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439847] Code: 28 e0 ff ff 83 e2 08 75 22 31 d2 48 83 c0 10 48 89 d1 0f 01 c8 0f ae f0 48 8b 86 38 e0 ff ff a8 08 75 08 b1 01 4c 89 e8 0f 01 c9 <85> 1d ab 9f 72 00 75 0e 48 8d 75 dc bf 05 00 00 00 e8 93 a4 d5
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439905] NMI backtrace for cpu 3
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439913] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G O 3.11.0-rc5-wl-testing-x64-00002-g079f98c-dirty #1
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439915] Hardware name: Dell Inc. Latitude E6410/07XJP9, BIOS A07 02/15/2011
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439918] task: ffff8801271396d0 ti: ffff880127134000 task.ti: ffff880127134000
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439921] RIP: 0010:[<ffffffff81342e27>] [<ffffffff81342e27>] intel_idle+0xa7/0x100
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439927] RSP: 0018:ffff880127135db8 EFLAGS: 00000046
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439930] RAX: 0000000000000020 RBX: 0000000000000008 RCX: 0000000000000001
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439932] RDX: 0000000000000000 RSI: ffff880127135fd8 RDI: 0000000000000003
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439935] RBP: ffff880127135de8 R08: 0000000000000e79 R09: 00000000001a62c9
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439937] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000004
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439939] R13: 0000000000000020 R14: 0000000000000003 R15: 0000000000000004
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439942] FS: 0000000000000000(0000) GS:ffff88012bcc0000(0000) knlGS:0000000000000000
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439945] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439948] CR2: 0000000000bff54e CR3: 0000000001a0b000 CR4: 00000000000007e0
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439950] Stack:
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439952] ffff880127135de8 00000003810967e4 ffff88012bcd9800 00000fa97738df12
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439956] ffffffff81a6cbb8 ffffffff81a6ca40 ffff880127135e48 ffffffff8147749f
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439960] 0000000000000000 00000000003b7c0c 0000000000000000 00000000003b7c0c
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439964] Call Trace:
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439970] [<ffffffff8147749f>] cpuidle_enter_state+0x4f/0xe0
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439975] [<ffffffff814775fe>] cpuidle_idle_call+0xce/0x230
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439980] [<ffffffff8100b1de>] arch_cpu_idle+0xe/0x30
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439984] [<ffffffff81094ede>] cpu_startup_entry+0xce/0x290
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439989] [<ffffffff8102c57d>] start_secondary+0x1cd/0x230
Sep 4 20:20:13 lb-bun-21 kernel: [17237.439992] Code: 28 e0 ff ff 83 e2 08 75 22 31 d2 48 83 c0 10 48 89 d1 0f 01 c8 0f ae f0 48 8b 86 38 e0 ff ff a8 08 75 08 b1 01 4c 89 e8 0f 01 c9 <85> 1d ab 9f 72 00 75 0e 48 8d 75 dc bf 05 00 00 00 e8 93 a4 d5
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bcma problem on x86_64
2013-09-05 12:32 bcma problem on x86_64 Arend van Spriel
@ 2013-09-06 8:05 ` Rafał Miłecki
2013-09-06 9:05 ` Arend van Spriel
0 siblings, 1 reply; 6+ messages in thread
From: Rafał Miłecki @ 2013-09-06 8:05 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
Hi,
2013/9/5 Arend van Spriel <arend@broadcom.com>:
> Since 3.11-rc4 I am seeing a problem with bcma on x64 (see attached log). I
> thought I misconfigured my setup, but just upgraded to 3.11 and I am still
> seeing the same issue. Did you have any reports like this?
Unfortunately I wasn't testing final 3.11 with x86_64, I'll give it a
try over the weekend.
--
Rafał
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bcma problem on x86_64
2013-09-06 8:05 ` Rafał Miłecki
@ 2013-09-06 9:05 ` Arend van Spriel
2013-09-06 15:25 ` Arend van Spriel
0 siblings, 1 reply; 6+ messages in thread
From: Arend van Spriel @ 2013-09-06 9:05 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: linux-wireless
On 09/06/2013 10:05 AM, Rafał Miłecki wrote:
> Hi,
>
> 2013/9/5 Arend van Spriel <arend@broadcom.com>:
>> Since 3.11-rc4 I am seeing a problem with bcma on x64 (see attached log). I
>> thought I misconfigured my setup, but just upgraded to 3.11 and I am still
>> seeing the same issue. Did you have any reports like this?
>
> Unfortunately I wasn't testing final 3.11 with x86_64, I'll give it a
> try over the weekend.
>
I am bisecting. Will let you know when I find something.
Gr. AvS
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bcma problem on x86_64
2013-09-06 9:05 ` Arend van Spriel
@ 2013-09-06 15:25 ` Arend van Spriel
2013-09-06 16:37 ` Hauke Mehrtens
0 siblings, 1 reply; 6+ messages in thread
From: Arend van Spriel @ 2013-09-06 15:25 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: linux-wireless, Hauke Mehrtens
On 09/06/2013 11:05 AM, Arend van Spriel wrote:
> On 09/06/2013 10:05 AM, Rafał Miłecki wrote:
>> Hi,
>>
>> 2013/9/5 Arend van Spriel <arend@broadcom.com>:
>>> Since 3.11-rc4 I am seeing a problem with bcma on x64 (see attached
>>> log). I
>>> thought I misconfigured my setup, but just upgraded to 3.11 and I am
>>> still
>>> seeing the same issue. Did you have any reports like this?
>>
>> Unfortunately I wasn't testing final 3.11 with x86_64, I'll give it a
>> try over the weekend.
>>
>
> I am bisecting. Will let you know when I find something.
Bisect points to:
fd4edf197544bae1c77d84bad354aa7ce1d08ce1 is the first bad commit
commit fd4edf197544bae1c77d84bad354aa7ce1d08ce1
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date: Mon Jul 15 13:15:08 2013 +0200
bcma: fix handling of big addrl
The return value of bcma_erom_get_addr_desc() is a unsigned value
and it
could wrap around in the two complement writing. This happens for one
core in the BCM4708 SoC.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It is probably caused by using IS_ERR_VALUE() macro which does a
unsigned long cast, which gives different results on 64-bit platform.
This patch was submitted upstream yesterday by Dave for 3.12-rc1.
Regards,
Arend
> Gr. AvS
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-wireless" 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 [flat|nested] 6+ messages in thread
* Re: bcma problem on x86_64
2013-09-06 15:25 ` Arend van Spriel
@ 2013-09-06 16:37 ` Hauke Mehrtens
2013-09-06 16:50 ` Arend van Spriel
0 siblings, 1 reply; 6+ messages in thread
From: Hauke Mehrtens @ 2013-09-06 16:37 UTC (permalink / raw)
To: Arend van Spriel; +Cc: Rafał Miłecki, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]
On 09/06/2013 05:25 PM, Arend van Spriel wrote:
> On 09/06/2013 11:05 AM, Arend van Spriel wrote:
>> On 09/06/2013 10:05 AM, Rafał Miłecki wrote:
>>> Hi,
>>>
>>> 2013/9/5 Arend van Spriel <arend@broadcom.com>:
>>>> Since 3.11-rc4 I am seeing a problem with bcma on x64 (see attached
>>>> log). I
>>>> thought I misconfigured my setup, but just upgraded to 3.11 and I am
>>>> still
>>>> seeing the same issue. Did you have any reports like this?
>>>
>>> Unfortunately I wasn't testing final 3.11 with x86_64, I'll give it a
>>> try over the weekend.
>>>
>>
>> I am bisecting. Will let you know when I find something.
>
> Bisect points to:
>
> fd4edf197544bae1c77d84bad354aa7ce1d08ce1 is the first bad commit
> commit fd4edf197544bae1c77d84bad354aa7ce1d08ce1
> Author: Hauke Mehrtens <hauke@hauke-m.de>
> Date: Mon Jul 15 13:15:08 2013 +0200
>
> bcma: fix handling of big addrl
>
> The return value of bcma_erom_get_addr_desc() is a unsigned value
> and it
> could wrap around in the two complement writing. This happens for one
> core in the BCM4708 SoC.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> It is probably caused by using IS_ERR_VALUE() macro which does a
> unsigned long cast, which gives different results on 64-bit platform.
>
> This patch was submitted upstream yesterday by Dave for 3.12-rc1.
>
> Regards,
> Arend
>
Hi Arend,
Thanks for spotting this. This commit is not in final 3.11, otherwise
I would have suspected it before.
Could you please try the attached patch.
Hauke
[-- Attachment #2: 0001-bcma-fix-error-handling.patch --]
[-- Type: text/x-patch, Size: 2529 bytes --]
>From 4a6337b38369977b94d6e752c57b09e7f4539830 Mon Sep 17 00:00:00 2001
From: Hauke Mehrtens <hauke@hauke-m.de>
Date: Fri, 6 Sep 2013 18:32:41 +0200
Subject: [PATCH] bcma: fix error handling
---
drivers/bcma/scan.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/bcma/scan.c b/drivers/bcma/scan.c
index cd6b20f..b7906d5 100644
--- a/drivers/bcma/scan.c
+++ b/drivers/bcma/scan.c
@@ -269,6 +269,8 @@ static struct bcma_device *bcma_find_core_reverse(struct bcma_bus *bus, u16 core
return NULL;
}
+#define IS_ERR_VALUE_U32 unlikely((x) >= (u32)-MAX_ERRNO)
+
static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
struct bcma_device_id *match, int core_num,
struct bcma_device *core)
@@ -351,11 +353,11 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
* the main register space for the core
*/
tmp = bcma_erom_get_addr_desc(bus, eromptr, SCAN_ADDR_TYPE_SLAVE, 0);
- if (tmp == 0 || IS_ERR_VALUE(tmp)) {
+ if (tmp == 0 || IS_ERR_VALUE_U32(tmp)) {
/* Try again to see if it is a bridge */
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_BRIDGE, 0);
- if (tmp == 0 || IS_ERR_VALUE(tmp)) {
+ if (tmp == 0 || IS_ERR_VALUE_U32(tmp)) {
return -EILSEQ;
} else {
bcma_info(bus, "Bridge found\n");
@@ -369,7 +371,7 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
for (j = 0; ; j++) {
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_SLAVE, i);
- if (IS_ERR_VALUE(tmp)) {
+ if (IS_ERR_VALUE_U32(tmp)) {
/* no more entries for port _i_ */
/* pr_debug("erom: slave port %d "
* "has %d descriptors\n", i, j); */
@@ -386,7 +388,7 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
for (j = 0; ; j++) {
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_MWRAP, i);
- if (IS_ERR_VALUE(tmp)) {
+ if (IS_ERR_VALUE_U32(tmp)) {
/* no more entries for port _i_ */
/* pr_debug("erom: master wrapper %d "
* "has %d descriptors\n", i, j); */
@@ -404,7 +406,7 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
for (j = 0; ; j++) {
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_SWRAP, i + hack);
- if (IS_ERR_VALUE(tmp)) {
+ if (IS_ERR_VALUE_U32(tmp)) {
/* no more entries for port _i_ */
/* pr_debug("erom: master wrapper %d "
* has %d descriptors\n", i, j); */
--
1.7.10.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: bcma problem on x86_64
2013-09-06 16:37 ` Hauke Mehrtens
@ 2013-09-06 16:50 ` Arend van Spriel
0 siblings, 0 replies; 6+ messages in thread
From: Arend van Spriel @ 2013-09-06 16:50 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: Rafał Miłecki, linux-wireless
On 09/06/2013 06:37 PM, Hauke Mehrtens wrote:
> On 09/06/2013 05:25 PM, Arend van Spriel wrote:
>> On 09/06/2013 11:05 AM, Arend van Spriel wrote:
>>> On 09/06/2013 10:05 AM, Rafał Miłecki wrote:
>>>> Hi,
>>>>
>>>> 2013/9/5 Arend van Spriel <arend@broadcom.com>:
>>>>> Since 3.11-rc4 I am seeing a problem with bcma on x64 (see attached
>>>>> log). I
>>>>> thought I misconfigured my setup, but just upgraded to 3.11 and I am
>>>>> still
>>>>> seeing the same issue. Did you have any reports like this?
>>>>
>>>> Unfortunately I wasn't testing final 3.11 with x86_64, I'll give it a
>>>> try over the weekend.
>>>>
>>>
>>> I am bisecting. Will let you know when I find something.
>>
>> Bisect points to:
>>
>> fd4edf197544bae1c77d84bad354aa7ce1d08ce1 is the first bad commit
>> commit fd4edf197544bae1c77d84bad354aa7ce1d08ce1
>> Author: Hauke Mehrtens <hauke@hauke-m.de>
>> Date: Mon Jul 15 13:15:08 2013 +0200
>>
>> bcma: fix handling of big addrl
>>
>> The return value of bcma_erom_get_addr_desc() is a unsigned value
>> and it
>> could wrap around in the two complement writing. This happens for one
>> core in the BCM4708 SoC.
>>
>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
>> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>
>> It is probably caused by using IS_ERR_VALUE() macro which does a
>> unsigned long cast, which gives different results on 64-bit platform.
>>
>> This patch was submitted upstream yesterday by Dave for 3.12-rc1.
>>
>> Regards,
>> Arend
>>
> Hi Arend,
>
> Thanks for spotting this. This commit is not in final 3.11, otherwise
> I would have suspected it before.
Yeah. It will need to be fixed for 3.12 after the merge window.
> Could you please try the attached patch.
Just tried my own patch, which essentially does the same (not using a
macro).
So you may add
Acked-by: or Tested-by: Arend van Spriel <arend@broadcom.com>
Whatever you think is most appropriate.
Regards,
Arend
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-09-06 16:50 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-05 12:32 bcma problem on x86_64 Arend van Spriel
2013-09-06 8:05 ` Rafał Miłecki
2013-09-06 9:05 ` Arend van Spriel
2013-09-06 15:25 ` Arend van Spriel
2013-09-06 16:37 ` Hauke Mehrtens
2013-09-06 16:50 ` Arend van Spriel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).