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 e
> 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
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
T
> 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:
On Sun, Dec 31, 2000 at 01:37:00PM +, 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,
> > 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
> 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 te
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 conversa
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 conversa
> > 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
On Sat, Dec 30, 2000 at 05:01:27PM +, 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
>
> 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
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
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
>
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
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
> 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 interrupt
On Thu, Dec 28, 2000 at 02:37:19AM +, 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
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 eventual
> > 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
>
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 r
Hi
That did it, thanks
Kees
On Sat, 23 Dec 2000, J . A . Magallon wrote:
>
> On 2000.12.23 kees wrote:
> > Hi,
> >
> > Trying to build 2.2.18+pe-patch-2.2.19-3 gives:
> >
> >
> > /usr/bin/cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
> > -O2
> > -fomit-frame-pointer -f
On 2000.12.23 kees wrote:
> Hi,
>
> Trying to build 2.2.18+pe-patch-2.2.19-3 gives:
>
>
> /usr/bin/cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
> -O2
> -fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce
> -m486 -malign-loops=2 -malign-jumps=2
Hi,
Trying to build 2.2.18+pe-patch-2.2.19-3 gives:
/usr/bin/cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce -m486
-malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -c -o ne2k-p
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 bo
ory. 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: 000a @ (usable)
BIOS-88: 02e0 @ 0010 (usable)
Memory: 46128k/48128k available
linux-2.2.18 or linux-2
n'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
> +++ lin
w 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
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 versio
> 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 behavi
> > 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 wa
> > 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
On Fri, 22 Dec 2000, Petri Kaukasoina wrote:
> On Fri, Dec 22, 2000 at 12:52:32AM +, 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 sc
> 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 th
On Fri, Dec 22, 2000 at 12:52:32AM +, 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 fo
> 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
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 Samuel
37 matches
Mail list logo
