[RFC] must fix lists

[RFC] must fix lists

[Nick Piggin]

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

The following people have their names in Documentation/must-fix.txt. Lots
of others in should-fix.txt in 2.6.0-test8-mm1. Please review your entries.
Also, please add any other substantial changes you need before 2.6. Thanks.

Al Viro
Alan
Albert Cahalan
Andi
Badari Pulavarty
brodo
Dave M
Dipankar
hch
hollisb
Ingo
James B
Jens
lmb
Mike Anderson
Patrick Mansfield
rmk
Rusty
Trond

(Maybe missed a couple)


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

 linux-2.6-npiggin/Documentation/must-fix.txt   |   44 -------------------------
 linux-2.6-npiggin/Documentation/should-fix.txt |   20 -----------
 2 files changed, 64 deletions(-)

diff -puN Documentation/must-fix.txt~mustfix Documentation/must-fix.txt
--- linux-2.6/Documentation/must-fix.txt~mustfix	2003-10-20 19:37:24.000000000 +1000
+++ linux-2.6-npiggin/Documentation/must-fix.txt	2003-10-20 20:06:26.000000000 +1000
@@ -13,17 +13,9 @@ o TTY locking is broken.
 
   o somebody will have to document the tty driver and ldisc API
 
-o Lack of test cases and/or stress tests is a problem.  Contributions and
-  suggestions are sought.
-
-o Lots of drivers are using cli/sti and are broken.
-
 drivers/tty
 ~~~~~~~~~~~
 
-o viro: we need to fix refcounting for tty_driver (oopsable race, must fix
-  anyway, hopefully about a week until it's merged) then we can do
-  tty/misc/upper levels of sound.
 
 drivers/block/
 ~~~~~~~~~~~~~~
@@ -33,16 +25,6 @@ o ideraid hasn't been ported to 2.5 at a
   We need to understand whether the proposed BIO split code will suffice
   for this.
 
-o CD burning.  There are still a few quirks to solve wrt SG_IO and ide-cd.
-
-  Jens: The basic hang has been solved (double fault in ide-cd), there still
-  seems to be some cases that don't work too well.  Don't really have a
-  handle on those :/
-
-o lmb: Last time I looked at the multipath code (2.5.50 or so) it also
-  looked pretty broken; I plan to port forward the changes we did on 2.4
-  before KS.
-
 drivers/input/
 ~~~~~~~~~~~~~~
 
@@ -55,20 +37,6 @@ o viro: parport is nearly as bad as that
   IMO parport is more of "figure out what API changes are needed for its
   users, get them done ASAP, then fix generic layer at leisure"
 
-o (Albert Cahalan) Lots of people (check Google) get this message from the
-  kernel:
-
-  psmouse.c: Lost synchronization, throwing 2 bytes away.
-
-  (the number of bytes will be 1, 2, or 3)
-
-  At work, I get it when there is heavy NFS traffic.  The mouse goes crazy,
-  jumping around and doing random cut-and-paste all over everything.  This
-  is with a decently fast and modern PC.
-
-o There seem to be too many reports of keyboards and mice failing or acting
-  strangely.
-
 
 drivers/misc/
 ~~~~~~~~~~~~~
@@ -84,14 +52,6 @@ o viro: actually, misc.c has a good chan
 drivers/net/
 ~~~~~~~~~~~~
 
-o rmk: network drivers.  ARM people like to add tonnes of #ifdefs into
-  these to customise them to their hardware platform (eg, chip access
-  methods, addresses, etc.) I cope with this by not integrating them into my
-  tree.  The result is that many ARM platforms can't be built from even my
-  tree without extra patches.  This isn't sane, and has bred a culture of
-  network drivers not being submitted.  I don't see this changing for 2.6
-  though.
-
 drivers/net/irda/
 ~~~~~~~~~~~~~~~~~
 
@@ -348,7 +308,3 @@ o A couple of hundred real looking bugzi
 o viro: cdev rework.  Main group is pretty stable and I hope to feed it to
   Linus RSN.  That's cdev-cidr and ->i_cdev/->i_cindex stuff
 
-o Athlon prefetch oopses sometimes.  It is currently disabled, and needs to
-  be fixed.
-
-
diff -puN Documentation/should-fix.txt~mustfix Documentation/should-fix.txt
--- linux-2.6/Documentation/should-fix.txt~mustfix	2003-10-20 19:37:27.000000000 +1000
+++ linux-2.6-npiggin/Documentation/should-fix.txt	2003-10-20 20:21:24.000000000 +1000
@@ -10,12 +10,6 @@ PRI3:	Not very important
 drivers/block/
 ~~~~~~~~~~~~~~
 
-o Framework for selecting IO schedulers.  This is the main one really. 
-  Once this is in place we can drop in new schedulers any old time, no risk.
-  Nick Piggin has code for this.
-
-  PRI1
-
 o viro: paride drivers need a big cleanup
 
   PRI2
@@ -145,13 +139,6 @@ o (Trond:) Yes: I'm still working on an 
 
    PRI2 (?)
 
-o (Chuck Lever <cel@citi.umich.edu>): NFS O_DIRECT support must be
-  completed.  The best approach is to fall back to something like the 2.4 NFS
-  O_DIRECT support, which issues RPCs synchronously and uses the RPC
-  completion mechanism to wait for I/O completion.
-
-  PRI2
-
 o viro: cleaning up options-parsers in filesystems.  (patch exists, needs
   porting).
 
@@ -200,9 +187,6 @@ o klibc merge?
 mm/
 ~~~
 
-o objrmap: concerns over page reclaim performance at high sharing levels,
-  and interoperation with nonlinear mappings is hairy.
-
 o oxymoron's async write-error-handling patch
 
   PRI1
@@ -514,10 +498,6 @@ o NMI watchdog seems to tick too fast
 
   PRI2
 
-o not very well tested. probably more bugs lurking.
-
-  PRI1
-
 o need to coredump 64bit vsyscall code with dwarf2
 
   PRI2

_

Re: [RFC] must fix lists

[Lars Marowsky-Bree]

On 2003-10-21T15:46:27,
   Nick Piggin <piggin@cyberone.com.au> said:

The multipath module will be (outcome of KS) implemented as a
device-mapper personality, which Sistina / Joe are developing. So,
luckily, I'm sort of out of the loop of the "must fix" list, but I'll
hopefully have some of the issues on my "will fix" list anyway ;-)


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering	      \ ever tried. ever failed. no matter.
SUSE Labs			      | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ 	-- Samuel Beckett

Re: [RFC] must fix lists

[Randy.Dunlap]

On Tue, 21 Oct 2003 15:46:27 +1000 Nick Piggin <piggin@cyberone.com.au> wrote:

| The following people have their names in Documentation/must-fix.txt. Lots
| of others in should-fix.txt in 2.6.0-test8-mm1. Please review your entries.
| Also, please add any other substantial changes you need before 2.6. Thanks.


In the should-fix.txt file:

o viro: cleaning up options-parsers in filesystems.  (patch exists, needs
  porting).

The parser lib functions are merged and approx. 15 filesystems
have been converted to use it, so this could be changed to:

o viro: convert more filesystems to use lib/parser.c for parsing options
(still PRI2 I suppose)

--
~Randy

Re: [RFC] must fix lists

[Nick Piggin]

Lars Marowsky-Bree wrote:

>On 2003-10-21T15:46:27,
>   Nick Piggin <piggin@cyberone.com.au> said:
>
>The multipath module will be (outcome of KS) implemented as a
>device-mapper personality, which Sistina / Joe are developing. So,
>luckily, I'm sort of out of the loop of the "must fix" list, but I'll
>hopefully have some of the issues on my "will fix" list anyway ;-)
>

OK so that means it can go in any time really, right? So it can
be removed from the list. Thanks.

Re: [RFC] must fix lists

[Albert Cahalan]

On Tue, 2003-10-21 at 01:46, Nick Piggin wrote:

> -o (Albert Cahalan) Lots of people (check Google) get this message from the
> -  kernel:
> -
> -  psmouse.c: Lost synchronization, throwing 2 bytes away.
> -
> -  (the number of bytes will be 1, 2, or 3)
> -
> -  At work, I get it when there is heavy NFS traffic.  The mouse goes crazy,
> -  jumping around and doing random cut-and-paste all over everything.  This
> -  is with a decently fast and modern PC.

I'm pretty sure this problem is NOT fixed and is NOT
related to the problems with support for some oddball
touchpad thing.

The system in question would also lose time when
under heavy load. Note that HZ is now 1000 HZ.
If interrupts are kept off for too long or an
SMI grabs the CPU...

Another infuriating symptom is that, when Linux
detects that the TSC doesn't match jiffies, the
TSC usage is turned off. There goes the only GOOD
time source, tossed aside in favor of a bad one.
Fix for that: if jiffies fall behind the TSC,
trust the TSC -- you've lost some clock ticks.

Re: [RFC] must fix lists

[Alan Cox]

On Maw, 2003-10-21 at 06:46, Nick Piggin wrote:
> The following people have their names in Documentation/must-fix.txt. Lots

Someone also needs to go fix all the 2.4 security holes still in 2.6
last time I checked - things like the execve holes and execve versus
proc races.

Re: [RFC] must fix lists

[Alan Cox]

On Mer, 2003-10-22 at 03:50, Albert Cahalan wrote:
> The system in question would also lose time when
> under heavy load. Note that HZ is now 1000 HZ.
> If interrupts are kept off for too long or an
> SMI grabs the CPU...

With a lot of laptops this is a huge problem. Its one of the reasons Red
Hat went back to 100Hz in the RH 2.4 tree. With many laptops your clock
becomes junk at 1Khz. It will be interesting to see if the ACPI timers
help but that wont solve things for older laptops.

BTW another one for the list might be the SiS IRQ routing fixes from 2.4
if not merged otherwise newer sis and some older intel wont work
properly.

Re: [RFC] must fix lists

[Nick Piggin]

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



Alan Cox wrote:

>On Maw, 2003-10-21 at 06:46, Nick Piggin wrote:
>
>>The following people have their names in Documentation/must-fix.txt. Lots
>>
>
>Someone also needs to go fix all the 2.4 security holes still in 2.6
>last time I checked - things like the execve holes and execve versus
>proc races.
>
>

I put your name down for that entry Alan. I don't know who else is
aware of all the problems.

OK, a new patch. Includes everyone's suggestions. If anyone wants to
be removed from the CC list please email me privately.


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

 linux-2.6-npiggin/Documentation/must-fix.txt   |   37 ++++---------------------
 linux-2.6-npiggin/Documentation/should-fix.txt |   23 ---------------
 2 files changed, 7 insertions(+), 53 deletions(-)

diff -puN Documentation/must-fix.txt~mustfix Documentation/must-fix.txt
--- linux-2.6/Documentation/must-fix.txt~mustfix	2003-10-24 09:28:12.000000000 +1000
+++ linux-2.6-npiggin/Documentation/must-fix.txt	2003-10-24 09:38:22.000000000 +1000
@@ -13,17 +13,9 @@ o TTY locking is broken.
 
   o somebody will have to document the tty driver and ldisc API
 
-o Lack of test cases and/or stress tests is a problem.  Contributions and
-  suggestions are sought.
-
-o Lots of drivers are using cli/sti and are broken.
-
 drivers/tty
 ~~~~~~~~~~~
 
