On Thursday, 27 of March 2008, Len Brown wrote: > On Friday 14 March 2008, Rafael J. Wysocki wrote: > > On Friday, 14 of March 2008, Shaohua Li wrote: > > > I just found a system (Asus A6B00VC) suffers a regression of suspend > > > order adjust. In the system, if _PTS is called before pci device > > > suspend, pci config read of slot 01:01.0 will always return 0xffffffff > > > (only this slot, not other devices). Adding acpi_new_pts_ordering fixes > > > this. I checked the log, _PTS itself doesn't generate any pci config > > > access, it appears _PTS call into SMBIOS and changes something. Note, > > > this is ACPI 1.0 table. Should we just blacklist the system or re-think > > > the suspend order? > > > > I don't want to change the ordering of code. It's been changed for many times > > and it always turned out that some systems didn't work. > > > > If we can implement the blacklisting in a reasonable fashion, I'd prefer to do > > just that. > > It isn't obvious to me why this regression is exempt from the > normal response we have to regressions found during -rc. > Particullarly sinced it was root caused to show that > we did the right thing before and we do the wrong thing now. Hm, is it a post-2.6.24 one? Ah, it is. Well, ok. In fact we have examples both ways now, but I really won't be comfortable with changing the default ordering once again. OTOH, the "ACPI 2.0" ordering is more logical IMO ... Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
