OpenWrt/LEDE Project

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Bug Report
  • Category Kernel
  • Assigned To No-one
  • Operating System All
  • Severity Critical
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Paul Flinders - 01.03.2020

FS#2871 - Buffalo WHR-600D fails to initialise RT5592.

This *might* be the same bug as  bug 691  (https://bugs.openwrt.org/index.php?do=details&task_id=691), or at least related.

Rooting around in the junk box I found a dismantled and bricked WHR-600D, not sure why or how it got into that state but I would have been tinkering with it in the Chaos Calmer era so possibly could not get it working at the time.

However I decided it would be a useful upgrade to a WHR-HP-G300N that I have covering a corner of the house - especially as that only has 4MB flash/32MB ram so is not really suitable for modern versions of OpenWRT

But... no dice

I successfully got half a serial console (I think the 600D’s rx pin is hosed) and got an initramfs image booted and flashed 19.07.1 - subsequent to that I compiled trunk from source but the behaviour is the same.

The RT5592 is not initialized - it is not “mis-detected” as a 2.4GHz only interface (although the unused MT7620A WiFi interface *is* detected as phy1).

Boot shows:

[ 8.984703] rt2800pci 0000:01:00.0: loaded eeprom from mtd device “factory” [ 8.998658] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5592, rev 0222 detected
[ 9.014109] ieee80211 phy0: rt2800_init_eeprom: Error - Invalid RF chipset 0×0000 detected
[ 9.030585] ieee80211 phy0: rt2x00lib_probe_dev: Error - Failed to allocate device

then - for phy1

[ 9.050320] rt2800_wmac 10180000.wmac: loaded eeprom from mtd device “factory” [ 9.064801] ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 6352, rev 0500 detected
[ 9.080250] ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 7620 detected
[ 9.094676] ieee80211 phy1: Selected rate control algorithm ‘minstrel_ht’

iw list only gives phy1 although I think that is unused/unconnected on this router (AFAICS the two antenna connect only into the RT5592) - I can’t try the images that Mathias Kresin posted in the previous bug report as the links are now dead but I see that the two commits that were made to the WHR-600D and RP-N53 dts files don’t seem to have been accidentally reverted.

Also tried 18.06.7 but that just crashes with:
[ 10.951562] rt2800pci 0000:01:00.0: loaded eeprom from mtd device “factory” [ 10.965533] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5592, rev 0222 detected
[ 10.980983] ieee80211 phy0: rt2800_init_eeprom: Error - Invalid RF chipset 0×0000 detected
[ 10.997460] ieee80211 phy0: rt2x00lib_probe_dev: Error - Failed to allocate device
[ 11.012574] ————[ cut here ]———— [ 11.021787] WARNING: CPU: 0 PID: 426 at mm/vmalloc.c:1466 0x801b2480()
[ 11.034795] Trying to vfree() nonexistent vm area (8317e000)

Not sure where to take this but happy to supply extra info or try patches if anyone has any ideas.

 


psyborg commented on 03.03.2020 03:08

hi

take a look at the comments here: https://patchwork.kernel.org/patch/10743707/

Paul Flinders commented on 04.03.2020 21:54

Yeah I saw that - I figured the comment about it not being needed was correct as there is no crash with the 19.07.1 kernel (or from trunk) and it is not done like that in mainstream kernels.

If I apply the patch to rt2800lib.c things improve a lot - at least I can see the interface & iwlist produces valid looking output, the MAC address looks OK as well so the 0x8000 offset into factory.bin looks correct.

It works - after a fashion. I can scan the 5GHz band and it picks up my main network and I can see the beacon on "WiFi Analyzer" on my Android phone but no idea if I can associate to it (that can wait for tomorrow).

The original bug report mentioned that it was *not* possible to associate with the network and that large numbers of error messages appear - which I also get. I note also that you commented that this is also the case for the EA2750.

Kernel log is full of eg
[ 368.287025] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0001, type=4
[ 368.324850] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0001, signal=0x0120, type=4
[ 377.089716] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 4095 max 3840
[ 377.105202] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840

Attached are the iwlist/ifconfig outputs and a dump of factory.bin.

Any further suggestions welcome - especially as I know the square root of nothing about programming WiFi chipsets

psyborg commented on 06.03.2020 09:10

you can try with passing RAM size arguments: https://bugzilla.kernel.org/show_bug.cgi?id=110091

Paul Flinders commented on 07.03.2020 16:50

OK, it's not unreasonable to think it might be something similar but the WHR-600D does not use pci_lantiq and passing "phym=64M mem=32M", while it cuts the available RAM by half, does not change the error messages at all.

psyborg commented on 08.03.2020 11:03

same on EA2750... maybe target specific pci patch needs to be adapted for your target. haven't tried that

Paul Flinders commented on 08.03.2020 11:13

It's possible some of the changes here might be relevant:

https://patchwork.kernel.org/patch/11131963/

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing