Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #574 (closed defect: fixed)

Opened 14 years ago

Last modified 13 years ago

HAL oopses int ath_hal_reset on mips-be

Reported by: Assigned to:
Priority: major Milestone:
Component: madwifi: HAL Version: trunk
Keywords: Cc:
Patch is attached: 0 Pending:


svn-trunk oops with HAL in ath_hal_reset() on mips-be

This is the last output with reg output debugging enabled:

--> call to ath_hal_reset():

READ 0x4004 => 0x0
WRITE 0x4004 <= 0x0
READ 0x4010 => 0x14
READ 0x8004 => 0xeaef
WRITE 0x8004 <= 0xeaef
READ 0x1140 => 0x0
READ 0x9860 => 0x3fffc
READ 0x9864 => 0xf467fd0

I would attach a decode of the oops, but i havn't yet got a working ksymoops for the cross compiler

Change History

04/28/06 10:09:12 changed by anonymous

  • cc set to

04/28/06 10:50:23 changed by Stijn Tintel <>

Afaik, the HAL version in current SVN trunk is HAL, I assume you used the HAL from, which is, is this correct?

Please note that this HAL hasn't been publically released yet, because is needs further testing.

04/28/06 10:57:09 changed by

... and i'm testing it ;-)

The older HAL's doesn't work on this platform, since they insist on doing byteswapping on some registers. The new HAL uses external write functions, which allows me to disable the byteswapping.

Here is the promissed complete oops. Turned out that i didn't need ksymoops at all. Just building the kernel with full debugging was enough:

CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == c013dda4,c
Oops in arch/mips/mm/fault.c::do_page_fault, line 167[#1]:
Cpu 0
$ 0   : 00000000 1000fc00 80670000 000000a0
$ 4   : 00000000 00000000 00000000 80670000
$ 8   : 000000a0 000012db 80260000 80260000
$12   : 80260000 00705aac 00000001 6c6195ea
$16   : c00f0000 80670000 80670000 80670000
$20   : 00000000 806702c0 80030000 80250000
$24   : 00000010 800e0e20
$28   : 80556000 80557d00 80baf138 c013ebac
Hi    : 000004fd
Lo    : f3898000
epc   : c013dda4 zz0b69b07c+0x94/0x100 [ath_hal]     Tainted: P
ra    : c013ebac zz0016d872+0x2c/0x250 [ath_hal]
Status: 1000fc03    KERNEL EXL IE
Cause : 00800008
BadVA : c01399e8
PrId  : 00029107
Modules linked in: ath_pci ath_rate_sample ath_hal wlan_scan_sta wlan_scan_ap wlan
Process ifconfig (pid: 175, threadinfo=80556000, task=80ba25c0)
Stack : 00000000 c0120a3c ffff0400 1000fc01 c00f0000 80bae220 80670000 c0137b48
        80030000 80250000 800e05c4 80bae334 8025906e 1000fc01 80210000 00000006
        00000000 80033fc0 c00dff60 c00dff2c 802135bc 802135cc c00f0000 80bae220
        80bae000 80033f08 80670000 80bae334 80030000 80250000 00000000 c00e5a88
        80056704 00000001 00000001 00000001 80557d98 000000d2 00000000 00000010
Call Trace:
 [<c0120a3c>] zz00067d32+0x54/0xa4 [ath_hal]
 [<c0137b48>] zz0002dbd2+0x188/0x1174 [ath_hal]
 [<80030000>] init_idle+0x108/0x124
 [<80250000>] bcm63xx_enet_probe+0xa0/0x8f0
 [<800e05c4>] vscnprintf+0x14/0x30
 [<80033fc0>] printk+0xb8/0x27c
 [<c00dff60>] ath_stoprecv+0x80/0x160 [ath_pci]
 [<c00dff2c>] ath_stoprecv+0x4c/0x160 [ath_pci]
 [<80033f08>] printk+0x0/0x27c
 [<80030000>] init_idle+0x108/0x124
 [<80250000>] bcm63xx_enet_probe+0xa0/0x8f0
 [<c00e5a88>] ath_reset+0xec/0x490 [ath_pci]
 [<80056704>] buffered_rmqueue+0xc0/0x364
 [<800e0e20>] memcpy+0x0/0x4
 [<c00ea6e8>] ath_set_mac_address+0x204/0x2f8 [ath_pci]
 [<80157274>] dev_ifsioc+0x248/0x500
 [<80157050>] dev_ifsioc+0x24/0x500
 [<80154c4c>] dev_load+0x14/0x64
 [<80157b6c>] dev_ioctl+0x640/0x7a4
 [<80157b58>] dev_ioctl+0x62c/0x7a4
 [<8001cc00>] do_page_fault+0x160/0x360
 [<80095524>] d_alloc+0x34/0x20c
 [<801a3010>] inet_ioctl+0x138/0x154
 [<80149a00>] __sock_create+0x174/0x3b8
 [<801494d4>] sock_ioctl+0x578/0x5a4
 [<8008fc14>] sys_ioctl+0x384/0x3c0
 [<8001b900>] stack_done+0x20/0x3c
 [<800ae688>] proc_mkdir_mode+0x54/0x78

Code: 000210c0  00471021  94442c30 <94a30000> 10830017  00c01025  00061040  00461021  0002

05/02/06 11:00:12 changed by mrenzmann

FYI: I've forwarded this information to Sam. He answered, that the mentioned combination reportedly works fine on NetBSD. His suspection is that this could be a MadWifi-specific issue.

05/09/06 04:21:45 changed by

FYI, this combination is not known to operate on NetBSD. I'm working on this now.

05/09/06 06:43:31 changed by mrenzmann

@gdamore: Thanks for the information, please keep us updated and let us know if we can be of any help.

05/09/06 07:46:20 changed by

I was planning on running this under KGDB control to get a more reliable backtrace. Would this be of any help?

05/16/06 03:58:41 changed by dyqith

Architecture more info there, if not, please add some, thanks.

02/17/07 15:22:02 changed by

fixed by [1714]

could somebody please close this ticket

02/17/07 16:07:21 changed by mentor

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


Reported resolved in r1714