To be able to reproduce this bug a bit easier, i added usbautosuspend to ath9k_htc. There is some interesting statistic of power usage for now: ar9271: • power on + wifi on = 160 uA • "ifconfig wlan0 down" without autosuspend = 60 uA • "ifconfig wlan0" down with autosupend = 1,6 uA
Current problem is to bring adapter back. Am 17.05.2013 20:51, schrieb Oleksij Rempel: > Am 17.05.2013 17:37, schrieb Adrian Chadd: >> On 17 May 2013 05:00, Oleksij Rempel <li...@rempel-privat.de> wrote: >> >>>>>> here is a workaround for this issue, please test it: >>>>>> https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend >>>>> >>>>> It seems to work just right on the PC. I'll test on the RPi and let you >>>>> know. >>>> >>>> Works on the RPi as well! Are there any implications for this being a >>>> workaround and not a proper fix? >>> >>> Yes, i do not know what i did. I will need to find out, what it actually >>> should do. >> >> ... hm, is this reset type not working? Is this the whole "reset >> through watchdog" versus "reset through reset" thing you talked about >> a couple weeks ago? > > No, it is different issue, at least at different path. > I did some more test and i'll try now to reflect all collected informations: > - Only ar9271 devices are affected. ar7010 seems to be fine. > - the issue is in: > target_firmware/magpie_fw_dev/target/hif/k2_fw_usb_api.c: > in _fw_usb_suspend_reboot() > > this function is called from two points: > - _fw_usbfifo_recv_command(), this one is triggered if host go to supend > - _fw_usb_fw_task(), this function is called on different events, > including reset, some cases if suspend? and resume? last was never > called. I'll need to check how exactly this part is working. > > So, _fw_usb_suspend_reboot() should theoretically prepare adapter for > suspend, to reduce power consumption. But there are fallowing problems > with this function: > - some hosts will completely power down this device. Absolutely no power > is consumed and all preparations made by this function are lost (cald > reset). > - some hosts keep usb port powered to be able to charge some device. It > is done only on laptops/pcs connected to power supply (i have one of > this, so i was able to check it). In this case we go to some undefined > state, and probably prepared to receive firmware. In this state device > use about 40mA. > - in all cases linux will do reset on resume. So all side effects > produced by _fw_usb_suspend_reboot() are reseted. This is why it is so > hard to reproduce this case. > > The problem what we now have is passed from _fw_usb_fw_task(), in this > case adapter will restart to boot loader and got ready to receive > firmware. But it looks like usb descriptor in this case is incomplete: > > here is brocken descriptor: > Bus 003 Device 002: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 255 Vendor Specific Class > bDeviceSubClass 255 Vendor Specific Subclass > bDeviceProtocol 255 Vendor Specific Protocol > bMaxPacketSize0 64 > idVendor 0x0cf3 Atheros Communications, Inc. > idProduct 0x9271 AR9271 802.11n > bcdDevice 1.08 > iManufacturer 16 > iProduct 32 > iSerial 48 > bNumConfigurations 1 > ---end--- > > > here is ok descriptor: > > Bus 003 Device 003: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 255 Vendor Specific Class > bDeviceSubClass 255 Vendor Specific Subclass > bDeviceProtocol 255 Vendor Specific Protocol > bMaxPacketSize0 64 > idVendor 0x0cf3 Atheros Communications, Inc. > idProduct 0x9271 AR9271 802.11n > bcdDevice 1.08 > iManufacturer 16 ATHEROS > iProduct 32 UB91C > iSerial 48 12345 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 60 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x80 > (Bus Powered) > MaxPower 500mA > --- and some more -------- > > > after i disabled this function... see my workaround patch. I got > fallowing process. Host send suspend command.... no changes was made, > (currently i do not know what should we send as response), host trying > to send it some more times and the send reset. After this, adapter is > rebooting and firmware is uploaded... so it comes to normal working state. > > There is no way to support WoW here. So, there is no need to have some > sort of reduced power state. I assume, we can remove most part of > suspend sequence from firmware. And replace it with some correct > response to the host that every thing is ok, or that we do not support > this bit. > -- Regards, Oleksij _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
