Re: Initializing iwl3945 error

[Kamil Grzebien]

Hi Bjorn,

I've attached logs as you asked for. It was done on kernel 3.3.0-4.fc16.i686.

Regards,
Kamil

On Thu, Mar 15, 2012 at 9:08 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote:
> On Tue, Mar 13, 2012 at 2:12 AM, Stanislaw Gruszka <sgruszka@xxxxxxxxxx> wrote:
>> On Sun, Mar 11, 2012 at 05:43:26PM +0000, Kamil Grzebien wrote:
>>> I've initialisation problem with my iwl3945 network card in Dell XPS
>>> M1530 laptop. The issue is known and described in couple of bug
>>> reports (eg. http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2143).
>>> There are workarounds but I'd like to solve the problem permanently.
>>> Basically when initializing I get:
>>>
>>> iwl3945 0000:0b:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ
>>> iwl3945 0000:0b:00.0: setting latency timer to 64
>>> iwl3945 0000:0b:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
>>> iwl3945 0000:0b:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
>>> ....
>>> iwl3945 0000:0b:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL = 0xFFFFFFFF
>>> iwl3945 0000:0b:00.0: bad EEPROM signature,EEPROM_GP=0x00000007
>>> iwl3945 0000:0b:00.0: EEPROM not found, EEPROM_GP=0xffffffff
>> It's worth to mansion that this problem happen after wakeup from suspend
>> to ram.
>>
>>> 1. Driver can't initialize card as all ioread32/iowrite32 seems to not
>>> do their job. All reads finalize with 0xffffffff.
>>>
>>> However I can see that:
>>> - pci_iomap(pdev, 0, 0) doesn't return error,
>>> - pci_resource_start(pdev, 0) seems gives correct address (I can
>>> compare it with the one I can see in /proc/iomem).
>>>
>>> If I access the memory directly, not by mapping, I can write and read
>>> pci memory but driver load fails anyway. I don't understand why can't
>>> access using mapped memory.
>> How do you access memory directly ?
>>
>>> 2. If I check BASE_ADDRESS with setpci it doesn't give correct values:
>>>
>>> # setpci -v -s 0b:00.0 BASE_ADDRESS_0 BASE_ADDRESS_1
>>> 0000:0b:00.0 @10 = 00000000
>>> 0000:0b:00.0 @14 = 00000000
>>>
>>> Not sure if it's done by driver itself or it should point correct
>>> values even if the driver wasn't fully loaded.
>>>
>>> Have you got any idea of:
>>> - why IO memory isn't accessible? what could cause that?
>>> - how APIC could change the load process in this particular case? (if
>>> I boot with noapic kernel option it usually works fine)
>> Is this really noapic or maybe noacpi ? ACPI manage PCIe devices.
>>
>>> This issue is reproducible in 100% on my system when I turn on the
>>> machine. It doesn't occur after some work on it. I'd be very happy to
>>> get rid of the issue.
>>>
>>> Could you point some ideas that might be worth checking in driver or
>>> kernel please? I've tried couple of ideas but none worked for me.
>>
>> Would be good to check if pcie bridge is configured correctly after
>> suspend to ram. But I don't know how to do this, that's why we are
>> on linux-pci mailing list :-)
>>
>> Note we have similar bug report, which was actual regression and
>> that problem is already fixed by PCI patch:
>> http://marc.info/?l=linux-kernel&m=132577331232330&w=2
>
> The bug report (http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2143)
> has a lot of logs, but they're pretty old and I can't tell how
> applicable they are to your situation.
>
> It would be useful to see a complete dmesg log, /proc/iomem, and
> "lspci -vv" output from your machine after the problem occurs, and
> also the same information when it works (when using the noapic flag).
>
> Bjorn

Attachment: iwl3945logs.tar.gz
Description: GNU Zip compressed data

Attachment: iwl3945logs_noapic.tar.gz
Description: GNU Zip compressed data