rtl8192se solution: Kernel panic on attempt to suspend or hibernate

racecar56 · 2011-11-12 11:03:40

I had this issue with suspend and hibernate with the rtl8192se module and my Asus Eee PC 1201T upon upgrading to Linux 3.1, and you can "fix" it with this command:

sudo sh -c 'echo SUSPEND_MODULES="rtl8192se" >/etc/pm/config.d/rtl8192se-workaround'

I hope this helps someone.

Last edited by racecar56 (2011-11-14 05:55:32)

eldragon · 2011-11-12 13:15:10

if it did work on kernel 3.0 and it does not work on kernel 3.1 it is a good idea to git bisect to find out which commit broke your driver.

i would start by building 3.1-rc1 and see if the problem is there. if it is. then git bisect between 3.0 and 3.1-rc1, if it doesnt. move to 3.1-rc2 and same applies.

man git-bisect for more info.

AFTER finding what commit breaks your suspend. report back (since bugzilla is down!).

eugenjung · 2011-11-13 11:59:29

I had the same issue on my Toshiba L450D, and the above fix workaround worked for me. Thanks, racecar56!

Last edited by eugenjung (2011-11-24 14:11:29)

Gusar · 2011-11-13 12:22:15

This is not a fix. The driver should suspend and resume. This is merely a workaround, because the driver fails at doing so. Some might say I'm nitpicking, but I think it's important to make the distinction. A fully working driver does not require this.

racecar56 · 2011-11-14 05:55:13

Gusar wrote:

This is not a fix. The driver should suspend and resume. This is merely a workaround, because the driver fails at doing so. Some might say I'm nitpicking, but I think it's important to make the distinction. A fully working driver does not require this.

That is true. This is not a fix, it's just a workaround.

eugenjung · 2011-11-24 14:39:10

Gusar wrote:

This is not a fix. The driver should suspend and resume. This is merely a workaround, because the driver fails at doing so. Some might say I'm nitpicking, but I think it's important to make the distinction. A fully working driver does not require this.

I agree that this is a workaround, but I think a workaround is also a fix, because it fixes a problem (but not necessarily the cause of the problem). The problem with the driver is not fixed. The problem with my computer is fixed (but the cause of the problem is not fixed).

I may be wrong, of course; that's just my interpretation (using the Merriam-Webster definition of fix (noun) as "something that fixes or restores (solution)", in my case fixing the problem that I was trying to fix, and restoring my computer's behavior to the way it was before the update; and the definition of solution (noun) as "an action or process of solving a problem" -- but not necessarily the cause of the problem -- where the problem was being unable to suspend my PC).

But, whatever, it's doesn't really matter; my computer suspends properly again, and that's all that matters to me.

eldragon · 2011-11-24 14:58:26

eugenjung wrote:

But, whatever, it's doesn't really matter; my computer suspends properly again, and that's all that matters to me.

it should matter, you have all the tools to actually find the problem and have it automatically fixed for everyone else in the future (who might not know when this problem was introduced and hence, not being able to bisect).

bisecting is, imo, the right thing to do.

you will most likely

- find the REAL problem, report it and have it fixed.
- learn quite a bit
- help others in doing so.

your reply here is a bit selfish if you ask me. in the future, if you dont want to do the right thing, dont bother asking for help.

Gusar · 2011-11-24 15:23:54

eugenjung wrote:

in my case fixing the problem that I was trying to fix, and restoring my computer's behavior to the way it was before the update

Actually no, your computer does not behave the way it used to. Unloading the module before suspend (which is what the workaround does) destroys the network card state. But a driver that properly suspends, will then resume the card in the same state it was before. You may not notice the effect of this depending on your configuration, but the effect is there.

eugenjung · 2011-11-26 19:07:36

eldragon wrote:

eugenjung wrote:
But, whatever, it's doesn't really matter; my computer suspends properly again, and that's all that matters to me.

it should matter, you have all the tools to actually find the problem and have it automatically fixed for everyone else in the future (who might not know when this problem was introduced and hence, not being able to bisect).
bisecting is, imo, the right thing to do.
you will most likely
- find the REAL problem, report it and have it fixed.
- learn quite a bit
- help others in doing so.

