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

[Frans Pop]

On Wednesday 03 December 2008, Linus Torvalds wrote:
> Well, I think that what _would_ be generally correct, and actually
> pretty simple, is a rather different approach: just not sizing things
> behind a transparent bridge AT ALL, since it really shouldn't matter.

I've given your patch a try and the few resumes from STR I've done were 
all successful. That's not 100% conclusive yet, but a nice start.
Some info from logs etc. below.

> > Also, I would be happy to actually understand _why_ this happens.
>
> 100% agreed. I do _not_ see why it should ever matter how we set up a
> PCI bridging window - whether prefetchable or not - on a bridge that
> should be transparent. It sounds really odd. I'm wondering if there is
> something we're missing here.

The theory that it is really a resume issue and not a device layout issue 
sounds logical. Especially as everything always works correctly after a 
normal boot.

Cheers,
FJP

Below info from 3 kernels, all based on 2.6.28-rc7-91:
A) unpatched
B) with the revert/debug patch
C) with the oneliner "ignore transparent bridges" patch

AFAICT all results are probably as expected.

From lspci -vvxxx:
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge
- for A)
	I/O behind bridge: 00003000-00003fff
	Memory behind bridge: e0100000-e03fffff
	Prefetchable memory behind bridge: 0000000080000000-0000000083ffffff
- for B)
	I/O behind bridge: 00003000-00003fff
	Memory behind bridge: e0100000-e03fffff
- for C)
	Memory behind bridge: e0100000-e03fffff
02:06.0 CardBus bridge: Ricoh Co Ltd RL5c476 II
- for A)
	Memory window 0: 80000000-83fff000 (prefetchable)
	Memory window 1: 84000000-87fff000
	I/O window 0: 00003000-000030ff
	I/O window 1: 00003400-000034ff
- for B)
	Memory window 0: 84400000-847ff000 (prefetchable)
	Memory window 1: 80000000-83fff000
	I/O window 0: 00003000-000030ff
	I/O window 1: 00003400-000034ff
- for C)
	Memory window 0: 80000000-83fff000 (prefetchable)
	Memory window 1: 84000000-87fff000
	I/O window 0: 00001400-000014ff
	I/O window 1: 00001800-000018ff

From /proc/iomem:
- for A)
80000000-83ffffff : PCI Bus 0000:02
  80000000-83ffffff : PCI CardBus 0000:03
84000000-87ffffff : PCI CardBus 0000:03
88000000-88000fff : Intel Flush Page
- for B)
80000000-83ffffff : PCI CardBus 0000:03
84000000-84000fff : Intel Flush Page
84400000-847fffff : PCI CardBus 0000:03
- for C)
80000000-83ffffff : PCI CardBus 0000:03
84000000-87ffffff : PCI CardBus 0000:03
88000000-88000fff : Intel Flush Page

Attached a tarball with dmesg for all 3 kernel, including a successful 
STR/resume cycle for each (not cleaned up this time).
A) 2.6.28-rc7_nofix
B) 2.6.28-rc7_revert
C) 2.6.28-rc7_resumefix

From the last one:
pci 0000:02:06.0: CardBus bridge, secondary bus 0000:03
pci 0000:02:06.0:   IO window: 0x001400-0x0014ff
pci 0000:02:06.0:   IO window: 0x001800-0x0018ff
pci 0000:02:06.0:   PREFETCH window: 0x80000000-0x83ffffff
pci 0000:02:06.0:   MEM window: 0x84000000-0x87ffffff
pci 0000:00:1e.0: PCI bridge, secondary bus 0000:02
pci 0000:00:1e.0:   IO window: disabled
pci 0000:00:1e.0:   MEM window: 0xe0100000-0xe03fffff
pci 0000:00:1e.0:   PREFETCH window: disabled
[...]
bus: 02 index 0 mmio: [0x0-0x0]
bus: 02 index 1 mmio: [0xe0100000-0xe03fffff]
bus: 02 index 2 mmio: [0x0-0x0]
bus: 02 index 3 io port: [0x00-0xffff]
bus: 02 index 4 mmio: [0x000000-0xffffffffffffffff]
bus: 03 index 0 io port: [0x1400-0x14ff]
bus: 03 index 1 io port: [0x1800-0x18ff]
bus: 03 index 2 mmio: [0x80000000-0x83ffffff]
bus: 03 index 3 mmio: [0x84000000-0x87ffffff]

Attachment: dmesg.tgz
Description: application/tgz