VLAN and Network Drivers 2.4.x

VLAN and Network Drivers 2.4.x

[jd]

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?

Re: VLAN and Network Drivers 2.4.x

[David S. Miller]

   From: jd@epcnet.de
   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.

AW: Re: VLAN and Network Drivers 2.4.x

[jd]

> Von: <davem@redhat.com>
> 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.

Re: AW: Re: VLAN and Network Drivers 2.4.x

[David S. Miller]

   From: jd@epcnet.de
   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.

AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[jd]

> Von: <davem@redhat.com>
> 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.

Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[David S. Miller]

   From: jd@epcnet.de
   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
davem@redhat.com

Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[Ben Greear]

David S. Miller wrote:

>    From: jd@epcnet.de
>    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
> davem@redhat.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 


-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[David S. Miller]

   From: Ben Greear <greearb@candelatech.com>
   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
davem@redhat.com

Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[Ben Greear]

David S. Miller wrote:

>    From: Ben Greear <greearb@candelatech.com>
>    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
> davem@redhat.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 


-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[David S. Miller]

   From: Ben Greear <greearb@candelatech.com>
   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
davem@redhat.com

Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[Ben Greear]

David S. Miller wrote:

>    From: Ben Greear <greearb@candelatech.com>
>    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 <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

AW: Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[jd]

