Hi,
why is a there a experimental VLAN option in the stable 2.4.x-kernel, when it's useless without patching Network Drivers?
Why isn't there a solution for all network drivers to accept frames 4 bytes longer on request of e.g. vconfig (like ifconfig setting promiscious mode on/off) ? Or to deny vconfig to add a vlan, if the network driver/hardware doesn't support this?
Today the situation is as follows: The experimental VLAN-option is useless, if i dont patch my network drivers, otherwise there is no working VLAN function.
Any future plans?
From: [email protected]
Date: Wed, 24 Apr 2002 15:09:09
why is a there a experimental VLAN option in the stable
2.4.x-kernel, when it's useless without patching Network Drivers?
It is not useless for the drivers that have been fixed.
Why isn't there a solution for all network drivers to accept frames
4 bytes longer on request of e.g. vconfig (like ifconfig setting
promiscious mode on/off) ? Or to deny vconfig to add a vlan, if the
network driver/hardware doesn't support this?
Because the solutions are hardware specific to allow these extra
4 bytes to be received by the card. Some cards, in fact, cannot
support VLAN at all because they cannot be programmed at all to
take those 4 extra bytes.
Today the situation is as follows: The experimental VLAN-option is
useless, if i dont patch my network drivers, otherwise there is no
working VLAN function.
No it isn't useless. There are many network drivers for which VLAN
works out of the box RIGHT NOW. In fact, many of which support full
hardware acceleration of VLAN tagging, for instance Tigon3 is one
such device.
Some drivers work, more are being fixed. Others have to be
patched. All work if you set the MTU of the link to 1496.
We can use testing of patched drivers, so if you do patch any
and have good results, then let us know and the driver changes might
get pushed into the kernel sooner.
Ben
[email protected] wrote:
> Hi,
>
> why is a there a experimental VLAN option in the stable 2.4.x-kernel, when it's useless without patching Network Drivers?
>
> Why isn't there a solution for all network drivers to accept frames 4 bytes longer on request of e.g. vconfig (like ifconfig setting promiscious mode on/off) ? Or to deny vconfig to add a vlan, if the network driver/hardware doesn't support this?
>
> Today the situation is as follows: The experimental VLAN-option is useless, if i dont patch my network drivers, otherwise there is no working VLAN function.
>
> Any future plans?
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
> Von: <[email protected]>
> Gesendet: 24.04.2002 16:11
>
> 2.4.x-kernel, when it's useless without patching Network Drivers?
> It is not useless for the drivers that have been fixed.
Ok, but i have a stock 2.4.18 kernel, i can enable the VLAN option, recompile the kernel, configure a VLAN without any error or hint.
BUT: If i try to do ftp or ping with a payload greater than 1468 my tulipbased ZNYX 346Q ethernetcards drop those packets. The driver or the card cannot handle those packets. They are to large. Maybe a driverpatch solve my problem - maybe not. The kernel itself doesn't care. vconfig doesn't barf. It silently fails.. not so good behaviour in my opinion. This is why there are always the same questions on the vlan mailinglist.
> Because the solutions are hardware specific to allow these extra
> 4 bytes to be received by the card. Some cards, in fact, cannot
> support VLAN at all because they cannot be programmed at all to
> take those 4 extra bytes.
Ok. But why isn't there a "tag" (capabilities?) on the drivers which let vconfig barf with a message like "underlying network driver or hardware doesn't support VLAN"?
> No it isn't useless. There are many network drivers for which VLAN
> works out of the box RIGHT NOW.
Ok. But i don't get a message about the drivers which don't work. Which driver work/which not? Isn't it easier to tag all drivers as not VLAN-ready till somebody make a patch or confirm that its working with VLAN?
On the other side, my ZNYX works "out of the box" too. It works till 1468 Bytes ;) - I tend to say that ALL nic-drivers/hardware work till 1468 Bytes. But its not the intention of VLAN to lower the MTU on each Client.
On Wed, 24 Apr 2002 [email protected] wrote:
> > Von: <[email protected]>
> > Gesendet: 24.04.2002 16:11
> >
> > 2.4.x-kernel, when it's useless without patching Network Drivers?
> > It is not useless for the drivers that have been fixed.
>
> Ok, but i have a stock 2.4.18 kernel, i can enable the VLAN option, recompile the kernel, configure a VLAN without any error or hint.
>
> BUT: If i try to do ftp or ping with a payload greater than 1468 my
> tulipbased ZNYX 346Q ethernetcards drop those packets. The driver or the
> card cannot handle those packets. They are to large. Maybe a driverpatch
> solve my problem - maybe not. The kernel itself doesn't care. vconfig
> doesn't barf. It silently fails.. not so good behaviour in my opinion.
> This is why there are always the same questions on the vlan mailinglist.
>
See linux-kernel archives.. some time ago Paul P Komkoff Jr <[email protected]>
posted a patch for tulip to make VLANs work.. the subject of the post was
something like "tulip and VLAN tagging".
> > Because the solutions are hardware specific to allow these extra
> > 4 bytes to be received by the card. Some cards, in fact, cannot
> > support VLAN at all because they cannot be programmed at all to
> > take those 4 extra bytes.
>
> Ok. But why isn't there a "tag" (capabilities?) on the drivers which let vconfig barf with a message like "underlying network driver or hardware doesn't support VLAN"?
>
> > No it isn't useless. There are many network drivers for which VLAN
> > works out of the box RIGHT NOW.
>
> Ok. But i don't get a message about the drivers which don't work. Which driver work/which not? Isn't it easier to tag all drivers as not VLAN-ready till somebody make a patch or confirm that its working with VLAN?
>
> On the other side, my ZNYX works "out of the box" too. It works till 1468 Bytes ;) - I tend to say that ALL nic-drivers/hardware work till 1468 Bytes. But its not the intention of VLAN to lower the MTU on each Client.
>
- Pasi K?rkk?inen
^
. .
Linux
/ - \
Choice.of.the
.Next.Generation.
From: [email protected]
Date: Wed, 24 Apr 2002 18:23:35 +0200
Ok. But why isn't there a "tag" (capabilities?) on the drivers
which let vconfig barf with a message like "underlying network
driver or hardware doesn't support VLAN"?
There actually is a flag the driver can set fo this purpose.
Someone should walk over all the drivers that are known to not
work currently with VLAN and for them to set the
NETIF_F_VLAN_CHALLENGED flag.
Another idea, is to do the opposite, set that flag by default and
clear it in drivers that we know it works.
> Von: <[email protected]>
> Gesendet: 24.04.2002 18:20
> Some drivers work, more are being fixed. Others have to be
> patched. All work if you set the MTU of the link to 1496.
I made some tests with Windows2000. I have to set the MTU manually (in the registry) to 1496 to get all working. Thats ok for a few clients, but not for many.
> We can use testing of patched drivers, so if you do patch any
> and have good results, then let us know and the driver changes might
> get pushed into the kernel sooner.
I don't use a kernel driver, i use a driver from a manufacturer. ZNYX provides some with Source, but i'm not the nic-register-voodoo-man to allow this driver to receive larger frames. I just changed some defines, but this doesn't work.
I use the ZNYX driver cause i didn't got Jeffs Tulip driver to work correctly with my card (346Q). Maybe the tulip driver works better now, but this is not the point.
The point is that i get no information if VLAN works with a nic/driver (including third party drivers) without MTU limitations.
There should really be a flag, a tag or a capability thing in the driver which says "VLAN not possible", when vconfig tries to add a VLAN. So if i get a third party driver, vconfig would report if i can use it or not.
Today i have to test it with every nic/driver - not so nice. But think of others, who are not so involved in networking things, they setup a vlan like you (and e.g. Cisco or 3COM) described and get problems with ftp, large pings, etc. pp.
> Von: <[email protected]>
> Gesendet: 24.04.2002 18:45
>
> There actually is a flag the driver can set fo this purpose.
Oh. Even in 2.4 ?
> Someone should walk over all the drivers that are known to not
> work currently with VLAN and for them to set the
> NETIF_F_VLAN_CHALLENGED flag.
That's a good idea. So vconfig could check, if its possible to create a VLAN on top of such a driver - and issue a message if not.
> Another idea, is to do the opposite, set that flag by default and
> clear it in drivers that we know it works.
It depends - if all drivers must be changed or just those, who support VLAN. I tend to a solution where just the VLAN-capable drivers should be changed.
From: [email protected]
Date: Wed, 24 Apr 2002 19:03:19 +0200
Oh. Even in 2.4 ?
Yes, the "cannot do VLAN" flag is there in 2.4.x
That's a good idea. So vconfig could check, if its possible to
create a VLAN on top of such a driver - and issue a message if
not.
VLAN layer checks this and fails to bring up VLAN if
flag is set for the device being configured. I'm way
ahead of you.
Franks a lot,
David S. Miller
[email protected]
David S. Miller wrote:
> From: [email protected]
> Date: Wed, 24 Apr 2002 19:03:19 +0200
>
> Oh. Even in 2.4 ?
>
> Yes, the "cannot do VLAN" flag is there in 2.4.x
>
> That's a good idea. So vconfig could check, if its possible to
> create a VLAN on top of such a driver - and issue a message if
> not.
>
> VLAN layer checks this and fails to bring up VLAN if
> flag is set for the device being configured. I'm way
> ahead of you.
Maybe it could just WARN and still bring it up, if it's just
an MTU issue? (Or is this a total failure of VLAN support you
are talking about?)
Also, is there any good reason that we can't get at least a compile
time change into some of the drivers like tulip where we know we can
get at least MOST of the cards supported with a small change?
I know the driver writers hate cruft in the drivers, but we have had
ppl using the patches in production machines for months, if not years,
with no ill effects.
The same argument applies to the EEPRO driver (we know a cure, but it's
a magic register number, and no one will accept the patch).
Ben
>
> Franks a lot,
> David S. Miller
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
From: Ben Greear <[email protected]>
Date: Wed, 24 Apr 2002 10:31:29 -0700
Maybe it could just WARN and still bring it up, if it's just
an MTU issue? (Or is this a total failure of VLAN support you
are talking about?)
This creates a support issue. It's almost impossible to field
bug reports effectively once you start letting users do stuff
like this.
Also, is there any good reason that we can't get at least a compile
time change into some of the drivers like tulip where we know we can
get at least MOST of the cards supported with a small change?
I know the driver writers hate cruft in the drivers, but we have had
ppl using the patches in production machines for months, if not years,
with no ill effects.
But the changes are wrong, just because they work for some people
doesn't make the change mergeable into the main tree.
The same argument applies to the EEPRO driver (we know a cure, but it's
a magic register number, and no one will accept the patch).
Intel is making strides with their e1000 and e100 drivers, just give
them some time.
Also Jeff is in a rut right and busy with some things, once he gets
back up to speed you can expect a lot of these issues to be dealt
with.
Franks a lot,
David S. Miller
[email protected]
> Von: <[email protected]>
> Gesendet: 24.04.2002 19:10
> Yes, the "cannot do VLAN" flag is there in 2.4.x
Mhh, did not found the symbol in netdevice.h on stock 2.4.18.
> VLAN layer checks this and fails to bring up VLAN if
> flag is set for the device being configured. I'm way
> ahead of you.
Ok, awaiting your changes.
Greetings
Jochen Dolze
From: [email protected]
Date: Wed, 24 Apr 2002 19:42:24 +0200
> Von: <[email protected]>
> Gesendet: 24.04.2002 19:10
> Yes, the "cannot do VLAN" flag is there in 2.4.x
Mhh, did not found the symbol in netdevice.h on stock 2.4.18.
See 2.4.19-preX
On Wed, Apr 24, 2002 at 10:31:29AM -0700, Ben Greear wrote:
> Also, is there any good reason that we can't get at least a compile
> time change into some of the drivers like tulip where we know we can
> get at least MOST of the cards supported with a small change?
The tulip patch is butt-ugly - the oversized allocation isn't needed,
and it just flat-out turns off large packet protection. That's really
not what you want to do, even for the best tulip cards. If an oversized
gram (non-VLAN) makes it into a network which such a patched tulip
driver, you can DoS. So, I view the current tulip patch as unacceptable
too -- for security reasons, we should not even take it as a compile
time patch. (and I recommend against using that patch on production
machines, for the same security reasons)
The proper tulip patch does not need to change packet allocation size
at all (it's already plenty big enough), and it needs to copy the RX
fragment handling code from 8139cp (which is admittedly ugly, slow path)
or write fresh fragment handling code. Along with that fragment
handling code comes a safe way to do VLAN, and non-standard large MTUs
in general.
> The same argument applies to the EEPRO driver (we know a cure, but it's
> a magic register number, and no one will accept the patch).
I think we have a good chance of making that a less magic-number patch,
though, given the last discussion.
Jeff
David S. Miller wrote:
> From: Ben Greear <[email protected]>
> Date: Wed, 24 Apr 2002 10:31:29 -0700
>
> Maybe it could just WARN and still bring it up, if it's just
> an MTU issue? (Or is this a total failure of VLAN support you
> are talking about?)
>
> This creates a support issue. It's almost impossible to field
> bug reports effectively once you start letting users do stuff
> like this.
We let users do much worse: rm -fr /
won't even warn you. I'm all for warning the user, but since the
MTU issue can be worked around by setting the VLAN MTU to 1496,
and sometimes setting the eth0 MTU to 1504, then putting hard
restrictions in the kernel sounds like a really bad idea.
> Also, is there any good reason that we can't get at least a compile
> time change into some of the drivers like tulip where we know we can
> get at least MOST of the cards supported with a small change?
>
> I know the driver writers hate cruft in the drivers, but we have had
> ppl using the patches in production machines for months, if not years,
> with no ill effects.
>
> But the changes are wrong, just because they work for some people
> doesn't make the change mergeable into the main tree.
Wrong is a strong word for a change that makes it work for some people without
obvious negative side effects. I can understand not putting the changes in
by default, but a module-load flag, or a compile time check is much easier
to support than telling the user to go patch their driver and come back when
they figure out how to do that... It will also allow users to easily test
the patches on all their various systems.
> The same argument applies to the EEPRO driver (we know a cure, but it's
> a magic register number, and no one will accept the patch).
>
> Intel is making strides with their e1000 and e100 drivers, just give
> them some time.
That is good news, but does not change my arguments about fixing up
the eepro driver at all :)
> Also Jeff is in a rut right and busy with some things, once he gets
> back up to speed you can expect a lot of these issues to be dealt
> with.
I'm looking forward to Jeff's return. I still haven't heard if he
ever figured out why 3 DFE-570-tx (4-port) tulip nics cannot exist
in the same system :)
Ben
>
> Franks a lot,
> David S. Miller
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
Jeff Garzik wrote:
> On Wed, Apr 24, 2002 at 10:31:29AM -0700, Ben Greear wrote:
>
>>Also, is there any good reason that we can't get at least a compile
>>time change into some of the drivers like tulip where we know we can
>>get at least MOST of the cards supported with a small change?
>>
>
> The tulip patch is butt-ugly - the oversized allocation isn't needed,
> and it just flat-out turns off large packet protection. That's really
> not what you want to do, even for the best tulip cards. If an oversized
> gram (non-VLAN) makes it into a network which such a patched tulip
> driver, you can DoS. So, I view the current tulip patch as unacceptable
> too -- for security reasons, we should not even take it as a compile
> time patch. (and I recommend against using that patch on production
> machines, for the same security reasons)
I can DOS a tulip card with very small packets too ;)
The oversized allocations can be removed from the patch since they
are not needed.
> The proper tulip patch does not need to change packet allocation size
> at all (it's already plenty big enough), and it needs to copy the RX
> fragment handling code from 8139cp (which is admittedly ugly, slow path)
> or write fresh fragment handling code. Along with that fragment
> handling code comes a safe way to do VLAN, and non-standard large MTUs
> in general.
In the general case, where the packets are only 1518 (ie no DoS or mis-configured
hardware is in effect), is there a need for the "ugly, slow path" code to run?
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
On Wed, Apr 24, 2002 at 01:49:33PM -0400, Jeff Garzik wrote:
...
> The tulip patch is butt-ugly - the oversized allocation isn't needed,
> and it just flat-out turns off large packet protection. That's really
> not what you want to do, even for the best tulip cards. If an oversized
> gram (non-VLAN) makes it into a network which such a patched tulip
> driver, you can DoS.
It all depends... At least the cisco switches I have used have
protection by controlling on how large frames you can send, and
having automatic enlarging of frame size for VLAN Trunking port.
Of course those switches have some amounts of "jumbogram support"
as well at port by port basis.
So perhaps you can DoS your machine off the net (or your stream
very least), but not other machines.
> Jeff
/Matti Aarnio
From: Ben Greear <[email protected]>
Date: Wed, 24 Apr 2002 10:58:06 -0700
> But the changes are wrong, just because they work for some people
> doesn't make the change mergeable into the main tree.
Wrong is a strong word for a change that makes it work for some people without
obvious negative side effects.
Ummm, sed 's/obvious/known/' We don't know what the patch
even does.
That is good news, but does not change my arguments about fixing up
the eepro driver at all :)
The point is that once we see what works in the e100 driver (and Jeff
and I are making them document the bits) we can add the same fix
to eepro100.c
Franks a lot,
David S. Miller
[email protected]
On Wed, Apr 24, 2002 at 11:04:47AM -0700, Ben Greear wrote:
> Jeff Garzik wrote:
>
> > On Wed, Apr 24, 2002 at 10:31:29AM -0700, Ben Greear wrote:
> >
> >>Also, is there any good reason that we can't get at least a compile
> >>time change into some of the drivers like tulip where we know we can
> >>get at least MOST of the cards supported with a small change?
> >>
> >
> > The tulip patch is butt-ugly - the oversized allocation isn't needed,
> > and it just flat-out turns off large packet protection. That's really
> > not what you want to do, even for the best tulip cards. If an oversized
> > gram (non-VLAN) makes it into a network which such a patched tulip
> > driver, you can DoS. So, I view the current tulip patch as unacceptable
> > too -- for security reasons, we should not even take it as a compile
> > time patch. (and I recommend against using that patch on production
> > machines, for the same security reasons)
>
>
> I can DOS a tulip card with very small packets too ;)
A tulip card? Or the stack?
Can you DoS it when CONFIG_NET_HW_FLOWCONTROL is enabled?
That's basically NAPI without the fancy acronym...
> > The proper tulip patch does not need to change packet allocation size
> > at all (it's already plenty big enough), and it needs to copy the RX
> > fragment handling code from 8139cp (which is admittedly ugly, slow path)
> > or write fresh fragment handling code. Along with that fragment
> > handling code comes a safe way to do VLAN, and non-standard large MTUs
> > in general.
>
> In the general case, where the packets are only 1518 (ie no DoS or mis-configured
> hardware is in effect), is there a need for the "ugly, slow path" code to run?
It depends on the chip, but most generally: no
Jeff
On Wed, Apr 24, 2002 at 09:07:23PM +0300, Matti Aarnio wrote:
> On Wed, Apr 24, 2002 at 01:49:33PM -0400, Jeff Garzik wrote:
> ...
> > The tulip patch is butt-ugly - the oversized allocation isn't needed,
> > and it just flat-out turns off large packet protection. That's really
> > not what you want to do, even for the best tulip cards. If an oversized
> > gram (non-VLAN) makes it into a network which such a patched tulip
> > driver, you can DoS.
>
> It all depends... At least the cisco switches I have used have
> protection by controlling on how large frames you can send, and
> having automatic enlarging of frame size for VLAN Trunking port.
>
> Of course those switches have some amounts of "jumbogram support"
> as well at port by port basis.
>
> So perhaps you can DoS your machine off the net (or your stream
> very least), but not other machines.
The DoS certainly assumes that one can send jumbo datagrams to the
target machine via a local network. There are a multitude of ways
one can prevent the DoS present in the tulip VLAN patch, what you
name is certainly one of them.
Jeff
David S. Miller wrote:
> From: Ben Greear <[email protected]>
> Date: Wed, 24 Apr 2002 10:58:06 -0700
>
> > But the changes are wrong, just because they work for some people
> > doesn't make the change mergeable into the main tree.
>
> Wrong is a strong word for a change that makes it work for some people without
> obvious negative side effects.
>
> Ummm, sed 's/obvious/known/' We don't know what the patch
> even does.
We may not know EVERYTHING the patch does, but we do know that it
enables VLANs to work, and does not degrade other functionality in
any _observable_ way (to this point in time, at least.)
If someone wants to use VLANS, and wants to use EEPRO nics, then this
patch is obviously better than the unpatched driver. Thus my suggestion
that we make it easier for users to enable this patch/hack/whatever.
Allowing a #define switch, or even clearly commented driver code that
a FAQ can point to will help the VLAN user, and will not AT ALL affect
non-vlan aware users.
If/when the e100 guys show us a better way, no one will argue that
you shouldn't modify the eepro100 to be more kosher.
Thanks,
Ben
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
> Von: <[email protected]>
> Gesendet: 24.04.2002 20:00
>
> > This creates a support issue. It's almost impossible to field
> > bug reports effectively once you start letting users do stuff
> > like this.
> We let users do much worse: rm -fr /
> won't even warn you.
But it would do, what we expect. VLAN on a e.g. unpatched tulip driver is somewhat unpredictable.
You can hope any application is using small packets, but if not things get worse.
> I'm all for warning the user, but since the
> MTU issue can be worked around by setting the VLAN MTU to 1496,
> and sometimes setting the eth0 MTU to 1504, then putting hard
> restrictions in the kernel sounds like a really bad idea.
This sounds very "experimental". What about the non-VLAN packets on eth0, when you set the MTU
1504?
I like the NETIF_F_VLAN_CHALLENGED capability in the driver itself, which is then tested by the net subsystem on
creation of a VLAN. No more tweaks and fiddling around with MTU and framesizes.
Greetings
Jochen Dolze
> Von: <[email protected]>
> Gesendet: 24.04.2002 19:50
>
> Mhh, did not found the symbol in netdevice.h on stock 2.4.18.
> See 2.4.19-preX
Ok. I think NETIF_F_VLAN_CHALLENGED should be set if the device or driver can handle VLAN.
So older third party drivers (based on < 2.4.19) get denied at first, till the driver maintainer explicitly set the NETIF_F_VLAN_CHALLENDGED capability (or one of the VLAN-hardware capabilities).
Greetings
Jochen Dolze
From: [email protected]
Date: Thu, 25 Apr 2002 00:28:05 +0200
Ok. I think NETIF_F_VLAN_CHALLENGED should be set if the device or
driver can handle VLAN.
No, "challenged" means "cannot handle". Do not invert the meaning,
the macro says what the meaning is.
To get the behavior you want, we set the flat by default and drivers
for devices which are deemed "VLAN capable" can set the bit
themselves.
Uhhhh. What's up with the subject line? Somehow I suspect that it is
related to MS Outlook and "embracing and breaking" standards.
Dax Kelson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On April 24, 2002 21:40, I wrote:
> It seems to be related to "avixxmail 1.2.2.7", used by Dax Kelson
> <[email protected]>. "AW" is probably a localized reply prefix, and his
Eh, sorry, I meant [email protected] of course
- -Ryan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjzHiWQACgkQLGMzRzbJfbT25gCeIlox3XaPYgo+JrnWNm9rSm0a
C9IAni5wRvrBcH5N1UlwDEWpoQXx8oYe
=EH5J
-----END PGP SIGNATURE-----
On Wed, 24 Apr 2002, Dax Kelson wrote:
> Uhhhh. What's up with the subject line? Somehow I suspect that it is
> related to MS Outlook and "embracing and breaking" standards.
MS Outlook should be configured to use English attribution and Subject
tags. It's possible, but not the default setting.
(Apart from that, Outlook should be precluded from mailing lists for
technical reasons, the most important being improper quote marks on
base64/quoted-printable encoded mails.)
--
Matthias Andree
On Wed, 24 Apr 2002, David S. Miller wrote:
> From: [email protected]
> Date: Wed, 24 Apr 2002 19:03:19 +0200
>
> Oh. Even in 2.4 ?
>
> Yes, the "cannot do VLAN" flag is there in 2.4.x
Is there an up-to-date list of hardware and/or drivers that support VLAN
with Linux 2.4?
--
Matthias Andree
> Von: <[email protected]>
> Gesendet: 25.04.2002 00:33
>
> Ok. I think NETIF_F_VLAN_CHALLENGED should be set if the device or
> driver can handle VLAN.
> No, "challenged" means "cannot handle". Do not invert the meaning,
> the macro says what the meaning is.
Why not call it NETIF_F_VLAN ?
> To get the behavior you want, we set the flat by default
What does this mean, "set the flat by default", setting NETIF_F_VLAN_CHALLENGED by default?
> and drivers
> for devices which are deemed "VLAN capable" can set the bit
> themselves.
If it works for older thirdparty (< 2.4.19) driver too (without any changes - only recompile), it would be great.
Greetings
Jochen Dolze
From: [email protected]
Date: Thu, 25 Apr 2002 15:45:59 +0200
> No, "challenged" means "cannot handle". Do not invert the meaning,
> the macro says what the meaning is.
Why not call it NETIF_F_VLAN ?
BTW, your mail client's mangling of subject lines is REALLY ANNOYING.
We don't call it NETIF_F_VLAN because the hope is that eventually
it will be rare for a network device to not be able to support it.
Not the other day around.
Please fix your mail client before replying anymore, ok? Thanks.
Franks a lot,
David S. Miller
[email protected]
> Von: <[email protected]>
> Gesendet: 26.04.2002 02:57
>
> BTW, your mail client's mangling of subject lines is REALLY ANNOYING.
Sorry, i fixed it.
> We don't call it NETIF_F_VLAN because the hope is that eventually
> it will be rare for a network device to not be able to support it.
> Not the other day around.
I don't know how many cards won't support VLAN nowadays. But i will test
these changes with my third party driver (just recompile it against pre-2.4.19)
and report the results.
Greetings
Jochen Dolze
From: [email protected]
Date: Sat, 27 Apr 2002 22:34:09 +0200
> We don't call it NETIF_F_VLAN because the hope is that eventually
> it will be rare for a network device to not be able to support it.
> Not the other day around.
I don't know how many cards won't support VLAN nowadays. But i will test
these changes with my third party driver (just recompile it against pre-2.4.19)
and report the results.
This will tell us exactly nothing. It will continue to tell us
nothing until I make the change whereby NETIF_F_VLAN_CHALLENGED is set
by default and devices known to work are updated to clear it.
Please don't bother posting the results, we know what will happen.
> Von: <[email protected]>
> Gesendet: 28.04.2002 04:54
>
> I don't know how many cards won't support VLAN nowadays. But i will test
> these changes with my third party driver (just recompile it against pre-2.4.19)
> and report the results.
>
> This will tell us exactly nothing. It will continue to tell us
> nothing until I make the change whereby NETIF_F_VLAN_CHALLENGED is set
> by default and devices known to work are updated to clear it.
Then i understood it right. I hope your change is made in this way only for the 2.5 tree.
Changing all drivers is ok for 2.5, but most third party driver supplier update their drivers
only rarely.
> Please don't bother posting the results, we know what will happen.
I think your solution is ok for 2.5 but not for 2.4. On the 2.4 series it would be easier to
add a flag which is set if the driver is VLAN ready. This wouldn't break third party drivers,
which are not VLAN ready. And vconfig would report the right thing without changing any
driver code (as it was intended by one of my former postings).
Greetings
Jochen Dolze
From: [email protected]
Date: Sun, 28 Apr 2002 22:28:06 +0200
> Please don't bother posting the results, we know what will happen.
I think your solution is ok for 2.5 but not for 2.4. On the 2.4 series it would be easier to
add a flag which is set if the driver is VLAN ready.
Will you at least listen to what my proposed solution is?
It has precisely the same effect your proposal has.
Let me say it for millionth time:
Networking sets "can't VLAN" by default in device flags,
if device driver clear it we can do VLAN. So by default
device is marked as not VLAN capable.
This is exactly the behavior you are asking for. There
is no fundamental difference between your scheme and mine
except that I am being required to retype a description
of mine a million times.
Hi,
It may be a simple question. But I cannot see the result of printk in
console like the following. Do i need to enable it somewhere? Thanks
/*-O2 -Wall -DMODULE -D__KERNEL__ -DLINUX -c testsys.c */
#include <linux/sys.h>
#include <linux/mm.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/sched.h>
#include <sys/syscall.h>
#include <asm/uaccess.h>
/* The system call number we attempt to install ourselves as. */
static int syscall_num = 165;
asmlinkage int sys_test(int pid, int period, int cycles, int* ptr)
{
put_user(current->pid, ptr);
return pid-10000;
}
extern int sys_call_table[];
#ifdef MODULE
int init_module(void)
{
printk("yes\n");
sys_call_table[syscall_num] = (int)sys_test;
return 0;
}
void cleanup_module(void)
{
sys_call_table[syscall_num] = 0;
}
#endif /* MODULE */
On Monday 29 April 2002 08:20 am, Wanghong Yuan wrote:
> Hi,
>
> It may be a simple question. But I cannot see the result of printk in
> console like the following. Do i need to enable it somewhere? Thanks
>
man dmesg
The manual is not explicit about valid values for the logging level.
Try "dmesg -n8".
-- Itai
In default priority printk maybe don't show anything on terminal, try printk("<1>yes\n"). Remenber that you can't use xterm.
Uilton Dutra
[email protected]
http://iam.uiltrix.com.br
On Mon, 29 Apr 2002 00:20:11 -0500
"Wanghong Yuan" <[email protected]> wrote:
//Hi,
//
//It may be a simple question. But I cannot see the result of printk in
//console like the following. Do i need to enable it somewhere? Thanks
//
///*-O2 -Wall -DMODULE -D__KERNEL__ -DLINUX -c testsys.c */
//
//#include <linux/sys.h>
//#include <linux/mm.h>
//#include <linux/module.h>
//#include <linux/kernel.h>
//#include <linux/sched.h>
//#include <sys/syscall.h>
//#include <asm/uaccess.h>
//
//
///* The system call number we attempt to install ourselves as. */
//static int syscall_num = 165;
//
//asmlinkage int sys_test(int pid, int period, int cycles, int* ptr)
//
//{
//
// put_user(current->pid, ptr);
// return pid-10000;
//
//}
//
//extern int sys_call_table[];
//
//#ifdef MODULE
//int init_module(void)
//{
// printk("yes\n");
// sys_call_table[syscall_num] = (int)sys_test;
// return 0;
//}
//
//void cleanup_module(void)
//{
// sys_call_table[syscall_num] = 0;
//}
//
//#endif /* MODULE */
//
//
//-
//To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
//the body of a message to [email protected]
//More majordomo info at http://vger.kernel.org/majordomo-info.html
//Please read the FAQ at http://www.tux.org/lkml/
//
* Wanghong Yuan ([email protected]) wrote:
> Hi,
>
> It may be a simple question. But I cannot see the result of printk in
> console like the following. Do i need to enable it somewhere? Thanks
Take a look a man 8 dmesg. Also Documentation/sysctl/kernel.txt.
> /*-O2 -Wall -DMODULE -D__KERNEL__ -DLINUX -c testsys.c */
>
> #include <linux/sys.h>
> #include <linux/mm.h>
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/sched.h>
> #include <sys/syscall.h>
> #include <asm/uaccess.h>
>
>
> /* The system call number we attempt to install ourselves as. */
> static int syscall_num = 165;
I hope you know this can't be done safely (race free).
> asmlinkage int sys_test(int pid, int period, int cycles, int* ptr)
>
> {
>
> put_user(current->pid, ptr);
> return pid-10000;
>
> }
>
> extern int sys_call_table[];
>
> #ifdef MODULE
> int init_module(void)
> {
> printk("yes\n");
> sys_call_table[syscall_num] = (int)sys_test;
> return 0;
> }
>
> void cleanup_module(void)
> {
> sys_call_table[syscall_num] = 0;
this could cause a problem. you should save the original entry when you
insmod and restore it here ;-)
> }
>
> #endif /* MODULE */
btw, take a look at how the module_init() and module_exit() macros are used
in the kernel.
hope that helps,
-chris
> Von: <[email protected]>
> Gesendet: 29.04.2002 06:00
>
> Will you at least listen to what my proposed solution is?
> It has precisely the same effect your proposal has.
> Let me say it for millionth time:
> Networking sets "can't VLAN" by default in device flags,
> if device driver clear it we can do VLAN. So by default
> device is marked as not VLAN capable.
> This is exactly the behavior you are asking for. There
> is no fundamental difference between your scheme and mine
> except that I am being required to retype a description
> of mine a million times.
Sorry, i didn't got it. Now its clear. I missed that the device
flags are set in the networking code too and not only
in the driver. I apologize me for the former posts.
Greetings
Jochen Dolze
[email protected] said:
> It may be a simple question. But I cannot see the result of printk in
> console like the following. Do i need to enable it somewhere? Thanks
You didn't give a priority, so it will have defaulted to KERN_WARNING.
Some distributions disable the logging of KERN_WARNING messages to the
console, which seems to be a very silly thing to do. I suggest you
re-enable these messages (echo 7 > /proc/sys/kernel/printk) and file a bug
report.
--
dwmw2
Is there any package or program, which can be used to accurately measure the
CPU cycles used by a program? I think the following code can only provide an
inaccurate one, beause it may count on the waiting time of the program.
gettimeofday(t1)
runprogam
gettimeofday(t2)
t2-t1
If I need to instrument the kernel, which part I should investigate? Thanks
a lot in advance
Wanghong
On 2002.04.30 Wanghong Yuan wrote:
>Is there any package or program, which can be used to accurately measure the
>CPU cycles used by a program? I think the following code can only provide an
>inaccurate one, beause it may count on the waiting time of the program.
>
>gettimeofday(t1)
>runprogam
>gettimeofday(t2)
>t2-t1
>
>If I need to instrument the kernel, which part I should investigate? Thanks
>a lot in advance
>
man getrusage
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.3 (Cooker) for i586
Linux werewolf 2.4.19-pre7-jam7 #1 SMP jue abr 25 00:19:56 CEST 2002 i686
On 29 April 2002 09:37, David Woodhouse wrote:
> [email protected] said:
> > It may be a simple question. But I cannot see the result of printk in
> > console like the following. Do i need to enable it somewhere? Thanks
>
> You didn't give a priority, so it will have defaulted to KERN_WARNING.
>
> Some distributions disable the logging of KERN_WARNING messages to the
> console, which seems to be a very silly thing to do.
It is not silly as long as kernel continues to log tons of normal stuff
as warnings.
> file a bug report.
Here it is:
There are way too many printks without a log level!
--
vda
[email protected] said:
> It is not silly as long as kernel continues to log tons of normal
> stuff as warnings.
Er, IMO it _is_ silly as long as the kernel continues to log real warnings
as warnings too.
> Here it is: There are way too many printks without a log level! --
Oh, well the answer is obvious - just disable _all_ the warning messages.
Why not turn off KERN_CRIT too, while we're at it? I'm sure we can find at
least one superfluous KERN_CRIT message.
--
dwmw2
On 30 April 2002 10:55, David Woodhouse wrote:
> [email protected] said:
> > It is not silly as long as kernel continues to log tons of normal
> > stuff as warnings.
>
> Er, IMO it _is_ silly as long as the kernel continues to log real warnings
> as warnings too.
>
> > Here it is: There are way too many printks without a log level! --
>
> Oh, well the answer is obvious - just disable _all_ the warning messages.
>
> Why not turn off KERN_CRIT too, while we're at it? I'm sure we can find at
> least one superfluous KERN_CRIT message.
Hey, hey... do you expect users to patch all those printk() calls
in their kernel themself? Realistically they can:
* enable console logging for warnings and be flooded
* disable console logging for warnings and stay blind
* send patches to lkml and be ignored
* configure syslogd to print warnings on a dedicated tty
Anyway, that's what I did.
--
vda
[email protected] said:
> Hey, hey... do you expect users to patch all those printk() calls in
> their kernel themself? Realistically they can:
I was talking about vendors setting silly defaults. One can reasonably
expect _vendors_ to fix printks with wrong or no priority rather than just
disabling them all.
There's a lot of crap at KERN_NOTICE that could be sanely ignored by
default. Stuff at KERN_WARNING probably ought to be printed by default. It
can often precede and explain a crash.
> * send patches to lkml and be ignored
There are more sensible places to send patches than lkml.
--
dwmw2
> >Is there any package or program, which can be used to accurately measure the
> >CPU cycles used by a program? I think the following code can only provide an
>
> man getrusage
There is a measurable chance that getrusage isn't good enough, something
like perfctr ( http://www.csd.uu.se/~mikpe/linux/perfctr/ ) that
actually measures cpu events may be more insteresting. See also:
http://oprofile.sourceforge.net/
- z
Hi,
It seems that tq_scheduler disappears in Linux 2.4. SO what can I do if I
need to do something when the scheduler wakes up. The old code likes
queue_task(&myqueue, &tq_scheduler);
Thanks
Wanghong Yuan wrote:
>
> Hi,
>
> It seems that tq_scheduler disappears in Linux 2.4. SO what can I do if I
> need to do something when the scheduler wakes up. The old code likes
>
All users of tq_scheduler were using it as a way of running
process-context code shortly after the occurrence of an
interrupt. They were moved over to using schedule_task().
Probably, that is what you want.
If you specifically have a need to know when the
scheduler is entered then there is no longer a way of
doing that.
-
> Wanghong Yuan wrote:
> It seems that tq_scheduler disappears in Linux 2.4. SO what can
> I do if I need to do something when the scheduler wakes up.
I also needed the tq_scheduler "feature". I've used the following
patch with success on 2.4.18 (UP) + preempt. However, since this is
strictly a local hack I felt free to change the semantics somewhat.
If this patch is applied to 2.4.18, the tq_scheduler hook returns
-- but the runqueue is serviced *after* the context switch, just
before execution in user space is resumed. The old 2.2.x
tq_scheduler ran just *before* the context switch.
YMMV.
>>>>>
--- linux-2.4.18/include/linux/tqueue.h.old Tue Apr 30 19:03:59 2002
+++ linux-2.4.18/include/linux/tqueue.h Tue Apr 30 19:04:12 2002
@@ -66,7 +66,7 @@
#define DECLARE_TASK_QUEUE(q) LIST_HEAD(q)
#define TQ_ACTIVE(q) (!list_empty(&q))
-extern task_queue tq_timer, tq_immediate, tq_disk;
+extern task_queue tq_timer, tq_immediate, tq_scheduler, tq_disk;
/*
* To implement your own list of active bottom halfs, use the following
--- linux-2.4.18/kernel/sched.c.old Tue Apr 30 19:06:30 2002
+++ linux-2.4.18/kernel/sched.c Tue Apr 30 19:06:00 2002
@@ -106,6 +106,8 @@
char __pad [SMP_CACHE_BYTES];
} aligned_data [NR_CPUS] __cacheline_aligned = { {{&init_task,0}}};
+DECLARE_TASK_QUEUE(tq_scheduler);
+
#define cpu_curr(cpu) aligned_data[(cpu)].schedule_data.curr
#define last_schedule(cpu) aligned_data[(cpu)].schedule_data.last_schedule
@@ -496,6 +498,7 @@
out_unlock:
task_unlock(prev); /* Synchronise here with release_task() if
prev is TASK_ZOMBIE */
+ run_task_queue(&tq_scheduler);
return;
/*
@@ -528,6 +531,7 @@
}
#else
prev->policy &= ~SCHED_YIELD;
+ run_task_queue(&tq_scheduler);
#endif /* CONFIG_SMP */
}
--- linux-2.4.18/kernel/ksyms.c.old Tue Apr 30 19:06:40 2002
+++ linux-2.4.18/kernel/ksyms.c Tue Apr 30 19:04:46 2002
@@ -442,6 +442,7 @@
EXPORT_SYMBOL(xtime);
EXPORT_SYMBOL(do_gettimeofday);
EXPORT_SYMBOL(do_settimeofday);
+EXPORT_SYMBOL(tq_scheduler);
#if !defined(__ia64__)
EXPORT_SYMBOL(loops_per_jiffy);
<<<<<
Andrew Purtell [email protected]
NAI Labs at Network Associates, Inc. Seattle, WA