[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200812041229.45443.elendil@planet.nl>
Date: Thu, 4 Dec 2008 12:29:43 +0100
From: Frans Pop <elendil@...net.nl>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: "Rafael J. Wysocki" <rjw@...k.pl>, Greg KH <greg@...ah.com>,
Ingo Molnar <mingo@...e.hu>, jbarnes@...tuousgeek.org,
lenb@...nel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
tiwai@...e.de, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)
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]
Download attachment "dmesg.tgz" of type "application/x-tgz" (32289 bytes)
Powered by blists - more mailing lists