* defxx: skb_push() failing? @ 2013-03-26 14:29 David Oostdyk 2013-03-26 15:15 ` Eric Dumazet 0 siblings, 1 reply; 9+ messages in thread From: David Oostdyk @ 2013-03-26 14:29 UTC (permalink / raw) To: netdev; +Cc: macro Hello, In dfx_xmt_queue_pkt() in defxx.c, there is a skb_push(3) call which makes room for 3 packet request header bytes. There is some discussion in the driver explaining why those three bytes will be available. I have an old FDDI card that I'm trying to bring up: 05:05.0 FDDI network controller: Digital Equipment Corporation PCI-to-PDQ Interface Chip [PFI] (rev 02) Most skbuffs that come through dfx_xmit_queue_pkt() have 11 bytes between skb->head and skb->data. On the other hand, at almost exactly 60-second intervals, an skb arrives that has zero bytes between skb->head and skb->data. This normally causes a kernel panic, and for the time I just skip over such skb's. Does anyone have advice on where I should start digging to find the cause of this? Thanks in advance! - David Oostdyk ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: defxx: skb_push() failing? 2013-03-26 14:29 defxx: skb_push() failing? David Oostdyk @ 2013-03-26 15:15 ` Eric Dumazet 2013-03-26 16:03 ` David Oostdyk 0 siblings, 1 reply; 9+ messages in thread From: Eric Dumazet @ 2013-03-26 15:15 UTC (permalink / raw) To: David Oostdyk; +Cc: netdev, macro On Tue, 2013-03-26 at 10:29 -0400, David Oostdyk wrote: > Hello, > > In dfx_xmt_queue_pkt() in defxx.c, there is a skb_push(3) call which > makes room for 3 packet request header bytes. There is some discussion > in the driver explaining why those three bytes will be available. I > have an old FDDI card that I'm trying to bring up: > > 05:05.0 FDDI network controller: Digital Equipment Corporation > PCI-to-PDQ Interface Chip [PFI] (rev 02) > > Most skbuffs that come through dfx_xmit_queue_pkt() have 11 bytes > between skb->head and skb->data. On the other hand, at almost exactly > 60-second intervals, an skb arrives that has zero bytes between > skb->head and skb->data. This normally causes a kernel panic, and for > the time I just skip over such skb's. > > Does anyone have advice on where I should start digging to find the > cause of this? > Have you read comments in defxx.c file around line 151 ? If one skb arrives with not enough headroom, you could add a WARN_ON_ONCE(skb_headroom(skb) < 3); and report stack trace so that we can identify and fix the caller. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: defxx: skb_push() failing? 2013-03-26 15:15 ` Eric Dumazet @ 2013-03-26 16:03 ` David Oostdyk 2013-03-26 16:30 ` Eric Dumazet 0 siblings, 1 reply; 9+ messages in thread From: David Oostdyk @ 2013-03-26 16:03 UTC (permalink / raw) To: Eric Dumazet; +Cc: netdev@vger.kernel.org, macro@linux-mips.org On 03/26/13 11:15, Eric Dumazet wrote: > On Tue, 2013-03-26 at 10:29 -0400, David Oostdyk wrote: >> Hello, >> >> In dfx_xmt_queue_pkt() in defxx.c, there is a skb_push(3) call which >> makes room for 3 packet request header bytes. There is some discussion >> in the driver explaining why those three bytes will be available. I >> have an old FDDI card that I'm trying to bring up: >> >> 05:05.0 FDDI network controller: Digital Equipment Corporation >> PCI-to-PDQ Interface Chip [PFI] (rev 02) >> >> Most skbuffs that come through dfx_xmit_queue_pkt() have 11 bytes >> between skb->head and skb->data. On the other hand, at almost exactly >> 60-second intervals, an skb arrives that has zero bytes between >> skb->head and skb->data. This normally causes a kernel panic, and for >> the time I just skip over such skb's. >> >> Does anyone have advice on where I should start digging to find the >> cause of this? >> > Have you read comments in defxx.c file around line 151 ? > > If one skb arrives with not enough headroom, you could add a > > WARN_ON_ONCE(skb_headroom(skb) < 3); > > and report stack trace so that we can identify and fix the caller. > > > I have read the comments, and alloc_fddidev() seems to set the hard_header_len as described. As for the stack trace, thanks for the tip! Here is the output (including various defxx debug statements): [ 350.312482] defxx: v1.10 2006/12/14 Lawrence V. Stefani and others [ 350.312582] In dfx_driver_init... [ 350.312583] In dfx_bus_init... [ 350.312585] In dfx_bus_config_check... [ 351.699416] 0000:05:05.0: DEFPA at addr = 0xf9eeff80, IRQ = 26, Hardware addr = 00-60-b0-58-48-53 [ 351.699425] 0000:05:05.0: Descriptor block virt = FFFF8800CB834000, phys = CB834000 [ 351.699426] 0000:05:05.0: Command Request buffer virt = FFFF8800CB835380, phys = CB835380 [ 351.699427] 0000:05:05.0: Command Response buffer virt = FFFF8800CB835580, phys = CB835580 [ 351.699428] 0000:05:05.0: Receive buffer block virt = FFFF8800CB835780, phys = CB835780 [ 351.699429] 0000:05:05.0: Consumer block virt = FFFF8800CB835780, phys = CB835780 [ 351.700049] 0000:05:05.0: registered as fddi0 [ 351.756194] In dfx_open... [ 351.756215] In dfx_adap_init... [ 353.927747] fddi0: Multicast address table updated! Added 1 addresses. [ 353.930352] fddi0: Adapter filters updated! [ 353.975887] fddi0: Multicast address table updated! Added 1 addresses. [ 353.978492] fddi0: Adapter filters updated! [ 354.043455] fddi0: Multicast address table updated! Added 2 addresses. [ 354.046359] fddi0: Adapter filters updated! [ 354.097315] fddi0: Multicast address table updated! Added 3 addresses. [ 354.099919] fddi0: Adapter filters updated! [ 354.204301] fddi0: Multicast address table updated! Added 3 addresses. [ 354.207107] fddi0: Adapter filters updated! [ 354.257972] fddi0: Multicast address table updated! Added 3 addresses. [ 354.261577] fddi0: Adapter filters updated! [ 362.976038] ------------[ cut here ]------------ [ 362.976044] WARNING: at drivers/net/fddi/defxx.c:3202 dfx_xmt_queue_pkt+0xa2/0x2f2 [defxx]() [ 362.976046] Hardware name: Precision WorkStation 490 [ 362.976047] Modules linked in: defxx snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm iTCO_wdt snd_page_alloc lpc_ich snd_timer mfd_core i5000_edac rng_core i2c_i801 fddi rtc_cmos [last unloaded: defxx] [ 362.976066] Pid: 1773, comm: aoe_tx Tainted: G I 3.7.10-hippi+ #6 [ 362.976068] Call Trace: [ 362.976076] [<ffffffff810357e7>] warn_slowpath_common+0x7e/0x96 [ 362.976080] [<ffffffff81035814>] warn_slowpath_null+0x15/0x17 [ 362.976083] [<ffffffffa0063213>] dfx_xmt_queue_pkt+0xa2/0x2f2 [defxx] [ 362.976088] [<ffffffff813c3401>] ? map_single+0x45/0x45 [ 362.976093] [<ffffffff819175a8>] dev_hard_start_xmit+0x288/0x398 [ 362.976097] [<ffffffff81929d1c>] sch_direct_xmit+0x72/0x19b [ 362.976100] [<ffffffff819179ec>] dev_queue_xmit+0x145/0x339 [ 362.976105] [<ffffffff8184ab20>] tx+0x1c/0x42 [ 362.976108] [<ffffffff818489a2>] kthread+0x5e/0xbf [ 362.976113] [<ffffffff81056451>] ? try_to_wake_up+0x239/0x239 [ 362.976116] [<ffffffff81848944>] ? rexmit_timer+0x349/0x349 [ 362.976119] [<ffffffff8104c678>] kthread+0xb5/0xbd [ 362.976122] [<ffffffff8104c5c3>] ? __kthread_parkme+0x67/0x67 [ 362.976127] [<ffffffff81a314ec>] ret_from_fork+0x7c/0xb0 [ 362.976129] [<ffffffff8104c5c3>] ? __kthread_parkme+0x67/0x67 [ 362.976131] ---[ end trace ce553e95611628f3 ]--- Thanks again for any help! ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: defxx: skb_push() failing? 2013-03-26 16:03 ` David Oostdyk @ 2013-03-26 16:30 ` Eric Dumazet 2013-03-26 18:45 ` David Oostdyk 0 siblings, 1 reply; 9+ messages in thread From: Eric Dumazet @ 2013-03-26 16:30 UTC (permalink / raw) To: David Oostdyk; +Cc: netdev@vger.kernel.org, macro@linux-mips.org On Tue, 2013-03-26 at 12:03 -0400, David Oostdyk wrote: > On 03/26/13 11:15, Eric Dumazet wrote: > > On Tue, 2013-03-26 at 10:29 -0400, David Oostdyk wrote: > >> Hello, > >> > >> In dfx_xmt_queue_pkt() in defxx.c, there is a skb_push(3) call which > >> makes room for 3 packet request header bytes. There is some discussion > >> in the driver explaining why those three bytes will be available. I > >> have an old FDDI card that I'm trying to bring up: > >> > >> 05:05.0 FDDI network controller: Digital Equipment Corporation > >> PCI-to-PDQ Interface Chip [PFI] (rev 02) > >> > >> Most skbuffs that come through dfx_xmit_queue_pkt() have 11 bytes > >> between skb->head and skb->data. On the other hand, at almost exactly > >> 60-second intervals, an skb arrives that has zero bytes between > >> skb->head and skb->data. This normally causes a kernel panic, and for > >> the time I just skip over such skb's. > >> > >> Does anyone have advice on where I should start digging to find the > >> cause of this? > >> > > Have you read comments in defxx.c file around line 151 ? > > > > If one skb arrives with not enough headroom, you could add a > > > > WARN_ON_ONCE(skb_headroom(skb) < 3); > > > > and report stack trace so that we can identify and fix the caller. > > > > > > > > I have read the comments, and alloc_fddidev() seems to set the > hard_header_len as described. > > As for the stack trace, thanks for the tip! Here is the output > (including various defxx debug statements): > > [ 350.312482] defxx: v1.10 2006/12/14 Lawrence V. Stefani and others > [ 350.312582] In dfx_driver_init... > [ 350.312583] In dfx_bus_init... > [ 350.312585] In dfx_bus_config_check... > [ 351.699416] 0000:05:05.0: DEFPA at addr = 0xf9eeff80, IRQ = 26, > Hardware addr = 00-60-b0-58-48-53 > [ 351.699425] 0000:05:05.0: Descriptor block virt = FFFF8800CB834000, > phys = CB834000 > [ 351.699426] 0000:05:05.0: Command Request buffer virt = > FFFF8800CB835380, phys = CB835380 > [ 351.699427] 0000:05:05.0: Command Response buffer virt = > FFFF8800CB835580, phys = CB835580 > [ 351.699428] 0000:05:05.0: Receive buffer block virt = > FFFF8800CB835780, phys = CB835780 > [ 351.699429] 0000:05:05.0: Consumer block virt = FFFF8800CB835780, > phys = CB835780 > [ 351.700049] 0000:05:05.0: registered as fddi0 > [ 351.756194] In dfx_open... > [ 351.756215] In dfx_adap_init... > [ 353.927747] fddi0: Multicast address table updated! Added 1 addresses. > [ 353.930352] fddi0: Adapter filters updated! > [ 353.975887] fddi0: Multicast address table updated! Added 1 addresses. > [ 353.978492] fddi0: Adapter filters updated! > [ 354.043455] fddi0: Multicast address table updated! Added 2 addresses. > [ 354.046359] fddi0: Adapter filters updated! > [ 354.097315] fddi0: Multicast address table updated! Added 3 addresses. > [ 354.099919] fddi0: Adapter filters updated! > [ 354.204301] fddi0: Multicast address table updated! Added 3 addresses. > [ 354.207107] fddi0: Adapter filters updated! > [ 354.257972] fddi0: Multicast address table updated! Added 3 addresses. > [ 354.261577] fddi0: Adapter filters updated! > [ 362.976038] ------------[ cut here ]------------ > [ 362.976044] WARNING: at drivers/net/fddi/defxx.c:3202 > dfx_xmt_queue_pkt+0xa2/0x2f2 [defxx]() > [ 362.976046] Hardware name: Precision WorkStation 490 > [ 362.976047] Modules linked in: defxx snd_hda_codec_idt snd_hda_intel > snd_hda_codec snd_hwdep snd_pcm iTCO_wdt snd_page_alloc lpc_ich > snd_timer mfd_core i5000_edac rng_core i2c_i801 fddi rtc_cmos [last > unloaded: defxx] > [ 362.976066] Pid: 1773, comm: aoe_tx Tainted: G I > 3.7.10-hippi+ #6 > [ 362.976068] Call Trace: > [ 362.976076] [<ffffffff810357e7>] warn_slowpath_common+0x7e/0x96 > [ 362.976080] [<ffffffff81035814>] warn_slowpath_null+0x15/0x17 > [ 362.976083] [<ffffffffa0063213>] dfx_xmt_queue_pkt+0xa2/0x2f2 [defxx] > [ 362.976088] [<ffffffff813c3401>] ? map_single+0x45/0x45 > [ 362.976093] [<ffffffff819175a8>] dev_hard_start_xmit+0x288/0x398 > [ 362.976097] [<ffffffff81929d1c>] sch_direct_xmit+0x72/0x19b > [ 362.976100] [<ffffffff819179ec>] dev_queue_xmit+0x145/0x339 > [ 362.976105] [<ffffffff8184ab20>] tx+0x1c/0x42 > [ 362.976108] [<ffffffff818489a2>] kthread+0x5e/0xbf > [ 362.976113] [<ffffffff81056451>] ? try_to_wake_up+0x239/0x239 > [ 362.976116] [<ffffffff81848944>] ? rexmit_timer+0x349/0x349 > [ 362.976119] [<ffffffff8104c678>] kthread+0xb5/0xbd > [ 362.976122] [<ffffffff8104c5c3>] ? __kthread_parkme+0x67/0x67 > [ 362.976127] [<ffffffff81a314ec>] ret_from_fork+0x7c/0xb0 > [ 362.976129] [<ffffffff8104c5c3>] ? __kthread_parkme+0x67/0x67 > [ 362.976131] ---[ end trace ce553e95611628f3 ]--- > > > Thanks again for any help! Are you really using AOE ? drivers/block/aoe/aoenet.c can apparently call dev_queue_xmit() with non compliant skbs. Please try following patch : diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c index 25ef5c0..92b6d7c 100644 --- a/drivers/block/aoe/aoecmd.c +++ b/drivers/block/aoe/aoecmd.c @@ -51,8 +51,9 @@ new_skb(ulong len) { struct sk_buff *skb; - skb = alloc_skb(len, GFP_ATOMIC); + skb = alloc_skb(len + MAX_HEADER, GFP_ATOMIC); if (skb) { + skb_reserve(skb, MAX_HEADER); skb_reset_mac_header(skb); skb_reset_network_header(skb); skb->protocol = __constant_htons(ETH_P_AOE); ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: defxx: skb_push() failing? 2013-03-26 16:30 ` Eric Dumazet @ 2013-03-26 18:45 ` David Oostdyk 2013-03-26 19:00 ` Maciej W. Rozycki 0 siblings, 1 reply; 9+ messages in thread From: David Oostdyk @ 2013-03-26 18:45 UTC (permalink / raw) To: Eric Dumazet; +Cc: netdev@vger.kernel.org, macro@linux-mips.org [-- Attachment #1: Type: text/plain, Size: 5964 bytes --] On 03/26/13 12:30, Eric Dumazet wrote: > On Tue, 2013-03-26 at 12:03 -0400, David Oostdyk wrote: >> On 03/26/13 11:15, Eric Dumazet wrote: >>> On Tue, 2013-03-26 at 10:29 -0400, David Oostdyk wrote: >>>> Hello, >>>> >>>> In dfx_xmt_queue_pkt() in defxx.c, there is a skb_push(3) call which >>>> makes room for 3 packet request header bytes. There is some discussion >>>> in the driver explaining why those three bytes will be available. I >>>> have an old FDDI card that I'm trying to bring up: >>>> >>>> 05:05.0 FDDI network controller: Digital Equipment Corporation >>>> PCI-to-PDQ Interface Chip [PFI] (rev 02) >>>> >>>> Most skbuffs that come through dfx_xmit_queue_pkt() have 11 bytes >>>> between skb->head and skb->data. On the other hand, at almost exactly >>>> 60-second intervals, an skb arrives that has zero bytes between >>>> skb->head and skb->data. This normally causes a kernel panic, and for >>>> the time I just skip over such skb's. >>>> >>>> Does anyone have advice on where I should start digging to find the >>>> cause of this? >>>> >>> Have you read comments in defxx.c file around line 151 ? >>> >>> If one skb arrives with not enough headroom, you could add a >>> >>> WARN_ON_ONCE(skb_headroom(skb) < 3); >>> >>> and report stack trace so that we can identify and fix the caller. >>> >>> >>> >> I have read the comments, and alloc_fddidev() seems to set the >> hard_header_len as described. >> >> As for the stack trace, thanks for the tip! Here is the output >> (including various defxx debug statements): >> >> [ 350.312482] defxx: v1.10 2006/12/14 Lawrence V. Stefani and others >> [ 350.312582] In dfx_driver_init... >> [ 350.312583] In dfx_bus_init... >> [ 350.312585] In dfx_bus_config_check... >> [ 351.699416] 0000:05:05.0: DEFPA at addr = 0xf9eeff80, IRQ = 26, >> Hardware addr = 00-60-b0-58-48-53 >> [ 351.699425] 0000:05:05.0: Descriptor block virt = FFFF8800CB834000, >> phys = CB834000 >> [ 351.699426] 0000:05:05.0: Command Request buffer virt = >> FFFF8800CB835380, phys = CB835380 >> [ 351.699427] 0000:05:05.0: Command Response buffer virt = >> FFFF8800CB835580, phys = CB835580 >> [ 351.699428] 0000:05:05.0: Receive buffer block virt = >> FFFF8800CB835780, phys = CB835780 >> [ 351.699429] 0000:05:05.0: Consumer block virt = FFFF8800CB835780, >> phys = CB835780 >> [ 351.700049] 0000:05:05.0: registered as fddi0 >> [ 351.756194] In dfx_open... >> [ 351.756215] In dfx_adap_init... >> [ 353.927747] fddi0: Multicast address table updated! Added 1 addresses. >> [ 353.930352] fddi0: Adapter filters updated! >> [ 353.975887] fddi0: Multicast address table updated! Added 1 addresses. >> [ 353.978492] fddi0: Adapter filters updated! >> [ 354.043455] fddi0: Multicast address table updated! Added 2 addresses. >> [ 354.046359] fddi0: Adapter filters updated! >> [ 354.097315] fddi0: Multicast address table updated! Added 3 addresses. >> [ 354.099919] fddi0: Adapter filters updated! >> [ 354.204301] fddi0: Multicast address table updated! Added 3 addresses. >> [ 354.207107] fddi0: Adapter filters updated! >> [ 354.257972] fddi0: Multicast address table updated! Added 3 addresses. >> [ 354.261577] fddi0: Adapter filters updated! >> [ 362.976038] ------------[ cut here ]------------ >> [ 362.976044] WARNING: at drivers/net/fddi/defxx.c:3202 >> dfx_xmt_queue_pkt+0xa2/0x2f2 [defxx]() >> [ 362.976046] Hardware name: Precision WorkStation 490 >> [ 362.976047] Modules linked in: defxx snd_hda_codec_idt snd_hda_intel >> snd_hda_codec snd_hwdep snd_pcm iTCO_wdt snd_page_alloc lpc_ich >> snd_timer mfd_core i5000_edac rng_core i2c_i801 fddi rtc_cmos [last >> unloaded: defxx] >> [ 362.976066] Pid: 1773, comm: aoe_tx Tainted: G I >> 3.7.10-hippi+ #6 >> [ 362.976068] Call Trace: >> [ 362.976076] [<ffffffff810357e7>] warn_slowpath_common+0x7e/0x96 >> [ 362.976080] [<ffffffff81035814>] warn_slowpath_null+0x15/0x17 >> [ 362.976083] [<ffffffffa0063213>] dfx_xmt_queue_pkt+0xa2/0x2f2 [defxx] >> [ 362.976088] [<ffffffff813c3401>] ? map_single+0x45/0x45 >> [ 362.976093] [<ffffffff819175a8>] dev_hard_start_xmit+0x288/0x398 >> [ 362.976097] [<ffffffff81929d1c>] sch_direct_xmit+0x72/0x19b >> [ 362.976100] [<ffffffff819179ec>] dev_queue_xmit+0x145/0x339 >> [ 362.976105] [<ffffffff8184ab20>] tx+0x1c/0x42 >> [ 362.976108] [<ffffffff818489a2>] kthread+0x5e/0xbf >> [ 362.976113] [<ffffffff81056451>] ? try_to_wake_up+0x239/0x239 >> [ 362.976116] [<ffffffff81848944>] ? rexmit_timer+0x349/0x349 >> [ 362.976119] [<ffffffff8104c678>] kthread+0xb5/0xbd >> [ 362.976122] [<ffffffff8104c5c3>] ? __kthread_parkme+0x67/0x67 >> [ 362.976127] [<ffffffff81a314ec>] ret_from_fork+0x7c/0xb0 >> [ 362.976129] [<ffffffff8104c5c3>] ? __kthread_parkme+0x67/0x67 >> [ 362.976131] ---[ end trace ce553e95611628f3 ]--- >> >> >> Thanks again for any help! > Are you really using AOE ? > > drivers/block/aoe/aoenet.c can apparently call dev_queue_xmit() with non > compliant skbs. > > Please try following patch : > > diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c > index 25ef5c0..92b6d7c 100644 > --- a/drivers/block/aoe/aoecmd.c > +++ b/drivers/block/aoe/aoecmd.c > @@ -51,8 +51,9 @@ new_skb(ulong len) > { > struct sk_buff *skb; > > - skb = alloc_skb(len, GFP_ATOMIC); > + skb = alloc_skb(len + MAX_HEADER, GFP_ATOMIC); > if (skb) { > + skb_reserve(skb, MAX_HEADER); > skb_reset_mac_header(skb); > skb_reset_network_header(skb); > skb->protocol = __constant_htons(ETH_P_AOE); > > > Hi Eric, This patch did remove the offending skb's. (I'm not using AOE - not intentionally, anyway - so I'm not sure why this was being called.) (Now if I could only figure out why these FDDI cards don't want to talk to each other... I was hoping that was it.) Thanks for the help! [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4567 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: defxx: skb_push() failing? 2013-03-26 18:45 ` David Oostdyk @ 2013-03-26 19:00 ` Maciej W. Rozycki 2013-03-28 4:11 ` David Oostdyk 0 siblings, 1 reply; 9+ messages in thread From: Maciej W. Rozycki @ 2013-03-26 19:00 UTC (permalink / raw) To: David Oostdyk; +Cc: Eric Dumazet, netdev@vger.kernel.org On Tue, 26 Mar 2013, David Oostdyk wrote: > (Now if I could only figure out why these FDDI cards don't want to talk to > each other... I was hoping that was it.) I saw 64-bit addresses in your log -- the driver is known not to be 64-bit-clean, I've had an initial look into it recently and will be addressing it shortly. Maciej ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: defxx: skb_push() failing? 2013-03-26 19:00 ` Maciej W. Rozycki @ 2013-03-28 4:11 ` David Oostdyk 2013-03-28 4:28 ` [PATCH] aoe: reserve enough headroom on skbs Eric Dumazet 0 siblings, 1 reply; 9+ messages in thread From: David Oostdyk @ 2013-03-28 4:11 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Eric Dumazet, netdev@vger.kernel.org [-- Attachment #1: Type: text/plain, Size: 1070 bytes --] Hi Maciej, I can confirm that the two FDDI cards work on a 32-bit kernel. I'm not getting anywhere near the data rates I'd expect (3.5MB/sec?) but it's a start. I'd be glad to help test any 64-bit patches you come up with, Maciej. Either way, Eric Dumazet's patch to drivers/block/aoe/aoecmd.c seems to be required to prevent a panic right after defxx is loaded. Eric - good find. Should your patch be submitted upstream, then? Dave O. On 03/26/13 15:00, Maciej W. Rozycki wrote: > On Tue, 26 Mar 2013, David Oostdyk wrote: > >> (Now if I could only figure out why these FDDI cards don't want to talk to >> each other... I was hoping that was it.) > I saw 64-bit addresses in your log -- the driver is known not to be > 64-bit-clean, I've had an initial look into it recently and will be > addressing it shortly. > > Maciej > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4567 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] aoe: reserve enough headroom on skbs 2013-03-28 4:11 ` David Oostdyk @ 2013-03-28 4:28 ` Eric Dumazet 2013-03-28 18:30 ` David Miller 0 siblings, 1 reply; 9+ messages in thread From: Eric Dumazet @ 2013-03-28 4:28 UTC (permalink / raw) To: David Oostdyk, ecashin; +Cc: Maciej W. Rozycki, netdev@vger.kernel.org From: Eric Dumazet <edumazet@google.com> Some network drivers use a non default hard_header_len Transmitted skb should take into account dev->hard_header_len, or risk crashes or expensive reallocations. In the case of aoe, lets reserve MAX_HEADER bytes. David reported a crash in defxx driver, solved by this patch. Reported-by: David Oostdyk <daveo@ll.mit.edu> Tested-by: David Oostdyk <daveo@ll.mit.edu> Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Ed Cashin <ecashin@coraid.com> --- drivers/block/aoe/aoecmd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c index 25ef5c0..92b6d7c 100644 --- a/drivers/block/aoe/aoecmd.c +++ b/drivers/block/aoe/aoecmd.c @@ -51,8 +51,9 @@ new_skb(ulong len) { struct sk_buff *skb; - skb = alloc_skb(len, GFP_ATOMIC); + skb = alloc_skb(len + MAX_HEADER, GFP_ATOMIC); if (skb) { + skb_reserve(skb, MAX_HEADER); skb_reset_mac_header(skb); skb_reset_network_header(skb); skb->protocol = __constant_htons(ETH_P_AOE); ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] aoe: reserve enough headroom on skbs 2013-03-28 4:28 ` [PATCH] aoe: reserve enough headroom on skbs Eric Dumazet @ 2013-03-28 18:30 ` David Miller 0 siblings, 0 replies; 9+ messages in thread From: David Miller @ 2013-03-28 18:30 UTC (permalink / raw) To: eric.dumazet; +Cc: daveo, ecashin, macro, netdev From: Eric Dumazet <eric.dumazet@gmail.com> Date: Wed, 27 Mar 2013 21:28:41 -0700 > From: Eric Dumazet <edumazet@google.com> > > Some network drivers use a non default hard_header_len > > Transmitted skb should take into account dev->hard_header_len, or risk > crashes or expensive reallocations. > > In the case of aoe, lets reserve MAX_HEADER bytes. > > David reported a crash in defxx driver, solved by this patch. > > Reported-by: David Oostdyk <daveo@ll.mit.edu> > Tested-by: David Oostdyk <daveo@ll.mit.edu> > Signed-off-by: Eric Dumazet <edumazet@google.com> Applied and queued up for -stable, thanks. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-03-28 18:30 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-03-26 14:29 defxx: skb_push() failing? David Oostdyk 2013-03-26 15:15 ` Eric Dumazet 2013-03-26 16:03 ` David Oostdyk 2013-03-26 16:30 ` Eric Dumazet 2013-03-26 18:45 ` David Oostdyk 2013-03-26 19:00 ` Maciej W. Rozycki 2013-03-28 4:11 ` David Oostdyk 2013-03-28 4:28 ` [PATCH] aoe: reserve enough headroom on skbs Eric Dumazet 2013-03-28 18:30 ` David Miller
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).