1On Tue, Jun 25, 2013 at 3:25 PM, Stanislaw Gruszka [off-list ref] wrote:

On Fri, Jun 14, 2013 at 03:18:29PM +0200, Stanislaw Gruszka wrote:

quoted

quoted

quoted

quoted

I also got a SYSASSERT:
(...)

I disabled powersave (but kept running the same kernel) and none of
the errors appeared again.

Yes, this seems to be iwlegacy PS issue and has to be fixed before
this patch could be applied.

But is it a driver-only issue? I had assumed it was some sort of
fireware+driver issue...

Looks like driver issue or firmware issue that can be workaround in
the driver.

quoted

Will running with debug on help? Or is it easily reproducible on any
iwl3945 / iwl4465 ?

Because in my case (iwl3945) it happens after boot, no prior suspend
to RAM is required to trigger the issues.

I can reproduce microcode error on iwl4965 by reloading modules. Looks
like we put device in sleep mode and it can not be properly booted when
driver initalize. I did not yet test patch on iwl3945. When I'll do
this, I think I'll be able to reproduce problems you discovered. If not
I'll ask for more debug info.

I found problem on 4965, we have to send power configuration command to
device earlier, before some other commands. Attached patch solved
microcode errors I have on 4965.

Regarding iwl3945. Display on my 3945 laptop no longer works. I took
3945 device from that laptop and installed it on two different machines.
Unfortunately on none of them device was detected by pci system :-/
I have figure out how to get working 3945 testing environment, but for
now, perhaps you could provide me some more debug information.

Pedro, please do the fallowing:

Add this line in /etc/rsyslog.conf:
kern.*                                                  /var/log/kernel

Restart rsyslog services:
# systemctl restart rsyslog.service

Restart iwl3945 module with verbose debug enabled:
modprobe -r iwl3945
modprobe iwl3945 debug=0x47ffffff

Reproduce the problem.

Unload module:
modprobe -r iwl3945

Then provide me generated /var/log/kernel file (compressed if needed).

I seem only to be able to trigger it with disable_hw_scan=0, I need
further testing with disable_hw_scan=1 (I use disable_hw_scan=0
because it prevents me from getting disconnected from eduroam Cisco
APs -- haven't tested disable_hw_scan=0 since the VOIP-friendly SW
scanning patch, however).

Do you want the log anyway? (modprobe iwl3945 debug=0x47ffffff
disable_hw_scan=0 and runtime PCI powersave also enabled -- I don't
know if it matters).
--
Pedro