From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 19 Jul 2006 14:42:35 +0200
> Stefan Rompf wrote:
> > [VLAN]: Fix link state propagation
> >
> > When the queue of the underlying device is stopped at initialization time
> > or the device is marked "not present", the state will be propagated to
Stefan Rompf wrote:
> VLAN devices did not get registered as admin up in 2.6.16 and IMHO also
> not in 2.6.17. So update patch description.
>
> Ok,
>
> the following patch should fix the problem. Patrick, can you give it a
> try? As the bug did not affect me through my testing, I want to be sure
Stefan Rompf wrote:
> the following patch should fix the problem. Patrick, can you give it a
> try? As the bug did not affect me through my testing, I want to be sure it
> works now. This is stuff for 2.6.18 and 2.6.17-stable.
I'm on my way out the door and will be gone for a couple of days,
so it
Ok,
the following patch should fix the problem. Patrick, can you give it a
try? As the bug did not affect me through my testing, I want to be sure it
works now. This is stuff for 2.6.18 and 2.6.17-stable.
Stefan
[VLAN]: Fix link state propagation
When the queue of the underlying device is stop
VLAN devices did not get registered as admin up in 2.6.16 and IMHO also
not in 2.6.17. So update patch description.
Ok,
the following patch should fix the problem. Patrick, can you give it a
try? As the bug did not affect me through my testing, I want to be sure it
works now. This is stuff for 2.
Am Montag, 10. Juli 2006 18:56 schrieb Stephen Hemminger:
> 1. I think vlan code should never be using the state bits directly at all.
> It makes the code error prone if the bits ever change, and it means
> that the proper callbacks are not being done. The existing
> vlan_transfer_operstate does w
Am Montag, 10. Juli 2006 14:01 schrieb Krzysztof Halasa:
> > You've got two independant flags of which one does not stop the queue.
>
> Is it ok to set that flag without synchronization with other flags?
> I.e, from within another module and without using cross-module locks,
> as I've shown at the
Stephen Hemminger wrote:
On Sun, 9 Jul 2006 10:49:31 +0200
Stefan Rompf <[EMAIL PROTECTED]> wrote:
Am Freitag, 7. Juli 2006 23:33 schrieb Stephen Hemminger:
Not really. The flag code last major change was to do the dormant
stuff that HDLC wanted.
... and where the maintainer doesn't seem
On Sun, 9 Jul 2006 10:49:31 +0200
Stefan Rompf <[EMAIL PROTECTED]> wrote:
> Am Freitag, 7. Juli 2006 23:33 schrieb Stephen Hemminger:
>
> > Not really. The flag code last major change was to do the dormant
> > stuff that HDLC wanted.
>
> ... and where the maintainer doesn't seem to care to use i
Stefan Rompf <[EMAIL PROTECTED]> writes:
> You've been asking for two independant flags of which one does not stop the
> queue.
Actually I asked for only one flag which can be set independently of
others, and which would be visible to userspace. I provided a patch
as well. It didn't break anythi
David Miller <[EMAIL PROTECTED]> writes:
>> I'm a single developer BTW.
>
> So am I, and I've been keeping the core networking and the sparc64
> port afloat for more than 10 years.
I was just referring to your use of plural form.
I don't know about you, but I'm doing Linux (and other related) wo
[Trimmed CC list as we're off topic]
Am Sonntag, 9. Juli 2006 22:05 schrieb Krzysztof Halasa:
> >> ... and where the maintainer doesn't seem to care to use it now that the
> >> infrastructure is there. Sigh.
>
> This is very different from what I proposed and doesn't fit very well.
> We've been d
From: Krzysztof Halasa <[EMAIL PROTECTED]>
Date: Sun, 09 Jul 2006 22:05:43 +0200
> I'm a single developer BTW.
So am I, and I've been keeping the core networking and the sparc64
port afloat for more than 10 years.
In comparison, very little is being asked of you.
-
To unsubscribe from this list:
David Miller <[EMAIL PROTECTED]> writes:
>> > Not really. The flag code last major change was to do the dormant
>> > stuff that HDLC wanted.
>>
>> ... and where the maintainer doesn't seem to care to use it now that the
>> infrastructure is there. Sigh.
This is very different from what I propos
From: Stefan Rompf <[EMAIL PROTECTED]>
Date: Sun, 9 Jul 2006 10:49:31 +0200
> Am Freitag, 7. Juli 2006 23:33 schrieb Stephen Hemminger:
>
> > Not really. The flag code last major change was to do the dormant
> > stuff that HDLC wanted.
>
> ... and where the maintainer doesn't seem to care to use
Am Freitag, 7. Juli 2006 23:33 schrieb Stephen Hemminger:
> Not really. The flag code last major change was to do the dormant
> stuff that HDLC wanted.
... and where the maintainer doesn't seem to care to use it now that the
infrastructure is there. Sigh.
> IMHO VLAN device's should mirror the
On Fri, 07 Jul 2006 11:56:28 +0200
Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Stefan Rompf wrote:
> > Am Donnerstag 06 Juli 2006 09:42 schrieb Patrick McHardy:
> >
> >
> >>>I believe this link-state logic was added by someone else. I'm not
> >>>sure exactly what these flags are supposed to do
Stefan Rompf wrote:
> Am Donnerstag 06 Juli 2006 09:42 schrieb Patrick McHardy:
>
>
>>>I believe this link-state logic was added by someone else. I'm not
>>>sure exactly what these flags are supposed to do, so I am not sure if
>>>they should be propagated to the VLAN or not.
>>
>>I looked into t
Am Donnerstag 06 Juli 2006 09:42 schrieb Patrick McHardy:
> > I believe this link-state logic was added by someone else. I'm not
> > sure exactly what these flags are supposed to do, so I am not sure if
> > they should be propagated to the VLAN or not.
>
> I looked into this. The present flag use
Ben Greear wrote:
> Patrick McHardy wrote:
>
>> Stefan Rompf wrote:
>>
>>> Anyway, is it good to propagate __LINK_STATE_PRESENT then? The same
>>> situation here, add a VLAN while the main interface is "not present",
>>> and you are out. Can you try to revert the quoted part of my patch,
>>> I'll
Patrick McHardy wrote:
Stefan Rompf wrote:
Am Dienstag 04 Juli 2006 12:07 schrieb Patrick McHardy:
- new_dev->state = real_dev->state & VLAN_LINK_STATE_MASK;
+ new_dev->state = real_dev->state & ~(1<<__LINK_STATE_START);
This change looks funky because it ignores the link stat
Stefan Rompf wrote:
> Am Dienstag 04 Juli 2006 12:07 schrieb Patrick McHardy:
>
>
>>>-new_dev->state = real_dev->state & VLAN_LINK_STATE_MASK;
>>>+new_dev->state = real_dev->state & ~(1<<__LINK_STATE_START);
>
>
>>This introduced a regression by propagating the __LINK_STATE_XOFF flag,
>
Am Dienstag 04 Juli 2006 12:07 schrieb Patrick McHardy:
> > - new_dev->state = real_dev->state & VLAN_LINK_STATE_MASK;
> > + new_dev->state = real_dev->state & ~(1<<__LINK_STATE_START);
> This introduced a regression by propagating the __LINK_STATE_XOFF flag,
> when the queue of the underlyin
; Tue, 21 Mar 2006 09:11:41 -0800
>
> [VLAN]: translate IF_OPER_DORMANT to netif_dormant_on()
>
> diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
> index fa76220..3948949 100644
> --- a/net/8021q/vlan.c
> +++ b/net/8021q/vlan.c
> @@ -69,7 +69,7 @@ static struct packet_type vla
From: Stefan Rompf <[EMAIL PROTECTED]>
Date: Thu, 8 Dec 2005 00:19:56 +0100
> this patch adds support to the VLAN driver to translate IF_OPER_DORMANT of
> the
> underlying device to netif_dormant_on(). Beside clean state forwarding, this
> allows running independant userspace supplicants on bot
Hi David,
this patch adds support to the VLAN driver to translate IF_OPER_DORMANT of the
underlying device to netif_dormant_on(). Beside clean state forwarding, this
allows running independant userspace supplicants on both the real device and
the stacked VLAN. It depends on my RFC2863 patch.
P
26 matches
Mail list logo
