[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0812020735150.3256@nehalem.linux-foundation.org>
Date: Tue, 2 Dec 2008 07:46:38 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Frans Pop <elendil@...net.nl>
cc: rjw@...k.pl, greg@...ah.com, mingo@...e.hu,
jbarnes@...tuousgeek.org, lenb@...nel.org,
linux-kernel@...r.kernel.org, tiwai@...e.de,
akpm@...ux-foundation.org, ink@...assic.park.msu.ru
Subject: Re: Regression from 2.6.26: Hibernation (possibly suspend) broken
on Toshiba R500 (bisected)
On Tue, 2 Dec 2008, Frans Pop wrote:
>
> Attached is a full diff between dmesg from -rc3 and -rc6 with your debug
> patch.
>
> I've cleaned up the diff a bit to make it more readable (mostly removal of
> changes that I always get due to random USB load order changes - UHCI
> still frequently loads before EHCI).
>
> The most interesting points are probably at lines 298-346 and 639-649.
So, it looks like you have MSI enabled in -rc6, and not in -rc3. And yes,
for some reason -rc3 will create the prefetchable memory range windows,
but -rc6 won't.
I have to admit that I'm not seeing _why_ to that latter one. I don't
think we've done any resource allocation changes since -rc3 (the "clean up
late e820 resource allocation" thing happened just _before_ -rc3), so I'm
really not seeing why -rc3 would act differently from -rc6..
> At the bottom there's a fairly long addition from the few suspend/resume
> cycles I did (again, running with the debug patch).
Sure. Quite frankly, from these messages, I'm not seeing anything really
even remotely wrong. And apparently it does actually work for you.
It would perhaps be more interesting to see if there is some dmesg
difference in a boot that then ends up _not_ able to resume from
hibernation? But apparently that hasn't happened to you lately?
I don't like not knowing why you have prefetchable windows in one, and not
in the other, but it is indeed a transparent bridge and so that difference
really shouldn't even matter.
Do you perhaps dual-boot that laptop? What can sometimes happen is that
PCI resources do not get totally reset over a warm-boot.
We've (very occasionally) had situations where PCI resource bugs only
happen when you warm-boot from another OS (generally Windows), or when you
warm-boot from an earlier version of Linux. Exactly because some firmware
didn't fully re-initialize the state of the PCI bus, and because Linux
will try to honor everything that the firmware set up..
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists