Opened 16 months ago

Last modified 3 months ago

#14265 new bug

iprowifi3945 may not power ON wifi adapter

Reported by: cocobean Owned by: waddlesplash
Priority: normal Milestone: Unscheduled
Component: Drivers/Network/iprowifi3945 Version: R1/Development
Keywords: iprowifi3945, wpi Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Errors:

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

Attachments (4)

P_20190104_135726[1].jpg (4.6 MB ) - added by cocobean 11 months ago.
iprowifi3924 driver KDL info with hrev52711 x86
P_20190105_184811[1].jpg (2.4 MB ) - added by cocobean 11 months ago.
iprowifi3945 driver KDL info on hrev52711 x86
haiku_hrev52711_x86_iprowifi3945_syslog_cocobean.txt (81.9 KB ) - added by cocobean 11 months ago.
Syslog info from hrev52711 x86
haiku_hrev52738_x86_iprowifi3945_syslog_cocobean.txt (131.3 KB ) - added by cocobean 10 months ago.
Syslog info from hrev52738 x86

Change History (22)

comment:1 by waddlesplash, 16 months ago

Please retest after hrev52114.

comment:2 by cocobean, 16 months ago

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

comment:3 by mmu_man, 16 months ago

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.

comment:4 by cocobean, 15 months ago

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)

Last edited 11 months ago by cocobean (previous) (diff)

by cocobean, 11 months ago

Attachment: P_20190104_135726[1].jpg added

iprowifi3924 driver KDL info with hrev52711 x86

comment:5 by waddlesplash, 11 months ago

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

comment:6 by cocobean, 11 months ago

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.

Last edited 11 months ago by cocobean (previous) (diff)

comment:7 by waddlesplash, 11 months ago

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.

by cocobean, 11 months ago

Attachment: P_20190105_184811[1].jpg added

iprowifi3945 driver KDL info on hrev52711 x86

by cocobean, 11 months ago

Syslog info from hrev52711 x86

comment:8 by waddlesplash, 10 months ago

Panic fixed in hrev52721.

comment:9 by cocobean, 10 months ago

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)

comment:10 by waddlesplash, 10 months ago

Please upload a new full syslog under this revision.

by cocobean, 10 months ago

Syslog info from hrev52738 x86

comment:11 by cocobean, 10 months ago

New syslog added to ticket.

comment:12 by waddlesplash, 6 months ago

Please retest after hrev53174.

comment:13 by cocobean, 6 months ago

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.)

Last edited 6 months ago by cocobean (previous) (diff)

comment:14 by waddlesplash, 6 months ago

There is still a "could not lock memory"?

comment:15 by cocobean, 6 months ago

Yes. All related syslog messages are the same.

comment:16 by luroh, 6 months ago

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)

comment:17 by waddlesplash, 6 months ago

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.

comment:18 by cocobean, 3 months ago

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.

Note: See TracTickets for help on using tickets.