Comment # 9 on bug 1206767 from
(In reply to Takashi Iwai from comment #8)
> In general, we need to identify at which timing it crashes.  I suppose that
> the crash happens at re-loading the module after the resume (without the
> module).
> If so, you can omit the re-loading part ("post" in the script), and verify
> that the desktop is still up after the resume, then manually load the
> module.  This will have a better chance to catch the crash log.
> 
> OTOH, if the crash happens before the re-loading, it means that there was
> already some corruption (or other reason).

This morning I successfully exited sleep mode using a 15 second sleep. I'm
going to play around with the timing and maybe even manage to get a bit of log
information.
The next step for a workaround is to delay the loading on boot. What I find
strange about boot up is after I've entered runlevel 1 the rtl modules aren't
loaded at all but I can then go to runlevel 5 for the gui with no problem. If I
can somehow simulate that behavior without having to boot in stages I'm happy.

I looked at coreboot but unfortunately I'm stuck with the laptop's stock virus.


You are receiving this mail because: