Linux 2.2.19pre3

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 <[email protected]>
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

[snip]

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

@@ -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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

In article <[email protected]>,

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:

@@ -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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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

@@ -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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

...

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Thats unrelated

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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

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.

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Yep

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

That would be interesting

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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

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: [email protected]
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Sounds like a good explanation.

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: [email protected]
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan, that's what I reported -- restricted to the system time -- two days ago in <[email protected]>. 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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Nothing much

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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: [email protected]
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Userspace issue.

Alan

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

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

This should cover CMOS locking for 2400-prerel.

Paul.

diff -ur linux-orig/Documentation/rtc.txt linux/Documentation/rtc.txt
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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 <[email protected]>

__________________________________________________
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/