Linux 2.2.19pre3

Linux 2.2.19pre3

[Alan Cox]

2.2.19pre3
o	Merge ADMtek-comet tulip support		(Jim McQuillan)
o	Update microcode driver				(Tigran Aivazian)
o	Merge Don Becker's NE2K full duplex support	(Juan Lacarta)
o	Optimise kernel compiler detect, kgcc before	(Peter Samuelson)
	gcc272 also
o	Fix compile combination problems		(Arjan van de Ven)
o	Update via-rhine driver to include Don's changes(Urban Widmark)
	for VT6102
o	Documentation updates				(Tim Waugh)
o	Add ISDN PCI defines to pci.h			(Kai Germaschewski)
o	Fix smb/fat handling for pre 1980 dates		(Igor Zhbanov)
o	SyncLink updates				(Paul Fulghum)
o	ICP vortex driver updates 			(Andreas Köpf)
o	mdacon clean up					(Pavel Rabel)
o	Fix bugs in es1370/es1371/sonicvibes/solo1/	(Thomas Sailer)
	dabusb
o	Speed up x86 irq/fault paths by avoiding xchg	(Mikael Pettersson)
	locked cycles (from Brian Gerst's 2.4test change)
o	Tighten up K6 check in bug tests		(Mikael Pettersson)
o	Backport configure scripts bug fixes		(Mikael Pettersson)
o	Fix duplicat help entries			(Riley Williams)
o	Fix small asm bug in constant size uaccess	(David Kutz)
o	Update ymfpci driver to handle legacy audio	(Daisuke Nagano)
o	Remove ymfsb driver now no longer needed	(Daisuke Nagano)
o	Add Empeg support to usb-serial			(Gary Brubaker)
o	Fix e820 handling				(Andrea Arcangeli)
o	Fix lanstreamer SMP locking			(George Staikos)
o	Fix S/390 non SMP build				(Kurt Roeckx)
o	Fix the PCI syscall on PowerMac		(Benjamin Herrenschmidt)
o	Fix IPC_RMID behaviour				(Christoph Rohland)
o	Fix NETCTL_GETFD on sparc64			(Dave Miller)
o	Tidy unneeded restore_flags/save sequence  (Arnaldo Carvalho de Melo)
	on the ultrastor
o	Fix resource clean up on error in 89xo     (Arnaldo Carvalho de Melo)
	driver
o	Update wireless headers				(Jean Tourrilhes)
o	Fix non modular emu10k init			(Mikael Pettersson)
o	Fix cpuid/msr driver crashes			(Andrew Morton)
o	Write core files sparse				(Christoph Rohland)
o	Merge the i810 tco (watchdog) timer		(me)
	| original by Jeff Garzik


2.2.19pre2
o	Drop the page aging for a moment to merge the
	Andrea VM
o	Merge Andrea's VM-global patch			(Andrea Arcangeli)

2.2.19pre1
o	Basic page aging				(Neil Schemenauer)
	| This is a beginning to trying to get the VM right
	| Next stage is to go through Andrea's stuff and sort 
	| it out the way I want it.
o	E820 memory detect backport from 2.4		(Michael Chen)
o	Fix cs46xx refusing to run on emachines400	(me)
o	Fix parport docs				(Tim Waugh)
o	Fix USB serial name reporting			(me)
o	Fix else warning in initio scsi			(John Fort)
o	Fix incorrect timeout (that couldnt occur
	fortunately) in sched.c				(Andrew Archibald)
o	Fix A20 fix credits				(Christian Lademann)
o	Support for OnStream SC-x0 tape drives		(Willem Riede, 
							 Kurt Garloff)
o	Intel 815 added to the AGPGART code		(Robert M Love)
o	3Ware scsi fixes			(Arnaldo Carvalho de Melo)
o	Clean up scsi_init_malloc no mem case	(Arnaldo Carvalho de Melo)
o	Fix dead module parameter in ip_masq_user.c	(Keith Owens)
o	Switch max_files and friends to a struct to	(Tigran Aivazian)
	be sure they stay together
o	Update microcode driver				(Tigran Aivazian)
o	Fix free memory dereference in lance driver	(Eli Carter)
o	ISOfs fixes 					(Andries Brouwer)
o	Watchdog driver for Advantech boards		(Marek Michalkiewicz)
o	ISDN updates					(Karsten Keil)
o	Docs fix 					(Pavel Rabel)
o	wake_one semantics for accept()			(Andrew Morton)
o	Masquerade updates				(Juanjo Ciarlante)
o	Add support for long serialnums on the Metricom	(Alex Belits)
o	Onboard ethernet driver for the Intel 'Panther'	(Ard van Breemen,
	boards						 Andries Brouwer)
o	VIA686a timer reset to 18Hz background		(Vojtech Pavlik)
o	3c527 driver rewrite				(Richard Procter)
	| This supercedes my driver because
	| - it works for more people
	| - he has time to use his MCA box to debug it
o	Minix subpartition support			(Anand Krishnamurthy 
							 Rajeev Pillai)
o	Remove unused() crap from DRM. You will need
	to hand load agp as well if needed		(me)


--
Alan Cox <alan@lxorguk.ukuu.org.uk>
Red Hat Kernel Hacker
& Linux 2.2 Maintainer                        Brainbench MVP for TCP/IP
http://www.linux.org.uk/diary                 http://www.brainbench.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Mitch Adair]

> 2.2.19pre3
[snip]
> o	Optimise kernel compiler detect, kgcc before	(Peter Samuelson)
> 	gcc272 also

I get an endless stream of this:

kgcc:gcc272:cc:gcc: not found
kgcc:gcc272:cc:gcc: not found
/bin/sh: -D__KERNEL__: command not found
/bin/sh: -D__KERNEL__: command not found
/bin/sh: -D__KERNEL__: command not found
/bin/sh: -D__KERNEL__: command not found


I think the Makefile optimisation needs to be (cut-n-paste):

--- Makefile~   Thu Dec 21 21:35:39 2000
+++ Makefile    Thu Dec 21 21:35:54 2000
@@ -28,7 +28,7 @@
 #      gcc272 for Debian
 #      otherwise 'cc'
 #
-CCFOUND :=$(shell $(CONFIG_SHELL) scripts/kwhich kgcc gcc272 cc gcc)
+CCFOUND :=$(shell $(CONFIG_SHELL) scripts/kwhich kgcc:gcc272:cc:gcc)
 ## Faster, but requires GNU make 3.78, which postdates Linux 2.2.0
 ##CC   =$(if $(CROSS_COMPILE),$(CROSS_COMPILE)gcc,$(CCFOUND)) -D__KERNEL__ -I$(HPATH)
 CC     =$(shell if [ -n "$(CROSS_COMPILE)" ]; then echo $(CROSS_COMPILE)gcc; else echo $(CCFOUND); fi) \


	M
(what's the old saying - the first rule of optimization is don't or
something like that... ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Petri Kaukasoina]

On Fri, Dec 22, 2000 at 12:52:32AM +0000, Alan Cox wrote:
> 
> o	Optimise kernel compiler detect, kgcc before	(Peter Samuelson)
> 	gcc272 also

kwhich doesn't seem to work ok with several arguments if sh is bash-1.14.7:

$ sh scripts/kwhich kgcc gcc272 cc gcc
kgcc:gcc272:cc:gcc: not found

If sh is bash-2.04 or ash-0.3.7 it works ok:

$ sh scripts/kwhich kgcc gcc272 cc gcc
/usr/bin/kgcc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Richard B. Johnson]

