Re: [Bug #15096] Resume lock up -- bisected, commit 3a1151e3f124fd1a2c54b8153f510f1a7c715369

[Stefan Bader]

RafaÅ MiÅecki wrote:
> 2010/2/8 Stefan Bader <stefan.bader@xxxxxxxxxxxxx>:
>> Rafael J. Wysocki wrote:
>>> On Monday 08 February 2010, RafaÅ MiÅecki wrote:
>>>> 2010/2/8 Stefan Bader <stefan.bader@xxxxxxxxxxxxx>:
>>>>> Rafael J. Wysocki wrote:
>>>>>> On Monday 08 February 2010, RafaÅ MiÅecki wrote:
>>>>>>> 2010/2/8 Rafael J. Wysocki <rjw@xxxxxxx>:
>>>>>>>> This message has been generated automatically as a part of a report
>>>>>>>> of regressions introduced between 2.6.31 and 2.6.32.
>>>>>>>>
>>>>>>>> The following bug entry is on the current list of known regressions
>>>>>>>> introduced between 2.6.31 and 2.6.32.  Please verify if it still should
>>>>>>>> be listed and let the tracking team know (either way).
>>>>>>>>
>>>>>>>>
>>>>>>>> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=15096
>>>>>>>> Subject         : Resume lock up -- bisected, commit 3a1151e3f124fd1a2c54b8153f510f1a7c715369
>>>>>>>> Submitter       : RafaÅ MiÅecki <zajec5@xxxxxxxxx>
>>>>>>>> Date            : 2010-01-20 23:15 (19 days old)
>>>>>>>> First-Bad-Commit: http://git.kernel.org/git/linus/3a1151e3f124fd1a2c54b8153f510f1a7c715369
>>>>>> It looks like we should revert this commit, seems broken.
>>>>> Hm, otoh we had definitely people with some Asus laptops who where only be able
>>>>> to use backlight control with it. So I would rather prefer some work around to
>>>>> the suspend/resume problem (_DOS if I understood correctly).
>>>> It's same case with my Sony VAIO. Without this I can not control
>>>> backlight. Eventually I can hack on GPU registers directly, but I
>>>> don't think it can be called solution.
>>> Well, do I understand correctly that without commit
>>> 3a1151e3f124fd1a2c54b8153f510f1a7c715369 you can't control the backlight,
>>> but with the commit applied there's a resume problem on your box?
>>>
>>> Rafael
>> RafaÅ can correct me. I would phrase it that way that without the bisected
>> patch, there is no backlight control. And because there is with it, we hit the
>> next BIOS bug because the backlight driver now tries to correctly bring it back
>> on resume.
> 
> Do you suspect some conflict between video module and BIOS? Any more ideas?
> 
That would be my guess based on the (admitted not to be very deep reading across
some of your and Rui's comments. He probably has a better Idea on that. But what
the patch in question does is to allow video devices that have not all the
methods defined (before _DOD *and* _DOS, after _DOD *or* _DOS) to be handled by
the generic acpi video driver. And this gets you backlight control (by some
additional methods). But now, as the driver is in use, it is in the
suspend/resume path and this causes problems.
>From cross reading bugmail I had the feeling Rui was on a track while I did not
follow close enough to take in any details.
I would suspect that code assumes details from those two (_DOD and _DOS which is
not there if the BIOS provides them both and is not handled as the driver used
to be only used in that case). I probably should get back and read the bug
report with all the info in detail somewhen tomorrow.

Stefan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/