your reply here is a bit selfish if you ask me. in the future, if you dont want to do the right thing, dont bother asking for help.

Woah, what's with the aggressive attitude here? I didn't ask for any help, I merely confirmed that the workaround posted by the OP worked for me too, and thanked him/her for posting it in the first place.

Unfortunately, I don't have time to "do the right thing". I have to urgently fly abroad to take care of an elderly relative. I'm currently stuck in Dublin waiting for my emergency travel certificate, and have to fly out in 4 days time.

Gusar wrote:

eugenjung wrote:
in my case fixing the problem that I was trying to fix, and restoring my computer's behavior to the way it was before the update
Actually no, your computer does not behave the way it used to. Unloading the module before suspend (which is what the workaround does) destroys the network card state. But a driver that properly suspends, will then resume the card in the same state it was before. You may not notice the effect of this depending on your configuration, but the effect is there.

Perhaps it doesn't behave exactly the way it used to, but at least it actually works.

Last edited by eugenjung (2011-11-26 21:46:23)

eldragon · 2011-11-27 12:32:46

eugenjung wrote:

Woah, what's with the aggressive attitude here? I didn't ask for any help, I merely confirmed that the workaround posted by the OP worked for me too, and thanked him/her for posting it in the first place.
Unfortunately, I don't have time to "do the right thing". I have to urgently fly abroad to take care of an elderly relative. I'm currently stuck in Dublin waiting for my emergency travel certificate, and have to fly out in 4 days time.

sorry, i did not mean for the reply to be harsh, and even if it was a bit directed to the topic, it should be taken in a general way. it does not really help if bugs arent solved upstream.

and of course. posting a "this helped me too" on a "solution" involving removing the module does not add to the solution if you dont have time to follow the problem.

me replying to this thread doesnt either. i just want to state for the record. i did not mean to hurt anyone's feelings. and if i did, im sorry.

trapanator · 2011-12-12 08:23:04

racecar56 wrote:

I had this issue with suspend and hibernate with the rtl8192se module and my Asus Eee PC 1201T upon upgrading to Linux 3.1, and you can "fix" it with this command:
sudo sh -c 'echo SUSPEND_MODULES="rtl8192se" >/etc/pm/config.d/rtl8192se-workaround'
I hope this helps someone.

I have an asus 1201T! I'll try it tonight

trapanator · 2011-12-18 19:06:46

trapanator wrote:

racecar56 wrote:
I had this issue with suspend and hibernate with the rtl8192se module and my Asus Eee PC 1201T upon upgrading to Linux 3.1, and you can "fix" it with this command:
sudo sh -c 'echo SUSPEND_MODULES="rtl8192se" >/etc/pm/config.d/rtl8192se-workaround'
I hope this helps someone.
I have an asus 1201T! I'll try it tonight

I tested it now. It worked to me, too.

Arch Linux

#1 2011-11-12 11:03:40

rtl8192se solution: Kernel panic on attempt to suspend or hibernate

#2 2011-11-12 13:15:10

Re: rtl8192se solution: Kernel panic on attempt to suspend or hibernate

#3 2011-11-13 11:59:29

Re: rtl8192se solution: Kernel panic on attempt to suspend or hibernate

#4 2011-11-13 12:22:15

Re: rtl8192se solution: Kernel panic on attempt to suspend or hibernate

#5 2011-11-14 05:55:13

Re: rtl8192se solution: Kernel panic on attempt to suspend or hibernate

#6 2011-11-24 14:39:10

Re: rtl8192se solution: Kernel panic on attempt to suspend or hibernate

#7 2011-11-24 14:58:26

Re: rtl8192se solution: Kernel panic on attempt to suspend or hibernate

#8 2011-11-24 15:23:54

Re: rtl8192se solution: Kernel panic on attempt to suspend or hibernate

#9 2011-11-26 19:07:36

Re: rtl8192se solution: Kernel panic on attempt to suspend or hibernate

#10 2011-11-27 12:32:46

Re: rtl8192se solution: Kernel panic on attempt to suspend or hibernate

#11 2011-12-12 08:23:04

Re: rtl8192se solution: Kernel panic on attempt to suspend or hibernate

#12 2011-12-18 19:06:46

Re: rtl8192se solution: Kernel panic on attempt to suspend or hibernate

Board footer