Re: Initializing iwl3945 error

[Bjorn Helgaas]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/