Bug 12897

Please attach the backtrace (or at least the first few bits of the trace). Also see if it occurs if you kill off pbuttonsd before suspend/resume

Created attachment 20604 [details]
Whole dmesg of the machine, freshly booted and with the stack trace

This is the whole dmesg from my freshly compiled 2.6.29-rc8 kernel, right after a boot and going to Xorg, pressing the suspend button and any other key to make the iBook wake up.

Created attachment 20605 [details]
Output of lspci -vvvxxx

Created attachment 20606 [details]
Output of lsusb -v

Created attachment 20607 [details]
Register dump of the rt2x00 driver after the call trace appears

Created attachment 20608 [details]
My kernel config file

(In reply to comment #1)
> Please attach the backtrace (or at least the first few bits of the trace).
> Also
> see if it occurs if you kill off pbuttonsd before suspend/resume
> 

Thanks, Alan. I have send some attachments to the bug. If you want me to send more information, please just let me know.


Thanks again, Rogério Brito.

If my System.map file is needed, just let me know, please.


Thanks, Rogério Brito.

P.S.: I'm now going to see how things work with pbbuttonsd killed.

Hi, Alan.

I have just narrowed it down to the rt2x000 driver.

When I rebooted the system (so that it was in a clean state), I killed pbbuttonsd and, without X being started, I did "echo mem > /sys/power/state" without the USB device being up. The machine went to sleep and woke up without any problems.

Then, I rebooted (just in case), killed pbbuttonsd and, without X being started, I upped the USB wifi card and I had connection to the network. But then, a simple "echo mem > /sys/power/state" did the same thing as I reported earlier.

The only difference was that, instead of the stack trace being generated with the pbbuttonsd process, it was generated with bash (my shell).

Also, I got an Oops when I tried to reboot (and the system hang and I had to cold reboot the iBook). If any further information is necessary, please let me know (and Ivo, if I can provide you with any further information, also let me know).

Just as a reminder, this box is a powerpc (and, thus, a big-endian) machine.


Thank you very much for any help, Rogério Brito.

Details adjusted and its a nice clear trace but probably needs the right driver maintainer to cure it.

Could you try wireless-testing.git (http://wireless.kernel.org/en/developers/Documentation#wireless-testing.git)
or the wireless-compat package (http://wireless.kernel.org/en/users/Download)
to see if the poblem has been solved in those versions?

Hi, Alan and other people.

On Mar 20, 2009, at 10:46 AM, alan@lxorguk.ukuu.org.uk wrote:
> Details adjusted and its a nice clear trace

Thank you so very much for your usual kindness with me (you're lovely  
as always).

> but probably needs the right driver maintainer to cure it.

I will see what I can do with Ivo regarding the driver, then.


Thanks again, Rog

Hi, Ivo.

On Mar 21, 2009, at 9:23 AM, IvDoorn@gmail.com wrote:
> Could you try wireless-testing.git
> (http://wireless.kernel.org/en/developers/Documentation#wireless- 
> testing.git)
> or the wireless-compat package (http://wireless.kernel.org/en/users/ 
> Download)
> to see if the poblem has been solved in those versions?

Sure I can. I will grab the git tree ASAP. The only problem is that  
(even though I'm using ccache), my iBook takes a loong time to  
compile things (and I'm not near any machine where I can cross- 
compile things).

I will report back today. Please be tuned. :-)


Regards, Rog

tip: using the compat-wireless package would save compile time since you won't need to build the entire kernel. ;)

Hi, Ivo.

I just got back to the business of compiling a new kernel for this powerpc laptop. It seems that the wireless-testing.git tree from 2009-03-26 works without giving me give me stack traces.

I will have to see why, after resume, I loose connection to the AP. Bringing the interface down and up doesn't seem to solve it. Removing the modules and loading them again seem to work (from my limited testing).

I still have to test other things related to this driver, but, at least, the suspend/resume thing appears to be working fine.

If any further information is needed, please let me know.


Thank you very much, Rogério Brito.

That problem has been solved, I'll attach the patch I have send upstream yesterday to fix this issue.

Created attachment 20720 [details]
Fix failed association after resume

commit 499a214ca2765522d6a59ff73825d40e7bb31510
Author: Ivo van Doorn <ivdoorn@gmail.com>
Date:   Sat Mar 28 20:51:58 2009 +0100

    rt2x00: Don't free register information on suspend
    
    After suspend & resume the rt2x00 devices won't wakeup
    anymore due to a broken register information setup.
    The most important problem is the release of the EEPROM
    buffer which is completely cleared and never read again
    after the suspend.
    
    Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

Hi there.

I'm not exactly sure if the driver is fixed. I just did a git pull from the wireless-next and I'm compiling it at this moment.

I will report back in some hours (compiling the kernel here does take some considerable amount of time).


Thanks, Rogério Brito.

Hi, Ivo, John.

I will perform some further tests with a recent git tree (I just got some spare time) and I will report back on what I see. I think that I'm seeing some strange things here.


Thanks, Rogério Brito.