iwl3945 didn't survive after s2ram failure

iwl3945 didn't survive after s2ram failure

[Michal Hocko]

Hi,
my laptop died (due to drained batteries) while it was suspended to
RAM and the wireless didn't get back to life after I booted again.
Dmesg says:
cfg80211: Calling CRDA to update world regulatory domain
iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, in-tree:s
iwl3945: Copyright(c) 2003-2011 Intel Corporation
iwl3945 0000:05:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
iwl3945 0000:05:00.0: setting latency timer to 64
iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:05:00.0: bad EEPROM signature,EEPROM_GP=0x00000007
iwl3945 0000:05:00.0: EEPROM not found, EEPROM_GP=0xffffffff
iwl3945 0000:05:00.0: Unable to init EEPROM
iwl3945 0000:05:00.0: PCI INT A disabled
iwl3945: probe of 0000:05:00.0 failed with error -2

Is there anything I can do to resurrect it?

Thanks a lot
-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

Re: iwl3945 didn't survive after s2ram failure

[Stanislaw Gruszka]

On Tue, Dec 27, 2011 at 11:53:40AM +0100, Michal Hocko wrote:
> my laptop died (due to drained batteries) while it was suspended to
> RAM and the wireless didn't get back to life after I booted again.

I wonder how we could kill hardware that way ...

> Dmesg says:
> cfg80211: Calling CRDA to update world regulatory domain
> iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, in-tree:s
> iwl3945: Copyright(c) 2003-2011 Intel Corporation
> iwl3945 0000:05:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> iwl3945 0000:05:00.0: setting latency timer to 64
> iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> iwl3945 0000:05:00.0: bad EEPROM signature,EEPROM_GP=0x00000007
> iwl3945 0000:05:00.0: EEPROM not found, EEPROM_GP=0xffffffff
> iwl3945 0000:05:00.0: Unable to init EEPROM
> iwl3945 0000:05:00.0: PCI INT A disabled
> iwl3945: probe of 0000:05:00.0 failed with error -2
> 
> Is there anything I can do to resurrect it?

No idea. Please provide logs with debug=0x47ffffff option.

Did you try to totally power-off the laptop by removing
battery (and power cable of course) ?

If anything other will not help, is possible to rewrite eeprom, I don't
know how to do this, but I know that tool for that exist:
http://code.google.com/p/iwleeprom/

Stanislaw

Re: iwl3945 didn't survive after s2ram failure

[Stanislaw Gruszka]

On Tue, Jan 03, 2012 at 11:34:58AM +0100, Stanislaw Gruszka wrote:
> On Tue, Dec 27, 2011 at 11:53:40AM +0100, Michal Hocko wrote:
> > my laptop died (due to drained batteries) while it was suspended to
> > RAM and the wireless didn't get back to life after I booted again.
> 
> I wonder how we could kill hardware that way ...
> 
> > Dmesg says:
> > cfg80211: Calling CRDA to update world regulatory domain
> > iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, in-tree:s
> > iwl3945: Copyright(c) 2003-2011 Intel Corporation
> > iwl3945 0000:05:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> > iwl3945 0000:05:00.0: setting latency timer to 64
> > iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> > iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> > iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> > iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> > iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> > iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> > iwl3945 0000:05:00.0: bad EEPROM signature,EEPROM_GP=0x00000007
> > iwl3945 0000:05:00.0: EEPROM not found, EEPROM_GP=0xffffffff
> > iwl3945 0000:05:00.0: Unable to init EEPROM
> > iwl3945 0000:05:00.0: PCI INT A disabled
> > iwl3945: probe of 0000:05:00.0 failed with error -2
> > 
> > Is there anything I can do to resurrect it?
> 
> No idea. Please provide logs with debug=0x47ffffff option.
> 
> Did you try to totally power-off the laptop by removing
> battery (and power cable of course) ?
> 
> If anything other will not help, is possible to rewrite eeprom, I don't
> know how to do this, but I know that tool for that exist:
> http://code.google.com/p/iwleeprom/
Actually I do not think we overwrite eeprom, seems problem is at pci-e
bus level. Simply we can not communicate with device through pci-e bus.
That is kind a silly, but you can check if removing cart from slot
and put it back again (assuring it correctly connected) helps.
 
