Re: [Madwifi-users] madwifi CVS-Sept-15-04 doesn't work

[Sam L. <sa...@er...>]

On Wednesday 15 September 2004 06:27 am, Patrick Pichon wrote:
> Hello,
>
> I have downloaded the latest CVS HEAD today. I have apply Jazzzper's
> patch for proc_doinitvec and got the compilation done. I'm even bulding
> correctly my rpm file.
>
> However when loading the drivers (modprobe ath_pci) into the system I
> got an error message. And such with a stack trace here after.
>
> Does anyone has hints to sorted out. I am back to my late august
> version, which work well (except that sysctl command do a seg. fault
> which from the stack trace looks to the proc_doinitvec parameter)
>
>
> Best regards
> Patrick
>
> Sep 15 14:59:31 localhost kernel: ath_hal: 0.9.12.1
> Sep 15 14:59:31 localhost kernel: wlan: 0.8.4.2 (EXPERIMENTAL)
> Sep 15 14:59:31 localhost kernel: ath_pci: 0.9.4.1 (EXPERIMENTAL)
> Sep 15 14:59:31 localhost kernel: ACPI: PCI interrupt 0000:00:09.0[A] ->
> GSI 5 (level, low) -> IRQ 5
> Sep 15 14:59:31 localhost kernel: ath%%d: HAL ABI msmatch; driver
> expects 0x4050400, HAL reports 0x0

This is your problem.

> Sep 15 14:59:31 localhost kernel: Unable to handle kernel NULL pointer
> dereference at virtual address 00000000
> Sep 15 14:59:31 localhost kernel:  printing eip:
> Sep 15 14:59:31 localhost kernel: 00000000
> Sep 15 14:59:31 localhost kernel: *pde = 00000000
> Sep 15 14:59:31 localhost kernel: Oops: 0000 [#1]
> Sep 15 14:59:31 localhost kernel: Modules linked in: ath_pci(U) wlan(U)
> ath_hal(U) tg3 sg scsi_mod snd_mixer_oss snd_ali5451 snd_ac97_codec
> snd_pcm snd_page_alloc snd_timer snd soundcore vmnet(U) vmmon(U)
> parport_pc lp parport autofs4 ds yenta_socket pcmcia_core sunrpc
> ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables microcode
> vfat fat dm_mod joydev ohci_hcd ehci_hcd button battery asus_acpi ac md5
> ipv6 ext3 jbd
> Sep 15 14:59:31 localhost kernel: CPU:    0
> Sep 15 14:59:31 localhost kernel: EIP:    0060:[<00000000>]    Tainted:
> P
> Sep 15 14:59:31 localhost kernel: EFLAGS: 00010206   (2.6.8-1.521)
> Sep 15 14:59:31 localhost kernel: EIP is at 0x0
> Sep 15 14:59:31 localhost kernel: eax: 26aa0000   ebx: 00000006   ecx:
> 00000000   edx: 02344458
> Sep 15 14:59:31 localhost kernel: esi: 257fee9c   edi: 272e0000   ebp:
> 272e0000   esp: 257fee80
> Sep 15 14:59:31 localhost kernel: ds: 007b   es: 007b   ss: 0068
> Sep 15 14:59:31 localhost kernel: Process modprobe (pid: 4638,
> threadinfo=257fe000 task=23c44d50)
> Sep 15 14:59:31 localhost kernel: Stack: 40abb059 26aa0000 40a9693e
> 26aa0000 272e0430 272e0000 00000013 00000000
> Sep 15 14:59:31 localhost kernel:        10000000 1d244b3c 00000000
> 0000000a 40a9d0c5 00000000 00000000 272e0000
> Sep 15 14:59:31 localhost kernel:        40a9dfe4 272e0000 272e0000
> 272e0006 3ff2c400 40a9c8b6 40a47000 98080000
> Sep 15 14:59:31 localhost kernel: Call Trace:
> Sep 15 14:59:31 localhost kernel:  [<40abb059>] ath_hal_detach+0x4/0x28
> [ath_hal]
> Sep 15 14:59:31 localhost kernel:  [<40a9693e>] ath_attach+0x93e/0x94f
> [ath_pci]
> Sep 15 14:59:31 localhost kernel:  [<40a9c8b6>]
> ath_pci_probe+0x226/0x2c6 [ath_pci]
> Sep 15 14:59:31 localhost kernel:  [<021df6cc>]
> pci_device_probe_static+0x2a/0x3d
> Sep 15 14:59:31 localhost kernel:  [<021df6fa>]
> __pci_device_probe+0x1b/0x2c
> Sep 15 14:59:31 localhost kernel:  [<021df726>]
> pci_device_probe+0x1b/0x2d
> Sep 15 14:59:31 localhost kernel:  [<0222cfeb>] bus_match+0x27/0x45
> Sep 15 14:59:31 localhost kernel:  [<0222d0b7>] driver_attach+0x37/0x6a
> Sep 15 14:59:31 localhost kernel:  [<0222d475>] bus_add_driver+0x77/0x97
> Sep 15 14:59:31 localhost kernel:  [<0222d88b>]
> driver_register+0x48/0x50
> Sep 15 14:59:31 localhost kernel:  [<0211f483>]
> release_console_sem+0x205/0x20b
> Sep 15 14:59:31 localhost kernel:  [<021df8d2>]
> pci_register_driver+0x84/0x9f
> Sep 15 14:59:31 localhost kernel:  [<408e0020>] init_ath_pci+0x20/0x4a
> [ath_pci]
> Sep 15 14:59:31 localhost kernel:  [<021385ab>]
> sys_init_module+0x1fd/0x2e5
> Sep 15 14:59:31 localhost kernel: Code:  Bad EIP value.

The crash shouldn't occur.  I guess it's potentially unsafe to call 
ath_hal_detach even when ath_hal_attach returns a reference to hal state (or 
appears to).  I could drop calling ath_hal_detach and potentially leak the 
memory I suppose but all previous testing has shown it's ok to do that.  LOL.

	Sam