On Mon, 04 Jun 2007 14:00:56 -0400 [EMAIL PROTECTED] wrote:
> On Wed, 30 May 2007 23:58:23 PDT, Andrew Morton said:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
>
> Under 22-rc2-mm1, if my VPN connection got reset, ppp0 just quietly went away.
>
>
From: Miklos Szeredi <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 07:26:52 +0200
> > Holding a global mutex over recvmsg() calls under AF_UNIX is pretty
> > much a non-starter, this will kill performance for multi-threaded
> > apps.
>
> That's an rwsem held for read. It's held for write in unix_gc
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> > Date: Mon, 04 Jun 2007 11:45:32 +0200
> >
> > > > A recv() on an AF_UNIX, SOCK_STREAM socket can race with a
> > > > send()+close() on the peer, causing recv() to return zero, even though
> > > > the sent data should be received.
> > > >
> > > > Th
Hi,
Following on from a previous (now lost :-)) posting, I have been trying
to send out IPv6 packets from a kernel module using the kern_sendmsg()
function. Since in theory I need this function to be started in
interrupt context (actually, softirq context), but since this is
impossible because
On 6/6/07, David Miller <[EMAIL PROTECTED]> wrote:
From: Randy Dunlap <[EMAIL PROTECTED]>
Date: Tue, 5 Jun 2007 18:01:41 -0700
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> gcc doesn't like the location of the __attribute__ string here:
> net/ipv4/tcp_probe.c:83: warning: empty declaration
>
> so
Kok, Auke wrote:
Milton Miller wrote:
On Jun 5, 2007, at 12:43 PM, Kok, Auke wrote:
Jeff Garzik wrote:
On Tue, Jun 05, 2007 at 10:27:19AM -0700, Kok, Auke wrote:
We need to make sure that now that we're getting closer to 2.6.22 we
don't end up killing e100 in it. Should we drop the current f
From: Randy Dunlap <[EMAIL PROTECTED]>
Date: Tue, 5 Jun 2007 18:01:41 -0700
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> gcc doesn't like the location of the __attribute__ string here:
> net/ipv4/tcp_probe.c:83: warning: empty declaration
>
> so move it to before the function and all is well.
>
From: Randy Dunlap <[EMAIL PROTECTED]>
gcc doesn't like the location of the __attribute__ string here:
net/ipv4/tcp_probe.c:83: warning: empty declaration
so move it to before the function and all is well.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
net/ipv4/tcp_probe.c |3 ++-
1 fi
Reading through the patches they look usable to me.
Having to patch iproute to create the more interesting network
devices sucks, but that problem seems fundamental. We might
be able to avoid it if we allowed fields to be reused between
different types of devices but that makes the error checkin
From: David Miller <[EMAIL PROTECTED]>
Date: Tue, 05 Jun 2007 00:02:47 -0700 (PDT)
> From: Miklos Szeredi <[EMAIL PROTECTED]>
> Date: Mon, 04 Jun 2007 11:45:32 +0200
>
> > > A recv() on an AF_UNIX, SOCK_STREAM socket can race with a
> > > send()+close() on the peer, causing recv() to return zero,
Jesse Huang <[EMAIL PROTECTED]> writes:
Hi Jesse,
> - for (phy = 1; phy <= 32 && phy_idx < MII_CNT; phy++) {
> + if(sundance_pci_tbl[np->chip_id].device == 0x0200)
> + phy = 0;
> + else
> + phy = 1;
> + for (; phy <= 32 && phy_idx < MII_CNT; phy++) {
I t
On Tue, Jun 05, 2007 at 04:33:12PM -0700, Kok, Auke wrote:
> Jeff, please `git-revert d52df4a35af569071fda3f4eb08e47cc7023f094` to
> revert the following patch for now:
Can you do me one more favor, and write a short paragraph describing why
it is getting reverted, to paste into the commit messag
From: Chris Wright <[EMAIL PROTECTED]>
Date: Tue, 5 Jun 2007 16:36:16 -0700
> Rather than reverting that patch, applying this patch should fix
> your ipv6 issue:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=7ebba6d14f8d63cad583bf1cc0330b601d5a8171
>
>
* Simon Arlott ([EMAIL PROTECTED]) wrote:
> Adding a ::/0 route doesn't work:
> # ip -6 r a ::/0 via fe80::230:18ff:feb0:25c2 dev eth0
> # ping6 -c 1 2001:4b10:1005:0:205:b4ff:fe12:530
> connect: Network is unreachable
>
> A route assigned by addrconf works.
>
> Reverting this patch from 2.6.22-r
Milton Miller wrote:
On Jun 5, 2007, at 12:43 PM, Kok, Auke wrote:
Jeff Garzik wrote:
On Tue, Jun 05, 2007 at 10:27:19AM -0700, Kok, Auke wrote:
We need to make sure that now that we're getting closer to 2.6.22 we
don't end up killing e100 in it. Should we drop the current fixes in
it to be
On Wed, 06 Jun 2007 01:17:11 +0200
Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > On Tue, 5 Jun 2007 16:12:57 +0200 (MEST)
> > Patrick McHardy <[EMAIL PROTECTED]> wrote:
> >
> >
> >>[RTNETLINK]: Link creation API
> >>
> >>Add rtnetlink API for creating, changing and d
On Tue, 05 Jun 2007 13:12:03 -0700
James Ketrenos <[EMAIL PROTECTED]> wrote:
> John W. Linville wrote:
> > On Tue, Jun 05, 2007 at 02:06:14AM -0700, Andrew Morton wrote:
> >
> >> Please, don't anybody dare think about thinking about letting this anywhere
> >> near mainline until it has had a thor
Stephen Hemminger wrote:
> On Tue, 5 Jun 2007 16:12:57 +0200 (MEST)
> Patrick McHardy <[EMAIL PROTECTED]> wrote:
>
>
>>[RTNETLINK]: Link creation API
>>
>>Add rtnetlink API for creating, changing and deleting software devices.
>>
>>Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
>>
>
> If yo
From: Michal Piotrowski <[EMAIL PROTECTED]>
Date: Tue, 05 Jun 2007 16:54:28 +0200
> Networking
>
> Subject: OOPS iproute2/tc/u32_destroy in 2.6.22-rc3-git6
> References : http://lkml.org/lkml/2007/6/3/66
> Submitter : Strobl Anton <[EMAIL PROTECTED]>
> Handled-By : Patrick McHardy <[EMAIL PR
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Wed, 6 Jun 2007 00:54:53 +0200
> When changing the link state from userspace not affecting any other
> flags. Two duplicate notification are being sent, once as action
> in the NETDEV_UP/NETDEV_DOWN notification chain and a second time
> when comparing o
From: David Miller <[EMAIL PROTECTED]>
Date: Tue, 05 Jun 2007 13:37:17 -0700 (PDT)
> From: Eric Dumazet <[EMAIL PROTECTED]>
> Date: Tue, 05 Jun 2007 22:22:36 +0200
>
> > David Miller a écrit :
> > > Does checking for INADDR_ANY sockets really require a full scan?
> > > It should just need two has
When changing the link state from userspace not affecting any other
flags. Two duplicate notification are being sent, once as action
in the NETDEV_UP/NETDEV_DOWN notification chain and a second time
when comparing old and new device flags after the change has been
completed. Although harmless, the
On Wed, 2007-06-06 at 00:07 +0200, Patrick McHardy wrote:
> How about IFLA_INFO_KIND (borrowed from sch_api)? I generally don't
> like the IFLA_INFO_ prefix very much, but so far didn't come up with
> something better. Suggestions welcome :)
KIND sounds a lot more tasty ;-> Thanks.
cheers,
jamal
On Tue, 2007-05-06 at 08:51 -0700, Waskiewicz Jr, Peter P wrote:
> No, we don't have subqueue semantics going directly to the hardware
> subqueues. Only in software.
Yes, that is one thing i was speaking against.
> sch_rr gives a qdisc without a strict scheduling policy for people that
> either
On Tue, 5 Jun 2007 16:12:57 +0200 (MEST)
Patrick McHardy <[EMAIL PROTECTED]> wrote:
> [RTNETLINK]: Link creation API
>
> Add rtnetlink API for creating, changing and deleting software devices.
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
>
If you want I'll extend existing bridge net
John W. Linville wrote:
On Tue, Jun 05, 2007 at 02:06:14AM -0700, Andrew Morton wrote:
Please, don't anybody dare think about thinking about letting this anywhere
near mainline until it has had a thorough review. Or at least, a little bit
of review.
Don't worry -- I assure you that everyone
jamal wrote:
> All patches looked really good. speaking for the ifb stuff, a definete
> ACK.
> The only thing that threw me off for a sec was the naming convention for
> "type" referenced via IFLA_INFO_NAME because it seems to be colliding
> semantic with dev->type and dev->name as in IFLA_NAME an
Patrick McHardy wrote:
Ben Greear wrote:
Patrick McHardy wrote:
[VLAN]: Use rtnl_link API
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
+static int vlan_newlink(struct net_device *dev,
+struct nlattr *tb[], struct nlattr *data[])
+{
+struct vlan_dev_info *vlan = VLAN_D
All patches looked really good. speaking for the ifb stuff, a definete
ACK.
The only thing that threw me off for a sec was the naming convention for
"type" referenced via IFLA_INFO_NAME because it seems to be colliding
semantic with dev->type and dev->name as in IFLA_NAME and
ifi_type ifinfomsg
Ben Greear wrote:
> Patrick McHardy wrote:
>
>> [VLAN]: Use rtnl_link API
>>
>> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
>
>
>> +static int vlan_newlink(struct net_device *dev,
>> +struct nlattr *tb[], struct nlattr *data[])
>> +{
>> +struct vlan_dev_info *vlan = VLAN_D
Patrick McHardy wrote:
[VLAN]: Use rtnl_link API
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
+static int vlan_newlink(struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
+{
+ struct vlan_dev_info *vlan = VLAN_DEV_INFO(dev);
+ int err;
Ben Greear wrote:
> Patrick McHardy wrote:
>
>> Ben Greear wrote:
>>
>>> Patrick McHardy wrote:
>>>
The last VLAN patchset was outdated, sorry about the mixup. These
are the
correct patches. The iproute patch I posted was correct, so no
repost of
that one.
>>>
David Miller wrote:
> From: Patrick McHardy <[EMAIL PROTECTED]>
> Date: Tue, 5 Jun 2007 16:12:51 +0200 (MEST)
>
>
>>A few words about the API:
>>
>>[..]
>>
>>Not sure what else to say .. comments welcome.
>
>
> This excellent description of the APIs (particularly the background
> and reasoning
David Miller wrote:
> From: Patrick McHardy <[EMAIL PROTECTED]>
> Date: Tue, 5 Jun 2007 16:12:57 +0200 (MEST)
>
>>[RTNETLINK]: Link creation API
>>
>>Add rtnetlink API for creating, changing and deleting software devices.
>>
>>Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
>
>
> Looks mostl
Paolo Galtieri wrote:
> Vlad,
> I'm looking for something that exercises the SCTP stack. Something
> that can be run against different kernel versions for comparing features
> and regression testing.
>
lksctp-tools git repo is a good start. There 2 different sets of test:
1. Frame tests in
Vlad Yasevich wrote:
Paolo Galtieri wrote:
Vlad,
what test suite exists for SCTP? The lksctp-tools code hasn't been
updated since Feb of 2006, and I was wondering whether this version is
still the most useful.
Thanks
Hi Paolo
I have a lksctp-tools tree on git.kernel.org that's up t
Kacper Bielecki <[EMAIL PROTECTED]> :
[...]
> The motherboadr is ASRock ConRoe945G-DVI
Same model as my current test machine.
It uses a boring el-cheapo PIV though.
> After installing kernel 2.6.22-rc4 with patches 0001..0013 (there wasn't
> patch) the problem is not solved. I still get th
Paolo Galtieri wrote:
> Vlad,
> what test suite exists for SCTP? The lksctp-tools code hasn't been
> updated since Feb of 2006, and I was wondering whether this version is
> still the most useful.
>
> Thanks
Hi Paolo
I have a lksctp-tools tree on git.kernel.org that's up to date. We'll need
t
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 05 Jun 2007 22:22:36 +0200
> David Miller a écrit :
> > Does checking for INADDR_ANY sockets really require a full scan?
> > It should just need two hash probes as far as I can tell to see
> > if there is "0.0.0.0:PORT" bound already.
>
> Well, we
Vlad,
what test suite exists for SCTP? The lksctp-tools code hasn't been
updated since Feb of 2006, and I was wondering whether this version is
still the most useful.
Thanks
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More
David Miller a écrit :
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 5 Jun 2007 19:15:36 +0200
I discovered one big problem with UDP binding in 2.6.22-rc4 :
Thanks for finding this problem, the crux of the issue is
INADDR_ANY.
Well, I feel guilty as I was initial patch submiter :(
We
From: Miklos Szeredi <[EMAIL PROTECTED]>
Date: Tue, 05 Jun 2007 09:42:41 +0200
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> A recv() on an AF_UNIX, SOCK_STREAM socket can race with a
> send()+close() on the peer, causing recv() to return zero, even though
> the sent data should be received.
>
Patrick McHardy wrote:
Ben Greear wrote:
Patrick McHardy wrote:
The last VLAN patchset was outdated, sorry about the mixup. These are the
correct patches. The iproute patch I posted was correct, so no repost of
that one.
Is there any significant performance penalty in creating VLANs using
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 5 Jun 2007 19:15:36 +0200
> I discovered one big problem with UDP binding in 2.6.22-rc4 :
Thanks for finding this problem, the crux of the issue is
INADDR_ANY.
> We really should check no socket is bound to XXX.XXX.XXX.XXX:32769. With
> current
> Can you try 2.6.22-rc3 (or -rc4) + patches ..0013 from
> http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc3/r8169-20070527
After installing kernel 2.6.22-rc4 with patches 0001..0013 (there wasn't
patch) the problem is not solved. I still get the same behaviour.
-
To unsubscribe
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 5 Jun 2007 16:13:02 +0200 (MEST)
> [DUMMY]: Use rtnl_link API
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
This looks good too.
I'll let folks like Jamal and Ben look over the IFB and
VLAN bits.
Thanks for doing this work Patrick!
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 5 Jun 2007 16:13:00 +0200 (MEST)
> [DUMMY]: Keep dummy devices on list
>
> Use a list instead of an array to allow creating new devices.
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Looks good.
-
To unsubscribe from this list: send
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 5 Jun 2007 16:12:57 +0200 (MEST)
> [RTNETLINK]: Link creation API
>
> Add rtnetlink API for creating, changing and deleting software devices.
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Looks mostly fine, perhaps you can make even
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 5 Jun 2007 16:12:59 +0200 (MEST)
> [DUMMY]: Use dev->stats
>
> Use dev->stats instead of netdev_priv().
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Looks good.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 5 Jun 2007 16:12:54 +0200 (MEST)
> [RTNETLINK]: ifindex 0 does not exist
>
> ifindex == 0 does not exist and implies we should do a lookup by name if
> one was given.
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
This one is also mo
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 5 Jun 2007 16:12:55 +0200 (MEST)
> [RTNETLINK]: Split up rtnl_setlink
>
> Split up rtnl_setlink into a function performing validation and a function
> performing the actual changes. This allows to share the modifcation logic
> with rtnl_newlin
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 5 Jun 2007 16:12:52 +0200 (MEST)
> [NETLINK]: Mark netlink policies const
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
This one looks good enough for 2.6.22, as I consider more
accurate typing a way to prevent and find bugs.
So I'l
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 5 Jun 2007 16:12:51 +0200 (MEST)
> A few words about the API:
>
> Drivers wishing to use the API register a struct rtnl_link_ops, which
> contains a few function pointers for device setup, registation, changing
> and deletion, as well as netli
> Your suggestion, to utilize NET_XMIT_* code returned from an
> underlying layer, is done in tcp_transmit_skb.
>
> But my problem is that tcp_transmit_skb is not called during a
> certain period of time. So I'm suggesting to cap RTO value so
> that tcp_transmit_skb gets called more frequently.
Ben Greear wrote:
> Patrick McHardy wrote:
>
>> The last VLAN patchset was outdated, sorry about the mixup. These are the
>> correct patches. The iproute patch I posted was correct, so no repost of
>> that one.
>>
>>
>
> Is there any significant performance penalty in creating VLANs using
> th
Ben Greear wrote:
> Patrick McHardy wrote:
>
>> [VLAN]: Fix off-by-ones in VLAN ID checks
>>
>> The valid range of VLAN IDs is 0-4095, fix using ID 4095.
>>
>
> Per http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf
> page 69
>
> 0xFFF is reserved for future use, so we should not b
On Mon, 2007-06-04 at 15:44 -0400, James Morris wrote:
> On Mon, 4 Jun 2007, Eric Paris wrote:
>
> > Some time ago this thread bounced back and forth and seemed to come to
> > rest with the patch below, I cleaned up the comments and put all the
> > ACKs it received in one place below, but so much
On Jun 5, 2007, at 12:43 PM, Kok, Auke wrote:
Jeff Garzik wrote:
On Tue, Jun 05, 2007 at 10:27:19AM -0700, Kok, Auke wrote:
We need to make sure that now that we're getting closer to 2.6.22 we
don't end up killing e100 in it. Should we drop the current fixes in
it to be on the safe side and
Jeff Garzik wrote:
On Tue, Jun 05, 2007 at 10:27:19AM -0700, Kok, Auke wrote:
We need to make sure that now that we're getting closer to 2.6.22 we don't
end up killing e100 in it. Should we drop the current fixes in it to be on
the safe side and aim for 2.6.23? I would hate to see an untested c
Jeff Garzik wrote:
On Tue, Jun 05, 2007 at 10:27:19AM -0700, Kok, Auke wrote:
We need to make sure that now that we're getting closer to 2.6.22 we don't
end up killing e100 in it. Should we drop the current fixes in it to be on
the safe side and aim for 2.6.23? I would hate to see an untested c
chris schlund wrote:
Using read() on a socket(AF_INET, SOCK_STREAM) connected via any network
interface (e.g eth0) and putting this interface down (ifconfig) while
the socket is in read() produces a hanger (the read() will not return
anymore).
Even if I install sigaction signal handler I got no s
On Tue, Jun 05, 2007 at 10:27:19AM -0700, Kok, Auke wrote:
> We need to make sure that now that we're getting closer to 2.6.22 we don't
> end up killing e100 in it. Should we drop the current fixes in it to be on
> the safe side and aim for 2.6.23? I would hate to see an untested codepath
> brea
Milton Miller wrote:
First, a question especially to Auke and Jeff:
Since this patch both reverts the broken change that is currently in
-rc and creates the fixed driver, I'm not sure I like the subject
stating "on ARM", although that is the feature of the rewrite, and was
the intent of mergi
On Tue, 5 Jun 2007 10:56:58 -0400 Sam Hopkins wrote:
> Hello,
>
> I'm forwarding along a message sent to kernelnewbies as I was directed
> to address my question to this list. I am not a member of netdev, so
> please copy me on all discussion of this topic.
>
> Cheers,
>
> Sam
>
> ---
>
> Gr
David
I discovered one big problem with UDP binding in 2.6.22-rc4 :
Consider you have eth0 with addr 192.168.0.1
Consider one UDP socket was bound to 192.168.0.1:32769. It will be stored on a
slot != 1
Another UDP socket is created and binded to (0.0.0.0:0)
__udp_lib_get_port() is called with
Divy Le Ray wrote:
Divy Le Ray wrote:
Hi Jeff,
I'm submitting a set of bug fixes for inclusion in 2.6.22.
The patches are built against Linus'git tree.
The mail title was incomplete. sorry about that.
Cheers,
Divy
Hi Jeff,
Did you get a chance to review the series I posted for driver fi
> Can you try 2.6.22-rc3 (or -rc4) + patches ..0013 from
> http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc3/r8169-20070527
>
> Which motherboard is it ?
>
> Please Cc: netdev@vger.kernel.org
The motherboadr is ASRock ConRoe945G-DVI
I will get you know when I try new kernel.
-
To unsubscr
Patrick McHardy wrote:
The last VLAN patchset was outdated, sorry about the mixup. These are the
correct patches. The iproute patch I posted was correct, so no repost of
that one.
Is there any significant performance penalty in creating VLANs using
these patches?
If you have a test station
Patrick McHardy wrote:
[VLAN]: Fix off-by-ones in VLAN ID checks
The valid range of VLAN IDs is 0-4095, fix using ID 4095.
Per http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf
page 69
0xFFF is reserved for future use, so we should not be using VLANs with
that VID.
Thanks,
Be
First, a question especially to Auke and Jeff:
Since this patch both reverts the broken change that is currently in
-rc and creates the fixed driver, I'm not sure I like the subject
stating "on ARM", although that is the feature of the rewrite, and was
the intent of merging the previous patch
On Jun 5, 2007, at 8:34 AM, David Acker wrote:
Milton Miller wrote:
On Jun 1, 2007, at 3:45 PM, David Acker wrote:
Ok, I took a stab at coding and testing these ideas. Below is a
patch against 2.6.22-rc3.
Let me know what you think.
I think you got most of the ideas. As Auke noted, your cod
>From a high level i see a good start that you at least have
> a separate
> qdisc. I dont see the need for making any subqueue semantics
> in the qdisc. We already have them.
No, we don't have subqueue semantics going directly to the hardware
subqueues. Only in software.
> I also still dont se
Andrew Morton wrote:
I was doing some suspend-to-ram testing on the Vaio with the 2.6.22-rc3-mm1
lineup. After 10 or 15 cycles a resume failed:
[ 357.119436] Suspending device full
[ 357.120450] Suspending device zero
[ 358.084978] Suspending device port
[ 358.085664] Suspending device null
On Tue, 2007-06-05 at 16:54 +0200, Michal Piotrowski wrote:
> File systems
>
> Subject: JFFS2 issues
> References :
> http://lists.infradead.org/pipermail/linux-mtd/2007-May/018426.html
> Submitter : Haavard Skinnemoen <[EMAIL PROTECTED]>
> Caused-By : commit 10731f83009e2556f98ffa5c7c2cbff
Using read() on a socket(AF_INET, SOCK_STREAM) connected via any network
interface (e.g eth0) and putting this interface down (ifconfig) while
the socket is in read() produces a hanger (the read() will not return
anymore).
Even if I install sigaction signal handler I got no signal when the
interfac
Hello,
I'm forwarding along a message sent to kernelnewbies as I was directed
to address my question to this list. I am not a member of netdev, so
please copy me on all discussion of this topic.
Cheers,
Sam
---
Greetings,
I am a developer of the kernel AoE (ATA over Ethernet) driver. I am
Hi all,
Here is a list of some known regressions in 2.6.22-rc4
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
Block devices
Subject: loop devices limited to one single device
References : http://lkml.org/lkml/2007/5/1
On Tue, Jun 05, 2007 at 06:31:31PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> [ 263.936418] RIP [] skb_splice_bits+0xac/0x1c9
> [ 263.942516] RSP
>
> This a vm_bug_on in get_page().
>
> > +static inline int spd_fill_page(struct splice_pipe_desc *spd, struct page
> > *page,
>
Hi all,
Here is a list of some known regressions in 2.6.22-rc4.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
Networking
Subject: list_add corruption. prev->next should be next (f7d28794), but was
f0df8ed4 (prev=f0df8ed4) Kernel Bug at lib
[VLAN]: Keep track of number of QoS mappings
Keep track of the number of configured ingress/egress QoS mappings to
avoid iteration while calculating the netlink attribute size.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit e38a7f02fcf29d44a81cb1e697f7381a8764c28d
tree 2e24e2b1421
[VLAN]: Use rtnl_link API
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 0c8500625d51c2a0c38404d941ab925c23c972b3
tree 9fbf7296bb873dc918d6865aa4437a9dfaf53237
parent e38a7f02fcf29d44a81cb1e697f7381a8764c28d
author Patrick McHardy <[EMAIL PROTECTED]> Tue, 05 Jun 2007 16:33:45 +0200
[VLAN]: Move device registation to seperate function
Move device registration and configuration of the underlying device to a
seperate function.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 312dc0ee04bed170ad8091f777fcc2108105ca2c
tree 34a83935bc1bfbac67cc50dc83bbdf67645dcc0d
pa
[VLAN]: Return proper error codes in register_vlan_device
The returned device is unused, return proper error codes instead and avoid
having the ioctl handler guess the error.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit f2eb0828c4cfaf4d4aed225b55ca65b052109657
tree 967dc78c7ed89
[VLAN]: Use 32 bit value for skb->priority mapping
skb->priority has only 32 bits and even VLAN uses 32 bit values in its API.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 3151f6fdca072a91c2184192dc1d431a4d9248b7
tree 21f76dd1682e385f7d958d5d5ebb66c3585ed2ca
parent f2eb0828c4cfa
[VLAN]: Move vlan_group allocation to seperate function
Move group allocation to a seperate function to clean up the code a bit
and allocate groups before registering the device. Device registration
is globally visible and causes netlink events, so we shouldn't fail
afterwards.
Signed-off-by: Pat
[VLAN]: Split up device checks
Move the checks of the underlying device to a seperate function.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 2d952c2f38391a43f380028a42106ee8880574be
tree e877b367527691ea5abc0342bf5212fa1e97205d
parent 77fa17d4f74fcc3a330b95023fc335713eba995a
aut
[VLAN]: Convert name-based configuration functions to struct netdevice *
Move the device lookup and checks to the ioctl handler under the RTNL and
change all name-based interfaces to take a struct net_device * instead.
This allows to use them from a netlink interface, which identifies devices
bas
[VLAN]: Move some device intialization code to dev->init callback
Move some device initialization code to new dev->init callback to make
it shareable with netlink. Additionally this fixes a minor bug, dev->iflink
is set after registration, which causes an incorrect value in the initial
netlink mes
The last VLAN patchset was outdated, sorry about the mixup. These are the
correct patches. The iproute patch I posted was correct, so no repost of
that one.
include/linux/if_link.h | 25 ++
include/linux/if_vlan.h |7
net/8021q/Makefile |2
net/8021q/vlan.c | 537 +++
[VLAN]: Fix off-by-ones in VLAN ID checks
The valid range of VLAN IDs is 0-4095, fix using ID 4095.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 576d73325b7ce3d454c544dcdfea0a2e3ae6486e
tree 2039651421302cf1863cd4b70f502d18a04bc7ac
parent 6a0492fd68c8c5f528e4277bec20bef8047aec2e
Patrick McHardy wrote:
> These patches convert VLAN to the rtnl_link API as a more complex example.
> The patches need some more work, not all VLAN features are supported yet.
Unfortunately I managed to send the wrong patchset :(
Please ignore (only the VLAN kernel patches), new patches
coming up
On Tue, Jun 05, 2007 at 10:05:43AM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote:
> Here's an implementation of tcp network splice receive support. It's
> originally based on the patch set that Intel posted some time ago, but
> has been (close to) 100% reworked.
>
> Now, I'm not a networking guru by
This patch contains the iproute changes needed for VLAN configuration.
Examples:
Add VLAN device:
# ip link add dev eth0.1000 link eth0 type vlan \
id 1000 \
egress-qos-map 1:2 2:3 \
ingress-qos-map 2:1 3:2
Show new device:
# ip link list eth0.1000
9: [EMAIL PROTECTED]
[VLAN]: Keep track of number of QoS mappings
Keep track of the number of configured ingress/egress QoS mappings to
avoid iteration while calculating the netlink attribute size.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit fba4579d0d3c365f1ff5473e905dac68c5ec62f3
tree 892fa4a95ab
[VLAN]: Use rtnl_link API
---
commit 6e11b791711627a87abfe1bd8c21a4f4d369bca6
tree 5fbe3c1ff51dd87c80748b2793878c076ed57ed7
parent fba4579d0d3c365f1ff5473e905dac68c5ec62f3
author Patrick McHardy <[EMAIL PROTECTED]> Tue, 29 May 2007 17:53:18 +0200
committer Patrick McHardy <[EMAIL PROTECTED]> Tue,
[VLAN]: Split up device creation
Split up device creation in allocation/registration functions taking
struct net_device * and a small wrapper for the ioctl handling. This is
needed by the netlink interface to properly set up the device before
registration.
Signed-off-by: Patrick McHardy <[EMAIL P
[VLAN]: Use 32 bit value for skb->priority mapping
skb->priority has only 32 bits and even VLAN uses 32 bit values in its
API.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 24b7a56049e5e9f63e6fc5933d10b47c15294fea
tree 7c1d37c5c3b9f09c3c7d726d6fa922454d57bf16
parent c59e99d32d808
[VLAN]: Add device init callback
Move device initialization to ->init callback to fix an incorrect iflink
value in the initial NEWLINK message. Additionally this makes sure the
lockdep class is properly set before the device will be used.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
co
[VLAN]: Move vlan_group allocation to seperate function
Move group allocation to a seperate function to clean up the code a bit
and allocate groups before registering the device. Device registration
is globally visible and causes netlink events, so we shouldn't fail
afterwards.
Signed-off-by: Pat
[VLAN]: Move device lookup to ioctl handler
Move the device lookup and checks to the ioctl handler under the RTNL and
change all name-based interfaces to take a struct net_device * instead.
This allows to use them from a netlink interface, which identifies devices
based on ifindex not name. It al
1 - 100 of 139 matches
Mail list logo