-o viro: we need to fix refcounting for tty_driver (oopsable race, must fix
-  anyway, hopefully about a week until it's merged) then we can do
-  tty/misc/upper levels of sound.
 
 drivers/block/
 ~~~~~~~~~~~~~~
@@ -33,16 +25,6 @@ o ideraid hasn't been ported to 2.5 at a
   We need to understand whether the proposed BIO split code will suffice
   for this.
 
-o CD burning.  There are still a few quirks to solve wrt SG_IO and ide-cd.
-
-  Jens: The basic hang has been solved (double fault in ide-cd), there still
-  seems to be some cases that don't work too well.  Don't really have a
-  handle on those :/
-
-o lmb: Last time I looked at the multipath code (2.5.50 or so) it also
-  looked pretty broken; I plan to port forward the changes we did on 2.4
-  before KS.
-
 drivers/input/
 ~~~~~~~~~~~~~~
 
@@ -84,14 +66,6 @@ o viro: actually, misc.c has a good chan
 drivers/net/
 ~~~~~~~~~~~~
 
-o rmk: network drivers.  ARM people like to add tonnes of #ifdefs into
-  these to customise them to their hardware platform (eg, chip access
-  methods, addresses, etc.) I cope with this by not integrating them into my
-  tree.  The result is that many ARM platforms can't be built from even my
-  tree without extra patches.  This isn't sane, and has bred a culture of
-  network drivers not being submitted.  I don't see this changing for 2.6
-  though.
-
 drivers/net/irda/
 ~~~~~~~~~~~~~~~~~
 
@@ -333,11 +307,16 @@ o rmk: need to complete ALSA-ification o
 global
 ~~~~~~
 
+o alan, Albert Cahalan: 1000 HZ timer increases the need for a stable time
+  source. Many laptops, SMI can lose ticks. ACPI timers? TSC?
+
 o 64-bit dev_t.  Seems almost ready, but it's not really known how much
   work is still to do.  Patches exist in -mm but with the recent rise of the
   neo-viro I'm not sure where things are at.
 
-o Lots of 2.4 fixes including some security are not in 2.5
+o alan: Forward port 2.4 fixes
+  - Security fixes including execve holes, execve vs proc races
+  - SiS IRQ routing for newer SiS and older Intel
 
 o There are about 60 or 70 security related checks that need doing
   (copy_user etc) from Stanford tools.  (badari is looking into this, and
@@ -348,7 +327,3 @@ o A couple of hundred real looking bugzi
 o viro: cdev rework.  Main group is pretty stable and I hope to feed it to
   Linus RSN.  That's cdev-cidr and ->i_cdev/->i_cindex stuff
 
-o Athlon prefetch oopses sometimes.  It is currently disabled, and needs to
-  be fixed.
-
-
diff -puN Documentation/should-fix.txt~mustfix Documentation/should-fix.txt
--- linux-2.6/Documentation/should-fix.txt~mustfix	2003-10-24 09:28:12.000000000 +1000
+++ linux-2.6-npiggin/Documentation/should-fix.txt	2003-10-24 09:29:55.000000000 +1000
@@ -10,12 +10,6 @@ PRI3:	Not very important
 drivers/block/
 ~~~~~~~~~~~~~~
 
-o Framework for selecting IO schedulers.  This is the main one really. 
-  Once this is in place we can drop in new schedulers any old time, no risk.
-  Nick Piggin has code for this.
-
-  PRI1
-
 o viro: paride drivers need a big cleanup
 
   PRI2
@@ -145,15 +139,7 @@ o (Trond:) Yes: I'm still working on an 
 
    PRI2 (?)
 
-o (Chuck Lever <cel@citi.umich.edu>): NFS O_DIRECT support must be
-  completed.  The best approach is to fall back to something like the 2.4 NFS
-  O_DIRECT support, which issues RPCs synchronously and uses the RPC
-  completion mechanism to wait for I/O completion.
-
-  PRI2
-
-o viro: cleaning up options-parsers in filesystems.  (patch exists, needs
-  porting).
+o viro: convert more filesystems to use lib/parser.c for options.
 
   PRI2
 
@@ -200,9 +186,6 @@ o klibc merge?
 mm/
 ~~~
 
-o objrmap: concerns over page reclaim performance at high sharing levels,
-  and interoperation with nonlinear mappings is hairy.
-
 o oxymoron's async write-error-handling patch
 
   PRI1
@@ -514,10 +497,6 @@ o NMI watchdog seems to tick too fast
 
   PRI2
 
-o not very well tested. probably more bugs lurking.
-
-  PRI1
-
 o need to coredump 64bit vsyscall code with dwarf2
 
   PRI2

_

Re: [RFC] must fix lists

[Chris Wright]

* Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
> On Maw, 2003-10-21 at 06:46, Nick Piggin wrote:
> > The following people have their names in Documentation/must-fix.txt. Lots
> 
> Someone also needs to go fix all the 2.4 security holes still in 2.6
> last time I checked - things like the execve holes and execve versus
> proc races.

I thought these had been fixed, but I'd be happy to take a look.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [RFC] must fix lists

[Albert Cahalan]

On Thu, 2003-10-23 at 19:46, Nick Piggin wrote:
 
> +o alan, Albert Cahalan: 1000 HZ timer increases the need for a stable time
> +  source. Many laptops, SMI can lose ticks. ACPI timers? TSC?

Oh, I have an example for you.

Consider the Intel Plumas chipset. There are
some predictable time windows during which the
RTC will return garbage. The BIOS "fix" leads to
SMI/SMM stuff stealing large chunks of CPU time.
On a logic analyser, somebody at work observed
chunks of time as large as 4 ms. That's 3 to 5
clock ticks. Maybe that isn't worst-case even.

To avoid this disaster, Linux must _never_ touch
the RTC registers. The HPET can be used instead.
The TSC is of course also reliable, but Linux
stops using it as soon as a problem hits!

The ignore-the-TSC code really should be doing
just the opposite. Ticks are likely to be lost.
I've never seen an unstable TSC. :-)

>  o 64-bit dev_t.  Seems almost ready, but it's not really known how much
>    work is still to do.  Patches exist in -mm but with the recent rise of the
>    neo-viro I'm not sure where things are at.

Hey, 32-bit dev_t is in already. That's it. Done.

Re: [RFC] must fix lists

[viro]

On Fri, Oct 24, 2003 at 09:46:33AM +1000, Nick Piggin wrote:
>  drivers/tty
>  ~~~~~~~~~~~
>  
> -o viro: we need to fix refcounting for tty_driver (oopsable race, must fix
> -  anyway, hopefully about a week until it's merged) then we can do
> -  tty/misc/upper levels of sound.

Still not completely fixed.
  
>  o 64-bit dev_t.  Seems almost ready, but it's not really known how much
>    work is still to do.  Patches exist in -mm but with the recent rise of the
>    neo-viro I'm not sure where things are at.

32-bit dev_t is done, 64-bit means extra work on nfsd/raid/etc. for those who
are really interested.  Not a mustfix for 2.6.0.
  
>  o viro: cdev rework.  Main group is pretty stable and I hope to feed it to
>    Linus RSN.  That's cdev-cidr and ->i_cdev/->i_cindex stuff

Mostly done.
  
>  o viro: paride drivers need a big cleanup

Partially done, but ATAPI drivers will need serious work.  There are
real bugs, BTW - it's not just that code is ugly as hell.

Re: [RFC] must fix lists

[Alan Cox]

On Gwe, 2003-10-24 at 01:23, Chris Wright wrote:
> > Someone also needs to go fix all the 2.4 security holes still in 2.6
> > last time I checked - things like the execve holes and execve versus
> > proc races.
> 
> I thought these had been fixed, but I'd be happy to take a look.

I got mail from a guy at intel implying the unshare_files stuff wasnt in
2.6 yet

[RFC][PATCH] must fix lists

[Nick Piggin]

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

OK, I have incorporated comments. If everyone could try to keep your entries
on the list up to date it would be nice. It might give you a bit more
bargaining power to get things in.

I'll continue to try to keep things together until people get sick of it,
but its not easy working out exactly where people are up to with most 
things.

Everyone has to work extra hard to clear this list for 2.6.0, but that
doesn't look realistic. Hopefully it can be done before 2.7 branches. I
guess the security fixes audit is the most important thing for 2.6.0.


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

 l-2.6-npiggin/Documentation/must-fix.txt   |   49 +++++++----------------------
 l-2.6-npiggin/Documentation/should-fix.txt |   26 +--------------
 2 files changed, 16 insertions(+), 59 deletions(-)

diff -puN Documentation/must-fix.txt~mustfix Documentation/must-fix.txt
--- l-2.6/Documentation/must-fix.txt~mustfix	2003-10-27 23:33:03.000000000 +1100
+++ l-2.6-npiggin/Documentation/must-fix.txt	2003-10-27 23:39:48.000000000 +1100
@@ -13,17 +13,11 @@ o TTY locking is broken.
 
   o somebody will have to document the tty driver and ldisc API
 
-o Lack of test cases and/or stress tests is a problem.  Contributions and
-  suggestions are sought.
-
-o Lots of drivers are using cli/sti and are broken.
-
 drivers/tty
 ~~~~~~~~~~~
 
-o viro: we need to fix refcounting for tty_driver (oopsable race, must fix
-  anyway, hopefully about a week until it's merged) then we can do
-  tty/misc/upper levels of sound.
+o viro: tty_driver refcounting, tty/misc/upper levels of sound still not
+  completely fixed.
 
 drivers/block/
 ~~~~~~~~~~~~~~
@@ -33,16 +27,6 @@ o ideraid hasn't been ported to 2.5 at a
   We need to understand whether the proposed BIO split code will suffice
   for this.
 
-o CD burning.  There are still a few quirks to solve wrt SG_IO and ide-cd.
-
-  Jens: The basic hang has been solved (double fault in ide-cd), there still
-  seems to be some cases that don't work too well.  Don't really have a
-  handle on those :/
-
-o lmb: Last time I looked at the multipath code (2.5.50 or so) it also
-  looked pretty broken; I plan to port forward the changes we did on 2.4
-  before KS.
-
 drivers/input/
 ~~~~~~~~~~~~~~
 
@@ -84,14 +68,6 @@ o viro: actually, misc.c has a good chan
 drivers/net/
 ~~~~~~~~~~~~
 
-o rmk: network drivers.  ARM people like to add tonnes of #ifdefs into
-  these to customise them to their hardware platform (eg, chip access
-  methods, addresses, etc.) I cope with this by not integrating them into my
-  tree.  The result is that many ARM platforms can't be built from even my
-  tree without extra patches.  This isn't sane, and has bred a culture of
-  network drivers not being submitted.  I don't see this changing for 2.6
-  though.
-
 drivers/net/irda/
 ~~~~~~~~~~~~~~~~~
 
@@ -176,6 +152,8 @@ o rmk: I have a pending todo: I need to 
 
 o James B: USB hot-removal crash: "It's a known scsi refcounting issue."
 
+o James B: refcounting issues in SCSI and in the block layer.
+
 fs/
 ~~~
 
@@ -333,11 +311,15 @@ o rmk: need to complete ALSA-ification o
 global
 ~~~~~~
 
-o 64-bit dev_t.  Seems almost ready, but it's not really known how much
-  work is still to do.  Patches exist in -mm but with the recent rise of the
-  neo-viro I'm not sure where things are at.
+o alan, Albert Cahalan: 1000 HZ timer increases the need for a stable time
+  source. Many laptops, SMI can lose ticks. ACPI timers? TSC?
+
+o viro: 64-bit dev_t (not a mustfix for 2.6.0). 32-bit dev_t is done, 64-bit
+  means extra work on nfsd/raid/etc.
 
-o Lots of 2.4 fixes including some security are not in 2.5
+o alan: Forward port 2.4 fixes
+  - Security fixes including execve holes, execve vs proc races
+  - SiS IRQ routing for newer SiS and older Intel
 
 o There are about 60 or 70 security related checks that need doing
   (copy_user etc) from Stanford tools.  (badari is looking into this, and
@@ -345,10 +327,5 @@ o There are about 60 or 70 security rela
 
 o A couple of hundred real looking bugzilla bugs
 
-o viro: cdev rework.  Main group is pretty stable and I hope to feed it to
-  Linus RSN.  That's cdev-cidr and ->i_cdev/->i_cindex stuff
-
-o Athlon prefetch oopses sometimes.  It is currently disabled, and needs to
-  be fixed.
-
+o viro: cdev rework. Mostly done.
 
diff -puN Documentation/should-fix.txt~mustfix Documentation/should-fix.txt
--- l-2.6/Documentation/should-fix.txt~mustfix	2003-10-27 23:33:03.000000000 +1100
+++ l-2.6-npiggin/Documentation/should-fix.txt	2003-10-27 23:36:43.000000000 +1100
@@ -10,13 +10,8 @@ PRI3:	Not very important
 drivers/block/
 ~~~~~~~~~~~~~~
 
-o Framework for selecting IO schedulers.  This is the main one really. 
-  Once this is in place we can drop in new schedulers any old time, no risk.
-  Nick Piggin has code for this.
-
-  PRI1
-
-o viro: paride drivers need a big cleanup
+o viro: paride drivers need a big cleanup. Partially done, but ATAPI drivers
+  need serious work and bug fixing.
 
   PRI2
 
@@ -145,15 +140,7 @@ o (Trond:) Yes: I'm still working on an 
 
    PRI2 (?)
 
-o (Chuck Lever <cel@citi.umich.edu>): NFS O_DIRECT support must be
-  completed.  The best approach is to fall back to something like the 2.4 NFS
-  O_DIRECT support, which issues RPCs synchronously and uses the RPC
-  completion mechanism to wait for I/O completion.
-
-  PRI2
-
-o viro: cleaning up options-parsers in filesystems.  (patch exists, needs
-  porting).
+o viro: convert more filesystems to use lib/parser.c for options.
 
   PRI2
 
@@ -200,9 +187,6 @@ o klibc merge?
 mm/
 ~~~
 
-o objrmap: concerns over page reclaim performance at high sharing levels,
-  and interoperation with nonlinear mappings is hairy.
-
 o oxymoron's async write-error-handling patch
 
   PRI1
@@ -514,10 +498,6 @@ o NMI watchdog seems to tick too fast
 
   PRI2
 
-o not very well tested. probably more bugs lurking.
-
-  PRI1
-
 o need to coredump 64bit vsyscall code with dwarf2
 
   PRI2

_

ACPI PM-Timer [Was: Re: [RFC][PATCH] must fix lists]

[Dominik Brodowski]

On Mon, Oct 27, 2003 at 11:53:43PM +1100, Nick Piggin wrote:
> +o alan, Albert Cahalan: 1000 HZ timer increases the need for a stable time
> +  source. Many laptops, SMI can lose ticks. ACPI timers? TSC?

A few months ago, I proposed to make the ACPI "Powermanagement" timer, a 
reliable timing source with  ~3.6MHz resolution, available as a timer_opts
for arch/i386/kernel/timers/timer.c. [1]

The major difficulty with this ACPI PM-Timer is that the I/O-port it is
located at is unknown during time_init.[2] So, it becomes necessary to use a
different timing source in the beginning, and switch to the ACPI PM-Timer
later.

Here are two different methods to replace one timing source with another.
First, the simple (and buggy) one -- the timing is broken until the next
timer "tick" == the next call to mark_offset().

diff -ruN linux-original/arch/i386/kernel/timers/timer.c linux/arch/i386/kernel/timers/timer.c
--- linux-original/arch/i386/kernel/timers/timer.c	2003-10-27 16:45:25.071848960 +0100
+++ linux/arch/i386/kernel/timers/timer.c	2003-10-27 18:59:23.904760600 +0100
@@ -35,12 +35,20 @@
 __setup("clock=", clock_setup);
 
 
+/* Switch to other timesource. */
+int replace_timer_opts(struct timer_opts *replacement)
+{
+	replacement->mark_offset();
+	cur_timer = replacement;
+	return 0;
+}
+
 /* The chosen timesource has been found to be bad.
  * Fall back to a known good timesource (the PIT)
  */
 void clock_fallback(void)
 {
-	cur_timer = &timer_pit;
+	replace_timer_opts(&timer_pit);
 }
 
 /* iterates through the list of timers, returning the first 
diff -ruN linux-original/include/asm-i386/timer.h linux/include/asm-i386/timer.h
--- linux-original/include/asm-i386/timer.h	2003-10-27 16:45:34.000000000 +0100
+++ linux/include/asm-i386/timer.h	2003-10-27 18:57:06.345672760 +0100
@@ -22,6 +22,7 @@
 
 extern struct timer_opts* select_timer(void);
 extern void clock_fallback(void);
+extern int replace_timer_opts(struct timer_opts *replacement);
 
 /* Modifiers for buggy PIT handling */
 

||| END OF PATCH |||


A different, more sensible approach is this:

diff -ruN linux-original/arch/i386/kernel/timers/timer.c linux/arch/i386/kernel/timers/timer.c
--- linux-original/arch/i386/kernel/timers/timer.c	2003-10-27 16:45:25.071848960 +0100
+++ linux/arch/i386/kernel/timers/timer.c	2003-10-27 18:43:56.644725552 +0100
@@ -1,7 +1,10 @@
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/string.h>
+#include <linux/spinlock.h>
+#include <linux/errno.h>
 #include <asm/timer.h>
+#include <linux/delay.h>
 
 #ifdef CONFIG_HPET_TIMER
 /*
@@ -35,12 +38,83 @@
 __setup("clock=", clock_setup);
 
 
+/* Switch to other timesource.
+ * This is tricky as it must be done during the next "mark_offset",
+ * to assure that get_offset() is correct.
+ */
+
+struct timer_opts intermediate_timer_opts;
+struct timer_opts *replacement_timer_opts = NULL;
+static spinlock_t replace_timer_lock = SPIN_LOCK_UNLOCKED;
+
+static void mark_offset_and_replace(void)
+{
+	/* in interrupt... */
+	spin_lock(&replace_timer_lock);
+
+	/* replace... */
+	cur_timer = replacement_timer_opts;
+	replacement_timer_opts = NULL;
+
+	/* and mark the offset with the new timer */
+	cur_timer->mark_offset();
+
+	spin_unlock(&replace_timer_lock);
+}
+
+
+int replace_timer_opts(struct timer_opts *replacement)
+{
+	unsigned long flags;
+	unsigned long counter = 0;
+
+	might_sleep();
+	spin_lock_irqsave(&replace_timer_lock, flags);
+
+	/* verify nobody else is trying to replace right now */
+	if (replacement_timer_opts)
+	{
+		spin_unlock_irqrestore(&replace_timer_lock, flags);
+		return -EBUSY;
+	}
+	replacement_timer_opts = replacement;
+
+	/* copy the current timer source operations to a new timer_opts struct,
+	 * but use our special own mark_offset funciton which replaces the
+	 * time source. */
+
+	memcpy(&intermediate_timer_opts, cur_timer, sizeof(struct timer_opts));
+	intermediate_timer_opts.mark_offset = mark_offset_and_replace;
+	cur_timer = &intermediate_timer_opts;
+	spin_unlock_irqrestore(&replace_timer_lock, flags);	
+
+	/* wait until the change is done. Can't rely on mdelay and/or friends
+	 * here, as we don't really trust the previous timing source any longer. */
+
+	for (;;) {
+		spin_lock_irqsave(&replace_timer_lock, flags);
+		if (replacement_timer_opts != cur_timer) {
+			spin_unlock_irqrestore(&replace_timer_lock, flags);
+			return 0;
+		}
+		counter++;
+		if (counter > loops_per_jiffy) {
+			/* lose temper */
+			cur_timer = replacement_timer_opts;
+			replacement_timer_opts = NULL;
+		}
+		spin_unlock_irqrestore(&replace_timer_lock, flags);
+	}
+
+	return 1;
+}
+
 /* The chosen timesource has been found to be bad.
  * Fall back to a known good timesource (the PIT)
  */
 void clock_fallback(void)
 {
-	cur_timer = &timer_pit;
+	replace_timer_opts(&timer_pit);
 }
 
 /* iterates through the list of timers, returning the first 
diff -ruN linux-original/include/asm-i386/timer.h linux/include/asm-i386/timer.h
--- linux-original/include/asm-i386/timer.h	2003-10-27 16:45:34.000000000 +0100
+++ linux/include/asm-i386/timer.h	2003-10-27 18:21:46.341962312 +0100
@@ -22,6 +22,7 @@
 
 extern struct timer_opts* select_timer(void);
 extern void clock_fallback(void);
+extern int replace_timer_opts(struct timer_opts *replacement);
 
 /* Modifiers for buggy PIT handling */
 

||| END OF PATCH |||


And, last but not least, here's the actual timer code:

diff -ruN linux-original/arch/i386/Kconfig linux/arch/i386/Kconfig
--- linux-original/arch/i386/Kconfig	2003-10-27 16:45:25.074848504 +0100
+++ linux/arch/i386/Kconfig	2003-10-27 18:45:04.259446552 +0100
@@ -510,6 +510,18 @@
 	depends on (MWINCHIP3D || MWINCHIP2 || MCRUSOE || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2) && !X86_NUMAQ
 	default y
 
+config X86_PM_TIMER
+	bool "Use Power Management Timer (PMTMR) as primary timing source"
+	depends on ACPI_BUS
+	help
+	  The Power Management Timer (PMTMR) is available on all 
+	  ACPI-capable systems. it provides a reliable timing source 
+	  which does not get affected by powermanagement features 
+	  (e.g. aggressive idling, throttling or frequency scaling), 
+	  unlike the commonly used Time Stamp Counter (TSC) timing source.
+	  If you see messages like 'Losing too many ticks!' in the kernel
+	  logs, you may want to say "Y" here.
+
 config X86_MCE
 	bool "Machine Check Exception"
 	---help---
diff -ruN linux-original/arch/i386/kernel/timers/Makefile linux/arch/i386/kernel/timers/Makefile
--- linux-original/arch/i386/kernel/timers/Makefile	2003-10-27 16:45:25.071848960 +0100
+++ linux/arch/i386/kernel/timers/Makefile	2003-10-27 18:34:49.717871072 +0100
@@ -6,3 +6,4 @@
 
 obj-$(CONFIG_X86_CYCLONE_TIMER)	+= timer_cyclone.o
 obj-$(CONFIG_HPET_TIMER)	+= timer_hpet.o
+obj-$(CONFIG_X86_PM_TIMER)	+= timer_pm.o
diff -ruN linux-original/arch/i386/kernel/timers/timer_pm.c linux/arch/i386/kernel/timers/timer_pm.c
--- linux-original/arch/i386/kernel/timers/timer_pm.c	1970-01-01 01:00:00.000000000 +0100
+++ linux/arch/i386/kernel/timers/timer_pm.c	2003-10-27 18:46:13.944852760 +0100
@@ -0,0 +1,168 @@
+/*
+ * (C) Dominik Brodowski <linux@brodo.de> 2003
+ *
+ * Driver to use the Power Management Timer (PMTMR) available in some
+ * southbridges as primary timing source for the Linux kernel.
+ *
+ * based on parts of linux/drivers/acpi/hardware/hwtimer.c and of timer_pit.c,
+ * and on Arjan van de Ven's implementation for 2.4. 
+ *
+ * This file is licensed under the GPL v2.
+ */
+
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <asm/types.h>
+#include <asm/timer.h>
+#include <asm/smp.h>
+#include <asm/io.h>
+#include <asm/arch_hooks.h>
+
+/* The I/O port the PMTMR resides at */
+static u32 pmtmr_ioport = 0;
+
+/* value of the Power timer at last timer interrupt */
+static u32 offset_tick;
+
+struct timer_opts timer_pmtmr;
+
+/************ detection of the I/O port *****************/
+
+/*
+ * The PMTMR I/O port can be detected using the following methods:
+ *
+ * a) Scan the PCI bus for the device the PMTMR is located at [e.g. PIIX4 southbridge],
+ *    locate its I/O port range, and then use a table-lookup to find the I/O port 
+ *    (offset) for the PMTMR for this device. 
+ *    While this provides some safety from buggy BIOSes, it is also very chipset-specific
+ *    and only available once the PCI devices are properly enabled, e.g. very late during
+ *    the boot process. Another timing source needs to be used in between. However, as this
+ *    approach is independent of ACPI and CONFIG_ACPI, it might be a good solution for some
+ *    very broken systems.
+ *    This method has not been implemented yet.
+ *
+ * b) Ask the ACPI subsystem's FADT. While this is the easiest approach, it also means that
+ *    this timer is only available _late_ in the boot process, only after the ACPI subsystem
+ *    has been initialized (which is a subsys_initcall). However, the timing sources are set
+ *    up already earlier. This means that we need to use the TSC or the PIT intermediately until
+ *    this code replaces the earlier used timer with the PMTMR [see mark_offset_and_replace() foir
+ *    details on this].
+ *    This method is implemented.
+ *
+ * c) Parse the ACPI FADT here, too. This means that this code could be independend of CONFIG_ACPI,
+ *    but it would cause a lot of code duplication between the ACPI subsystem and this file. However,
+ *    as this could mean that the PMTMR can be used immediately, without having to rely on alternate
+ *    timing sources first.
+ *    This method has not been implemented yet.
+ */
+
+/* method b) */
+
+#include <acpi/acpi.h>
+#include <acpi/acpi_bus.h>
+
+static int __init pmtimer_init(void)
+{
+	int ret;
+
+	ret = acpi_get_timer(&offset_tick);
+	if (ret) {
+		printk(KERN_ERR "acpi_get_timer failed\n");
+		return -EINVAL;
+	}
+
+	if (acpi_fadt.xpm_tmr_blk.address_space_id != ACPI_ADR_SPACE_SYSTEM_IO) {
+		printk(KERN_INFO "ACPI PM timer is not at IO port -- error\n");
+		return -EINVAL;
+	}
+
+	pmtmr_ioport = acpi_fadt.xpm_tmr_blk.address;
+	if (!pmtmr_ioport) {
+		printk(KERN_INFO "ACPI PM timer invalid IO port\n");
+		return -EINVAL;
+	}
+		
+	printk(KERN_INFO "Trying to switch to ACPI PM timer at 0x%x as timing source\n.", pmtmr_ioport);
+
+	replace_timer_opts(&timer_pmtmr);
+	
+	return 0;
+}
+fs_initcall(pmtimer_init);
+
+
+/************ actual timing code *****************/
+
+/*
+ * this gets called during each timer interrupt
+ */
+static void mark_offset_pmtmr(void)
+{
+	offset_tick = inl(pmtmr_ioport);
+	offset_tick &= 0xFFFFFF; /* limit it to 24 bits */
+	return;
+}
+
+static unsigned long long monotonic_clock_pmtmr(void)
+{
+	return 0;
+}
+
+/*
+ * copied from delay_pit
+ */
+static void delay_pmtmr(unsigned long loops)
+{
+	int d0;
+	__asm__ __volatile__(
+		"\tjmp 1f\n"
+		".align 16\n"
+		"1:\tjmp 2f\n"
+		".align 16\n"
+		"2:\tdecl %0\n\tjns 2b"
+		:"=&a" (d0)
+		:"0" (loops));
+}
+
+/*
+ * get the offset (in microseconds) from the last call to mark_offset()
+ */
+static unsigned long get_offset_pmtmr(void)
+{
+	u32 now, offset, delta = 0;
+
+	offset = offset_tick;
+	now = inl(pmtmr_ioport);
+	now &= 0xFFFFFF;
+	if (offset < now)
+		delta = now - offset;
+	else if (offset > now)
+		delta = (0xFFFFFF - offset) + now;
+
+	/* The Power Management Timer ticks at 3.579545 ticks per microsecond.
+	 * 1 / PM_TIMER_FREQUENCY == 0.27936511 =~ 286/1024 [error: 0.024%]
+	 *
+	 * Even with HZ = 100, delta is at maximum 35796 ticks, so it can 
+	 * easily be multiplied with 286 (=0x11E) without having to fear
+	 * u32 overflows.
+	 */
+	delta *= 286;
+	return (unsigned long) (delta >> 10);
+}
+
+/* acpi timer_opts struct */
+struct timer_opts timer_pmtmr = {
+	.init =		NULL,
+	.mark_offset =	mark_offset_pmtmr, 
+	.get_offset =	get_offset_pmtmr,
+	.monotonic_clock = monotonic_clock_pmtmr,
+	.delay = delay_pmtmr,
+};
+
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Dominik Brodowski <linux@brodo.de>");
+MODULE_DESCRIPTION("Power Management Timer (PMTMR) as primary timing source for x86");

||| END OF PATCH |||

These patches have been tested on two i386 systems with 2.6.0-test9.

John? Albert?

	Dominik

[1] http://marc.theaimsgroup.com/?l=linux-kernel&m=105860269801212&w=2
[2] For details, see the comment in the third patch, below "detection
    of the I/O Port".

Re: ACPI PM-Timer [Was: Re: [RFC][PATCH] must fix lists]

[john stultz]

On Mon, 2003-10-27 at 10:24, Dominik Brodowski wrote:
> On Mon, Oct 27, 2003 at 11:53:43PM +1100, Nick Piggin wrote:
> > +o alan, Albert Cahalan: 1000 HZ timer increases the need for a stable time
> > +  source. Many laptops, SMI can lose ticks. ACPI timers? TSC?
> 
> A few months ago, I proposed to make the ACPI "Powermanagement" timer, a 
> reliable timing source with  ~3.6MHz resolution, available as a timer_opts
> for arch/i386/kernel/timers/timer.c. [1]
> 
> The major difficulty with this ACPI PM-Timer is that the I/O-port it is
> located at is unknown during time_init.[2] So, it becomes necessary to use a
> different timing source in the beginning, and switch to the ACPI PM-Timer
> later.
> 
> Here are two different methods to replace one timing source with another.
> First, the simple (and buggy) one -- the timing is broken until the next
> timer "tick" == the next call to mark_offset().

Thanks for working on this, Dominik!  

My only comment is that rather then replacing the time source midstream,
could we not do as the HPET time source does and use the late_time_init
callback? That avoids the nasty time source switching code. 

thanks
-john

Re: ACPI PM-Timer [Was: Re: [RFC][PATCH] must fix lists]

[Dominik Brodowski]

On Mon, Oct 27, 2003 at 10:42:34AM -0800, john stultz wrote:
> On Mon, 2003-10-27 at 10:24, Dominik Brodowski wrote:
> > On Mon, Oct 27, 2003 at 11:53:43PM +1100, Nick Piggin wrote:
> > > +o alan, Albert Cahalan: 1000 HZ timer increases the need for a stable time
> > > +  source. Many laptops, SMI can lose ticks. ACPI timers? TSC?
> > 
> > A few months ago, I proposed to make the ACPI "Powermanagement" timer, a 
> > reliable timing source with  ~3.6MHz resolution, available as a timer_opts
> > for arch/i386/kernel/timers/timer.c. [1]
> > 
> > The major difficulty with this ACPI PM-Timer is that the I/O-port it is
> > located at is unknown during time_init.[2] So, it becomes necessary to use a
> > different timing source in the beginning, and switch to the ACPI PM-Timer
> > later.
> > 
> > Here are two different methods to replace one timing source with another.
> > First, the simple (and buggy) one -- the timing is broken until the next
> > timer "tick" == the next call to mark_offset().
> 
> Thanks for working on this, Dominik!  
> 
> My only comment is that rather then replacing the time source midstream,
> could we not do as the HPET time source does and use the late_time_init
> callback? That avoids the nasty time source switching code. 

Because "late_time_init" is way too early. It might be usable for the
(unimplemented) detection method c) -- parsing the ACPI FADT ourselves --
described in the timer_pm.c code.
However, the currently used method uses struct acpi_fadt which is
filled in drivers/acpi/bus.c:acpi_bus_init(), which is called from 
a subsys_initcall.

	Dominik

Re: ACPI PM-Timer [Was: Re: [RFC][PATCH] must fix lists]

[john stultz]

On Mon, 2003-10-27 at 10:49, Dominik Brodowski wrote:
> On Mon, Oct 27, 2003 at 10:42:34AM -0800, john stultz wrote:
> > My only comment is that rather then replacing the time source midstream,
> > could we not do as the HPET time source does and use the late_time_init
> > callback? That avoids the nasty time source switching code. 
> 
> Because "late_time_init" is way too early. It might be usable for the
> (unimplemented) detection method c) -- parsing the ACPI FADT ourselves --
> described in the timer_pm.c code.
> However, the currently used method uses struct acpi_fadt which is
> filled in drivers/acpi/bus.c:acpi_bus_init(), which is called from 
> a subsys_initcall.


Ah, OK. Well, I'd prefer the manual ACPI parsing personally, but having
tried and failed to implement it once myself, I'd more prefer not to do
it myself. ;)

Let me get your patches up and running and I'll see if I have any
reasonable feedback. 

Thanks again!
-john

ACPI PM-Timer rev.2 [Was: Re: ACPI PM-Timer [Was: Re: [RFC][PATCH] must fix lists]]

[Dominik Brodowski]

On Mon, Oct 27, 2003 at 11:07:19AM -0800, john stultz wrote:
> Ah, OK. Well, I'd prefer the manual ACPI parsing personally, but having
> tried and failed to implement it once myself, I'd more prefer not to do
> it myself. ;)

Here it is, and it is soooo much nicer than my previous implementation. It
lacks the "lost-ticks compensation" and math cleanup John is working on, but
otherwise:

 arch/i386/Kconfig                  |   18 ++++
 arch/i386/kernel/acpi/boot.c       |   31 ++++++++
 arch/i386/kernel/timers/Makefile   |    1
 arch/i386/kernel/timers/timer.c    |    3
 arch/i386/kernel/timers/timer_pm.c |  139 +++++++++++++++++++++++++++++++++++++
 include/asm-i386/timer.h           |    3
 6 files changed, 195 insertions(+)

	Dominik

diff -ruN linux-original/arch/i386/Kconfig linux/arch/i386/Kconfig
--- linux-original/arch/i386/Kconfig	2003-10-27 16:45:25.000000000 +0100
+++ linux/arch/i386/Kconfig	2003-10-27 23:51:07.364168640 +0100
@@ -411,6 +411,24 @@
 config HPET_EMULATE_RTC
 	def_bool HPET_TIMER && RTC=y
 
+config X86_PM_TIMER
+	bool "Power Management Timer Support"
+	depends on (!X86_VISWS && !X86_VISWS) && EXPERIMENTAL
+	default n
+	help
+	  The Power Management Timer is available on all ACPI-capable,
+	  in most cases even if ACPI is unusable or blacklisted.
+
+	  This timing source is not affected by powermanagement features
+	  like aggressive processor idling, throttling, frequency and/or
+	  voltage scaling, unlike the commonly used Time Stamp Counter 
+	  (TSC) timing source.
+
+	  So, if you see messages like 'Losing too many ticks!' in the 
+	  kernel logs, and/or you are using a this on a notebook which
+	  does not yet have an HPET (see above), you should say "Y" 
+	  here. Otherwise, say "N".
+
 config SMP
 	bool "Symmetric multi-processing support"
 	---help---
diff -ruN linux-original/arch/i386/kernel/acpi/boot.c linux/arch/i386/kernel/acpi/boot.c
--- linux-original/arch/i386/kernel/acpi/boot.c	2003-10-27 16:45:25.000000000 +0100
+++ linux/arch/i386/kernel/acpi/boot.c	2003-10-27 23:48:07.873455376 +0100
@@ -319,6 +319,33 @@
 }
 #endif
 
