Re: Airnic
jrobison-/[email protected]
| Newsgroups | gmane.linux.drivers.atmel-wlan |
|---|---|
| Message-ID | <[email protected]> |
The airnic I have uses the 503A chip(I took it appart) The driver I am using is 2.1.2.2 Thanks. Joe > Send Atmel-wlan-usb mailing list submissions to > atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://iprserv.jura.uni-leipzig.de/mailman/listinfo/atmel-wlan-usb > or, via email, send a message with subject or body 'help' to > atmel-wlan-usb-request-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > > You can reach the person managing the list at > atmel-wlan-usb-admin-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > > When replying, please edit your Subject line so it is more specific than > "Re: Contents of Atmel-wlan-usb digest..." > > > Today's Topics: > > 1. Re: usb-Atmel - Ad0-Hoc - ZyAIR B-200 - Wifi Link > OK, TCP/IP Link dead (Joerg Albert) > 2. Re: usb-Atmel - Ad0-Hoc - ZyAIR B-200 - Wifi Link OK, TCP/IP Link > dead (Joerg Mertin) 3. Re: Problem with TEW-USB WEP ? > (=?iso-8859-1?Q?Ingegno_di_Luca_Macci=F2?=) 4. Re: Problem with > TEW-USB WEP ? (Joerg Albert) > 5. Re: usb-Atmel - Ad0-Hoc - ZyAIR B-200 - Wifi Link > OK, TCP/IP Link dead (Joerg Albert) > 6. Re: Berlios driver and debian 2.4.20-i586-tsc (was > Re: Kernel error) (Florin Buzesteanu) > 7. Re: Re: Atmel-wlan-usb digest, Vol 1 #410 - 12 msgs (Joerg Albert) > 8. OOPS on startup (Jody Goldberg) > 9. Re: OOPS on startup (Joerg Albert) > > --__--__-- > > Message: 1 > Date: Sat, 12 Jul 2003 13:50:14 +0200 (CEST) > From: Joerg Albert <[email protected]> > To: atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > Subject: Re: [Atmel-WLAN-USB] usb-Atmel - Ad0-Hoc - ZyAIR B-200 - Wifi > Link > OK, TCP/IP Link dead > Reply-To: atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > > Hi Jörg, > > On Sat, 12 Jul 2003, Joerg Mertin wrote: > >> From my Networking Background - what I see is that the Sun-System has >> a >> weird setup. The iwconfig output gives me the mac address of the >> remote device - however the ifconfig shows the Mac address of the >> Local device. Seems like a proxy-Arping to me - but how am I supposed >> to configure a routing table into that ? > > iwconfig never displays the local MAC address under "Cell:". > It shows either the IBSS id choosen if it has started its own IBSS in > ad-hoc mode or the (I)BSS id joined if (a) in managed mode or (b) if it > had joined an already existing IBSS (i.e. if it was not the first STA > started for a given SSID in mode ad-hoc). > >> Note - that I can run the Prism3 based Wifi under Windows XP - and >> there is no difference in beheaviour at all - so I really think the >> problem is on the atmel-device side. > > Not necessarily. Old Prism2 firmware (you didn't post which one you use) > seems to have problems in ad-hoc mode - grep the lwlan-ng mailing lists. > I had a Prism2 PCMCIA card with 0.8.3 inside which (if it started the > IBSS first) sometimes decided to leave the IBSS by itself. > Windows driver might load newer fw versions into RAM on startup. > > Try starting both devices in a different order (AFAIR starting the > Atmel-USB first fixed my problem with the 0.8.3 Prism firmware - but I > used the Berlios driver). > > I'm of little help with the Sourceforge USB driver. > If you could get another Prism2/2.5/3 device you may use it in monitor > mode to trace the air traffic. > > /Jörg > > > > --__--__-- > > Message: 2 > Date: Sat, 12 Jul 2003 17:12:06 +0200 (CEST) > Subject: Re: [Atmel-WLAN-USB] usb-Atmel - Ad0-Hoc - ZyAIR B-200 - Wifi > Link OK, TCP/IP Link dead From: "Joerg Mertin" <[email protected]> > To: <atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org> > Cc: <[email protected]>, <[email protected]> > Reply-To: atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > > Hi Joerg, > > thx for the Hint. It's a prism3 card actually - from the following data: > usb.c: registered new driver prism2_usb > ident: nic h/w: id=0x8026 1.0.0 > ident: pri f/w: id=0x15 1.1.0 > ident: sta f/w: id=0x1f 1.4.2 > > The 0x8026 Identifies it as a prism 3 chip. > The Firmware version - I dojn't know which entry I have to use from > head. 1.1.0 or 1.4.2 ? Well - so it's a fairly new card. > > Regarding the IBSS - I figured it out. However - what I never saw > anywhere mentioned - is how do the BSSI need to be set for the Add-Hoc > mode to work, and how do the Mac-Addresses on the ofconfig call work. > > So - does the CELL-Entry has to look the same on both sides ? Or, in > case of a WiFi Link, do the devices exchange their IBSS's ? > How about the Mac-Addresses of the "Virtual" network devices ? Are these > also communicated to the remote side or not ? > > Could anyone here having a Working Add-Hoc config provide me the > iwconfig and ifconfig output of their 2 Endpoints ? This would help me a > lot. > > It's always hard to dig into something - when you don't know what it > should look like :) > > Joerg Albert said: >> Hi Jörg, >> >> On Sat, 12 Jul 2003, Joerg Mertin wrote: >> >>> From my Networking Background - what I see is that the Sun-System >>> has >>> a >>> weird setup. The iwconfig output gives me the mac address of the >>> remote device - however the ifconfig shows the Mac address of the >>> Local device. Seems like a proxy-Arping to me - but how am I supposed >>> to configure a routing table into that ? >> >> iwconfig never displays the local MAC address under "Cell:". >> It shows either the IBSS id choosen if it has started its own IBSS in >> ad-hoc mode or the (I)BSS id joined if (a) in managed mode or (b) if >> it had joined an already existing IBSS (i.e. if it was not the first >> STA started for a given SSID in mode ad-hoc). > > So - If I understood correctly - in case B here, Pandora had it's IBSS: > 02:A0:70:C0:63:CE - and when I tell my Atmel based device to connect it, > this one will copy the IBSS from Pandora to the Sun System, showing me > the same IBSS in the Cell line ... > So far - so good. got that one. > >>> Note - that I can run the Prism3 based Wifi under Windows XP - and >>> there is no difference in beheaviour at all - so I really think the >>> problem is on the atmel-device side. >> >> Not necessarily. Old Prism2 firmware (you didn't post which one you >> use) seems to have problems in ad-hoc mode - grep the lwlan-ng mailing >> lists. I had a Prism2 PCMCIA card with 0.8.3 inside which (if it >> started the IBSS first) sometimes decided to leave the IBSS by itself. >> Windows driver might load newer fw versions into RAM on startup. >> >> Try starting both devices in a different order (AFAIR starting the >> Atmel-USB first fixed my problem with the 0.8.3 Prism firmware - but I >> used the Berlios driver). > > Ohf - you're talking to an Old LInux guy here :) That was the third > thing I tried out ;) > BTW - does the Berlios Driver support the iwconfig from the wireless > tools ??? > The linux-wlan-ng has an own set of tools - and I do admit I do prefere > using the wireless-tools API. It's coping better into the ifconfig logic > :) > > >> I'm of little help with the Sourceforge USB driver. >> If you could get another Prism2/2.5/3 device you may use it in monitor >> mode to trace the air traffic. > > Actually - I do have a ZyAir B100 hanging around here. The Problem is > that I have only a very old subnotebook with a 486DX2-50MHz System - > and a very old Linux Redhat-6.1 Distribution runing on it. Maybe I'll > give it a try to compile the drivers etc. > > Thanx & Cheers > > Joerg > -- > ------------------------------------------------------------------------ > | Joerg Mertin : [email protected] (Home)| > | in Neuchâtel/Schweiz : | > | Stardust's LiNUX System : | > | PGP 2.6.3in Key on Demand : Voice & Fax: +41(0)32 / 725 52 54 | > ------------------------------------------------------------------------ > Home-Page: http://www.solsys.org > > > > --__--__-- > > Message: 3 > From: =?iso-8859-1?Q?Ingegno_di_Luca_Macci=F2?= <[email protected]> > To: <atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org> > Subject: Re: [Atmel-WLAN-USB] Problem with TEW-USB WEP ? > Date: Sat, 12 Jul 2003 17:23:18 +0200 > Reply-To: atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > > Hi Jörg > > I will be happy for test the version cvs version to 0.11beta3 with my > TEW-USB > > but I've not found it on web http://at76c503a.berlios.de/ where I've > download previous version 0.10. > > Send me a message with link or directly the file. > > Best regard's Luca. > > > ----- Original Message ----- > From: "Joerg Albert" <[email protected]> > To: <atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org> > Sent: Friday, July 11, 2003 10:55 PM > Subject: Re: [Atmel-WLAN-USB] Problem with TEW-USB WEP ? > > >> Hi Luca, >> >> On Tue, 8 Jul 2003, Luca Macciò wrote: >> >> > Hi Jörg, I've found my problem on at76c503.c for truncated 4 bits >> !!! >> > >> > I've corrected after line 2824 in function >> *check_for_rx_frags(struct at76c503 *dev) >> > where is a (length-4 ) when copy packet and than working OK ! >> > ... >> >> Seems like firmware 0.84.0 does not send the trailing FCS in rx data >> packets. I've updated the cvs version to 0.11beta3 which should handle >> this feature properly. Could you please try the cvs snapshot with your >> adapter? >> >> /Jörg >> >> _______________________________________________ >> Atmel-wlan-usb mailing list >> Atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org >> https://iprserv.jura.uni-leipzig.de/mailman/listinfo/atmel-wlan-usb >> > > --__--__-- > > Message: 4 > Date: Sat, 12 Jul 2003 18:27:19 +0200 (CEST) > From: Joerg Albert <[email protected]> > To: atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > Subject: Re: [Atmel-WLAN-USB] Problem with TEW-USB WEP ? > Reply-To: atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > > Hi Luca, > > On Sat, 12 Jul 2003, Ingegno di Luca Macciò wrote: > >> I will be happy for test the version cvs version to 0.11beta3 with my >> TEW-USB >> >> but I've not found it on web http://at76c503a.berlios.de/ where I've >> download previous version 0.10. >> >> Send me a message with link or directly the file. > > I was talking about the latest cvs snapshot at > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/at76c503a/at76c503a.tar.gz?tarball=1 > (0.11beta3 is not a released version). > > /Jörg > > > --__--__-- > > Message: 5 > Date: Sat, 12 Jul 2003 19:22:56 +0200 (CEST) > From: Joerg Albert <[email protected]> > To: atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > Subject: Re: [Atmel-WLAN-USB] usb-Atmel - Ad0-Hoc - ZyAIR B-200 - Wifi > Link > OK, TCP/IP Link dead > Reply-To: atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > > Hi Jörg, > > On Sat, 12 Jul 2003, Joerg Mertin wrote: > >> ident: nic h/w: id=0x8026 1.0.0 >> ident: pri f/w: id=0x15 1.1.0 >> ident: sta f/w: id=0x1f 1.4.2 > I was talking about the station fw - your 1.4.2 is fairly new. > >> Regarding the IBSS - I figured it out. However - what I never saw >> anywhere mentioned - is how do the BSSI need to be set for the Add-Hoc >> mode to work, and how do the Mac-Addresses on the ofconfig call work. >> >> So - does the CELL-Entry has to look the same on both sides ? Or, in >> case of a WiFi Link, do the devices exchange their IBSS's ? > > - BSS = basic service set = 2+ STA communicating > - IBSS = independent BSS = 2+ STA in ad-hoc mode > - ESS = extended service set = 1+ BSS connected by a distribtion > system (DS). Each BSS contains one access point which acts as a > STA (station) and connects the BSS to the DS. > > Each BSS has its own BSSID = MAC address like id. The BSSID of an IBSS > is marked as temporary (bit 43 set to 1) and is randomly choosen on each > start of the IBSS. The BSSID of a BSS created by an access point usually > is its normal MAC address. > > Furthermore each BSS has a service set ID (SSID) = a (normally > human readable) name of the IBSS/ESS. > > iwconfig always calls the SSID "essid" and the BSSID "Cell:". > > For ad-hoc mode, the "Cell:" entries must show the same addr. Be aware > that wlan-ng does not fully support the wireless extensions, i.e. using > iwconfig to obtain information may be broken. In my case iwconfig did > not show the correct "Cell:" id, I had to use their own tools > (wlanctl-ng/wlancfg ?). > > In ad-hoc mode the first STA started usually scans for the given SSID > and if it cannot find a IBSS with it, starts its own, choosing a random > BSSID and using the configure channel. The second STA scans as well and > find this IBSS. If this fails for any reason, it starts a second IBSS > and no communication is possible. > >> How about the Mac-Addresses of the "Virtual" network devices ? Are >> these also communicated to the remote side or not ? > What are "virtual" network devices? > >> Could anyone here having a Working Add-Hoc config provide me the >> iwconfig and ifconfig output of their 2 Endpoints ? This would help me >> a lot. > > no, sorry, have no running ad-hoc config here. But IMHO your setup looks > OK. I would: > - compare the Prism2's iwconfig output to the wlan tools' output > - try different start order > - run tcpdump in the background in case some data got corrupted > - check if ARP entries are received for the peer > - try broadcast pings > > /Jörg > > > --__--__-- > > Message: 6 > Date: Sat, 12 Jul 2003 21:19:25 +0200 > From: [email protected] (Florin Buzesteanu) > To: atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > Subject: Re: [Atmel-WLAN-USB] Berlios driver and debian 2.4.20-i586-tsc > (was > Re: Kernel error) > Reply-To: atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > > Hi Joerg, > > I got the problem under debian i have looked at the Makefile in the > Berlios drivers and have see that this: > ----------------------------------- > KERNEL_SRC = /lib/modules/$(KERNEL_VERSION)/build > KERNEL_HEADERS = $(KERNEL_SRC)/include > ----------------------------------- > > can not match on my System, so i have do an link with: > ----------------------------------- > ln -s /usr/src/linux /lib/modules/2.4.20-1-586tsc/build > ----------------------------------- > because the build directory is not there, and now the drivers work > perfect and since 2 days i have no kernel crash. > > so a very big thx for your help. > > /Florin > > > Joerg Albert wrote: > >>Hi Florin, >> >>On Tue, 8 Jul 2003, Florin Buzesteanu wrote: >> >> >> >>>router:~/# depmod -ae >>> >>>depmod: *** Unresolved symbols in >>>/lib/modules/2.4.20-1-586tsc/kernel/drivers/usb/at76c503-i3861.o >>> depmod: usb_deregister >>>depmod: usb_register >>>depmod: printk >>>... >>> >>>dont know if this are errors, hope not ;) >>> >>> >> >>These are errors: loading these modules will fail, because there >>external symbol references cannot be satisfied by the running kernel or >> some other modules, i.e. the problem you get later. >> >>Seems your kernel has symbol versioning, while the Makefile of >>the driver cannot see it. Either the sources don't match the running >> kernel or the Makefile is broken. Please post the output of: >> grep CONFIG_MODVERSIONS \ >> /lib/modules/`uname -r`/build/include/linux/autoconf.h >> grep printk /proc/ksyms >> >> >> >>>router:~/# grep usbdfu /proc/ksyms >>> >>>c59347dc usbdfu_register_R__ver_usbdfu_register [usbdfu] >>>c5934864 usbdfu_deregister_R__ver_usbdfu_deregister [usbdfu] >>> c5934914 usbdfu_in_use_R__ver_usbdfu_in_use [usbdfu] >>>c5934a68 usbdfu_initiate_download_R__ver_usbdfu_initiate_download >>> [usbdfu] c5934000 >>> >>> >> >>Wonder how you got the _R_ tail here. I don't know the settings of this >> debain kernel. What does a >> grep usbdfu_ <your kernel root dir>/include/linux/modules/* >>reveal? Did you compile your own kernel from these sources? >> >> >> >>>this are the berlios 0.10 driver have download the latest snapshot >>> from there but i can not compile it. >>> >>>get this error: >>> >>>---------------------------------------------- >>>router:~/at76c503a# make >>>gcc -MD -O2 -Wall -Wstrict-prototypes -pipe -fno-strict-aliasing >>> -fno-common -Wno-sign-compare -Wno-unused-variable -D__KERNEL__ >>> -DMODULE -DEXPORT_SYMTAB -DDRIVER_VERSION=\"v0.11beta2\" >>>-I/lib/modules/2.4.20-1-586tsc/build/include -c at76c503.c >>>cc1: Invalid option `-Wno-unused-variable' >>>make: *** [at76c503.o] Error 1 >>>---------------------------------------------- >>> >>> >>That option was introduced recently to suppress warnings of gcc 3.3 >> (the version SuSE 8.2 installs) while compiling kernel headers. >>What's your gcc version ("gcc --version")? >> >>IMHO the latest cvs snapshot won't fix the insmod problems above. >> >>/Jörg >> > > > --__--__-- > > Message: 7 > Date: Sat, 12 Jul 2003 21:54:13 +0200 (CEST) > From: Joerg Albert <[email protected]> > To: atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > Subject: Re: [Atmel-WLAN-USB] Re: Atmel-wlan-usb digest, Vol 1 #410 - 12 > msgs Reply-To: atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > > Hi Joel, > > On Sat, 12 Jul 2003 jrobison-/[email protected] wrote: > >> Hi all, >> I finnaly got my Airnic to work... kinda... >> the driver loads >> i can use scan and pick up the AP. >> the only broblem is i can never authenticate.. >> I think this is because for some off reason it is mis-reporting the >> MAC address. odd huh? >> is there a patch for this at all? >> the MAC it shows : A0:E3:08:10:80:E5 >> the MAC on the nic is: 00:30:1A:00:24:8C >> the MAC on the AP is : 00:80:C8:AD:19:E5 >> >> this is really odd... >> anyone got a clue as to why? > > Which version of the Sourceforge driver do you use? > > Which radio chipset did you assume? > Rumours are that the AirNic contains a Intersil 3861 radio set, i.e. you > must use snapshot 2002-12-09 (or older) and put your USB ids in the > correct array. > You may be able to check this assumption if you search for your FCC ID > at http://www.fcc.gov/oet/fccid/ > and look at the internal photos. > > /Jörg > > > --__--__-- > > Message: 8 > Date: Sat, 12 Jul 2003 16:25:11 -0400 > To: atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > From: Jody Goldberg <[email protected]> > Subject: [Atmel-WLAN-USB] OOPS on startup > Reply-To: atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > > > --opJtzjQTFsWo+cga > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > I've been trying the snapshots regularly for a while now under > 2.4.20. Things have gotten marginally better recently, only the > keyboard locks up now. Strangely the atmel driver did actually > mostly work a few months ago until I tried the berlios driver. Now both > are unhappy. > > Today I tried a nice fresh 2.4.21 + 0.11beta3 (July 12 snapshot) > with no appreciable change. > > Any insight on the attached oops ? > It corresponds to manually loading the rfmd drivers via modprobe and > plugging a netgear 101b into the usb slot of a sony vaio sr7 laptop. The > config is pretty vanilla, I've tried various combinations of > debug enabled/disabled with varying levels of lockup. > > --opJtzjQTFsWo+cga > Content-Type: text/plain; charset=us-ascii > Content-Disposition: attachment; filename="oops.txt" > > ksymoops 2.4.8 on i686 2.4.21. Options used > -V (default) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.21/ (default) > -m /boot/System.map-2.4.21 (default) > > Warning: You did not tell me where to find symbol information. I will > assume that the log matches the kernel and modules that are running > right now and I'll use the default options above for symbol resolution. > If the current kernel and/or modules do not match the log, you can get > more accurate output by telling me the kernel version and where to find > map, modules, ksyms etc. ksymoops -h explains the options. > > Jul 12 15:07:14 laptop kernel: Unable to handle kernel paging request at > virtual address 0060002b Jul 12 15:07:14 laptop kernel: cc84615c > Jul 12 15:07:14 laptop kernel: *pde = 00000000 > Jul 12 15:07:14 laptop kernel: Oops: 0000 > Jul 12 15:07:14 laptop kernel: CPU: 0 > Jul 12 15:07:14 laptop kernel: EIP: 0010:[<cc84615c>] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > Jul 12 15:07:14 laptop kernel: EFLAGS: 00013206 > Jul 12 15:07:14 laptop kernel: eax: 0060000f ebx: 00000000 ecx: > c123be9c edx: cba59d40 Jul 12 15:07:14 laptop kernel: esi: 000001f4 > edi: c123a000 ebp: c123be84 esp: c123be5c Jul 12 15:07:14 laptop > kernel: ds: 0018 es: 0018 ss: 0018 > Jul 12 15:07:14 laptop kernel: Process keventd (pid: 2, > stackpage=c123b000) Jul 12 15:07:14 laptop kernel: Stack: 000001f4 > cc84625a cba59d40 00000001 00000000 00000000 c123a000 00000000 Jul 12 > 15:07:14 laptop kernel: 00000000 00000023 c123be9c c123be9c > 00000000 00000000 00000000 c123a000 Jul 12 15:07:14 laptop kernel: > c123be84 c123be84 00000000 c87455c0 00000005 c9dd2a00 cc8463c3 > cba59d40 Jul 12 15:07:14 laptop kernel: Call Trace: [<cc84625a>] > [<cc8463c3>] [<cc84646b>] [<cc853bc0>] [<cc847281>] Jul 12 15:07:14 > laptop kernel: [<cc84a4b5>] [<cc88b75c>] [schedule+524/848] > [__run_task_queue+90/112] [context_thread+307/448] > [context_thread+0/448] Jul 12 15:07:14 laptop kernel: Code: 8b 40 1c 85 > c0 75 14 8d b6 00 00 00 00 8d bc 27 00 00 00 00 > > >>>EIP; cc84615c <[usbcore]usb_submit_urb+1c/40> <===== > >>>ecx; c123be9c <_end+f154d8/c51669c> >>>edx; cba59d40 <_end+b73337c/c51669c> >>>edi; c123a000 <_end+f1363c/c51669c> >>>ebp; c123be84 <_end+f154c0/c51669c> >>>esp; c123be5c <_end+f15498/c51669c> > > Trace; cc84625a <[usbcore]usb_start_wait_urb+7a/180> > Trace; cc8463c3 <[usbcore]usb_internal_control_msg+63/70> > Trace; cc84646b <[usbcore]usb_control_msg+9b/b0> > Trace; cc853bc0 <[usbcore]hub_event_lock+0/0> > Trace; cc847281 <[usbcore]usb_set_address+61/70> > Trace; cc84a4b5 <[usbcore]usb_reset_device+b5/350> > Trace; cc88b75c <[usbdfu]kevent+b0/148> > > Code; cc84615c <[usbcore]usb_submit_urb+1c/40> > 00000000 <_EIP>: > Code; cc84615c <[usbcore]usb_submit_urb+1c/40> <===== > 0: 8b 40 1c mov 0x1c(%eax),%eax <===== > Code; cc84615f <[usbcore]usb_submit_urb+1f/40> > 3: 85 c0 test %eax,%eax > Code; cc846161 <[usbcore]usb_submit_urb+21/40> > 5: 75 14 jne 1b <_EIP+0x1b> > Code; cc846163 <[usbcore]usb_submit_urb+23/40> > 7: 8d b6 00 00 00 00 lea 0x0(%esi),%esi > Code; cc846169 <[usbcore]usb_submit_urb+29/40> > d: 8d bc 27 00 00 00 00 lea 0x0(%edi,1),%edi > > > 1 warning issued. Results may not be reliable. > > --opJtzjQTFsWo+cga-- > > --__--__-- > > Message: 9 > Date: Sun, 13 Jul 2003 11:26:27 +0200 (CEST) > From: Joerg Albert <[email protected]> > To: atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > Subject: Re: [Atmel-WLAN-USB] OOPS on startup > Reply-To: atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > > Hi Jody, > > On Sat, 12 Jul 2003, Jody Goldberg wrote: > >> I've been trying the snapshots regularly for a while now under >> 2.4.20. Things have gotten marginally better recently, only the >> keyboard locks up now. Strangely the atmel driver did actually >> mostly work a few months ago until I tried the berlios driver. Now >> both are unhappy. >> >> Today I tried a nice fresh 2.4.21 + 0.11beta3 (July 12 snapshot) with >> no appreciable change. >> >> Any insight on the attached oops ? >> It corresponds to manually loading the rfmd drivers via modprobe and >> plugging a netgear 101b into the usb slot of a sony vaio sr7 laptop. >> The config is pretty vanilla, I've tried various combinations of debug >> enabled/disabled with varying levels of lockup. > >>From your oops it looks like the kernel crashes in > usb.c:usb_submit_urb() when it tries to access the urb->dev->bus->op and > urb->dev->bus == 0x60000f. > > I wasn't able to reproduce this error here with 2.4.21 and 0.11beta3. > Tried usb-uhci,uhci and ohci both with and w/o external hubs. > Are you using ehci? > > /Jörg > > > > --__--__-- > > _______________________________________________ > Atmel-wlan-usb mailing list > Atmel-wlan-usb-ikZNBd7uB5wQUIZIPwn63sWURRETrGNnG9Ur7JDdleE@public.gmane.org > https://iprserv.jura.uni-leipzig.de/mailman/listinfo/atmel-wlan-usb > > > End of Atmel-wlan-usb Digest