From owner-freebsd-current@FreeBSD.ORG Sun May 17 19:18:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6AA4106566B; Sun, 17 May 2009 19:18:15 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 4BDC98FC12; Sun, 17 May 2009 19:18:14 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by yw-out-2324.google.com with SMTP id 9so1735454ywe.13 for ; Sun, 17 May 2009 12:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=buGNP3cMvwRIhUMX6R3ehLFNa3cY8VDinqcra9TXQ1g=; b=N4kgIXPXWUJ74qpAODdpCHdlXmj5wH7spv9Stt9nurAerVN/gjtCWDkiEYrzl85i28 rOyr74oLDJcVvjy7EE5HtRxpdmedsBAyld90mV4vyMx5uX2X++/O814eUPOo4EQkB8GS QaBAjB0mJEt7He5kEkKwWautHEf7cefvgXFls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Nt+yvv1rLydNs2q49D7T6iyx0T1nHAk+rp+Hztg1DQWIB3OIGtQpTvI49QdlFnczzl XVrwtrVTAWCiRNYrk2cDKLNAeLRNTGGSsbs+lZKew9/55+1xn2UFHyGmJMSMzBccBZwa 1Rtnf5eHbZ8DlAfyjMsMkRuD6rO5ooX1p3we4= MIME-Version: 1.0 Received: by 10.151.155.8 with SMTP id h8mr10627414ybo.308.1242587894510; Sun, 17 May 2009 12:18:14 -0700 (PDT) In-Reply-To: <4A0F419A.2020700@freebsd.org> References: <20090407022956.GA71377@weongyo.cdnetworks.kr> <90a5caac0905161502x3771072n22d58111a235de24@mail.gmail.com> <4A0F419A.2020700@freebsd.org> Date: Sun, 17 May 2009 21:18:14 +0200 Message-ID: <90a5caac0905171218r6de3473le8edcac3dab7e2bb@mail.gmail.com> From: Lucius Windschuh To: Sam Leffler Content-Type: multipart/mixed; boundary=0015175707f40df55e046a208abc Cc: Weongyo Jeong , current@freebsd.org Subject: Re: HEADSUP: uath(4) has been committed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 19:18:15 -0000 --0015175707f40df55e046a208abc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2009/5/17 Sam Leffler : > Lucius Windschuh wrote: >> Thanks for porting the driver. > This is not a port of anyone else's driver. Sorry, my fault. I saw the comment in if_uath.c, but Damien's driver is very different, you are right. >> I tried it with a TRENDnet TEW-504UB/EU on CURRENT as of today. >> But there are a couple of problems with that device: >> 1. Different product ID >> My TEW-504UB/EU becomes 0x3207 after loading the firmware. OK, this one = is >> easy to fix: >> Index: sys/dev/usb/usbdevs >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- sys/dev/usb/usbdevs (revision 192196) >> +++ sys/dev/usb/usbdevs (working copy) >> @@ -2425,6 +2425,7 @@ >> =A0product UMEDIA ALL0298V2 0x3204 ALL0298 v2 >> =A0product UMEDIA AR5523_2 0x3205 AR5523 >> =A0product UMEDIA AR5523_2_NF 0x3206 AR5523 (no firmware) >> +product UMEDIA AR5523_3 0x3207 AR5523 >> >> =A0/* Universal Access products */ >> =A0product UNIACCESS PANACHE 0x0101 Panache Surf USB ISDN Adapter >> Index: sys/dev/usb/wlan/if_uath.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- sys/dev/usb/wlan/if_uath.c (revision 192196) >> +++ sys/dev/usb/wlan/if_uath.c (working copy) >> @@ -192,6 +192,7 @@ >> =A0 UATH_DEV(NETGEAR3, WPN111), >> =A0 UATH_DEV(UMEDIA, TEW444UBEU), >> =A0 UATH_DEV(UMEDIA, AR5523_2), >> + UATH_DEV(UMEDIA, AR5523_3), >> =A0 UATH_DEV(WISTRONNEWEB, AR5523_1), >> =A0 UATH_DEV(WISTRONNEWEB, AR5523_2), >> =A0 UATH_DEV(ZCOM, AR5523) >> >> I don't know why this device has another product ID with a loaded firmwa= re, >> but perhaps because it is an 802.11a capable device? > > The device works by changing identity once the firmware is downloaded. > One id is for the stick w/o fw and one for the stick w/ fw loaded and > running. I was a bit unclear, but what I meant to say: My device uses a different product ID in warm state (0x3207) than what the driver expects (0x3205). Interestingly, when booting the vendor's driver, the warm product ID is 0x3205. Anyway, with the extra ID, it works. >> >> So, now to the second problem: >> The device works like a charm in 802.11b/g mode (ifconfig wlan0 chanlist >> 1-13) with FreeBSD's firmware. >> But 802.11a scanning does not work. Without the chanlist restrictiong, I= get >> the following messages: >> (plug in the device) >> =A0 ugen4.2: at usbus4 >> (uathload) >> =A0 ugen4.2: at usbus4 (disconnected) >> =A0 ugen4.2: at usbus4 >> (ifconfig wlan create wlandev uath0) >> =A0 wlan0: Ethernet address: 00:14:d1:c0:23:5f >> (ifconfig wlan0 up) >> =A0 uath0: uath_cmdsend: empty inactive queue >> =A0 uath0: could not init Tx queues, error 55 >> =A0 uath0: uath_cmdsend: empty inactive queue >> =A0 uath0: could not set channel, error 55 >> =A0 [...] >> =A0 uath0: could not set channel, error 55 >> =A0 uath0: uath_cmdsend: empty inactive queue >> =A0 uath0: could not write register 0x08 >> =A0 uath0: uath_cmdsend: empty inactive queue >> =A0 uath0: could not set channel, error 55 >> =A0 uath0: could not switch channel >> I'd like to provide additional debugging information. If you need more, >> please tell me what. > > Known problem. =A0Weongoy didn't have a dual-band stick and I never had > time to track down why 5Ghz channels failed. Set OFDM instead of no modulation when setting the 802.11a channel... See the attached mini patch. >> BTW: Could you add a message declaring the device when it is plugged in? >> Something like "uath0: on usbu= s?" >> and "uath0: ether aa:bb:cc:dd:ee:ff"? > > I thought it did this but perhaps not; we can try to add it. That would be nice. Unfortunately, I can provoke 3 different panics when detaching the running device. But this is sometimes mixed with data corruption on device removal -- on two different machines. I still have no clue which kernel part is guilty. More in a different mail to current@. Lucius --0015175707f40df55e046a208abc Content-Type: application/octet-stream; name="uath-11a-ofdm.patch" Content-Disposition: attachment; filename="uath-11a-ofdm.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fuu456340 SW5kZXg6IHN5cy9kZXYvdXNiL3dsYW4vaWZfdWF0aC5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYv dXNiL3dsYW4vaWZfdWF0aC5jCShyZXZpc2lvbiAxOTIxMDgpCisrKyBzeXMvZGV2L3VzYi93bGFu L2lmX3VhdGguYwkod29ya2luZyBjb3B5KQpAIC0xNDkyLDcgKzE0OTMsNyBAQAogCWlmIChJRUVF ODAyMTFfSVNfQ0hBTl81R0haKGMpKQogCQlyZXNldC5mbGFncyB8PSBodG9iZTMyKFVBVEhfQ0hB Tl81R0haKTsKIAkvKiBOQjogMTFnID0+J3MgMTFiIHNvIGRvbid0IHNwZWNpZnkgYm90aCBPRkRN IGFuZCBDQ0sgKi8KLQlpZiAoSUVFRTgwMjExX0lTX0NIQU5fRyhjKSkKKwlpZiAoSUVFRTgwMjEx X0lTX0NIQU5fRyhjKSB8fCBJRUVFODAyMTFfSVNfQ0hBTl9BKGMpKQogCQlyZXNldC5mbGFncyB8 PSBodG9iZTMyKFVBVEhfQ0hBTl9PRkRNKTsKIAllbHNlIGlmIChJRUVFODAyMTFfSVNfQ0hBTl9C KGMpKQogCQlyZXNldC5mbGFncyB8PSBodG9iZTMyKFVBVEhfQ0hBTl9DQ0spOwo= --0015175707f40df55e046a208abc--