> Von: <greearb@candelatech.com>
> 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

Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[Jeff Garzik]

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

Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[Ben 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 <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[Jeff Garzik]

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

Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[Matti Aarnio]

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

Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[Jeff Garzik]

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

AW: Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[jd]

> Von: <davem@redhat.com>
> 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

Re: AW: Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[David S. Miller]

   From: jd@epcnet.de
   Date: Wed, 24 Apr 2002 19:42:24 +0200

   > Von: <davem@redhat.com>
   > 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

AW: Re: AW: Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[jd]

> Von: <davem@redhat.com>
> 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

Re: AW: Re: AW: Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[David S. Miller]

   From: jd@epcnet.de
   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.

Re: AW: Re: AW: Re: AW: Re: AW: Re: AW: Re: AW: Re: AW: [was: VLAN and Network Drivers 2.4.x]

[Dax Kelson]

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

Re: AW: Re: AW: Re: AW: Re: AW: Re: AW: Re: AW: Re: AW: [was: VLAN and Network Drivers 2.4.x]

[Ryan Cumming]

-----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
> <dax@gurulabs.com>. "AW" is probably a localized reply prefix, and his
Eh, sorry, I meant jd@epcnet.de 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-----

Re: [was: VLAN and Network Drivers 2.4.x]

[Matthias Andree]

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

AW: Re: AW: Re: AW: Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[jd]

> Von: <davem@redhat.com>
> 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

Re: AW: Re: AW: Re: AW: Re: AW: Re: AW: Re: VLAN and Network Drivers 2.4.x

[David S. Miller]

   From: jd@epcnet.de
   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
davem@redhat.com

Re: VLAN and Network Drivers 2.4.x

[jd]

> Von: <davem@redhat.com>
> 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

Re: VLAN and Network Drivers 2.4.x

[David S. Miller]

   From: jd@epcnet.de
   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.

Re: VLAN and Network Drivers 2.4.x

[jd]

> Von: <davem@redhat.com>
> 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

Re: VLAN and Network Drivers 2.4.x

[David S. Miller]

   From: jd@epcnet.de
   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.

How to enable printk

[Wanghong Yuan]

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 */

Re: How to enable printk

[Uilton Dutra]

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
uilton@uiltrix.com.br
http://iam.uiltrix.com.br

On Mon, 29 Apr 2002 00:20:11 -0500
"Wanghong Yuan" <wyuan1@ews.uiuc.edu> 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 majordomo@vger.kernel.org
//More majordomo info at  http://vger.kernel.org/majordomo-info.html
//Please read the FAQ at  http://www.tux.org/lkml/
//

Re: How to enable printk

[Itai Nahshon]

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

Re: How to enable printk

[Chris Wright]

* Wanghong Yuan (wyuan1@ews.uiuc.edu) 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

Re: How to enable printk

[David Woodhouse]

wyuan1@ews.uiuc.edu 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

Re: How to enable printk

[Denis Vlasenko]

On 29 April 2002 09:37, David Woodhouse wrote:
> wyuan1@ews.uiuc.edu 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

Re: How to enable printk

[David Woodhouse]

vda@port.imtp.ilyichevsk.odessa.ua 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

Re: How to enable printk

[Denis Vlasenko]

On 30 April 2002 10:55, David Woodhouse wrote:
> vda@port.imtp.ilyichevsk.odessa.ua 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

Re: How to enable printk

[David Woodhouse]

vda@port.imtp.ilyichevsk.odessa.ua 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

Accurately measure CPU cycles used by a program? thanks

[Wanghong Yuan]

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

Re: Accurately measure CPU cycles used by a program? thanks

[J.A. Magallon]

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:jamagallon@able.es
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

Re: Accurately measure CPU cycles used by a program? thanks

[Zach Brown]

> >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

Re: Accurately measure CPU cycles used by a program? thanks

[Corey Minyard]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

J.A. Magallon wrote:

>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
>
getrusage is grossly inaccurate.  If a process is running when the timer 
interrupt hits, it's assigned an entire timer interrupt's worth of CPU, 
even if it's only run one instruction.  I've attached an old patch that 
makes getrusage farily accurate.  It's not going to be accurate to the 
CPU cycle, but it's not too bad.  It does increase the overhead for 
system calls and interrupts.  It works on newer x86 and PowerPC.

-Corey


[-- Attachment #2: highres.patch --]
[-- Type: text/plain, Size: 28161 bytes --]

--- ./fs/proc/proc_misc.c.highres	Tue Nov 20 23:29:09 2001
+++ ./fs/proc/proc_misc.c	Sat Feb  9 17:30:04 2002
@@ -101,7 +101,8 @@
 	int len;
 
 	uptime = jiffies;
-	idle = init_tasks[0]->times.tms_utime + init_tasks[0]->times.tms_stime;
+	idle = (tms_time_to_ticks(init_tasks[0]->times.tms_utime)
+		+ tms_time_to_ticks(init_tasks[0]->times.tms_stime));
 
 	/* The formula for the fraction parts really is ((t * 100) / HZ) % 100, but
 	   that would overflow about every five days at HZ == 100.
--- ./fs/proc/array.c.highres	Thu Oct 11 11:00:01 2001
+++ ./fs/proc/array.c	Sat Feb  9 17:30:04 2002
@@ -358,10 +358,10 @@
 		task->cmin_flt,
 		task->maj_flt,
 		task->cmaj_flt,
-		task->times.tms_utime,
-		task->times.tms_stime,
-		task->times.tms_cutime,
-		task->times.tms_cstime,
+		tms_time_to_ticks(task->times.tms_utime),
+		tms_time_to_ticks(task->times.tms_stime),
+		tms_time_to_ticks(task->times.tms_cutime),
+		tms_time_to_ticks(task->times.tms_cstime),
 		priority,
 		nice,
 		0UL /* removed */,
@@ -682,8 +682,8 @@
 
 	len = sprintf(buffer,
 		"cpu  %lu %lu\n",
-		task->times.tms_utime,
-		task->times.tms_stime);
+		tms_time_to_ticks(task->times.tms_utime),
+		tms_time_to_ticks(task->times.tms_stime));
 		
 	for (i = 0 ; i < smp_num_cpus; i++)
 		len += sprintf(buffer + len, "cpu%d %lu %lu\n",
--- ./fs/binfmt_elf.c.highres	Thu Jan 10 15:52:13 2002
+++ ./fs/binfmt_elf.c	Sat Feb  9 17:30:04 2002
@@ -1105,14 +1105,10 @@
 	psinfo.pr_ppid = prstatus.pr_ppid = current->p_pptr->pid;
 	psinfo.pr_pgrp = prstatus.pr_pgrp = current->pgrp;
 	psinfo.pr_sid = prstatus.pr_sid = current->session;
-	prstatus.pr_utime.tv_sec = CT_TO_SECS(current->times.tms_utime);
-	prstatus.pr_utime.tv_usec = CT_TO_USECS(current->times.tms_utime);
-	prstatus.pr_stime.tv_sec = CT_TO_SECS(current->times.tms_stime);
-	prstatus.pr_stime.tv_usec = CT_TO_USECS(current->times.tms_stime);
-	prstatus.pr_cutime.tv_sec = CT_TO_SECS(current->times.tms_cutime);
-	prstatus.pr_cutime.tv_usec = CT_TO_USECS(current->times.tms_cutime);
-	prstatus.pr_cstime.tv_sec = CT_TO_SECS(current->times.tms_cstime);
-	prstatus.pr_cstime.tv_usec = CT_TO_USECS(current->times.tms_cstime);
+	prstatus.pr_utime = tms_time_to_timeval(current->times.tms_utime);
+	prstatus.pr_stime = tms_time_to_timeval(current->times.tms_stime);
+	prstatus.pr_cutime = tms_time_to_timeval(current->times.tms_cutime);
+	prstatus.pr_cstime = tms_time_to_timeval(current->times.tms_cstime);
 
 	/*
 	 * This transfers the registers from regs into the standard
--- ./mm/oom_kill.c.highres	Sat Nov  3 19:05:25 2001
+++ ./mm/oom_kill.c	Sat Feb  9 17:30:04 2002
@@ -72,7 +72,9 @@
 	 * very well in practice. This is not safe against jiffie wraps
 	 * but we don't care _that_ much...
 	 */
-	cpu_time = (p->times.tms_utime + p->times.tms_stime) >> (SHIFT_HZ + 3);
+	cpu_time = (tms_time_to_ticks(p->times.tms_utime)
+		    + tms_time_to_ticks(p->times.tms_stime))
+			>> (SHIFT_HZ + 3);
 	run_time = (jiffies - p->start_time) >> (SHIFT_HZ + 10);
 
 	points /= int_sqrt(cpu_time);
--- ./arch/ppc/config.in.highres	Fri Nov 16 12:10:08 2001
+++ ./arch/ppc/config.in	Sat Feb  9 17:30:04 2002
@@ -237,6 +237,11 @@
   source drivers/zorro/Config.in
 fi
 
+bool 'High resolution CPU usage and virtual itimers' CONFIG_HIGHRES_CPU_USAGE
+if [ "$CONFIG_HIGHRES_CPU_USAGE" = "y" ]; then
+  bool 'Does the virtual itimer count system CPU usage?' CONFIG_VIRT_ITIMER_COUNTS_SYSTEM
+fi
+
 endmenu
 source drivers/mtd/Config.in
 source drivers/pnp/Config.in
--- ./arch/ppc/kernel/entry.S.highres	Mon Nov 26 07:29:17 2001
+++ ./arch/ppc/kernel/entry.S	Sat Feb  9 17:30:04 2002
@@ -298,6 +298,10 @@
 ret_to_user_hook:
 	nop
 restore:
+#ifdef CONFIG_HIGHRES_CPU_USAGE
+	mr	r3,r2
+	bl	tms_leave_system
+#endif
 	lwz	r3,_XER(r1)
 	mtspr	XER,r3
 	REST_10GPRS(9,r1)
--- ./arch/ppc/kernel/time.c.highres	Mon Oct  8 13:43:01 2001
+++ ./arch/ppc/kernel/time.c	Sat Feb  9 17:30:04 2002
@@ -243,6 +243,35 @@
 	tv->tv_usec = usec;
 }
 
+#ifdef CONFIG_HIGHRES_CPU_USAGE
+unsigned long curr_timestamp(void)
+{
+        return get_native_tbl();
+}
+
+unsigned long timestamp_usec_diff(unsigned long ts1, unsigned long ts2)
+{
+        unsigned long val;
+	unsigned long usec;
+
+	if (__USE_RTC()) {
+	        int delta = ts1 - ts2;
+		val = delta<0 ? delta + 1000000000 : delta;
+	} else {
+        	val = ts1 - ts2;
+	}
+	usec = mulhwu(tb_to_us, val);
+	if (usec > 1000000) {
+		/* We had some wierd overflow due to the timebases being
+		   changed, just ignore it. */
+		printk("tb went backwards? ts1=%lu, ts2=%ld\n", ts1, ts2);
+		usec = 0;
+	}
+
+	return usec;
+}
+#endif
+
 void do_settimeofday(struct timeval *tv)
 {
 	unsigned long flags;
--- ./arch/ppc/kernel/head.S.highres	Fri Nov  2 19:43:54 2001
+++ ./arch/ppc/kernel/head.S	Sat Feb  9 17:30:04 2002
@@ -771,6 +771,12 @@
 2:	addi	r2,r23,-THREAD		/* set r2 to current */
 	tovirt(r2,r2)
 	mflr	r23
+#ifdef CONFIG_HIGHRES_CPU_USAGE
+	bl	3f
+	.long	highres_start
+3:	mflr	r25
+	lwz	r25,0(r25)
+#endif
 	andi.	r24,r23,0x3f00		/* get vector offset */
 	stw	r24,TRAP(r21)
 	li	r22,0
@@ -784,11 +790,50 @@
 	lwz	r24,0(r23)		/* virtual address of handler */
 	lwz	r23,4(r23)		/* where to go when done */
 	FIX_SRR1(r20,r22)
+#ifdef CONFIG_HIGHRES_CPU_USAGE
+	mtspr	SRR0,r25
+#else
 	mtspr	SRR0,r24
+#endif
 	mtspr	SRR1,r20
+#ifndef CONFIG_HIGHRES_CPU_USAGE
 	mtlr	r23
+#endif
 	SYNC
 	RFI				/* jump to handler, enable MMU */
+
+#ifdef CONFIG_HIGHRES_CPU_USAGE
+highres_start:
+	subi	r1,r1,52
+	stw	r12,44(r1)
+	stw	r11,40(r1)
+	stw	r10,36(r1)
+	stw	r9,32(r1)
+	stw	r8,28(r1)
+	stw	r7,24(r1)
+	stw	r6,20(r1)
+	stw	r5,16(r1)
+	stw	r4,12(r1)
+	stw	r3,8(r1)
+	stw	r0,48(r1)
+	mr	r3,r2
+	bl	tms_enter_system
+	mtlr	r23
+	mtctr	r24
+	lwz	r12,44(r1)
+	lwz	r11,40(r1)
+	lwz	r10,36(r1)
+	lwz	r9,32(r1)
+	lwz	r8,28(r1)
+	lwz	r7,24(r1)
+	lwz	r6,20(r1)
+	lwz	r5,16(r1)
+	lwz	r4,12(r1)
+	lwz	r3,8(r1)
+	lwz	r0,48(r1)
+	addi	r1,r1,52
+	bctr
+#endif
 
 /*
  * On kernel stack overflow, load up an initial stack pointer
--- ./arch/i386/config.in.highres	Sat Feb  9 20:48:32 2002
+++ ./arch/i386/config.in	Sat Feb  9 21:04:26 2002
@@ -279,6 +279,9 @@
    bool '    Use real mode APM BIOS call to power off' CONFIG_APM_REAL_MODE_POWER_OFF
 fi
 
+dep_bool 'High resolution CPU usage and virtual itimers' CONFIG_HIGHRES_CPU_USAGE $CONFIG_X86_TSC
+dep_bool 'Does the virtual itimer count system CPU usage?' CONFIG_VIRT_ITIMER_COUNTS_SYSTEM $CONFIG_HIGHRES_CPU_USAGE
+
 endmenu
 
 source drivers/mtd/Config.in
--- ./arch/i386/kernel/entry.S.highres	Sat Feb  9 20:48:02 2002
+++ ./arch/i386/kernel/entry.S	Mon Feb 11 14:55:52 2002
@@ -81,6 +81,27 @@
 
 ENOSYS = 38
 
+#define GET_CURRENT(reg) \
+	movl $-8192, reg; \
+	andl %esp, reg
+
+#ifdef CONFIG_HIGHRES_CPU_USAGE
+#define HIGHRES_START_CODE \
+	pushl %eax;        \
+	GET_CURRENT(%ebx); \
+	pushl %ebx;        \
+	call  SYMBOL_NAME(tms_enter_system); \
+	addl  $4,%esp;     \
+	popl %eax; 
+#define HIGHRES_END_CODE \
+	GET_CURRENT(%ebx); \
+	pushl %ebx;        \
+	call  SYMBOL_NAME(tms_leave_system); \
+	addl  $4,%esp; 
+#else
+#define HIGHRES_START_CODE
+#define HIGHRES_END_CODE
+#endif
 
 #define SAVE_ALL \
 	cld; \
@@ -95,9 +116,11 @@
 	pushl %ebx; \
 	movl $(__KERNEL_DS),%edx; \
 	movl %edx,%ds; \
-	movl %edx,%es;
+	movl %edx,%es; \
+	HIGHRES_START_CODE;
 
 #define RESTORE_ALL	\
+	HIGHRES_END_CODE; \
 	popl %ebx;	\
 	popl %ecx;	\
 	popl %edx;	\
@@ -128,10 +151,6 @@
 	.long 3b,6b;	\
 .previous
 
-#define GET_CURRENT(reg) \
-	movl $-8192, reg; \
-	andl %esp, reg
-
 ENTRY(lcall7)
 	pushfl			# We get a different stack layout with call gates,
 	pushl %eax		# which has to be cleaned up later..
@@ -286,6 +305,9 @@
 	movl $(__KERNEL_DS),%edx
 	movl %edx,%ds
 	movl %edx,%es
+	pushl %edi
+	HIGHRES_START_CODE
+	popl %edi
 	GET_CURRENT(%ebx)
 	call *%edi
 	addl $8,%esp
--- ./arch/i386/kernel/time.c.highres	Sat Feb  9 20:46:39 2002
+++ ./arch/i386/kernel/time.c	Mon Feb 11 10:13:28 2002
@@ -715,3 +715,34 @@
 	setup_irq(0, &irq0);
 #endif
 }
+
+#ifdef CONFIG_HIGHRES_CPU_USAGE
+unsigned long curr_timestamp(void)
+{
+	register unsigned long eax, edx;
+	rdtsc(eax,edx);
+	return eax;
+}
+
+unsigned long timestamp_usec_diff(unsigned long ts1, unsigned long ts2)
+{
+	register unsigned long eax, rv;
+
+	/* Read the Time Stamp Counter */
+
+	eax = ts1 - ts2;
+	__asm__("mull %2"
+		:"=a" (eax), "=d" (rv)
+		:"rm" (fast_gettimeoffset_quotient),
+		 "0" (eax));
+
+	if (rv >= 1000000) {
+		/* We had some wierd overflow due to the timebases being
+		   changed, just ignore it. */
+		printk("tb went backwards? ts1=%lu, ts2=%ld\n", ts1, ts2);
+		rv = 0;
+	}
+
+	return rv;
+}
+#endif
--- ./kernel/acct.c.highres	Mon Mar 19 14:35:08 2001
+++ ./kernel/acct.c	Sat Feb  9 17:30:04 2002
@@ -296,8 +296,8 @@
 
 	ac.ac_btime = CT_TO_SECS(current->start_time) + (xtime.tv_sec - (jiffies / HZ));
 	ac.ac_etime = encode_comp_t(jiffies - current->start_time);
-	ac.ac_utime = encode_comp_t(current->times.tms_utime);
-	ac.ac_stime = encode_comp_t(current->times.tms_stime);
+	ac.ac_utime = encode_comp_t(tms_time_to_ticks(current->times.tms_utime));
+	ac.ac_stime = encode_comp_t(tms_time_to_ticks(current->times.tms_stime));
 	ac.ac_uid = current->uid;
 	ac.ac_gid = current->gid;
 	ac.ac_tty = (current->tty) ? kdev_t_to_nr(current->tty->device) : 0;
--- ./kernel/timer.c.highres	Mon Oct  8 12:41:41 2001
+++ ./kernel/timer.c	Mon Feb 11 15:23:55 2002
@@ -518,6 +518,8 @@
 	}
 }
 
+#ifndef CONFIG_HIGHRES_CPU_USAGE
+
 static inline void do_process_times(struct task_struct *p,
 	unsigned long user, unsigned long system)
 {
@@ -549,6 +551,144 @@
 	}
 }
 
+#else /* CONFIG_HIGHRES_CPU_USAGE */
+
+/* This spin lock protects the virtual itimer and tms structures while
+   we are messing with it. */
+rwlock_t virt_itimer_lock = RW_LOCK_UNLOCKED;
+
+/* This is assumed to be called more than once a second. */
+static inline void add_usec_to_timeval(struct timeval *tv,
+				       unsigned long  usecs)
+{
+	tv->tv_usec += usecs;
+	if (tv->tv_usec >= 1000000) {
+		tv->tv_usec -= 1000000;
+		tv->tv_sec += 1;
+	}
+}
+
+/* virt_itimer_lock should be held when this is called. */
+static inline void tms_check_virt(struct task_struct *p,
+				  unsigned long      usecs)
+{
+	struct timeval *it_virt = &(p->it_virt_value);
+
+	if (it_virt->tv_sec || it_virt->tv_usec) {
+		/* This is called every tick, so we don't have to
+                   worry about large values of usecs.  It should be
+                   less than 12ms or so, certainly less than a
+                   second. */
+		if ((it_virt->tv_sec == 0) && (it_virt->tv_usec <= usecs)) {
+			*it_virt = p->it_virt_incr;
+			send_sig(SIGVTALRM, p, 1);
+		} else {
+			it_virt->tv_usec -= usecs;
+			if (it_virt->tv_usec < 0) {
+				it_virt->tv_usec += 1000000;
+				it_virt->tv_sec--;
+			}
+		}
+	}
+}
+
+void tms_task_stopped_running(struct task_struct *p)
+{
+	unsigned long timestamp;
+	unsigned long usecs;
+	unsigned long flags;
+
+	write_lock_irqsave(&virt_itimer_lock, flags);
+	timestamp = curr_timestamp();
+
+	/* We have to be running in system code to call this.  But
+	   when called from a kernel thread, the nest count won't be
+	   correct, so fix it. */
+	if (!p->system_code_nest)
+		p->system_code_nest++;
+
+	usecs = timestamp_usec_diff(timestamp, p->last_timestamp);
+	add_usec_to_timeval(&p->times.tms_stime, usecs);
+
+#ifdef CONFIG_VIRT_ITIMER_COUNTS_SYSTEM
+	tms_check_virt(p, usecs);
+#endif
+	write_unlock_irqrestore(&virt_itimer_lock, flags);
+}
+
+void tms_task_started_running(struct task_struct *p)
+{
+	unsigned long flags;
+
+	write_lock_irqsave(&virt_itimer_lock, flags);
+	p->last_timestamp = curr_timestamp();
+	write_unlock_irqrestore(&virt_itimer_lock, flags);
+}
+
+void tms_update_task_times(struct task_struct *p)
+{
+	unsigned long timestamp;
+	unsigned long usecs;
+	unsigned long flags;
+
+	write_lock_irqsave(&virt_itimer_lock, flags);
+	timestamp = curr_timestamp();
+
+	/* We have to be running in system code to call this. */
+	usecs = timestamp_usec_diff(timestamp, p->last_timestamp);
+	add_usec_to_timeval(&p->times.tms_stime, usecs);
+#ifdef CONFIG_VIRT_ITIMER_COUNTS_SYSTEM
+	tms_check_virt(p, usecs);
+#endif
+	p->last_timestamp = timestamp;
+	write_unlock_irqrestore(&virt_itimer_lock, flags);
+}
+
+asmlinkage void tms_enter_system(struct task_struct *p)
+{
+	unsigned long timestamp;
+	unsigned long usecs;
+	unsigned long flags;
+
+	write_lock_irqsave(&virt_itimer_lock, flags);
+	timestamp = curr_timestamp();
+	if (p->system_code_nest) {
+		p->system_code_nest++;
+	} else {
+		/* Leaving userland. */
+		usecs = timestamp_usec_diff(timestamp, p->last_timestamp);
+		
+		add_usec_to_timeval(&p->times.tms_utime, usecs);
+		tms_check_virt(p, usecs);
+		p->last_timestamp = timestamp;
+		p->system_code_nest = 1;
+	}
+	write_unlock_irqrestore(&virt_itimer_lock, flags);
+}
+
+asmlinkage void tms_leave_system(struct task_struct *p)
+{
+	unsigned long timestamp;
+	unsigned long usecs;
+	unsigned long flags;
+
+	write_lock_irqsave(&virt_itimer_lock, flags);
+	timestamp = curr_timestamp();
+
+	p->system_code_nest--;
+	if (! p->system_code_nest) {
+		/* Returning to userland. */
+		usecs = timestamp_usec_diff(timestamp, p->last_timestamp);
+		add_usec_to_timeval(&p->times.tms_stime, usecs);
+#ifdef CONFIG_VIRT_ITIMER_COUNTS_SYSTEM
+		tms_check_virt(p, usecs);
+#endif
+		p->last_timestamp = timestamp;
+	}
+	write_unlock_irqrestore(&virt_itimer_lock, flags);
+}
+#endif /* CONFIG_HIGHRES_CPU_USAGE */
+
 static inline void do_it_prof(struct task_struct *p)
 {
 	unsigned long it_prof = p->it_prof_value;
@@ -567,8 +707,12 @@
 {
 	p->per_cpu_utime[cpu] += user;
 	p->per_cpu_stime[cpu] += system;
+#ifndef CONFIG_HIGHRES_CPU_USAGE
 	do_process_times(p, user, system);
 	do_it_virt(p, user);
+#else
+	tms_update_task_times(p);
+#endif
 	do_it_prof(p);
 }	
 
--- ./kernel/fork.c.highres	Wed Nov 21 12:18:42 2001
+++ ./kernel/fork.c	Sat Feb  9 17:30:04 2002
@@ -626,15 +626,25 @@
 	p->sigpending = 0;
 	init_sigpending(&p->pending);
 
-	p->it_real_value = p->it_virt_value = p->it_prof_value = 0;
-	p->it_real_incr = p->it_virt_incr = p->it_prof_incr = 0;
+	p->it_real_value = p->it_prof_value = 0;
+	p->it_real_incr = p->it_prof_incr = 0;
+#ifndef CONFIG_HIGHRES_CPU_USAGE
+	p->it_virt_value = p->it_virt_incr = 0;
+#else
+	p->it_virt_value.tv_sec = p->it_virt_value.tv_usec = 0;
+	p->it_virt_incr.tv_sec = p->it_virt_incr.tv_usec = 0;
+	/* We start out in system code. */
+	p->system_code_nest = 1;
+#endif
 	init_timer(&p->real_timer);
 	p->real_timer.data = (unsigned long) p;
 
 	p->leader = 0;		/* session leadership doesn't inherit */
 	p->tty_old_pgrp = 0;
-	p->times.tms_utime = p->times.tms_stime = 0;
-	p->times.tms_cutime = p->times.tms_cstime = 0;
+	init_tms_time(&(p->times.tms_utime));
+	init_tms_time(&(p->times.tms_stime));
+	init_tms_time(&(p->times.tms_cutime));
+	init_tms_time(&(p->times.tms_cstime));
 #ifdef CONFIG_SMP
 	{
 		int i;
--- ./kernel/sys.c.highres	Tue Sep 18 16:10:43 2001
+++ ./kernel/sys.c	Sat Feb  9 17:30:04 2002
@@ -789,6 +789,15 @@
 	return old_fsgid;
 }
 
+static inline void tms_internal_to_tms(struct internal_tms *internal,
+				       struct tms          *external)
+{
+	external->tms_utime = tms_time_to_ticks(internal->tms_utime);
+	external->tms_stime = tms_time_to_ticks(internal->tms_stime);
+	external->tms_cutime = tms_time_to_ticks(internal->tms_cutime);
+	external->tms_cstime = tms_time_to_ticks(internal->tms_cstime);
+}
+
 asmlinkage long sys_times(struct tms * tbuf)
 {
 	/*
@@ -797,9 +806,12 @@
 	 *	atomically safe type this is just fine. Conceptually its
 	 *	as if the syscall took an instant longer to occur.
 	 */
-	if (tbuf)
-		if (copy_to_user(tbuf, &current->times, sizeof(struct tms)))
+	if (tbuf) {
+		struct tms external;
+		tms_internal_to_tms(&current->times, &external);
+		if (copy_to_user(tbuf, &external, sizeof(struct tms)))
 			return -EFAULT;
+	}
 	return jiffies;
 }
 
@@ -1157,32 +1169,35 @@
 	memset((char *) &r, 0, sizeof(r));
 	switch (who) {
 		case RUSAGE_SELF:
-			r.ru_utime.tv_sec = CT_TO_SECS(p->times.tms_utime);
-			r.ru_utime.tv_usec = CT_TO_USECS(p->times.tms_utime);
-			r.ru_stime.tv_sec = CT_TO_SECS(p->times.tms_stime);
-			r.ru_stime.tv_usec = CT_TO_USECS(p->times.tms_stime);
+		        r.ru_utime = tms_time_to_timeval(p->times.tms_utime);
+		        r.ru_stime = tms_time_to_timeval(p->times.tms_stime);
 			r.ru_minflt = p->min_flt;
 			r.ru_majflt = p->maj_flt;
 			r.ru_nswap = p->nswap;
 			break;
 		case RUSAGE_CHILDREN:
-			r.ru_utime.tv_sec = CT_TO_SECS(p->times.tms_cutime);
-			r.ru_utime.tv_usec = CT_TO_USECS(p->times.tms_cutime);
-			r.ru_stime.tv_sec = CT_TO_SECS(p->times.tms_cstime);
-			r.ru_stime.tv_usec = CT_TO_USECS(p->times.tms_cstime);
+		        r.ru_utime = tms_time_to_timeval(p->times.tms_cutime);
+		        r.ru_stime = tms_time_to_timeval(p->times.tms_cstime);
 			r.ru_minflt = p->cmin_flt;
 			r.ru_majflt = p->cmaj_flt;
 			r.ru_nswap = p->cnswap;
 			break;
 		default:
-			r.ru_utime.tv_sec = CT_TO_SECS(p->times.tms_utime + p->times.tms_cutime);
-			r.ru_utime.tv_usec = CT_TO_USECS(p->times.tms_utime + p->times.tms_cutime);
-			r.ru_stime.tv_sec = CT_TO_SECS(p->times.tms_stime + p->times.tms_cstime);
-			r.ru_stime.tv_usec = CT_TO_USECS(p->times.tms_stime + p->times.tms_cstime);
+		{
+		        tms_time tmsv;
+
+			tmsv = add_tms_times(p->times.tms_utime,
+					     p->times.tms_cutime);
+		        r.ru_utime = tms_time_to_timeval(tmsv);
+			tmsv = add_tms_times(p->times.tms_stime,
+					     p->times.tms_cstime);
+		        r.ru_stime = tms_time_to_timeval(tmsv);
+
 			r.ru_minflt = p->min_flt + p->cmin_flt;
 			r.ru_majflt = p->maj_flt + p->cmaj_flt;
 			r.ru_nswap = p->nswap + p->cnswap;
 			break;
+		}
 	}
 	return copy_to_user(ru, &r, sizeof(r)) ? -EFAULT : 0;
 }
--- ./kernel/itimer.c.highres	Thu Jun 29 12:07:36 2000
+++ ./kernel/itimer.c	Sat Feb  9 17:30:04 2002
@@ -58,20 +58,35 @@
 			if ((long) val <= 0)
 				val = 1;
 		}
+		jiffiestotv(val, &value->it_value);
+		jiffiestotv(interval, &value->it_interval);
 		break;
 	case ITIMER_VIRTUAL:
+#ifndef CONFIG_HIGHRES_CPU_USAGE
 		val = current->it_virt_value;
 		interval = current->it_virt_incr;
+		jiffiestotv(val, &value->it_value);
+		jiffiestotv(interval, &value->it_interval);
+#else
+		{
+			unsigned long flags;
+
+			read_lock_irqsave(&virt_itimer_lock, flags);
+			value->it_value = current->it_virt_value;
+			value->it_interval = current->it_virt_incr;
+			read_unlock_irqrestore(&virt_itimer_lock, flags);
+		}
+#endif
 		break;
 	case ITIMER_PROF:
 		val = current->it_prof_value;
 		interval = current->it_prof_incr;
+		jiffiestotv(val, &value->it_value);
+		jiffiestotv(interval, &value->it_interval);
 		break;
 	default:
 		return(-EINVAL);
 	}
-	jiffiestotv(val, &value->it_value);
-	jiffiestotv(interval, &value->it_interval);
 	return 0;
 }
 
@@ -110,12 +125,12 @@
 	register unsigned long i, j;
 	int k;
 
-	i = tvtojiffies(&value->it_interval);
-	j = tvtojiffies(&value->it_value);
 	if (ovalue && (k = do_getitimer(which, ovalue)) < 0)
 		return k;
 	switch (which) {
 		case ITIMER_REAL:
+			i = tvtojiffies(&value->it_interval);
+			j = tvtojiffies(&value->it_value);
 			del_timer_sync(&current->real_timer);
 			current->it_real_value = j;
 			current->it_real_incr = i;
@@ -128,12 +143,28 @@
 			add_timer(&current->real_timer);
 			break;
 		case ITIMER_VIRTUAL:
+#ifndef CONFIG_HIGHRES_CPU_USAGE
+			i = tvtojiffies(&value->it_interval);
+			j = tvtojiffies(&value->it_value);
 			if (j)
 				j++;
 			current->it_virt_value = j;
 			current->it_virt_incr = i;
+#else
+			{
+				unsigned long flags;
+
+				write_lock_irqsave(&virt_itimer_lock, flags);
+				current->it_virt_value = value->it_value;
+				current->it_virt_incr = value->it_interval;
+				write_unlock_irqrestore(&virt_itimer_lock,
+							flags);
+			}
+#endif
 			break;
 		case ITIMER_PROF:
+			i = tvtojiffies(&value->it_interval);
+			j = tvtojiffies(&value->it_value);
 			if (j)
 				j++;
 			current->it_prof_value = j;
--- ./kernel/exit.c.highres	Wed Nov 21 16:42:27 2001
+++ ./kernel/exit.c	Sat Feb  9 17:30:04 2002
@@ -535,8 +535,19 @@
 				}
 				goto end_wait4;
 			case TASK_ZOMBIE:
-				current->times.tms_cutime += p->times.tms_utime + p->times.tms_cutime;
-				current->times.tms_cstime += p->times.tms_stime + p->times.tms_cstime;
+				current->times.tms_cutime
+				    = add_tms_times(current->times.tms_utime,
+						    p->times.tms_utime);
+				current->times.tms_cutime
+				    = add_tms_times(current->times.tms_cutime,
+						    p->times.tms_cutime);
+				current->times.tms_cstime
+				    = add_tms_times(current->times.tms_stime,
+						    p->times.tms_stime);
+				current->times.tms_cstime
+				    = add_tms_times(current->times.tms_cstime,
+						    p->times.tms_cstime);
+
 				read_unlock(&tasklist_lock);
 				retval = ru ? getrusage(p, RUSAGE_BOTH, ru) : 0;
 				if (!retval && stat_addr)
--- ./kernel/signal.c.highres	Wed Nov 21 18:26:27 2001
+++ ./kernel/signal.c	Sat Feb  9 17:30:04 2002
@@ -742,8 +742,8 @@
 	info.si_uid = tsk->uid;
 
 	/* FIXME: find out whether or not this is supposed to be c*time. */
-	info.si_utime = tsk->times.tms_utime;
-	info.si_stime = tsk->times.tms_stime;
+	info.si_utime = tms_time_to_ticks(tsk->times.tms_utime);
+	info.si_stime = tms_time_to_ticks(tsk->times.tms_stime);
 
 	status = tsk->exit_code & 0x7f;
 	why = SI_KERNEL;	/* shouldn't happen */
--- ./kernel/sched.c.highres	Thu Jan 10 15:52:14 2002
+++ ./kernel/sched.c	Sat Feb  9 17:30:04 2002
@@ -694,6 +694,8 @@
 	 * This just switches the register state and the
 	 * stack.
 	 */
+	tms_task_stopped_running(prev);
+	tms_task_started_running(next);
 	switch_to(prev, next, prev);
 	__schedule_tail(prev);
 
--- ./Documentation/Configure.help.highres	Thu Jan 10 15:52:12 2002
+++ ./Documentation/Configure.help	Sat Feb  9 17:30:04 2002
@@ -19794,6 +19794,19 @@
 
   "Area6" will work for most boards. For ADX, select "Area5".
 
+High resolution CPU usage and virtual itimers
+CONFIG_HIGHRES_CPU_USAGE
+  If you say Y here, the cpu usage tracked for programs and virtual itimers
+  will be much higher precision.  The downside of this is that the system
+  call overhead will go up some (every entry into and out of the kernel must
+  be tracked).  Also, the architecture must support high-res timers of
+  some kind and the support must be added to the architecture code.
+
+Does the virtual itimer count system CPU usage?
+CONFIG_VIRT_ITIMER_COUNTS_SYSTEM
+  If highres CPU is counted, this sets whether virtual itimers count system
+  CPU used towards the amount of CPU until the virtual timer goes off.
+
 #
 # m68k-specific kernel options
 # Documented by Chris Lawrence <mailto:quango@themall.net> et al.
--- ./include/linux/sched.h.highres	Sun Jan 13 14:52:51 2002
+++ ./include/linux/sched.h	Sun Feb 10 20:19:05 2002
@@ -278,6 +278,124 @@
 extern struct user_struct root_user;
 #define INIT_USER (&root_user)
 
+#ifndef CONFIG_HIGHRES_CPU_USAGE
+typedef clock_t tms_time;
+#else
+typedef struct timeval tms_time;
+#endif
+
+struct internal_tms {
+        tms_time tms_utime;
+	tms_time tms_stime;
+	tms_time tms_cutime;
+	tms_time tms_cstime;
+};
+
+#ifndef CONFIG_HIGHRES_CPU_USAGE
+static inline clock_t tms_time_to_ticks(tms_time tv)
+{
+	return tv;
+}
+
+static inline tms_time add_tms_times(tms_time tv1, tms_time tv2)
+{
+	return tv1 + tv2;
+}
+
+static inline void init_tms_time(tms_time *tv)
+{
+	*tv = 0;
+}
+
+static inline struct timeval tms_time_to_timeval(tms_time tv)
+{
+	struct timeval rv;
+
+	rv.tv_sec = CT_TO_SECS(tv);
+	rv.tv_usec = CT_TO_USECS(tv);
+	return rv;
+}
+
+/* Called when a running task is stopped. */
+#define tms_task_stopped_running(p)
+
+/* Called when a task that was not running is started. */
+#define tms_task_started_running(p)
+
+/* Called periodically in case a task is taking all the CPU to avoid
+   curr_usec_time() overflowing. */
+#define tms_update_task_times(p)
+
+#else
+
+/* This spin lock protects the virtual itimer structure while we are
+   messing with it. */
+extern rwlock_t virt_itimer_lock;
+
+static inline clock_t tms_time_to_ticks(tms_time tv)
+{
+	clock_t ticks;
+
+	ticks = tv.tv_sec * HZ;
+	ticks += tv.tv_usec / (1000000 / HZ);
+	return ticks;
+}
+
+static inline tms_time add_tms_times(tms_time tv1,
+				     tms_time tv2)
+{
+	tms_time rv;
+
+	rv.tv_sec = tv1.tv_sec + tv2.tv_sec;
+	rv.tv_usec = tv1.tv_usec + tv2.tv_usec;
+	if (rv.tv_usec >= 1000000) {
+		rv.tv_usec -= 1000000;
+		rv.tv_sec += 1;
+	}
+
+	return rv;
+}
+
+static inline void init_tms_time(tms_time *tv)
+{
+	tv->tv_sec = 0;
+	tv->tv_usec = 0;
+}
+
+static inline struct timeval tms_time_to_timeval(tms_time tv)
+{
+	return tv;
+}
+
+/* Return a current timestamp from the architecture. */
+extern unsigned long curr_timestamp(void);
+
+/* Return the difference in microseconds of ts1-ts2.  This is called
+   by the highres usage time code to get microsecond resolution from
+   some highres clock. */
+extern unsigned long timestamp_usec_diff(unsigned long ts1, unsigned long ts2);
+
+struct task_struct;
+
+/* Called when a running task is stopped. */
+void tms_task_stopped_running(struct task_struct *p);
+
+/* Called when a task that was not running is started. */
+void tms_task_started_running(struct task_struct *p);
+
+/* Called periodically in case a task is taking all the CPU to avoid
+   curr_usec_time() overflowing. */
+void tms_update_task_times(struct task_struct *p);
+
+/* Called when we enter system code for a process. */
+void tms_enter_system(struct task_struct *p);
+
+/* Called when leave system code for a process. */
+void tms_leave_system(struct task_struct *p);
+
+#endif
+
+
 struct task_struct {
 	/*
 	 * offsets of these are hardcoded elsewhere - touch with care
@@ -355,10 +473,22 @@
 	wait_queue_head_t wait_chldexit;	/* for wait4() */
 	struct completion *vfork_done;		/* for vfork() */
 	unsigned long rt_priority;
-	unsigned long it_real_value, it_prof_value, it_virt_value;
-	unsigned long it_real_incr, it_prof_incr, it_virt_incr;
+	unsigned long it_real_value, it_prof_value;
+#ifndef CONFIG_HIGHRES_CPU_USAGE
+        unsigned long it_virt_value;
+#else
+        struct timeval it_virt_value;
+        unsigned long last_timestamp;   /* The last usec time taken for the process. */
+        unsigned long system_code_nest; /* How nested am I in system code? */
+#endif
+        unsigned long it_real_incr, it_prof_incr;
+#ifndef CONFIG_HIGHRES_CPU_USAGE
+        unsigned long it_virt_incr;
+#else
+        struct timeval it_virt_incr;
+#endif
 	struct timer_list real_timer;
-	struct tms times;
+	struct internal_tms times;
 	unsigned long start_time;
 	long per_cpu_utime[NR_CPUS], per_cpu_stime[NR_CPUS];
 /* mm fault and swap info: this can arguably be seen as either mm-specific or thread-specific */
@@ -451,6 +581,12 @@
 #define DEF_NICE	(0)
 
 
+#ifdef CONFIG_HIGHRES_CPU_USAGE
+#define INIT_SYSTEM_CODE_NEST	system_code_nest:		1,
+#else
+#define INIT_SYSTEM_CODE_NEST
+#endif
+
 /*
  * The default (Linux) execution domain.
  */
@@ -501,6 +637,7 @@
     blocked:		{{0}},						\
     alloc_lock:		SPIN_LOCK_UNLOCKED,				\
     journal_info:	NULL,						\
+    INIT_SYSTEM_CODE_NEST						\
 }
 
 
