iprowifi3945 may not power ON wifi adapter

[cocobean]

The iprowifi3945 driver may not 'power on' the Intel 3945 wifi adapter used by some older laptops (<=Y2010).

NOTE (same hardware tested, no hardware changes):

1. wpi driver and Intel 3945 firmware used in FreeBSD 11.1/11.2 - works.
2. Same Intel 3945 firmware is used in test Linux distro - works.

Hardware: HP Pavilion DV8000 laptop Part #: RG475UA#ABA

Errors:

KERN: [iprowifi3945] (wpi) wpi_read_eeprom: could not power ON adapter, error -2147483639
KERN: [iprowifi3945] (wpi) could not read EEPROM, error -2147483KERN: 639

[waddlesplash]

Please retest after hrev52114.

[cocobean]

No change. hrev52115 x86_gcc2.

KERN: [iprowifi3945] (wpi) bus_alloc_resource(3, [16], 0x0, 0xffffffff, 0x1,0x2)
KERN: [iprowifi3945] (wpi) bus_alloc_resource(1, [1], 0x0, 0xffffffff, 0x1,0x2)
KERN: [iprowifi3945] (wpi) could not lock memory
KERN: [iprowifi3945] (wpi) wpi_read_eeprom: could not power ON adapter, error -2147483639
KERN: [iprowifi3945] (wpi) could not read EEPROM, error -2147483639

[mmu_man]

Please test with hrev52204. If it used PCI config registers to do this, they it might work now as it will address the correct device.

[cocobean]

Tested hrev52711 x86. Crashes with iprowifi3945 wifi driver. Had to use safe mode as workaround until blacklisted. See P_20190104_135726[1].jpg attachment

NOTE: 
PANIC: vm_page_fault: unhandled page fault in kernel space at 0x8175affc, ip 0x8124fc52
...
pci_reserve_device(6,0,0,iprowifi3945)

[cocobean]

iprowifi3924 driver KDL info with hrev52711 x86

[waddlesplash]

The message is cut off, and without that I can't do much.

[cocobean]

Updated info on initial PANIC message. The 'Haiku legacy driver (probe) code' messages are new as I don't think I saw this in the older revision issue.

[waddlesplash]

Yes, they are new, the compat layer now reserves devices. That is unrelated.

Please post a picture that is not cut off at the top. I can't do much without the actual panic message.

[cocobean]

iprowifi3945 driver KDL info on hrev52711 x86

[cocobean]

Syslog info from hrev52711 x86

[waddlesplash]

Panic fixed in hrev52721.

[cocobean]

Tested on hrev52738 x86. Confirmed kernel panic issues resolved:

KERN: pci_reserve_device(6,0,0,iprowifi3945)
KERN: [iprowifi3945] (wpi) bus_alloc_resource(3, [16], 0x0, 0xffffffff, 0x1,0x2)
KERN: [iprowifi3945] (wpi) bus_alloc_resource(1, [1], 0x0, 0xffffffff, 0x1,0x2)
KERN: [iprowifi3945] (wpi) could not lock memory
KERN: [iprowifi3945] (wpi) wpi_read_eeprom: could not power ON adapter, error -2147483639
KERN: [iprowifi3945] (wpi) could not read EEPROM, error -2147483639
KERN: pci_unreserve_device(6,0,0,iprowifi3945)

[waddlesplash]

Please upload a new full syslog under this revision.

[cocobean]

Syslog info from hrev52738 x86

[cocobean]

New syslog added to ticket.

[waddlesplash]

Please retest after hrev53174.

[cocobean]

Tested hrev53174 x86_gcc2 nightly image.
WIFI Hardware detected: 8086, 4222 - Intel PRO/Wireless 3945ABG Golan Network Connection
NOTE: No change. Previous syslog info exactly the same. No KDL (benefit, I don't have to blacklist the wpi driver anymore.)

[waddlesplash]

There is still a "could not lock memory"?

[cocobean]

Yes. All related syslog messages are the same.

[luroh]

32-bit Haiku is currently broken, network wise (see ticket:15096). It would be interesting if you could give x86_64 a try. I think there's a good chance it will work, based on the seemingly similar failures to initialize our devices under gcc2h:

KERN: pci_reserve_device(6, 0, 0, iprowifi3945)
KERN: [iprowifi3945] (wpi) bus_alloc_resource(3, [16], 0x0, 0xffffffff, 0x1,0x2)
KERN: [iprowifi3945] (wpi) bus_alloc_resource(1, [1], 0x0, 0xffffffff, 0x1,0x2)
KERN: [iprowifi3945] (wpi) could not lock memory
KERN: [iprowifi3945] (wpi) wpi_read_eeprom: could not power ON adapter, error -2147483639
KERN: [iprowifi3945] (wpi) could not read EEPROM, error -2147483639
KERN: pci_unreserve_device(6, 0, 0, iprowifi3945)

KERN: pci_reserve_device(3, 0, 0, idualwifi7260)
KERN: [idualwifi7260] (iwm) bus_alloc_resource(3, [16], 0x0, 0xffffffff, 0x1,0x2)
KERN: [idualwifi7260] (iwm) bus_alloc_resource(1, [1], 0x0, 0xffffffff, 0x1,0x2)
KERN: [idualwifi7260] (iwm) fw chunk addr 0x404000 len 712 failed to load
KERN: [idualwifi7260] (iwm) iwm_pcie_load_section: Could not load the [0] uCode section
KERN: [idualwifi7260] (iwm) iwm_start_fw: failed -2147483639
KERN: [idualwifi7260] (iwm) Failed to start INIT ucode: -2147483639
KERN: pci_unreserve_device(3, 0, 0, idualwifi7260)

[waddlesplash]

Only some machines are broken for 32-bit Haiku and network drivers. Quite a lot still work just fine, so your ticket really is the exception here.

[cocobean]

Updated for hrev53404 x86_gcc2:

Ok, I may go back and try hrev50465 (was mentioned to work previously). I noticed the Haiku wpi code had some small changes (29) versus the FreeBSD wpi code so I'd took more time to breeze through the wpi code. Noted some TX/RX handling and AES disable changes. FreeBSD updated the wpi code to Fix ieee80211_radiotap(9) usage in the wireless drivers.

One thing that I'm pondering:

* The 3945ABG network adapter doesn't use traditional hardware as
 * many other adaptors do. Instead at run time the eeprom is set into a known
 * state and told to load boot firmware. The boot firmware loads an init and a
 * main  binary firmware image into SRAM on the card via DMA.
 * Once the firmware is loaded, the driver/hw then
 * communicate by way of circular dma rings via the SRAM to the firmware.
 *
 * There is 6 memory rings. 1 command ring, 1 rx data ring & 4 tx data rings.
 * The 4 tx data rings allow for prioritization QoS.
 *
 * The rx data ring consists of 32 dma buffers. Two registers are used to
 * indicate where in the ring the driver and the firmware are up to. The
 * driver sets the initial read index (reg1) and the initial write index (reg2),
 * the firmware updates the read index (reg1) on rx of a packet and fires an
 * interrupt. The driver then processes the buffers starting at reg1 indicating
 * to the firmware which buffers have been accessed by updating reg2. At the
 * same time allocating new memory for the processed buffer.
 *
 * A similar thing happens with the tx rings. The difference is the firmware
 * stop processing buffers once the queue is full and until confirmation
 * of a successful transmition (tx_done) has occurred.
 *
 * The command ring operates in the same manner as the tx queues.
 *
 * All communication direct to the card (ie eeprom) is classed as Stage1
 * communication
 *
 * All communication via the firmware to the card is classed as State2.
 * The firmware consists of 2 parts. A bootstrap firmware and a runtime
 * firmware. The bootstrap firmware and runtime firmware are loaded
 * from host memory via dma to the card then told to execute. From this point
 * on the majority of communications between the driver and the card goes
 * via the firmware.

ic->ic_cryptocaps =
		  IEEE80211_CRYPTO_AES_CCM;

	/*
	 * Read in the eeprom and also setup the channels for
	 * net80211. We don't set the rates as net80211 does this for us
	 */
	if ((error = wpi_read_eeprom(sc, ic->ic_macaddr)) != 0) {
		device_printf(dev, "could not read EEPROM, error %d\n",
		    error);
		goto fail;
	}

I don't see any significant changes in the current FreeBSD wpi code and FreeBSD 11.x/12.0 works on this laptop.

[Kitsune64]

What is the more recently version of Haiku Beos x86 suppose to work with IntelPro 3945agb driver? I have the same kind of trouble with the new updates hr54326 (named Walter) x86_gcc2. I can't see my card at all.

[cocobean]

Please close this ticket. I can use existing alternative Ethernet-to-WiFi solutions.

[waddlesplash]

Please retest after hrev54790.

[cocobean]

hrev54790 x86 results - Still no memory lock.

KERN: pci_reserve_device(6, 0, 0, iprowifi3945)
KERN: [iprowifi3945] (wpi) bus_alloc_resource(3, [16], 0x0, 0xffffffff, 0x1,0x2)
KERN: [iprowifi3945] (wpi) bus_alloc_resource(1, [1], 0x0, 0xffffffff, 0x1,0x2)
KERN: [iprowifi3945] (wpi) could not lock memory
KERN: [iprowifi3945] (wpi) wpi_read_eeprom: could not power ON adapter, error -2147483639
KERN: [iprowifi3945] (wpi) could not read EEPROM, error -2147483639
KERN: pci_unreserve_device(6, 0, 0, iprowifi3945)

[cocobean]

HP Pavilion dv8000 laptop (with Wifi button enabled and blue light indicator (shown above keyboard)).

[waddlesplash]

Please retest after hrev55890; it may help with this.

[cocobean]

Haiku hrev55891 x86: FAILED

KERN: [iprowifi3945] (wpi) wpi_read_eeprom: could not power ON adapter, error -2147483639
KERN: [iprowifi3945] (wpi) could not read EEPROM, error -2147483639

[cocobean]

Haiku hrev56496 x86: FAILED

• Wifi EEPROM R/W and loading - same issue.
• Wifi firmware version: v15.32.2.9 (iwlwifi-3945-2.ucode)

[cocobean]

Please close this ticket.

• Retested wifi power on activation Haiku hrev56511 x86: FAILED
• Retested wifi power on activation with FreeBSD: PASSED
• Retested wifi power on activation with Linux: PASSED