Re: suspend order - again

Re: suspend order - again

[Rafael J. Wysocki]

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.

Thanks,
Rafael

Re: suspend order - again

[Len Brown]

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.

-Len

Re: suspend order - again

[Rafael J. Wysocki]

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

Re: suspend order - again

[Len Brown]

On Thursday 27 March 2008, Rafael J. Wysocki wrote:
> 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 ...

Unfortunately logic doesn't rule here -- compatibility
with the installed base is the only thing that matters.

Of course when we've got examples and counter-examples,
it can be quite a puzzle figuring out what
hoops that installed base is asking us to jump through:-)

Re: suspend order - again

[Carlos Corbacho]

> Unfortunately logic doesn't rule here -- compatibility
> with the installed base is the only thing that matters.
>
> Of course when we've got examples and counter-examples,
> it can be quite a puzzle figuring out what
> hoops that installed base is asking us to jump through:-)

As one of the 'installed base', I say keep the 1.0 order for .25, because
it fixes a real regression that has been around for three releases.

We currently have more examples of nVidia boards that were broken by the
2.0 ordering, than we have concrete examples of boards broken by the 1.0
ordering (3 to 1).

We had the 1.0 ordering before, and we have a DMI quirk for the one system
shown so far to actually be broken with the 1.0 ordering, and, IIUC, we
also have the infrastructure now to be able to test either order on
systems to gather more information. If we find more systems that break
with the 1.0 ordering than 2.0, then yes, we can review this decision in
.26.

IMHO, we need more concrete data to decide which way we default to (i.e.
are nVidia boards just an abberation here, or is this
1.0-ordering-required problem more wide spread? We may be lucky, and we
only need to switch to the 1.0 order if we detect an nVidia chipset, or
start blacklisting the bad boards/ BIOS's, since I suspect Windows has
some sort of nVidia chipset blacklist as well, although I don't know how
fine grained).

-Carlos
-- 
E-Mail: carlos@strangeworlds.co.uk
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D