On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/net/spider_net.c
[PATCH -mm] spider_net: Misc build fixes after recent netdev stats changes
Unbreak the following:
drivers/net/spider_net.c
Hi!
> I'm pleased to announce third release of the distributed storage
> subsystem, which allows to form a storage on top of remote and local
> nodes, which in turn can be exported to another storage as a node to
> form tree-like storages.
How is this different from raid0/1 over nbd? Or raid0/1 o
On Fri, 2007-09-21 at 10:49 -0700, David Miller wrote:
> From: Denys Vlasenko <[EMAIL PROTECTED]>
> Date: Fri, 21 Sep 2007 18:03:55 +0100
>
> > Do patches look ok to you?
>
> I'm travelling so I haven't looked closely yet :-)
>
> Michael can take a look and I'll try to do so as well
> tonight.
>
On Fri, Sep 21, 2007 at 04:59:54PM +0200, Christian Borntraeger wrote:
>
> I suggest to document that LLTX is deprecated.
>
> Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
This looks good to me.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EM
On Fri, Sep 21, 2007 at 11:48:05PM +0100, Alan Cox wrote:
> > 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
Denys Vlasenko wrote:
On Friday 21 September 2007 20:33, Krzysztof Oledzki wrote:
On Fri, 21 Sep 2007, Denys Vlasenko wrote:
On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote:
On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said:
I plan to use gzip compression on following drivers
On Friday 21 September 2007 20:33, Krzysztof Oledzki wrote:
>
> On Fri, 21 Sep 2007, Denys Vlasenko wrote:
>
> > On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote:
> >> On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said:
> >>
> >>> I plan to use gzip compression on following drivers'
Bruce Cole <[EMAIL PROTECTED]> :
> 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 coul
> 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 p
On Friday 21 September 2007 21:13, Andi Kleen wrote:
> Denys Vlasenko <[EMAIL PROTECTED]> writes:
> >
> > I plan to use gzip compression on following drivers' firmware,
> > if patches will be accepted:
> >
> >textdata bss dec hex filename
> > 17653 109968 240 127861
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.
d
On Fri, Sep 21, 2007 at 10:58:37AM +0800, [EMAIL PROTECTED] 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 t
On Fri, 2007-09-21 at 15:02 -0700, Greg KH wrote:
> When this goes into Linus's tree, please resend it to the
> [EMAIL PROTECTED] 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 reall
Francois Romieu wrote:
Bruce Cole <[EMAIL PROTECTED]> :
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
On 9/21/07, jamal <[EMAIL PROTECTED]> 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 :)
>
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 <[EMAIL PROTECTED]>
When this goes into Linus's tree, please resend it
Bruce Cole <[EMAIL PROTECTED]> :
> >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.
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 wo
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 b
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
-
To unsubscribe fro
On 9/21/07, jamal <[EMAIL PROTECTED]> 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.
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 s
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://s
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/ge
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/geti
Patrick McHardy <[EMAIL PROTECTED]> 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 dis
> 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 sho
> 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.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body
Denys Vlasenko <[EMAIL PROTECTED]> writes:
>
> I plan to use gzip compression on following drivers' firmware,
> if patches will be accepted:
>
>textdata bss dec hex filename
> 17653 109968 240 127861 1f375 drivers/net/acenic.o
>6628 120448 4 127080 1f06
On Fri, 21 Sep 2007 12:52:10 +0100 (BST)
"Maciej W. Rozycki" <[EMAIL PROTECTED]> 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 Li
On Fri, 21 Sep 2007, Denys Vlasenko wrote:
On Friday 21 September 2007 19:36, [EMAIL PROTECTED] 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:
textdata bss dec hex
On Fri, 21 Sep 2007 20:18:06 BST, Denys Vlasenko said:
> On Friday 21 September 2007 19:36, [EMAIL PROTECTED] 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
On Friday 21 September 2007 19:36, [EMAIL PROTECTED] 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:
> >
> >textdata bss dec hex filename
> > 17653 109968
On Fri, 21 Sep 2007 13:51:12 +0100 (BST)
"Maciej W. Rozycki" <[EMAIL PROTECTED]> wrote:
> On Thu, 20 Sep 2007, Andrew Morton wrote:
>
> > You always put boring, crappy, insufficient text in the for-the-changelog
> > section and interesting, useful, sufficient text in the
> > not-for-the-changelo
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:
>
>textdata bss dec hex filename
> 17653 109968 240 127861 1f375 drivers/net/acenic.o
>6628 120448 4 127
L F wrote:
Aha. This doesn't seem to be in mr. Romieu's patch above: should it go
in on top of that?
His newer
0002-r8169-workaround-against-ignored-TxPoll-writes-8168.patch
does the same thing as the older quoted version, and is also
included in the roll-up patch he pointed you to.
I agree
On 9/19/07, Ayaz Abdulla <[EMAIL PROTECTED]> wrote:
> It seems that you are powering down the phy even if WOL is enabled.
Right; I've updated the patch to skip powering down the phy when wol is enabled.
> Secondly, can you powerdown the phy at the same time you start
> performing autoneg restart?
Patrick McHardy <[EMAIL PROTECTED]> writes:
> You drop the module reference again when leaving this function.
> So sock->ops might contain a stale pointer if the module is
> unloaded after this. You need to either keep the module reference
> while the socket is alive or remove stale references whe
On Friday 21 September 2007 18:49, David Miller wrote:
> From: Denys Vlasenko <[EMAIL PROTECTED]>
> Date: Fri, 21 Sep 2007 18:03:55 +0100
>
> > Do patches look ok to you?
>
> I'm travelling so I haven't looked closely yet :-)
>
> Michael can take a look and I'll try to do so as well
> tonight.
From: Denys Vlasenko <[EMAIL PROTECTED]>
Date: Fri, 21 Sep 2007 18:03:55 +0100
> Do patches look ok to you?
I'm travelling so I haven't looked closely yet :-)
Michael can take a look and I'll try to do so as well
tonight.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the
On Thu, 20 Sep 2007, Nagendra Tomar wrote:
> > That's not what POLLOUT means in the Unix meaning. POLLOUT indicates the
> > ability to write, and it is not meant as to signal every time a packet
> > (skb) is sent on the wire (and the buffer released).
>
> Aren't they both the same ? Everytime a
Emil Micek wrote:
> What is the right behaviour according to specification? In iee802.3,
> minFrameSize is 64bytes. I've never seen any document which'd say that
> VLAN frames should be 68 bytes minimum.
e1000 only hardware pads to 64 bytes, but if you use the vlan module and
turn off the hardware
On Friday 21 September 2007 17:14, David Miller wrote:
> From: Denys Vlasenko <[EMAIL PROTECTED]>
> Date: Fri, 21 Sep 2007 12:01:24 +0100
>
> > Hi Jeff,
>
> BNX2 and TG3 patches goes through Michael Chan and myself,
> and I usually merge them in instead of Jeff.
Didn't know that, sorry.
Do patc
On Fri, 2007-09-21 at 12:35 +0200, Urs Thuermann wrote:
> I didn't find a way with gcc-2.95 to make the format
> string a separate macro argument (which I also wanted).
The old 2.x GCC workaround was to use
#define DBG(fmt, arg) printk(fmt , ## arg)
adding a space before the last comma.
>
From: Krishna Kumar <[EMAIL PROTECTED]>
Returning BUSY will make qdisc_restart enqueue the skb which was already
freed. The bad skb was correctly freed and we should return NETDEV_TX_OK.
First spotted by Jeff Garzik on 08/13/07.
Signed-off-by: Krishna Kumar <[EMAIL PROTECTED]>
Signed-off-by: Auk
On Thursday 20 September 2007 00:17:12 David Miller wrote:
> From: Joe Perches <[EMAIL PROTECTED]>
> Date: Wed, 19 Sep 2007 14:53:22 -0700
>
> > drivers/net/wireless/b43legacy/built-in.o: In function `tsf_read_file':
> > drivers/net/wireless/b43legacy/debugfs.c:80: multiple definition of
> > `tsf
From: Denys Vlasenko <[EMAIL PROTECTED]>
Date: Fri, 21 Sep 2007 12:01:24 +0100
> Hi Jeff,
BNX2 and TG3 patches goes through Michael Chan and myself,
and I usually merge them in instead of Jeff.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL
I'd like to see the same order of devices in /sys/class/net/eth*
as in /sys/bus/pci/devices. This would make administration easier.
On Fedora 8 tests, the order I see is reversed:
http://bugzilla.redhat.com/show_bug.cgi?id=291431
Perhaps the reversal is a result of the alias order listed in
/et
Hello!
Remove artificial limitation for sfq queue limit.
This is followup to Patrick's patch. A little optimization to enqueue
routine allows to remove artificial limitation on queue length.
Plus, testing showed that hash function used by SFQ is too bad or even worse.
It does not even sweep the
jamal wrote:
On Fri, 2007-21-09 at 09:37 -0400, jamal wrote:
On Fri, 2007-21-09 at 14:50 +0200, Emil Micek wrote:
On Fri, 2007-09-21 at 07:59 -0400, jamal wrote:
Which would make it a bug. AFAIK, the minimum VLAN tagged packet going
out is 68 bytes.
Are you sure about t
Evgeniy Polyakov wrote:
Hi Steve.
On Mon, Sep 17, 2007 at 10:25:04AM -0500, Steve Wise ([EMAIL PROTECTED]) wrote:
Does creating the whole new netdevice is a too big overhead, or is it
considered bad idea?
I think its too big overhead, and pretty invasive on the low level cxgb3
driver. I thi
lepton wrote:
> My situation is:
> The default route device is a e1000 network card that can do TSO.
> So the tcp stack will try send big skb to netfilter frame work.
> But after rerouting, the packtes will go out from a device that
> can not do TSO. the packet is just get dropped..
>
> I thinks
Am Freitag, 21. September 2007 schrieb Herbert Xu:
> Please don't use LLTX in new drivers. We're trying to get rid
> of it since it's
>
> 1) unnecessary;
> 2) causes problems with AF_PACKET seeing things twice.
I suggest to document that LLTX is deprecated.
Signed-off-by: Christian Borntraeger
On 9/21/07, jamal <[EMAIL PROTECTED]> wrote:
> Hope that makes sense.
[cut]
> cheers,
> jamal
Hi all,
as far as I understand ieee docs both 64 and 68
approaches are fine...
--- Std 802.1Q-2005, 6.5.1 ---
On receipt of an M_UNITDATA.request primitive that
represents a tagged frame, the implementa
On 9/20/07, Bruce Cole <[EMAIL PROTECTED]> wrote:
> Yes, that *was* the common recommendation. But recently I narrowed down the
> realtek performance problem most commonly seen with samba (but also applicable
> to other TCP applications), and I also narrowed down the fix as well.
>
> The current f
Yes.
My situation is:
The default route device is a e1000 network card that can do TSO.
So the tcp stack will try send big skb to netfilter frame work.
But after rerouting, the packtes will go out from a device that
can not do TSO. the packet is just get dropped..
I thinks if we can't get a way t
On 9/19/07, Bill Fink <[EMAIL PROTECTED]> wrote:
> Just my personal opinion, but unless you want to do more testing,
> since you now seem to have a working setup, I would tend to leave
> it the way it is.
Quite sensible, yes. Performance even seems to be good - I am getting
40-40MBps reads and 24-2
On Wed, 19 Sep 2007, Tom Quetchenbach wrote:
> Here are a couple of patches against 2.6.22.6. The first one is just
> David's patches tweaked for 2.6.22.6, with a couple of minor bugfixes to
> get it to compile and not crash.
Why did you combine original patches to a single larger one, I think Da
On Wed, 19 Sep 2007, Tom Quetchenbach wrote:
> Patch 2: fixes to fack_counts and enhancement of SACK fast path
...Usually these are not combined in patches but a separate patch per
change.
> diff -ur linux-2.6.22.6-rbtree-davem-fixed/include/net/tcp.h
> linux-2.6.22.6-rbtree-tomq/include/net/t
On Fri, 2007-21-09 at 09:37 -0400, jamal wrote:
> On Fri, 2007-21-09 at 14:50 +0200, Emil Micek wrote:
> > On Fri, 2007-09-21 at 07:59 -0400, jamal wrote:
>
> > > Which would make it a bug. AFAIK, the minimum VLAN tagged packet going
> > > out is 68 bytes.
> > Are you sure about this?
>
> This i
On Wed, 19 Sep 2007, Tom Quetchenbach wrote:
> Patch 1: David Miller's red-black tree code, tweaked for 2.6.22.6,
> with some bugfixes
It would help if you would leave the original changes as is (rb-tree and
fack_count separated) and add your work on top of that...
> diff -ur linux-2.6.22.6/inc
On Fri, 2007-21-09 at 14:50 +0200, Emil Micek wrote:
> On Fri, 2007-09-21 at 07:59 -0400, jamal wrote:
> > Which would make it a bug. AFAIK, the minimum VLAN tagged packet going
> > out is 68 bytes.
> Are you sure about this?
This is what i have always seen. Double checked with google and she ga
Marco Berizzi wrote:
> inet 1.1.1.1/32 scope global eth0
^^
Sorry, my fault.
Apologies for all the noise.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majord
Satoshi OSHIMA <[EMAIL PROTECTED]> writes:
> This patch introduces global variable for UDP memory accounting.
> The unit is page.
The global variable doesn't seem to be very MP scalable, especially
if you change it for each packet. This will be a very hot cache line,
in the worst case bouncing ar
Hi.
On Fri, Sep 21, 2007 at 09:18:07PM +0900, Satoshi OSHIMA ([EMAIL PROTECTED])
wrote:
> This patch set try to introduce memory usage accounting for
> UDP(currently ipv4 only).
>
> Currently, memory usage of UDP can be observed as the sam of
> usage of tx_queue and rx_queue. But I believe that
jamal wrote:
> On Fri, 2007-21-09 at 11:08 +0200, Marco Berizzi wrote:
>
> > thanks for the reply.
> > I have tried to 'echo 1 > /proc/sys/net/ipv4/conf/eth0',
> > but the 'arp whos-has' behaviour doesn't change.
> > Other hints?
>
> Give a man a fish and he'll eat for a day
>
> Documentation/
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.
-
To unsubscribe from this list: send the line "unsubscribe netdev"
Urs Thuermann wrote:
> +static int can_create(struct net *net, struct socket *sock, int protocol)
> +{
> + ...
> +
> + spin_lock(&proto_tab_lock);
> + cp = proto_tab[protocol];
> + if (cp && !try_module_get(cp->prot->owner))
> + cp = NULL;
> + spin_unlock(&proto_tab_
On Thu, 20 Sep 2007, Andrew Morton wrote:
> You always put boring, crappy, insufficient text in the for-the-changelog
> section and interesting, useful, sufficient text in the not-for-the-changelog
> section.
I'll swap the sections in the future then. ;-) Frankly I was not sure
whether the cha
On Fri, 2007-09-21 at 07:59 -0400, jamal wrote:
> > Current e1000 (according to our observations) first appends 4 bytes of
> > VLAN tag and then pads the frame to 64 bytes with zeroes if necessary
> > before transmiting it.
>
> Which would make it a bug. AFAIK, the minimum VLAN tagged packet going
lepton wrote:
> Yes, you are right.
> What do you think about this:
> For all packets can be sent out, we just disable
> all things in sk_route_caps in ip_route_me_harder
Whats the point of doing that? Is rerouting breaking anything for you?
-
To unsubscribe from this list: send the line "unsubs
This patch introduces sndbuf size check before
memory allcation for send buffer.
signed-off-by: Satoshi Oshima <[EMAIL PROTECTED]>
signed-off-by: Hideo Aoki <[EMAIL PROTECTED]>
Index: 2.6.23-rc7-udp_limit/net/ipv4/ip_output.c
===
--
This patch introduces memory usage measurement for UDP.
signed-off-by: Satoshi Oshima <[EMAIL PROTECTED]>
signed-off-by: Hideo Aoki <[EMAIL PROTECTED]>
Index: 2.6.23-rc7-udp_limit/net/ipv4/ip_output.c
===
--- 2.6.23-rc7-udp_limit.or
This patch introduces global variable for UDP memory accounting.
The unit is page.
signed-off-by: Satoshi Oshima <[EMAIL PROTECTED]>
signed-off-by: Hideo Aoki <[EMAIL PROTECTED]>
Index: 2.6.23-rc3-udp_limit/include/net/sock.h
===
--
This patch set try to introduce memory usage accounting for
UDP(currently ipv4 only).
Currently, memory usage of UDP can be observed as the sam of
usage of tx_queue and rx_queue. But I believe that the system
wide accounting is usefull when heavy loaded condition.
In the next step, I would like t
On Fri, 2007-21-09 at 11:08 +0200, Marco Berizzi wrote:
> thanks for the reply.
> I have tried to 'echo 1 > /proc/sys/net/ipv4/conf/eth0',
> but the 'arp whos-has' behaviour doesn't change.
> Other hints?
Give a man a fish and he'll eat for a day
Documentation/networking/ip-sysctl.txt
chee
On Fri, 2007-21-09 at 13:56 +0200, Patrick McHardy wrote:
> This doesn't help much since he uses the iptables marks for
> classification on the ifb device, so he might as well just
> classify directly using u32.
true.
> I think it would be nice to
> have an ematch equivalent to the ipt action f
jamal wrote:
> On Thu, 2007-20-09 at 17:26 +0200, Patrick McHardy wrote:
>
>> I don't see a good solution for this that
>>allows to keep the iptables rules, I'd suggest to switch to ematches.
>
>
> One approach could be to use ipt action:
>
> ---
> tc filter add dev ppp0 parent
On Fri, 2007-21-09 at 09:31 +0200, Emil Micek wrote:
> Hello list,
>
> I'd like to change behaviour of e1000 module when transmiting short
> ethernet frames (shorter then 64 bytes) trough VLAN interface.
>
> Current e1000 (according to our observations) first appends 4 bytes of
> VLAN tag and the
A driver model and phylib update. It includes the following changes:
1. Removal of unused module options.
2. Phylib support and the resulting removal of generic bits for handling
the PHY.
3. Proper reserving of device resources and using ioremap()ped handles
to access MAC registers rathe
On Fri, 2007-21-09 at 07:43 -0400, jamal wrote:
> one cpu in either bottom/top half has to be slightly loaded and you
> loose the ordering where incoming doesnt match outgoing packet order.
Actually in your case it gets worse because (if i read that code
correctly) you randomly select the CPUs.
On Fri, 2007-21-09 at 17:25 +0800, John Ye wrote:
> David,
>
> Thanks for your reply. I understand it's not worth to do.
>
> I have made it a loadable module to fulfill the function. it mainly for busy
> NAT gateway server with SMP to speed up.
>
John,
It was a little hard to read your code; h
On Thu, 2007-20-09 at 17:26 +0200, Patrick McHardy wrote:
> I don't see a good solution for this that
> allows to keep the iptables rules, I'd suggest to switch to ematches.
One approach could be to use ipt action:
---
tc filter add dev ppp0 parent : protocol ip u32 match u32
On Friday 21 September 2007 12:01, Denys Vlasenko wrote:
> I will move this code
> out of the driver and into zlib in follow-on patch.
No, I won't. I accidentally attached both patches to first email,
you can find it there. Sorry.
--
vda
-
To unsubscribe from this list: send the line "unsubscribe
Hi Jeff,
This patch modifies gzip unpacking code in bnx2 driver so that
it does not depend on bnx2 internals. I will move this code
out of the driver and into zlib in follow-on patch.
It can be useful in other drivers which need to store firmwares
or any other relatively big binary blobs - fonts,
Joe Perches <[EMAIL PROTECTED]> writes:
> On Thu, 2007-09-20 at 20:43 +0200, Urs Thuermann wrote:
> > +#define DBG(...) (debug & 1 ? \
> > + (printk(KERN_DEBUG "can-%s %s: ", \
> > + IDENT, __func__), printk(args)) : 0)
> > +#define
David,
Thanks for your reply. I understand it's not worth to do.
I have made it a loadable module to fulfill the function. it mainly for busy
NAT gateway server with SMP to speed up.
John Ye
- Original Message -
From: "David Miller" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: ; <[
Chuck Ebbert wrote:
> > Is there a way to force linux to make an arp
> > probe with the source ip belonging to the
> > same subnet requesting ip?
>
> Umm, arp_filter?
Hello Chuck,
thanks for the reply.
I have tried to 'echo 1 > /proc/sys/net/ipv4/conf/eth0',
but the 'arp whos-has' behaviour does
Hello list,
I'd like to change behaviour of e1000 module when transmiting short
ethernet frames (shorter then 64 bytes) trough VLAN interface.
Current e1000 (according to our observations) first appends 4 bytes of
VLAN tag and then pads the frame to 64 bytes with zeroes if necessary
before transm
On Fri, Sep 21, 2007 at 09:20:30AM +0800, Zhu Yi wrote:
> > The depends on m for CONFIG_IWL4965 and CONFIG_IWL3945 needs to go,
> > we don't put drivers int that need to be modular.
>
> Since we splited the code base for 3945 and 4965 by a simple "fork" of
> file iwl-base.c, some non-static funct
Chuck Ebbert <[EMAIL PROTECTED]> :
[...]
> Looking again, it may not be r8169's fault, but it is involved. It
Sort of:
[...]
* Hung when moving data off a physical disk in an LVM. Twice during night.
* Hung when adding a disk to a software Raid. Once.
> used to hang and could be restarted by pull
91 matches
Mail list logo
