On Tue, Mar 13, 2012 at 2:12 AM, Stanislaw Gruszka [off-list ref] wrote:

On Sun, Mar 11, 2012 at 05:43:26PM +0000, Kamil Grzebien wrote:

quoted

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.

quoted

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 ?

quoted

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.

quoted

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