On Fri, 22 Dec 2000, Petri Kaukasoina wrote:

> On Fri, Dec 22, 2000 at 12:52:32AM +0000, Alan Cox wrote:
> > 
> > o	Optimise kernel compiler detect, kgcc before	(Peter Samuelson)
> > 	gcc272 also
> 
> kwhich doesn't seem to work ok with several arguments if sh is bash-1.14.7:
> 
> $ sh scripts/kwhich kgcc gcc272 cc gcc
> kgcc:gcc272:cc:gcc: not found
> 
> If sh is bash-2.04 or ash-0.3.7 it works ok:
> 
> $ sh scripts/kwhich kgcc gcc272 cc gcc
> /usr/bin/kgcc
> -

Yep.

alias kwhich='type -path' in ~./bashrc should fix. I don't know
why 'standard' Unix/sell/executable commands keep getting changed
to GNUisms in distributions.

If you make a neat new GNU program, it had ought to function at
least like what it's replacing...

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Chad Schwartz]

> alias kwhich='type -path' in ~./bashrc should fix. I don't know
> why 'standard' Unix/sell/executable commands keep getting changed
> to GNUisms in distributions.

I've been asking that question ever since most popular distributions
started putting a copy of bash in /bin/sh.

WHY oh WHY would they do that. Ugh.

This is one of the reasons why many BSD (and commercial unix) folks don't
like Linux. (It isn't the kernel they have a problem with. its the
operability of said software.)

Chad


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Alan Cox]

> > why 'standard' Unix/sell/executable commands keep getting changed
> > to GNUisms in distributions.
> 
> I've been asking that question ever since most popular distributions
> started putting a copy of bash in /bin/sh.

And which of the versions of 'which' would you rather people had. Do you want
csh behaviour, tcsh behaviour, which non builtin BSD behaviour, which as alias
trick behaviour, which as ksh behaviour..

There is no standard which command.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Chad Schwartz]

> And which of the versions of 'which' would you rather people had. Do you want
> csh behaviour, tcsh behaviour, which non builtin BSD behaviour, which as alias
> trick behaviour, which as ksh behaviour..
>
> There is no standard which command.

Exactly why there will be 3 different overall behaviors for 3 different
distributions, in most cases.

Chad



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Richard B. Johnson]

On Fri, 22 Dec 2000, Alan Cox wrote:

> > > why 'standard' Unix/sell/executable commands keep getting changed
> > > to GNUisms in distributions.
> > 
> > I've been asking that question ever since most popular distributions
> > started putting a copy of bash in /bin/sh.
> 
> And which of the versions of 'which' would you rather people had. Do you want
> csh behaviour, tcsh behaviour, which non builtin BSD behaviour, which as alias
> trick behaviour, which as ksh behaviour..
> 
> There is no standard which command.
> 

Which which would which which if which would which which? Perhaps
which would which kwhich when it whiches which. However, many
which which which would prefer that which not which any which
but be left as an alias.

Seasons Greetings!


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Miquel van Smoorenburg]

In article <Pine.LNX.3.95.1001222104908.791A-100000@chaos.analogic.com>,
Richard B. Johnson <root@chaos.analogic.com> wrote:
>alias kwhich='type -path' in ~./bashrc should fix.

Hmm? Smells like a stupid bug to me. The script is called as:

CCFOUND :=$(shell $(CONFIG_SHELL) scripts/kwhich kgcc gcc272 cc gcc)

So how can bash ever decide to replace scripts/kwhich (OBVIOUSLY
a call to a non-internal command) with an alias or builtin?

Are you sure this is in fact the bug?

Couldn't it be the games with IFS in the scripts/kwhich script?

Try this patch:

--- linux-2.2.19pre3/scripts/kwhich.orig	Tue Dec 19 23:16:52 2000
+++ linux-2.2.19pre3/scripts/kwhich	Fri Dec 22 19:02:47 2000
@@ -7,7 +7,7 @@
         exit 1
 fi
 
-IFS=:
+IFS=":$IFS"
 for cmd in $*
 do
         for path in $PATH


Mike.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Richard B. Johnson]

On 22 Dec 2000, Miquel van Smoorenburg wrote:

> In article <Pine.LNX.3.95.1001222104908.791A-100000@chaos.analogic.com>,
> Richard B. Johnson <root@chaos.analogic.com> wrote:
> >alias kwhich='type -path' in ~./bashrc should fix.
> 
> Hmm? Smells like a stupid bug to me. The script is called as:
> 
> CCFOUND :=$(shell $(CONFIG_SHELL) scripts/kwhich kgcc gcc272 cc gcc)
> 
> So how can bash ever decide to replace scripts/kwhich (OBVIOUSLY
> a call to a non-internal command) with an alias or builtin?
> 
> Are you sure this is in fact the bug?

No it isn't the bug. I didn't see the path to kwhich when I first
replied. I assumed another GNUism had appeared.

> 
> Couldn't it be the games with IFS in the scripts/kwhich script?
> 
> Try this patch:
> 
> --- linux-2.2.19pre3/scripts/kwhich.orig	Tue Dec 19 23:16:52 2000
> +++ linux-2.2.19pre3/scripts/kwhich	Fri Dec 22 19:02:47 2000
> @@ -7,7 +7,7 @@
>          exit 1
>  fi
>  
> -IFS=:
> +IFS=":$IFS"
>  for cmd in $*
>  do
>          for path in $PATH
>

And yes, this should do it.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Alan Cox]

> > o	Optimise kernel compiler detect, kgcc before	(Peter Samuelson)
> > 	gcc272 also
> 
> kwhich doesn't seem to work ok with several arguments if sh is bash-1.14.7:

Yep. I shall just back this out
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Petri Kaukasoina]

On Fri, Dec 22, 2000 at 12:52:32AM +0000, Alan Cox wrote:
> 
> 2.2.19pre3
> o	Fix e820 handling				(Andrea Arcangeli)


arch/i386/kernel/setup.c:

                /* compare results from other methods and take the greater */
                if (ALT_MEM_K < EXT_MEM_K) {
                        mem_size = EXT_MEM_K;
                        who = "BIOS-88";
                } else {
                        mem_size = ALT_MEM_K;
                        who = "BIOS-e801";
                }
 
                e820.nr_map = 0;
-               add_memory_region(0, LOWMEMSIZE(), E820_RAM);
-               add_memory_region(HIGH_MEMORY, mem_size << 10, E820_RAM);
+               add_memory_region(0, i386_endbase, E820_RAM);
+               add_memory_region(HIGH_MEMORY, (mem_size << 10)-HIGH_MEMORY,
+                                E820_RAM);

I think in case of BIOS-88 it now sees 1 Meg less than should. int 15, ah=88
gives the amount of extended memory above 1 Meg and it gets copied to
EXT_MEM_K. So HIGH_MEMORY should not be subtracted from it. (On the other
hand in case of BIOS-e801 ALT_MEM_K includes lower memory. I guess the
direct comparison of memory sizes ALT_MEM_K and EXT_MEM_K is not ok.)

linux-2.2.19pre3 on my 486 with 49152 k of RAM:

BIOS-provided physical RAM map:
 BIOS-88: 000a0000 @ 00000000 (usable)
 BIOS-88: 02e00000 @ 00100000 (usable)
Memory: 46128k/48128k available

linux-2.2.18 or linux-2.2.19pre2 :

Memory: 47144k/49152k available
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Andrea Arcangeli]

On Fri, Dec 22, 2000 at 09:33:58PM +0200, Petri Kaukasoina wrote:
> I think in case of BIOS-88 it now sees 1 Meg less than should. int 15, ah=88

Yes, you're right, sorry. Here a backout against 2.2.19pre3:

--- 2.2.19pre3-e820/arch/i386/kernel/setup.c.~1~	Fri Dec 22 14:51:26 2000
+++ 2.2.19pre3-e820/arch/i386/kernel/setup.c	Fri Dec 22 20:54:27 2000
@@ -376,8 +376,7 @@
 
                e820.nr_map = 0;
                add_memory_region(0, i386_endbase, E820_RAM);
-               add_memory_region(HIGH_MEMORY, (mem_size << 10)-HIGH_MEMORY,
-				 E820_RAM);
+               add_memory_region(HIGH_MEMORY, (mem_size << 10), E820_RAM);
        }
        printk("BIOS-provided physical RAM map:\n");
        print_memory_map(who);


The other part of the 2.4.x patch is still valid.

Thanks,
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Willy Tarreau]

Hello Alan,

did you receive the mails I sent to you on lxorguk last sunday with
the bonding driver updates ? I had mail problems, and received no ack.

If you want a resend, please just let me now.

Regards,
Willy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Matthias Andree]

Somewhat late, but not too late; Alan Cox wrote:

> 2.2.19pre1
...
> o	VIA686a timer reset to 18Hz background		(Vojtech Pavlik)

I patched my 2.2.18-ma2 with that patch to see if that helps me off my
sys time slowness, but it does unfortunately not help.

I have my system clock drift roughly -1 s/min, though my CMOS clock is
fine unless tampered with.

What can I do?

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Alan Cox]

> > o	VIA686a timer reset to 18Hz background		(Vojtech Pavlik)
> 
> I patched my 2.2.18-ma2 with that patch to see if that helps me off my
> sys time slowness, but it does unfortunately not help.

Thats unrelated

> I have my system clock drift roughly -1 s/min, though my CMOS clock is
> fine unless tampered with.

Unless its a driver holding off irqs for a long time your only option is
probably to replace the crystals on the board with ones that are more
accurate.

adjtimex will let you tell Linux the clock on the board is crap too

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Matthias Andree]

On Thu, 28 Dec 2000, Alan Cox wrote:

> > > o	VIA686a timer reset to 18Hz background		(Vojtech Pavlik)
> > 
> > I patched my 2.2.18-ma2 with that patch to see if that helps me off my
> > sys time slowness, but it does unfortunately not help.
> 
> Thats unrelated

Ok, that's what I eventually figured by looking at the code as well.

> > I have my system clock drift roughly -1 s/min, though my CMOS clock is
> > fine unless tampered with.
> 
> Unless its a driver holding off irqs for a long time your only option is
> probably to replace the crystals on the board with ones that are more
> accurate.

Wait a minute, this is a new board. I had a suspicion, and I have a new
suspect, can we investigate this?

I have used the same kernel, with the VIA 686a patch, but left some
config options out:

# diff -U1 -Nur <(egrep -v '^(#|$)' linux-2.2.18-ma3/.config) <(egrep -v
'^(#|$)' linux-2.2.18-try/.config)
--- /dev/fd/63  Thu Dec 28 11:20:05 2000
+++ /dev/fd/62  Thu Dec 28 11:20:05 2000
@@ -30,6 +30,2 @@
 CONFIG_PARPORT_PC=m
 -CONFIG_APM=y
 -CONFIG_APM_CPU_IDLE=y
 -CONFIG_APM_DISPLAY_BLANK=y
 -CONFIG_APM_RTC_IS_GMT=y
  CONFIG_BLK_DEV_FD=y

I rebooted, and since I left APM out, the system clock is alright since
63 mins. Might the APM BIOS CPU IDLE calls be related? I did *not* enable
CONFIG_APM_ALLOW_INTS. I'll investigate this right now and report back
what I find.

> adjtimex will let you tell Linux the clock on the board is crap too

Where is the source for the adjtimex /program/? SuSE don't bring
adjtimex.

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Alan Cox]

> Wait a minute, this is a new board. I had a suspicion, and I have a new
> suspect, can we investigate this?

Yep

> I rebooted, and since I left APM out, the system clock is alright since
> 63 mins. Might the APM BIOS CPU IDLE calls be related? I did *not* enable

If the APM bios holds interrupts off or doesnt let Linux handle each time
tick.

> CONFIG_APM_ALLOW_INTS. I'll investigate this right now and report back
> what I find.

That would be interesting
> 
> > adjtimex will let you tell Linux the clock on the board is crap too
> 
> Where is the source for the adjtimex /program/? SuSE don't bring
> adjtimex.

tickadj I think is one front end to it

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Matthias Andree]

On Thu, 28 Dec 2000, Alan Cox wrote:

> > CONFIG_APM_ALLOW_INTS. I'll investigate this right now and report back
> > what I find.
> 
> That would be interesting

Forget this all.

I found the problem trigger, it's reading from /proc/apm, for a reason I
cannot currently see.

Current config, as far as it's APM-related:
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
CONFIG_APM_RTC_IS_GMT=y
CONFIG_APM_ALLOW_INTS=y
# CONFIG_APM_REAL_MODE_POWER_OFF is not set
# CONFIG_TOSHIBA is not set

I had found out that my clock was slow while dnetc was running. I had a
dummy loader that just did while(1) {} which did not slow my clock. Now, I
straced that dnetc beast and found out that it reads /proc/apm quite
often.

I can have my clock almost halt with this one:

while cat /proc/apm ; do : ; done

If I leave this running for 15 s, my system time drifts back 11½ s.


Relevant dmesg:
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.13)


Board: Gigabyte 7ZXR, BIOS rev. F4 (VIA KT133 chip set, AMIBIOS).



I can and will test further, also with recompiled kernels, but I need
directions what to test.

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Matthias Andree]

On Thu, 28 Dec 2000, Matthias Andree wrote:

> Relevant dmesg:
> apm: BIOS version 1.2 Flags 0x03 (Driver version 1.13)
> 
> 
> Board: Gigabyte 7ZXR, BIOS rev. F4 (VIA KT133 chip set, AMIBIOS).

That's not a notebook, with a Duron CPU.

For what it's worth, here's a current /proc/apm output:

1.13 1.2 0x03 0x01 0xff 0x80 -1% -1 ?

That does not really tell us any more than we have APM driver version
1.13, APM BIOS v1.2, that it does support 16 and 32 bit, but idle does
not slow the clock, APM is engaged and enabled, that we're running
on-line and we don't know how long the power plants will last ;-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Erik Mouw]

On Thu, Dec 28, 2000 at 02:53:37PM +0100, Matthias Andree wrote:
> Forget this all.
> 
> I found the problem trigger, it's reading from /proc/apm, for a reason I
> cannot currently see.
> 
> Current config, as far as it's APM-related:
> CONFIG_APM=y
> # CONFIG_APM_IGNORE_USER_SUSPEND is not set
> # CONFIG_APM_DO_ENABLE is not set
> # CONFIG_APM_CPU_IDLE is not set
> # CONFIG_APM_DISPLAY_BLANK is not set
> CONFIG_APM_RTC_IS_GMT=y
> CONFIG_APM_ALLOW_INTS=y
> # CONFIG_APM_REAL_MODE_POWER_OFF is not set
> # CONFIG_TOSHIBA is not set
> 
> I had found out that my clock was slow while dnetc was running. I had a
> dummy loader that just did while(1) {} which did not slow my clock. Now, I
> straced that dnetc beast and found out that it reads /proc/apm quite
> often.

I got the same problem while running the GNOME battery_applet, which
checks /proc/apm every 2 seconds.

> I can have my clock almost halt with this one:
> 
> while cat /proc/apm ; do : ; done
> 
> If I leave this running for 15 s, my system time drifts back 11½ s.

Same over here on an Asus M8300 notebook (Celeron 500, 128MB, Intel
440MX chipset). Output from /proc/apm:

  1.14 1.2 0x03 0x01 0x03 0x09 100% -1 ?

I also enabled CONFIG_APM_ALLOW_INTS to see if it makes any difference,
but apparently it doesn't.

However, reading from /proc/apm also triggers other weird problems:

- Sound hickups: mp3 output starts to sound "scratchy". problem
  disappears after restarting mp3 player or after a couple of reads
  from /proc/apm. This is with mpg123, xmms, and madplay.
- USB drop outs, especially for bulk devices like scanners or USB audio
  devices. For sound it usually takes a second or so to restart.
- Received characters dropped on serial line. I thought my serial port
  was broken, because a 16550 is supposed to have a receive buffer.

All these problems went away when I removed the GNOME battery_applet.

I got the same problems with my previous notebook (Asus P6300, PII 266,
112MB, Intel BX/ZX chipset). It might be a BIOS problem, because both
notebooks use a Phoenix BIOS. OTOH, I can create the same problems with
USB on my desktop (Asus P5A motherboard, K6 333, 160MB, Ali 1541
chipset, Award BIOS) when I run the GNOME battery_applet. So is this an
Asus problem, or a general APM problem?


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Matthias Andree]

On Fri, 29 Dec 2000, Erik Mouw wrote:

> On Thu, Dec 28, 2000 at 02:53:37PM +0100, Matthias Andree wrote:
> However, reading from /proc/apm also triggers other weird problems:
> 
> - Received characters dropped on serial line. I thought my serial port
>   was broken, because a 16550 is supposed to have a receive buffer.

I don't know that the Linux driver sets the IRQ trigger to (you can have
the 16550 request interrupts after its 16-byte FIFO has 1, 4, 8 or 14
bytes ready for reading), but if it's set to 14 (to reduce the IRQ
frequency), you don't have much time at 115200 Bit/s, you have 1 Byte
every 87 ms then (it has 10 bit usually, 1 start + 1 stop bit), and
reading from /proc/apm stops my system clock for approx. 80 ... 90 ms -
then you still have IRQs with higher precedence and whooops, your buffer
overruns. Setting the trigger lower would help, but I never looked how
this will happen.

(I never run into this problem myself since I have 16750s here which
have at least 8 Bytes left when triggering, they have 64 Byte FIFO.)

> I got the same problems with my previous notebook (Asus P6300, PII 266,
> 112MB, Intel BX/ZX chipset). It might be a BIOS problem, because both
> notebooks use a Phoenix BIOS. OTOH, I can create the same problems with
> USB on my desktop (Asus P5A motherboard, K6 333, 160MB, Ali 1541
> chipset, Award BIOS) when I run the GNOME battery_applet. So is this an
> Asus problem, or a general APM problem?

My problem shows up on a Gigabyte board with AMIBIOS, so it's certainly
not a Phoenix or Asus specific problem.

However, reading from /proc/apm triggers BIOS calls which involve
certain action, maybe switching to Real Mode and other things, and I
suspect that either IRQs are still disabled while the BIOS is called or
the BIOS plays bad games which Linux would have to compensate for. :-/

HTH,
Matthias
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Alan Cox]

> However, reading from /proc/apm triggers BIOS calls which involve
> certain action, maybe switching to Real Mode and other things, and I
> suspect that either IRQs are still disabled while the BIOS is called or
> the BIOS plays bad games which Linux would have to compensate for. :-/

Looking at the one laptop with this problem I could acquire access to it seems
that the box switches to SMM mode with interrupts disabled for several timer
ticks. During this time the i2c bus is active and it appears to be having a
slow polled conversation with the battery or something attached to the battery
and monitoring it.

Doing

	while { true }
	do
		cat /proc/apm
	done

made the box visibly stall and jerk doing X operations


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Erik Mouw]

