linux-kernel - Re: iwl3945 didn't survive after s2ram failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120105110744.GA2222@redhat.com>
Date:	Thu, 5 Jan 2012 12:07:45 +0100
From:	Stanislaw Gruszka <sgruszka@...hat.com>
To:	Michal Hocko <mhocko@...e.cz>
Cc:	LKML <linux-kernel@...r.kernel.org>, linux-wireless@...r.kernel.org
Subject: Re: iwl3945 didn't survive after s2ram failure

On Tue, Jan 03, 2012 at 02:03:06PM +0100, Michal Hocko wrote:
> [ 5622.739466] ieee80211 phy0: U iwl_legacy_apm_init Init card's basic functions
> [ 5622.740021] iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
[snip]
> Yes and no change. I even tried to disable wireless in BIOS boot and
> then enable it again. No change...
> It seems somebody already had the same problem
> https://bugzilla.redhat.com/show_bug.cgi?id=639184. My BIOS doesn't
> provide any locator setting, unfortunatelly.
> 
> The message above says that the HW is still in a deep sleep state. Can
> we somehow force waking it up?

The message is a bit confusing, it happen when on device processor does
not clear bit it suppose to. It can be in some sleep state, reset state
or powered off. But this message could be triggered when there is PCIe
connection problem, since we can not read properly register value, what
seems to be issue here as value is 0xFFFFFFFF.

> Or, can we just ignore the signature check and (maybe) fix it by another
> suspend/resume cycle?

Only interesting thing we do while resume in the driver is:
pci_write_config_byte(pdev, PCI_CFG_RETRY_TIMEOUT, 0x00); 
we do the same during erly stage of .probe function too.

In the RH bugzilla case, it was regression. There are no iwlegacy
changes between mentioned kernel versions. There are some APCI and pci
changes. Can you try if any of these kernel boot parameters helps:
pcie_aspm=off
pcie_aspm=force
pci=nocsr
pci=use_csr

More than that, I'm attaching a patch, there is very small chance
it will help.

Stanislaw

View attachment "iwl3945.patch" of type "text/plain" (1107 bytes)