From owner-freebsd-current@FreeBSD.ORG Sun May 17 19:53:46 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 B6385106567C; Sun, 17 May 2009 19:53:46 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6E97E8FC1E; Sun, 17 May 2009 19:53:46 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n4HJrj91035207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 May 2009 12:53:46 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A106B49.4020809@freebsd.org> Date: Sun, 17 May 2009 12:53:45 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: Lucius Windschuh References: <20090407022956.GA71377@weongyo.cdnetworks.kr> <90a5caac0905161502x3771072n22d58111a235de24@mail.gmail.com> <4A0F419A.2020700@freebsd.org> <90a5caac0905171218r6de3473le8edcac3dab7e2bb@mail.gmail.com> In-Reply-To: <90a5caac0905171218r6de3473le8edcac3dab7e2bb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist 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:53:49 -0000 Lucius Windschuh wrote: > 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. > > No problem; just trying to clarify since the history of this driver is complicated. >>> 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 >>> =================================================================== >>> --- sys/dev/usb/usbdevs (revision 192196) >>> +++ sys/dev/usb/usbdevs (working copy) >>> @@ -2425,6 +2425,7 @@ >>> product UMEDIA ALL0298V2 0x3204 ALL0298 v2 >>> product UMEDIA AR5523_2 0x3205 AR5523 >>> product UMEDIA AR5523_2_NF 0x3206 AR5523 (no firmware) >>> +product UMEDIA AR5523_3 0x3207 AR5523 >>> >>> /* Universal Access products */ >>> product UNIACCESS PANACHE 0x0101 Panache Surf USB ISDN Adapter >>> Index: sys/dev/usb/wlan/if_uath.c >>> =================================================================== >>> --- sys/dev/usb/wlan/if_uath.c (revision 192196) >>> +++ sys/dev/usb/wlan/if_uath.c (working copy) >>> @@ -192,6 +192,7 @@ >>> UATH_DEV(NETGEAR3, WPN111), >>> UATH_DEV(UMEDIA, TEW444UBEU), >>> UATH_DEV(UMEDIA, AR5523_2), >>> + UATH_DEV(UMEDIA, AR5523_3), >>> UATH_DEV(WISTRONNEWEB, AR5523_1), >>> UATH_DEV(WISTRONNEWEB, AR5523_2), >>> UATH_DEV(ZCOM, AR5523) >>> >>> I don't know why this device has another product ID with a loaded firmware, >>> 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. > Ok, r192258. > >>> 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) >>> ugen4.2: at usbus4 >>> (uathload) >>> ugen4.2: at usbus4 (disconnected) >>> ugen4.2: at usbus4 >>> (ifconfig wlan create wlandev uath0) >>> wlan0: Ethernet address: 00:14:d1:c0:23:5f >>> (ifconfig wlan0 up) >>> uath0: uath_cmdsend: empty inactive queue >>> uath0: could not init Tx queues, error 55 >>> uath0: uath_cmdsend: empty inactive queue >>> uath0: could not set channel, error 55 >>> [...] >>> uath0: could not set channel, error 55 >>> uath0: uath_cmdsend: empty inactive queue >>> uath0: could not write register 0x08 >>> uath0: uath_cmdsend: empty inactive queue >>> uath0: could not set channel, error 55 >>> uath0: could not switch channel >>> I'd like to provide additional debugging information. If you need more, >>> please tell me what. >>> >> Known problem. Weongoy 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. > Great, thank you; committed as r192257 w/ a slight tweak. > >>> BTW: Could you add a message declaring the device when it is plugged in? >>> Something like "uath0: on usbus?" >>> 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@. > > I saw your other post; looks like it's outside net80211 so will let someone else handle it. Sam