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 kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
