Opened 5 weeks ago
Last modified 5 weeks ago
#19190 new bug
Atheros AR8152 V2.0 PHY errors
| Reported by: | majenko | Owned by: | nobody |
|---|---|---|---|
| Priority: | normal | Milestone: | Unscheduled |
| Component: | Drivers/Network/atheros813x | Version: | R1/beta5 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
Unable to activate the AR8152 on an E1-1500 (Compaq 100-100el) system. Syslog is filled with PHY timeouts / resets and then the driver gets unloaded.
KERN: [atheros813x] (alc) phy write timeout : 29 KERN: [atheros813x] (alc) phy read timeout : 30 ... KERN: [atheros813x] (alc) could not disable RxQ/TxQ (0xffffffff)! KERN: [atheros813x] (alc) could not disable Rx/Tx MAC(0xffffffff)! KERN: [atheros813x] (alc) master reset timeout! KERN: [atheros813x] (alc) reset timeout(0xffffffff)! ... KERN: [atheros813x] (alc) reloading EEPROM timeout! ... KERN: pci_unreserve_device(4, 0, 0, atheros813x)
Attachments (7)
Change History (23)
by , 5 weeks ago
| Attachment: | drivers.txt added |
|---|
by , 5 weeks ago
| Attachment: | listdev.txt added |
|---|
by , 5 weeks ago
| Attachment: | listusb.txt added |
|---|
by , 5 weeks ago
| Attachment: | syslog.txt added |
|---|
follow-up: 2 comment:1 by , 5 weeks ago
| Component: | Network & Internet → Drivers/Network/atheros813x |
|---|---|
| Platform: | x86-64 → All |
comment:2 by , 5 weeks ago
follow-up: 4 comment:3 by , 5 weeks ago
Please test on a recent nightly build, and also with ACPI disabled.
comment:4 by , 5 weeks ago
Replying to waddlesplash:
Please test on a recent nightly build, and also with ACPI disabled.
hrev58265 - no change. Same timeouts. Same attaching failed.
There are no ACPI settings in the BIOS on this little board. In fact there's very little of anything in the BIOS on this little board.
follow-up: 6 comment:5 by , 5 weeks ago
Waddlesplash ment disabeling acpi in our bootloader: https://www.haiku-os.org/docs/userguide/en/bootloader.html
comment:6 by , 5 weeks ago
Replying to nephele:
Waddlesplash ment disabeling acpi in our bootloader: https://www.haiku-os.org/docs/userguide/en/bootloader.html
Ah, gotcha. Took a few attempts and needing to slow down the boot with a POST delay in the BIOS, but I got there in the end.
Booted with ACPI disabled: fails to boot. Hangs on booting with USB errors.
usb error control pipe 6: timeout waiting for queued request to complete
Goes through hub after hub after hub (spoiler: it's lying) trying to add devices that don't exist.
by , 5 weeks ago
| Attachment: | my_photo-17.jpg added |
|---|
by , 5 weeks ago
| Attachment: | my_photo-18.jpg added |
|---|
follow-up: 8 comment:7 by , 5 weeks ago
If you're not booting from USB, try blocklisting the USB bus_manager in the bootloader options also, and see if this gets further.
comment:8 by , 5 weeks ago
Replying to waddlesplash:
If you're not booting from USB, try blocklisting the USB bus_manager in the bootloader options also, and see if this gets further.
Would that break my USB keyboard? (problem: there is only USB....)
follow-up: 10 comment:9 by , 5 weeks ago
Yes, it would, unfortunately.
You can also try disabling IO-APIC (but not ACPI), and "Ignore memory beyond 4GB" (both with and without disabling IO-APIC.)
comment:10 by , 5 weeks ago
Replying to waddlesplash:
Yes, it would, unfortunately.
You can also try disabling IO-APIC (but not ACPI), and "Ignore memory beyond 4GB" (both with and without disabling IO-APIC.)
Disabling IO-APIC (without disabling ACPI) kills the system with the same symptom as before. Disabling >4GB (with nothing else) gives atheros failures.
follow-up: 12 comment:11 by , 5 weeks ago
Well, that's all the ideas I have for the moment.
This driver comes from FreeBSD, so it may be interesting if you want to spend the time to see if it works under FreeBSD on this hardware, or whether it's really a driver bug and not a Haiku bug.
comment:12 by , 5 weeks ago
Replying to waddlesplash:
Well, that's all the ideas I have for the moment.
This driver comes from FreeBSD, so it may be interesting if you want to spend the time to see if it works under FreeBSD on this hardware, or whether it's really a driver bug and not a Haiku bug.
That's one of the first routes I went down: however FreeBSD won't boot on this system at the moment - fails to find any root FS to boot. I need to head down that rabbit hole I suppose.
comment:13 by , 5 weeks ago
Well, if you have any driver development experience and want to try and investigate this further (or want to try anyway even if you haven't looked into drivers before), feel free to find me on IRC and I can give you pointers on getting set up to do that, and other things you might poke at that way.
comment:14 by , 5 weeks ago
Ok, it works fine in FreeBSD 14.1 (the boot problem was it not liking booting off my iODD emulated USB CD drive, a real CD worked). Interface detected, DHCP acquired. Zero errors.
comment:15 by , 5 weeks ago
The errors from Haiku look like the device is "dead" or reads/writes to it are somehow failing (everything is coming back 0xFF it looks like.) In the past we had some issues with things being in the wrong powerstate or busmastering not being enabled properly, but I think those were fixed (or at least there's code for setting powerstates now.)
The question is then what FreeBSD is doing differently here to "wake up" the device before it even gets to this driver. We use ACPICA for ACPI same as FreeBSD, and our platform code for it is even loosely based/inspired by theirs, so hopefully that's not the problem. Our PCI bus implementation on the other hand is pretty different.
Is this on beta5?