* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: Valdis.Kletnieks @ 2007-09-21 19:32 UTC (permalink / raw)
To: Denys Vlasenko; +Cc: David Miller, jeff, mchan, linux-kernel, netdev
In-Reply-To: <200709212018.06553.vda.linux@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
On Fri, 21 Sep 2007 20:18:06 BST, Denys Vlasenko said:
> On Friday 21 September 2007 19:36, Valdis.Kletnieks@vt.edu wrote:
> > Should this be redone to use the existing firmware loading framework to
> > load the firmware instead?
>
> Not in every case.
>
> For example, bnx2 maintainer says that driver and
> firmware are closely tied for his driver. IOW: you upgrade kernel
> and your NIC is not working anymore.
>
> Another argument is to make kernel be able to bring up NICs
> without needing firmware images in initramfs/initrd/hard drive.
OK, I can live with "considered and decided against". :)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: Krzysztof Oledzki @ 2007-09-21 19:33 UTC (permalink / raw)
To: Denys Vlasenko
Cc: Valdis.Kletnieks, David Miller, jeff, mchan, linux-kernel, netdev
In-Reply-To: <200709212018.06553.vda.linux@googlemail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1179 bytes --]
On Fri, 21 Sep 2007, Denys Vlasenko wrote:
> On Friday 21 September 2007 19:36, Valdis.Kletnieks@vt.edu wrote:
>> On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said:
>>
>>> I plan to use gzip compression on following drivers' firmware,
>>> if patches will be accepted:
>>>
>>> text data bss dec hex filename
>>> 17653 109968 240 127861 1f375 drivers/net/acenic.o
>>> 6628 120448 4 127080 1f068 drivers/net/dgrs.o
>>> ^^^^^^
>>
>> Should this be redone to use the existing firmware loading framework to
>> load the firmware instead?
>
> Not in every case.
>
> For example, bnx2 maintainer says that driver and
> firmware are closely tied for his driver. IOW: you upgrade kernel
> and your NIC is not working anymore.
Firmware may come with a kernel. We have a "install modules", we can also
add "install firmware".
> Another argument is to make kernel be able to bring up NICs
> without needing firmware images in initramfs/initrd/hard drive.
It is not possible to bring up things like FC or WiFi without firmware,
what special is in classic NICs?
Best regards,
Krzysztof Olędzki
^ permalink raw reply
* Re: [PATCH] sb1250-mac: Driver model & phylib update
From: Andrew Morton @ 2007-09-21 19:44 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Jeff Garzik, netdev, linux-mips, linux-kernel
In-Reply-To: <Pine.LNX.4.64N.0709191811040.24627@blysk.ds.pg.gda.pl>
On Fri, 21 Sep 2007 12:52:10 +0100 (BST)
"Maciej W. Rozycki" <macro@linux-mips.org> wrote:
> A driver model and phylib update.
akpm:/usr/src/25> diffstat patches/git-net.patch | tail -n 1
1013 files changed, 187667 insertions(+), 23587 deletions(-)
Sorry, but raising networking patches against Linus's crufty
old mainline tree just isn't viable at present.
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: Andi Kleen @ 2007-09-21 20:13 UTC (permalink / raw)
To: Denys Vlasenko; +Cc: David Miller, jeff, mchan, linux-kernel, netdev
In-Reply-To: <200709211905.23946.vda.linux@googlemail.com>
Denys Vlasenko <vda.linux@googlemail.com> writes:
>
> I plan to use gzip compression on following drivers' firmware,
> if patches will be accepted:
>
> text data bss dec hex filename
> 17653 109968 240 127861 1f375 drivers/net/acenic.o
> 6628 120448 4 127080 1f068 drivers/net/dgrs.o
> ^^^^^^
Just change the makefiles to always install gzip'ed modules
modutils knows how to unzip them on the fly.
That will catch all the firmware and all the other code too.
-Andi
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: Roland Dreier @ 2007-09-21 20:31 UTC (permalink / raw)
To: Andi Kleen
Cc: Denys Vlasenko, David Miller, jeff, mchan, linux-kernel, netdev
In-Reply-To: <p73ps0b93ph.fsf@bingen.suse.de>
> Just change the makefiles to always install gzip'ed modules
> modutils knows how to unzip them on the fly.
But that leaves the uncompressed firmware blobs in .data that ends up
in unswappable kernel memory.
- R.
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: Alan Cox @ 2007-09-21 21:03 UTC (permalink / raw)
To: Denys Vlasenko
Cc: Valdis.Kletnieks, David Miller, jeff, mchan, linux-kernel, netdev
In-Reply-To: <200709212018.06553.vda.linux@googlemail.com>
> For example, bnx2 maintainer says that driver and
> firmware are closely tied for his driver. IOW: you upgrade kernel
> and your NIC is not working anymore.
>
> Another argument is to make kernel be able to bring up NICs
> without needing firmware images in initramfs/initrd/hard drive.
dgrs should be using the request_firmware interface. Actually dgrs is
probably a good candidate for /dev/null
Alan
^ permalink raw reply
* Re: [PATCH 3/7] CAN: Add raw protocol
From: Urs Thuermann @ 2007-09-21 21:05 UTC (permalink / raw)
To: Patrick McHardy
Cc: netdev, David Miller, Thomas Gleixner, Oliver Hartkopp,
Oliver Hartkopp
In-Reply-To: <46F3BDC1.2020200@trash.net>
Patrick McHardy <kaber@trash.net> writes:
> Urs Thuermann wrote:
> > +config CAN_RAW_USER
> > + bool "Allow non-root users to access Raw CAN Protocol sockets"
>
>
> If you plan to remove this option, it should happen before merging
> since it affects userspace visible behaviour.
We have discussed this and have come to the conclusion that we should
remove permission checks completely, i.e. any user can open any CAN
socket (raw, bcm, or whatever will be implemented in the future).
This is because CAN is a pure broadcast network with no addresses.
CAN frames can't be directed to only one machine or a group or to only
one process (say one port). There is no communication between only
two (or some number) of stations which must be protected from other
stations.
On the other hand, requiring a process to have CAP_NET_RAW to open a
CAN socket would mean that such process would also be able to sniff on
your ethernet or WLAN interfaces, which one probably wouldn't want.
We have added that check when we still allowed the CAN raw socket to
bind to any interface and we didn't want an unprivileged process to be
able to read all e.g. TCP/IP traffic. Now binding is restricted to
ARPHRD_CAN interfaces. But even without this restriction the check is
not necessary, since all CAN sockets can only receive and send
ETH_P_CAN packets. So even if there would be an encapsulation of CAN
frames over ethernet or some other type of network, a normal user
process opening a CAN socket would only be able to read/write CAN
traffic, which should be OK without any special capability.
So what do you think about this?
urs
^ permalink raw reply
* Re: change the way e1000 is handling short VLAN frames
From: jamal @ 2007-09-21 21:12 UTC (permalink / raw)
To: Ben Greear
Cc: Emil Micek, auke-jan.h.kok@intel.com, netdev mailing list, Jesse
In-Reply-To: <46F3E695.7010604@candelatech.com>
On Fri, 2007-21-09 at 08:43 -0700, Ben Greear wrote:
> I just re-read the spec, and a bridge *may* pad up to 68, but it is not
> required.
> On page 166, it says equipment must be able to handle 64 byte minimums.
>
> See page 22 (section 7.2) of this document:
>
> http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf
>
> Also, page 63, 165, 166
Thanks for the enlightnment.
Do we need an ethtool interface to turn off hardware accelerated vlans?
Jesse is indicating that the intel hardware can only handle the MUST but
not the SHOULD of the spec.
Actually a more basic question: Can you select one or the other mode in
the software based vlans?
cheers,
jamal
^ permalink raw reply
* Re: change the way e1000 is handling short VLAN frames
From: Ben Greear @ 2007-09-21 21:18 UTC (permalink / raw)
To: hadi; +Cc: Emil Micek, auke-jan.h.kok@intel.com, netdev mailing list, Jesse
In-Reply-To: <1190409160.4231.29.camel@localhost>
jamal wrote:
> On Fri, 2007-21-09 at 08:43 -0700, Ben Greear wrote:
>
>> I just re-read the spec, and a bridge *may* pad up to 68, but it is not
>> required.
>> On page 166, it says equipment must be able to handle 64 byte minimums.
>>
>> See page 22 (section 7.2) of this document:
>>
>> http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf
>>
>> Also, page 63, 165, 166
>
> Thanks for the enlightnment.
> Do we need an ethtool interface to turn off hardware accelerated vlans?
> Jesse is indicating that the intel hardware can only handle the MUST but
> not the SHOULD of the spec.
> Actually a more basic question: Can you select one or the other mode in
> the software based vlans?
It's not even clear to me that it's a Should..more like a 'May', for what
thats worth.
As for using the software stack, I don't think we are padding to 68 in
the soft vlans either...
It would be nice to have an ethtool to turn off hw vlans for other reasons,
like sniffing vlan tags, at least...
You cannot select hw v/s soft vlans...the code always uses hw-accel if it's
available, as far as I know.
Thanks,
Ben
>
> cheers,
> jamal
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: change the way e1000 is handling short VLAN frames
From: Kok, Auke @ 2007-09-21 21:21 UTC (permalink / raw)
To: hadi; +Cc: Ben Greear, Emil Micek, netdev mailing list, Jesse
In-Reply-To: <1190409160.4231.29.camel@localhost>
jamal wrote:
> On Fri, 2007-21-09 at 08:43 -0700, Ben Greear wrote:
>
>> I just re-read the spec, and a bridge *may* pad up to 68, but it is not
>> required.
>> On page 166, it says equipment must be able to handle 64 byte minimums.
>>
>> See page 22 (section 7.2) of this document:
>>
>> http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf
>>
>> Also, page 63, 165, 166
>
> Thanks for the enlightnment.
> Do we need an ethtool interface to turn off hardware accelerated vlans?
> Jesse is indicating that the intel hardware can only handle the MUST but
> not the SHOULD of the spec.
I don't actually see the "SHOULD" part you are referring to. AFAIK the RX side is
fully covered and only on TX the hardware sends out 64b padded vlan packets, which
is permitted. The spec never says that it is required to send out 68b padded vlan
packets - only permits either choice.
Auke
^ permalink raw reply
* Re: change the way e1000 is handling short VLAN frames
From: Chris Leech @ 2007-09-21 21:27 UTC (permalink / raw)
To: hadi
Cc: Ben Greear, Emil Micek, auke-jan.h.kok@intel.com,
netdev mailing list, Jesse
In-Reply-To: <1190409160.4231.29.camel@localhost>
On 9/21/07, jamal <hadi@cyberus.ca> wrote:
> On Fri, 2007-21-09 at 08:43 -0700, Ben Greear wrote:
>
> > I just re-read the spec, and a bridge *may* pad up to 68, but it is not
> > required.
> > On page 166, it says equipment must be able to handle 64 byte minimums.
> >
> > See page 22 (section 7.2) of this document:
> >
> > http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf
> >
> > Also, page 63, 165, 166
>
> Thanks for the enlightnment.
> Do we need an ethtool interface to turn off hardware accelerated vlans?
> Jesse is indicating that the intel hardware can only handle the MUST but
> not the SHOULD of the spec.
> Actually a more basic question: Can you select one or the other mode in
> the software based vlans?
Inserting the VLAN tag in software will not change the behavior in the
way you want anyway, short frames will still be padded to 64 bytes.
You'd have to do short packet padding in software to 68 bytes. Or do
software padding to 64 bytes and let the hardware insert the VLAN tag
after.
Chris
^ permalink raw reply
* Re: change the way e1000 is handling short VLAN frames
From: jamal @ 2007-09-21 21:29 UTC (permalink / raw)
To: Kok, Auke; +Cc: Ben Greear, Emil Micek, netdev mailing list, Jesse
In-Reply-To: <46F435CD.1090502@intel.com>
On Fri, 2007-21-09 at 14:18 -0700, Ben Greear wrote:
> As for using the software stack, I don't think we are padding to 68 in
> the soft vlans either...
Should be much easier than changing firmware or an ASIC.
> It would be nice to have an ethtool to turn off hw vlans for other reasons,
> like sniffing vlan tags, at least...
Hrm, no hardware out there will pass on tags to the stack as metadata?
On Fri, 2007-21-09 at 14:21 -0700, Kok, Auke wrote:
> I don't actually see the "SHOULD" part you are referring to.
the "optional" part;-> MAY?
> AFAIK the RX side is fully covered
so you can handle both 64B and 68B?
> and only on TX the hardware sends out 64b padded vlan packets, which
> is permitted. The spec never says that it is required to send out 68b padded vlan
> packets - only permits either choice.
The CISCO i pointed to seems to be only capable of 68B. So if the CISCO
sends to you, it would work, but you sending to the CISCO or to Emil's
CMTS you have challenges, no?
cheers,
jamal
^ permalink raw reply
* Re: change the way e1000 is handling short VLAN frames
From: Kok, Auke @ 2007-09-21 21:34 UTC (permalink / raw)
To: hadi; +Cc: Ben Greear, Emil Micek, netdev mailing list, Jesse
In-Reply-To: <1190410187.4231.43.camel@localhost>
jamal wrote:
>> AFAIK the RX side is fully covered
>
> so you can handle both 64B and 68B?
I never saw any bugreports about e1000 not being able to accept vlan packets
because of this, so I'm quite certain it works OK, feel free to find me a case
where this isn't so :)
Auke
^ permalink raw reply
* Re: change the way e1000 is handling short VLAN frames
From: jamal @ 2007-09-21 21:36 UTC (permalink / raw)
To: Chris Leech
Cc: Ben Greear, Emil Micek, auke-jan.h.kok@intel.com,
netdev mailing list, Jesse
In-Reply-To: <41b516cb0709211427s45cdd3b0pa0bb76d114d5f041@mail.gmail.com>
On Fri, 2007-21-09 at 14:27 -0700, Chris Leech wrote:
>
> Inserting the VLAN tag in software will not change the behavior in the
> way you want anyway, short frames will still be padded to 64 bytes.
> You'd have to do short packet padding in software to 68 bytes. Or do
> software padding to 64 bytes and let the hardware insert the VLAN tag
> after.
I like the second one because it could be done totaly in the driver and
would resolve the problem IMO. All we need after is an ethtool knob to
select between 64B or 68B txmit.
cheers,
jamal
^ permalink raw reply
* Re: change the way e1000 is handling short VLAN frames
From: jamal @ 2007-09-21 21:43 UTC (permalink / raw)
To: Kok, Auke; +Cc: Ben Greear, Emil Micek, netdev mailing list, Jesse
In-Reply-To: <46F438F3.5030201@intel.com>
On Fri, 2007-21-09 at 14:34 -0700, Kok, Auke wrote:
> I never saw any bugreports about e1000 not being able to accept vlan packets
> because of this, so I'm quite certain it works OK, feel free to find me a case
> where this isn't so :)
If you tell me it can be done on the rx, i will take your word for it;->
Emil can certainly verify it.
The tx you certainly have issues - Look at one of the suggestions from
Chris, i think it is resolvable.
cheers,
jamal
^ permalink raw reply
* Re: e1000 driver and samba
From: Francois Romieu @ 2007-09-21 21:49 UTC (permalink / raw)
To: Bruce Cole; +Cc: netdev
In-Reply-To: <46F302A8.7040008@gmail.com>
Bruce Cole <bacole@gmail.com> :
> >If you look for it on the Realtek cards, there had been sporadic
> >Nissues up to late 2005. The solution posted universally was 'change
> >card'.
>
> Yes, that *was* the common recommendation.
There was no such thing as a universal solution to sporadic issues.
[...]
> I suspect the root problem is the driver isn't properly locking
> the TX queue.
Can you be more specific ?
--
Ueimor
^ permalink raw reply
* Re: change the way e1000 is handling short VLAN frames
From: Chris Leech @ 2007-09-21 22:02 UTC (permalink / raw)
To: hadi; +Cc: Kok, Auke, Ben Greear, Emil Micek, netdev mailing list, Jesse
In-Reply-To: <1190411007.4231.54.camel@localhost>
On 9/21/07, jamal <hadi@cyberus.ca> wrote:
> On Fri, 2007-21-09 at 14:34 -0700, Kok, Auke wrote:
>
> > I never saw any bugreports about e1000 not being able to accept vlan packets
> > because of this, so I'm quite certain it works OK, feel free to find me a case
> > where this isn't so :)
>
> If you tell me it can be done on the rx, i will take your word for it;->
> Emil can certainly verify it.
> The tx you certainly have issues - Look at one of the suggestions from
> Chris, i think it is resolvable.
I'd say that devices that can't receive 64 bytes VLAN tagged frames
have an issue, but for the sake of interoperability and solving Emil's
problem I'm willing to discuss how a change to e1000 would work ;-)
The simplest option is to add software small frame padding all the
time. It won't catch software tagged frames if they were generated
somehow, but should fix the hardware tagged ones to be 68 bytes on the
wire. If you were worried about software tagged frames then replacing
ETH_ZLEN with VLAN_ETH_ZLEN would pad all frames, VLAN or not, to 68
bytes.
Emil, this patch will probably do what you want.
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 4a22595..34e3d18 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -3284,6 +3284,9 @@ e1000_xmit_frame(struct sk_buff *skb, struct
net_device *netdev)
return NETDEV_TX_OK;
}
+ if (skb_padto(skb, ETH_ZLEN))
+ return NETDEV_TX_OK;
+
/* 82571 and newer doesn't need the workaround that limited descriptor
* length to 4kB */
if (adapter->hw.mac_type >= e1000_82571)
^ permalink raw reply related
* Re: [stable] [PATCH] cfg80211: fix initialisation if built-in
From: Greg KH @ 2007-09-21 22:02 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, netdev, linux-wireless,
stable-DgEjT+Ai2ygdnm+yROfE0A, Rob Hussey
In-Reply-To: <1189424685.4506.63.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
On Mon, Sep 10, 2007 at 01:44:45PM +0200, Johannes Berg wrote:
> When cfg80211 is built into the kernel it needs to init earlier
> so that device registrations are run after it has initialised.
>
> Signed-off-by: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
When this goes into Linus's tree, please resend it to the
stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org address so we can add it to our queue.
thanks,
greg k-h
^ permalink raw reply
* Re: e1000 driver and samba
From: Bruce Cole @ 2007-09-21 22:01 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, bacole
In-Reply-To: <20070921214916.GA2386@electric-eye.fr.zoreil.com>
Francois Romieu wrote:
> Bruce Cole <bacole@gmail.com> :
>
>>> If you look for it on the Realtek cards, there had been sporadic
>>> Nissues up to late 2005. The solution posted universally was 'change
>>> card'.
>>>
>> Yes, that *was* the common recommendation.
>>
>
> There was no such thing as a universal solution to sporadic issues.
>
I made no such claim. I do claim the realtek samba et all issues are
not sporadic however. In fact the
common problem is readily reproducible as has been shown.
> [...]
>
>> I suspect the root problem is the driver isn't properly locking
>> the TX queue.
>>
>
> Can you be more specific ?
>
Yes per the reference I gave:
http://www.spinics.net/lists/netdev/msg40384.html
"Now since this change heals the TX queue stall, it would seem that the real
underlying problem involves a race condition with enqueueing to the TX queue
while the controller is processing the queue. The ultimate fix for that
I bet is either to address locking at TX enqueue time, or there is a
controller bug. Any clarification from realtek on the necessary
processing for the NPQ bit, or
a known controller problem?
PS: I've also received private email that this problem pertains to video
streaming (to a Kiss DVD player) not just samba or X11 traffic. Basically
most all high-level TCP based protocols are affected it seems. This serious
performance problem should be considered to impact a lot more than just
samba
users."
I could probably help fix the underlying problem but I didn't
receive any response to my post quoted above.
^ permalink raw reply
* Re: [stable] [PATCH] cfg80211: fix initialisation if built-in
From: Johannes Berg @ 2007-09-21 22:06 UTC (permalink / raw)
To: Greg KH; +Cc: John W. Linville, netdev, linux-wireless, stable, Rob Hussey
In-Reply-To: <20070921220253.GA32585@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 453 bytes --]
On Fri, 2007-09-21 at 15:02 -0700, Greg KH wrote:
> When this goes into Linus's tree, please resend it to the
> stable@kernel.org address so we can add it to our queue.
It's on the way, sitting in net-2.6.24 right now but I don't know
whether it's scheduled for .23. I'm no longer sure if it really matters
for -stable since we have no drivers there so typically drivers build as
out-of-tree modules and the issue doesn't matter.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: ?^?H?G Re: [linux-usb-devel] Please pull 'ssb-drivers' branch of wireless-2.6 -- aln.
From: Greg KH @ 2007-09-21 22:19 UTC (permalink / raw)
To: Alninuo_Li
Cc: John W. Linville, David Brownell, linux-usb-devel, jeff, netdev,
linux-wireless, linux-usb-users, mb, zambrano, davem
In-Reply-To: <OF5E769610.A64618C1-ON4825735D.000F9F12@sdc.sercomm.com>
On Fri, Sep 21, 2007 at 10:58:37AM +0800, Alninuo_Li@sdc.sercomm.com wrote:
>
> Hi Greh,
hm, I don't know of anyone by that name :)
You might not want to take over a totally different thread for your
question, it doesn't make much sense that way...
> I donot know how to ask question to u, so use this reply.
> We are focusing on 2.4.20 to make use of usbserial driver work for
> Notevel U740, but it would crash after long run, seem the Interrupt
> stopped, and can't send down, stoped at generic_write func call alwways
> return with busy.
> And could you tell us some idea or how to debug the code, when we
> open the usb debug, it would crash quickly, since the printk have huge
> messages, is there good idea to debug or how to go?
No one supports 2.4.20 anymore, sorry. I suggest you move to the 2.6
kernel tree instead.
good luck,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: Jeff Garzik @ 2007-09-21 22:33 UTC (permalink / raw)
To: Alan Cox
Cc: Denys Vlasenko, Valdis.Kletnieks, David Miller, mchan,
linux-kernel, netdev
In-Reply-To: <20070921220333.3b31afb5@the-village.bc.nu>
Alan Cox wrote:
>> For example, bnx2 maintainer says that driver and
>> firmware are closely tied for his driver. IOW: you upgrade kernel
>> and your NIC is not working anymore.
>>
>> Another argument is to make kernel be able to bring up NICs
>> without needing firmware images in initramfs/initrd/hard drive.
>
> dgrs should be using the request_firmware interface. Actually dgrs is
> probably a good candidate for /dev/null
According to an earlier thread, dgrs was never really maintained,
written for hardware that was never really distributed widely, and very
likely hasn't had users in years... if ever.
If that picture is accurate (it's a story I was told), then I am
definitely queueing up a deletion patch.
Jeff
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: Denys Vlasenko @ 2007-09-21 22:37 UTC (permalink / raw)
To: Andi Kleen; +Cc: David Miller, jeff, mchan, linux-kernel, netdev
In-Reply-To: <p73ps0b93ph.fsf@bingen.suse.de>
On Friday 21 September 2007 21:13, Andi Kleen wrote:
> Denys Vlasenko <vda.linux@googlemail.com> writes:
> >
> > I plan to use gzip compression on following drivers' firmware,
> > if patches will be accepted:
> >
> > text data bss dec hex filename
> > 17653 109968 240 127861 1f375 drivers/net/acenic.o
> > 6628 120448 4 127080 1f068 drivers/net/dgrs.o
> > ^^^^^^
>
> Just change the makefiles to always install gzip'ed modules
> modutils knows how to unzip them on the fly.
But I compile net/* into bzImage. I like netbooting :)
--
vda
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: Alan Cox @ 2007-09-21 22:48 UTC (permalink / raw)
To: Jeff Garzik
Cc: Denys Vlasenko, Valdis.Kletnieks, David Miller, mchan,
linux-kernel, netdev
In-Reply-To: <46F446C3.9050600@garzik.org>
> According to an earlier thread, dgrs was never really maintained,
> written for hardware that was never really distributed widely, and very
> likely hasn't had users in years... if ever.
>
> If that picture is accurate (it's a story I was told), then I am
> definitely queueing up a deletion patch.
I think thats sensible. If someone whines it can be put back but I really
don't think anyone will
^ permalink raw reply
* Re: e1000 driver and samba
From: Francois Romieu @ 2007-09-21 22:41 UTC (permalink / raw)
To: Bruce Cole; +Cc: netdev
In-Reply-To: <46F43F4B.7090903@gmail.com>
Bruce Cole <bacole@gmail.com> :
> Francois Romieu wrote:
[...]
> >Can you be more specific ?
> >
> Yes per the reference I gave:
> http://www.spinics.net/lists/netdev/msg40384.html
[...]
Ok, I wondered if you had found something between the start_xmit and the
Tx completion code.
[...]
> I could probably help fix the underlying problem but I didn't
> receive any response to my post quoted above.
I have submitted the smallest workaround to Jeff. It is not necessarily
the best wrt performance but this part is not trivial to arbitrate.
--
Ueimor
^ 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