Hi Stephen,
I presume this should be going to you, as the person named in
arch/i386/kernel/apm.c - if not please redirect/ignore as appropriate.
I compiled the Debian distribution of 2.2.18pre21 source on and for a
AcerNote-950, with APM enabled.
All is fine except that I can reliably "oops" it simply by trying to read
from /proc/apm (e.g. cat /proc/apm).
oops output and ksymoops-2.3.4 output is attached.
Is there anything else I can contribute?
Thanks,
Neale.
> I compiled the Debian distribution of 2.2.18pre21 source on and for a
> AcerNote-950, with APM enabled.
>
> All is fine except that I can reliably "oops" it simply by trying to read
> from /proc/apm (e.g. cat /proc/apm).
>
> oops output and ksymoops-2.3.4 output is attached.
>
> Is there anything else I can contribute?
The latitude and longtitude of the bios writers current position, and
a ballistic missile.
Please boot 2.2.18pre24 (not pre25) on the machine and send me its DMI strings
printed at boot time. I'll add it to the 'stupid morons who cant program and
wouldnt know QA if it hit them on the head with a mallet' list
On Fri, 8 Dec 2000, Alan Cox wrote:
> > Is there anything else I can contribute?
>
> The latitude and longtitude of the bios writers current position, and
> a ballistic missile.
;-)
> Please boot 2.2.18pre24 (not pre25) [...]
Please pardon the naive question: is pre-patch-2.2.18-24 to be applied
over 2.2.17?
Thanks,
Neale.
> On Fri, 8 Dec 2000, Alan Cox wrote:
>
> > > Is there anything else I can contribute?
> >
> > The latitude and longtitude of the bios writers current position, and
> > a ballistic missile.
>
> ;-)
>
> > Please boot 2.2.18pre24 (not pre25) [...]
>
> Please pardon the naive question: is pre-patch-2.2.18-24 to be applied
> over 2.2.17?
Yes. Each pre is relative to 2.2.17
On Fri, 8 Dec 2000, Alan Cox wrote:
[...]
> Please boot 2.2.18pre24 (not pre25) on the machine and send me its DMI strings
> printed at boot time. I'll add it to the 'stupid morons who cant program and
> wouldnt know QA if it hit them on the head with a mallet' list
OK, I did this (at least I think I got it right: the patch was happy) but
I can't see anything resembling DMI strings (even after I removed
frame-buffer so as not to nuke the first few messages). What keywords etc
should I be seeing, at what point?
the only vaguely relevant message I see is:
apm: BIOS version 1.1 Flags 0x03 (Driver version 1.13)
Thanks,
Neale.
> OK, I did this (at least I think I got it right: the patch was happy) but
> I can't see anything resembling DMI strings (even after I removed
Ok your machine probably doesnt have DMI then. That unfortunately means its
hard to identify the specific machine
On Sun, 10 Dec 2000, Alan Cox wrote:
> > OK, I did this (at least I think I got it right: the patch was happy) but
> > I can't see anything resembling DMI strings (even after I removed
>
> Ok your machine probably doesnt have DMI then. That unfortunately means its
> hard to identify the specific machine
Which I presume rather rules out automagic detection and workaround?
I take it you are refering to the Phoenix BIOS detection code in
arch/i386/kernel/dmi_scan.c (ah yes, I see coments about QA ;-) and
subsequent call to apm_battery_horked()?
Is it "obvious" that I'm dealing with the same or similar kind of
bugginess here?
That being the case, any reason I can't/shouldn't put in a function
similar to apm_battery_horked(), and call/run it based on a config-time
variable?
FWIW, the machine claims "Phoenix NoteBIOS" dated 1994, and the poweroff
bit of APM appears to work just fine.
Thanks,
Neale.
> Is it "obvious" that I'm dealing with the same or similar kind of
> bugginess here?
Obvious no, but its a pretty good guess.
>
> That being the case, any reason I can't/shouldn't put in a function
> similar to apm_battery_horked(), and call/run it based on a config-time
> variable?
None at all
> FWIW, the machine claims "Phoenix NoteBIOS" dated 1994, and the poweroff
> bit of APM appears to work just fine.
Alan
On Sun, 10 Dec 2000, Alan Cox wrote:
> > Is it "obvious" that I'm dealing with the same or similar kind of
> > bugginess here?
>
> Obvious no, but its a pretty good guess.
FWIW, I now get:
-------------------------------------
neale@gull:~$ cat /proc/apm
1.13 1.1 0x03 0xff 0xff 0xff -1% -1 ?
-------------------------------------
> > That being the case, any reason I can't/shouldn't put in a function
> > similar to apm_battery_horked(), and call/run it based on a config-time
> > variable?
>
> None at all
Diff against unmolested 2.2.18pre24 is attached.
Obviously the next challenge is to figure out how I can get what
information out of this strange beastie.
Regards,
Neale.
On Tue, 12 Dec 2000, Neale Banks wrote:
[...]
> Diff against unmolested 2.2.18pre24 is attached.
Hold that one, I just found another case I haven't covered: booting with
apm=debug causes oops and nukes the bootup. Reading the source, I can't
see how this doesn't also affect the "dell_crap" case too.
New diff to follow, hopefully tomorrow.
Neale.
On Tue, 12 Dec 2000, Neale Banks wrote:
[...]
> New diff to follow, hopefully tomorrow.
New diff against unmolested 2.2.18pre24 (appears to apply cleanly to
2.2.18 also) is attached.
Main points:
(1) adds a configure item for buggy BIOS (i.e. that can't be automagically
detected).
(2) catches the case of booting with boot-parameter apm=debug (previously
this could cause a fatal oops during the boot)
(3) modifies the output of /proc/apm when power status reporting is
disabled - on reflection, maybe this wasn't such a smart thing to do
(could royally stuff anybody who is automagically parsing /proc/apm?)
Neale.
> (3) modifies the output of /proc/apm when power status reporting is
> disabled - on reflection, maybe this wasn't such a smart thing to do
> (could royally stuff anybody who is automagically parsing /proc/apm?)
Please dont - it correctly reports 'dunno' right now
On Wed, 13 Dec 2000, Alan Cox wrote:
> > (3) modifies the output of /proc/apm when power status reporting is
> > disabled - on reflection, maybe this wasn't such a smart thing to do
> > (could royally stuff anybody who is automagically parsing /proc/apm?)
>
> Please dont - it correctly reports 'dunno' right now
OK, (yet another) diff attached, against 2.2.18.
Neale.