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
16 matches
Mail list logo
