http://bugzilla.kernel.org/show_bug.cgi?id=12878
--- Comment #66 from Eddy Petrișor <eddy.petrisor+lin...@gmail.com> 2009-10-23
06:58:05 ---
(In reply to comment #51)
> Quite likely, none!
>
> Unfortunately it could be such that slight differences in the handing of
> especially graphics might trigger BIOS bugs, but that's like finding a needle
> in a haystack.
>
> Now, the *current* code uses the new code for the resume path as well, but
> that
> is not the commit you fingered...
I was looking over this BR and I wanted to point out that currently the sleep
LED behaviour is not correct and since the first tests about sleep it remained
lit (while the machine is on, obviously) and booting in Windows or an older
kernel did not change things.
OTOH, testing sleep with the newer 2.6.32-rc3 I have observed that, although
the sleep-resume cycle still doesn't work properly, there is a slight change in
behaviour:
Before:
- trigger sleep
- pressing the power button for resume resulted in:
- some activity
- auto shut-down
- trying to power the laptop again would result in an "on" cycle which didn't
initialize the graphics card properly and the fans would speed (probably due to
some infinite cycle)
- to recover I had to power off again, then power on
With the new kernel the sequence is the same up until the auto shut-down
(including it), but then, when trying to power on the laptop doesn't result in
the fake failing power cycle.
Another idea, could someone help me come up with a patch that would enable me
to use even the incremental development commits of the setup sequence so I
could pin point which of the setup changes is actually at fault?
AIUI, now I am actually pointing to a 'blob' in a way, so I would like to pin
point which specific change in that blob is at fault.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
