Ticket #927 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

Total hang on loading ath_pci (0.9.2) on mips-be platform

Reported by: adq_dvb@lidskialf.net Assigned to:
Priority: major Milestone: version 0.9.3
Component: madwifi: driver Version:
Keywords: Cc:
Patch is attached: 0 Pending:

Description

Hi, I am building my own firmware image for a Netgear DG834GT router. This is based on the Broadcom BCM6348 (mips-be), and has an atheros minipci card in it. Unfortunately the latest (0.9.2) drivers lock the machine up completely as soon as I load ath_pci.

Details of the card: 

vendor:0x168c
device:0x0013
subsystem_vendor:0x168c
subsystem_device:0x2051
There are no markings on minipci card itself.

Loading the 0.9.2 modules reports: 

wlan: 0.8.4.2 (0.9.2)
wlan: mac acl policy registered
ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413, REGOPS_FUNC)
ath_rate_amrr: 0.1 (0.9.2)
ath_pci: 0.9.4.5 (0.9.2)
PCI: Enabling device 0000:00:01.0 (0000 -> 0002)
ath_attach: devid 0x13

At this point, the machine locks - no oops or anything. I enabled as many kernel debug options as possible, but.. nothing.

I then added tracing and found its the call to: ath_hal_attach() which hangs. So I enabled the HAL debug. This shows the following: 

ath_hal_reg_read(16388)
READ 0x4004 => 0x100
WRITE 0x4004 <= 0x100
ath_hal_reg_read(16400)
READ 0x4010 => 0x14000100
ath_hal_reg_read(32772)
READ 0x8004 => 0x0
WRITE 0x8004 <= 0x0
ath_hal_reg_read(16416)
READ 0x4020 => 0x79000000
ath_hal_reg_read(16388)
READ 0x4004 => 0x100
WRITE 0x4004 <= 0x100
ath_hal_reg_read(16400)
READ 0x4010 => 0x14000100
ath_hal_reg_read(32772)
READ 0x8004 => 0x0
WRITE 0x8004 <= 0x0
ath_hal_reg_read(12)
READ 0xc => 0x0
WRITE 0x4000 <= 0x13
ath_hal_reg_read(16384)
READ 0x4000 => 0x0

it then does: 

ath_hal_reg_read(16384)
READ 0x4000 => 0x0
usleep()

loads of times - looks like some kind of polling wait for something to initialise to me.

Finally, it does: 

READ 0x4000 => 0x0
ath_hal_reg_read(32772)

At this point, it hangs.

The machine actually comes with drivers which seem /very/ similar to the madwifi ones, however, it also contains a module, ath_rate_atheros.ko, which makes me think they are basing it on an internal atheros codebase. These drivers actually work ok, so I could use them instead, but where's the fun in that? :)

Loading the /Netgear/ drivers reports: 

wlan: 0.8.4.2 (Atheros/multi-bss)
wlan: mac acl policy registered
ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 0.9.14.25 (AR5212, RF5111, RF5112, RF2413)
ath_rate_atheros: Version 2.0.1
ath_pci: 0.9.4.5 (Atheros/multi-bss) (0.1.1)
PCI: Enabling device 0000:00:01.0 (0000 -> 0002)
wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: turboG rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: mac 7.9 phy 4.5 radio 5.6
wifi0: Use hw queue 1 for WME_AC_BE traffic
wifi0: Use hw queue 0 for WME_AC_BK traffic
wifi0: Use hw queue 2 for WME_AC_VI traffic
wifi0: Use hw queue 3 for WME_AC_VO traffic
wifi0: Use hw queue 8 for CAB traffic
wifi0: Use hw queue 9 for beacons
wifi0: Atheros 5212: mem=0x8000000, irq=32

Is there anything else I can do to provide more information to help with debugging?

Attachments

Change History

09/30/06 01:39:18 changed by adq_dvb@lidskialf.net

I've been doing further research. Improving my tracing I modified the ath_hal_reg_read() function so it looks like this: 

u_int32_t __ahdecl
ath_hal_reg_read(struct ath_hal *ah, u_int reg)
{
        u_int32_t val;

   printk("PREREAD 0x%x\n", reg);

        val = _OS_REG_READ(ah, reg);
#ifdef AH_DEBUG
        if (ath_hal_debug > 1)
                ath_hal_printf(ah, "READ 0x%x => 0x%x\n", reg, val);
#endif
        return val;
}

At the hang, I see: 

READ 0x4000 => 0x0
DELAY 10
PREREAD 0x8004

So the call to _OS_REG_READ(0x8004) never actually returns!!

As that seems to be doing a simple memory mapped access, it sounds like the device is dropping off the PCI bus during the initialisation, and never coming back.

09/30/06 04:35:30 changed by adq_dvb@lidskialf.net

Further analysis of the netgear drivers shows the HAL version is "pre-madwifi-ng" equivalent.

Using nasty kernel hacks to cause page faults, I've managed to trace the init sequence of the netgear HAL drivers: 

READ: 0x4004
WRITE: ? -> 0x4004
READ: 0x4010
READ: 0x8004
WRITE: 0x8004
READ: 0xC
WRITE: 0x13 -> 0x4000
... loop waiting for 0x4000 to become ready
onwards...

I can see this looks similar to the -ng HAL init, but it does obviously differ in the sequence.. cleaned up -ng init follows: 

READ 0x4004 => 0x100
WRITE 0x4004 <= 0x100
READ 0x4010 => 0x14000100
READ 0x8004 => 0x0
WRITE 0x8004 <= 0x0
READ 0x4020 => 0x79000000
READ 0x4004 => 0x100
WRITE 0x4004 <= 0x100
READ 0x4010 => 0x14000100
READ 0x8004 => 0x0
WRITE 0x8004 <= 0x0
READ 0xc => 0x0
WRITE 0x4000 <= 0x13
READ 0x4000 => 0x0
... this is the loop waiting for 0x4000 to become ready.

Anyway, this is about as much as I can do... I hope this helps to shed some light on what has changed...

09/30/06 16:01:16 changed by adq_dvb@lidskialf.net

Ah - one last thing: I tried hooking the latest hal (ath_hal-20060909.tgz), downloaded from: 

people.freebsd.org ~sam

Same result - locks up in the same manner.

10/02/06 18:53:32 changed by mrenzmann

The mentioned HAL has already been committed to trunk in r1711, by the way.

10/04/06 00:34:03 changed by adq_dvb@lidskialf.net

Tried a complete trunk checkout just in case; no change.

04/24/07 23:00:57 changed by adq_dvb@lidskialf.net

Hi - this fatal hang is now gone with 0.9.3, so this can be safely closed.

(There is a different problem now, but I'll open a new ticket for that)

04/24/07 23:59:16 changed by mentor

  • status changed from new to closed.
  • resolution set to fixed.

04/25/07 07:22:42 changed by mrenzmann

  • milestone set to version 0.9.3.

04/25/07 07:23:03 changed by mrenzmann

Thanks for the feedback.

Add/Change #927 (Total hang on loading ath_pci (0.9.2) on mips-be platform)