+/* detect the location of the ACPI PM Timer
+#ifdef CONFIG_X86_PM_TIMER
+extern u32 pmtmr_ioport;
+
+static int __init acpi_parse_fadt(unsigned long phys, unsigned long size)
+{
+	struct fadt_descriptor_rev2 *fadt;
+
+	fadt = __va(phys);
+
+	if (fadt->revision >= FADT2_REVISION_ID) {
+		/* FADT rev. 2 */
+		if (fadt->xpm_tmr_blk.address_space_id != ACPI_ADR_SPACE_SYSTEM_IO)
+			return 0;
+
+		pmtmr_ioport = fadt->xpm_tmr_blk.address;
+	} else {
+		/* FADT rev. 1 */
+		pmtmr_ioport = fadt->V1_pm_tmr_blk;
+	}
+	if (pmtmr_ioport)
+		printk(KERN_INFO PREFIX "PM-Timer IO Port: %#x\n", pmtmr_ioport);
+	return 0;
+}
+#endif
+
+
 unsigned long __init
 acpi_find_rsdp (void)
 {
@@ -512,5 +539,9 @@
 	acpi_table_parse(ACPI_HPET, acpi_parse_hpet);
 #endif
 
+#ifdef CONFIG_X86_PM_TIMER
+	acpi_table_parse(ACPI_FADT, acpi_parse_fadt);
+#endif
+
 	return 0;
 }
