Discussion:
[Orinoco-users] Kernel oops when loading airport module on 2.6.29-rc3 with G4 Powerbook
Eerikki Hakanen
2009-02-08 18:26:26 UTC
Permalink
Hi,


Loading the airport driver as a module causes a kernel oops in 2.6.29-
rc3 on a 15" 550Mhz Powerbook G4 (PPC). This also happens with 2.6.28.

If the driver is compiled into the kernel, rather than as a module
there is only a "can not find agere_sta_fw.bin" error message on boot
time, even though the firmware file has been placed in /lib/firmware/

Firmware file used is the one found in linux-firmware tree (v.9.48).


Please find the dmesg output below

airport 0.15 (Benjamin Herrenschmidt <***@kernel.crashing.org>)
airport: Physical address 80030000
eth0 (airport): not using net_device_ops yet
eth0: Hardware identity 0005:0001:0001:0002
eth0: Station identity 001f:0001:0008:0046
eth0: Firmware determined as Lucent/Agere 8.70
airport 0.00030000:radio: firmware: requesting agere_sta_fw.bin
eth0: Attempting to download firmware agere_sta_fw.bin
hermes_dld: AUX enable returned 0
hermes_dld: AUX disable returned 0
hermes_dld: Actual PDA length 998, Max allowed 1000
eth0: Read PDA returned 0
hermes_dld: AUX enable returned 0
hermes_dld: Enabling volatile, EP 0x0f80c200
hermes_dld: PROGRAM_ENABLE returned 0
eth0: Program init returned 0
hermes_dld: Programming block of length 67 to address 0x01696377
hermes_dld: Programming block of length 48835 to address 0x66006070
eth0: Program returned 0
Unable to handle kernel paging request for data at address 0x9f38f230
Faulting instruction address: 0xc01dd6d0
Oops: Kernel access of bad area, sig: 11 [#1]
PowerMac
Modules linked in: snd_aoa_i2sbus(+) snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer snd_page_alloc snd soundcore pcmcia airport(+)
snd_aoa_soundbus yenta_socket rsrc_nonstatic pcmcia_core uninorth_agp
agpgart evdev ohci_hcd ide_cd_mod cdrom ohci1394 sungem sungem_phy
ieee1394 usbcore i2c_powermac
NIP: c01dd6d0 LR: c01d5d20 CTR: 00000001
REGS: de493bd0 TRAP: 0300 Not tainted (2.6.29-rc3)
MSR: 00009032 <EE,ME,IR,DR> CR: 22002228 XER: 20000000
DAR: 9f38f230, DSISR: 40000000
TASK = df9e26a0[1439] 'modprobe' THREAD: de492000
GPR00: c01d5d20 de493c80 df9e26a0 de47546c 9f38f230 de507800 c03a0000
c0370000
GPR08: c03a4470 0012c3bc e275e000 00003000 0000001c 1001ec04 00000000
00000000
GPR16: 00000000 00000000 10020ca0 100019a0 4801a000 00000000 00000000
00000003
GPR24: 9f38f618 de507804 de47546c 9f38f230 de47546c 00000000 e275e000
de475380
NIP [c01dd6d0] hermes_apply_pda_with_defaults+0x214/0x248
LR [c01d5d20] orinoco_download+0x1dc/0x3ac
Call Trace:
[de493c80] [c01dd7e0] hermes_program+0x90/0x128 (unreliable)
[de493cb0] [c01d5d20] orinoco_download+0x1dc/0x3ac
[de493ce0] [c01da3a0] orinoco_init+0xe8/0x730
[de493d30] [c021bfd0] register_netdevice+0x174/0x398
[de493d80] [c021c23c] register_netdev+0x48/0x68
[de493d90] [e2537388] airport_attach+0x1a8/0x1fc [airport]
[de493db0] [c01dead4] macio_device_probe+0x5c/0x84
[de493dd0] [c01cbb98] driver_probe_device+0xfc/0x1a0
[de493df0] [c01cbcac] __driver_attach+0x70/0xa4
[de493e10] [c01caea0] bus_for_each_dev+0x54/0x98
[de493e40] [c01cb984] driver_attach+0x24/0x34
[de493e50] [c01cb4e8] bus_add_driver+0xb0/0x218
[de493e70] [c01cbf18] driver_register+0xa8/0x13c
[de493e90] [c01de9a8] macio_register_driver+0x28/0x38
[de493ea0] [e253c02c] init_airport+0x2c/0x60 [airport]
[de493eb0] [c0003cf4] do_one_initcall+0x58/0x19c
[de493f20] [c0054df8] sys_init_module+0xac/0x1bc
[de493f40] [c0014724] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xff6cdc8
LR = 0x10003c50
Instruction dump:
5405c23e 5005442e 801a0000 54a50bfc 7c634830 38a5fffe 7c630214 54a5f87e
4be3aa45 3b7b000c 7f9bc040 409c0020 <801b0000> 541d463e 501dc42e
501d421e
---[ end trace 29288e4819c89477 ]---




Best regards,
Eerikki Hakanen
Dave
2009-02-09 00:00:49 UTC
Permalink
Post by Eerikki Hakanen
Loading the airport driver as a module causes a kernel oops in 2.6.29-
rc3 on a 15" 550Mhz Powerbook G4 (PPC). This also happens with 2.6.28.
Thanks for the report.
Post by Eerikki Hakanen
If the driver is compiled into the kernel, rather than as a module
there is only a "can not find agere_sta_fw.bin" error message on boot
time, even though the firmware file has been placed in /lib/firmware/
I'll recompile my kernel to check, but I think you might have to compile
the firmware into the kernel if you want to do that.
Post by Eerikki Hakanen
Firmware file used is the one found in linux-firmware tree (v.9.48).
airport: Physical address 80030000
eth0 (airport): not using net_device_ops yet
eth0: Hardware identity 0005:0001:0001:0002
eth0: Station identity 001f:0001:0008:0046
eth0: Firmware determined as Lucent/Agere 8.70
airport 0.00030000:radio: firmware: requesting agere_sta_fw.bin
eth0: Attempting to download firmware agere_sta_fw.bin
hermes_dld: AUX enable returned 0
hermes_dld: AUX disable returned 0
hermes_dld: Actual PDA length 998, Max allowed 1000
eth0: Read PDA returned 0
hermes_dld: AUX enable returned 0
hermes_dld: Enabling volatile, EP 0x0f80c200
The entry point is suspect, it should be 0x000f8000
Post by Eerikki Hakanen
hermes_dld: PROGRAM_ENABLE returned 0
eth0: Program init returned 0
hermes_dld: Programming block of length 67 to address 0x01696377
hermes_dld: Programming block of length 48835 to address 0x66006070
And the length/addresses here are suspect too.

The driver appears to be reading the firmware headers wrong. The above
numbers ought to be enough to identify where it's all gone wrong - but
I'll have to do that tomorrow.

In the meantime, I can only suggest moving the firmware out of the way,
and sticking with WEP until the problem is addressed.


Regards,

Dave.
Dave
2009-02-09 21:00:43 UTC
Permalink
Post by Dave
Post by Eerikki Hakanen
Loading the airport driver as a module causes a kernel oops in 2.6.29-
rc3 on a 15" 550Mhz Powerbook G4 (PPC). This also happens with 2.6.28.
Firmware file used is the one found in linux-firmware tree (v.9.48).
airport: Physical address 80030000
eth0 (airport): not using net_device_ops yet
eth0: Hardware identity 0005:0001:0001:0002
eth0: Station identity 001f:0001:0008:0046
eth0: Firmware determined as Lucent/Agere 8.70
airport 0.00030000:radio: firmware: requesting agere_sta_fw.bin
eth0: Attempting to download firmware agere_sta_fw.bin
hermes_dld: AUX enable returned 0
hermes_dld: AUX disable returned 0
hermes_dld: Actual PDA length 998, Max allowed 1000
eth0: Read PDA returned 0
hermes_dld: AUX enable returned 0
hermes_dld: Enabling volatile, EP 0x0f80c200
The entry point is suspect, it should be 0x000f8000
Post by Eerikki Hakanen
hermes_dld: PROGRAM_ENABLE returned 0
eth0: Program init returned 0
hermes_dld: Programming block of length 67 to address 0x01696377
hermes_dld: Programming block of length 48835 to address 0x66006070
And the length/addresses here are suspect too.
The driver appears to be reading the firmware headers wrong. The above
numbers ought to be enough to identify where it's all gone wrong - but
I'll have to do that tomorrow.
OK, I've had a closer look. I strongly suspect a corrupt image. The
numbers in you dmesg output can be found in the firmware file, but I
can't see how the compiler could mangle the header reading to get the
results you're seeing. See below for details.

Do you have CONFIG_HERMES_CACHE_FW_ON_INIT set? If the answer is yes,
another part of the kernel may be corrupting the cache. Can you please
try with this option set to no?

Can you confirm the following:
* version of the compiler that you are using
* whether you are using any special optimisation flags
* whether you use other firmware with your kernel
* distro
* first 128 bytes of your firmware image:
'head -c 128 /lib/firmware/agere_sta_fw.bin | od -x'

Thanks,

Dave.
---
The entry point is a 32 bit LE at offset 8. It looks like it's been read
from offset 7 - however a 0xc2 has crept in from somewhere.

The address for the first block should be at the header size (16 bit LE,
offset 6 = 0x30) plus the block offset (32 bit LE offset 16 = 0x00), but
it is being read from offset 0x2b. The size of the block is in the next
2 bytes as a 16 bit LE.

The address and size of the next block should follow on immediately
after the data of the first block. However the address seems to come
from offset 66 instead of 0x6E, and I can't where the size is coming from.
Eerikki Hakanen
2009-02-09 22:11:07 UTC
Permalink
Post by Dave
Post by Dave
Post by Eerikki Hakanen
Loading the airport driver as a module causes a kernel oops in 2.6.29-
rc3 on a 15" 550Mhz Powerbook G4 (PPC). This also happens with 2.6.28.
Firmware file used is the one found in linux-firmware tree (v.9.48).
airport: Physical address 80030000
eth0 (airport): not using net_device_ops yet
eth0: Hardware identity 0005:0001:0001:0002
eth0: Station identity 001f:0001:0008:0046
eth0: Firmware determined as Lucent/Agere 8.70
airport 0.00030000:radio: firmware: requesting agere_sta_fw.bin
eth0: Attempting to download firmware agere_sta_fw.bin
hermes_dld: AUX enable returned 0
hermes_dld: AUX disable returned 0
hermes_dld: Actual PDA length 998, Max allowed 1000
eth0: Read PDA returned 0
hermes_dld: AUX enable returned 0
hermes_dld: Enabling volatile, EP 0x0f80c200
The entry point is suspect, it should be 0x000f8000
Post by Eerikki Hakanen
hermes_dld: PROGRAM_ENABLE returned 0
eth0: Program init returned 0
hermes_dld: Programming block of length 67 to address 0x01696377
hermes_dld: Programming block of length 48835 to address 0x66006070
And the length/addresses here are suspect too.
The driver appears to be reading the firmware headers wrong. The above
numbers ought to be enough to identify where it's all gone wrong - but
I'll have to do that tomorrow.
OK, I've had a closer look. I strongly suspect a corrupt image. The
numbers in you dmesg output can be found in the firmware file, but I
can't see how the compiler could mangle the header reading to get the
results you're seeing. See below for details.
Do you have CONFIG_HERMES_CACHE_FW_ON_INIT set? If the answer is yes,
another part of the kernel may be corrupting the cache. Can you please
try with this option set to no?
CONFIG_HERMES_CACHE_FW_ON_INIT was set. I will set it to no and re-compile. I will have the time to test the re-compiled kernel tomorrow.
Post by Dave
* version of the compiler that you are using
* whether you are using any special optimisation flags
* whether you use other firmware with your kernel
* distro
'head -c 128 /lib/firmware/agere_sta_fw.bin | od -x'
Compiler version from "cat /proc/version" is "(gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)"
No special optimisation flags that I am aware of
No other firmwares in use that I would be aware of
Distribution used is Debian 4.0r3 for PPC

First 128 bytes of the firmware image is below

0000000 4846 5730 3030 3000 00c2 800f 0002 0000
0000020 0000 0000 0012 c3bc 0000 7ac3 bd00 00c3
0000040 a6c3 bd00 0046 5550 5537 4433 3764 6866
0000060 7763 6901 4300 001f 0000 c3ac 0f60 c3bc
0000100 633e 6000 65c3 af60 c3be 613c 6000 66c3
0000120 af60 c3be 6446 4b58 c390 6546 59c3 982b
0000140 46c3 bb1f c280 6013 78c3 bfc3 bf00 6401
0000160 60c3 be63 0360 c3be 6170 6000 66c3 be60
0000200

Best regards,
Eerikki Hakanen
Post by Dave
Thanks,
Dave.
---
The entry point is a 32 bit LE at offset 8. It looks like it's been read
from offset 7 - however a 0xc2 has crept in from somewhere.
The address for the first block should be at the header size (16 bit LE,
offset 6 = 0x30) plus the block offset (32 bit LE offset 16 = 0x00), but
it is being read from offset 0x2b. The size of the block is in the next
2 bytes as a 16 bit LE.
The address and size of the next block should follow on immediately
after the data of the first block. However the address seems to come
from offset 66 instead of 0x6E, and I can't where the size is coming from.
Dave
2009-02-10 18:46:39 UTC
Permalink
Post by Eerikki Hakanen
Post by Dave
Post by Eerikki Hakanen
Loading the airport driver as a module causes a kernel oops in 2.6.29-
rc3 on a 15" 550Mhz Powerbook G4 (PPC). This also happens with 2.6.28.
Firmware file used is the one found in linux-firmware tree (v.9.48).
'head -c 128 /lib/firmware/agere_sta_fw.bin | od -x'
First 128 bytes of the firmware image is below
0000000 4846 5730 3030 3000 00c2 800f 0002 0000
0000020 0000 0000 0012 c3bc 0000 7ac3 bd00 00c3
0000040 a6c3 bd00 0046 5550 5537 4433 3764 6866
0000060 7763 6901 4300 001f 0000 c3ac 0f60 c3bc
0000100 633e 6000 65c3 af60 c3be 613c 6000 66c3
0000120 af60 c3be 6446 4b58 c390 6546 59c3 982b
0000140 46c3 bb1f c280 6013 78c3 bfc3 bf00 6401
0000160 60c3 be63 0360 c3be 6170 6000 66c3 be60
0000200
The firmware image on disk is corrupt. I've just re-pulled from
linux-firmware, and the image there looks correct*:

0000000 48 46 57 30 30 30 30 00 00 80 0f 00 02 00 00 00
0000020 00 00 00 00 12 fc 00 00 7a fd 00 00 e6 fd 00 00
0000040 46 55 50 55 37 44 33 37 64 68 66 77 63 69 01 43
0000060 00 00 1f 00 00 ec 0f 60 fc 63 3e 60 00 65 ef 60
0000100 fe 61 3c 60 00 66 ef 60 fe 64 46 4b 58 d0 65 46
0000120 59 d8 2b 46 fb 1f 80 60 13 78 ff ff 00 64 01 60
0000140 fe 63 03 60 fe 61 70 60 00 66 fe 60 00 65 a5 d2
0000160 da 85 59 db 60 47 59 db fa 1f 88 e2 3e 60 00 66

That said, it shouldn't be causing an oops. I'll try get a patch applied
to avoid that.


Thanks,

Dave.

PS. used 'od -t x1' since I noticed od was reading shorts in native
endianess.
Eerikki Hakanen
2009-02-10 19:50:24 UTC
Permalink
Post by Dave
Post by Eerikki Hakanen
Post by Dave
Post by Eerikki Hakanen
Loading the airport driver as a module causes a kernel oops in 2.6.29-
rc3 on a 15" 550Mhz Powerbook G4 (PPC). This also happens with 2.6.28.
Firmware file used is the one found in linux-firmware tree (v.
9.48).
'head -c 128 /lib/firmware/agere_sta_fw.bin | od -x'
First 128 bytes of the firmware image is below
0000000 4846 5730 3030 3000 00c2 800f 0002 0000
0000020 0000 0000 0012 c3bc 0000 7ac3 bd00 00c3
0000040 a6c3 bd00 0046 5550 5537 4433 3764 6866
0000060 7763 6901 4300 001f 0000 c3ac 0f60 c3bc
0000100 633e 6000 65c3 af60 c3be 613c 6000 66c3
0000120 af60 c3be 6446 4b58 c390 6546 59c3 982b
0000140 46c3 bb1f c280 6013 78c3 bfc3 bf00 6401
0000160 60c3 be63 0360 c3be 6170 6000 66c3 be60
0000200
The firmware image on disk is corrupt. I've just re-pulled from
I re-downloaded the linux-firmware tree using git and copied the
agere_sta_fw.bin to /lib/firmware. The first 128 bytes look exactly
like below now and there is no error messages on the startup.

Thanks for all the help.

Best regards,
Eerikki Hakanen
Post by Dave
0000000 48 46 57 30 30 30 30 00 00 80 0f 00 02 00 00 00
0000020 00 00 00 00 12 fc 00 00 7a fd 00 00 e6 fd 00 00
0000040 46 55 50 55 37 44 33 37 64 68 66 77 63 69 01 43
0000060 00 00 1f 00 00 ec 0f 60 fc 63 3e 60 00 65 ef 60
0000100 fe 61 3c 60 00 66 ef 60 fe 64 46 4b 58 d0 65 46
0000120 59 d8 2b 46 fb 1f 80 60 13 78 ff ff 00 64 01 60
0000140 fe 63 03 60 fe 61 70 60 00 66 fe 60 00 65 a5 d2
0000160 da 85 59 db 60 47 59 db fa 1f 88 e2 3e 60 00 66
That said, it shouldn't be causing an oops. I'll try get a patch applied
to avoid that.
Thanks,
Dave.
PS. used 'od -t x1' since I noticed od was reading shorts in native
endianess.
Loading...