Re: Initializing iwl3945 error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Stanislaw

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux