Re: Corrupted files after suspend to disk

[Andreas Hartmann]

Rafael J. Wysocki wrote:
> On Tuesday, March 13, 2012, Andreas Hartmann wrote:
>> Rafael J. Wysocki schrieb:
>>> On Tuesday, March 13, 2012, Andreas Hartmann wrote:
>>>> Dave Jones wrote:
>>>>> On Mon, Mar 12, 2012 at 02:24:00PM +0100, Andreas Hartmann wrote:
>>>>>  
>>>>>  > >>>>> This is happening to me as well. Something like 1 resume out of 5 goes
>>>>>  > >>>>> wrong this very same way.
>>>>>  > >>>>>
>>>>>  > >>>>> This is thinkpad x200s.
>>>>>  > >>>>>
>>>>>  > >>>>> All the userspace is segfaulting all over the place (most frequently in
>>>>>  > >>>>> libselinux for some reason).
>>>>>  > >>>>>
>>>>>  > >>>>> I am not able to verify the 'drop_caches' theory, as I can't invoke a
>>>>>  > >>>>> single command that wouldn't crash.
>>>>>  > >>>>
>>>>>  > >>>> The question is how should we proceed?
>>>>>  > >>>> I've reported this issue one year (!!!) ago.
>>>>>  > >>>
>>>>>  > >>> Hmm, 3.3-rcX seems to be the first version when it started to happen to
>>>>>  > >>> me. I take it that you have seen this also with 3.2? 3.1?
>>>>>  > >>
>>>>>  > >> Quote from my very first email:
>>>>>  > >> "I'm facing a very strange problem on my netbook (Lenovo Ideapad S10)
>>>>>  > >> running Linux 2.6.37.4."
>>>>>  > > 
>>>>>  > > So we both seem to have Lenovos at least. I thus wanted to verify whether 
>>>>>  > > the problem will trigger with thinkpad_acpi removed, but it oopsed while 
>>>>>  > > rmmoding :) I will start looking into this right away.
>>>>>  > > 
>>>>>  > > Is your system using thinkpad_acpi as well?
>>>>>  > 
>>>>>  > I dont't think, that it is lenovo related as I'm having a MSI machine.
>>>>>  > 
>>>>>  > https://bugzilla.novell.com/show_bug.cgi?id=732908
>>>>>  > 
>>>>>  > Following the link, you are able to compare the used chips - maybe there
>>>>>  > are some equal components?
>>>>>
>>>>> This looks like the i915 corruption problem mentioned in a few other threads.
>>>>>
>>>>> if you compare the hexdump of the good/bad files, you find that the corruption
>>>>> happens in 8x 4 byte writes of either 0x00000000 or 0x00aaaaaa.
>>>>>
>>>>> KeithP clued me in last week that that looks like an ARGB pixel quad, so these
>>>>> writes are likely 8 pixel strips.
>>>>
>>>> Thanks Dave. I disabled i915 (with nomodeset) and voila, the problem
>>>> disappears. As I already know, that the problem isn't X-related (I saw
>>>> it even without any X involved, only with runlevel 3 and nothing more),
>>>> the problem seems to be now narrowed down to the relevant component.
>>>
>>> I wonder what's the kernel command line you can reproduce the problem with?
>>
>> It's the standard kernel command line of openSUSE:
>> root=/dev/system/root resume=/dev/system/swap splash=silent quiet vga=791 3
> 
> Is it reproducible with vga=0 (or no vga= option at all)?

It's reproducible with both options (vga=0 and no vga option at all).


Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/