On Sat, Dec 30, 2000 at 05:01:27PM +0000, Alan Cox wrote:
> Looking at the one laptop with this problem I could acquire access to it seems
> that the box switches to SMM mode with interrupts disabled for several timer
> ticks. During this time the i2c bus is active and it appears to be having a
> slow polled conversation with the battery or something attached to the battery
> and monitoring it.

Sounds like a good explanation.

> Doing
> 
> 	while { true }
> 	do
> 		cat /proc/apm
> 	done
> 
> made the box visibly stall and jerk doing X operations

Yup, same over here. Is there any way to find out if my laptop also
enters SMM mode? Just to check if it has the same problem as your
laptop.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Alan Cox]

> > made the box visibly stall and jerk doing X operations
> 
> Yup, same over here. Is there any way to find out if my laptop also
> enters SMM mode? Just to check if it has the same problem as your
> laptop.

Not unless you want to stick wires into it and onto the i2c bus 8) At least
not that I know of other than disassembling the drivers

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Matthias Andree]

On Sat, 30 Dec 2000, Alan Cox wrote:

> Looking at the one laptop with this problem I could acquire access to it seems
> that the box switches to SMM mode with interrupts disabled for several timer
> ticks. During this time the i2c bus is active and it appears to be having a
> slow polled conversation with the battery or something attached to the battery
> and monitoring it.
> 
> Doing
> 
> 	while { true }
> 	do
> 		cat /proc/apm
> 	done
> 
> made the box visibly stall and jerk doing X operations

Alan, that's what I reported -- restricted to the system time -- two
days ago in <20001228151441.A3473@emma1.emma.line.org>. That mail is
also in my lk folder and has kernel.org Received: headers, so you should
have got that mail as well; plus you got it as copy. Is there something
wrong with mail routing?

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Matthias Andree]

On Sat, 30 Dec 2000, Alan Cox wrote:

> Looking at the one laptop with this problem I could acquire access to
> it seems that the box switches to SMM mode with interrupts disabled
> for several timer ticks. During this time the i2c bus is active and it
> appears to be having a slow polled conversation with the battery or
> something attached to the battery and monitoring it.
> 
> Doing
> 
> 	while { true } do cat /proc/apm done
> 
> made the box visibly stall and jerk doing X operations

Ok, now, what can be done about the stall? I assume nothing serious.

Is there at least away we can recover the proper system time after these
stalls?

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Chris Wedgwood]

    Is there at least away we can recover the proper system time
    after these stalls?

re-read the RTC -- but that's pretty slow and ugly



  --cw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Alan Cox]

>     Is there at least away we can recover the proper system time
>     after these stalls?
> 
> re-read the RTC -- but that's pretty slow and ugly

Be very careful doing that in 2.4test. The 2.2 CMOS locking patches are not yet
in so there is already a window for CMOS problems as far as I can tell. Don't
make it bigger

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] CMOS locking for 2.4 (was: /proc/apm slows system time)

[Paul Gortmaker]

Alan Cox wrote:
> 
> >     Is there at least away we can recover the proper system time
> >     after these stalls?
> >
> > re-read the RTC -- but that's pretty slow and ugly
> 
> Be very careful doing that in 2.4test. The 2.2 CMOS locking patches are not yet
> in so there is already a window for CMOS problems as far as I can tell. Don't
> make it bigger

This should cover CMOS locking for 2400-prerel.

Paul.

diff -ur linux-orig/Documentation/rtc.txt linux/Documentation/rtc.txt
--- linux-orig/Documentation/rtc.txt	Fri May 26 16:03:14 2000
+++ linux/Documentation/rtc.txt	Tue Jan  2 05:48:03 2001
@@ -56,7 +56,7 @@
 exclusive access to the device for your applications.
 
 The alarm and/or interrupt frequency are programmed into the RTC via
-various ioctl(2) calls as listed in ./include/linux/mc146818rtc.h
+various ioctl(2) calls as listed in ./include/linux/rtc.h
 Rather than write 50 pages describing the ioctl() and so on, it is
 perhaps more useful to include a small test program that demonstrates
 how to use them, and demonstrates the features of the driver. This is
@@ -81,7 +81,7 @@
  */
 
 #include <stdio.h>
-#include <linux/mc146818rtc.h>
+#include <linux/rtc.h>
 #include <sys/ioctl.h>
 #include <sys/time.h>
 #include <sys/types.h>
diff -ur linux-orig/arch/i386/kernel/process.c linux/arch/i386/kernel/process.c
--- linux-orig/arch/i386/kernel/process.c	Mon Jan  1 04:36:51 2001
+++ linux/arch/i386/kernel/process.c	Tue Jan  2 08:58:50 2001
@@ -32,6 +32,7 @@
 #include <linux/delay.h>
 #include <linux/reboot.h>
 #include <linux/init.h>
+#include <linux/mc146818rtc.h>
 
 #include <asm/uaccess.h>
 #include <asm/pgtable.h>
@@ -257,6 +258,8 @@
  */
 void machine_real_restart(unsigned char *code, int length)
 {
+	unsigned long flags;
+
 	cli();
 
 	/* Write zero to CMOS register number 0x0f, which the BIOS POST
@@ -266,10 +269,12 @@
 	   disable NMIs by setting the top bit in the CMOS address register,
 	   as we're about to do peculiar things to the CPU.  I'm not sure if
 	   `outb_p' is needed instead of just `outb'.  Use it to be on the
-	   safe side. */
+	   safe side.  (Yes, CMOS_WRITE does outb_p's. -  Paul G.)
+	 */
 
-	outb_p (0x8f, 0x70);
-	outb_p (0x00, 0x71);
+	spin_lock_irqsave(&rtc_lock, flags);
+	CMOS_WRITE(0x00, 0x8f);
+	spin_unlock_irqrestore(&rtc_lock, flags);
 
 	/* Remap the kernel at virtual address zero, as well as offset zero
 	   from the kernel segment.  This assumes the kernel segment starts at
diff -ur linux-orig/drivers/char/nvram.c linux/drivers/char/nvram.c
--- linux-orig/drivers/char/nvram.c	Mon Nov 20 04:12:31 2000
+++ linux/drivers/char/nvram.c	Tue Jan  2 05:50:36 2001
@@ -107,8 +107,6 @@
 #include <asm/uaccess.h>
 #include <asm/system.h>
 
-extern spinlock_t rtc_lock;
-
 static int nvram_open_cnt;	/* #times opened */
 static int nvram_open_mode;		/* special open modes */
 #define	NVRAM_WRITE		1		/* opened for writing (exclusive) */
diff -ur linux-orig/drivers/char/rtc.c linux/drivers/char/rtc.c
--- linux-orig/drivers/char/rtc.c	Mon Nov 20 04:19:54 2000
+++ linux/drivers/char/rtc.c	Tue Jan  2 05:50:29 2001
@@ -89,8 +89,6 @@
 
 static DECLARE_WAIT_QUEUE_HEAD(rtc_wait);
 
-extern spinlock_t rtc_lock;
-
 static struct timer_list rtc_irq_timer;
 
 static loff_t rtc_llseek(struct file *file, loff_t offset, int origin);
diff -ur linux-orig/drivers/ide/hd.c linux/drivers/ide/hd.c
--- linux-orig/drivers/ide/hd.c	Mon Nov 20 04:19:58 2000
+++ linux/drivers/ide/hd.c	Tue Jan  2 08:05:44 2001
@@ -738,6 +738,7 @@
 	if (!NR_HD) {
 		extern struct drive_info drive_info;
 		unsigned char *BIOS = (unsigned char *) &drive_info;
+		unsigned long flags;
 		int cmos_disks;
 
 		for (drive=0 ; drive<2 ; drive++) {
@@ -773,10 +774,15 @@
 		Needless to say, a non-zero value means we have 
 		an AT controller hard disk for that drive.
 
-		
+		Currently the rtc_lock is a bit academic since this
+		driver is non-modular, but someday... ?         Paul G.
 	*/
 
-		if ((cmos_disks = CMOS_READ(0x12)) & 0xf0) {
+		spin_lock_irqsave(&rtc_lock, flags);
+		cmos_disks = CMOS_READ(0x12);
+		spin_unlock_irqrestore(&rtc_lock, flags);
+
+		if (cmos_disks & 0xf0) {
 			if (cmos_disks & 0x0f)
 				NR_HD = 2;
 			else
diff -ur linux-orig/drivers/ide/ide-geometry.c linux/drivers/ide/ide-geometry.c
--- linux-orig/drivers/ide/ide-geometry.c	Tue Aug  8 03:56:16 2000
+++ linux/drivers/ide/ide-geometry.c	Tue Jan  2 07:25:10 2001
@@ -3,6 +3,7 @@
  */
 #include <linux/config.h>
 #include <linux/ide.h>
+#include <linux/mc146818rtc.h>
 #include <asm/io.h>
 
 /*
@@ -46,13 +47,15 @@
 	extern struct drive_info_struct drive_info;
 	byte cmos_disks, *BIOS = (byte *) &drive_info;
 	int unit;
+	unsigned long flags;
 
 #ifdef CONFIG_BLK_DEV_PDC4030
 	if (hwif->chipset == ide_pdc4030 && hwif->channel != 0)
 		return;
 #endif /* CONFIG_BLK_DEV_PDC4030 */
-	outb_p(0x12,0x70);		/* specify CMOS address 0x12 */
-	cmos_disks = inb_p(0x71);	/* read the data from 0x12 */
+	spin_lock_irqsave(&rtc_lock, flags);
+	cmos_disks = CMOS_READ(0x12);
+	spin_unlock_irqrestore(&rtc_lock, flags);
 	/* Extract drive geometry from CMOS+BIOS if not already setup */
 	for (unit = 0; unit < MAX_DRIVES; ++unit) {
 		ide_drive_t *drive = &hwif->drives[unit];
diff -ur linux-orig/include/asm-i386/floppy.h linux/include/asm-i386/floppy.h
--- linux-orig/include/asm-i386/floppy.h	Mon Nov 20 04:17:40 2000
+++ linux/include/asm-i386/floppy.h	Tue Jan  2 06:19:09 2001
@@ -285,8 +285,28 @@
 static int FDC1 = 0x3f0;
 static int FDC2 = -1;
 
-#define FLOPPY0_TYPE	((CMOS_READ(0x10) >> 4) & 15)
-#define FLOPPY1_TYPE	(CMOS_READ(0x10) & 15)
+/*
+ * Floppy types are stored in the rtc's CMOS RAM and so rtc_lock
+ * is needed to prevent corrupted CMOS RAM in case "insmod floppy"
+ * coincides with another rtc CMOS user.		Paul G.
+ */
+#define FLOPPY0_TYPE	({				\
+	unsigned long flags;				\
+	unsigned char val;				\
+	spin_lock_irqsave(&rtc_lock, flags);		\
+	val = (CMOS_READ(0x10) >> 4) & 15;		\
+	spin_unlock_irqrestore(&rtc_lock, flags);	\
+	val;						\
+})
+
+#define FLOPPY1_TYPE	({				\
+	unsigned long flags;				\
+	unsigned char val;				\
+	spin_lock_irqsave(&rtc_lock, flags);		\
+	val = CMOS_READ(0x10) & 15;			\
+	spin_unlock_irqrestore(&rtc_lock, flags);	\
+	val;						\
+})
 
 #define N_FDC 2
 #define N_DRIVE 8
diff -ur linux-orig/include/linux/mc146818rtc.h linux/include/linux/mc146818rtc.h
--- linux-orig/include/linux/mc146818rtc.h	Wed Jun 28 11:39:35 2000
+++ linux/include/linux/mc146818rtc.h	Tue Jan  2 05:21:51 2001
@@ -15,6 +15,8 @@
 #include <linux/rtc.h>			/* get the user-level API */
 #include <asm/mc146818rtc.h>		/* register access macros */
 
+extern spinlock_t rtc_lock;		/* serialize CMOS RAM access */
+
 /**********************************************************************
  * register summary
  **********************************************************************/
diff -ur linux-orig/include/linux/rtc.h linux/include/linux/rtc.h
--- linux-orig/include/linux/rtc.h	Wed Jul 12 04:18:51 2000
+++ linux/include/linux/rtc.h	Tue Jan  2 05:37:04 2001
@@ -2,6 +2,8 @@
  * Generic RTC interface.
  * This version contains the part of the user interface to the Real Time Clock
  * service. It is used with both the legacy mc146818 and also  EFI
+ * Struct rtc_time and first 12 ioctl by Paul Gortmaker, 1996 - separated out
+ * from <linux/mc146818rtc.h> to this file for 2.4 kernels.
  * 
  * Copyright (C) 1999 Hewlett-Packard Co.
  * Copyright (C) 1999 Stephane Eranian <eranian@hpl.hp.com>



__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Alan Cox]

> > 	while { true } do cat /proc/apm done
> > 
> > made the box visibly stall and jerk doing X operations
> 
> Ok, now, what can be done about the stall? I assume nothing serious.

Nothing much

> Is there at least away we can recover the proper system time after these
> stalls?

If you have a tsc on your chip - I think most modern laptops will do as they
tend to be pentium/mmx k6 or pII/pIII processors, then you can check the 
elapsed CPU cycles and recover the jiffies from that. Might be an interesting
exercise for someone


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Erik Mouw]

On Sun, Dec 31, 2000 at 01:37:00PM +0000, Alan Cox wrote:
> Nothing much
> 
> > Is there at least away we can recover the proper system time after these
> > stalls?
> 
> If you have a tsc on your chip - I think most modern laptops will do as they
> tend to be pentium/mmx k6 or pII/pIII processors, then you can check the 
> elapsed CPU cycles and recover the jiffies from that. Might be an interesting
> exercise for someone

But that doesn't solve the problem with corrupted sound, serial drop
outs, etc. To solve those issues (well, to decrease their impact),
could we cache the results from a previous call and only call the APM
BIOS once a minute or so?


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Alan Cox]

> But that doesn't solve the problem with corrupted sound, serial drop
> outs, etc. To solve those issues (well, to decrease their impact),
> could we cache the results from a previous call and only call the APM
> BIOS once a minute or so?

Userspace issue. 

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Matthias Andree]

On Sun, 31 Dec 2000, Alan Cox wrote:

> If you have a tsc on your chip - I think most modern laptops will do as they
> tend to be pentium/mmx k6 or pII/pIII processors, then you can check the 
> elapsed CPU cycles and recover the jiffies from that. Might be an interesting
> exercise for someone

This had been a report for a non-portable computer which should (Duron)
indeed have a TSC, that is, /proc/cpuinfo lists one ;-) Do 486s
generally have APM so it might be worth fixing/working around for them?

If so, would re-reading from CMOS for boxes without TSC be a "valid"
solution?

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Alan Cox]

> This had been a report for a non-portable computer which should (Duron)
> indeed have a TSC, that is, /proc/cpuinfo lists one ;-) Do 486s
> generally have APM so it might be worth fixing/working around for them?
> 
> If so, would re-reading from CMOS for boxes without TSC be a "valid"
> solution?

The TSC one is fairly sane, the CMOS gets messy because host and CMOS time
are not always the same

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18: /proc/apm slows system time (was: Linux 2.2.19pre3)

[Matthias Andree]

On Tue, 02 Jan 2001, Alan Cox wrote:

> The TSC one is fairly sane, the CMOS gets messy because host and CMOS time
> are not always the same

The idea is to read out the CMOS clock before and after polling the
BIOS, hoping that the BIOS would not tamper with the CMOS time. However,
thinking more elaborately, I think, CMOS is limited to 1 s, so the
granularity will make the whole thing pretty vain.

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.19pre3

[Guest section DW]

On Thu, Dec 28, 2000 at 02:37:19AM +0000, Alan Cox wrote:

> > I have my system clock drift roughly -1 s/min, though my CMOS clock is
> > fine unless tampered with.

> adjtimex will let you tell Linux the clock on the board is crap too

But may tamper with the CMOS clock
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/