SV: [Madwifi-users] ath_hal_attach segfaults on IXDP425
Status: Beta
Brought to you by:
otaku
From: Lie, M. <mar...@wr...> - 2004-05-22 19:22:14
|
Just wanted to inform you that I have the wireless driver up and running, and that the reason for causing all the trouble is in the Intel IXP425 architecture implementation of ioremap() (kernel 2.4.24). It seems that the ioremap()-function returns the physical address when an address within the PCI memory range is specified, and the virtual address is returned when outside. By always returning the virtual address, the driver did not segfault (although just removing the 'if' is no permanent solution..., but I don't have any other PCI targets on the bus in this specific system so it is a solution for now). Here is the function from linux-2.4.x/include/asm-arm/arch-ixp425/io.h: static inline void * __arch_ioremap(unsigned long phys_addr, size_t size, unsigned long flags) { extern void * __ioremap(unsigned long, size_t, unsigned long); if((phys_addr < 0x48000000) || (phys_addr > 0x4bffffff)) return __ioremap(phys_addr, size, flags); return (void *)phys_addr; } By always returning the value of __ioremap(), the driver loads ok. I am not sure if this is a driver subject or a flaw that one must live aside with on the IXP425? The discussion on this subject may be found under: http://lists.arm.linux.org.uk/pipermail/linux-arm/2003-November/6526 Look for IXP425 and PCI (several subjects). The segfault experienced earlier complained about paging request to virtal address that do not exist (it is the physical address showing up in the segfault). I have compiled the driver with the arm-linux- binutils and gcc. I do, however, get another error when running the driver, although my guess is that this has nothing to do with the driver itself, but merely other subsystems or the wireless extensions: # iwconfig ath0 ath0 (WE) : Buffer for request 8B0B too small (0<564) Any ideas? - Martin -----Opprinnelig melding----- Fra: Sam Leffler [mailto:sa...@er...] Sendt: 5. mai 2004 15:30 Til: mad...@li... Kopi: Lie, Martin Emne: Re: [Madwifi-users] ath_hal_attach segfaults on IXDP425 On Wednesday 05 May 2004 04:39 am, Lie, Martin wrote: > Hello, > > I am experiencing some troubles when insmod'ing ath_pci on my Intel > IXDP425 board. I am running Snapgear 3.1.1 and Atheros 5212 running on > a miniPCI board and loading segfaults like this: <...stuff snipped...> > It seems that a call to ath_hal_attach() in if_ath.c is the > showstopper. I have tried all available versions of the xscale-be-elf > with the same result. I have also tried a different miniPCI-card with > the same chipset, but with no luck. > > Does anyone have some suggestions on how I could resolve this? Many of the hal builds are not "maintained" because we don't have the resources. That is to say, these builds were known to work on at least one platform at one time but since that time they are just mechanically built with each new release. Those builds that are/were known to work should have the specific processor model and/or board identified in the .inc file in the hal/linux directory. The xscale-be build was tested on this exact board I believe (I note however that info is not in the .inc file). In general getting things working on embedded platforms can be painful. You often must use precisely the same toolchain and compilation options when building the hal and kernel/driver to get things to work. This is why the hal .inc files have complete info about how the hal binary was built. Embedded platforms sometimes require special glue code to access registers in the hardware and the distributed code in linux/ah_osdep.? is insufficient (that code assumes a strict memory-mapped i/o model). If I had to guess I'd say you have a toolchain compatibility problem. Sam ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Madwifi-users mailing list Mad...@li... https://lists.sourceforge.net/lists/listinfo/madwifi-users |