suspend/resume regression

John Baldwin jhb at freebsd.org
Thu Jul 30 02:04:21 UTC 2015


On Saturday, July 25, 2015 03:54:40 PM Kevin Oberman wrote:
> John,
> 
> I'm concerned that two issues may be getting conflated.
> 
> The issue I thought we were looking at was the failure of some systems
> (T520, X220, T430) to resume after a number of PCI enhancements were MFCed.
> This is completely unrelated to the USB issue I was experiencing when
> trying to test the problem on HEAD. The more I think about it, the more I
> think that the USB "issue" is just how things need to work.

Well, the USB thing could be smarter, but it's a bit of a PITA.  What if
you take the USB stick out, mess with it on another system, then plug
it back in before resume?  All the cached file data in the RAM of the
resumed system would need to be invalidated, etc.

However, I ended up copying a HEAD kernel onto my USB stick and seeing 
that I at least got the console back before it panic'd.  This was sufficient
to let me test the reversion patch via the USB stick (and would be sufficient
for seeing if we can merge it again for 10.3).

> The real issue is just resuming the system after  r281874 was MFCed as a
> part of 284034. No USB connected file systems are involved. I m happy to
> see that it has been reverted for 10.2, but clearly, these changes are
> needed down the line and I hope the issue can be resolved well before 11.0.
> (This assumes a 10.3 before 11.0 happens next year.)

So it works fine in 11.0 on my x220, and as other folks reported in the PR,
so 11.0 is fine.  It is also needed for PCI-e hotplug to work after resume
(using out-of-tree patches for PCI-e hotplug that jmg@ has).  If I merge it
to 10.3 it won't be until I've verified that whatever I merge works on my
x220 as well as the T440.

-- 
John Baldwin


More information about the freebsd-stable mailing list