Re: Regression from 2.6.26: Hibernation (possibly suspend) brokenon Toshiba R500 (bisected)

From: Linus Torvalds
Date: Tue Dec 02 2008 - 18:38:33 EST

On Tue, 2 Dec 2008, Rafael J. Wysocki wrote:
> * dmesg output including one hibernation-resume cycle from 2.6.28-rc7 with the
> debug patch (appended for completness):
> * dmesg output including one hibernation-resume cycle from 2.6.28-rc7 without
> the debug patch:

As with Frans, the debug patch seems to make no difference what-so-ever.
Yes, the cardbus regions get allocated differently, but they're fine in
either case, and arguably (exactly as with Frans) the debug patch actually
makes things uglier by actively getting the alignment wrong, and skipping
cardbus setup until later.

That's what your patch (without debugging) should have resulted in too,
except you'd not have seen the "bad alignment flags" printout, of course
(but you probably would have seen the "bad alignment 0: [...]" one).

In fact, I'm starting to think I know why we set up the prefetch window
without the patch, and why we don't with it - because with the patch, the
PCI code ends up never seeing any valid prefetchable region for the
cardbus controller at all, so it never even bothers to try to set up a
prefetchable window.

So in many ways, the debug patch that gets the alignment wrong (on
purpose) is really the inferior one. Plain -rc7 seems to do everything

> * diff between the two:

Gaah. Using "-U 0" is likely the least readable form of diffs there
exists, even if it makes the diff smaller.

> This part of the diff (+ is the patched one) seems to be particularly
> interesting to me, especially the overlapping MEM windows for 0000:00:1e.0 and
> 0000:03:0b.0 (may that be the reason for the observed failures?):

No, those are very much on purpose.

Device 0000:00:1e.0 is the PCI bridge that bridges to PCI bus#3, so the
MEM window is very much intentional - exactly because MMIO goes through
that PCI bridge bus to get to bus#3, which is where the cardbus controller

IOW, the topology is as follows:
- CPU is on the root bus (bus #0)
- device 00:1e.0 is the PCI bridge to bus #3
- device 03:0b.0 is the CardBus bridge (to bus #4)
and any actual cardbus cards (if you had any) would be on that bus #4, so
they'd be named "04:xx.y".

Now, that PCI bridge 00:1e.0 is a transparent bridge (aka "[Subtractive
decode]" in your lspci output - as compared to the other bridges that say
"[Normal decode]"), which means that you don't actually _have_ to set up
any MMIO window on them, since the bridge will forward _any_ PCI cycles
that don't get responded to by any other PCI device.

But having an explicit window is still generally a good idea, since it
should allow the PCI bridge to pick up the PCI cycles earlier (no need to
wait to see if others respond to it), and possibly allows for better
prefetching behavior. So again, the dmesg and the PCI layout actually
looks _better_ without the hacky patch.

So are you saying that the unpatched kernel still reliably doesn't
hibernate for you, while the (arguably _incorrect_) patched kernel
reliably does hibernate?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at