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 '
> (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
-
To unsubscribe from this lis
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
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
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 ?
-
> 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 a
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
> 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
-
To unsubscribe from this list: send
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 th
> 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-pa
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 appl
> 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 anyt
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
13 matches
Mail list logo
