* Re: ipw2200: firmware DMA loading rework
From: Pekka Enberg @ 2009-09-21 10:56 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Mel Gorman, Luis R. Rodriguez, Tso Ted, Aneesh Kumar K.V, Zhu Yi,
Andrew Morton, Johannes Weiner, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Mel Gorman,
netdev@vger.kernel.org, linux-mm@kvack.org, James Ketrenos,
Chatre, Reinette, linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <200909211246.34774.bzolnier@gmail.com>
On Mon, 2009-09-21 at 12:46 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > I don't know why people don't see it but for me it has a memory management
> > > regression and reliability issue written all over it.
> >
> > Possibly but drivers that reload their firmware as a response to an
> > error condition is relatively new and loading network drivers while the
> > system is already up and running a long time does not strike me as
> > typical system behaviour.
>
> Loading drivers after boot is a typical desktop/laptop behavior, please
> think about hotplug (the hardware in question is an USB dongle).
Yeah, I wonder what broke things. Did the wireless stack change in
2.6.31-rc1 too? IIRC Mel ruled out page allocator changes as a suspect.
Pekka
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: ipw2200: firmware DMA loading rework
From: Bartlomiej Zolnierkiewicz @ 2009-09-21 10:46 UTC (permalink / raw)
To: Mel Gorman
Cc: Luis R. Rodriguez, Tso Ted, Aneesh Kumar K.V, Zhu Yi,
Andrew Morton, Johannes Weiner, Pekka Enberg, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Mel Gorman,
netdev@vger.kernel.org, linux-mm@kvack.org, James Ketrenos,
Chatre, Reinette, linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <20090921100813.GL12726@csn.ul.ie>
On Monday 21 September 2009 12:08:13 Mel Gorman wrote:
> On Mon, Sep 21, 2009 at 11:59:27AM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > > > > On Sunday 30 August 2009 14:37:42 Bartlomiej Zolnierkiewicz wrote:
> > > > > > >> On Friday 28 August 2009 05:42:31 Zhu Yi wrote:
> > > > > > >> > Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
> > > > > > >> > for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
> > > > > > >>
> > > > > > >> s/2.6.30/2.6.31-rc6/
> > > > > > >>
> > > > > > >> The issue has always been there but it was some recent change that
> > > > > > >> explicitly triggered the allocation failures (after 2.6.31-rc1).
> > > > > > >
> > > > > > > ipw2200 fix works fine but yesterday I got the following error while mounting
> > > > > > > ext4 filesystem (mb_history is optional so the mount succeeded):
> > > > > >
> > > > > > OK so the mount succeeded.
> > > > > >
> > > > > > > EXT4-fs (dm-2): barriers enabled
> > > > > > > kjournald2 starting: pid 3137, dev dm-2:8, commit interval 5 seconds
> > > > > > > EXT4-fs (dm-2): internal journal on dm-2:8
> > > > > > > EXT4-fs (dm-2): delayed allocation enabled
> > > > > > > EXT4-fs: file extents enabled
> > > > > > > mount: page allocation failure. order:5, mode:0xc0d0
> > > > > > > Pid: 3136, comm: mount Not tainted 2.6.31-rc8-00015-gadda766-dirty #78
> > > > > > > Call Trace:
> > > > > > > [<c0394de3>] ? printk+0xf/0x14
> > > > > > > [<c016a693>] __alloc_pages_nodemask+0x400/0x442
> > > > > > > [<c016a71b>] __get_free_pages+0xf/0x32
> > > > > > > [<c01865cf>] __kmalloc+0x28/0xfa
> > > > > > > [<c023d96f>] ? __spin_lock_init+0x28/0x4d
> > > > > > > [<c01f529d>] ext4_mb_init+0x392/0x460
> > > > > > > [<c01e99d2>] ext4_fill_super+0x1b96/0x2012
> > > > > > > [<c0239bc8>] ? snprintf+0x15/0x17
> > > > > > > [<c01c0b26>] ? disk_name+0x24/0x69
> > > > > > > [<c018ba63>] get_sb_bdev+0xda/0x117
> > > > > > > [<c01e6711>] ext4_get_sb+0x13/0x15
> > > > > > > [<c01e7e3c>] ? ext4_fill_super+0x0/0x2012
> > > > > > > [<c018ad2d>] vfs_kern_mount+0x3b/0x76
> > > > > > > [<c018adad>] do_kern_mount+0x33/0xbd
> > > > > > > [<c019d0af>] do_mount+0x660/0x6b8
> > > > > > > [<c016a71b>] ? __get_free_pages+0xf/0x32
> > > > > > > [<c019d168>] sys_mount+0x61/0x99
> > > > > > > [<c0102908>] sysenter_do_call+0x12/0x36
> > > > > > > Mem-Info:
> > > > > > > DMA per-cpu:
> > > > > > > CPU 0: hi: 0, btch: 1 usd: 0
> > > > > > > Normal per-cpu:
> > > > > > > CPU 0: hi: 186, btch: 31 usd: 0
> > > > > > > Active_anon:25471 active_file:22802 inactive_anon:25812
> > > > > > > inactive_file:33619 unevictable:2 dirty:2452 writeback:135 unstable:0
> > > > > > > free:4346 slab:4308 mapped:26038 pagetables:912 bounce:0
> > > > > > > DMA free:2060kB min:84kB low:104kB high:124kB active_anon:1660kB inactive_anon:1848kB active_file:144kB inactive_file:868kB unevictable:0kB present:15788kB pages_scanned:0 all_unreclaimable? no
> > > > > > > lowmem_reserve[]: 0 489 489
> > > > > > > Normal free:15324kB min:2788kB low:3484kB high:4180kB active_anon:100224kB inactive_anon:101400kB active_file:91064kB inactive_file:133608kB unevictable:8kB present:501392kB pages_scanned:0 all_unreclaimable? no
> > > > > > > lowmem_reserve[]: 0 0 0
> > > > > > > DMA: 1*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2060kB
> > > > > > > Normal: 1283*4kB 648*8kB 159*16kB 53*32kB 10*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 15324kB
> > > > > > > 57947 total pagecache pages
> > > > > > > 878 pages in swap cache
> > > > > > > Swap cache stats: add 920, delete 42, find 11/11
> > > > > > > Free swap = 1016436kB
> > > > > > > Total swap = 1020116kB
> > > > > > > 131056 pages RAM
> > > > > > > 4233 pages reserved
> > > > > > > 90573 pages shared
> > > > > > > 77286 pages non-shared
> > > > > > > EXT4-fs: mballoc enabled
> > > > > > > EXT4-fs (dm-2): mounted filesystem with ordered data mode
> > > > > > >
> > > > > > > Thus it seems like the original bug is still there and any ideas how to
> > > > > > > debug the problem further are appreciated..
> > > > > > >
> > > > > > > The complete dmesg and kernel config are here:
> > > > > > >
> > > > > > > http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.dmesg
> > > > > > > http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.config
> > > > > >
> > > > > > This looks very similar to the kmemleak ext4 reports upon a mount. If
> > > > > > it is the same issue, which from the trace it seems it is, then this
> > > > > > is due to an extra kmalloc() allocation and this apparently will not
> > > > > > get fixed on 2.6.31 due to the closeness of the merge window and the
> > > > > > non-criticalness this issue has been deemed.
> > > > > >
> > > > > > A patch fix is part of the ext4-patchqueue
> > > > > > http://repo.or.cz/w/ext4-patch-queue.git
> > > > >
> > > > > Thanks for the pointer but the page allocation failures that I hit seem
> > > > > to be caused by the memory management itself and the ext4 issue fixed by:
> > > > >
> > > > > http://repo.or.cz/w/ext4-patch-queue.git?a=blob;f=memory-leak-fix-ext4_group_info-allocation;h=c919fff34e70ec85f96d1833f9ce460c451000de;hb=HEAD
> > > > >
> > > > > is a different problem (unrelated to this one).
> > > >
> > > > Here is another data point.
> > > >
> > > > This time it is an order-6 page allocation failure for rt2870sta
> > > > (w/ upcoming driver changes) and Linus' tree from few days ago..
> > > >
> > >
> > > It's another high-order atomic allocation which is difficult to grant.
> > > I didn't look closely, but is this the same type of thing - large allocation
> > > failure during firmware loading? If so, is this during resume or is the
> > > device being reloaded for some other reason?
> >
> > Just modprobing the driver on a system running for some time.
> >
>
> Was this a common situation before?
Yes, just like firmware restarts with ipw2200.
> > > I suspect that there are going to be a few of these bugs cropping up
> > > every so often where network devices are assuming large atomic
> > > allocations will succeed because the "only time they happen" is during
> > > boot but these days are happening at runtime for other reasons.
> >
> > I wouldn't go so far as calling a normal order-6 (256kB) allocation on
> > 512MB machine with 1024MB swap a bug. Moreover such failures just never
> > happened before 2.6.31-rc1.
>
> It's not that normal, it's an allocation that cannot sleep and cannot
> reclaim. Why is something like firmware loading allocating memory like
OK.
> that? Is this use of GFP_ATOMIC relatively recent or has it always been
> that way?
It has always been like that.
> > I don't know why people don't see it but for me it has a memory management
> > regression and reliability issue written all over it.
> >
>
> Possibly but drivers that reload their firmware as a response to an
> error condition is relatively new and loading network drivers while the
> system is already up and running a long time does not strike me as
> typical system behaviour.
Loading drivers after boot is a typical desktop/laptop behavior, please
think about hotplug (the hardware in question is an USB dongle).
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* 'cfg80211: fix SME connect' breaks b43 in latest net-2.6 and linux-2.6
From: Oliver Hartkopp @ 2009-09-21 10:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: Michael Buesch, Linux Netdev List
In-Reply-To: <4AB4BF1F.7070501@hartkopp.net>
Hello Johannes,
your commit 'cfg80211: fix SME connect' breaks my WPA2 WLAN connection on a
b43 adapter.
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff;h=bbac31f4c0339f6c51afbd0edfb4959df9b53fa9
Oliver Hartkopp wrote:
> my b43 wireless card (Dell 830) is not working with the latest net-2.6 (and
> also linux-2.6 2.6.31-05767-gdf58bee).
>
> net-2.6 2.6.31-03263-gc29854e is working
> net-2.6 2.6.31-03301-ga97e178 is broken
When reverting the mentioned commit it works again.
I'm running a Debian testing distro.
Regards,
Oliver
^ permalink raw reply
* Re: ipw2200: firmware DMA loading rework
From: Mel Gorman @ 2009-09-21 10:08 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Luis R. Rodriguez, Tso Ted, Aneesh Kumar K.V, Zhu Yi,
Andrew Morton, Johannes Weiner, Pekka Enberg, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Mel Gorman,
netdev@vger.kernel.org, linux-mm@kvack.org, James Ketrenos,
Chatre, Reinette, linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <200909211159.27344.bzolnier@gmail.com>
On Mon, Sep 21, 2009 at 11:59:27AM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > > > On Sunday 30 August 2009 14:37:42 Bartlomiej Zolnierkiewicz wrote:
> > > > > >> On Friday 28 August 2009 05:42:31 Zhu Yi wrote:
> > > > > >> > Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
> > > > > >> > for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
> > > > > >>
> > > > > >> s/2.6.30/2.6.31-rc6/
> > > > > >>
> > > > > >> The issue has always been there but it was some recent change that
> > > > > >> explicitly triggered the allocation failures (after 2.6.31-rc1).
> > > > > >
> > > > > > ipw2200 fix works fine but yesterday I got the following error while mounting
> > > > > > ext4 filesystem (mb_history is optional so the mount succeeded):
> > > > >
> > > > > OK so the mount succeeded.
> > > > >
> > > > > > EXT4-fs (dm-2): barriers enabled
> > > > > > kjournald2 starting: pid 3137, dev dm-2:8, commit interval 5 seconds
> > > > > > EXT4-fs (dm-2): internal journal on dm-2:8
> > > > > > EXT4-fs (dm-2): delayed allocation enabled
> > > > > > EXT4-fs: file extents enabled
> > > > > > mount: page allocation failure. order:5, mode:0xc0d0
> > > > > > Pid: 3136, comm: mount Not tainted 2.6.31-rc8-00015-gadda766-dirty #78
> > > > > > Call Trace:
> > > > > > [<c0394de3>] ? printk+0xf/0x14
> > > > > > [<c016a693>] __alloc_pages_nodemask+0x400/0x442
> > > > > > [<c016a71b>] __get_free_pages+0xf/0x32
> > > > > > [<c01865cf>] __kmalloc+0x28/0xfa
> > > > > > [<c023d96f>] ? __spin_lock_init+0x28/0x4d
> > > > > > [<c01f529d>] ext4_mb_init+0x392/0x460
> > > > > > [<c01e99d2>] ext4_fill_super+0x1b96/0x2012
> > > > > > [<c0239bc8>] ? snprintf+0x15/0x17
> > > > > > [<c01c0b26>] ? disk_name+0x24/0x69
> > > > > > [<c018ba63>] get_sb_bdev+0xda/0x117
> > > > > > [<c01e6711>] ext4_get_sb+0x13/0x15
> > > > > > [<c01e7e3c>] ? ext4_fill_super+0x0/0x2012
> > > > > > [<c018ad2d>] vfs_kern_mount+0x3b/0x76
> > > > > > [<c018adad>] do_kern_mount+0x33/0xbd
> > > > > > [<c019d0af>] do_mount+0x660/0x6b8
> > > > > > [<c016a71b>] ? __get_free_pages+0xf/0x32
> > > > > > [<c019d168>] sys_mount+0x61/0x99
> > > > > > [<c0102908>] sysenter_do_call+0x12/0x36
> > > > > > Mem-Info:
> > > > > > DMA per-cpu:
> > > > > > CPU 0: hi: 0, btch: 1 usd: 0
> > > > > > Normal per-cpu:
> > > > > > CPU 0: hi: 186, btch: 31 usd: 0
> > > > > > Active_anon:25471 active_file:22802 inactive_anon:25812
> > > > > > inactive_file:33619 unevictable:2 dirty:2452 writeback:135 unstable:0
> > > > > > free:4346 slab:4308 mapped:26038 pagetables:912 bounce:0
> > > > > > DMA free:2060kB min:84kB low:104kB high:124kB active_anon:1660kB inactive_anon:1848kB active_file:144kB inactive_file:868kB unevictable:0kB present:15788kB pages_scanned:0 all_unreclaimable? no
> > > > > > lowmem_reserve[]: 0 489 489
> > > > > > Normal free:15324kB min:2788kB low:3484kB high:4180kB active_anon:100224kB inactive_anon:101400kB active_file:91064kB inactive_file:133608kB unevictable:8kB present:501392kB pages_scanned:0 all_unreclaimable? no
> > > > > > lowmem_reserve[]: 0 0 0
> > > > > > DMA: 1*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2060kB
> > > > > > Normal: 1283*4kB 648*8kB 159*16kB 53*32kB 10*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 15324kB
> > > > > > 57947 total pagecache pages
> > > > > > 878 pages in swap cache
> > > > > > Swap cache stats: add 920, delete 42, find 11/11
> > > > > > Free swap = 1016436kB
> > > > > > Total swap = 1020116kB
> > > > > > 131056 pages RAM
> > > > > > 4233 pages reserved
> > > > > > 90573 pages shared
> > > > > > 77286 pages non-shared
> > > > > > EXT4-fs: mballoc enabled
> > > > > > EXT4-fs (dm-2): mounted filesystem with ordered data mode
> > > > > >
> > > > > > Thus it seems like the original bug is still there and any ideas how to
> > > > > > debug the problem further are appreciated..
> > > > > >
> > > > > > The complete dmesg and kernel config are here:
> > > > > >
> > > > > > http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.dmesg
> > > > > > http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.config
> > > > >
> > > > > This looks very similar to the kmemleak ext4 reports upon a mount. If
> > > > > it is the same issue, which from the trace it seems it is, then this
> > > > > is due to an extra kmalloc() allocation and this apparently will not
> > > > > get fixed on 2.6.31 due to the closeness of the merge window and the
> > > > > non-criticalness this issue has been deemed.
> > > > >
> > > > > A patch fix is part of the ext4-patchqueue
> > > > > http://repo.or.cz/w/ext4-patch-queue.git
> > > >
> > > > Thanks for the pointer but the page allocation failures that I hit seem
> > > > to be caused by the memory management itself and the ext4 issue fixed by:
> > > >
> > > > http://repo.or.cz/w/ext4-patch-queue.git?a=blob;f=memory-leak-fix-ext4_group_info-allocation;h=c919fff34e70ec85f96d1833f9ce460c451000de;hb=HEAD
> > > >
> > > > is a different problem (unrelated to this one).
> > >
> > > Here is another data point.
> > >
> > > This time it is an order-6 page allocation failure for rt2870sta
> > > (w/ upcoming driver changes) and Linus' tree from few days ago..
> > >
> >
> > It's another high-order atomic allocation which is difficult to grant.
> > I didn't look closely, but is this the same type of thing - large allocation
> > failure during firmware loading? If so, is this during resume or is the
> > device being reloaded for some other reason?
>
> Just modprobing the driver on a system running for some time.
>
Was this a common situation before?
> > I suspect that there are going to be a few of these bugs cropping up
> > every so often where network devices are assuming large atomic
> > allocations will succeed because the "only time they happen" is during
> > boot but these days are happening at runtime for other reasons.
>
> I wouldn't go so far as calling a normal order-6 (256kB) allocation on
> 512MB machine with 1024MB swap a bug. Moreover such failures just never
> happened before 2.6.31-rc1.
It's not that normal, it's an allocation that cannot sleep and cannot
reclaim. Why is something like firmware loading allocating memory like
that? Is this use of GFP_ATOMIC relatively recent or has it always been
that way?
> I don't know why people don't see it but for me it has a memory management
> regression and reliability issue written all over it.
>
Possibly but drivers that reload their firmware as a response to an
error condition is relatively new and loading network drivers while the
system is already up and running a long time does not strike me as
typical system behaviour.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: ipw2200: firmware DMA loading rework
From: Bartlomiej Zolnierkiewicz @ 2009-09-21 9:59 UTC (permalink / raw)
To: Mel Gorman
Cc: Luis R. Rodriguez, Tso Ted, Aneesh Kumar K.V, Zhu Yi,
Andrew Morton, Johannes Weiner, Pekka Enberg, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Mel Gorman,
netdev@vger.kernel.org, linux-mm@kvack.org, James Ketrenos,
Chatre, Reinette, linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <20090921085843.GF12726@csn.ul.ie>
On Monday 21 September 2009 10:58:44 Mel Gorman wrote:
> On Sat, Sep 19, 2009 at 03:25:32PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 02 September 2009 20:26:17 Bartlomiej Zolnierkiewicz wrote:
> > > On Wednesday 02 September 2009 20:02:14 Luis R. Rodriguez wrote:
> > > > On Wed, Sep 2, 2009 at 10:48 AM, Bartlomiej
> > > > Zolnierkiewicz<bzolnier@gmail.com> wrote:
> > > > > On Sunday 30 August 2009 14:37:42 Bartlomiej Zolnierkiewicz wrote:
> > > > >> On Friday 28 August 2009 05:42:31 Zhu Yi wrote:
> > > > >> > Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
> > > > >> > for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
> > > > >>
> > > > >> s/2.6.30/2.6.31-rc6/
> > > > >>
> > > > >> The issue has always been there but it was some recent change that
> > > > >> explicitly triggered the allocation failures (after 2.6.31-rc1).
> > > > >
> > > > > ipw2200 fix works fine but yesterday I got the following error while mounting
> > > > > ext4 filesystem (mb_history is optional so the mount succeeded):
> > > >
> > > > OK so the mount succeeded.
> > > >
> > > > > EXT4-fs (dm-2): barriers enabled
> > > > > kjournald2 starting: pid 3137, dev dm-2:8, commit interval 5 seconds
> > > > > EXT4-fs (dm-2): internal journal on dm-2:8
> > > > > EXT4-fs (dm-2): delayed allocation enabled
> > > > > EXT4-fs: file extents enabled
> > > > > mount: page allocation failure. order:5, mode:0xc0d0
> > > > > Pid: 3136, comm: mount Not tainted 2.6.31-rc8-00015-gadda766-dirty #78
> > > > > Call Trace:
> > > > > [<c0394de3>] ? printk+0xf/0x14
> > > > > [<c016a693>] __alloc_pages_nodemask+0x400/0x442
> > > > > [<c016a71b>] __get_free_pages+0xf/0x32
> > > > > [<c01865cf>] __kmalloc+0x28/0xfa
> > > > > [<c023d96f>] ? __spin_lock_init+0x28/0x4d
> > > > > [<c01f529d>] ext4_mb_init+0x392/0x460
> > > > > [<c01e99d2>] ext4_fill_super+0x1b96/0x2012
> > > > > [<c0239bc8>] ? snprintf+0x15/0x17
> > > > > [<c01c0b26>] ? disk_name+0x24/0x69
> > > > > [<c018ba63>] get_sb_bdev+0xda/0x117
> > > > > [<c01e6711>] ext4_get_sb+0x13/0x15
> > > > > [<c01e7e3c>] ? ext4_fill_super+0x0/0x2012
> > > > > [<c018ad2d>] vfs_kern_mount+0x3b/0x76
> > > > > [<c018adad>] do_kern_mount+0x33/0xbd
> > > > > [<c019d0af>] do_mount+0x660/0x6b8
> > > > > [<c016a71b>] ? __get_free_pages+0xf/0x32
> > > > > [<c019d168>] sys_mount+0x61/0x99
> > > > > [<c0102908>] sysenter_do_call+0x12/0x36
> > > > > Mem-Info:
> > > > > DMA per-cpu:
> > > > > CPU 0: hi: 0, btch: 1 usd: 0
> > > > > Normal per-cpu:
> > > > > CPU 0: hi: 186, btch: 31 usd: 0
> > > > > Active_anon:25471 active_file:22802 inactive_anon:25812
> > > > > inactive_file:33619 unevictable:2 dirty:2452 writeback:135 unstable:0
> > > > > free:4346 slab:4308 mapped:26038 pagetables:912 bounce:0
> > > > > DMA free:2060kB min:84kB low:104kB high:124kB active_anon:1660kB inactive_anon:1848kB active_file:144kB inactive_file:868kB unevictable:0kB present:15788kB pages_scanned:0 all_unreclaimable? no
> > > > > lowmem_reserve[]: 0 489 489
> > > > > Normal free:15324kB min:2788kB low:3484kB high:4180kB active_anon:100224kB inactive_anon:101400kB active_file:91064kB inactive_file:133608kB unevictable:8kB present:501392kB pages_scanned:0 all_unreclaimable? no
> > > > > lowmem_reserve[]: 0 0 0
> > > > > DMA: 1*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2060kB
> > > > > Normal: 1283*4kB 648*8kB 159*16kB 53*32kB 10*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 15324kB
> > > > > 57947 total pagecache pages
> > > > > 878 pages in swap cache
> > > > > Swap cache stats: add 920, delete 42, find 11/11
> > > > > Free swap = 1016436kB
> > > > > Total swap = 1020116kB
> > > > > 131056 pages RAM
> > > > > 4233 pages reserved
> > > > > 90573 pages shared
> > > > > 77286 pages non-shared
> > > > > EXT4-fs: mballoc enabled
> > > > > EXT4-fs (dm-2): mounted filesystem with ordered data mode
> > > > >
> > > > > Thus it seems like the original bug is still there and any ideas how to
> > > > > debug the problem further are appreciated..
> > > > >
> > > > > The complete dmesg and kernel config are here:
> > > > >
> > > > > http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.dmesg
> > > > > http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.config
> > > >
> > > > This looks very similar to the kmemleak ext4 reports upon a mount. If
> > > > it is the same issue, which from the trace it seems it is, then this
> > > > is due to an extra kmalloc() allocation and this apparently will not
> > > > get fixed on 2.6.31 due to the closeness of the merge window and the
> > > > non-criticalness this issue has been deemed.
> > > >
> > > > A patch fix is part of the ext4-patchqueue
> > > > http://repo.or.cz/w/ext4-patch-queue.git
> > >
> > > Thanks for the pointer but the page allocation failures that I hit seem
> > > to be caused by the memory management itself and the ext4 issue fixed by:
> > >
> > > http://repo.or.cz/w/ext4-patch-queue.git?a=blob;f=memory-leak-fix-ext4_group_info-allocation;h=c919fff34e70ec85f96d1833f9ce460c451000de;hb=HEAD
> > >
> > > is a different problem (unrelated to this one).
> >
> > Here is another data point.
> >
> > This time it is an order-6 page allocation failure for rt2870sta
> > (w/ upcoming driver changes) and Linus' tree from few days ago..
> >
>
> It's another high-order atomic allocation which is difficult to grant.
> I didn't look closely, but is this the same type of thing - large allocation
> failure during firmware loading? If so, is this during resume or is the
> device being reloaded for some other reason?
Just modprobing the driver on a system running for some time.
> I suspect that there are going to be a few of these bugs cropping up
> every so often where network devices are assuming large atomic
> allocations will succeed because the "only time they happen" is during
> boot but these days are happening at runtime for other reasons.
I wouldn't go so far as calling a normal order-6 (256kB) allocation on
512MB machine with 1024MB swap a bug. Moreover such failures just never
happened before 2.6.31-rc1.
I don't know why people don't see it but for me it has a memory management
regression and reliability issue written all over it.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: ipw2200: firmware DMA loading rework
From: Mel Gorman @ 2009-09-21 8:58 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Luis R. Rodriguez, Tso Ted, Aneesh Kumar K.V, Zhu Yi,
Andrew Morton, Johannes Weiner, Pekka Enberg, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Mel Gorman,
netdev@vger.kernel.org, linux-mm@kvack.org, James Ketrenos,
Chatre, Reinette, linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <200909191525.33297.bzolnier@gmail.com>
On Sat, Sep 19, 2009 at 03:25:32PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 02 September 2009 20:26:17 Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 02 September 2009 20:02:14 Luis R. Rodriguez wrote:
> > > On Wed, Sep 2, 2009 at 10:48 AM, Bartlomiej
> > > Zolnierkiewicz<bzolnier@gmail.com> wrote:
> > > > On Sunday 30 August 2009 14:37:42 Bartlomiej Zolnierkiewicz wrote:
> > > >> On Friday 28 August 2009 05:42:31 Zhu Yi wrote:
> > > >> > Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
> > > >> > for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
> > > >>
> > > >> s/2.6.30/2.6.31-rc6/
> > > >>
> > > >> The issue has always been there but it was some recent change that
> > > >> explicitly triggered the allocation failures (after 2.6.31-rc1).
> > > >
> > > > ipw2200 fix works fine but yesterday I got the following error while mounting
> > > > ext4 filesystem (mb_history is optional so the mount succeeded):
> > >
> > > OK so the mount succeeded.
> > >
> > > > EXT4-fs (dm-2): barriers enabled
> > > > kjournald2 starting: pid 3137, dev dm-2:8, commit interval 5 seconds
> > > > EXT4-fs (dm-2): internal journal on dm-2:8
> > > > EXT4-fs (dm-2): delayed allocation enabled
> > > > EXT4-fs: file extents enabled
> > > > mount: page allocation failure. order:5, mode:0xc0d0
> > > > Pid: 3136, comm: mount Not tainted 2.6.31-rc8-00015-gadda766-dirty #78
> > > > Call Trace:
> > > > [<c0394de3>] ? printk+0xf/0x14
> > > > [<c016a693>] __alloc_pages_nodemask+0x400/0x442
> > > > [<c016a71b>] __get_free_pages+0xf/0x32
> > > > [<c01865cf>] __kmalloc+0x28/0xfa
> > > > [<c023d96f>] ? __spin_lock_init+0x28/0x4d
> > > > [<c01f529d>] ext4_mb_init+0x392/0x460
> > > > [<c01e99d2>] ext4_fill_super+0x1b96/0x2012
> > > > [<c0239bc8>] ? snprintf+0x15/0x17
> > > > [<c01c0b26>] ? disk_name+0x24/0x69
> > > > [<c018ba63>] get_sb_bdev+0xda/0x117
> > > > [<c01e6711>] ext4_get_sb+0x13/0x15
> > > > [<c01e7e3c>] ? ext4_fill_super+0x0/0x2012
> > > > [<c018ad2d>] vfs_kern_mount+0x3b/0x76
> > > > [<c018adad>] do_kern_mount+0x33/0xbd
> > > > [<c019d0af>] do_mount+0x660/0x6b8
> > > > [<c016a71b>] ? __get_free_pages+0xf/0x32
> > > > [<c019d168>] sys_mount+0x61/0x99
> > > > [<c0102908>] sysenter_do_call+0x12/0x36
> > > > Mem-Info:
> > > > DMA per-cpu:
> > > > CPU 0: hi: 0, btch: 1 usd: 0
> > > > Normal per-cpu:
> > > > CPU 0: hi: 186, btch: 31 usd: 0
> > > > Active_anon:25471 active_file:22802 inactive_anon:25812
> > > > inactive_file:33619 unevictable:2 dirty:2452 writeback:135 unstable:0
> > > > free:4346 slab:4308 mapped:26038 pagetables:912 bounce:0
> > > > DMA free:2060kB min:84kB low:104kB high:124kB active_anon:1660kB inactive_anon:1848kB active_file:144kB inactive_file:868kB unevictable:0kB present:15788kB pages_scanned:0 all_unreclaimable? no
> > > > lowmem_reserve[]: 0 489 489
> > > > Normal free:15324kB min:2788kB low:3484kB high:4180kB active_anon:100224kB inactive_anon:101400kB active_file:91064kB inactive_file:133608kB unevictable:8kB present:501392kB pages_scanned:0 all_unreclaimable? no
> > > > lowmem_reserve[]: 0 0 0
> > > > DMA: 1*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2060kB
> > > > Normal: 1283*4kB 648*8kB 159*16kB 53*32kB 10*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 15324kB
> > > > 57947 total pagecache pages
> > > > 878 pages in swap cache
> > > > Swap cache stats: add 920, delete 42, find 11/11
> > > > Free swap = 1016436kB
> > > > Total swap = 1020116kB
> > > > 131056 pages RAM
> > > > 4233 pages reserved
> > > > 90573 pages shared
> > > > 77286 pages non-shared
> > > > EXT4-fs: mballoc enabled
> > > > EXT4-fs (dm-2): mounted filesystem with ordered data mode
> > > >
> > > > Thus it seems like the original bug is still there and any ideas how to
> > > > debug the problem further are appreciated..
> > > >
> > > > The complete dmesg and kernel config are here:
> > > >
> > > > http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.dmesg
> > > > http://www.kernel.org/pub/linux/kernel/people/bart/ext4-paf.config
> > >
> > > This looks very similar to the kmemleak ext4 reports upon a mount. If
> > > it is the same issue, which from the trace it seems it is, then this
> > > is due to an extra kmalloc() allocation and this apparently will not
> > > get fixed on 2.6.31 due to the closeness of the merge window and the
> > > non-criticalness this issue has been deemed.
> > >
> > > A patch fix is part of the ext4-patchqueue
> > > http://repo.or.cz/w/ext4-patch-queue.git
> >
> > Thanks for the pointer but the page allocation failures that I hit seem
> > to be caused by the memory management itself and the ext4 issue fixed by:
> >
> > http://repo.or.cz/w/ext4-patch-queue.git?a=blob;f=memory-leak-fix-ext4_group_info-allocation;h=c919fff34e70ec85f96d1833f9ce460c451000de;hb=HEAD
> >
> > is a different problem (unrelated to this one).
>
> Here is another data point.
>
> This time it is an order-6 page allocation failure for rt2870sta
> (w/ upcoming driver changes) and Linus' tree from few days ago..
>
It's another high-order atomic allocation which is difficult to grant.
I didn't look closely, but is this the same type of thing - large allocation
failure during firmware loading? If so, is this during resume or is the
device being reloaded for some other reason?
I suspect that there are going to be a few of these bugs cropping up
every so often where network devices are assuming large atomic
allocations will succeed because the "only time they happen" is during
boot but these days are happening at runtime for other reasons.
> ifconfig: page allocation failure. order:6, mode:0x8020
> Pid: 4752, comm: ifconfig Tainted: G WC 2.6.31-04082-g1824090-dirty #80
> Call Trace:
> [<c03996f2>] ? printk+0xf/0x15
> [<c016b841>] __alloc_pages_nodemask+0x41d/0x462
> [<c010681e>] dma_generic_alloc_coherent+0x53/0xbd
> [<c02f83aa>] hcd_buffer_alloc+0xdb/0xe8
> [<c01067cb>] ? dma_generic_alloc_coherent+0x0/0xbd
> [<c02ee2d6>] usb_buffer_alloc+0x16/0x1d
> [<e121b627>] NICInitTransmit+0xe2/0x7e4 [rt2870sta]
> [<e121bfb1>] RTMPAllocTxRxRingMemory+0x11c/0x17b [rt2870sta]
> [<e11f0960>] rt28xx_init+0xa5/0x3f8 [rt2870sta]
> [<e121194a>] rt28xx_open+0x53/0xa2 [rt2870sta]
> [<e1211b77>] MainVirtualIF_open+0x23/0xf6 [rt2870sta]
> [<c03383a4>] dev_open+0x86/0xbb
> [<c0337b1a>] dev_change_flags+0x96/0x147
> [<c036e9cb>] devinet_ioctl+0x20f/0x4f8
> [<c036fc8f>] inet_ioctl+0x8e/0xa7
> [<c032ab50>] sock_ioctl+0x1c9/0x1ed
> [<c032a987>] ? sock_ioctl+0x0/0x1ed
> [<c0195732>] vfs_ioctl+0x18/0x71
> [<c0195cbb>] do_vfs_ioctl+0x491/0x4cf
> [<c01779d6>] ? handle_mm_fault+0x242/0x4ff
> [<c0119609>] ? do_page_fault+0x102/0x292
> [<c0140721>] ? up_read+0x16/0x29
> [<c0195d27>] sys_ioctl+0x2e/0x48
> [<c0102908>] sysenter_do_call+0x12/0x36
> Mem-Info:
> DMA per-cpu:
> CPU 0: hi: 0, btch: 1 usd: 0
> Normal per-cpu:
> CPU 0: hi: 186, btch: 31 usd: 84
> Active_anon:14664 active_file:30057 inactive_anon:31744
> inactive_file:29940 unevictable:2 dirty:11 writeback:0 unstable:0
> free:5421 slab:4037 mapped:7781 pagetables:963 bounce:0
> DMA free:2060kB min:84kB low:104kB high:124kB active_anon:0kB inactive_anon:124kB active_file:3284kB inactive_file:972kB unevictable:0kB present:15788kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 489 489
> Normal free:19624kB min:2788kB low:3484kB high:4180kB active_anon:58656kB inactive_anon:126852kB active_file:116944kB inactive_file:118788kB unevictable:8kB present:501392kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 0 0
> DMA: 3*4kB 0*8kB 2*16kB 1*32kB 1*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 2060kB
> Normal: 2180*4kB 625*8kB 303*16kB 33*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 19624kB
> 64568 total pagecache pages
> 3652 pages in swap cache
> Swap cache stats: add 21642, delete 17990, find 4906/6079
> Free swap = 981700kB
> Total swap = 1020116kB
> 131056 pages RAM
> 4262 pages reserved
> 91941 pages shared
> 60834 pages non-shared
> <-- ERROR in Alloc TX TxContext[0] HTTX_BUFFER !!
> <-- RTMPAllocTxRxRingMemory, Status=3
> ERROR!!! RTMPAllocDMAMemory failed, Status[=0x00000003]
> !!! rt28xx Initialized fail !!!
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [AX25] kernel panic
From: Bernard Pidoux @ 2009-09-21 8:44 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Ralf Baechle DL5RB, Linux Netdev List, linux-hams
In-Reply-To: <20090920210242.GA9804@del.dom.local>
Hi Jarek,
Good fishing !
During the night I catched the following two identical AX25_DBG messages with netconsole
sending already reported message: kernel BUG at kernel/timer.c:913! and followed by kernel
panics and the machine rebooting.
Sep 21 03:24:06 f6bvp-11 klogd: ------------[ cut here ]------------
Sep 21 03:24:06 f6bvp-11 klogd: WARNING: at include/net/ax25.h:260 ax25_kiss_rcv+0x650/0xab0 [ax25]()
Sep 21 03:24:06 f6bvp-11 klogd: Hardware name: MS-7258
Sep 21 03:24:06 f6bvp-11 klogd: Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl aut
h_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss i2c_viapro snd i2c
_core soundcore 8139cp 8139too shpchp pci_hotplug mii sr_mod binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative
cpufreq_powersave acpi_cpufreq freq_table floppy rtc_cmos processor thermal button via_agp sg evdev pata_via ata_generic
ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Sep 21 03:24:06 f6bvp-11 klogd: Pid: 5, comm: events/0 Not tainted 2.6.31-nosmp #3
Sep 21 03:24:06 f6bvp-11 klogd: Call Trace:
Sep 21 03:24:06 f6bvp-11 klogd: <IRQ> [<ffffffffa03ab750>] ? ax25_kiss_rcv+0x650/0xab0 [ax25]
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff81053b90>] warn_slowpath_common+0x80/0xe0
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff81053c12>] warn_slowpath_null+0x22/0x40
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffffa03ab750>] ax25_kiss_rcv+0x650/0xab0 [ax25]
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff8132b4bd>] ? sock_def_readable+0x3d/0x80
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff8132c96d>] ? sock_queue_rcv_skb+0x12d/0x160
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff8133a831>] netif_receive_skb+0x351/0x5f0
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff81061699>] ? run_timer_softirq+0x179/0x250
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff8133ab50>] process_backlog+0x80/0xe0
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff8133b4a4>] net_rx_action+0xf4/0x220
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff8105b242>] __do_softirq+0xe2/0x1d0
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff8101414a>] call_softirq+0x1a/0x30
Sep 21 03:24:06 f6bvp-11 klogd: <EOI> [<ffffffff810162c5>] do_softirq+0x75/0xc0
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff8105b094>] local_bh_enable+0xc4/0xd0
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffffa03cd798>] mkiss_receive_buf+0x3a8/0x460 [mkiss]
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff8104b864>] ? finish_task_switch+0x44/0xe0
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff812af800>] flush_to_ldisc+0x110/0x1f0
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff812af6f0>] ? flush_to_ldisc+0x0/0x1f0
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff8106c263>] worker_thread+0x173/0x260
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff81071be0>] ? autoremove_wake_function+0x0/0x60
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff8106c0f0>] ? worker_thread+0x0/0x260
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff8107149e>] kthread+0xae/0xc0
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff8101404a>] child_rip+0xa/0x20
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff810713f0>] ? kthread+0x0/0xc0
Sep 21 03:24:06 f6bvp-11 klogd: [<ffffffff81014040>] ? child_rip+0x0/0x20
Sep 21 03:24:06 f6bvp-11 klogd: ---[ end trace cea93cec47668ffd ]---
Sep 21 03:24:06 f6bvp-11 klogd: AX25_DBG: 1 ffff88005a127c00 0
Sep 21 04:30:40 f6bvp-11 klogd: ------------[ cut here ]------------
Sep 21 04:30:40 f6bvp-11 klogd: WARNING: at include/net/ax25.h:260 ax25_kiss_rcv+0x650/0xab0 [ax25]()
Sep 21 04:30:40 f6bvp-11 klogd: Hardware name: MS-7258
Sep 21 04:30:40 f6bvp-11 klogd: Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd 8139cp i2c_viapro 8139too soundcore i2c_core shpchp sr_mod mii pci_hotplug binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table processor rtc_cmos floppy button thermal via_agp evdev sg pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Sep 21 04:30:40 f6bvp-11 klogd: Pid: 5, comm: events/0 Not tainted 2.6.31-nosmp #3
Sep 21 04:30:40 f6bvp-11 klogd: Call Trace:
Sep 21 04:30:40 f6bvp-11 klogd: <IRQ> [<ffffffffa03ab750>] ? ax25_kiss_rcv+0x650/0xab0 [ax25]
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff81053b90>] warn_slowpath_common+0x80/0xe0
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff81053c12>] warn_slowpath_null+0x22/0x40
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffffa03ab750>] ax25_kiss_rcv+0x650/0xab0 [ax25]
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff8132b4bd>] ? sock_def_readable+0x3d/0x80
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff8132c96d>] ? sock_queue_rcv_skb+0x12d/0x160
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff8133a831>] netif_receive_skb+0x351/0x5f0
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff81061699>] ? run_timer_softirq+0x179/0x250
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff8133ab50>] process_backlog+0x80/0xe0
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff8133b4a4>] net_rx_action+0xf4/0x220
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff8105b242>] __do_softirq+0xe2/0x1d0
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff8101414a>] call_softirq+0x1a/0x30
Sep 21 04:30:40 f6bvp-11 klogd: <EOI> [<ffffffff810162c5>] do_softirq+0x75/0xc0
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff8105b094>] local_bh_enable+0xc4/0xd0
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffffa03cd798>] mkiss_receive_buf+0x3a8/0x460 [mkiss]
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff8104b864>] ? finish_task_switch+0x44/0xe0
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff812af800>] flush_to_ldisc+0x110/0x1f0
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff8106c71c>] ? schedule_delayed_work+0x2c/0x50
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff812af6f0>] ? flush_to_ldisc+0x0/0x1f0
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff8106c263>] worker_thread+0x173/0x260
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff81071be0>] ? autoremove_wake_function+0x0/0x60
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff8106c0f0>] ? worker_thread+0x0/0x260
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff8107149e>] kthread+0xae/0xc0
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff8101404a>] child_rip+0xa/0x20
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff810713f0>] ? kthread+0x0/0xc0
Sep 21 04:30:40 f6bvp-11 klogd: [<ffffffff81014040>] ? child_rip+0x0/0x20
Sep 21 04:30:40 f6bvp-11 klogd: ---[ end trace 5e079e87d8b30365 ]---
Sep 21 04:30:40 f6bvp-11 klogd: AX25_DBG: 1 ffff880064471c00 0
Regards,
Bernard
^ permalink raw reply
* [PATCH] iproute2: use -fPIC in lib/
From: Andreas Henriksson @ 2009-09-21 7:47 UTC (permalink / raw)
To: shemminger, netdev; +Cc: Dmitry Baryshev, 547602
In-Reply-To: <39840bc80909201712o65b1c84m1bc453bf9d4329a@mail.gmail.com>
The static libnetlink.a library is exposed to other users in Debian via the
"iproute-dev" package. Apparently people are interested in using it in their
shared libraries and would like to see the code be position independent.
Patch below makes the code under lib/ build with -fPIC.
See http://bugs.debian.org/547602
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
diff --git a/lib/Makefile b/lib/Makefile
index bc270bf..da2f0fc 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -1,3 +1,4 @@
+CFLAGS += -fPIC
UTILOBJ=utils.o rt_names.o ll_types.o ll_proto.o ll_addr.o inet_proto.o
^ permalink raw reply related
* Re: [RFC] Virtual Machine Device Queues(VMDq) support on KVM
From: Rusty Russell @ 2009-09-21 7:07 UTC (permalink / raw)
To: virtualization
Cc: Stephen Hemminger, Xin, Xiaohui, kvm@vger.kernel.org,
mst@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, hpa@zytor.com,
mingo@elte.hu, akpm@linux-foundation.org
In-Reply-To: <20090901090518.1193e412@nehalam>
On Wed, 2 Sep 2009 01:35:18 am Stephen Hemminger wrote:
> On Tue, 1 Sep 2009 14:58:19 +0800
> "Xin, Xiaohui" <xiaohui.xin@intel.com> wrote:
>
> > [RFC] Virtual Machine Device Queues (VMDq) support on KVM
> >
> > Network adapter with VMDq technology presents multiple pairs of tx/rx queues,
> > and renders network L2 sorting mechanism based on MAC addresses and VLAN tags
> > for each tx/rx queue pair. Here we present a generic framework, in which network
> > traffic to/from a tx/rx queue pair can be directed from/to a KVM guest without
> > any software copy.
> >
> > Actually this framework can apply to traditional network adapters which have
> > just one tx/rx queue pair. And applications using the same user/kernel interface
> > can utilize this framework to send/receive network traffic directly thru a tx/rx
> > queue pair in a network adapter.
> >
> > We use virtio-net architecture to illustrate the framework.
> >
> >
> > |--------------------| pop add_buf |----------------|
> > | Qemu process | <--------- TX <---------- | Guest Kernel |
> > | | ---------> ----------> | |
> > | Virtio-net | push get_buf | |
> > | (Backend service) | ---------> RX ----------> | Virtio-net |
> > | | <--------- <---------- | driver |
> > | | push get_buf | |
> > |--------------------| |----------------|
> > |
> > |
> > | AIO (read & write) combined with Direct I/O
> > | (which substitute synced file operations)
> > |-----------------------------------------------------------------------|
> > | Host kernel | read: copy-less with directly mapped user |
> > | | space to kernel, payload directly DMAed |
> > | | into user space |
> > | | write: copy-less with directly mapped user |
> > | | space to kernel, payload directly hooked |
> > | | to a skb |
> > | | |
> > | (a likely | |
> > | queue pair | |
> > | instance) | |
> > | | | |
> > | NIC driver <--> TUN/TAP driver |
> > |-----------------------------------------------------------------------|
> > |
> > |
> > traditional adapter or a tx/rx queue pair
> >
> > The basic idea is to utilize the kernel Asynchronous I/O combined with Direct
> > I/O to implements copy-less TUN/TAP device. AIO and Direct I/O is not new to
> > kernel, we still can see it in SCSI tape driver.
> >
> > With traditional file operations, a copying of payload contents from/to the
> > kernel DMA address to/from a user buffer is needed. That's what the copying we
> > want to save.
> >
> > The proposed framework is like this:
> > A TUN/TAP device is bound to a traditional NIC adapter or a tx/rx queue pair in
> > host side. KVM virto-net Backend service, the user space program submits
> > asynchronous read/write I/O requests to the host kernel through TUN/TAP device.
> > The requests are corresponding to the vqueue elements include both transmission
> > & receive. They can be queued in one AIO request and later, the completion will
> > be notified through the underlying packets tx/rx processing of the rx/tx queue
> > pair.
> >
> > Detailed path:
> >
> > To guest Virtio-net driver, packets receive corresponding to asynchronous read
> > I/O requests of Backend service.
> >
> > 1) Guest Virtio-net driver provides header and payload address through the
> > receive vqueue to Virtio-net backend service.
> >
> > 2) Virtio-net backend service encapsulates multiple vqueue elements into
> > multiple AIO control blocks and composes them into one AIO read request.
> >
> > 3) Virtio-net backend service uses io_submit() syscall to pass the request to
> > the TUN/TAP device.
> >
> > 4) Virtio-net backend service uses io_getevents() syscall to check the
> > completion of the request.
> >
> > 5) The TUN/TAP driver receives packets from the queue pair of NIC, and prepares
> > for Direct I/O.
> > A modified NIC driver may render a skb which header is allocated in host
> > kernel, but the payload buffer is directly mapped from user space buffer which
> > are rendered through the AIO request by the Backend service. get_user_pages()
> > may do this. For one AIO read request, the TUN/TAP driver maintains a list for
> > the directly mapped buffers, and a NIC driver tries to get the buffers as
> > payload buffer to compose the new skbs. Of course, if getting the buffers
> > fails, then kernel allocated buffers are used.
> >
> > 6) Modern NIC cards now mostly have the header split feature. The NIC queue
> > pair then may directly DMA the payload into the user spaces mapped payload
> > buffers.
> > Thus a zero-copy for payload is implemented in packet receiving.
> >
> > 7) The TUN/TAP driver manually copy the host header to space user mapped.
> >
> > 8) aio_complete() to notify the Virtio-net backend service for io_getevents().
> >
> >
> > To guest Virtio-net driver, packets send corresponding to asynchronous write
> > I/O requests of backend. The path is similar to packet receive.
> >
> > 1) Guest Virtio-net driver provides header and payload address filled with
> > contents through the transmit vqueue to Virtio-net backed service.
> >
> > 2) Virtio-net backend service encapsulates the vqueue elements into multiple
> > AIO control blocks and composes them into one AIO write request.
> >
> > 3) Virtio-net backend service uses the io_submit() syscall to pass the
> > requests to the TUN/TAP device.
> >
> > 4) Virtio-net backend service uses io_getevents() syscall to check the request
> > completion.
> >
> > 5) The TUN/TAP driver gets the write requests and allocates skbs for it. The
> > header contents are copied into the skb header. The directly mapped user space
> > buffer is easily hooked into skb. Thus a zero copy for payload is implemented
> > in packet sending.
> >
> > 6) aio_complete() to notify the Virtio-net backend service for io_getevents().
> >
> > The proposed framework is described as above.
> >
> > Consider the modifications to the kernel and qemu:
> >
> > To kernel:
> > 1) The TUN/TAP driver may be modified a lot to implement AIO device operations
> > and to implement directly user space mapping into kernel. Code to maintain the
> > directly mapped user buffers should be in. It's just a modification for driver.
> >
> > 2) The NIC driver may be modified to compose skb differently and slightly data
> > structure change to add user directly mapped buffer pointer.
> > Here, maybe it's better for a NIC driver to present an interface for an rx/tx
> > queue pair instance which will also apply to traditional hardware, the kernel
> > interface should not be changed to make the other components happy.
> > The abstraction is useful, though it is not needed immediately here.
> >
> > 3) The skb shared info structure may be modified a little to contain the user
> > directly mapped info.
> >
> > To Qemu:
> > 1) The Virtio-net backend service may be modified to handle AIO read/write
> > requests from the vqueues.
> > 2) Maybe a separate pthread to handle the AIO request triggering is needed.
> >
> > Any comments are appreciated here.
>
> * Code is easier to review than bullet points.
>
> * Direct I/O has to be safe when page is shared by multiple threads,
> and has to be non-blocking since network I/O can take indeterminately
> long (think big queue's, tunneling, ...)
>
> * In the past attempts at Direct I/O on network have always had SMP
> TLB issues. The page has to be flipped or marked as COW on all CPU's
> and the cost of the Inter Processor Interrupt to steal the page has
> been slower than copying
The Guest shouldn't touch the packet, until the virtio net protocol says
it's finished with (just like a real NIC). Even if it's being nasty, if we
have hw csum it'll get the right csum on the wire, and if we don't we copy
internally anyway.
So I think this isn't a problem...
Rusty.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC] skb align patch
From: Eric Dumazet @ 2009-09-21 6:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jesse Brandeburg, Jesper Dangaard Brouer, netdev
In-Reply-To: <20090920142212.1106d2a1@s6510>
Stephen Hemminger a écrit :
> Based on the Intel suggestion that PCI-express overhead is
> a significant cost.
>
> Would people doing performance please measure the impact of
> changing SKB alignment (64 bit only).
I had this idea some time ago when I hit a limit on bnx2 adapter
(Giga bit link, BCM5708S), with small packets. pktgen was able
to send ~500 Mbps 'only', or 700kps if I remember well.
So I tried to align the pktgen build packet to a cache line,
it gave no difference at all, but it was on a 32 bit kernel.
(Thus my patch was for pktgen only, not a generic one as yours)
Could you elaborate why this change could be useful on 64bit ?
Thanks
>
>
> --- a/arch/x86/include/asm/system.h 2009-09-20 14:08:40.922346912 -0700
> +++ b/arch/x86/include/asm/system.h 2009-09-20 14:14:37.012371200 -0700
> @@ -455,4 +455,14 @@ static inline void rdtsc_barrier(void)
> alternative(ASM_NOP3, "lfence", X86_FEATURE_LFENCE_RDTSC);
> }
>
> +#ifndef CONFIG_X86_32
> +/*
> + * DMA to unaligned address is more expensive than the the
> + * overhead of unaligned CPU access.
> + */
> +#define NET_IP_ALIGN 0
> +#define NET_SKB_PAD L1_CACHE_BYTES
> +#endif
> +
> +
> #endif /* _ASM_X86_SYSTEM_H */
> --
^ permalink raw reply
* [PATCH 1/2] netxen: fix minor tx timeout bug
From: Dhananjay Phadke @ 2009-09-21 5:20 UTC (permalink / raw)
To: davem; +Cc: netdev
Fix minor bug in netdev tx timeout handling which could
always lead to firmware reset instead of pci function reset.
netxen_nic_reset_context() requires __NX_RESETTING bit
cleared.
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
---
drivers/net/netxen/netxen_nic_main.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index f7bdde1..b8c7235 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -1903,12 +1903,13 @@ static void netxen_tx_timeout_task(struct work_struct *work)
netif_wake_queue(adapter->netdev);
- goto done;
+ clear_bit(__NX_RESETTING, &adapter->state);
} else {
+ clear_bit(__NX_RESETTING, &adapter->state);
if (!netxen_nic_reset_context(adapter)) {
adapter->netdev->trans_start = jiffies;
- goto done;
+ return;
}
/* context reset failed, fall through for fw reset */
@@ -1916,8 +1917,6 @@ static void netxen_tx_timeout_task(struct work_struct *work)
request_reset:
adapter->need_fw_reset = 1;
-done:
- clear_bit(__NX_RESETTING, &adapter->state);
}
struct net_device_stats *netxen_nic_get_stats(struct net_device *netdev)
--
1.6.0.2
^ permalink raw reply related
* [PATCH 2/2] netxen: fix firmware init after resume
From: Dhananjay Phadke @ 2009-09-21 5:20 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1253510439-28464-1-git-send-email-dhananjay@netxen.com>
After successful firmware init, return instead of
falling to error path (leading to detach) after
resuming to D0 state. This was broken in recent
firmware reset rehaul.
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
---
drivers/net/netxen/netxen_nic_main.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index b8c7235..b5aa974 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -1469,6 +1469,7 @@ netxen_nic_resume(struct pci_dev *pdev)
}
netxen_schedule_work(adapter, netxen_fw_poll_work, FW_POLL_DELAY);
+ return 0;
err_out_detach:
netxen_nic_detach(adapter);
--
1.6.0.2
^ permalink raw reply related
* [Patch net-next]atl1c:remove compiling warning
From: jie.yang @ 2009-09-21 5:01 UTC (permalink / raw)
To: davem; +Cc: akpm, jirislaby, jcliburn, netdev, linux-kernel, Jie Yang
Set wol_ctrl_data to value 0, to remove compiling warning.
Signed-off-by: Jie Yang <jie.yang@atheros.com>
---
diff --git a/drivers/net/atl1c/atl1c_main.c b/drivers/net/atl1c/atl1c_main.c
index be2c6cf..1372e9a 100644
--- a/drivers/net/atl1c/atl1c_main.c
+++ b/drivers/net/atl1c/atl1c_main.c
@@ -2296,7 +2296,7 @@ static int atl1c_suspend(struct pci_dev *pdev, pm_message_t state)
u32 ctrl;
u32 mac_ctrl_data;
u32 master_ctrl_data;
- u32 wol_ctrl_data;
+ u32 wol_ctrl_data = 0;
u16 mii_bmsr_data;
u16 save_autoneg_advertised;
u16 mii_intr_status_data;
^ permalink raw reply related
* Re: [PANIC] pktgen panic on load
From: Stephen Hemminger @ 2009-09-21 4:35 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: netdev
In-Reply-To: <1253486747.17792.9.camel@jbrandeb-mobl2>
On Sun, 20 Sep 2009 15:45:47 -0700
Jesse Brandeburg <jesse.brandeburg@intel.com> wrote:
> just got this today after cloning Linus' tree, please let me know if you
> want .config or full dmesg
config would help (hrt, nohz, preempt, ...), and was it just on module load?
or had you started it sending?
> [ 22.441999] modprobe used greatest stack depth: 3144 bytes left
> [ 503.775093] ------------[ cut here ]------------
> [ 503.780252] kernel BUG at net/core/pktgen.c:3503!
> [ 503.785505] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
> [ 503.791575] last sysfs file: /sys/devices/system/cpu/sched_smt_power_savings
> [ 503.799443] CPU 6
> [ 503.801698] Modules linked in: pktgen(+) ixgbe mdio [last unloaded: scsi_wait_scan]
> [ 503.810313] Pid: 6120, comm: kpktgend_13 Not tainted 2.6.31 #1 S5520HC
> [ 503.817600] RIP: 0010:[<ffffffffa0029cda>] [<ffffffffa0029cda>] pktgen_thread_worker+0x76/0x1497 [pktgen]
> [ 503.828402] RSP: 0018:ffff88036dca7d80 EFLAGS: 00010297
> [ 503.834332] RAX: 0000000000000006 RBX: ffff88036d6d0fe0 RCX: 0000000000000000
> [ 503.842299] RDX: 0000000000000006 RSI: ffff8800282d3740 RDI: ffff88036dca7e18
> [ 503.850264] RBP: ffff88036dca7ee0 R08: ffff88036dca6000 R09: ffff8801ed430700
> [ 503.858231] R10: 00000000afddf7db R11: ffff8801e0423e08 R12: ffff88036d9dd9e8
> [ 503.866195] R13: ffffffffa0029c64 R14: ffff88036d9dd9e8 R15: 0000000000000001
> [ 503.874161] FS: 0000000000000000(0000) GS:ffff8800282c0000(0000) knlGS:0000000000000000
> [ 503.883196] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> [ 503.889611] CR2: 00007f1bb5b3e00f CR3: 00000001d7c91000 CR4: 00000000000006e0
> [ 503.897578] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 503.905544] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 503.913513] Process kpktgend_13 (pid: 6120, threadinfo ffff88036dca6000, task ffff88036d6d0fe0)
> [ 503.923224] Stack:
> [ 503.925472] ffff88036dca7ea0 00000002afddf7db 000000000000028c 00000000d2c939bd
> [ 503.933573] <0> ffff88036dca7e00 ffffffff8100a7b4 ffff8801f5993740 00000000afddf7db
> [ 503.942191] <0> ffff8800282d3740 ffff8801ef1897d0 ffff88036dca7e10 ffffffff8104906c
> [ 503.951002] Call Trace:
> [ 503.953739] [<ffffffff8100a7b4>] ? __switch_to+0xfd/0x23b
> [ 503.959870] [<ffffffff8104906c>] ? finish_task_switch+0x4d/0x92
> [ 503.966582] [<ffffffff8106b57b>] ? autoremove_wake_function+0x0/0x5a
> [ 503.973778] [<ffffffff8147aaa5>] ? thread_return+0x71/0xd8
> [ 503.980003] [<ffffffffa0029c64>] ? pktgen_thread_worker+0x0/0x1497 [pktgen]
> [ 503.987874] [<ffffffff8106b12e>] kthread+0x89/0x91
> [ 503.993321] [<ffffffff8100ce5a>] child_rip+0xa/0x20
> [ 503.998865] [<ffffffff8106b0a5>] ? kthread+0x0/0x91
> [ 504.004409] [<ffffffff8100ce50>] ? child_rip+0x0/0x20
> [ 504.010146] Code: 48 89 85 28 ff ff ff 48 89 85 30 ff ff ff 48 c7 85 20 ff ff ff 7b b5 06 81 65 8b 04 25 30 cc 00 00 41 3b 84 24 34 02 00 00 74 04 <0f> 0b eb fe 49 8d 94 24 38 02 00 00 48 c7 c6 a8 ec 02 a0 48 89
> [ 504.032139] RIP [<ffffffffa0029cda>] pktgen_thread_worker+0x76/0x1497 [pktgen]
> [ 504.040316] RSP <ffff88036dca7d80>
> [ 504.044227] ---[ end trace ddca71c9720a201f ]---
>
--
^ permalink raw reply
* [PATCH kernel 2.6.31-git9] 3c574_cs: spin_lock the set_multicast_list function
From: Ken Kawasaki @ 2009-09-21 4:10 UTC (permalink / raw)
To: netdev
In-Reply-To: <20090913072203.d92f1734.ken_kawasaki@spring.nifty.jp>
3c574_cs:
spin_lock the set_multicast_list,
and clean up the set_rx_mode function.
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
---
--- linux-2.6.31-git9.orig/drivers/net/pcmcia/3c574_cs.c 2009-09-20 06:53:31.000000000 +0900
+++ linux-2.6.31-git9/drivers/net/pcmcia/3c574_cs.c 2009-09-20 07:03:39.000000000 +0900
@@ -251,6 +251,7 @@ static void el3_tx_timeout(struct net_de
static int el3_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
static const struct ethtool_ops netdev_ethtool_ops;
static void set_rx_mode(struct net_device *dev);
+static void set_multicast_list(struct net_device *dev);
static void tc574_detach(struct pcmcia_device *p_dev);
@@ -266,7 +267,7 @@ static const struct net_device_ops el3_n
.ndo_tx_timeout = el3_tx_timeout,
.ndo_get_stats = el3_get_stats,
.ndo_do_ioctl = el3_ioctl,
- .ndo_set_multicast_list = set_rx_mode,
+ .ndo_set_multicast_list = set_multicast_list,
.ndo_change_mtu = eth_change_mtu,
.ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
@@ -1153,12 +1154,23 @@ static void set_rx_mode(struct net_devic
unsigned int ioaddr = dev->base_addr;
if (dev->flags & IFF_PROMISC)
- outw(SetRxFilter | RxStation | RxMulticast | RxBroadcast | RxProm,
- ioaddr + EL3_CMD);
+ outw(SetRxFilter|RxStation|RxMulticast|RxBroadcast|RxProm,
+ ioaddr + EL3_CMD);
else if (dev->mc_count || (dev->flags & IFF_ALLMULTI))
- outw(SetRxFilter|RxStation|RxMulticast|RxBroadcast, ioaddr + EL3_CMD);
+ outw(SetRxFilter|RxStation|RxMulticast|RxBroadcast,
+ ioaddr + EL3_CMD);
else
- outw(SetRxFilter | RxStation | RxBroadcast, ioaddr + EL3_CMD);
+ outw(SetRxFilter|RxStation|RxBroadcast, ioaddr + EL3_CMD);
+}
+
+static void set_multicast_list(struct net_device *dev)
+{
+ struct el3_private *lp = netdev_priv(dev);
+ unsigned long flags;
+
+ spin_lock_irqsave(&lp->window_lock, flags);
+ set_rx_mode(dev);
+ spin_unlock_irqrestore(&lp->window_lock, flags);
}
static int el3_close(struct net_device *dev)
^ permalink raw reply
* Re: sky2 rx length errors
From: Stephen Hemminger @ 2009-09-21 1:46 UTC (permalink / raw)
To: Mike McCormack
Cc: Andrew Morton, Grozdan, linux-kernel, Stephen Hemminger, netdev
In-Reply-To: <392fb48f0909201511h34c71e0au838b52c413d517e0@mail.gmail.com>
On Mon, 21 Sep 2009 07:11:21 +0900
Mike McCormack <mikem@ring3k.org> wrote:
> 2009/9/21 Stephen Hemminger <shemminger@vyatta.com>
>
> > On Sat, 19 Sep 2009 23:35:36 -0700
> > Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > (added cc's from the MAINTAINERS file)
> > >
> > > On Fri, 18 Sep 2009 15:41:45 +0200 Grozdan <neutrino8@gmail.com> wrote:
> >
>
> <snip>
>
> > > martian destination 0.0.0.0 from 172.23.204.1, dev eth0
> > > > sky2 eth0: rx length error: status 0x4420100 length 598
> > > > sky2 eth0: rx length error: status 0x5ea0100 length 598
> >
> > This error status occurs if the length reported by the PHY does not
> > match the len reported by the DMA engine. The error status is:
> > 0x4420100 = length 1090 + broadcast packet...
> >
> > No idea what is on your network, but perhaps there is some MTU confusion?
> > Since martian destination seems related, knowing more about that packet
> > might help.
> >
> >
> This appears to be the same problem reported at:
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/292445
>
> Mike
This really looks like multiple packets are getting smashed
together into one DMA, i.e a hardware timing related issue.
it might be possible to work around the problem
by separating them.
--
^ permalink raw reply
* r8169 64-bit DMA support
From: Robert Hancock @ 2009-09-20 23:38 UTC (permalink / raw)
To: netdev; +Cc: Francois Romieu
The r8169 driver currently disables 64-bit DMA support by default (needs
a module parameter to turn it on). This is a bit sub-optimal these days
with most new systems using more than 4GB of RAM. It was this patch back
in 2004 that disabled it:
http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commitdiff;h=c525e7cf69bfe18a1bf362558be5398e0b925d07
It's not clear (from the mails I've read) exactly what was going on in
the case that caused this to be added. Normally these days the PCI
subsystem is supposed to detect that DAC isn't usable on a machine and
refuse setting 64-bit DMA masks, it's not the driver's responsibility to
handle this. I'm guessing that when this change was made that detection
didn't exist though.
Thoughts on whether this default can be changed now? Or at least for the
PCI Express devices, which really should have nothing special about
64-bit addressing..
^ permalink raw reply
* [PANIC] pktgen panic on load
From: Jesse Brandeburg @ 2009-09-20 22:45 UTC (permalink / raw)
To: netdev
just got this today after cloning Linus' tree, please let me know if you
want .config or full dmesg
[ 22.441999] modprobe used greatest stack depth: 3144 bytes left
[ 503.775093] ------------[ cut here ]------------
[ 503.780252] kernel BUG at net/core/pktgen.c:3503!
[ 503.785505] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 503.791575] last sysfs file: /sys/devices/system/cpu/sched_smt_power_savings
[ 503.799443] CPU 6
[ 503.801698] Modules linked in: pktgen(+) ixgbe mdio [last unloaded: scsi_wait_scan]
[ 503.810313] Pid: 6120, comm: kpktgend_13 Not tainted 2.6.31 #1 S5520HC
[ 503.817600] RIP: 0010:[<ffffffffa0029cda>] [<ffffffffa0029cda>] pktgen_thread_worker+0x76/0x1497 [pktgen]
[ 503.828402] RSP: 0018:ffff88036dca7d80 EFLAGS: 00010297
[ 503.834332] RAX: 0000000000000006 RBX: ffff88036d6d0fe0 RCX: 0000000000000000
[ 503.842299] RDX: 0000000000000006 RSI: ffff8800282d3740 RDI: ffff88036dca7e18
[ 503.850264] RBP: ffff88036dca7ee0 R08: ffff88036dca6000 R09: ffff8801ed430700
[ 503.858231] R10: 00000000afddf7db R11: ffff8801e0423e08 R12: ffff88036d9dd9e8
[ 503.866195] R13: ffffffffa0029c64 R14: ffff88036d9dd9e8 R15: 0000000000000001
[ 503.874161] FS: 0000000000000000(0000) GS:ffff8800282c0000(0000) knlGS:0000000000000000
[ 503.883196] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[ 503.889611] CR2: 00007f1bb5b3e00f CR3: 00000001d7c91000 CR4: 00000000000006e0
[ 503.897578] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 503.905544] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 503.913513] Process kpktgend_13 (pid: 6120, threadinfo ffff88036dca6000, task ffff88036d6d0fe0)
[ 503.923224] Stack:
[ 503.925472] ffff88036dca7ea0 00000002afddf7db 000000000000028c 00000000d2c939bd
[ 503.933573] <0> ffff88036dca7e00 ffffffff8100a7b4 ffff8801f5993740 00000000afddf7db
[ 503.942191] <0> ffff8800282d3740 ffff8801ef1897d0 ffff88036dca7e10 ffffffff8104906c
[ 503.951002] Call Trace:
[ 503.953739] [<ffffffff8100a7b4>] ? __switch_to+0xfd/0x23b
[ 503.959870] [<ffffffff8104906c>] ? finish_task_switch+0x4d/0x92
[ 503.966582] [<ffffffff8106b57b>] ? autoremove_wake_function+0x0/0x5a
[ 503.973778] [<ffffffff8147aaa5>] ? thread_return+0x71/0xd8
[ 503.980003] [<ffffffffa0029c64>] ? pktgen_thread_worker+0x0/0x1497 [pktgen]
[ 503.987874] [<ffffffff8106b12e>] kthread+0x89/0x91
[ 503.993321] [<ffffffff8100ce5a>] child_rip+0xa/0x20
[ 503.998865] [<ffffffff8106b0a5>] ? kthread+0x0/0x91
[ 504.004409] [<ffffffff8100ce50>] ? child_rip+0x0/0x20
[ 504.010146] Code: 48 89 85 28 ff ff ff 48 89 85 30 ff ff ff 48 c7 85 20 ff ff ff 7b b5 06 81 65 8b 04 25 30 cc 00 00 41 3b 84 24 34 02 00 00 74 04 <0f> 0b eb fe 49 8d 94 24 38 02 00 00 48 c7 c6 a8 ec 02 a0 48 89
[ 504.032139] RIP [<ffffffffa0029cda>] pktgen_thread_worker+0x76/0x1497 [pktgen]
[ 504.040316] RSP <ffff88036dca7d80>
[ 504.044227] ---[ end trace ddca71c9720a201f ]---
--
Jesse Brandeburg
This email sent from Evolution, powered by Linux
^ permalink raw reply
* [RFC] skb align patch
From: Stephen Hemminger @ 2009-09-20 21:22 UTC (permalink / raw)
To: Jesse Brandeburg, Jesper Dangaard Brouer; +Cc: netdev
Based on the Intel suggestion that PCI-express overhead is
a significant cost.
Would people doing performance please measure the impact of
changing SKB alignment (64 bit only).
--- a/arch/x86/include/asm/system.h 2009-09-20 14:08:40.922346912 -0700
+++ b/arch/x86/include/asm/system.h 2009-09-20 14:14:37.012371200 -0700
@@ -455,4 +455,14 @@ static inline void rdtsc_barrier(void)
alternative(ASM_NOP3, "lfence", X86_FEATURE_LFENCE_RDTSC);
}
+#ifndef CONFIG_X86_32
+/*
+ * DMA to unaligned address is more expensive than the the
+ * overhead of unaligned CPU access.
+ */
+#define NET_IP_ALIGN 0
+#define NET_SKB_PAD L1_CACHE_BYTES
+#endif
+
+
#endif /* _ASM_X86_SYSTEM_H */
^ permalink raw reply
* [GIT *] Solos PCI ADSL driver update
From: David Woodhouse @ 2009-09-20 21:17 UTC (permalink / raw)
To: davem; +Cc: netdev
I'm sorry, I suck. I forgot I had anything outstanding to be pushed
upstream, and should have done this a while ago.
In later versions of the card's FPGA code, the RAM layout for
card<->host communication has changed -- and the new FPGA code is in the
devices which are being shipped now, so it would be really useful if we
could sneak this into 2.6.32. Sorry it's so late.
Please pull from git://git.infradead.org/users/dwmw2/solos-2.6.git
David Woodhouse (1):
solos: Add some margin-related parameters
Nathan Williams (2):
solos: support new FPGA RAM layout
solos: Check for rogue received packets
Simon Farnsworth (1):
solos: Show Interleaving details for ADSL2 and 2+
drivers/atm/solos-attrlist.c | 11 ++++++
drivers/atm/solos-pci.c | 75 +++++++++++++++++++++++++++++++++++++-----
2 files changed, 77 insertions(+), 9 deletions(-)
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [AX25] kernel panic
From: Jarek Poplawski @ 2009-09-20 21:02 UTC (permalink / raw)
To: Bernard Pidoux; +Cc: Ralf Baechle DL5RB, Linux Netdev List, linux-hams
In-Reply-To: <4AB5EAE5.6070605@upmc.fr>
On Sun, Sep 20, 2009 at 10:42:13AM +0200, Bernard Pidoux wrote:
> Hi,
>
> Here are the first events noticed since I turned on
> CONFIG_DEBUG_OBJECTS_TIMERS option.
>
> First a kernel BUG, second a kernel panic.
...
> ------------[ cut here ]------------
> kernel BUG at kernel/timer.c:913!
Alas this BUG doesn't show much (this new debugging didn't trigger
here). Maybe the patch below will be luckier.
Best regards,
Jarek P.
---
include/net/ax25.h | 36 ++++++++++++++++++++++++++++++++++++
net/ax25/af_ax25.c | 3 +++
2 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/include/net/ax25.h b/include/net/ax25.h
index 717e219..e8f6e33 100644
--- a/include/net/ax25.h
+++ b/include/net/ax25.h
@@ -252,9 +252,45 @@ typedef struct ax25_cb {
#define ax25_cb_hold(__ax25) \
atomic_inc(&((__ax25)->refcount))
+static __inline__ int ax25_timers_warn(ax25_cb *ax25)
+{
+ int err = 0;
+
+ if (del_timer(&ax25->timer)) {
+ WARN_ON_ONCE(1);
+ err = 1;
+ }
+ if (del_timer(&ax25->t1timer)) {
+ WARN_ON_ONCE(1);
+ err += 2;
+ }
+ if (del_timer(&ax25->t2timer)) {
+ WARN_ON_ONCE(1);
+ err += 4;
+ }
+ if (del_timer(&ax25->t3timer)) {
+ WARN_ON_ONCE(1);
+ err += 8;
+ }
+ if (del_timer(&ax25->idletimer)) {
+ WARN_ON_ONCE(1);
+ err += 16;
+ }
+ if (del_timer(&ax25->dtimer)) {
+ WARN_ON_ONCE(1);
+ err += 32;
+ }
+ if (err)
+ printk(KERN_WARNING "AX25_DBG: %d %p %u\n", err, ax25,
+ ax25->state);
+
+ return err;
+}
+
static __inline__ void ax25_cb_put(ax25_cb *ax25)
{
if (atomic_dec_and_test(&ax25->refcount)) {
+ ax25_timers_warn(ax25);
kfree(ax25->digipeat);
kfree(ax25);
}
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index da0f64f..f443fe0 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -58,6 +58,9 @@ static const struct proto_ops ax25_proto_ops;
static void ax25_free_sock(struct sock *sk)
{
+ if (ax25_timers_warn(ax25_sk(sk)))
+ printk(KERN_WARNING "AX25_DBG: %p %u %u %u\n", sk,
+ sk->sk_family, sk->sk_type, sk->sk_protocol);
ax25_cb_put(ax25_sk(sk));
}
^ permalink raw reply related
* [PATCH] ipv4: fib table algorithm performance improvement
From: Stephen Hemminger @ 2009-09-20 20:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev
The FIB algorithim for IPV4 is set at compile time, but kernel goes through
the overhead of function call indirection at runtime. Save some
cycles by turning the indirect calls to direct calls to either
hash or trie code.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/include/net/ip_fib.h 2009-09-20 12:16:02.819467348 -0700
+++ b/include/net/ip_fib.h 2009-09-20 12:37:53.391940040 -0700
@@ -144,18 +144,21 @@ struct fib_table {
struct hlist_node tb_hlist;
u32 tb_id;
int tb_default;
- int (*tb_lookup)(struct fib_table *tb, const struct flowi *flp, struct fib_result *res);
- int (*tb_insert)(struct fib_table *, struct fib_config *);
- int (*tb_delete)(struct fib_table *, struct fib_config *);
- int (*tb_dump)(struct fib_table *table, struct sk_buff *skb,
- struct netlink_callback *cb);
- int (*tb_flush)(struct fib_table *table);
- void (*tb_select_default)(struct fib_table *table,
- const struct flowi *flp, struct fib_result *res);
-
unsigned char tb_data[0];
};
+extern int fib_table_lookup(struct fib_table *tb, const struct flowi *flp,
+ struct fib_result *res);
+extern int fib_table_insert(struct fib_table *, struct fib_config *);
+extern int fib_table_delete(struct fib_table *, struct fib_config *);
+extern int fib_table_dump(struct fib_table *table, struct sk_buff *skb,
+ struct netlink_callback *cb);
+extern int fib_table_flush(struct fib_table *table);
+extern void fib_table_select_default(struct fib_table *table,
+ const struct flowi *flp,
+ struct fib_result *res);
+
+
#ifndef CONFIG_IP_MULTIPLE_TABLES
#define TABLE_LOCAL_INDEX 0
@@ -182,11 +185,11 @@ static inline int fib_lookup(struct net
struct fib_table *table;
table = fib_get_table(net, RT_TABLE_LOCAL);
- if (!table->tb_lookup(table, flp, res))
+ if (!fib_table_lookup(table, flp, res))
return 0;
table = fib_get_table(net, RT_TABLE_MAIN);
- if (!table->tb_lookup(table, flp, res))
+ if (!fib_table_lookup(table, flp, res))
return 0;
return -ENETUNREACH;
}
--- a/net/ipv4/fib_frontend.c 2009-09-20 12:23:52.199466411 -0700
+++ b/net/ipv4/fib_frontend.c 2009-09-20 12:26:45.969439904 -0700
@@ -125,7 +125,7 @@ void fib_select_default(struct net *net,
#endif
tb = fib_get_table(net, table);
if (FIB_RES_GW(*res) && FIB_RES_NH(*res).nh_scope == RT_SCOPE_LINK)
- tb->tb_select_default(tb, flp, res);
+ fib_table_select_default(tb, flp, res);
}
static void fib_flush(struct net *net)
@@ -139,7 +139,7 @@ static void fib_flush(struct net *net)
for (h = 0; h < FIB_TABLE_HASHSZ; h++) {
head = &net->ipv4.fib_table_hash[h];
hlist_for_each_entry(tb, node, head, tb_hlist)
- flushed += tb->tb_flush(tb);
+ flushed += fib_table_flush(tb);
}
if (flushed)
@@ -162,7 +162,7 @@ struct net_device * ip_dev_find(struct n
#endif
local_table = fib_get_table(net, RT_TABLE_LOCAL);
- if (!local_table || local_table->tb_lookup(local_table, &fl, &res))
+ if (!local_table || fib_table_lookup(local_table, &fl, &res))
return NULL;
if (res.type != RTN_LOCAL)
goto out;
@@ -200,7 +200,7 @@ static inline unsigned __inet_dev_addr_t
local_table = fib_get_table(net, RT_TABLE_LOCAL);
if (local_table) {
ret = RTN_UNICAST;
- if (!local_table->tb_lookup(local_table, &fl, &res)) {
+ if (!fib_table_lookup(local_table, &fl, &res)) {
if (!dev || dev == res.fi->fib_dev)
ret = res.type;
fib_res_put(&res);
@@ -473,13 +473,13 @@ int ip_rt_ioctl(struct net *net, unsigne
if (cmd == SIOCDELRT) {
tb = fib_get_table(net, cfg.fc_table);
if (tb)
- err = tb->tb_delete(tb, &cfg);
+ err = fib_table_delete(tb, &cfg);
else
err = -ESRCH;
} else {
tb = fib_new_table(net, cfg.fc_table);
if (tb)
- err = tb->tb_insert(tb, &cfg);
+ err = fib_table_insert(tb, &cfg);
else
err = -ENOBUFS;
}
@@ -594,7 +594,7 @@ static int inet_rtm_delroute(struct sk_b
goto errout;
}
- err = tb->tb_delete(tb, &cfg);
+ err = fib_table_delete(tb, &cfg);
errout:
return err;
}
@@ -616,7 +616,7 @@ static int inet_rtm_newroute(struct sk_b
goto errout;
}
- err = tb->tb_insert(tb, &cfg);
+ err = fib_table_insert(tb, &cfg);
errout:
return err;
}
@@ -647,7 +647,7 @@ static int inet_dump_fib(struct sk_buff
if (dumped)
memset(&cb->args[2], 0, sizeof(cb->args) -
2 * sizeof(cb->args[0]));
- if (tb->tb_dump(tb, skb, cb) < 0)
+ if (fib_table_dump(tb, skb, cb) < 0)
goto out;
dumped = 1;
next:
@@ -701,9 +701,9 @@ static void fib_magic(int cmd, int type,
cfg.fc_scope = RT_SCOPE_HOST;
if (cmd == RTM_NEWROUTE)
- tb->tb_insert(tb, &cfg);
+ fib_table_insert(tb, &cfg);
else
- tb->tb_delete(tb, &cfg);
+ fib_table_delete(tb, &cfg);
}
void fib_add_ifaddr(struct in_ifaddr *ifa)
@@ -832,7 +832,7 @@ static void nl_fib_lookup(struct fib_res
local_bh_disable();
frn->tb_id = tb->tb_id;
- frn->err = tb->tb_lookup(tb, &fl, &res);
+ frn->err = fib_table_lookup(tb, &fl, &res);
if (!frn->err) {
frn->prefixlen = res.prefixlen;
@@ -1009,7 +1009,7 @@ static void __net_exit ip_fib_net_exit(s
head = &net->ipv4.fib_table_hash[i];
hlist_for_each_entry_safe(tb, node, tmp, head, tb_hlist) {
hlist_del(node);
- tb->tb_flush(tb);
+ fib_table_flush(tb);
kfree(tb);
}
}
--- a/net/ipv4/fib_rules.c 2009-09-20 12:30:43.159471244 -0700
+++ b/net/ipv4/fib_rules.c 2009-09-20 12:32:08.709470541 -0700
@@ -94,7 +94,7 @@ static int fib4_rule_action(struct fib_r
if ((tbl = fib_get_table(rule->fr_net, rule->table)) == NULL)
goto errout;
- err = tbl->tb_lookup(tbl, flp, (struct fib_result *) arg->result);
+ err = fib_table_lookup(tbl, flp, (struct fib_result *) arg->result);
if (err > 0)
err = -EAGAIN;
errout:
--- a/net/ipv4/fib_trie.c 2009-09-20 12:23:59.409447223 -0700
+++ b/net/ipv4/fib_trie.c 2009-09-20 12:29:45.041693219 -0700
@@ -1174,7 +1174,7 @@ done:
/*
* Caller must hold RTNL.
*/
-static int fn_trie_insert(struct fib_table *tb, struct fib_config *cfg)
+int fib_table_insert(struct fib_table *tb, struct fib_config *cfg)
{
struct trie *t = (struct trie *) tb->tb_data;
struct fib_alias *fa, *new_fa;
@@ -1373,8 +1373,8 @@ static int check_leaf(struct trie *t, st
return 1;
}
-static int fn_trie_lookup(struct fib_table *tb, const struct flowi *flp,
- struct fib_result *res)
+int fib_table_lookup(struct fib_table *tb, const struct flowi *flp,
+ struct fib_result *res)
{
struct trie *t = (struct trie *) tb->tb_data;
int ret;
@@ -1595,7 +1595,7 @@ static void trie_leaf_remove(struct trie
/*
* Caller must hold RTNL.
*/
-static int fn_trie_delete(struct fib_table *tb, struct fib_config *cfg)
+int fib_table_delete(struct fib_table *tb, struct fib_config *cfg)
{
struct trie *t = (struct trie *) tb->tb_data;
u32 key, mask;
@@ -1786,7 +1786,7 @@ static struct leaf *trie_leafindex(struc
/*
* Caller must hold RTNL.
*/
-static int fn_trie_flush(struct fib_table *tb)
+int fib_table_flush(struct fib_table *tb)
{
struct trie *t = (struct trie *) tb->tb_data;
struct leaf *l, *ll = NULL;
@@ -1807,9 +1807,9 @@ static int fn_trie_flush(struct fib_tabl
return found;
}
-static void fn_trie_select_default(struct fib_table *tb,
- const struct flowi *flp,
- struct fib_result *res)
+void fib_table_select_default(struct fib_table *tb,
+ const struct flowi *flp,
+ struct fib_result *res)
{
struct trie *t = (struct trie *) tb->tb_data;
int order, last_idx;
@@ -1952,8 +1952,8 @@ static int fn_trie_dump_leaf(struct leaf
return skb->len;
}
-static int fn_trie_dump(struct fib_table *tb, struct sk_buff *skb,
- struct netlink_callback *cb)
+int fib_table_dump(struct fib_table *tb, struct sk_buff *skb,
+ struct netlink_callback *cb)
{
struct leaf *l;
struct trie *t = (struct trie *) tb->tb_data;
@@ -2020,12 +2020,6 @@ struct fib_table *fib_hash_table(u32 id)
tb->tb_id = id;
tb->tb_default = -1;
- tb->tb_lookup = fn_trie_lookup;
- tb->tb_insert = fn_trie_insert;
- tb->tb_delete = fn_trie_delete;
- tb->tb_flush = fn_trie_flush;
- tb->tb_select_default = fn_trie_select_default;
- tb->tb_dump = fn_trie_dump;
t = (struct trie *) tb->tb_data;
memset(t, 0, sizeof(*t));
--- a/net/ipv4/fib_hash.c 2009-09-20 12:23:55.799439103 -0700
+++ b/net/ipv4/fib_hash.c 2009-09-20 12:46:25.700353394 -0700
@@ -242,8 +242,8 @@ fn_new_zone(struct fn_hash *table, int z
return fz;
}
-static int
-fn_hash_lookup(struct fib_table *tb, const struct flowi *flp, struct fib_result *res)
+int fib_table_lookup(struct fib_table *tb,
+ const struct flowi *flp, struct fib_result *res)
{
int err;
struct fn_zone *fz;
@@ -274,8 +274,8 @@ out:
return err;
}
-static void
-fn_hash_select_default(struct fib_table *tb, const struct flowi *flp, struct fib_result *res)
+void fib_table_select_default(struct fib_table *tb,
+ const struct flowi *flp, struct fib_result *res)
{
int order, last_idx;
struct hlist_node *node;
@@ -366,7 +366,7 @@ static struct fib_node *fib_find_node(st
return NULL;
}
-static int fn_hash_insert(struct fib_table *tb, struct fib_config *cfg)
+int fib_table_insert(struct fib_table *tb, struct fib_config *cfg)
{
struct fn_hash *table = (struct fn_hash *) tb->tb_data;
struct fib_node *new_f = NULL;
@@ -544,8 +544,7 @@ out:
return err;
}
-
-static int fn_hash_delete(struct fib_table *tb, struct fib_config *cfg)
+int fib_table_delete(struct fib_table *tb, struct fib_config *cfg)
{
struct fn_hash *table = (struct fn_hash *)tb->tb_data;
struct fib_node *f;
@@ -662,7 +661,7 @@ static int fn_flush_list(struct fn_zone
return found;
}
-static int fn_hash_flush(struct fib_table *tb)
+int fib_table_flush(struct fib_table *tb)
{
struct fn_hash *table = (struct fn_hash *) tb->tb_data;
struct fn_zone *fz;
@@ -743,7 +742,8 @@ fn_hash_dump_zone(struct sk_buff *skb, s
return skb->len;
}
-static int fn_hash_dump(struct fib_table *tb, struct sk_buff *skb, struct netlink_callback *cb)
+int fib_table_dump(struct fib_table *tb, struct sk_buff *skb,
+ struct netlink_callback *cb)
{
int m, s_m;
struct fn_zone *fz;
@@ -787,12 +787,7 @@ struct fib_table *fib_hash_table(u32 id)
tb->tb_id = id;
tb->tb_default = -1;
- tb->tb_lookup = fn_hash_lookup;
- tb->tb_insert = fn_hash_insert;
- tb->tb_delete = fn_hash_delete;
- tb->tb_flush = fn_hash_flush;
- tb->tb_select_default = fn_hash_select_default;
- tb->tb_dump = fn_hash_dump;
+
memset(tb->tb_data, 0, sizeof(struct fn_hash));
return tb;
}
^ permalink raw reply
* Re: SO_TIMESTAMPING fix and design decisions
From: Christopher Zimmermann @ 2009-09-20 18:50 UTC (permalink / raw)
To: netdev
In-Reply-To: <1253468893.2654.6.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]
On Sun, 20 Sep 2009 10:48:13 -0700
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> wrote:
> On Sun, 2009-09-20 at 00:52 -0700, Christopher Zimmermann wrote:
> > On Sat, 19 Sep 2009 15:09:21 -0700
> > Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> wrote:
> >
> > > > hardware timestamps only work for the Intel igb driver. I have
> > > > access to two test machines with NICs supported by this driver.
> > >
> > > Intel's 82599, supported by ixgbe, also has the same IEEE 1588
> > > timestamping support in hardware. We haven't implemented the support
> > > yet in ixgbe, but the hardware is there and does work. If you were
> > > curious of the interface, the datasheet for the hardware is available on
> > > our SourceForge site (e1000.sf.net).
> >
> > hi! thanks for the reply.
> >
> > I already got the documentation for the 82576 cards I have access to. I
> > won't be able to afford another pair.
> >
> > What do you think about my idea to expose the relevant registers to
> > userspace? I believe it would not be too difficult for userspace to
> > configure the timestamps this way and would allow way more flexibility.
> > Of course I would #DEFINE the constants used to set the registers.
>
> The patch seems reasonable, but I haven't played with the igb
> timestamping very much. However, what impact will this have on the
> existing ptpd userspace daemon?
It will need to be modified. If you want to avoid this, one could keep
the HWTSTAMP_FILTER_PTP_.... defines and just redifine them to reflect
the new interface.
Where can I find this ptpd userspace daemon, which supports hardware
timestamps using the ioctl interface? ptpd.sourceforge.net doesn't.
Cheers,
Christopher Zimmermann
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH net-next-2.6] bonding: remove useless assignment
From: Nicolas de Pesloüan @ 2009-09-20 18:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Jay Vosburgh, bonding-devel
The variable old_active is first set to bond->curr_active_slave.
Then, it is unconditionally set to new_active, without being used in between.
The first assignment, having no side effect, is useless.
Signed-off-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
---
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index a7e731f..fce7233 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1084,7 +1084,7 @@ static struct slave *bond_find_best_slave(struct bonding *bond)
int mintime = bond->params.updelay;
int i;
- new_active = old_active = bond->curr_active_slave;
+ new_active = bond->curr_active_slave;
if (!new_active) { /* there were no active slaves left */
if (bond->slave_cnt > 0) /* found one slave */
^ permalink raw reply related
* Re: sky2 rx length errors
From: Stephen Hemminger @ 2009-09-20 18:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: Grozdan, linux-kernel, Stephen Hemminger, netdev
In-Reply-To: <20090919233536.f5fb700c.akpm@linux-foundation.org>
On Sat, 19 Sep 2009 23:35:36 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> (added cc's from the MAINTAINERS file)
>
> On Fri, 18 Sep 2009 15:41:45 +0200 Grozdan <neutrino8@gmail.com> wrote:
>
> > Hi,
> >
> > I have a Marvell onboard NIC (88E8053) and I've been noticing for a
> > while now a bit weird behavior with the sky2 driver. This mostly
> > occurs with newer kernels (2.6.30, 2.6.31) and my older distro kernel
> > (2.6.27.21) does not seem to have the same problem. Basically, the
> > sky2 driver will randomly and unpredictably spew rx length error
> > messages and reboot itself. I also noticed in dmesg that this mostly
> > occurs after "martian destination" messages. After this message, sky2
> > starts spewing messages as shown below and then reboots itself. It is
> > not really a big problem for me, but since I'm virtually always logged
> > in in IRC, the client always loses connection, waits for a few minutes
> > to get a response from the server and then relogs me again. I do not
> > think it's a HW problem as the Marvell NIC otherwise works perfectly
> > and I've checked my cable modem too which operates without a problem.
> > Any ideas?
> >
> > PS: please cc me as I'm not subscribed to the mailing list
> >
> > sky2 driver version 1.23
> > sky2 0000:05:00.0: PCI INT A -> GSI 36 (level, low) -> IRQ 36
> > sky2 0000:05:00.0: setting latency timer to 64
> > sky2 0000:05:00.0: PCI: Disallowing DAC for device
> > sky2 0000:05:00.0: Yukon-2 EC chip revision 2
> > sky2 0000:05:00.0: irq 53 for MSI/MSI-X
> > sky2 0000:05:00.0: No interrupt generated using MSI, switching to INTx mode.
> > sky2 eth0: addr 00:11:d8:a1:5b:0e
> > sky2 eth0: enabling interface
> > sky2 eth0: Link is up at 100 Mbps, full duplex, flow control rx
> > .....
> > .....
> > martian destination 0.0.0.0 from 172.23.204.1, dev eth0
> > sky2 eth0: rx length error: status 0x4420100 length 598
> > sky2 eth0: rx length error: status 0x5ea0100 length 598
This error status occurs if the length reported by the PHY does not
match the len reported by the DMA engine. The error status is:
0x4420100 = length 1090 + broadcast packet...
No idea what is on your network, but perhaps there is some MTU confusion?
Since martian destination seems related, knowing more about that packet
might help.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox