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

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.

>> 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.

>>
>> 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.

>> 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_.

Lucius