--- ./include/asm-i386/hw_irq.h.highres	Mon Feb 11 15:10:39 2002
+++ ./include/asm-i386/hw_irq.h	Mon Feb 11 15:19:50 2002
@@ -95,6 +95,22 @@
 #define __STR(x) #x
 #define STR(x) __STR(x)
 
+#define GET_CURRENT \
+	"movl %esp, %ebx\n\t" \
+	"andl $-8192, %ebx\n\t"
+
+#ifdef CONFIG_HIGHRES_CPU_USAGE
+#define HIGHRES_START_CODE \
+	"pushl %eax\n\t"		          \
+	GET_CURRENT				  \
+	"pushl %ebx\n\t"			  \
+	"call  " SYMBOL_NAME_STR(tms_enter_system) "\n\t" \
+	"addl  $4,%esp\n\t"			  \
+	"popl %eax\n\t" 
+#else
+#define HIGHRES_START_CODE
+#endif
+
 #define SAVE_ALL \
 	"cld\n\t" \
 	"pushl %es\n\t" \
@@ -108,14 +124,11 @@
 	"pushl %ebx\n\t" \
 	"movl $" STR(__KERNEL_DS) ",%edx\n\t" \
 	"movl %edx,%ds\n\t" \
-	"movl %edx,%es\n\t"
+	"movl %edx,%es\n\t" \
+        HIGHRES_START_CODE
 
 #define IRQ_NAME2(nr) nr##_interrupt(void)
 #define IRQ_NAME(nr) IRQ_NAME2(IRQ##nr)
-
-#define GET_CURRENT \
-	"movl %esp, %ebx\n\t" \
-	"andl $-8192, %ebx\n\t"
 
 /*
  *	SMP has a few special interrupts for IPI messages

what replaces tq_scheduler in 2.4

[Wanghong Yuan]

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

Re: what replaces tq_scheduler in 2.4

[Andrew Morton]

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.

-

Re: what replaces tq_scheduler in 2.4

[Ingo Oeser]

Hi Andrew,
hi others,

On Tue, Apr 30, 2002 at 03:31:21PM -0700, Andrew Morton wrote:
> 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. 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.

What is the main difference between tq_immediate and the former
tq_scheduler?

I would like to know, whether I can convert my old bh routines[1] to
that new mechanism.

Thanks & Regards

Ingo Oeser

[1] Note to German readers: I mean interrupt backends! Nothing
   else :-)
-- 
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth

Re: what replaces tq_scheduler in 2.4

[Wanghong Yuan]

HI, Ingo

Did you get the answer? Please cc me


> Hi Andrew,
> hi others,
>
> On Tue, Apr 30, 2002 at 03:31:21PM -0700, Andrew Morton wrote:
> > 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. 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.
>
> What is the main difference between tq_immediate and the former
> tq_scheduler?
>
> I would like to know, whether I can convert my old bh routines[1] to
> that new mechanism.
>
> Thanks & Regards
>
> Ingo Oeser
>
> [1] Note to German readers: I mean interrupt backends! Nothing
>    else :-)
> --
> Science is what we can tell a computer. Art is everything else. ---
D.E.Knuth
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: what replaces tq_scheduler in 2.4

[Andrew Morton]

Ingo Oeser wrote:
> 
> ...
> What is the main difference between tq_immediate and the former
> tq_scheduler?

tq_immediate looks to be some very old piece of kernel infrastructure
which is somewhat obsolete but all the users have not been converted
to yet.  May run in interrupt context.  

tq_scheduler callbacks run in process context.  Use schedule_task()
instead.

These mechanisms are discussed in the Rubini/Corbet bible:
http://www.xml.com/ldd/chapter/book/

suspend a thread in LKM

[Wanghong Yuan]

Hi,

I am currently working a scheduling algorithm, implemented with a LKM. The
basic probelm is to control a thread (user-level) to run for x time units
every y. After x, it should wait until next y.

My current problem is that how can I let the thread wait (sleep) until next
y? I think I should put the thread in a unrunable state, and then enable it
when next y comes.  But how?

Thanks alot in advance.

w.h.y

Re: VLAN and Network Drivers 2.4.x

[jd]

> Von: <davem@redhat.com>
> 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

Re: VLAN and Network Drivers 2.4.x

[Matthias Andree]

On Wed, 24 Apr 2002, David S. Miller wrote:

>    From: jd@epcnet.de
>    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

Re: AW: Re: VLAN and Network Drivers 2.4.x

[Pasi Kärkkäinen]

On Wed, 24 Apr 2002 jd@epcnet.de wrote:

> > Von: <davem@redhat.com>
> > 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 <i@stingr.net>
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.

Re: VLAN and Network Drivers 2.4.x

[Ben Greear]

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

jd@epcnet.de 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 


-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

AW: Re: VLAN and Network Drivers 2.4.x

[jd]

> Von: <greearb@candelatech.com>
> 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.