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
> 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... ;)
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
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.
> 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
> > 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
> > 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.
> 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
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.
In article <[email protected]>,
Richard B. Johnson <[email protected]> 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.
On 22 Dec 2000, Miquel van Smoorenburg wrote:
> In article <[email protected]>,
> Richard B. Johnson <[email protected]> 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.
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
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
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
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
> > 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
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
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
> 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
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
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 ;-)
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: [email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/
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
> 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
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: [email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/
> > 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
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 <[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
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
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
> 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
> > 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
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: [email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/
> 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