Messages in this thread | | | From | Frans Pop <> | Subject | Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) | Date | Tue, 2 Dec 2008 18:46:48 +0100 |
| |
On Tuesday 02 December 2008, Linus Torvalds wrote: > 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 no changes in my config that would explain that (checked the diff). The only changes are simple 'make oldconfig' updates.
> 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..
I could reinstall some intermediate versions and check when that change got introduced if that would help, or revert to the kernel I was using before I did the pull today and applied the debug patch (which was plain rc6 + a few selected bug fix patches that had not yet been merged).
> > 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.
Right. All these resumes were perfect.
> 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?
It did happen once a few days ago, but with the workarounds I had resume failures were extremely rare. I'll see if I can work out which boot it was, but that could well be very tricky as a failed resume leaves no trace.
The way I "see" the failure is that the wireless led does not come on
> 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.
/me always likes the use of "should" in such situations ;-)
> Do you perhaps dual-boot that laptop? What can sometimes happen is that > PCI resources do not get totally reset over a warm-boot.
No. I only run Debian testing on that machine. As Debian Lenny is getting close to release there are very few changes in userland ATM. For kernels I essentially follow git starting with -rc2/3 or so of each new minor.
> 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..
Given the above that does not seem relevant.
| |