linux-kernel - Initializing iwl3945 error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANHD2=rF6dBkLLkWAj8uS3nq0B1wCt7Uvu=HzO84UNz2kuiaFg@mail.gmail.com>
Date:	Sun, 11 Mar 2012 17:43:26 +0000
From:	Kamil Grzebien <ciptok@...il.com>
To:	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-wireless@...r.kernel.org
Cc:	sgruszka@...hat.com
Subject: Initializing iwl3945 error

Hello,

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

Currently I'm working on Fedora 16 with 3.1.5-6.fc16.i686 kernel. I
did some investigation/debugging on iwlegacy driver and found out few
things.

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.

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 there a way to check the status or rescan the device from driver itself?

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.

Regards,
Kamil Grzebien
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/