* Re: [PATCH] bridge: add per bridge device controls for invoking iptables
From: Stephen Hemminger @ 2010-06-30 21:24 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <1277729220-11775-1-git-send-email-kaber@trash.net>
On Mon, 28 Jun 2010 14:47:00 +0200
kaber@trash.net wrote:
> From: Patrick McHardy <kaber@trash.net>
>
> Support more fine grained control of bridge netfilter iptables invocation
> by adding seperate brnf_call_*tables parameters for each device using the
> sysfs interface. Packets are passed to layer 3 netfilter when either the
> global parameter or the per bridge parameter is enabled.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Looks like a good idea.
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
--
^ permalink raw reply
* Re: [PATCH] bridge: add per bridge device controls for invoking iptables
From: David Miller @ 2010-06-30 21:27 UTC (permalink / raw)
To: shemminger; +Cc: kaber, netdev
In-Reply-To: <20100630142440.68adfdb1@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 30 Jun 2010 14:24:40 -0700
> On Mon, 28 Jun 2010 14:47:00 +0200
> kaber@trash.net wrote:
>
>> From: Patrick McHardy <kaber@trash.net>
>>
>> Support more fine grained control of bridge netfilter iptables invocation
>> by adding seperate brnf_call_*tables parameters for each device using the
>> sysfs interface. Packets are passed to layer 3 netfilter when either the
>> global parameter or the per bridge parameter is enabled.
>>
>> Signed-off-by: Patrick McHardy <kaber@trash.net>
>
> Looks like a good idea.
>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: David S. Miller <davem@davemloft.net>
Patrick since this is mostly netfilter'ish, please toss it into one
of your trees.
Thanks!
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ixgbe: add 1g PHY support for 82599
From: David Miller @ 2010-06-30 21:27 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, donald.c.skidmore
In-Reply-To: <20100630043017.8987.49958.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:30:59 -0700
> From: Don Skidmore <donald.c.skidmore@intel.com>
>
> Add support for 1G SFP+ PHY's to 82599.
>
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] x86: Align skb w/ start of cacheline on newer core 2/Xeon Arch
From: David Miller @ 2010-06-30 21:28 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, bphilips, tglx, mingo, hpa, x86, alexander.h.duyck
In-Reply-To: <20100630043728.9224.64191.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:38:00 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> x86 architectures can handle unaligned accesses in hardware, and it has
> been shown that unaligned DMA accesses can be expensive on Nehalem
> architectures. As such we should overwrite NET_IP_ALIGN to resolve
> this issue.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Can I get an x86'er ACK on this? I can merge it in via net-next-2.6
which is probably most convenient for people who want to see the
networking performance effects of this change.
^ permalink raw reply
* Re: [PATCHv2] vhost-net: add dhclient work-around from userspace
From: David Miller @ 2010-06-30 21:30 UTC (permalink / raw)
To: mst
Cc: arozansk, herbert.xu, quintela, kvm, virtualization, netdev,
linux-kernel, ykaul, markmc
In-Reply-To: <20100629130439.GD3603@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Tue, 29 Jun 2010 16:04:39 +0300
> Since using the module involves updating the management tools
> as well, if we go down this route it will be much less painful
> for everyone to do push it upstream.
Ok, you can make your case to Patrick McHardy and if he'll merge
it into his netfilter GIT tree I guess I'll have to take it :)
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] x86: Align skb w/ start of cacheline on newer core 2/Xeon Arch
From: H. Peter Anvin @ 2010-06-30 21:32 UTC (permalink / raw)
To: David Miller
Cc: jeffrey.t.kirsher, netdev, gospo, bphilips, tglx, mingo, x86,
alexander.h.duyck
In-Reply-To: <20100630.142832.51275605.davem@davemloft.net>
On 06/30/2010 02:28 PM, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Tue, 29 Jun 2010 21:38:00 -0700
>
>> From: Alexander Duyck <alexander.h.duyck@intel.com>
>>
>> x86 architectures can handle unaligned accesses in hardware, and it has
>> been shown that unaligned DMA accesses can be expensive on Nehalem
>> architectures. As such we should overwrite NET_IP_ALIGN to resolve
>> this issue.
>>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> Cc: x86@kernel.org
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Can I get an x86'er ACK on this? I can merge it in via net-next-2.6
> which is probably most convenient for people who want to see the
> networking performance effects of this change.
Acked-by: H. Peter Anvin <hpa@zytor.com>
-hpa
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] x86: Align skb w/ start of cacheline on newer core 2/Xeon Arch
From: David Miller @ 2010-06-30 21:34 UTC (permalink / raw)
To: hpa
Cc: jeffrey.t.kirsher, netdev, gospo, bphilips, tglx, mingo, x86,
alexander.h.duyck
In-Reply-To: <4C2BB7F1.6050009@zytor.com>
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Wed, 30 Jun 2010 14:32:33 -0700
> On 06/30/2010 02:28 PM, David Miller wrote:
>> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> Date: Tue, 29 Jun 2010 21:38:00 -0700
>>
>>> From: Alexander Duyck <alexander.h.duyck@intel.com>
>>>
>>> x86 architectures can handle unaligned accesses in hardware, and it has
>>> been shown that unaligned DMA accesses can be expensive on Nehalem
>>> architectures. As such we should overwrite NET_IP_ALIGN to resolve
>>> this issue.
>>>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Ingo Molnar <mingo@redhat.com>
>>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>>> Cc: x86@kernel.org
>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>
>> Can I get an x86'er ACK on this? I can merge it in via net-next-2.6
>> which is probably most convenient for people who want to see the
>> networking performance effects of this change.
>
> Acked-by: H. Peter Anvin <hpa@zytor.com>
Applied, thanks everyone.
^ permalink raw reply
* [PATCH 1/1] ehea: Allocate stats buffer with GFP_KERNEL
From: Brian King @ 2010-06-30 21:59 UTC (permalink / raw)
To: ossthema; +Cc: osstklei, raisch, netdev, brking
Since ehea_get_stats calls ehea_h_query_ehea_port, which
can sleep, we can also sleep when allocating a page in
this function. This fixes some memory allocation failure
warnings seen under low memory conditions.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
drivers/net/ehea/ehea_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/net/ehea/ehea_main.c~ehea_get_stats_gfp drivers/net/ehea/ehea_main.c
--- linux-2.6/drivers/net/ehea/ehea_main.c~ehea_get_stats_gfp 2010-06-28 09:46:51.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ehea/ehea_main.c 2010-06-28 09:46:51.000000000 -0500
@@ -335,7 +335,7 @@ static struct net_device_stats *ehea_get
memset(stats, 0, sizeof(*stats));
- cb2 = (void *)get_zeroed_page(GFP_ATOMIC);
+ cb2 = (void *)get_zeroed_page(GFP_KERNEL);
if (!cb2) {
ehea_error("no mem for cb2");
goto out;
_
^ permalink raw reply
* Re: [PATCHv2] vhost-net: add dhclient work-around from userspace
From: Anthony Liguori @ 2010-06-30 22:08 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Miller, arozansk, herbert.xu, quintela, kvm, virtualization,
netdev, linux-kernel, ykaul, markmc
In-Reply-To: <20100629130439.GD3603@redhat.com>
On 06/29/2010 08:04 AM, Michael S. Tsirkin wrote:
> On Tue, Jun 29, 2010 at 12:36:47AM -0700, David Miller wrote:
>
>> From: "Michael S. Tsirkin"<mst@redhat.com>
>> Date: Mon, 28 Jun 2010 13:08:07 +0300
>>
>>
>>> Userspace virtio server has the following hack
>>> so guests rely on it, and we have to replicate it, too:
>>>
>>> Use port number to detect incoming IPv4 DHCP response packets,
>>> and fill in the checksum for these.
>>>
>>> The issue we are solving is that on linux guests, some apps
>>> that use recvmsg with AF_PACKET sockets, don't know how to
>>> handle CHECKSUM_PARTIAL;
>>> The interface to return the relevant information was added
>>> in 8dc4194474159660d7f37c495e3fc3f10d0db8cc,
>>> and older userspace does not use it.
>>> One important user of recvmsg with AF_PACKET is dhclient,
>>> so we add a work-around just for DHCP.
>>>
>>> Don't bother applying the hack to IPv6 as userspace virtio does not
>>> have a work-around for that - let's hope guests will do the right
>>> thing wrt IPv6.
>>>
>>> Signed-off-by: Michael S. Tsirkin<mst@redhat.com>
>>>
>> Yikes, this is awful too.
>>
>> Nothing in the kernel should be mucking around with procotol packets
>> like this by default. In particular, what the heck does port 67 mean?
>> Locally I can use it for whatever I want for my own purposes, I don't
>> have to follow the conventions for service ports as specified by the
>> IETF.
>>
>> But I can't have the packet checksum state be left alone for port 67
>> traffic on a box using virtio because you have this hack there.
>>
>> And yes it's broken on machines using the qemu thing, but at least the
>> hack there is restricted to userspace.
>>
> Yes, and I think it was a mistake to add the hack there. This is what
> prevented applications from using the new interface in the 3 years
> since it was first introduced.
>
It's far more complicated than that. dhclient is part of ISC's DHCP
package. They do not have a public SCM and instead require you to join
their Software Guild to get access to it.
This problem was identified in one distribution and the patch was pushed
upstream but because they did not have a public SCM, most other
distributions did not see the fix until it appeared in a release. ISC
has a pretty long release cycle historically.
ISC's had the fix for a long time but there was a 3-year gap in their
releases and since their SCM isn't public, users are stuck with the last
release.
This hack makes sense in QEMU as we have a few hacks like this to fix
broken guests. A primary use of virtualization is to run old
applications so it makes sense for us to do that.
I don't think it makes sense for vhost to do this. These guests are so
old that they don't have the requisite features to achieve really high
performance anyway.
I've always thought making vhost totally transparent was a bad idea and
this is one of the reasons. We can do a lot of ugly things in userspace
that we shouldn't be doing in the kernel.
Regards,
Anthony Liguori
^ permalink raw reply
* Re: b44: Reset due to FIFO overflow.
From: James Courtier-Dutton @ 2010-06-30 22:20 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, erblichs, netdev
In-Reply-To: <20100630.132220.129754921.davem@davemloft.net>
On 30 June 2010 21:22, David Miller <davem@davemloft.net> wrote:
> From: James Courtier-Dutton <james.dutton@gmail.com>
> Date: Mon, 28 Jun 2010 11:17:59 +0100
>
>> Interesting, which hardware, apart from the b44, is it that "requires"
>> a hardware reset after a RX FIFO overflow.
>
> This problem is quite common, actually.
>
> Even though it shouldn't be, this is seemingly one of the least tested
> paths of a networking chip.
>
> You'd think the recovery would be easy, flush the fifos and drop the
> packet, then rewind the RX descriptor pointer.
>
> But it's not and I've seen everything from RX descriptor corruption
> to random DMA splats elsewhere corrupting memory entirely, as a result
> of a networking card taking a RX fifo overflow.
>
Well, I have just written a patch (see other thread) to try and reset
the FIFO instead of a complete HW reset.
How do I know if I have RX descriptor corruption, or random DMA splats?
I have not detected any problems so far.
^ permalink raw reply
* Re: [PATCHv2] vhost-net: add dhclient work-around from userspace
From: Michael S. Tsirkin @ 2010-06-30 22:31 UTC (permalink / raw)
To: Anthony Liguori
Cc: David Miller, arozansk, herbert.xu, quintela, kvm, virtualization,
netdev, linux-kernel, ykaul, markmc
In-Reply-To: <4C2BC04B.3000100@codemonkey.ws>
On Wed, Jun 30, 2010 at 05:08:11PM -0500, Anthony Liguori wrote:
> On 06/29/2010 08:04 AM, Michael S. Tsirkin wrote:
> >On Tue, Jun 29, 2010 at 12:36:47AM -0700, David Miller wrote:
> >>From: "Michael S. Tsirkin"<mst@redhat.com>
> >>Date: Mon, 28 Jun 2010 13:08:07 +0300
> >>
> >>>Userspace virtio server has the following hack
> >>>so guests rely on it, and we have to replicate it, too:
> >>>
> >>>Use port number to detect incoming IPv4 DHCP response packets,
> >>>and fill in the checksum for these.
> >>>
> >>>The issue we are solving is that on linux guests, some apps
> >>>that use recvmsg with AF_PACKET sockets, don't know how to
> >>>handle CHECKSUM_PARTIAL;
> >>>The interface to return the relevant information was added
> >>>in 8dc4194474159660d7f37c495e3fc3f10d0db8cc,
> >>>and older userspace does not use it.
> >>>One important user of recvmsg with AF_PACKET is dhclient,
> >>>so we add a work-around just for DHCP.
> >>>
> >>>Don't bother applying the hack to IPv6 as userspace virtio does not
> >>>have a work-around for that - let's hope guests will do the right
> >>>thing wrt IPv6.
> >>>
> >>>Signed-off-by: Michael S. Tsirkin<mst@redhat.com>
> >>Yikes, this is awful too.
> >>
> >>Nothing in the kernel should be mucking around with procotol packets
> >>like this by default. In particular, what the heck does port 67 mean?
> >>Locally I can use it for whatever I want for my own purposes, I don't
> >>have to follow the conventions for service ports as specified by the
> >>IETF.
> >>
> >>But I can't have the packet checksum state be left alone for port 67
> >>traffic on a box using virtio because you have this hack there.
> >>
> >>And yes it's broken on machines using the qemu thing, but at least the
> >>hack there is restricted to userspace.
> >Yes, and I think it was a mistake to add the hack there. This is what
> >prevented applications from using the new interface in the 3 years
> >since it was first introduced.
>
> It's far more complicated than that. dhclient is part of ISC's DHCP
> package. They do not have a public SCM and instead require you to
> join their Software Guild to get access to it.
>
> This problem was identified in one distribution and the patch was
> pushed upstream but because they did not have a public SCM, most
> other distributions did not see the fix until it appeared in a
> release. ISC has a pretty long release cycle historically.
>
> ISC's had the fix for a long time but there was a 3-year gap in
> their releases and since their SCM isn't public, users are stuck
> with the last release.
>
> This hack makes sense in QEMU as we have a few hacks like this to
> fix broken guests.
> A primary use of virtualization is to run old
> applications so it makes sense for us to do that.
IMO it was wrong to put it in qemu: originally, if a distro shipped
a broken virtio/dhclient combo, it was it's own bug to fix.
But now that qemu has shipped the work-around for so long,
broken guests seemed work. So we *still* see the bug re-surface in new guests.
And since they are fairly new, it is interesting to
get decent performance from them now.
>
> I don't think it makes sense for vhost to do this. These guests are
> so old that they don't have the requisite features to achieve really
> high performance anyway.
>
> I've always thought making vhost totally transparent was a bad idea
> and this is one of the reasons.
It does not have to be fully transparent. You can insert your own ring
in the middle, and copy descriptors around. And we stop on errors and
let userspace handle. This will come handy if we get e.g. virtio bug
that we need to work around.
> We can do a lot of ugly things in
> userspace that we shouldn't be doing in the kernel.
>
> Regards,
>
> Anthony Liguori
QEMU is only userspace for the host. It is the hardware for the guest.
So IMO we should not be doing the ugly things there either.
--
MST
^ permalink raw reply
* RE: [net-next-2.6 PATCH 1/8] e1000e: cleanup ethtool loopback setup code
From: Allan, Bruce W @ 2010-06-30 22:41 UTC (permalink / raw)
To: David Miller, Kirsher, Jeffrey T; +Cc: netdev@vger.kernel.org
In-Reply-To: <20100618.221512.102550313.davem@davemloft.net>
On Friday, June 18, 2010 10:15 PM, David Miller wrote:
> I've applied this series however:
>
> 1) Please address Ben's concerns about turning EEE on by default
> given that standardization is not complete yet.
>
> 2) I hate module parameters, I'd rather you create a new ethtool
> feature bit and thus allow the setting to be modified at run
> time. Please create a new ethtool control flag, and remove
> this module option.
>
> Thanks.
Hi Dave,
I've been looking into your request number 2 above (as a reminder, it had to do with a patch I submitted that added a module parameter to e1000e in order to enable/disable Energy Efficient Ethernet for a particular type of adapter).
For this new ethtool feature bit/flag for EEE, would you prefer it be set via:
1) the generic parameter setting option (e.g. -s ethX [eee on|off]),
2) yet another new show/change option pair, or
3) a new option that can set this new feature and be expandable to future features that are likewise not related to existing ethtool options (e.g. -F [eee on|off] [whizbang on|off])?
For #2 or #3, it makes sense to use ethtool_op_[g|s]et_flags with new ETH_FLAG_<feature> and NETIF_F_<feature> defines, but #1 can be implemented that way or by using remaining reserved elements of struct ethtool_cmd - if your preference is for #1, would you prefer it be implemented with the former or latter?
Thanks,
Bruce.
^ permalink raw reply
* RE: [REGRESSION] e1000e stopped working
From: Maxim Levitsky @ 2010-06-30 22:59 UTC (permalink / raw)
To: Tantilov, Emil S
Cc: netdev@vger.kernel.org, Allan, Bruce W, Pieper, Jeffrey E
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FF4705C9D@rrsmsx501.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3835 bytes --]
On Tue, 2010-06-29 at 12:37 -0600, Tantilov, Emil S wrote:
> Maxim Levitsky wrote:
> > On Mon, 2010-06-28 at 18:09 -0700, Allan, Bruce W wrote:
> >> On Monday, June 28, 2010 10:14 AM, Maxim Levitsky wrote:
> >>> On Mon, 2010-06-28 at 10:04 -0700, Allan, Bruce W wrote:
> >>>> On Sunday, June 27, 2010 10:47 AM, Maxim Levitsky wrote:
> >>>>> On Sun, 2010-06-27 at 20:43 +0300, Maxim Levitsky wrote:
> >>>>>> On Sun, 2010-06-27 at 20:29 +0300, Maxim Levitsky wrote:
> >>>>>>> On Sun, 2010-06-27 at 20:27 +0300, Maxim Levitsky wrote:
> >>>>>>>> Just that,
> >>>>>>>>
> >>>>>>>> It doesn't receive anything from my internet router during
> >>>>>>>> DHCP.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 00:19.0 Ethernet controller [0200]: Intel Corporation 82566DC
> >>>>>>>> Gigabit Network Connection [8086:104b] (rev 02) Subsystem:
> >>>>>>>> Intel Corporation Device [8086:0001] Control: I/O+ Mem+
> >>>>>>>> BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
> >>>>>>>> SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B-
> >>>>>>>> ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> >>>>>>>> INTx- Latency: 0 Interrupt: pin A routed to IRQ 47 Region 0:
> >>>>>>>> Memory at 50300000 (32-bit, non-prefetchable) [size=128K]
> >>>>>>>> Region 1: Memory at 50324000 (32-bit, non-prefetchable)
> >>>>>>>> [size=4K] Region 2: I/O ports at 30e0 [size=32]
> >>>>>>>> Capabilities: [c8] Power Management version 2 Flags: PMEClk-
> >>>>>>>> DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> >>>>>>>> Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities:
> >>>>>>>> [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
> >>>>>>>> Enable+ Address: 00000000fee0100c Data: 41c9 Kernel driver
> >>>>>>>> in use: e1000e Kernel modules: e1000e
> >>>>>>>>
> >>>>>>>> I use vanilla tree, commit
> >>>>>>>> bf2937695fe2330bfd8933a2310e7bdd2581dc2e
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Best regards,
> >>>>>>>> Maxim Levitsky
> >>>>>>>>
> >>>>>>>
> >>>>>>> It appears to work now after reboot.
> >>>>>>> Will keep a look for this.
> >>>>>>>
> >>>>>>> Disregard for now.
> >>>>>>
> >>>>>>
> >>>>>> Just s2ram cycle, problem is back.
> >>>>>> Did full reboot (power off then on), same thing card doesn't
> >>>>>> work...
> >>>>>>
> >>>>>
> >>>>> Yep, s2ram sometimes 'fixes', sometimes breaks the card.
> >>>>> Something got broken in device initialization path.
> >>>>>
> >>>>> Best regards,
> >>>>> Maxim Levitsky
> >>>>
> >>>> What distro are you using? If RedHat, since you are using DHCP
> >>>> will you please try putting a "LINKDELAY=10" in the
> >>>> /etc/sysconfig/network-scripts/ifcfg-ethX config file.
> >>>>
> >>> I use ubuntu 9.10
> >>>
> >>>> Is there anything in the system log that might help narrow down the
> >>>> issue?
> >>>
> >>> Nothing, really nothing.
> >>> It seems to detect link, dhcp client sends requests, but doesn't
> >>> recieve a thing (even tried promisc mode - doesn't help)
> >>>
> >>>
> >>>
> >>> Best regards,
> >>> Maxim Levitsky
> >>
> >> Since you say this is a regression, when did this last work for you
> >> without this problem, i.e. which distro, which kernel?
> >
> > I always compile kernel, and last kernel I compiled here was vanilla
> > 2.6.33-rc4.
> > It works just fine.
> >
> > I mostly use my laptop, and therefore didn't update kernel on my
> > desktop for long time.
> >
> > If I find some free time I try to bisect the problem.
>
> Could you provide some additional info about your setup:
> ethtool -e eth0
> ethtool -d eth0
> kernel config (if possible)
>
> What is the model of your system/MB?
Sure,
My motherboard on this system is Intel DG965RY
The bug in about 90% reproducible.
Doing several s2ram cycles, its possible to catch a moment when the
device starts working.
Best regards,
Maxim Levitsky
[-- Attachment #2: eeprom --]
[-- Type: text/plain, Size: 14622 bytes --]
Offset Values
------ ------
0x0000 00 19 d1 ed 88 2a 00 08 ff ff 10 10 ff ff ff ff
0x0010 ff ff ff ff c7 10 01 00 86 80 4b 10 86 80 00 00
0x0020 01 0d 00 00 00 00 05 96 20 50 00 33 00 00 07 8d
0x0030 84 06 41 03 00 00 00 00 00 00 00 00 00 00 00 00
0x0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0060 00 01 00 40 2a 12 07 40 ff ff ff ff ff ff ff ff
0x0070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 1f ff
0x0080 20 61 1f 00 02 0e 12 00 40 2f 1f 00 18 90 1b 00
0x0090 00 00 12 00 a0 2f 1f 00 24 8b 11 00 f0 f8 12 00
0x00a0 00 20 1f 00 b0 10 10 00 00 00 11 00 c0 20 1f 00
0x00b0 9a 24 1d 00 d3 00 1e 00 a0 28 1f 00 ce 04 14 00
0x00c0 60 2f 1f 00 e4 29 10 00 00 00 1f 00 40 01 00 00
0x00d0 20 1f 1f 00 06 16 10 00 14 b8 11 00 2a 01 15 00
0x00e0 67 00 1e 00 40 1f 1f 00 65 00 14 00 2a 00 15 00
0x00f0 2a 00 16 00 60 1f 1f 00 b0 3f 12 00 ff c0 16 00
0x0100 ec 1d 17 00 ef f9 18 00 10 02 19 00 80 18 1f 00
0x0110 03 00 15 00 80 17 1f 00 08 00 16 00 80 17 1f 00
0x0120 08 d0 18 00 80 18 1f 00 18 d9 18 00 60 18 1f 00
0x0130 00 08 1a 00 00 00 1f 00 01 00 19 00 40 13 00 00
0x0140 51 60 1f 00 01 00 11 00 00 00 1f 00 ff ff ff ff
0x0150 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0160 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0170 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0180 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0190 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0200 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0210 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0220 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0230 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0240 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0250 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0260 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0270 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0280 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0290 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0300 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0310 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0320 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0330 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0340 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0350 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0360 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0370 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0380 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0390 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0400 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0410 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0420 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0430 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0440 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0450 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0460 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0470 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0480 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0490 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x04a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x04b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x04c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x04d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x04e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x04f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0500 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0510 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0520 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0530 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0540 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0550 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0560 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0570 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0580 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0590 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0600 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0610 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0620 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0630 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0640 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0650 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0660 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0670 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0680 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0690 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0700 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0710 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0720 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0730 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0740 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0750 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0760 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0770 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0780 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0790 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0800 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0810 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0820 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0830 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0840 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0850 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0860 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0870 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0880 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0890 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0900 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0910 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0920 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0930 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0940 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0950 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0960 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0970 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0980 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0990 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0aa0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ab0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ac0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ad0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ae0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0af0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ba0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0bb0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0bc0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0bd0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0be0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0bf0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ca0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0cb0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0cc0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0cd0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ce0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0cf0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0da0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0db0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0dc0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0dd0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0de0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0df0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ea0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0eb0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ec0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ed0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ee0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ef0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fa0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fb0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fc0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fd0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ff0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[-- Attachment #3: misc --]
[-- Type: text/plain, Size: 1297 bytes --]
maxim@MAIN:~$ sudo ethtool -i eth1
driver: e1000e
version: 1.0.2-k4
firmware-version: 1.1-0
bus-info: 0000:00:19.0
maxim@MAIN:~$ sudo ethtool -g eth1
Ring parameters for eth1:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 256
RX Mini: 0
RX Jumbo: 0
TX: 256
maxim@MAIN:~$ ifconfig
eth1 Link encap:Ethernet HWaddr 00:19:d1:ed:88:2a
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:18 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3411 (3.4 KB) TX bytes:2736 (2.7 KB)
Interrupt:20 Memory:50300000-50320000
Number of RX packets seems to increase
Wireshark doesn't see them
Example:
maxim@MAIN:~$ sudo dhclient eth1
Internet Systems Consortium DHCP Client V3.1.2
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/eth1/00:19:d1:ed:88:2a
Sending on LPF/eth1/00:19:d1:ed:88:2a
Sending on Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 18
[-- Attachment #4: reg_dump --]
[-- Type: audio/x-ape, Size: 2300 bytes --]
[-- Attachment #5: .config.gz --]
[-- Type: application/x-gzip, Size: 16213 bytes --]
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/8] e1000e: cleanup ethtool loopback setup code
From: David Miller @ 2010-06-30 23:06 UTC (permalink / raw)
To: bruce.w.allan; +Cc: jeffrey.t.kirsher, netdev
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A9001591F6130@orsmsx509.amr.corp.intel.com>
From: "Allan, Bruce W" <bruce.w.allan@intel.com>
Date: Wed, 30 Jun 2010 15:41:19 -0700
> I've been looking into your request number 2 above (as a reminder,
> it had to do with a patch I submitted that added a module parameter
> to e1000e in order to enable/disable Energy Efficient Ethernet for a
> particular type of adapter).
>
> For this new ethtool feature bit/flag for EEE, would you prefer it be set via:
> 1) the generic parameter setting option (e.g. -s ethX [eee on|off]),
> 2) yet another new show/change option pair, or
> 3) a new option that can set this new feature and be expandable to future features that are likewise not related to existing ethtool options (e.g. -F [eee on|off] [whizbang on|off])?
>
> For #2 or #3, it makes sense to use ethtool_op_[g|s]et_flags with
> new ETH_FLAG_<feature> and NETIF_F_<feature> defines, but #1 can be
> implemented that way or by using remaining reserved elements of
> struct ethtool_cmd - if your preference is for #1, would you prefer
> it be implemented with the former or latter?
I only have strong feelings about the kernel side, and an ETH_FLAG_* seems
best for this since other devices will have this feature too.
I don't think overloading parts of ethtool_cmd is wise.
^ permalink raw reply
* Re: TCP not triggering a fast retransmit?
From: Mitchell Erblich @ 2010-06-30 23:10 UTC (permalink / raw)
To: David Miller; +Cc: bhutchings, novickivan, netdev, jmatthews, theath, herbert
In-Reply-To: <20100630.142256.77345240.davem@davemloft.net>
On Jun 30, 2010, at 2:22 PM, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Wed, 30 Jun 2010 22:03:49 +0100
>
>> In that packet capture I see TCP payload lengths which are 2, 3 and 4
>> times the usual MSS of 1448 bytes, which implies that GRO or LRO is in
>> use. In RHEL 5.4 the TCP stack does not ACK often enough in this case
>> because it is missing this change:
>>
>> commit ff9b5e0f08cb650d113eef0c654f931c0a7ae730
>> Author: Herbert Xu <herbert@gondor.apana.org.au>
>> Date: Thu Aug 31 15:11:02 2006 -0700
>>
>> [TCP]: Fix rcv mss estimate for LRO
>
> It certainly could be, I'll try make sure this gets rectified,
> thanks!
> --
Guys,
I think you suggesting that:
__tcp_ack_snd_chk() within tcp_input.c needs:
an ABC (Appropriate Byte Counting) Allman type check
where the frame rcv'd computed size is 2x or larger
(and no out of order queue) , then
even if NOT in quickack mode, needs to be ACKed,
with tcp_send_ack()
and if in quickack mode, needs a mss incr seq number of ACKs where
number of ACKs equals the number of the multiple of mss
Note: without incrementing the SEQ between ACKs, it would result in
a DupACK at the other end system,
Correct?
Mitchell Erblich
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv2] vhost-net: add dhclient work-around from userspace
From: Anthony Liguori @ 2010-06-30 23:24 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: markmc, kvm, quintela, herbert.xu, linux-kernel, virtualization,
ykaul, arozansk, netdev, David Miller
In-Reply-To: <20100630223157.GA25537@redhat.com>
On 06/30/2010 05:31 PM, Michael S. Tsirkin wrote:
> On Wed, Jun 30, 2010 at 05:08:11PM -0500, Anthony Liguori wrote:
>
>> On 06/29/2010 08:04 AM, Michael S. Tsirkin wrote:
>>
>>> On Tue, Jun 29, 2010 at 12:36:47AM -0700, David Miller wrote:
>>>
>>>> From: "Michael S. Tsirkin"<mst@redhat.com>
>>>> Date: Mon, 28 Jun 2010 13:08:07 +0300
>>>>
>>>>
>>>>> Userspace virtio server has the following hack
>>>>> so guests rely on it, and we have to replicate it, too:
>>>>>
>>>>> Use port number to detect incoming IPv4 DHCP response packets,
>>>>> and fill in the checksum for these.
>>>>>
>>>>> The issue we are solving is that on linux guests, some apps
>>>>> that use recvmsg with AF_PACKET sockets, don't know how to
>>>>> handle CHECKSUM_PARTIAL;
>>>>> The interface to return the relevant information was added
>>>>> in 8dc4194474159660d7f37c495e3fc3f10d0db8cc,
>>>>> and older userspace does not use it.
>>>>> One important user of recvmsg with AF_PACKET is dhclient,
>>>>> so we add a work-around just for DHCP.
>>>>>
>>>>> Don't bother applying the hack to IPv6 as userspace virtio does not
>>>>> have a work-around for that - let's hope guests will do the right
>>>>> thing wrt IPv6.
>>>>>
>>>>> Signed-off-by: Michael S. Tsirkin<mst@redhat.com>
>>>>>
>>>> Yikes, this is awful too.
>>>>
>>>> Nothing in the kernel should be mucking around with procotol packets
>>>> like this by default. In particular, what the heck does port 67 mean?
>>>> Locally I can use it for whatever I want for my own purposes, I don't
>>>> have to follow the conventions for service ports as specified by the
>>>> IETF.
>>>>
>>>> But I can't have the packet checksum state be left alone for port 67
>>>> traffic on a box using virtio because you have this hack there.
>>>>
>>>> And yes it's broken on machines using the qemu thing, but at least the
>>>> hack there is restricted to userspace.
>>>>
>>> Yes, and I think it was a mistake to add the hack there. This is what
>>> prevented applications from using the new interface in the 3 years
>>> since it was first introduced.
>>>
>> It's far more complicated than that. dhclient is part of ISC's DHCP
>> package. They do not have a public SCM and instead require you to
>> join their Software Guild to get access to it.
>>
>> This problem was identified in one distribution and the patch was
>> pushed upstream but because they did not have a public SCM, most
>> other distributions did not see the fix until it appeared in a
>> release. ISC has a pretty long release cycle historically.
>>
>> ISC's had the fix for a long time but there was a 3-year gap in
>> their releases and since their SCM isn't public, users are stuck
>> with the last release.
>>
>> This hack makes sense in QEMU as we have a few hacks like this to
>> fix broken guests.
>> A primary use of virtualization is to run old
>> applications so it makes sense for us to do that.
>>
> IMO it was wrong to put it in qemu: originally, if a distro shipped
> a broken virtio/dhclient combo, it was it's own bug to fix.
> But now that qemu has shipped the work-around for so long,
> broken guests seemed work.
The guests were broken before qemu implemented this.
virtio-net had checksum offload long before it was ever implemented in
qemu. Not even lguest implemented it because the interfaces weren't
available in tun/tap. I'm not sure how Rusty ever tested it. We only
discovered this bug after checksum offload was implemented in tun/tap
and we were able to enable it in QEMU. At that point, the guests had
shipped and were in the wild.
The real problem was that we implemented a feature in a guest driver
without having a backend implementation and then shipped the code.
Shipping untested code is a recipe for failure.
If we had implemented the front-end feature only when a backend
implementation was available, we would have caught this, fixed it in the
guests, and not be in the situation because there wouldn't be these
broken guests.
> So we *still* see the bug re-surface in new guests.
>
Which guests? Newer versions of dhclient should work as expected.
> And since they are fairly new, it is interesting to
> get decent performance from them now.
>
>
>> I don't think it makes sense for vhost to do this. These guests are
>> so old that they don't have the requisite features to achieve really
>> high performance anyway.
>>
>> I've always thought making vhost totally transparent was a bad idea
>> and this is one of the reasons.
>>
> It does not have to be fully transparent. You can insert your own ring
> in the middle, and copy descriptors around. And we stop on errors and
> let userspace handle. This will come handy if we get e.g. virtio bug
> that we need to work around.
>
I mean from a UI perspective. IOW, if users have to explicitly choose
to use vhost-net, then it's okay to force them to use newer guests that
support vhost-net. However, if we make it transparent, then it has to
support everything that QEMU virtio has ever supported which is
problematic for exactly the reasons you are now encountering.
>> We can do a lot of ugly things in
>> userspace that we shouldn't be doing in the kernel.
>>
>> Regards,
>>
>> Anthony Liguori
>>
> QEMU is only userspace for the host. It is the hardware for the guest.
> So IMO we should not be doing the ugly things there either.
>
Shouldn't we apply the same argument to the Windows RTC implementation
and say that Windows should not rely on counting interrupts? Or that it
shouldn't spin in a tight loop checking interrupt status with interrupts
disabled after receiving an interrupt?
Supporting broken guests is a big part of what we do in QEMU. We do
what we need to do to make guests that we cannot change work. When this
first was implemented, there were a good number of pre-existing guests
that broke because we enabled checksum offload.
If we can fix the guests to avoid doing ugly things in QEMU, we should,
but we can't regress an otherwise working guest just because we think
the solution is ugly in QEMU.
Regards,
Anthony Liguori
^ permalink raw reply
* Re: TCP not triggering a fast retransmit?
From: Ivan Novick @ 2010-07-01 0:27 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, jmatthews, Tim Heath, Herbert Xu
In-Reply-To: <1277931829.4878.9.camel@localhost>
On Wed, Jun 30, 2010 at 2:03 PM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
> On Wed, 2010-06-30 at 11:04 -0700, Ivan Novick wrote:
>> Hello all,
>>
>> Attached is a packet capture from my application that is running on
>> RedHat Enterprise Linux 5.4
>>
>> I am seeing a Retransmission timeout but I was hoping this case would
>> go into fast retransmit and not RTO.
>>
>> I am wondering why did the sender not send more data? If the sender
>> was to send more data and extend the window then it would seem the
>> duplicate acks or SACKS should trigger fast retransmit.
> [...]
>
> In that packet capture I see TCP payload lengths which are 2, 3 and 4
> times the usual MSS of 1448 bytes, which implies that GRO or LRO is in
> use. In RHEL 5.4 the TCP stack does not ACK often enough in this case
> because it is missing this change:
>
> commit ff9b5e0f08cb650d113eef0c654f931c0a7ae730
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Thu Aug 31 15:11:02 2006 -0700
>
> [TCP]: Fix rcv mss estimate for LRO
Wow, Thanks! Is this the patch you are talking about:
http://www.mail-archive.com/netdev@vger.kernel.org/msg21151.html ?
It looks like a one liner. I could apply it and rebuild my RHEL 5.4
to see if it helps.
Cheers,
Ivan Novick
^ permalink raw reply
* Re: TCP not triggering a fast retransmit?
From: Ben Hutchings @ 2010-07-01 1:23 UTC (permalink / raw)
To: Ivan Novick; +Cc: netdev, jmatthews, Tim Heath, Herbert Xu
In-Reply-To: <AANLkTimL7_h4J46-WyUYfXYX87t6tQzIn1YRrvJletWB@mail.gmail.com>
On Wed, 2010-06-30 at 17:27 -0700, Ivan Novick wrote:
> On Wed, Jun 30, 2010 at 2:03 PM, Ben Hutchings
> <bhutchings@solarflare.com> wrote:
> > On Wed, 2010-06-30 at 11:04 -0700, Ivan Novick wrote:
> >> Hello all,
> >>
> >> Attached is a packet capture from my application that is running on
> >> RedHat Enterprise Linux 5.4
> >>
> >> I am seeing a Retransmission timeout but I was hoping this case would
> >> go into fast retransmit and not RTO.
> >>
> >> I am wondering why did the sender not send more data? If the sender
> >> was to send more data and extend the window then it would seem the
> >> duplicate acks or SACKS should trigger fast retransmit.
> > [...]
> >
> > In that packet capture I see TCP payload lengths which are 2, 3 and 4
> > times the usual MSS of 1448 bytes, which implies that GRO or LRO is in
> > use. In RHEL 5.4 the TCP stack does not ACK often enough in this case
> > because it is missing this change:
> >
> > commit ff9b5e0f08cb650d113eef0c654f931c0a7ae730
> > Author: Herbert Xu <herbert@gondor.apana.org.au>
> > Date: Thu Aug 31 15:11:02 2006 -0700
> >
> > [TCP]: Fix rcv mss estimate for LRO
>
> Wow, Thanks! Is this the patch you are talking about:
> http://www.mail-archive.com/netdev@vger.kernel.org/msg21151.html ?
>
> It looks like a one liner. I could apply it and rebuild my RHEL 5.4
> to see if it helps.
Right, that's the same patch.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] nf_conntrack_reasm: add fast path for in-order fragments
From: Changli Gao @ 2010-07-01 3:58 UTC (permalink / raw)
To: Patrick McHardy
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet,
netfilter-devel, netdev, Mitchell Erblich, Changli Gao
nf_conntrack_reasm: add fast path for in-order fragments
As the fragments are sent in order in most of OSes, such as Windows, Darwin and
FreeBSD, it is likely the new fragments are at the end of the inet_frag_queue.
In the fast path, we check if the skb at the end of the inet_frag_queue is the
prev we expect.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/ipv6/netfilter/nf_conntrack_reasm.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
index 9254008..098a050 100644
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -269,6 +269,11 @@ static int nf_ct_frag6_queue(struct nf_ct_frag6_queue *fq, struct sk_buff *skb,
* in the chain of fragments so far. We must know where to put
* this fragment, right?
*/
+ prev = fq->q.fragments_tail;
+ if (!prev || NFCT_FRAG6_CB(prev)->offset < offset) {
+ next = NULL;
+ goto found;
+ }
prev = NULL;
for (next = fq->q.fragments; next != NULL; next = next->next) {
if (NFCT_FRAG6_CB(next)->offset >= offset)
@@ -276,6 +281,7 @@ static int nf_ct_frag6_queue(struct nf_ct_frag6_queue *fq, struct sk_buff *skb,
prev = next;
}
+found:
/* We found where to put this one. Check for overlap with
* preceding fragment, and, if needed, align things so that
* any overlaps are eliminated.
@@ -341,6 +347,8 @@ static int nf_ct_frag6_queue(struct nf_ct_frag6_queue *fq, struct sk_buff *skb,
/* Insert this fragment in the chain of fragments. */
skb->next = next;
+ if (!next)
+ fq->q.fragments_tail = skb;
if (prev)
prev->next = skb;
else
@@ -464,6 +472,7 @@ nf_ct_frag6_reasm(struct nf_ct_frag6_queue *fq, struct net_device *dev)
head->csum);
fq->q.fragments = NULL;
+ fq->q.fragments_tail = NULL;
/* all original skbs are linked into the NFCT_FRAG6_CB(head).orig */
fp = skb_shinfo(head)->frag_list;
^ permalink raw reply related
* Re: [net-next-2.6 PATCH] be2net: memory barrier fixes on IBM p7 platform
From: Sathya Perla @ 2010-07-01 6:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100630.132749.218066997.davem@davemloft.net>
On Wed, 2010-06-30 at 13:27 -0700, David Miller wrote:
> > -
> > +
> > + rmb();
>
> That first addition does nothing but add erroneous trailing
> whitespace.
>
> You can physically see that something must be wrong here just by look
> at this patch chunk, please review things more thoroughly before
> submitting in the future.
>
Will do, thanks.
___________________________________________________________________________________
This message, together with any attachment(s), contains confidential and proprietary information of
ServerEngines Corporation and is intended only for the designated recipient(s) named above. Any unauthorized
review, printing, retention, copying, disclosure or distribution is strictly prohibited. If you are not the
intended recipient of this message, please immediately advise the sender by reply email message and
delete all copies of this message and any attachment(s). Thank you.
^ permalink raw reply
* Re: [PATCH] igbvf: avoid name clash between PF and VF
From: Stefan Assmann @ 2010-07-01 6:37 UTC (permalink / raw)
To: Casey Leedom
Cc: netdev, e1000-devel, Duyck, Alexander H, gregory.v.rose,
jeffrey.t.kirsher, Andy Gospodarek
In-Reply-To: <201006300959.37145.leedom@chelsio.com>
On 30.06.2010 18:59, Casey Leedom wrote:
> | From: Stefan Assmann <sassmann@redhat.com>
> | Date: Wednesday, June 30, 2010 01:53 am
> |
> | This is not a udev bug since udev doesn't create persistent rules for
> | VFs as their MAC address changes every reboot.
> |
> | To avoid this problem we could change the kernel name for the VFs and
> | thus avoid confusion between VFs and PFs.
> |
> | I've already discussed this with Alexander Duyck and Greg Rose, so far
> | they have no objection. However this problem appears for all drivers that
> | support PFs and VFs and thus the changes should be applied consistently
> | to all of these drivers.
>
> I'm not sure that this problem affects "all drivers which support PFs and VFs."
> I think that you might mean "all drivers which support PFs and VFs with non-
> persistent MAC addresses for the VFs." For instance, the MAC addresses
> associated with the new cxgb4vf VFs are persistent so, from what I understand of
> the scenario you outlined, I don't think that they would trigger the problem you
> describe. Please correct me if I've missed something. Thanks.
>
> Casey
You're correct, the problem shouldn't occur with cxgb4vf and therefore
this change shouldn't be necessary. However we might consider a
consistent naming scheme for VFs in all drivers. But I don't have a
strong opinion about this, either way would be fine by me.
Stefan
--
Stefan Assmann | Red Hat GmbH
Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach
| HR: Amtsgericht Muenchen HRB 153243
| GF: Brendan Lane, Charlie Peters,
sassmann at redhat.com | Michael Cunningham, Charles Cachera
^ permalink raw reply
* Re: RFC: Allow 'ip' to run in daemon mode?
From: Simon Horman @ 2010-07-01 7:07 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev, Stephen Hemminger
In-Reply-To: <4C2A1291.7000203@candelatech.com>
On Tue, Jun 29, 2010 at 08:34:41AM -0700, Ben Greear wrote:
> I'm considering modifying 'ip' to be able to run in daemon
> mode so that I can do lots of IP commands without having to
> pay the startup cost of iproute.
>
> The -batch option almost works, but it's hard to programatically
> figure out failure codes.
>
> I'm thinking about making these changes:
>
> 1) Move all of the error printing code into common methods (basically,
> wrap printf). In daemon mode this text can be sent back to the
> calling process, and in normal mode, it will be printed to stdout/stderr
> as it is currently.
>
> 2) Remove all or most calls to 'exit' and instead return error codes
> to the calling logic.
>
> 3) Add ability to listen on a unix socket for commands, basically treat
> them just like batch commands, one command per packet.
>
> 4) Return well formatted error code and text response to calling process
> over the unix socket, maybe something like:
>
> RV: [errno or equiv, zero for success]\n
> CMD: [ command string this relates to ]\n
> [ Optional free form text ]
>
>
> Does something like this have any chance of upstream inclusion?
Hi Ben,
can't you achieve as much by omitting 3) and using stdio (cleanly)?
Or in other words, fix batch mode rather than adding another mode.
Or are you worried about backwards-compatibility?
^ permalink raw reply
* [PATCH] ll_temac: add error checking to DMA init path
From: Denis Kirjanov @ 2010-07-01 9:39 UTC (permalink / raw)
To: davem; +Cc: john.linn, brian.hill, netdev
Add error checking to DMA descriptor rings initialization code.
Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
---
drivers/net/ll_temac_main.c | 25 +++++++++++++++++++++++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index 52dcc84..7b12d0e 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -202,14 +202,29 @@ static int temac_dma_bd_init(struct net_device *ndev)
int i;
lp->rx_skb = kzalloc(sizeof(*lp->rx_skb) * RX_BD_NUM, GFP_KERNEL);
+ if (!lp->rx_skb) {
+ dev_err(&ndev->dev,
+ "can't allocate memory for DMA RX buffer\n");
+ goto out;
+ }
/* allocate the tx and rx ring buffer descriptors. */
/* returns a virtual addres and a physical address. */
lp->tx_bd_v = dma_alloc_coherent(ndev->dev.parent,
sizeof(*lp->tx_bd_v) * TX_BD_NUM,
&lp->tx_bd_p, GFP_KERNEL);
+ if (!lp->tx_bd_v) {
+ dev_err(&ndev->dev,
+ "unable to allocate DMA TX buffer descriptors");
+ goto out;
+ }
lp->rx_bd_v = dma_alloc_coherent(ndev->dev.parent,
sizeof(*lp->rx_bd_v) * RX_BD_NUM,
&lp->rx_bd_p, GFP_KERNEL);
+ if (!lp->rx_bd_v) {
+ dev_err(&ndev->dev,
+ "unable to allocate DMA RX buffer descriptors");
+ goto out;
+ }
memset(lp->tx_bd_v, 0, sizeof(*lp->tx_bd_v) * TX_BD_NUM);
for (i = 0; i < TX_BD_NUM; i++) {
@@ -227,7 +242,7 @@ static int temac_dma_bd_init(struct net_device *ndev)
if (skb == 0) {
dev_err(&ndev->dev, "alloc_skb error %d\n", i);
- return -1;
+ goto out;
}
lp->rx_skb[i] = skb;
/* returns physical address of skb->data */
@@ -258,6 +273,9 @@ static int temac_dma_bd_init(struct net_device *ndev)
lp->dma_out(lp, TX_CURDESC_PTR, lp->tx_bd_p);
return 0;
+
+out:
+ return -ENOMEM;
}
/* ---------------------------------------------------------------------
@@ -505,7 +523,10 @@ static void temac_device_reset(struct net_device *ndev)
}
lp->dma_out(lp, DMA_CONTROL_REG, DMA_TAIL_ENABLE);
- temac_dma_bd_init(ndev);
+ if (temac_dma_bd_init(ndev)) {
+ dev_err(&ndev->dev,
+ "temac_device_reset descriptor allocation failed\n");
+ }
temac_indirect_out32(lp, XTE_RXC0_OFFSET, 0);
temac_indirect_out32(lp, XTE_RXC1_OFFSET, 0);
^ permalink raw reply related
* [RESEND][PATCH] cxgb4: Use kfree_skb for skb pointers
From: Denis Kirjanov @ 2010-07-01 9:45 UTC (permalink / raw)
To: davem; +Cc: netdev
Use kfree_skb for skb pointers
Acked-by: Dimitris Michailidis <dm@chelsio.com>
Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
---
drivers/net/cxgb4/l2t.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb4/l2t.c b/drivers/net/cxgb4/l2t.c
index 5b990d2..e8f0f55 100644
--- a/drivers/net/cxgb4/l2t.c
+++ b/drivers/net/cxgb4/l2t.c
@@ -314,7 +314,7 @@ static void t4_l2e_free(struct l2t_entry *e)
struct sk_buff *skb = e->arpq_head;
e->arpq_head = skb->next;
- kfree(skb);
+ kfree_skb(skb);
}
e->arpq_tail = NULL;
}
^ permalink raw reply related
* [PATCH repost] sched: export sched_set/getaffinity to modules
From: Michael S. Tsirkin @ 2010-07-01 11:07 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra
Cc: Sridhar Samudrala, Tejun Heo, Oleg Nesterov, netdev, lkml,
kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev, Jiri Kosina,
Thomas Gleixner, Andi Kleen
In-Reply-To: <20100625101022.GA16321@redhat.com>
Author: Sridhar Samudrala <sri@us.ibm.com>
sched: export sched_set/getaffinity to modules
vhost-net driver wants to copy the affinity from the
owner thread to thread it creates. Export
sched_set/get affinity to modules to make this possible
when vhost is built as a module.
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
I'm not sure the previous time made it clear what exactly is the
proposed change, so reposting. Info, Peter, could you ack merging the
following through the net-next tree please?
diff --git a/kernel/sched.c b/kernel/sched.c
index d484081..3759391 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -4744,6 +4744,7 @@ out_put_task:
put_online_cpus();
return retval;
}
+EXPORT_SYMBOL_GPL(sched_setaffinity);
static int get_user_cpu_mask(unsigned long __user *user_mask_ptr, unsigned len,
struct cpumask *new_mask)
@@ -4807,6 +4808,7 @@ out_unlock:
return retval;
}
+EXPORT_SYMBOL_GPL(sched_getaffinity);
/**
* sys_sched_getaffinity - get the cpu affinity of a process
^ permalink raw reply related
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