Re: Debugging APM - cat /proc/apm produces oops

From: Stephen Rothwell
Date: Sun Jul 23 2006 - 11:17:39 EST

On Sun, 23 Jul 2006 16:30:53 +0200 Ondrej Zary <linux@xxxxxxxxxxxxxxxxxxxx> wrote:
> cat /proc/apm produces oops on my DTK notebook. Using "apm=broken-psr" kernel
> parameter fixes that but I lose the battery info. I'd like to have the
> battery info (and it works fine in Windows) so I want to debug it and
> (hopefully) fix.

Is there some reason you can't (or don't want to) use ACPI on this machine?

> The oops:
> # cat /proc/apm
> <1>BUG: unable to handle kernel paging request at virtual address 00005e88
Looks like it tried to access through the stack pointer while executeing 16 bit code.

> printing eip:
> 00002f9d
> *pre = 00000000
> Oops: 0002 [#4]
> Modules linked in:
> CPU: 0
> EIP: 00c0:[<00002f9d>] Not tainted VLI
This is the APM BIOS 16 bit code segment.

> EFLAGS: 00010017 (2.6.17-5-dtk #23)
> EIP is at 0x2f94
> eax: 00000033 ebx: 00000001 ecx: 00000000 edx: 00000000
> esi: c10a1000 edi: 00000014 ebp: c4755e8a esp: c4755e88
Accessing the stack while executing 16 bit code is never going to work.

> ds: 00c8 es: 0000 ss: 0068
> Process cat (pid: 1928, threadinfo=c4754000 task=c11240b0)
> Stack: 5e948001 5fc75e55 00005e94 000000c8 10000033 5ea800c0 00000001 530a0000
> 00000016 00b86017 00000000 0000530a c010830f 00000060 0000530a 00000033
> 0000007b 0000007b c0337368 00000000 c10a1000 00000000 00000000 00000282
> Call Trace:
> <c010830f> apm_bios_call+0x68/0xba <c0108728> apm_get_power_status+0x44/0x90
> <c01091a0> apm_get_info+0x34/0xdc <c01617dc> proc_file_read+0xda/0x22d
> <c013b5a2> vfs_read+0x82/0x10e <c013b873> sys_read+0x3c/0x62
> <c0102397> syscall_call+0x7/0xb
> Code: Bad EIP value.
> EIP: [<00002f9d>] 0x2f9d SS:ESP 0068:c4755e88
> So it looks like it dies somewhere in the APM BIOS code. But how to find
> exactly where and/or why? Maybe use GDB somehow (I've used it only for really
> simple debugging yet).
> I've tried calling the APM 0x530A function from DOS (real mode, int 15h) and
> single-stepping the BIOS APM code (using good old user-friendly Turbo
> Debugger). Noticed some OUTs to 0xB1 (or something like that), then some PCI
> accesses (0xCF8 and 0xCFC) and then IP ended in area of all zeros. When I
> step over the int 15h call, it works fine - returns correct info.

APM BIOS's are often only tested in real mode as that will suffice for
older Windows systems. If you machine is less than 6 years old, Windows
is almost certainly using ACPI and not APM.

If you really want this fixedm you will have to talk to your machine
menufacturer (or the BIOS manufacturer).

Stephen Rothwell sfr@xxxxxxxxxxxxxxxx

Attachment: pgp00000.pgp
Description: PGP signature