* Re: Page Allocation Failure with e1000 using jumbo frame
From: Nivedita Singhvi @ 2005-08-19 17:03 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: Ming Zhang, E1000, iet-dev, netdev
In-Reply-To: <Pine.WNT.4.63.0508190940210.3796@jbrandeb-desk.amr.corp.intel.com>
Jesse Brandeburg wrote:
> included netdev...
>
>
> On Wed, 17 Aug 2005, Ming Zhang wrote:
>
>>
>> Hi folks
>>
>> We ran into this problem when running jumbo frame with iscsi over e1000.
>> the MTU1500 is fine while jumbo frame can stably reproduce this error.
>>
>> when meet this error, as reported in iet list, the box still has >600MB
>> ram free. also the slab is not heavily used.
>>
>> any idea on this?
>
>
>
> So, what we do know is that your kernel memory manager is (for whatever
> unknown reason) having trouble finding contiguous 2^3 pages (32kB)
> chunks of memory. This occurs because we need to give our hardware 16kB
> contiguous (currently, we actually have a patch for this in internal
> testing) which means that when we do dev_alloc_skb, it allocates 16kB +
> 16 bytes reserve, plus 2 bytes NET_IP_ALIGN, which takes us into the
> 32kB slab (power of two roundup)
>
> I guess we need to approach the memory manager guys and ask them why the
> current kernels are having so much trouble getting contiguous memory.
> Also, recently thanks to David Miller's discussions on socket charge, we
> understand that we're getting hit hard by using such a big buffer.
>
> Netdev any ideas?
Interesting you should mention this, I just mentioned it
in the context of another thread like 3 seconds ago.
I've talked to Martin Bligh in the past about having the
VM do something sane about these to improve the situation - I'll
go kick, er, ping him again...
The current status is "try not to do that" (large contig allocs).
If anyone has any good ideas, speak up :)
thanks,
Nivedita
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* 2.6.13-rc6-mm1: too many 'ipv4_table' variables
From: Adrian Bunk @ 2005-08-19 17:28 UTC (permalink / raw)
To: Andrew Morton, netdev; +Cc: linux-kernel
In-Reply-To: <20050819043331.7bc1f9a9.akpm@osdl.org>
On Fri, Aug 19, 2005 at 04:33:31AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.13-rc5-mm1:
>...
> git-net.patch
>...
> Subsystem trees
>...
It seems there are too many different 'ipv4_table' variables:
<-- snip -->
...
CC net/ipv4/ipvs/ip_vs_ctl.o
net/ipv4/ipvs/ip_vs_ctl.c:1601: error: static declaration of 'ipv4_table' follows non-static declaration
include/net/ip.h:376: error: previous declaration of 'ipv4_table' was here
make[3]: *** [net/ipv4/ipvs/ip_vs_ctl.o] Error 1
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: Page Allocation Failure with e1000 using jumboframe
From: Jesse Brandeburg @ 2005-08-19 17:33 UTC (permalink / raw)
To: Ming Zhang; +Cc: Brandeburg, Jesse, E1000, iet-dev, netdev
In-Reply-To: <1124470909.5552.11.camel@localhost.localdomain>
On Fri, 19 Aug 2005, Ming Zhang wrote:
> This is first reported on IET list and then i redo the test with vanilla
> 2.6.12.4 kernel and everything went fine.
>
> so i suspect if there are special case caused by vendor kernel.
>
> is this 32KB ATOMIC ram allocation request only available in jumbo frame
> case? since the regular MTU case goes fine.
>
Ahh, okay. I'm pretty sure that SuSE did some changes (not sure what) to
memory management.
the formula for the size that the current e1000 looks for is something
like
a = MTU roundup to next power of 2
a += 2 (skb_reserve(NET_IP_ALIGN))
a += 16 (skb_reserve 16 by __dev_alloc_skb)
so, a = 2048 + 2 + 16, or 2066
request (a) from slab, which does a power of 2 roundup
so the skb comes from the 4k (single page) slab for standard mtu.
Jesse
PS we have a driver in test that won't do the large contig allocations any
more.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: [E1000-devel] Page Allocation Failure with e1000 using jumboframe
From: Andi Kleen @ 2005-08-19 17:42 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: Ming Zhang, E1000, iet-dev, netdev
In-Reply-To: <Pine.WNT.4.63.0508191023130.3796@jbrandeb-desk.amr.corp.intel.com>
> Ahh, okay. I'm pretty sure that SuSE did some changes (not sure what) to
> memory management.
I don't think so.
>
> the formula for the size that the current e1000 looks for is something
> like
>
> a = MTU roundup to next power of 2
> a += 2 (skb_reserve(NET_IP_ALIGN))
> a += 16 (skb_reserve 16 by __dev_alloc_skb)
>
> so, a = 2048 + 2 + 16, or 2066
> request (a) from slab, which does a power of 2 roundup
> so the skb comes from the 4k (single page) slab for standard mtu.
That's very suboptimal because you're wasting nearly 2k. It would
be better if you allocated 4k or exactly 2k
-Andi
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: [E1000-devel] Page Allocation Failure with e1000 using jumboframe
From: Jesse Brandeburg @ 2005-08-19 17:51 UTC (permalink / raw)
To: Andi Kleen; +Cc: Brandeburg, Jesse, Ming Zhang, E1000, iet-dev, netdev
In-Reply-To: <20050819174201.GJ3953@verdi.suse.de>
On Fri, 19 Aug 2005, Andi Kleen wrote:
> > Ahh, okay. I'm pretty sure that SuSE did some changes (not sure what) to
> > memory management.
>
> I don't think so.
I could certainly be mistaken. The difference I saw was that suse kernels
recycle the same skb pointers back to our driver, and the redhat kernels
seem to march through a much larger range before the values repeat. This
is all observation based, so I may be completely wrong on this issue.
> > the formula for the size that the current e1000 looks for is something
> > like
> >
> > a = MTU roundup to next power of 2
> > a += 2 (skb_reserve(NET_IP_ALIGN))
> > a += 16 (skb_reserve 16 by __dev_alloc_skb)
> >
> > so, a = 2048 + 2 + 16, or 2066
> > request (a) from slab, which does a power of 2 roundup
> > so the skb comes from the 4k (single page) slab for standard mtu.
>
> That's very suboptimal because you're wasting nearly 2k. It would
> be better if you allocated 4k or exactly 2k
we have to give the full 2k to hardware, unfortunately. which means
mapping the full 2k. we do the skb reserve because of cache/alighment
effects which show a (big) hit in performance if we don't align the IP
header. Yes I know that dword unaligned DMA really hurts on some arches,
but thats why the arch can #def NET_IP_ALIGN 0.
if thats the case, then we're left asking the question, who uses that 16
bytes that are skb_reserved by __dev_alloc_skb???
Jesse
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: Page Allocation Failure with e1000 using jumboframe
From: Ming Zhang @ 2005-08-19 17:52 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: E1000, iet-dev, netdev
In-Reply-To: <Pine.WNT.4.63.0508191023130.3796@jbrandeb-desk.amr.corp.intel.com>
On Fri, 2005-08-19 at 10:33 -0700, Jesse Brandeburg wrote:
> On Fri, 19 Aug 2005, Ming Zhang wrote:
> > This is first reported on IET list and then i redo the test with vanilla
> > 2.6.12.4 kernel and everything went fine.
> >
> > so i suspect if there are special case caused by vendor kernel.
> >
> > is this 32KB ATOMIC ram allocation request only available in jumbo frame
> > case? since the regular MTU case goes fine.
> >
>
> Ahh, okay. I'm pretty sure that SuSE did some changes (not sure what) to
> memory management.
>
> the formula for the size that the current e1000 looks for is something
> like
>
> a = MTU roundup to next power of 2
> a += 2 (skb_reserve(NET_IP_ALIGN))
> a += 16 (skb_reserve 16 by __dev_alloc_skb)
>
> so, a = 2048 + 2 + 16, or 2066
> request (a) from slab, which does a power of 2 roundup
> so the skb comes from the 4k (single page) slab for standard mtu.
>
that is wasteful.
> Jesse
>
> PS we have a driver in test that won't do the large contig allocations any
> more.
>
then wait to see this. :P
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: [E1000-devel] Page Allocation Failure with e1000 using jumboframe
From: Andi Kleen @ 2005-08-19 18:01 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: Andi Kleen, Ming Zhang, E1000, iet-dev, netdev
In-Reply-To: <Pine.WNT.4.63.0508191043440.3796@jbrandeb-desk.amr.corp.intel.com>
> I could certainly be mistaken. The difference I saw was that suse kernels
> recycle the same skb pointers back to our driver, and the redhat kernels
> seem to march through a much larger range before the values repeat. This
> is all observation based, so I may be completely wrong on this issue.
Maybe you're comparing 2.4 to 2.6 or different 2.6s. But I don't
think there are any SUSE specific patches affecting this.
>
> >> the formula for the size that the current e1000 looks for is something
> >> like
> >>
> >> a = MTU roundup to next power of 2
> >> a += 2 (skb_reserve(NET_IP_ALIGN))
> >> a += 16 (skb_reserve 16 by __dev_alloc_skb)
> >>
> >> so, a = 2048 + 2 + 16, or 2066
> >> request (a) from slab, which does a power of 2 roundup
> >> so the skb comes from the 4k (single page) slab for standard mtu.
> >
> >That's very suboptimal because you're wasting nearly 2k. It would
> >be better if you allocated 4k or exactly 2k
>
> we have to give the full 2k to hardware, unfortunately. which means
> mapping the full 2k. we do the skb reserve because of cache/alighment
> effects which show a (big) hit in performance if we don't align the IP
> header. Yes I know that dword unaligned DMA really hurts on some arches,
> but thats why the arch can #def NET_IP_ALIGN 0.
What is the requirement of your hardware? power of two alignment or
power of two size? If the later does it really trash the data behind it?
But surely it doesn't use all of the 2k for the 1.5k MTU, so it
would be good if you could fit the header alignment in there
and only get the exact needed amount from the underlying allocator.
>
> if thats the case, then we're left asking the question, who uses that 16
> bytes that are skb_reserved by __dev_alloc_skb???
Nothing, except maybe routing to a different class of link layer that
needs bigger headers (e.g. PPP). Even then it's just a performance
optimization to avoid a skb copy.
I suppose it would be possible to keep track of the largest supported
hard_header_len of all devices and if it's all identical don't add the
16 bytes.
-Andi
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: [E1000-devel] Page Allocation Failure with e1000 using jumbo frame
From: Martin Josefsson @ 2005-08-19 18:10 UTC (permalink / raw)
To: Andi Kleen; +Cc: Jesse Brandeburg, Ming Zhang, E1000, iet-dev, netdev
In-Reply-To: <20050819170248.GH3953@verdi.suse.de>
[-- Attachment #1: Type: text/plain, Size: 724 bytes --]
On Fri, 2005-08-19 at 19:02 +0200, Andi Kleen wrote:
> > I guess we need to approach the memory manager guys and ask them why the
> > current kernels are having so much trouble getting contiguous memory.
>
> Because memory fragments.
>
> The only long term reliable way is to not allocate buffers > PAGE_SIZE.
> The stack supports paged skbs for that.
And the e1000 supports receiving/transmitting packets containing several
buffers according to the SDM, it just uses more descriptors in the rx/tx
rings.
Maybe it should allocate PAGE_SIZE large buffers, a 9kB packet would
then use 3 such buffers.
And it of course means more and smaller DMA transfers than when using
larger buffers.
--
/Martin
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [E1000-devel] Page Allocation Failure with e1000 using jumboframe
From: Ming Zhang @ 2005-08-19 19:07 UTC (permalink / raw)
To: Andi Kleen; +Cc: Jesse Brandeburg, E1000, iet-dev, netdev
In-Reply-To: <20050819180132.GO22993@wotan.suse.de>
I am sorry that the guy who found this problem is running suse linux,
but with vanilla kernel. so this is a generic problem, not suse
specific.
I am sorry for my insaneness at that time. :P
Ming
On Fri, 2005-08-19 at 20:01 +0200, Andi Kleen wrote:
> > I could certainly be mistaken. The difference I saw was that suse kernels
> > recycle the same skb pointers back to our driver, and the redhat kernels
> > seem to march through a much larger range before the values repeat. This
> > is all observation based, so I may be completely wrong on this issue.
>
> Maybe you're comparing 2.4 to 2.6 or different 2.6s. But I don't
> think there are any SUSE specific patches affecting this.
>
> >
> > >> the formula for the size that the current e1000 looks for is something
> > >> like
> > >>
> > >> a = MTU roundup to next power of 2
> > >> a += 2 (skb_reserve(NET_IP_ALIGN))
> > >> a += 16 (skb_reserve 16 by __dev_alloc_skb)
> > >>
> > >> so, a = 2048 + 2 + 16, or 2066
> > >> request (a) from slab, which does a power of 2 roundup
> > >> so the skb comes from the 4k (single page) slab for standard mtu.
> > >
> > >That's very suboptimal because you're wasting nearly 2k. It would
> > >be better if you allocated 4k or exactly 2k
> >
> > we have to give the full 2k to hardware, unfortunately. which means
> > mapping the full 2k. we do the skb reserve because of cache/alighment
> > effects which show a (big) hit in performance if we don't align the IP
> > header. Yes I know that dword unaligned DMA really hurts on some arches,
> > but thats why the arch can #def NET_IP_ALIGN 0.
>
> What is the requirement of your hardware? power of two alignment or
> power of two size? If the later does it really trash the data behind it?
>
> But surely it doesn't use all of the 2k for the 1.5k MTU, so it
> would be good if you could fit the header alignment in there
> and only get the exact needed amount from the underlying allocator.
>
>
> >
> > if thats the case, then we're left asking the question, who uses that 16
> > bytes that are skb_reserved by __dev_alloc_skb???
>
> Nothing, except maybe routing to a different class of link layer that
> needs bigger headers (e.g. PPP). Even then it's just a performance
> optimization to avoid a skb copy.
>
> I suppose it would be possible to keep track of the largest supported
> hard_header_len of all devices and if it's all identical don't add the
> 16 bytes.
>
> -Andi
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: Possible race with br_del_if()
From: Ryan Harper @ 2005-08-19 19:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20050818153531.61f62ac0@dxpl.pdx.osdl.net>
* Stephen Hemminger <shemminger@osdl.org> [2005-08-18 17:36]:
> On Thu, 18 Aug 2005 17:23:23 -0500
> Ryan Harper <ryanh@us.ibm.com> wrote:
>
> > * Stephen Hemminger <shemminger@osdl.org> [2005-08-18 17:11]:
> > > On Thu, 18 Aug 2005 16:40:36 -0500
> > > Ryan Harper <ryanh@us.ibm.com> wrote:
> > >
> > > > Hello,
> > > >
> > > > I've encountered several oops when adding and removing interfaces from
> > > > bridges while using Xen. Most of the details are available [1]here.
> > > > The short of it is the following sequence:
> > >
> > > Doesn't the mutex in RTNL work right? or are you calling
> > > routines with out asserting it?
> >
> > unregister_netdevice asserts RTNL, add_del_if() in br_ioctl.c doesn't
> > seem to do so. I don't see it down dev_get_by_index() path either. It
> > looks like any caller of add_del_if() isn't asserting RTNL. The two
> > callers I see are:
> >
> > br_dev_ioctl() in br_ioctl.c
> > old_dev_ioctl() in br_ioctl.c
>
> But the pat to br_dev_ioctl() is via the socket ioctl and that
> should already have gotten RTNL.
>
>
> dev_ioctl
> rtnl_lock()
> dev_ifsioc()
> dev->do_ioctl --> br_dev_ioctl
Just to follow-up, the issue was a race between the call_rcu() callback
for destroy_nbp() and an unregister_netdev() call. Sometimes the
br_device_event() routine was triggered and destroy_nbp() had not been
run yet leaving dev->br_port non-NULL to which br_device_event then
correctly calls br_del_if().
We caused this by issuing a brctl delif from userspace scripts and
having a in kernel handler invoke unregister_netdev() call.
Our fix is to not bother calling brctl delif because the
unregister_netdev() call will automatically remove the device from the
bridge when the notify_call_chain() kicks in from
unregister_netdevice().
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh@us.ibm.com
^ permalink raw reply
* Re: Possible race with br_del_if()
From: Stephen Hemminger @ 2005-08-19 19:40 UTC (permalink / raw)
To: Ryan Harper; +Cc: netdev
In-Reply-To: <20050819191052.GE5523@us.ibm.com>
On Fri, 19 Aug 2005 14:10:52 -0500
Ryan Harper <ryanh@us.ibm.com> wrote:
> * Stephen Hemminger <shemminger@osdl.org> [2005-08-18 17:36]:
> > On Thu, 18 Aug 2005 17:23:23 -0500
> > Ryan Harper <ryanh@us.ibm.com> wrote:
> >
> > > * Stephen Hemminger <shemminger@osdl.org> [2005-08-18 17:11]:
> > > > On Thu, 18 Aug 2005 16:40:36 -0500
> > > > Ryan Harper <ryanh@us.ibm.com> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I've encountered several oops when adding and removing interfaces from
> > > > > bridges while using Xen. Most of the details are available [1]here.
> > > > > The short of it is the following sequence:
> > > >
> > > > Doesn't the mutex in RTNL work right? or are you calling
> > > > routines with out asserting it?
> > >
> > > unregister_netdevice asserts RTNL, add_del_if() in br_ioctl.c doesn't
> > > seem to do so. I don't see it down dev_get_by_index() path either. It
> > > looks like any caller of add_del_if() isn't asserting RTNL. The two
> > > callers I see are:
> > >
> > > br_dev_ioctl() in br_ioctl.c
> > > old_dev_ioctl() in br_ioctl.c
> >
> > But the pat to br_dev_ioctl() is via the socket ioctl and that
> > should already have gotten RTNL.
> >
> >
> > dev_ioctl
> > rtnl_lock()
> > dev_ifsioc()
> > dev->do_ioctl --> br_dev_ioctl
>
>
> Just to follow-up, the issue was a race between the call_rcu() callback
> for destroy_nbp() and an unregister_netdev() call. Sometimes the
> br_device_event() routine was triggered and destroy_nbp() had not been
> run yet leaving dev->br_port non-NULL to which br_device_event then
> correctly calls br_del_if().
>
> We caused this by issuing a brctl delif from userspace scripts and
> having a in kernel handler invoke unregister_netdev() call.
>
> Our fix is to not bother calling brctl delif because the
> unregister_netdev() call will automatically remove the device from the
> bridge when the notify_call_chain() kicks in from
> unregister_netdevice().
I'll get back to you, this needs some review, I have a bunch of old
test suites to dig up for it.
^ permalink raw reply
* Re: [E1000-devel] Page Allocation Failure with e1000 using jumboframe
From: Jesse Brandeburg @ 2005-08-19 21:10 UTC (permalink / raw)
To: Andi Kleen; +Cc: Brandeburg, Jesse, Ming Zhang, E1000, iet-dev, netdev
In-Reply-To: <20050819180132.GO22993@wotan.suse.de>
On Fri, 19 Aug 2005, Andi Kleen wrote:
> > >> the formula for the size that the current e1000 looks for is something
> > >> like
> > >>
> > >> a = MTU roundup to next power of 2
> > >> a += 2 (skb_reserve(NET_IP_ALIGN))
> > >> a += 16 (skb_reserve 16 by __dev_alloc_skb)
> > >>
> > >> so, a = 2048 + 2 + 16, or 2066
> > >> request (a) from slab, which does a power of 2 roundup
> > >> so the skb comes from the 4k (single page) slab for standard mtu.
> > >
> > >That's very suboptimal because you're wasting nearly 2k. It would
> > >be better if you allocated 4k or exactly 2k
> >
> > we have to give the full 2k to hardware, unfortunately. which means
> > mapping the full 2k. we do the skb reserve because of cache/alighment
> > effects which show a (big) hit in performance if we don't align the IP
> > header. Yes I know that dword unaligned DMA really hurts on some arches,
> > but thats why the arch can #def NET_IP_ALIGN 0.
>
> What is the requirement of your hardware? power of two alignment or
> power of two size? If the later does it really trash the data behind it?
our pci/pci-x hardware requires the full 2k, (power of 2 size) and it can
trash the data behind it even in the 1500 MTU case because a frame larger
than 1518 bytes can be received, and we could fill a whole descriptor and
overflow into the next. see next paragraph.
> But surely it doesn't use all of the 2k for the 1.5k MTU, so it
> would be good if you could fit the header alignment in there
> and only get the exact needed amount from the underlying allocator.
that would be ideal. Depending on the memory constraints of the system,
we could set the RCTL.LPE=0 (long packet enable that forces the hardware
to drop packets more than 1522 bytes) that would then enable us to
cheat/optimize for the 1500 MTU case. I guess then we just call alloc_skb
directly instead of the dev version.
> > if thats the case, then we're left asking the question, who uses that 16
> > bytes that are skb_reserved by __dev_alloc_skb???
>
> Nothing, except maybe routing to a different class of link layer that
> needs bigger headers (e.g. PPP). Even then it's just a performance
> optimization to avoid a skb copy.
>
> I suppose it would be possible to keep track of the largest supported
> hard_header_len of all devices and if it's all identical don't add the
> 16 bytes.
hmm, all this is pie in the sky until we can get some of this tested.
Unfortunately those resources are busy here :-(
Jesse
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: 2.6.13-rc6-rt6
From: Steven Rostedt @ 2005-08-19 21:22 UTC (permalink / raw)
To: Ingo Molnar; +Cc: netdev, Paul E. McKenney, linux-kernel
In-Reply-To: <20050817162324.GA24495@elte.hu>
On Wed, 2005-08-17 at 18:23 +0200, Ingo Molnar wrote:
>
> > And it goes on and on. This happens everytime. Without netconsole, I
> > only get the nonzero lock count error. Also, one of my lockups on SMP
> > had to do with the kernel_thread_helper:
> >
> > Using IPI Shortcut mode
> > khelper/794[CPU#0]: BUG in set_new_owner at kernel/rt.c:916
This was with netconsole and showed up after a bunch of other bugs. So
this is a side effect of what happened earlier.
>
> this is a 'must not happen'. Somehow lock->held list got non-empty.
> Maybe some use-after-free thing? Havent seen it myself.
>
I started debugging netconsole with the RT patch and found this
happening. After seeing what's wrong, I looked at the latest git
branch, and it seems to already have a similar solution that I was going
to make. Here's a description of what's wrong.
In net/core/dev.c the following code is in net_rx_action:
netpoll_poll_lock(dev);
if (dev->quota <= 0 || dev->poll(dev, &budget)) {
netpoll_poll_unlock(dev);
raw_local_irq_disable();
list_del(&dev->poll_list);
list_add_tail(&dev->poll_list, &queue->poll_list);
if (dev->quota < 0)
dev->quota += dev->weight;
else
dev->quota = dev->weight;
} else {
netpoll_poll_unlock(dev);
The netpoll_poll_lock and netpoll_poll_unlock look like this (in current RT):
static inline netpoll_poll_lock(struct net_device *dev)
{
if (dev->npinfo) {
spin_lock(&dev->npinfo->poll_lock);
dev->npinfo->poll_owner = smp_processor_id();
}
}
static inline void netpoll_poll_unlock(struct net_device *dev)
{
if (dev->npinfo) {
dev->npinfo->poll_owner = -1;
spin_unlock(&dev->npinfo->poll_lock);
}
}
The problem here is that between netpoll_poll_lock and
netpoll_poll_unlock the dev->npinfo gets assigned. So we unlock the
dev->npinfo->poll_lock without ever locking it.
Here's the port from the latest git to solve this. I've CCed the netdev,
since I'm not sure I got all the places for rcu_lock for the netpoll. At
least to solve this problem. I did boot up the kernel and this patch
did fix my bugs that I was getting using netconsole. (I have one more
patch to send to fix the illegal API messages).
-- Steve
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Index: linux_realtime_ernie/include/linux/netpoll.h
===================================================================
--- linux_realtime_ernie/include/linux/netpoll.h (revision 296)
+++ linux_realtime_ernie/include/linux/netpoll.h (working copy)
@@ -60,25 +60,31 @@
return ret;
}
-static inline void netpoll_poll_lock(struct net_device *dev)
+static inline void *netpoll_poll_lock(struct net_device *dev)
{
+ rcu_read_lock();
if (dev->npinfo) {
spin_lock(&dev->npinfo->poll_lock);
dev->npinfo->poll_owner = smp_processor_id();
+ return dev->npinfo;
}
+ return NULL;
}
-static inline void netpoll_poll_unlock(struct net_device *dev)
+static inline void netpoll_poll_unlock(void *have)
{
- if (dev->npinfo) {
- dev->npinfo->poll_owner = -1;
- spin_unlock(&dev->npinfo->poll_lock);
+ struct netpoll_info *npi = have;
+
+ if (npi) {
+ npi->poll_owner = -1;
+ spin_unlock(&npi->poll_lock);
}
+ rcu_read_unlock();
}
#else
#define netpoll_rx(a) 0
-#define netpoll_poll_lock(a)
+#define netpoll_poll_lock(a) 0
#define netpoll_poll_unlock(a)
#endif
Index: linux_realtime_ernie/net/core/netpoll.c
===================================================================
--- linux_realtime_ernie/net/core/netpoll.c (revision 296)
+++ linux_realtime_ernie/net/core/netpoll.c (working copy)
@@ -726,6 +726,9 @@
/* last thing to do is link it to the net device structure */
ndev->npinfo = npinfo;
+ /* avoid racing with NAPI reading npinfo */
+ synchronize_rcu();
+
return 0;
release:
Index: linux_realtime_ernie/net/core/dev.c
===================================================================
--- linux_realtime_ernie/net/core/dev.c (revision 296)
+++ linux_realtime_ernie/net/core/dev.c (working copy)
@@ -1723,6 +1723,7 @@
while (!list_empty(&queue->poll_list)) {
struct net_device *dev;
+ void *have;
if (budget <= 0 || jiffies - start_time > 1)
goto softnet_break;
@@ -1735,10 +1736,10 @@
dev = list_entry(queue->poll_list.next,
struct net_device, poll_list);
- netpoll_poll_lock(dev);
+ have = netpoll_poll_lock(dev);
if (dev->quota <= 0 || dev->poll(dev, &budget)) {
- netpoll_poll_unlock(dev);
+ netpoll_poll_unlock(have);
raw_local_irq_disable();
list_del(&dev->poll_list);
list_add_tail(&dev->poll_list, &queue->poll_list);
@@ -1747,7 +1748,7 @@
else
dev->quota = dev->weight;
} else {
- netpoll_poll_unlock(dev);
+ netpoll_poll_unlock(have);
dev_put(dev);
raw_local_irq_disable();
}
^ permalink raw reply
* Re: 2.6.13-rc6-rt6
From: Paul E. McKenney @ 2005-08-19 22:47 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Ingo Molnar, netdev, linux-kernel
In-Reply-To: <1124486548.18408.18.camel@localhost.localdomain>
On Fri, Aug 19, 2005 at 05:22:28PM -0400, Steven Rostedt wrote:
> On Wed, 2005-08-17 at 18:23 +0200, Ingo Molnar wrote:
>
> >
> > > And it goes on and on. This happens everytime. Without netconsole, I
> > > only get the nonzero lock count error. Also, one of my lockups on SMP
> > > had to do with the kernel_thread_helper:
> > >
> > > Using IPI Shortcut mode
> > > khelper/794[CPU#0]: BUG in set_new_owner at kernel/rt.c:916
>
> This was with netconsole and showed up after a bunch of other bugs. So
> this is a side effect of what happened earlier.
> >
> > this is a 'must not happen'. Somehow lock->held list got non-empty.
> > Maybe some use-after-free thing? Havent seen it myself.
>
> I started debugging netconsole with the RT patch and found this
> happening. After seeing what's wrong, I looked at the latest git
> branch, and it seems to already have a similar solution that I was going
> to make. Here's a description of what's wrong.
>
> In net/core/dev.c the following code is in net_rx_action:
>
> netpoll_poll_lock(dev);
>
> if (dev->quota <= 0 || dev->poll(dev, &budget)) {
> netpoll_poll_unlock(dev);
> raw_local_irq_disable();
> list_del(&dev->poll_list);
> list_add_tail(&dev->poll_list, &queue->poll_list);
> if (dev->quota < 0)
> dev->quota += dev->weight;
> else
> dev->quota = dev->weight;
> } else {
> netpoll_poll_unlock(dev);
>
> The netpoll_poll_lock and netpoll_poll_unlock look like this (in current RT):
>
> static inline netpoll_poll_lock(struct net_device *dev)
> {
> if (dev->npinfo) {
> spin_lock(&dev->npinfo->poll_lock);
> dev->npinfo->poll_owner = smp_processor_id();
> }
> }
>
> static inline void netpoll_poll_unlock(struct net_device *dev)
> {
> if (dev->npinfo) {
> dev->npinfo->poll_owner = -1;
> spin_unlock(&dev->npinfo->poll_lock);
> }
> }
>
>
> The problem here is that between netpoll_poll_lock and
> netpoll_poll_unlock the dev->npinfo gets assigned. So we unlock the
> dev->npinfo->poll_lock without ever locking it.
>
> Here's the port from the latest git to solve this. I've CCed the netdev,
> since I'm not sure I got all the places for rcu_lock for the netpoll. At
> least to solve this problem. I did boot up the kernel and this patch
> did fix my bugs that I was getting using netconsole. (I have one more
> patch to send to fix the illegal API messages).
>
> -- Steve
>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>
> Index: linux_realtime_ernie/include/linux/netpoll.h
> ===================================================================
> --- linux_realtime_ernie/include/linux/netpoll.h (revision 296)
> +++ linux_realtime_ernie/include/linux/netpoll.h (working copy)
> @@ -60,25 +60,31 @@
> return ret;
> }
Good catch -- but a few changes needed to be perfectly safe:
static inline void *netpoll_poll_lock(struct net_device *dev)
{
struct netpoll_info *npi;
rcu_read_lock();
npi = rcu_dereference(dev)->npinfo;
if (have) {
spin_lock(&npi->poll_lock);
npi->poll_owner = smp_processor_id();
return npi;
}
return NULL;
}
The earlier version could get in trouble if dev->npinfo was set
to NULL while this was executing.
I am assuming that the dev pointer is really what is being RCU-protected,
but this example uses mostly static data structures, so it is hard
for me to tell. The npinfo pointer is not being RCU protected, as it
appears to never be changed. The other candidate is the rx_np pointer,
which is set to NULL in netpoll_cleanup. I suggest a modification
to netpoll_cleanup below that handles both possibilities. Of course,
I might well be missing something...
> -static inline void netpoll_poll_unlock(struct net_device *dev)
> +static inline void netpoll_poll_unlock(void *have)
> {
> - if (dev->npinfo) {
> - dev->npinfo->poll_owner = -1;
> - spin_unlock(&dev->npinfo->poll_lock);
> + struct netpoll_info *npi = have;
> +
> + if (npi) {
> + npi->poll_owner = -1;
> + spin_unlock(&npi->poll_lock);
> }
> + rcu_read_unlock();
> }
>
> #else
> #define netpoll_rx(a) 0
> -#define netpoll_poll_lock(a)
> +#define netpoll_poll_lock(a) 0
> #define netpoll_poll_unlock(a)
> #endif
>
> Index: linux_realtime_ernie/net/core/netpoll.c
> ===================================================================
> --- linux_realtime_ernie/net/core/netpoll.c (revision 296)
> +++ linux_realtime_ernie/net/core/netpoll.c (working copy)
If netpoll_setup() is implicitly tearing down an earlier netpoll_setup(),
then something like Steve's change below might be needed.
> @@ -726,6 +726,9 @@
> /* last thing to do is link it to the net device structure */
> ndev->npinfo = npinfo;
>
> + /* avoid racing with NAPI reading npinfo */
> + synchronize_rcu();
> +
> return 0;
>
> release:
Assuming that it is legal to block in netpoll_cleanup(), the following
should work. The idea is to NULL the dev pointer, wait for all RCU
readers to get done, and only then complete the cleanup.
void netpoll_cleanup(struct netpoll *np)
{
struct netpoll_info *npinfo;
unsigned long flags;
struct net_device *dp;
if (np->dev) {
dp = np->dev;
rcu_assign_pointer(np->dev, NULL);
synchronize_rcu();
npinfo = dp->npinfo;
if (npinfo && npinfo->rx_np == np) {
spin_lock_irqsave(&npinfo->rx_lock, flags);
npinfo->rx_np = NULL;
npinfo->rx_flags &= ~NETPOLL_RX_ENABLED;
spin_unlock_irqrestore(&npinfo->rx_lock, flags);
}
dev_put(dp);
}
}
Again, I do not fully understand this code, so a grain of salt might
come in handy. But there definitely need to be some rcu_dereference()
and rcu_assign_pointer() primitives in there somewhere. ;-)
The following changes look good to me, but, as I said earlier, I do
not claim to fully understand this code.
> Index: linux_realtime_ernie/net/core/dev.c
> ===================================================================
> --- linux_realtime_ernie/net/core/dev.c (revision 296)
> +++ linux_realtime_ernie/net/core/dev.c (working copy)
> @@ -1723,6 +1723,7 @@
>
> while (!list_empty(&queue->poll_list)) {
> struct net_device *dev;
> + void *have;
>
> if (budget <= 0 || jiffies - start_time > 1)
> goto softnet_break;
> @@ -1735,10 +1736,10 @@
>
> dev = list_entry(queue->poll_list.next,
> struct net_device, poll_list);
> - netpoll_poll_lock(dev);
> + have = netpoll_poll_lock(dev);
>
> if (dev->quota <= 0 || dev->poll(dev, &budget)) {
> - netpoll_poll_unlock(dev);
> + netpoll_poll_unlock(have);
> raw_local_irq_disable();
> list_del(&dev->poll_list);
> list_add_tail(&dev->poll_list, &queue->poll_list);
> @@ -1747,7 +1748,7 @@
> else
> dev->quota = dev->weight;
> } else {
> - netpoll_poll_unlock(dev);
> + netpoll_poll_unlock(have);
> dev_put(dev);
> raw_local_irq_disable();
> }
Thanx, Paul
^ permalink raw reply
* Re: 2.6.13-rc6-rt6
From: Steven Rostedt @ 2005-08-19 23:02 UTC (permalink / raw)
To: paulmck; +Cc: Ingo Molnar, netdev, linux-kernel
In-Reply-To: <20050819224758.GJ1298@us.ibm.com>
On Fri, 2005-08-19 at 15:47 -0700, Paul E. McKenney wrote:
> Good catch -- but a few changes needed to be perfectly safe:
>
> static inline void *netpoll_poll_lock(struct net_device *dev)
> {
>
> struct netpoll_info *npi;
>
> rcu_read_lock();
> npi = rcu_dereference(dev)->npinfo;
> if (have) {
Here I'm sure you mean "if (npi) {" :-)
> spin_lock(&npi->poll_lock);
> npi->poll_owner = smp_processor_id();
> return npi;
> }
> return NULL;
> }
>
> The earlier version could get in trouble if dev->npinfo was set
> to NULL while this was executing.
Truth be told, I was just fixing the race with getting the npinfo
pointer set between netpoll_poll_lock and netpoll_poll_unlock. I wrote
a patch that fixed that but nothing with the rcu_locks. Then I looked
at the current git tree and saw that they already had my changes, but
also included the rcu locks. So I just (blindly) added them.
>
> Again, I do not fully understand this code, so a grain of salt might
> come in handy. But there definitely need to be some rcu_dereference()
> and rcu_assign_pointer() primitives in there somewhere. ;-)
>
> The following changes look good to me, but, as I said earlier, I do
> not claim to fully understand this code.
netpoll has changed quite a bit in the last few releases. I've seen lots
of fixup code sent in (which usually means there's lots of new broken
code ;-)
Anyway, I don't quite fully understand RCU. I read a few of the
documents on your web site, but I haven't had time to really digest it.
Have you taken a look at the latest git tree? The rcu_locks are used
for net poll quite a bit more there.
-- Steve
^ permalink raw reply
* Re: 2.6.13-rc6-rt6
From: Paul E. McKenney @ 2005-08-19 23:12 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Ingo Molnar, netdev, linux-kernel
In-Reply-To: <1124492562.18408.35.camel@localhost.localdomain>
On Fri, Aug 19, 2005 at 07:02:42PM -0400, Steven Rostedt wrote:
> On Fri, 2005-08-19 at 15:47 -0700, Paul E. McKenney wrote:
>
> > Good catch -- but a few changes needed to be perfectly safe:
> >
> > static inline void *netpoll_poll_lock(struct net_device *dev)
> > {
> >
> > struct netpoll_info *npi;
> >
> > rcu_read_lock();
> > npi = rcu_dereference(dev)->npinfo;
> > if (have) {
>
> Here I'm sure you mean "if (npi) {" :-)
Right you are! ;-)
> > spin_lock(&npi->poll_lock);
> > npi->poll_owner = smp_processor_id();
> > return npi;
> > }
> > return NULL;
> > }
> >
> > The earlier version could get in trouble if dev->npinfo was set
> > to NULL while this was executing.
>
> Truth be told, I was just fixing the race with getting the npinfo
> pointer set between netpoll_poll_lock and netpoll_poll_unlock. I wrote
> a patch that fixed that but nothing with the rcu_locks. Then I looked
> at the current git tree and saw that they already had my changes, but
> also included the rcu locks. So I just (blindly) added them.
Understood!
> > Again, I do not fully understand this code, so a grain of salt might
> > come in handy. But there definitely need to be some rcu_dereference()
> > and rcu_assign_pointer() primitives in there somewhere. ;-)
> >
> > The following changes look good to me, but, as I said earlier, I do
> > not claim to fully understand this code.
>
> netpoll has changed quite a bit in the last few releases. I've seen lots
> of fixup code sent in (which usually means there's lots of new broken
> code ;-)
>
> Anyway, I don't quite fully understand RCU. I read a few of the
> documents on your web site, but I haven't had time to really digest it.
> Have you taken a look at the latest git tree? The rcu_locks are used
> for net poll quite a bit more there.
Hmmm.... Guess it is time for me to stop procrastinating on better
understanding git...
Thanx, Paul
^ permalink raw reply
* Re: 2.6.13-rc6-rt6
From: Steven Rostedt @ 2005-08-19 23:20 UTC (permalink / raw)
To: paulmck; +Cc: Ingo Molnar, netdev, linux-kernel
In-Reply-To: <20050819231223.GN1298@us.ibm.com>
On Fri, 2005-08-19 at 16:12 -0700, Paul E. McKenney wrote:
>
> Hmmm.... Guess it is time for me to stop procrastinating on better
> understanding git...
Why? I still don't. Just go to http://www.kernel.org/ and download the
latest git release (as of now it's -git11).
Of course you need to know the special combination :-)
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.12.tar.bz2
http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.13-rc6.bz2
http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.13-rc6-git11.bz2
-- Steve
^ permalink raw reply
* Re: 2.6.13-rc6-rt6
From: Paul E. McKenney @ 2005-08-19 23:44 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Ingo Molnar, netdev, linux-kernel
In-Reply-To: <1124493620.18408.40.camel@localhost.localdomain>
On Fri, Aug 19, 2005 at 07:20:20PM -0400, Steven Rostedt wrote:
> On Fri, 2005-08-19 at 16:12 -0700, Paul E. McKenney wrote:
> >
> > Hmmm.... Guess it is time for me to stop procrastinating on better
> > understanding git...
>
> Why? I still don't. Just go to http://www.kernel.org/ and download the
> latest git release (as of now it's -git11).
>
> Of course you need to know the special combination :-)
>
> http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.12.tar.bz2
> http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.13-rc6.bz2
> http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.13-rc6-git11.bz2
I feel very much enlightened! ;-)
Thank you very much!!!
Thanx, Paul
^ permalink raw reply
* 2.6.13-rc6-mm1: why is PHYLIB a user-visible option?
From: Adrian Bunk @ 2005-08-20 0:20 UTC (permalink / raw)
To: Andrew Morton, jgarzik; +Cc: linux-kernel, netdev
In-Reply-To: <20050819043331.7bc1f9a9.akpm@osdl.org>
Is there any reason why PHYLIB is a user-visible option?
As far as I understand it, PHYLIB and the MII PHY device drivers are an
internal library drivers should start to use roughly similar to MII.
But in this case, the options shouldn't be user-visible.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: 2.6.13-rc6-mm1: why is PHYLIB a user-visible option?
From: Jeff Garzik @ 2005-08-20 0:29 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, linux-kernel, netdev
In-Reply-To: <20050820002027.GJ3615@stusta.de>
Adrian Bunk wrote:
> Is there any reason why PHYLIB is a user-visible option?
>
> As far as I understand it, PHYLIB and the MII PHY device drivers are an
> internal library drivers should start to use roughly similar to MII.
>
> But in this case, the options shouldn't be user-visible.
This code is still shaking out, so don't worry much about it right now.
Jeff
^ permalink raw reply
* Re: [PATCH 2.6.13-rc6] S2io: Hardware fixes for Xframe II adapter
From: Jeff Garzik @ 2005-08-20 1:42 UTC (permalink / raw)
To: ravinandan.arakali
Cc: netdev, raghavendra.koushik, leonid.grossman, rapuru.sriram,
ananda.raju
In-Reply-To: <20050812171559.F0C03983D0@linux.site>
applied
^ permalink raw reply
* Re: [E1000-devel] Page Allocation Failure with e1000 using jumbo frame
From: Michael Iatrou @ 2005-08-20 1:43 UTC (permalink / raw)
To: e1000-devel; +Cc: Jesse Brandeburg, Ming Zhang, iet-dev, netdev
In-Reply-To: <Pine.WNT.4.63.0508190940210.3796@jbrandeb-desk.amr.corp.intel.com>
When the date was Friday 19 August 2005 19:51, Jesse Brandeburg wrote:
> included netdev...
>
> On Wed, 17 Aug 2005, Ming Zhang wrote:
> > Hi folks
> >
> > We ran into this problem when running jumbo frame with iscsi over e1000.
> > the MTU1500 is fine while jumbo frame can stably reproduce this error.
> >
> > when meet this error, as reported in iet list, the box still has >600MB
> > ram free. also the slab is not heavily used.
> >
> > any idea on this?
>
> So, what we do know is that your kernel memory manager is (for whatever
> unknown reason) having trouble finding contiguous 2^3 pages (32kB) chunks
> of memory. This occurs because we need to give our hardware 16kB
> contiguous (currently, we actually have a patch for this in internal
> testing) which means that when we do dev_alloc_skb, it allocates 16kB + 16
> bytes reserve, plus 2 bytes NET_IP_ALIGN, which takes us into the 32kB
> slab (power of two roundup)
I don't get it: For MTU = 9000, you already have to allocate 2^3 pages, but
testing shows that the problem only occurs for MTU > 3*PAGE_SIZE
http://members.hellug.gr/iatrou/plain_ip_mtu.png
(reference to previous discussion)
http://sourceforge.net/mailarchive/forum.php?forum_id=12401&max_rows=25&style=ultimate&viewmonth=200505
--
Michael Iatrou
Electrical and Computer Engineering Dept.
University of Patras, Greece
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: Page Allocation Failure with e1000 using jumboframe
From: Michael Iatrou @ 2005-08-20 1:46 UTC (permalink / raw)
To: e1000-devel; +Cc: Jesse Brandeburg, Ming Zhang, iet-dev, netdev
In-Reply-To: <Pine.WNT.4.63.0508191023130.3796@jbrandeb-desk.amr.corp.intel.com>
When the date was Friday 19 August 2005 20:33, Jesse Brandeburg wrote:
> PS we have a driver in test that won't do the large contig allocations any
> more.
In fact, I tested a version of these drivers about 3 months ago and not only
they didn't solve the problem, but the throughput decreased!
Is there a newer version? I would gladly test it...
(previous report)
http://sourceforge.net/mailarchive/forum.php?thread_id=7237829&forum_id=12401
--
Michael Iatrou
Electrical and Computer Engineering Dept.
University of Patras, Greece
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply
* Re: [patch] net/tulip: LAN driver for ULI M5261/M5263
From: Jeff Garzik @ 2005-08-20 5:12 UTC (permalink / raw)
To: Peer.Chen
Cc: Alexey Dobriyan, Alan Cox, Clear.Zhang, netdev, linux-kernel,
Emily.Jiang
In-Reply-To: <OF308CFA6C.C728268D-ON4825705F.00365A7A@uli.com.tw>
Peer.Chen@uli.com.tw wrote:
> Jeff:
> The attached file is the incremental patch to the original uli526x.c I send
> you first time,
> I modify the source according to your advice, thanks.
>
> Signed-off-by: Peer Chen <Peer.Chen@uli.com.tw>
> (See attached file: patch_uli526x_inc)
Patch applied, thanks much.
I notice you removed the following code, rather than fixing it. It is
OK to remove this code??
- //add by clearzhang 2004/7/8
- pci_read_config_dword(pdev,0x0,&configval);
- m526x_id = configval;
- if(configval == 0x526310b9)
- {
- //printk("is m5263\n");
- pci_read_config_dword(pdev,0x0c,&configval);
- configval = ((configval & 0xffff00ff) | 0x8000);
- pci_write_config_dword(pdev,0x0c,configval);
- }
Thanks,
Jeff
^ permalink raw reply
* [-mm patch] net/core/sysctl_net_core.c: fix PROC_FS=n compile
From: Adrian Bunk @ 2005-08-20 19:03 UTC (permalink / raw)
To: Andrew Morton, davem; +Cc: linux-kernel, netdev
In-Reply-To: <20050819043331.7bc1f9a9.akpm@osdl.org>
On Fri, Aug 19, 2005 at 04:33:31AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.13-rc5-mm1:
>...
> git-net.patch
>...
> Subsystem trees
>...
This breaks the compilation with CONFIG_PROC_FS=n:
<-- snip -->
...
CC net/core/sysctl_net_core.o
net/core/sysctl_net_core.c:50: error: 'sysctl_wmem_default' undeclared here (not in a function)
net/core/sysctl_net_core.c:58: error: 'sysctl_rmem_default' undeclared here (not in a function)
make[2]: *** [net/core/sysctl_net_core.o] Error 1
<-- snip -->
The fix is simple.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.13-rc6-mm1-full/include/net/sock.h.old 2005-08-20 15:39:23.000000000 +0200
+++ linux-2.6.13-rc6-mm1-full/include/net/sock.h 2005-08-20 15:39:39.000000000 +0200
@@ -1372,9 +1372,7 @@
extern int sysctl_optmem_max;
#endif
-#ifdef CONFIG_PROC_FS
extern __u32 sysctl_wmem_default;
extern __u32 sysctl_rmem_default;
-#endif
#endif /* _SOCK_H */
^ 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