Opened 6 years ago
Last modified 2 years 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: | Cc: | ||
Blocked By: | Blocking: | #16262 | |
Platform: | All |
Description (last modified by )
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):
- wpi driver and Intel 3945 firmware used in FreeBSD 11.1/11.2 - works.
- 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
Attachments (5)
Change History (34)
comment:1 by , 6 years ago
comment:2 by , 6 years 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 , 6 years 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 , 6 years 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)
by , 6 years ago
Attachment: | P_20190104_135726[1].jpg added |
---|
iprowifi3924 driver KDL info with hrev52711 x86
comment:6 by , 6 years 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.
comment:7 by , 6 years 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 , 6 years ago
Attachment: | P_20190105_184811[1].jpg added |
---|
iprowifi3945 driver KDL info on hrev52711 x86
by , 6 years ago
Attachment: | haiku_hrev52711_x86_iprowifi3945_syslog_cocobean.txt added |
---|
Syslog info from hrev52711 x86
comment:9 by , 6 years 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)
by , 6 years ago
Attachment: | haiku_hrev52738_x86_iprowifi3945_syslog_cocobean.txt added |
---|
Syslog info from hrev52738 x86
comment:13 by , 5 years 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.)
comment:16 by , 5 years 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 , 5 years 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 , 5 years 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.
comment:19 by , 4 years ago
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.
comment:20 by , 4 years ago
Blocking: | 16262 added |
---|
comment:23 by , 4 years ago
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)
comment:24 by , 4 years ago
Description: | modified (diff) |
---|
by , 4 years ago
Attachment: | hp_pavilion_dv8000.jpg added |
---|
HP Pavilion dv8000 laptop (with Wifi button enabled and blue light indicator (shown above keyboard)).
comment:25 by , 3 years ago
Keywords: | iprowifi3945 wpi removed |
---|
comment:27 by , 3 years ago
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
comment:28 by , 2 years ago
Haiku hrev56496 x86: FAILED
- Wifi EEPROM R/W and loading - same issue.
- Wifi firmware version: v15.32.2.9 (iwlwifi-3945-2.ucode)
comment:29 by , 2 years ago
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
Please retest after hrev52114.