diff -ruN linux-original/arch/i386/kernel/timers/Makefile linux/arch/i386/kernel/timers/Makefile
--- linux-original/arch/i386/kernel/timers/Makefile	2003-10-27 16:45:25.000000000 +0100
+++ linux/arch/i386/kernel/timers/Makefile	2003-10-27 23:48:07.937445648 +0100
@@ -6,3 +6,4 @@
 
 obj-$(CONFIG_X86_CYCLONE_TIMER)	+= timer_cyclone.o
 obj-$(CONFIG_HPET_TIMER)	+= timer_hpet.o
+obj-$(CONFIG_X86_PM_TIMER)	+= timer_pm.o
diff -ruN linux-original/arch/i386/kernel/timers/timer.c linux/arch/i386/kernel/timers/timer.c
--- linux-original/arch/i386/kernel/timers/timer.c	2003-10-27 23:33:34.695198648 +0100
+++ linux/arch/i386/kernel/timers/timer.c	2003-10-27 23:48:07.938445496 +0100
@@ -19,6 +19,9 @@
 #ifdef CONFIG_HPET_TIMER
 	&timer_hpet,
 #endif
+#ifdef CONFIG_X86_PM_TIMER
+	&timer_pmtmr,
+#endif
 	&timer_tsc,
 	&timer_pit,
 	NULL,
diff -ruN linux-original/arch/i386/kernel/timers/timer_pm.c linux/arch/i386/kernel/timers/timer_pm.c
--- linux-original/arch/i386/kernel/timers/timer_pm.c	1970-01-01 01:00:00.000000000 +0100
+++ linux/arch/i386/kernel/timers/timer_pm.c	2003-10-27 23:48:08.002435768 +0100
@@ -0,0 +1,139 @@
+/*
+ * (C) Dominik Brodowski <linux@brodo.de> 2003
+ *
+ * Driver to use the Power Management Timer (PMTMR) available in some
+ * southbridges as primary timing source for the Linux kernel.
+ *
+ * Based on parts of linux/drivers/acpi/hardware/hwtimer.c, timer_pit.c,
+ * timer_hpet.c, and on Arjan van de Ven's implementation for 2.4. 
+ *
+ * This file is licensed under the GPL v2.
+ */
+
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <asm/types.h>
+#include <asm/timer.h>
+#include <asm/smp.h>
+#include <asm/io.h>
+#include <asm/arch_hooks.h>
+
+
+/* The I/O port the PMTMR resides at.
+ * The location is detected during setup_arch(),
+ * in arch/i386/acpi/boot.c */
+u32 pmtmr_ioport = 0;
+
+
+/* value of the Power timer at last timer interrupt */
+static u32 offset_tick;
+
+
+static int init_pmtmr(char* override)
+{
+	u32 value1, value2;
+	unsigned int i;
+
+ 	if (override[0] && strncmp(override,"pmtmr",5))
+		return -ENODEV;
+
+	if (!pmtmr_ioport)
+		return -ENODEV;
+
+	/* "verify" this timing source */
+	value1 = inl(pmtmr_ioport);
+	value1 &= 0xFFFFFF;
+	for (i=0; i < 10000; i++) {
+		value2 = inl(pmtmr_ioport);
+		value2 &= 0xFFFFFF;
+		if (value2 == value1) 
+			continue;
+		if (value2 > value1)
+			return 0;
+		if ((value2 < value1) && ((value2) < 0xFFF))
+			return 0;
+		printk(KERN_INFO "PM-Timer had inconsistent results: 0x%#x, 0x%#x - aborting.\n", value1, value2);
+		return -EINVAL;
+	}
+	printk(KERN_INFO "PM-Timer had no reasonable result: 0x%#x - aborting.\n", value1);
+	return -ENODEV;
+}
+
+
+/*
+ * this gets called during each timer interrupt
+ */
+static void mark_offset_pmtmr(void)
+{
+	offset_tick = inl(pmtmr_ioport);
+	offset_tick &= 0xFFFFFF; /* limit it to 24 bits */
+	return;
+}
+
+
+static unsigned long long monotonic_clock_pmtmr(void)
+{
+	return 0;
+}
+
+
+/*
+ * copied from delay_pit
+ */
+static void delay_pmtmr(unsigned long loops)
+{
+	int d0;
+	__asm__ __volatile__(
+		"\tjmp 1f\n"
+		".align 16\n"
+		"1:\tjmp 2f\n"
+		".align 16\n"
+		"2:\tdecl %0\n\tjns 2b"
+		:"=&a" (d0)
+		:"0" (loops));
+}
+
+
+/*
+ * get the offset (in microseconds) from the last call to mark_offset()
+ */
+static unsigned long get_offset_pmtmr(void)
+{
+	u32 now, offset, delta = 0;
+
+	offset = offset_tick;
+	now = inl(pmtmr_ioport);
+	now &= 0xFFFFFF;
+	if (likely(offset < now))
+		delta = now - offset;
+	else if (offset > now)
+		delta = (0xFFFFFF - offset) + now;
+
+	/* The Power Management Timer ticks at 3.579545 ticks per microsecond.
+	 * 1 / PM_TIMER_FREQUENCY == 0.27936511 =~ 286/1024 [error: 0.024%]
+	 *
+	 * Even with HZ = 100, delta is at maximum 35796 ticks, so it can 
+	 * easily be multiplied with 286 (=0x11E) without having to fear
+	 * u32 overflows.
+	 */
+	delta *= 286;
+	return (unsigned long) (delta >> 10);
+}
+
+
+/* acpi timer_opts struct */
+struct timer_opts timer_pmtmr = {
+	.init 			= init_pmtmr,
+	.mark_offset		= mark_offset_pmtmr, 
+	.get_offset		= get_offset_pmtmr,
+	.monotonic_clock 	= monotonic_clock_pmtmr,
+	.delay 			= delay_pmtmr,
+};
+
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Dominik Brodowski <linux@brodo.de>");
+MODULE_DESCRIPTION("Power Management Timer (PMTMR) as primary timing source for x86");
diff -ruN linux-original/include/asm-i386/timer.h linux/include/asm-i386/timer.h
--- linux-original/include/asm-i386/timer.h	2003-10-27 23:33:34.696198496 +0100
+++ linux/include/asm-i386/timer.h	2003-10-27 23:48:08.036430600 +0100
@@ -44,4 +44,7 @@
 extern unsigned long calibrate_tsc_hpet(unsigned long *tsc_hpet_quotient_ptr);
 #endif
 
+#ifdef CONFIG_X86_PM_TIMER
+extern struct timer_opts timer_pmtmr;
+#endif
 #endif

Re: ACPI PM-Timer rev.2 [Was: Re: ACPI PM-Timer [Was: Re: [RFC][PATCH] must fix lists]]

[john stultz]

On Mon, 2003-10-27 at 15:01, Dominik Brodowski wrote:
> On Mon, Oct 27, 2003 at 11:07:19AM -0800, john stultz wrote:
> > Ah, OK. Well, I'd prefer the manual ACPI parsing personally, but having
> > tried and failed to implement it once myself, I'd more prefer not to do
> > it myself. ;)
> 
> Here it is, and it is soooo much nicer than my previous implementation. It
> lacks the "lost-ticks compensation" and math cleanup John is working on, but
> otherwise:

Finally, here are my fixes to Dominik's patch (meant to send these out
last week, but got swamped). Basically it cleans up some of the math,
adds lost-tick compensation and monotonic_clock, fixes up a bit of the
ACPI table mapping, and moves the config option under the ACPI menu. Oh
yea, and it compiles, too ;)

Works well for me, but needs more testing. 

Applies on top of Dominik's ACPI PM-timer rev.2 patch.
http://www.ussg.iu.edu/hypermail/linux/kernel/0310.3/0669.html

Many thanks to Dominik for the great work and getting this started. 
-john


diff -Nru a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
--- a/Documentation/kernel-parameters.txt	Tue Nov  4 13:30:42 2003
+++ b/Documentation/kernel-parameters.txt	Tue Nov  4 13:30:42 2003
@@ -214,7 +214,7 @@
 			Forces specified timesource (if avaliable) to be used
 			when calculating gettimeofday(). If specicified timesource
 			is not avalible, it defaults to PIT. 
-			Format: { pit | tsc | cyclone | ... }
+			Format: { pit | tsc | cyclone | pmtmr }
 
 	hpet=		[IA-32,HPET] option to disable HPET and use PIT.
 			Format: disable
diff -Nru a/arch/i386/Kconfig b/arch/i386/Kconfig
--- a/arch/i386/Kconfig	Tue Nov  4 13:30:42 2003
+++ b/arch/i386/Kconfig	Tue Nov  4 13:30:42 2003
@@ -411,24 +411,6 @@
 config HPET_EMULATE_RTC
 	def_bool HPET_TIMER && RTC=y
 
-config X86_PM_TIMER
-	bool "Power Management Timer Support"
-	depends on (!X86_VISWS && !X86_VISWS) && EXPERIMENTAL
-	default n
-	help
-	  The Power Management Timer is available on all ACPI-capable,
-	  in most cases even if ACPI is unusable or blacklisted.
-
-	  This timing source is not affected by powermanagement features
-	  like aggressive processor idling, throttling, frequency and/or
-	  voltage scaling, unlike the commonly used Time Stamp Counter 
-	  (TSC) timing source.
-
-	  So, if you see messages like 'Losing too many ticks!' in the 
-	  kernel logs, and/or you are using a this on a notebook which
-	  does not yet have an HPET (see above), you should say "Y" 
-	  here. Otherwise, say "N".
-
 config SMP
 	bool "Symmetric multi-processing support"
 	---help---
diff -Nru a/arch/i386/kernel/acpi/boot.c b/arch/i386/kernel/acpi/boot.c
--- a/arch/i386/kernel/acpi/boot.c	Tue Nov  4 13:30:42 2003
+++ b/arch/i386/kernel/acpi/boot.c	Tue Nov  4 13:30:42 2003
@@ -319,15 +319,19 @@
 }
 #endif
 
-/* detect the location of the ACPI PM Timer
+/* detect the location of the ACPI PM Timer */
 #ifdef CONFIG_X86_PM_TIMER
 extern u32 pmtmr_ioport;
 
 static int __init acpi_parse_fadt(unsigned long phys, unsigned long
size)
 {
-	struct fadt_descriptor_rev2 *fadt;
+	struct fadt_descriptor_rev2 *fadt =0;
 
-	fadt = __va(phys);
+	fadt = (struct fadt_descriptor_rev2*) __acpi_map_table(phys,size);
+	if(!fadt) {
+		printk(KERN_WARNING PREFIX "Unable to map FADT\n");
+		return 0;
+	}
 
 	if (fadt->revision >= FADT2_REVISION_ID) {
 		/* FADT rev. 2 */
diff -Nru a/arch/i386/kernel/timers/timer_pm.c
b/arch/i386/kernel/timers/timer_pm.c
--- a/arch/i386/kernel/timers/timer_pm.c	Tue Nov  4 13:30:42 2003
+++ b/arch/i386/kernel/timers/timer_pm.c	Tue Nov  4 13:30:42 2003
@@ -30,7 +30,12 @@
 
 /* value of the Power timer at last timer interrupt */
 static u32 offset_tick;
+static u32 offset_delay;
 
+static unsigned long long monotonic_base;
+static seqlock_t monotonic_lock = SEQLOCK_UNLOCKED;
+
+#define ACPI_PM_MASK 0xFFFFFF /* limit it to 24 bits */
 
 static int init_pmtmr(char* override)
 {
@@ -62,23 +67,88 @@
 	return -ENODEV;
 }
 
+static inline u32 cyc2us(u32 cycles)
+{
+	/* The Power Management Timer ticks at 3.579545 ticks per microsecond.
+	 * 1 / PM_TIMER_FREQUENCY == 0.27936511 =~ 286/1024 [error: 0.024%]
+	 *
+	 * Even with HZ = 100, delta is at maximum 35796 ticks, so it can 
+	 * easily be multiplied with 286 (=0x11E) without having to fear
+	 * u32 overflows.
+	 */
+	cycles *= 286;
+	return (cycles >> 10);
+}
 
 /*
  * this gets called during each timer interrupt
  */
 static void mark_offset_pmtmr(void)
 {
+	u32 lost, delta, last_offset;
+	static int first_run = 1;
+	last_offset = offset_tick;
+
+	write_seqlock(&monotonic_lock);
+
 	offset_tick = inl(pmtmr_ioport);
-	offset_tick &= 0xFFFFFF; /* limit it to 24 bits */
+	offset_tick &= ACPI_PM_MASK; /* limit it to 24 bits */
+
+	/* calculate tick interval */
+	delta = (offset_tick - last_offset) & ACPI_PM_MASK;
+
+	/* convert to usecs */
+	delta = offset_delay + cyc2us(delta);
+
+	/* convert to ticks */
+	lost = delta/(USEC_PER_SEC/HZ);
+	offset_delay = delta%(USEC_PER_SEC/HZ);
+
+	/* update the monotonic base value */
+	monotonic_base += delta; 
+	write_sequnlock(&monotonic_lock);
+
+
+	/* compensate for lost ticks */
+	if (lost >= 2)
+		jiffies += lost - 1;
+
+	/* don't calculate delay for first run, 
+	   or if we've got less then a tick */
+	if (first_run || (lost < 1)) {
+		first_run = 0;
+		offset_delay = 0;
+	}
+
 	return;
 }
 
 
 static unsigned long long monotonic_clock_pmtmr(void)
 {
-	return 0;
-}
+	u32 last_offset, this_offset;
+	unsigned long long base, ret;
+	unsigned seq;
+
 
+	/* atomically read monotonic base & last_offset */
+	do {
+		seq = read_seqbegin(&monotonic_lock);
+		last_offset = offset_tick;
+		base = monotonic_base;
+	} while (read_seqretry(&monotonic_lock, seq));
+
+
+	/* Read the cyclone counter */
+
+	this_offset =  inl(pmtmr_ioport) & ACPI_PM_MASK;
+	
+
+	/* convert to nanoseconds */
+	ret = base + ((this_offset - last_offset) & ACPI_PM_MASK);
+	ret = cyc2us(ret)*1000;
+	return ret;
+}
 
 /*
  * copied from delay_pit
@@ -106,21 +176,10 @@
 
 	offset = offset_tick;
 	now = inl(pmtmr_ioport);
-	now &= 0xFFFFFF;
-	if (likely(offset < now))
-		delta = now - offset;
-	else if (offset > now)
-		delta = (0xFFFFFF - offset) + now;
+	now &= ACPI_PM_MASK;
+	delta = (now - offset)&ACPI_PM_MASK;
 
-	/* The Power Management Timer ticks at 3.579545 ticks per microsecond.
-	 * 1 / PM_TIMER_FREQUENCY == 0.27936511 =~ 286/1024 [error: 0.024%]
-	 *
-	 * Even with HZ = 100, delta is at maximum 35796 ticks, so it can 
-	 * easily be multiplied with 286 (=0x11E) without having to fear
-	 * u32 overflows.
-	 */
-	delta *= 286;
-	return (unsigned long) (delta >> 10);
+	return (unsigned long) offset_delay + cyc2us(delta);
 }
 
 
diff -Nru a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
--- a/drivers/acpi/Kconfig	Tue Nov  4 13:30:42 2003
+++ b/drivers/acpi/Kconfig	Tue Nov  4 13:30:42 2003
@@ -269,5 +269,24 @@
 	  particular, many Toshiba laptops require this for correct operation
 	  of the AC module.
 
+config X86_PM_TIMER
+	bool "Power Management Timer Support"
+	depends on X86 && ACPI
+	depends on ACPI_BOOT && EXPERIMENTAL
+	default n
+	help
+	  The Power Management Timer is available on all ACPI-capable,
+	  in most cases even if ACPI is unusable or blacklisted.
+
+	  This timing source is not affected by powermanagement features
+	  like aggressive processor idling, throttling, frequency and/or
+	  voltage scaling, unlike the commonly used Time Stamp Counter 
+	  (TSC) timing source.
+
+	  So, if you see messages like 'Losing too many ticks!' in the 
+	  kernel logs, and/or you are using a this on a notebook which
+	  does not yet have an HPET (see above), you should say "Y" 
+	  here.
+
 endmenu
 

Re: [RFC] must fix lists

[Mikael Pettersson]

On Thu, 23 Oct 2003 22:11:35 +0100, Alan Cox wrote:
>On Mer, 2003-10-22 at 03:50, Albert Cahalan wrote:
>> The system in question would also lose time when
>> under heavy load. Note that HZ is now 1000 HZ.
>> If interrupts are kept off for too long or an
>> SMI grabs the CPU...
>
>With a lot of laptops this is a huge problem. Its one of the reasons Red
>Hat went back to 100Hz in the RH 2.4 tree. With many laptops your clock
>becomes junk at 1Khz. It will be interesting to see if the ACPI timers
>help but that wont solve things for older laptops.

Or for really old desktops. My 486 loses time at a rate of about
2 minutes per hour when running 2.5/2.6 and doing lots of disk I/O.
Changing HZ back to 100 solves that problem.

I think we need a CONFIG_HZ.

/Mikael