Stanislaw 

Re: iwl3945 didn't survive after s2ram failure

[Michal Hocko]

On Tue 03-01-12 13:23:12, Stanislaw Gruszka wrote:
> On Tue, Jan 03, 2012 at 11:34:58AM +0100, Stanislaw Gruszka wrote:
[...]
> > If anything other will not help, is possible to rewrite eeprom, I don't
> > know how to do this, but I know that tool for that exist:
> > http://code.google.com/p/iwleeprom/
> Actually I do not think we overwrite eeprom, seems problem is at pci-e
> bus level. Simply we can not communicate with device through pci-e bus.
> That is kind a silly, but you can check if removing cart from slot
> and put it back again (assuring it correctly connected) helps.

I am not sure whether the wireless is integrated (this is a laptop) and
I am little bit reluctant to open it as the warranty seems to be still
valid and I would break it if I get inside.

I have just realized that I haven't provided lspci output so just in
case it is helpful:
05:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
        Subsystem: Intel Corporation PRO/Wireless 3945ABG Network Connection
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at 80100000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [c8] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [e0] Express (v1) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 128 bytes
                DevSta: CorrErr+ UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <64us
                        ClockPM+ Surprise- LLActRep- BwNot-
                LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
                        ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
        Capabilities: [100 v1] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP+ BadDLLP+ Rollover- Timeout- NonFatalErr-
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                AERCap: First Error Pointer: 14, GenCap- CGenEn- ChkCap- ChkEn-
        Capabilities: [140 v1] Device Serial Number 00-1c-bf-ff-ff-50-22-54

Thanks
-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

Re: iwl3945 didn't survive after s2ram failure

[Stanislaw Gruszka]

On Tue, Jan 03, 2012 at 02:07:33PM +0100, Michal Hocko wrote:
> On Tue 03-01-12 13:23:12, Stanislaw Gruszka wrote:
> > On Tue, Jan 03, 2012 at 11:34:58AM +0100, Stanislaw Gruszka wrote:
> [...]
> > > If anything other will not help, is possible to rewrite eeprom, I don't
> > > know how to do this, but I know that tool for that exist:
> > > http://code.google.com/p/iwleeprom/
> > Actually I do not think we overwrite eeprom, seems problem is at pci-e
> > bus level. Simply we can not communicate with device through pci-e bus.
> > That is kind a silly, but you can check if removing cart from slot
> > and put it back again (assuring it correctly connected) helps.
> 
> I am not sure whether the wireless is integrated (this is a laptop) and
> I am little bit reluctant to open it as the warranty seems to be still
> valid and I would break it if I get inside.
Wow, laptop with so old wifi adapter has still a warranty. That good news,
you can ask vendor for fixing the problem :-)

> I have just realized that I haven't provided lspci output so just in
> case it is helpful:
I tried to reproduce on my laptop by suspend and removing power sources,
device initialize properly during boot.

I'm still wondering why we can break anything by power off during
suspend. Maybe there is some BIOS facility that power off PCIe device
or bridge during suspend, and now it in powered off state. Hard to tell,
except mentioned in other email pci* boot parameter try to change PCIe
related BIOS settings if there are any. 

Stanislaw

Re: iwl3945 didn't survive after s2ram failure

[Michal Hocko]

On Thu 05-01-12 12:26:49, Stanislaw Gruszka wrote:
> On Tue, Jan 03, 2012 at 02:07:33PM +0100, Michal Hocko wrote:
> > On Tue 03-01-12 13:23:12, Stanislaw Gruszka wrote:
> > > On Tue, Jan 03, 2012 at 11:34:58AM +0100, Stanislaw Gruszka wrote:
> > [...]
> > > > If anything other will not help, is possible to rewrite eeprom, I don't
> > > > know how to do this, but I know that tool for that exist:
> > > > http://code.google.com/p/iwleeprom/
> > > Actually I do not think we overwrite eeprom, seems problem is at pci-e
> > > bus level. Simply we can not communicate with device through pci-e bus.
> > > That is kind a silly, but you can check if removing cart from slot
> > > and put it back again (assuring it correctly connected) helps.
> > 
> > I am not sure whether the wireless is integrated (this is a laptop) and
> > I am little bit reluctant to open it as the warranty seems to be still
> > valid and I would break it if I get inside.
> Wow, laptop with so old wifi adapter has still a warranty. That good news,
> you can ask vendor for fixing the problem :-)

Well it came with some kind of premium warranty and that one ends at the
end of this month so I should better hurry ;)

> > I have just realized that I haven't provided lspci output so just in
> > case it is helpful:
> I tried to reproduce on my laptop by suspend and removing power sources,
> device initialize properly during boot.

I assume that you don't see the same issue...

> I'm still wondering why we can break anything by power off during
> suspend. Maybe there is some BIOS facility that power off PCIe device
> or bridge during suspend, and now it in powered off state. Hard to tell,
> except mentioned in other email pci* boot parameter try to change PCIe
> related BIOS settings if there are any. 

Unfortunately not much to set up...

> 
> Stanislaw

Thanks
-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

Re: iwl3945 didn't survive after s2ram failure

[Michal Hocko]

On Tue 03-01-12 11:34:58, Stanislaw Gruszka wrote:
> On Tue, Dec 27, 2011 at 11:53:40AM +0100, Michal Hocko wrote:
> > my laptop died (due to drained batteries) while it was suspended to
> > RAM and the wireless didn't get back to life after I booted again.
> 
> I wonder how we could kill hardware that way ...
> 
> > Dmesg says:
> > cfg80211: Calling CRDA to update world regulatory domain
> > iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, in-tree:s
> > iwl3945: Copyright(c) 2003-2011 Intel Corporation
> > iwl3945 0000:05:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> > iwl3945 0000:05:00.0: setting latency timer to 64
> > iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> > iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> > iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> > iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> > iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> > iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
> > iwl3945 0000:05:00.0: bad EEPROM signature,EEPROM_GP=0x00000007
> > iwl3945 0000:05:00.0: EEPROM not found, EEPROM_GP=0xffffffff
> > iwl3945 0000:05:00.0: Unable to init EEPROM
> > iwl3945 0000:05:00.0: PCI INT A disabled
> > iwl3945: probe of 0000:05:00.0 failed with error -2
> > 
> > Is there anything I can do to resurrect it?
> 
> No idea. Please provide logs with debug=0x47ffffff option.

[ 5622.729333] cfg80211: Calling CRDA to update world regulatory domain
[ 5622.739262] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, in-tree:ds
[ 5622.739270] iwl3945: Copyright(c) 2003-2011 Intel Corporation
[ 5622.739324] ieee80211 phy0: U iwl3945_pci_probe Disabling hw_scan
[ 5622.739328] ieee80211 phy0: U iwl3945_pci_probe *** LOAD DRIVER ***
[ 5622.739396] iwl3945 0000:05:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 5622.739419] iwl3945 0000:05:00.0: setting latency timer to 64
[ 5622.739446] ieee80211 phy0: U iwl3945_pci_probe pci_resource_len = 0x00001000
[ 5622.739451] ieee80211 phy0: U iwl3945_pci_probe pci_resource_base = f801e000
[ 5622.739462] ieee80211 phy0: U iwl_legacy_eeprom_init NVM size = 1024
[ 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
[ 5622.760206] iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
[ 5622.777028] iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
[ 5622.793768] iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
[ 5622.810526] iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
[ 5622.827279] iwl3945 0000:05:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
[ 5622.840727] ieee80211 phy0: U iwl_legacy_eeprom_verify_signature EEPROM signature=0x00000007
[ 5622.840731] iwl3945 0000:05:00.0: bad EEPROM signature,EEPROM_GP=0x00000007
[ 5622.840735] iwl3945 0000:05:00.0: EEPROM not found, EEPROM_GP=0xffffffff
[ 5622.840740] ieee80211 phy0: U iwl_legacy_apm_stop Stop card, put in low power state
[ 5622.840746] ieee80211 phy0: U iwl_legacy_apm_stop_master stop master
[ 5622.840762] iwl3945 0000:05:00.0: Unable to init EEPROM
[ 5622.840836] iwl3945 0000:05:00.0: PCI INT A disabled
[ 5622.840851] iwl3945: probe of 0000:05:00.0 failed with error -2

> Did you try to totally power-off the laptop by removing
> battery (and power cable of course) ?

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?
Or, can we just ignore the signature check and (maybe) fix it by another
suspend/resume cycle?
-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

Re: iwl3945 didn't survive after s2ram failure

[Stanislaw Gruszka]

[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]

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

[-- Attachment #2: iwl3945.patch --]
[-- Type: text/plain, Size: 1106 bytes --]

diff --git a/drivers/net/wireless/iwlegacy/iwl3945-base.c b/drivers/net/wireless/iwlegacy/iwl3945-base.c
index b282d86..94934eb 100644
--- a/drivers/net/wireless/iwlegacy/iwl3945-base.c
+++ b/drivers/net/wireless/iwlegacy/iwl3945-base.c
@@ -3700,8 +3700,8 @@ static int iwl3945_pci_probe(struct pci_dev *pdev, const struct pci_device_id *e
 	/***************************
 	 * 2. Initializing PCI bus
 	 * *************************/
-	pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1 |
-				PCIE_LINK_STATE_CLKPM);
+	//pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1 |
+	//			PCIE_LINK_STATE_CLKPM);
 
 	if (pci_enable_device(pdev)) {
 		err = -ENODEV;
@@ -3751,7 +3751,7 @@ static int iwl3945_pci_probe(struct pci_dev *pdev, const struct pci_device_id *e
 	 * strange state ... like being left stranded by a primary kernel
 	 * and this is now the kdump kernel trying to start up
 	 */
-	iwl_write32(priv, CSR_RESET, CSR_RESET_REG_FLAG_NEVO_RESET);
+	//iwl_write32(priv, CSR_RESET, CSR_RESET_REG_FLAG_NEVO_RESET);
 
 	/***********************
 	 * 4. Read EEPROM

Re: iwl3945 didn't survive after s2ram failure

[Michal Hocko]

On Thu 05-01-12 12:07:45, Stanislaw Gruszka wrote:
[...]
> 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

OK, so I have tried to boot with pcie_aspm=off and the wireless
resurrect. The I found out that I booted into 3.2 rather than 3.2-rc6 so
I retested with the original kernel and guess what, yes it reported the
same problem as before (with or without parameter). 
So I have tried to retest with few kernels (3.2.0-rc5,
3.2.0-rc6-00005-ga36bfdd, 3.2.0-rc7-00083-g115e8e7 and 3.2.0) that I
still had on my machine and 3.2.0-rc6-00005-ga36bfdd seems to be the
only affected one.
There doesn't seem to be any obvious difference wrt. the driver in the
logs (attached).

Looking in the history it seems that 497f16f2 [pci: Fix hotplug of
Express Module with pci bridges] might be related. It fixes an issue
introduced by bbef98ab [PCI: defer enablement of SRIOV BARS] which is a
part of my 3.2.0-rc6-00005-ga36bfdd problematic version. But I do not
understand details of the patch so I cannot tell that for 100%.
Yinghai Lu, is it possible that I the problem I have seen is somehow
related? For reference the thread started at
https://lkml.org/lkml/2011/12/27/65

Thanks
-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

Re: iwl3945 didn't survive after s2ram failure

[Michal Hocko]

[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]

And of course I forgot to attach logs...

On Thu 05-01-12 15:19:13, Michal Hocko wrote:
> On Thu 05-01-12 12:07:45, Stanislaw Gruszka wrote:
> [...]
> > 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
> 
> OK, so I have tried to boot with pcie_aspm=off and the wireless
> resurrect. The I found out that I booted into 3.2 rather than 3.2-rc6 so
> I retested with the original kernel and guess what, yes it reported the
> same problem as before (with or without parameter). 
> So I have tried to retest with few kernels (3.2.0-rc5,
> 3.2.0-rc6-00005-ga36bfdd, 3.2.0-rc7-00083-g115e8e7 and 3.2.0) that I
> still had on my machine and 3.2.0-rc6-00005-ga36bfdd seems to be the
> only affected one.
> There doesn't seem to be any obvious difference wrt. the driver in the
> logs (attached).
> 
> Looking in the history it seems that 497f16f2 [pci: Fix hotplug of
> Express Module with pci bridges] might be related. It fixes an issue
> introduced by bbef98ab [PCI: defer enablement of SRIOV BARS] which is a
> part of my 3.2.0-rc6-00005-ga36bfdd problematic version. But I do not
> understand details of the patch so I cannot tell that for 100%.
> Yinghai Lu, is it possible that I the problem I have seen is somehow
> related? For reference the thread started at
> https://lkml.org/lkml/2011/12/27/65
> 
> Thanks
> -- 
> Michal Hocko
> SUSE Labs
> SUSE LINUX s.r.o.
> Lihovarska 1060/12
> 190 00 Praha 9    
> Czech Republic

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

[-- Attachment #2: iwlwifi-eeprom-dmesg.tar.bz2 --]
[-- Type: application/octet-stream, Size: 28152 bytes --]

Re: iwl3945 didn't survive after s2ram failure

[Stanislaw Gruszka]

On Thu, Jan 05, 2012 at 03:19:13PM +0100, Michal Hocko wrote:
> 
> OK, so I have tried to boot with pcie_aspm=off and the wireless
> resurrect. The I found out that I booted into 3.2 rather than 3.2-rc6 so
> I retested with the original kernel and guess what, yes it reported the
> same problem as before (with or without parameter). 
> So I have tried to retest with few kernels (3.2.0-rc5,
> 3.2.0-rc6-00005-ga36bfdd, 3.2.0-rc7-00083-g115e8e7 and 3.2.0) that I
> still had on my machine and 3.2.0-rc6-00005-ga36bfdd seems to be the
> only affected one.
> There doesn't seem to be any obvious difference wrt. the driver in the
> logs (attached).
> 
> Looking in the history it seems that 497f16f2 [pci: Fix hotplug of
> Express Module with pci bridges] might be related.

>From the changelog of that commit: "I noticed that the bridges get
assigned but do not get enabled", that looks like the problem we had
seen.

Anyway there is noting to do here, we have bug in 3.2-rc6 fixed in
3.2-rc7.

Thanks
Stanislaw

Re: iwl3945 didn't survive after s2ram failure

[Michal Hocko]

On Thu 05-01-12 16:00:41, Stanislaw Gruszka wrote:
> On Thu, Jan 05, 2012 at 03:19:13PM +0100, Michal Hocko wrote:
> > 
> > OK, so I have tried to boot with pcie_aspm=off and the wireless
> > resurrect. The I found out that I booted into 3.2 rather than 3.2-rc6 so
> > I retested with the original kernel and guess what, yes it reported the
> > same problem as before (with or without parameter). 
> > So I have tried to retest with few kernels (3.2.0-rc5,
> > 3.2.0-rc6-00005-ga36bfdd, 3.2.0-rc7-00083-g115e8e7 and 3.2.0) that I
> > still had on my machine and 3.2.0-rc6-00005-ga36bfdd seems to be the
> > only affected one.
> > There doesn't seem to be any obvious difference wrt. the driver in the
> > logs (attached).
> > 
> > Looking in the history it seems that 497f16f2 [pci: Fix hotplug of
> > Express Module with pci bridges] might be related.
> 
> From the changelog of that commit: "I noticed that the bridges get
> assigned but do not get enabled", that looks like the problem we had
> seen.

Yes, I am just wondering why I haven't seen the problem before. I was
using rc6 for quite some time and using suspend/resume cycle all the
time. It was just after suspend didn't survive when I saw the problem
for the first time...
-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

Re: iwl3945 didn't survive after s2ram failure

[Yinghai Lu]

On Thu, Jan 5, 2012 at 6:19 AM, Michal Hocko <mhocko@suse.cz> wrote:

>
> Looking in the history it seems that 497f16f2 [pci: Fix hotplug of
> Express Module with pci bridges] might be related. It fixes an issue
> introduced by bbef98ab [PCI: defer enablement of SRIOV BARS] which is a
> part of my 3.2.0-rc6-00005-ga36bfdd problematic version. But I do not
> understand details of the patch so I cannot tell that for 100%.
> Yinghai Lu, is it possible that I the problem I have seen is somehow
> related? For reference the thread started at
> https://lkml.org/lkml/2011/12/27/65

you have one bridge that BIOS does not assign resource to it.
so kernel will allocate resource to it.

[    0.331694] pci 0000:00:1c.2: BAR 8: assigned [mem 0x80100000-0x803fffff]
[    0.331825] pci 0000:00:1c.2: BAR 9: assigned [mem
0x80400000-0x805fffff 64bit pref]
[    0.332041] pci 0000:00:1c.2: BAR 7: assigned [io  0x4000-0x4fff]
[    0.334271] pci 0000:05:00.0: BAR 0: assigned [mem 0x80100000-0x80100fff]
[    0.334455] pci 0000:05:00.0: BAR 0: set to [mem
0x80100000-0x80100fff] (PCI address [0x80100000-0x80100fff])
[    0.334666] pci 0000:00:1c.2: PCI bridge to [bus 05-05]
[    0.334794] pci 0000:00:1c.2:   bridge window [io  0x4000-0x4fff]
[    0.334926] pci 0000:00:1c.2:   bridge window [mem 0x80100000-0x803fffff]
[    0.335058] pci 0000:00:1c.2:   bridge window [mem
0x80400000-0x805fffff 64bit pref]

yes, the commit fix the problem.

in the commit log i already said:

|    That should fix regression like BIOS does not assign correct resource to
|    bridge.


Thanks

Yinghai Lu

Re: iwl3945 didn't survive after s2ram failure

[Michal Hocko]

On Thu 05-01-12 11:44:17, Yinghai Lu wrote:
> On Thu, Jan 5, 2012 at 6:19 AM, Michal Hocko <mhocko@suse.cz> wrote:
> 
> >
> > Looking in the history it seems that 497f16f2 [pci: Fix hotplug of
> > Express Module with pci bridges] might be related. It fixes an issue
> > introduced by bbef98ab [PCI: defer enablement of SRIOV BARS] which is a
> > part of my 3.2.0-rc6-00005-ga36bfdd problematic version. But I do not
> > understand details of the patch so I cannot tell that for 100%.
> > Yinghai Lu, is it possible that I the problem I have seen is somehow
> > related? For reference the thread started at
> > https://lkml.org/lkml/2011/12/27/65
> 
> you have one bridge that BIOS does not assign resource to it.
> so kernel will allocate resource to it.
> 
> [    0.331694] pci 0000:00:1c.2: BAR 8: assigned [mem 0x80100000-0x803fffff]
> [    0.331825] pci 0000:00:1c.2: BAR 9: assigned [mem
> 0x80400000-0x805fffff 64bit pref]
> [    0.332041] pci 0000:00:1c.2: BAR 7: assigned [io  0x4000-0x4fff]
> [    0.334271] pci 0000:05:00.0: BAR 0: assigned [mem 0x80100000-0x80100fff]
> [    0.334455] pci 0000:05:00.0: BAR 0: set to [mem
> 0x80100000-0x80100fff] (PCI address [0x80100000-0x80100fff])
> [    0.334666] pci 0000:00:1c.2: PCI bridge to [bus 05-05]
> [    0.334794] pci 0000:00:1c.2:   bridge window [io  0x4000-0x4fff]
> [    0.334926] pci 0000:00:1c.2:   bridge window [mem 0x80100000-0x803fffff]
> [    0.335058] pci 0000:00:1c.2:   bridge window [mem
> 0x80400000-0x805fffff 64bit pref]
> 
> yes, the commit fix the problem.

Thanks for the confirmation!

> 
> in the commit log i already said:
> 
> |    That should fix regression like BIOS does not assign correct resource to
> |    bridge.
> 
> 
> Thanks
> 
> Yinghai Lu
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic