* kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069!
@ 2007-01-05 19:03 Thibaut VARENE
2007-01-09 9:26 ` Jarek Poplawski
0 siblings, 1 reply; 20+ messages in thread
From: Thibaut VARENE @ 2007-01-05 19:03 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 917 bytes --]
Hi,
I've been experiencing this bug on my Pegasos II (PPC G4 1GHz, 512M
RAM) box for a while: I can reliably kill my machine in about half an
hour while watching some video read from a remote nfs volume (hence
the "mplayer" task in the following dump). It was relatively uneasy to
get proper debug info as the crash happens while video was playing on
the screen, but it's there anyway :)
This particular dump comes from kernel 2.6.19-ck2 but I reproduced the
bug with vanilla 2.6.19 too, so the bug lives in mainline. I'm not
really familiar with that particular code, but I'd gladly provide as
much debug info as I can.
The box is hooked to a gigabit switch and the NIC is configured as
gigabit too. Interestingly, when I reboot immediately after the crash,
the NIC gets a bogus MAC address, and I have to reboot again to get
back to normal.
HTH
T-Bone
--
Thibaut VARENE
http://www.parisc-linux.org/~varenet/
[-- Attachment #2: panicdump.txt --]
[-- Type: text/plain, Size: 4972 bytes --]
kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069!
Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT
Modules linked in: nfs lockd sunrpc eeprom sbp2 scsi_mod eth1394 uhci_hcd ohci14
NIP: C020F0E0 LR: C0210C54 CTR: C0210B98
REGS: c7f6f670 TRAP: 0700 Not tainted (2.6.19-ck2)
MSR: 00021032 <ME,IR,DR> CR: 24022488 XER: 00000000
TASK = c49a8d10[2227] 'mplayer' THREAD: c7f6e000
GPR00: 00000000 C7F6F720 C49A8D10 DFF41260 DFF41000 0000000B CE0CF932 00000000
GPR08: 00000CEA 00000001 00001000 00000CEB 44022422 1085F9B8 C50B0368 0000B241
GPR16: C7F6FD28 0000B240 00000000 DFF412DC C0380000 00009032 00000400 C7F6E000
GPR24: 00000000 00000000 DFF41000 C7F6E000 C0210B98 CE0EAC80 DFF41260 CE0CF900
NIP [C020F0E0] eth_alloc_tx_desc_index+0x44/0x50
LR [C0210C54] mv643xx_eth_start_xmit+0xbc/0x3b8
Call Trace:
[C7F6F720] [CE0CF930] 0xce0cf930 (unreliable)
[C7F6F760] [C0299714] dev_hard_start_xmit+0x1d4/0x2c8
[C7F6F780] [C029C0E0] dev_queue_xmit+0x2bc/0x334
[C7F6F7A0] [C02B6E1C] ip_output+0x124/0x248
[C7F6F7C0] [C02B7E54] ip_queue_xmit+0x17c/0x404
[C7F6F830] [C02C91BC] tcp_transmit_skb+0x38c/0x7dc
[C7F6F860] [C02C65E4] __tcp_ack_snd_check+0x64/0xbc
[C7F6F870] [C02C8100] tcp_rcv_established+0x5d4/0x980
[C7F6F8A0] [C02CEDCC] tcp_v4_do_rcv+0xd8/0x3e4
[C7F6F8D0] [C02D1610] tcp_v4_rcv+0x788/0x98c
[C7F6F900] [C02B2594] ip_local_deliver+0xe4/0x1a4
[C7F6F920] [C02B2A50] ip_rcv+0x288/0x46c
[C7F6F950] [C0299308] netif_receive_skb+0x214/0x304
[C7F6F980] [C0211CBC] mv643xx_poll+0x41c/0x48c
[C7F6F9D0] [C029B550] net_rx_action+0x98/0x200
[C7F6FA00] [C0026958] __do_softirq+0x80/0xf4
[C7F6FA30] [C0006930] do_softirq+0x58/0x5c
[C7F6FA40] [C0026408] irq_exit+0x60/0x80
[C7F6FA50] [C00069DC] do_IRQ+0xa8/0xc8
[C7F6FA60] [C0012498] ret_from_except+0x0/0x14
--- Exception: 501 at __kmalloc+0x30/0xc0
LR = rpc_malloc+0x48/0xac [sunrpc]
[C7F6FB20] [C3D72508] 0xc3d72508 (unreliable)
[C7F6FB30] [E2A88E18] rpc_malloc+0x48/0xac [sunrpc]
[C7F6FB40] [E2A835F8] call_allocate+0x88/0x108 [sunrpc]
[C7F6FB60] [E2A89554] __rpc_execute+0x94/0x248 [sunrpc]
[C7F6FB80] [E2B0EEB0] nfs_execute_read+0x40/0x64 [nfs]
[C7F6FBB0] [E2B0F6A4] nfs_pagein_one+0x2a0/0x300 [nfs]
[C7F6FBF0] [E2B0FA9C] nfs_readpages+0x118/0x1f8 [nfs]
[C7F6FC40] [C00521DC] __do_page_cache_readahead+0x1e8/0x318
[C7F6FCD0] [C0052390] blockable_page_cache_readahead+0x84/0x114
[C7F6FCF0] [C00524A4] make_ahead_window+0x84/0xd4
[C7F6FD00] [C00525AC] page_cache_readahead+0xb8/0x220
[C7F6FD20] [C004B00C] do_generic_mapping_read+0x574/0x5e8
[C7F6FDC0] [C004D624] generic_file_aio_read+0x120/0x274
[C7F6FE00] [E2B06F00] nfs_file_read+0xc4/0xe4 [nfs]
[C7F6FE30] [C006EB50] do_sync_read+0xc4/0x138
[C7F6FEF0] [C006F734] vfs_read+0xc4/0x1a4
[C7F6FF10] [C006FC24] sys_read+0x4c/0x90
[C7F6FF40] [C0011DF0] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xf4f54d8
LR = 0x101e83a8
Instruction dump:
5400fffe 0f000000 81030020 81230024 39680001 7c0b53d6 7c0051d6 7d605850
7d694a78 91630020 7d290034 5529d97e <0f090000> 7d034378 4e800020 2f840001
<0>Kernel panic - not syncing: Fatal exception in interrupt
<0>Rebooting in 180 seconds..
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-05 19:03 kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! Thibaut VARENE @ 2007-01-09 9:26 ` Jarek Poplawski 2007-01-09 10:27 ` Thibaut VARENE 0 siblings, 1 reply; 20+ messages in thread From: Jarek Poplawski @ 2007-01-09 9:26 UTC (permalink / raw) To: Thibaut VARENE; +Cc: netdev On 05-01-2007 20:03, Thibaut VARENE wrote: > Hi, > > I've been experiencing this bug on my Pegasos II (PPC G4 1GHz, 512M ... > [C7F6FA60] [C0012498] ret_from_except+0x0/0x14 > --- Exception: 501 at __kmalloc+0x30/0xc0 > LR = rpc_malloc+0x48/0xac [sunrpc] > [C7F6FB20] [C3D72508] 0xc3d72508 (unreliable) > [C7F6FB30] [E2A88E18] rpc_malloc+0x48/0xac [sunrpc] > [C7F6FB40] [E2A835F8] call_allocate+0x88/0x108 [sunrpc] > [C7F6FB60] [E2A89554] __rpc_execute+0x94/0x248 [sunrpc] Aren't there any other warnings displayed before? No problems with memory or disk? Regards, Jarek P. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-09 9:26 ` Jarek Poplawski @ 2007-01-09 10:27 ` Thibaut VARENE 2007-01-09 10:52 ` Jarek Poplawski ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Thibaut VARENE @ 2007-01-09 10:27 UTC (permalink / raw) To: Jarek Poplawski; +Cc: netdev On 1/9/07, Jarek Poplawski <jarkao2@o2.pl> wrote: > On 05-01-2007 20:03, Thibaut VARENE wrote: > > Hi, > > > > I've been experiencing this bug on my Pegasos II (PPC G4 1GHz, 512M > ... > > [C7F6FA60] [C0012498] ret_from_except+0x0/0x14 > > --- Exception: 501 at __kmalloc+0x30/0xc0 > > LR = rpc_malloc+0x48/0xac [sunrpc] > > [C7F6FB20] [C3D72508] 0xc3d72508 (unreliable) > > [C7F6FB30] [E2A88E18] rpc_malloc+0x48/0xac [sunrpc] > > [C7F6FB40] [E2A835F8] call_allocate+0x88/0x108 [sunrpc] > > [C7F6FB60] [E2A89554] __rpc_execute+0x94/0x248 [sunrpc] > > Aren't there any other warnings displayed before? No, I've pasted the full dump that appeared on the serial console I had setup when the crash occured. > No problems with memory or disk? I suspected both and changed both the disk and the ram for quality parts, that I tested afterwards. Both passed thorough tests. Finally, using the other NIC on the box (a VIA Rhine II, 100Mbps), works absolutely fine. HTH T-Bone (PS: please CC me in answers) -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-09 10:27 ` Thibaut VARENE @ 2007-01-09 10:52 ` Jarek Poplawski 2007-01-09 10:56 ` Thibaut VARENE 2007-01-09 10:57 ` Jarek Poplawski 2007-01-09 13:02 ` Jarek Poplawski 2 siblings, 1 reply; 20+ messages in thread From: Jarek Poplawski @ 2007-01-09 10:52 UTC (permalink / raw) To: Thibaut VARENE; +Cc: netdev On Tue, Jan 09, 2007 at 11:27:59AM +0100, Thibaut VARENE wrote: ... > I suspected both and changed both the disk and the ram for quality > parts, that I tested afterwards. Both passed thorough tests. You wrote about half an hour, so overheating was also considered, I presume. > Finally, using the other NIC on the box (a VIA Rhine II, 100Mbps), > works absolutely fine. So it looks like the card/driver (or maybe this specimen?). Jarek P. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-09 10:52 ` Jarek Poplawski @ 2007-01-09 10:56 ` Thibaut VARENE 2007-01-09 11:48 ` Jarek Poplawski 0 siblings, 1 reply; 20+ messages in thread From: Thibaut VARENE @ 2007-01-09 10:56 UTC (permalink / raw) To: Jarek Poplawski; +Cc: netdev On 1/9/07, Jarek Poplawski <jarkao2@o2.pl> wrote: > On Tue, Jan 09, 2007 at 11:27:59AM +0100, Thibaut VARENE wrote: > ... > > I suspected both and changed both the disk and the ram for quality > > parts, that I tested afterwards. Both passed thorough tests. > > You wrote about half an hour, so overheating was also > considered, I presume. Yes, but since it works fine with the other NIC... :) > > Finally, using the other NIC on the box (a VIA Rhine II, 100Mbps), > > works absolutely fine. > > So it looks like the card/driver (or maybe this specimen?). I'm suspecting the driver, but I'm not a specialist :) It's true that this particular card specimen could be damaged even though that seems a bit unlikely. HTH T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-09 10:56 ` Thibaut VARENE @ 2007-01-09 11:48 ` Jarek Poplawski 0 siblings, 0 replies; 20+ messages in thread From: Jarek Poplawski @ 2007-01-09 11:48 UTC (permalink / raw) To: Thibaut VARENE; +Cc: netdev On Tue, Jan 09, 2007 at 11:56:59AM +0100, Thibaut VARENE wrote: ... > I'm suspecting the driver, but I'm not a specialist :) No problem, me also! I've also suspected the driver, looked at the code, found nothing yet (as expected), but this info about exception in malloc, introduces some doubts... Jarek P. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-09 10:27 ` Thibaut VARENE 2007-01-09 10:52 ` Jarek Poplawski @ 2007-01-09 10:57 ` Jarek Poplawski 2007-01-09 13:02 ` Jarek Poplawski 2 siblings, 0 replies; 20+ messages in thread From: Jarek Poplawski @ 2007-01-09 10:57 UTC (permalink / raw) To: Thibaut VARENE; +Cc: netdev On Tue, Jan 09, 2007 at 11:27:59AM +0100, Thibaut VARENE wrote: ... > Finally, using the other NIC on the box (a VIA Rhine II, 100Mbps), > works absolutely fine. ... and the speed could matter here too ... Jarek P. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-09 10:27 ` Thibaut VARENE 2007-01-09 10:52 ` Jarek Poplawski 2007-01-09 10:57 ` Jarek Poplawski @ 2007-01-09 13:02 ` Jarek Poplawski 2007-01-09 17:44 ` Thibaut VARENE 2 siblings, 1 reply; 20+ messages in thread From: Jarek Poplawski @ 2007-01-09 13:02 UTC (permalink / raw) To: Thibaut VARENE; +Cc: netdev On Tue, Jan 09, 2007 at 11:27:59AM +0100, Thibaut VARENE wrote: ... > I suspected both and changed both the disk and the ram for quality > parts, that I tested afterwards. Both passed thorough tests. > > Finally, using the other NIC on the box (a VIA Rhine II, 100Mbps), > works absolutely fine. If you are not tired, I'd suggest two more tests: - as above but with NIC set to 100Mbps also, - long downloading but without nfs e.g. ftp (btw. there were some patches after 2.6.19 for rpc memory races). Jarek P. PS: Maintainers were cc-ed, I hope? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-09 13:02 ` Jarek Poplawski @ 2007-01-09 17:44 ` Thibaut VARENE 2007-01-09 20:05 ` Dale Farnsworth 0 siblings, 1 reply; 20+ messages in thread From: Thibaut VARENE @ 2007-01-09 17:44 UTC (permalink / raw) To: Jarek Poplawski; +Cc: netdev, dale, mlachwani [-- Attachment #1: Type: text/plain, Size: 1946 bytes --] On 1/9/07, Jarek Poplawski <jarkao2@o2.pl> wrote: > On Tue, Jan 09, 2007 at 11:27:59AM +0100, Thibaut VARENE wrote: > ... > > I suspected both and changed both the disk and the ram for quality > > parts, that I tested afterwards. Both passed thorough tests. > > > > Finally, using the other NIC on the box (a VIA Rhine II, 100Mbps), > > works absolutely fine. > > If you are not tired, I'd suggest two more tests: I volunteered to help :) For the sake of testing up-to-date code, I performed the following tests with 2.6.20-rc4. First test was the usual nfs video playback. Crashdump is panic-2.6.20-rc4-nfs.txt. Went down in about 20mn. > - as above but with NIC set to 100Mbps also, Couldn't crash the machine (or at least it didn't happen in the time frame I was willing to wait for doing ftp downloads, ~20mn). One note though: The throughput of the card was terribly sucky when set in 100-FD: I couldn't get more than 5,5MB/s doing ftp get writing to /dev/null (to rule out disk perf), ie, half the max link speed, though the /only/ thing I changed in the setup was the link speed (same switch - made sure it properly detected link speed/duplex, same file server, same everything else). When configured in 1000-FD, still writing to /dev/null I could get about 60MB/s. Again half link speed, but there, I suppose that the remote fileserver couldn't pull data faster from the disks :) > - long downloading but without nfs e.g. ftp That was fast and easy. In 1000-FD, I took down the box in 2s (after downloading 90MB). Crashdump is panic-2.6.20-rc4-ftp.txt > (btw. there were some patches after 2.6.19 > for rpc memory races). It seems that's something else. I think I also reproduced the bug while surfing the internet with firefox, but I didn't have serial line hooked to capture a dump, unfortunately. > PS: Maintainers were cc-ed, I hope? Now they are :) HTH T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ [-- Attachment #2: panic-2.6.20-rc4-ftp.txt --] [-- Type: text/plain, Size: 3726 bytes --] Debian GNU/Linux 4.0 Alucard ttyS0 Alucard login: ------------[ cut here ]------------ kernel BUG at drivers/net/mv643xx_eth.c:1071! Oops: Exception in kernel mode, sig: 5 [#1] PREEMPT Modules linked in: eeprom sbp2 scsi_mod eth1394 uhci_hcd ohci1394 parport_pc pae NIP: C0210B40 LR: C02126DC CTR: C0212620 REGS: da247ac0 TRAP: 0700 Not tainted (2.6.20-rc4) MSR: 00021032 <ME,IR,DR> CR: 28222488 XER: 00000000 TASK = db82a050[1780] 'ncftp' THREAD: da246000 GPR00: 00000000 DA247B70 DB82A050 CFB14260 CFB14000 0000000B DED5FD72 00000000 GPR08: 00000819 00000001 00001000 0000081A 48222422 10056CD0 28004422 C03D9BF8 GPR16: 00000000 00000000 00000000 DA246000 00000001 CFB142BC 00009032 00000000 GPR24: 00000000 00000000 C03E0000 CFB14000 C0212620 DEDFD160 CFB14260 DED5FD40 NIP [C0210B40] eth_alloc_tx_desc_index+0x44/0x50 LR [C02126DC] mv643xx_eth_start_xmit+0xbc/0x3b8 Call Trace: [DA247B70] [DED5FD70] 0xded5fd70 (unreliable) [DA247BB0] [C029F258] dev_hard_start_xmit+0x1d4/0x2c8 [DA247BD0] [C02A1BF4] dev_queue_xmit+0x2bc/0x334 [DA247BF0] [C02BC8A8] ip_output+0x120/0x244 [DA247C10] [C02BD8DC] ip_queue_xmit+0x17c/0x408 [DA247C80] [C02CEB1C] tcp_transmit_skb+0x358/0x7bc [DA247CC0] [C02CBF80] __tcp_ack_snd_check+0x64/0xbc [DA247CD0] [C02CDA94] tcp_rcv_established+0x5d4/0x980 [DA247D00] [C02D4764] tcp_v4_do_rcv+0xe0/0x3c0 [DA247D30] [C0294B58] release_sock+0x7c/0xf4 [DA247D50] [C02C5C1C] tcp_recvmsg+0x4c8/0xbcc [DA247DB0] [C0294490] sock_common_recvmsg+0x3c/0x60 [DA247DD0] [C02920E4] sock_aio_read+0x10c/0x114 [DA247E30] [C006F210] do_sync_read+0xc4/0x138 [DA247EF0] [C006FECC] vfs_read+0x19c/0x1a4 [DA247F10] [C00702E4] sys_read+0x4c/0x90 [DA247F40] [C00122EC] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xff5ba98 LR = 0x10032fc0 Instruction dump: 5400fffe 0f000000 81030020 81230024 39680001 7c0b53d6 7c0051d6 7d605850 7d694a78 91630020 7d290034 5529d97e <0f090000> 7d034378 4e800020 2f840001 <0>Kernel panic - not syncing: Fatal exception in interrupt <0>Rebooting in 180 seconds..<4>atkbd.c: Spurious ACK on isa0060/serio0. Some . atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access ha. atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access ha. atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access ha. atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access ha. [-- Attachment #3: panic-2.6.20-rc4-nfs.txt --] [-- Type: text/plain, Size: 4455 bytes --] Debian GNU/Linux 4.0 Alucard ttyS0 Alucard login: [drm] Setting GART location based on new memory map [drm] Loading R200 Microcode [drm] writeback test succeeded in 1 usecs ------------[ cut here ]------------ kernel BUG at drivers/net/mv643xx_eth.c:1071! Oops: Exception in kernel mode, sig: 5 [#1] PREEMPT Modules linked in: nfs lockd sunrpc NIP: C0210B40 LR: C02126DC CTR: C0212620 REGS: d8961aa0 TRAP: 0700 Not tainted (2.6.20-rc4) MSR: 00021032 <ME,IR,DR> CR: 24022088 XER: 00000000 TASK = dffd91e0[3879] 'rpciod/0' THREAD: d8960000 GPR00: 00000000 D8961B50 DFFD91E0 CFB1E260 CFB1E000 0000000B DECA91B2 00000000 GPR08: 00000B6A 00000001 00001000 00000B6B 44022022 FFF045B4 009B52B4 017FFA7C GPR16: 009B52AC 017FFA80 009B4E68 D8960000 C03B0000 CFB1E2BC 00009032 00000000 GPR24: 00000000 00000000 C03E0000 CFB1E000 C0212620 DF0033A0 CFB1E260 DECA9180 NIP [C0210B40] eth_alloc_tx_desc_index+0x44/0x50 LR [C02126DC] mv643xx_eth_start_xmit+0xbc/0x3b8 Call Trace: [D8961B50] [DECA91B0] 0xdeca91b0 (unreliable) [D8961B90] [C029F258] dev_hard_start_xmit+0x1d4/0x2c8 [D8961BB0] [C02A1BF4] dev_queue_xmit+0x2bc/0x334 [D8961BD0] [C02BC8A8] ip_output+0x120/0x244 [D8961BF0] [C02BD8DC] ip_queue_xmit+0x17c/0x408 [D8961C60] [C02CEB1C] tcp_transmit_skb+0x358/0x7bc [D8961CA0] [C02CBF80] __tcp_ack_snd_check+0x64/0xbc [D8961CB0] [C02CDA94] tcp_rcv_established+0x5d4/0x980 [D8961CE0] [C02D4764] tcp_v4_do_rcv+0xe0/0x3c0 [D8961D10] [C02D6F2C] tcp_v4_rcv+0x760/0x940 [D8961D40] [C02B805C] ip_local_deliver+0xe4/0x1a4 [D8961D60] [C02B8518] ip_rcv+0x288/0x46c [D8961D90] [C029EE4C] netif_receive_skb+0x214/0x304 [D8961DC0] [C0213744] mv643xx_poll+0x41c/0x48c [D8961E10] [C02A1064] net_rx_action+0x98/0x200 [D8961E40] [C0026D48] __do_softirq+0x80/0xf4 [D8961E70] [C00068F4] do_softirq+0x58/0x5c [D8961E80] [C00267FC] irq_exit+0x60/0x80 [D8961E90] [C00069A0] do_IRQ+0xa8/0xc8 [D8961EA0] [C0012994] ret_from_except+0x0/0x14 --- Exception: 501 at add_wait_queue+0x50/0x84 LR = worker_thread+0x100/0x154 [D8961F60] [D988CE28] 0xd988ce28 (unreliable) [D8961F70] [C0035AB4] worker_thread+0x100/0x154 [D8961FC0] [C0039B4C] kthread+0xc0/0xfc [D8961FF0] [C00131C4] kernel_thread+0x44/0x60 Instruction dump: 5400fffe 0f000000 81030020 81230024 39680001 7c0b53d6 7c0051d6 7d605850 7d694a78 91630020 7d290034 5529d97e <0f090000> 7d034378 4e800020 2f840001 <0>Kernel panic - not syncing: Fatal exception in interrupt <0>Rebooting in 180 seconds..<4>atkbd.c: Spurious ACK on isa0060/serio0. Some . atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access ha. atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access ha. atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access ha. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-09 17:44 ` Thibaut VARENE @ 2007-01-09 20:05 ` Dale Farnsworth 2007-01-09 21:05 ` Thibaut VARENE 0 siblings, 1 reply; 20+ messages in thread From: Dale Farnsworth @ 2007-01-09 20:05 UTC (permalink / raw) To: Thibaut VARENE; +Cc: Jarek Poplawski, netdev, mlachwani On Tue, Jan 09, 2007 at 06:44:49PM +0100, Thibaut VARENE wrote: > On 1/9/07, Jarek Poplawski <jarkao2@o2.pl> wrote: > >On Tue, Jan 09, 2007 at 11:27:59AM +0100, Thibaut VARENE wrote: > >... > >> I suspected both and changed both the disk and the ram for quality > >> parts, that I tested afterwards. Both passed thorough tests. > >> > >> Finally, using the other NIC on the box (a VIA Rhine II, 100Mbps), > >> works absolutely fine. > > > >If you are not tired, I'd suggest two more tests: > > I volunteered to help :) Thank you Thibaut. Please try the following patch: From: Dale Farnsworth <dale@farnsworth.org> Reserve one unused descriptor in the TX ring to facilitate testing for when the ring is full. --- Signed-off-by: Dale Farnsworth <dale@farnsworth.org> drivers/net/mv643xx_eth.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c index 9997081..72f82ba 100644 --- a/drivers/net/mv643xx_eth.c +++ b/drivers/net/mv643xx_eth.c @@ -289,7 +289,7 @@ static void mv643xx_eth_tx_timeout_task( eth_port_reset(mp->port_num); eth_port_start(dev); - if (mp->tx_ring_size - mp->tx_desc_count >= MAX_DESCS_PER_SKB) + if (mp->tx_ring_size - mp->tx_desc_count > MAX_DESCS_PER_SKB) netif_wake_queue(dev); } @@ -356,7 +356,7 @@ static void mv643xx_eth_free_completed_t struct mv643xx_private *mp = netdev_priv(dev); if (mv643xx_eth_free_tx_descs(dev, 0) && - mp->tx_ring_size - mp->tx_desc_count >= MAX_DESCS_PER_SKB) + mp->tx_ring_size - mp->tx_desc_count > MAX_DESCS_PER_SKB) netif_wake_queue(dev); } @@ -536,7 +536,7 @@ static irqreturn_t mv643xx_eth_int_handl ETH_TX_QUEUES_ENABLED); if (!netif_carrier_ok(dev)) { netif_carrier_on(dev); - if (mp->tx_ring_size - mp->tx_desc_count >= + if (mp->tx_ring_size - mp->tx_desc_count > MAX_DESCS_PER_SKB) netif_wake_queue(dev); } @@ -1194,7 +1194,7 @@ static int mv643xx_eth_start_xmit(struct BUG_ON(netif_queue_stopped(dev)); BUG_ON(skb == NULL); - if (mp->tx_ring_size - mp->tx_desc_count < MAX_DESCS_PER_SKB) { + if (mp->tx_ring_size - mp->tx_desc_count <= MAX_DESCS_PER_SKB) { printk(KERN_ERR "%s: transmit with queue full\n", dev->name); netif_stop_queue(dev); return 1; @@ -1216,7 +1216,7 @@ static int mv643xx_eth_start_xmit(struct stats->tx_packets++; dev->trans_start = jiffies; - if (mp->tx_ring_size - mp->tx_desc_count < MAX_DESCS_PER_SKB) + if (mp->tx_ring_size - mp->tx_desc_count <= MAX_DESCS_PER_SKB) netif_stop_queue(dev); spin_unlock_irqrestore(&mp->lock, flags); ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-09 20:05 ` Dale Farnsworth @ 2007-01-09 21:05 ` Thibaut VARENE 2007-01-10 17:12 ` Thibaut VARENE 0 siblings, 1 reply; 20+ messages in thread From: Thibaut VARENE @ 2007-01-09 21:05 UTC (permalink / raw) To: Dale Farnsworth; +Cc: Jarek Poplawski, netdev, mlachwani On 1/9/07, Dale Farnsworth <dale@farnsworth.org> wrote: > On Tue, Jan 09, 2007 at 06:44:49PM +0100, Thibaut VARENE wrote: > > On 1/9/07, Jarek Poplawski <jarkao2@o2.pl> wrote: > > >On Tue, Jan 09, 2007 at 11:27:59AM +0100, Thibaut VARENE wrote: > > >... > > >> I suspected both and changed both the disk and the ram for quality > > >> parts, that I tested afterwards. Both passed thorough tests. > > >> > > >> Finally, using the other NIC on the box (a VIA Rhine II, 100Mbps), > > >> works absolutely fine. > > > > > >If you are not tired, I'd suggest two more tests: > > > > I volunteered to help :) > > Thank you Thibaut. Please try the following patch: > > From: Dale Farnsworth <dale@farnsworth.org> > > Reserve one unused descriptor in the TX ring > to facilitate testing for when the ring is full. Dale, tried it and unfortunately: Alucard login: ------------[ cut here ]------------ kernel BUG at drivers/net/mv643xx_eth.c:1071! Oops: Exception in kernel mode, sig: 5 [#1] PREEMPT Modules linked in: eeprom sbp2 scsi_mod eth1394 uhci_hcd vt8231 ohci1394 ieee13t NIP: C0210B40 LR: C02126DC CTR: C0212620 REGS: dd2d7b40 TRAP: 0700 Not tainted (2.6.20-rc4) MSR: 00021032 <ME,IR,DR> CR: 28242488 XER: 00000000 TASK = da03c640[1775] 'ncftp' THREAD: dd2d6000 GPR00: 00000000 DD2D7BF0 DA03C640 CFB16260 CFB16000 0000000B DF79FDD2 00000000 GPR08: 00000BA9 00000001 00001000 00000BAA 28242482 10056CD0 28004422 C03D9BF8 GPR16: 00000000 00000000 00000000 DD2D6000 00000001 CFB162BC 00009032 00000000 GPR24: 000005A8 00000000 C03E0000 CFB16000 C0212620 CFCB3260 CFB16260 DF79FDA0 NIP [C0210B40] eth_alloc_tx_desc_index+0x44/0x50 LR [C02126DC] mv643xx_eth_start_xmit+0xbc/0x3b8 Call Trace: [DD2D7BF0] [DF79FDD0] 0xdf79fdd0 (unreliable) [DD2D7C30] [C029F258] dev_hard_start_xmit+0x1d4/0x2c8 [DD2D7C50] [C02A1BF4] dev_queue_xmit+0x2bc/0x334 [DD2D7C70] [C02BC8A8] ip_output+0x120/0x244 [DD2D7C90] [C02BD8DC] ip_queue_xmit+0x17c/0x408 [DD2D7D00] [C02CEB1C] tcp_transmit_skb+0x358/0x7bc [DD2D7D40] [C02C2FC0] tcp_cleanup_rbuf+0xb8/0x158 [DD2D7D50] [C02C5C14] tcp_recvmsg+0x4c0/0xbcc [DD2D7DB0] [C0294490] sock_common_recvmsg+0x3c/0x60 [DD2D7DD0] [C02920E4] sock_aio_read+0x10c/0x114 [DD2D7E30] [C006F210] do_sync_read+0xc4/0x138 [DD2D7EF0] [C006FECC] vfs_read+0x19c/0x1a4 [DD2D7F10] [C00702E4] sys_read+0x4c/0x90 [DD2D7F40] [C00122EC] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xff5ba98 LR = 0x10032fc0 Instruction dump: 5400fffe 0f000000 81030020 81230024 39680001 7c0b53d6 7c0051d6 7d605850 7d694a78 91630020 7d290034 5529d97e <0f090000> 7d034378 4e800020 2f840001 <0>Kernel panic - not syncing: Fatal exception in interrupt <0>Rebooting in 180 seconds..<4>atkbd.c: Spurious ACK on isa0060/serio0. Some . atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access ha. atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access ha. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-09 21:05 ` Thibaut VARENE @ 2007-01-10 17:12 ` Thibaut VARENE 2007-01-11 10:42 ` [PATCH] " Jarek Poplawski 0 siblings, 1 reply; 20+ messages in thread From: Thibaut VARENE @ 2007-01-10 17:12 UTC (permalink / raw) To: Dale Farnsworth; +Cc: Jarek Poplawski, netdev, mlachwani On 1/9/07, Thibaut VARENE <T-Bone@parisc-linux.org> wrote: > On 1/9/07, Dale Farnsworth <dale@farnsworth.org> wrote: > > > > Thank you Thibaut. Please try the following patch: > > > > From: Dale Farnsworth <dale@farnsworth.org> > > > > Reserve one unused descriptor in the TX ring > > to facilitate testing for when the ring is full. > > Dale, > > tried it and unfortunately: Also, I don't know if you read that bit, but everytime I reboot the box immediately after a crash, the NIC gets a bogus (always the same it seems) MAC address, and I have to reboot one more time to get back to the "normal" MAC address. Dunno if that hints anything though. HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-10 17:12 ` Thibaut VARENE @ 2007-01-11 10:42 ` Jarek Poplawski 2007-01-21 12:18 ` Thibaut VARENE 0 siblings, 1 reply; 20+ messages in thread From: Jarek Poplawski @ 2007-01-11 10:42 UTC (permalink / raw) To: Thibaut VARENE; +Cc: Dale Farnsworth, netdev, mlachwani On Wed, Jan 10, 2007 at 06:12:29PM +0100, Thibaut VARENE wrote: > On 1/9/07, Thibaut VARENE <T-Bone@parisc-linux.org> wrote: > >On 1/9/07, Dale Farnsworth <dale@farnsworth.org> wrote: > >> > >> Thank you Thibaut. Please try the following patch: > >> > >> From: Dale Farnsworth <dale@farnsworth.org> > >> > >> Reserve one unused descriptor in the TX ring > >> to facilitate testing for when the ring is full. > > > >Dale, > > > >tried it and unfortunately: > > Also, I don't know if you read that bit, but everytime I reboot the > box immediately after a crash, the NIC gets a bogus (always the same > it seems) MAC address, and I have to reboot one more time to get back > to the "normal" MAC address. > > Dunno if that hints anything though. There is something in the code about MAC writing and saving some config during initialization, so probably it's possible if reinitialization was broken. I tried to look more into the code and here are my (maybe wrong) conclusions: - It looks like something could be broken during tx descs freeing or eth_tx_timeout_task. I compared the timeout code with e100 and tg3 and have a feeling mv643xx_eth is doing less but I'm not able to estimate the importance of this. - Such errors, IMHO, could be possible with races and not enough locking, and btw. I think suspected function isn't properly locked: mp->tx_desc_count in while condition isn't protected at all. Below I attach a patch proposal but I'm not sure some irq off or spin_lock isn't also needed elswere. If it's only locking it would be suitable to do the test with a kernel compiled without PREEMPT and SMP, but if irqs nothing should change... Regards, Jarek P. PS: alas I didn't even check compiling - I had no time to find all compile dependencies of this driver --- Signed-off-by: Jarek Poplawski <jarkao2@o2.pl> --- diff -Nurp linux-2.6.20-rc4-/drivers/net/mv643xx_eth.c linux-2.6.20-rc4/drivers/net/mv643xx_eth.c --- linux-2.6.20-rc4-/drivers/net/mv643xx_eth.c 2006-12-18 08:57:52.000000000 +0100 +++ linux-2.6.20-rc4/drivers/net/mv643xx_eth.c 2007-01-11 08:55:34.000000000 +0100 @@ -312,8 +312,8 @@ int mv643xx_eth_free_tx_descs(struct net int count; int released = 0; + spin_lock_irqsave(&mp->lock, flags); while (mp->tx_desc_count > 0) { - spin_lock_irqsave(&mp->lock, flags); tx_index = mp->tx_used_desc_q; desc = &mp->p_tx_desc_area[tx_index]; cmd_sts = desc->cmd_sts; @@ -348,8 +348,10 @@ int mv643xx_eth_free_tx_descs(struct net dev_kfree_skb_irq(skb); released = 1; + spin_lock_irqsave(&mp->lock, flags); } + spin_unlock_irqrestore(&mp->lock, flags); return released; } ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-11 10:42 ` [PATCH] " Jarek Poplawski @ 2007-01-21 12:18 ` Thibaut VARENE 2007-01-21 13:02 ` Thibaut VARENE 0 siblings, 1 reply; 20+ messages in thread From: Thibaut VARENE @ 2007-01-21 12:18 UTC (permalink / raw) To: Jarek Poplawski; +Cc: Dale Farnsworth, netdev, mlachwani On 1/11/07, Jarek Poplawski <jarkao2@o2.pl> wrote: > > PS: alas I didn't even check compiling - I had no time to > find all compile dependencies of this driver > --- > > Signed-off-by: Jarek Poplawski <jarkao2@o2.pl> > --- > > diff -Nurp linux-2.6.20-rc4-/drivers/net/mv643xx_eth.c linux-2.6.20-rc4/drivers/net/mv643xx_eth.c > --- linux-2.6.20-rc4-/drivers/net/mv643xx_eth.c 2006-12-18 08:57:52.000000000 +0100 > +++ linux-2.6.20-rc4/drivers/net/mv643xx_eth.c 2007-01-11 08:55:34.000000000 +0100 > @@ -312,8 +312,8 @@ int mv643xx_eth_free_tx_descs(struct net > int count; > int released = 0; > > + spin_lock_irqsave(&mp->lock, flags); > while (mp->tx_desc_count > 0) { > - spin_lock_irqsave(&mp->lock, flags); > tx_index = mp->tx_used_desc_q; > desc = &mp->p_tx_desc_area[tx_index]; > cmd_sts = desc->cmd_sts; > @@ -348,8 +348,10 @@ int mv643xx_eth_free_tx_descs(struct net > dev_kfree_skb_irq(skb); Hmm, I think this is guaranteed not to work. In between those lines the lock is released, while data in the mp structure is still being accessed. It seems that this bit of code is indeed not race-safe though, I'm gonna try to figure something. > released = 1; > + spin_lock_irqsave(&mp->lock, flags); > } > > + spin_unlock_irqrestore(&mp->lock, flags); > return released; > } Ugh, this is really unclean... Taking a lock "for nothing" like that has a perf cost. HTH T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-21 12:18 ` Thibaut VARENE @ 2007-01-21 13:02 ` Thibaut VARENE 2007-01-22 10:02 ` Jarek Poplawski 0 siblings, 1 reply; 20+ messages in thread From: Thibaut VARENE @ 2007-01-21 13:02 UTC (permalink / raw) To: Jarek Poplawski; +Cc: Dale Farnsworth, netdev, mlachwani [-- Attachment #1: Type: text/plain, Size: 980 bytes --] On 1/21/07, Thibaut VARENE <T-Bone@parisc-linux.org> wrote: > On 1/11/07, Jarek Poplawski <jarkao2@o2.pl> wrote: > > > > PS: alas I didn't even check compiling - I had no time to > > find all compile dependencies of this driver > > --- > Hmm, I think this is guaranteed not to work. In between those lines > the lock is released, while data in the mp structure is still being > accessed. It seems that this bit of code is indeed not race-safe > though, I'm gonna try to figure something. This was indeed the right spot. The attached raw hack seems to fix the bug (I couldn't crash the box so far). I haven't checked that the same "situation" happens elsewhere in the code, I leave that as an exercise for the maintainers (or until I experience another kind of crash :) The patch is a bit ugly (printk with irq disabled will not show, etc) but at least it does work. I'm sure somebody will figure something HTH T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: fix_mv643xx_race.patch --] [-- Type: text/x-patch; name="fix_mv643xx_race.patch", Size: 768 bytes --] --- linux-2.6.19.orig/drivers/net/mv643xx_eth.c 2007-01-21 13:56:04.450689123 +0100 +++ linux-2.6.19/drivers/net/mv643xx_eth.c 2007-01-21 13:39:58.228404763 +0100 @@ -312,8 +312,8 @@ int count; int released = 0; + spin_lock_irqsave(&mp->lock, flags); while (mp->tx_desc_count > 0) { - spin_lock_irqsave(&mp->lock, flags); tx_index = mp->tx_used_desc_q; desc = &mp->p_tx_desc_area[tx_index]; cmd_sts = desc->cmd_sts; @@ -332,8 +332,6 @@ if (skb) mp->tx_skb[tx_index] = NULL; - spin_unlock_irqrestore(&mp->lock, flags); - if (cmd_sts & ETH_ERROR_SUMMARY) { printk("%s: Error in TX\n", dev->name); mp->stats.tx_errors++; @@ -349,6 +347,7 @@ released = 1; } + spin_unlock_irqrestore(&mp->lock, flags); return released; } ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-21 13:02 ` Thibaut VARENE @ 2007-01-22 10:02 ` Jarek Poplawski 2007-01-22 17:06 ` Dale Farnsworth 0 siblings, 1 reply; 20+ messages in thread From: Jarek Poplawski @ 2007-01-22 10:02 UTC (permalink / raw) To: Thibaut VARENE; +Cc: Dale Farnsworth, netdev, mlachwani On Sun, Jan 21, 2007 at 02:02:15PM +0100, Thibaut VARENE wrote: > On 1/21/07, Thibaut VARENE <T-Bone@parisc-linux.org> wrote: ... > >Hmm, I think this is guaranteed not to work. In between those lines > >the lock is released, while data in the mp structure is still being > >accessed. It seems that this bit of code is indeed not race-safe > >though, I'm gonna try to figure something. I only changed the part I was quite sure is wrong. I didn't know the internals of this place but thought probably somebody had some reasons to enable irqs here. I hope the maintainers will decide the range of necessary changes considering your testing and the patch. > This was indeed the right spot. The attached raw hack seems to fix the > bug (I couldn't crash the box so far). I haven't checked that the > same "situation" happens elsewhere in the code, I leave that as an > exercise for the maintainers (or until I experience another kind of > crash :) > > The patch is a bit ugly (printk with irq disabled will not show, etc) > but at least it does work. I'm sure somebody will figure something Congratulations and regards, Jarek P. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-22 10:02 ` Jarek Poplawski @ 2007-01-22 17:06 ` Dale Farnsworth 2007-01-23 8:17 ` Jarek Poplawski 2007-01-23 11:52 ` Thibaut VARENE 0 siblings, 2 replies; 20+ messages in thread From: Dale Farnsworth @ 2007-01-22 17:06 UTC (permalink / raw) To: Jarek Poplawski; +Cc: Thibaut VARENE, netdev, mlachwani Jarek and Thibaut, Thank you both very much for your work finding and fixing this bug. Jarek, can you verify that the following patch fixes the problem you were seeing? -Dale ----- Patch follows ----- From: Dale Farnsworth <dale@farnsworth.org> mv643xx_eth: Fix race condition in mv643xx_eth_free_tx_descs The bug was found and isolated by Thibaut VARENE <T-Bone@parisc-linux.org> and Jarek Poplawski <jarkao2@o2.pl>. This patch is a modification of their fixes. We acquire and release the lock for each descriptor that is freed to minimize the time the lock is held. --- drivers/net/mv643xx_eth.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c index c41ae42..0d32381 100644 --- a/drivers/net/mv643xx_eth.c +++ b/drivers/net/mv643xx_eth.c @@ -314,6 +314,13 @@ int mv643xx_eth_free_tx_descs(struct net while (mp->tx_desc_count > 0) { spin_lock_irqsave(&mp->lock, flags); + + /* maybe tx_desc_count changed before the lock was acquired */ + if (mp->tx_desc_count <= 0) { + spin_unlock_irqrestore(&mp->lock, flags); + return released; + } + tx_index = mp->tx_used_desc_q; desc = &mp->p_tx_desc_area[tx_index]; cmd_sts = desc->cmd_sts; ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH] Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-22 17:06 ` Dale Farnsworth @ 2007-01-23 8:17 ` Jarek Poplawski 2007-01-23 11:52 ` Thibaut VARENE 1 sibling, 0 replies; 20+ messages in thread From: Jarek Poplawski @ 2007-01-23 8:17 UTC (permalink / raw) To: Dale Farnsworth; +Cc: Thibaut VARENE, netdev, mlachwani On Mon, Jan 22, 2007 at 10:06:16AM -0700, Dale Farnsworth wrote: > Jarek and Thibaut, > > Thank you both very much for your work finding and fixing this bug. > Jarek, can you verify that the following patch fixes the problem you > were seeing? > > -Dale Sorry, only Thibaut can verify this. I don't have such card. I can only confirm that your patch fixes unproper locking of mp->tx_desc_count in the while condition. But I'm not sure your way is optimal now because mp->tx_desc_count is checked 2 times per every loop. I think it is right only if you know the function mv643xx_eth_free_tx_descs is called mostly while mp->tx_desc_count == 0 or 1. > ----- Patch follows ----- > > From: Dale Farnsworth <dale@farnsworth.org> > > mv643xx_eth: Fix race condition in mv643xx_eth_free_tx_descs > > The bug was found and isolated by Thibaut VARENE <T-Bone@parisc-linux.org> > and Jarek Poplawski <jarkao2@o2.pl>. This patch is a modification of their > fixes. We acquire and release the lock for each descriptor that is freed > to minimize the time the lock is held. > > --- From: Dale Farnsworth <dale@farnsworth.org> mv643xx_eth: Fix race condition in mv643xx_eth_free_tx_descs The bug was found and isolated by Thibaut VARENE <T-Bone@parisc-linux.org> and Jarek Poplawski <jarkao2@o2.pl> noticed a locking problem. This patch is a modification of their fixes. We acquire and release the lock for each descriptor that is freed to minimize the time the lock is held. --- I did small adjustment of my role here. Regards, Jarek P. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-22 17:06 ` Dale Farnsworth 2007-01-23 8:17 ` Jarek Poplawski @ 2007-01-23 11:52 ` Thibaut VARENE 2007-01-23 12:42 ` Thibaut VARENE 1 sibling, 1 reply; 20+ messages in thread From: Thibaut VARENE @ 2007-01-23 11:52 UTC (permalink / raw) To: Dale Farnsworth; +Cc: Jarek Poplawski, netdev, mlachwani On 1/22/07, Dale Farnsworth <dale@farnsworth.org> wrote: > Jarek and Thibaut, > > Thank you both very much for your work finding and fixing this bug. > Jarek, can you verify that the following patch fixes the problem you > were seeing? > > -Dale Hi Dale, The patch seems to work fine. Just thinking out loud (as I really don't know this part of the kernel), here are a few remarks: - As Jarek pointed out, you're checking twice the value of mp->tx_desc_count, which means dereferencing a pointer and accessing memory twice. I don't know how perf-critical this bit of code is, but I wonder which of keeping the lock for a long time or doing what you is better (I'm being anal and you probably know that better than me :) - Also, lines 344-349, in the test condition, cmd_sts (an indirection to mp content) is accessed (dunno if it's ok to do that outside of the lock), and on line 346, mp->stats.tx.errors is incremented outside of the spinlock protection. But then, I don't know what that lock is meant to protect, just pointing this out :) Thanks for your help, I hope the fix will go upstream asap :) And about being the author of the patch, since I'm not, I don't really mind 8) HTH T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! 2007-01-23 11:52 ` Thibaut VARENE @ 2007-01-23 12:42 ` Thibaut VARENE 0 siblings, 0 replies; 20+ messages in thread From: Thibaut VARENE @ 2007-01-23 12:42 UTC (permalink / raw) To: Dale Farnsworth; +Cc: Jarek Poplawski, netdev, mlachwani On 1/23/07, Thibaut VARENE <T-Bone@parisc-linux.org> wrote: > - As Jarek pointed out, you're checking twice the value of > mp->tx_desc_count, which means dereferencing a pointer and accessing > memory twice. I don't know how perf-critical this bit of code is, but > I wonder which of keeping the lock for a long time or doing what you > is better (I'm being anal and you probably know that better than me :) Forget that. That's an irq disabling lock, it's worse than anything else :) -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2007-01-23 12:42 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-01-05 19:03 kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069! Thibaut VARENE 2007-01-09 9:26 ` Jarek Poplawski 2007-01-09 10:27 ` Thibaut VARENE 2007-01-09 10:52 ` Jarek Poplawski 2007-01-09 10:56 ` Thibaut VARENE 2007-01-09 11:48 ` Jarek Poplawski 2007-01-09 10:57 ` Jarek Poplawski 2007-01-09 13:02 ` Jarek Poplawski 2007-01-09 17:44 ` Thibaut VARENE 2007-01-09 20:05 ` Dale Farnsworth 2007-01-09 21:05 ` Thibaut VARENE 2007-01-10 17:12 ` Thibaut VARENE 2007-01-11 10:42 ` [PATCH] " Jarek Poplawski 2007-01-21 12:18 ` Thibaut VARENE 2007-01-21 13:02 ` Thibaut VARENE 2007-01-22 10:02 ` Jarek Poplawski 2007-01-22 17:06 ` Dale Farnsworth 2007-01-23 8:17 ` Jarek Poplawski 2007-01-23 11:52 ` Thibaut VARENE 2007-01-23 12:42 ` Thibaut VARENE
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.