Re: HEADSUP: uath(4) has been committed.

Lucius Windschuh wrote:
> 2009/5/17 Sam Leffler <sam_at_freebsd.org>:
>   
>> 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)
>>> _at__at_ -2425,6 +2425,7 _at__at_
>>>  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)
>>> _at__at_ -192,6 +192,7 _at__at_
>>>   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: <Atheros Communications Inc> at usbus4
>>> (uathload)
>>>   ugen4.2: <Atheros Communications Inc> at usbus4 (disconnected)
>>>   ugen4.2: <Atheros Communications Inc> 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: <TRENDnet TEW-504UB wireless LAN adaptor> 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_at_.
>
>   

I saw your other post; looks like it's outside net80211 so will let 
someone else handle it.

    Sam