On Wednesday, September 14, 2011 03:09:14 PM J Igrap wrote: > On Wed, Sep 14, 2011 at 5:50 AM, Christian Lamparter >> On Tuesday, September 13, 2011 11:18:23 PM J Igrap wrote: >>> While using the past days the carl9170 firmware with a USB card under a >>> linux guest running different kernel and driver versions I kept running into >>> the issue of a usb disconnect when the card was put under load: >> linux guest? You are not using carl9170 in a VM, are you? >> > It is in a VM. I was working on a VM for ease of debugging the issue. So, I presume you have already tried running the driver natively and it fails in a similar fashion, right? [I just want to rule out a bug in the VM layers] >>> usb 1-1: no command feedback received (-110). >>> carl9170 cmd: 08 01 00 00 f0 36 1c 00 00 24 00 00 .....6...$.. >>> usb 1-1: restart device (6) >>> >>> No matter what kernel driver/firmware I tried I will still get it. I decided >>> to look into it a bit more and I narrowed it down to be a firmware issue >>> with the following code snippet: >> Or it could be a problem with the USB PHY. However, the driver >> seems to be able to handle the situation and restarts the device >> accordingly. >> > I tried with several physical devices and they all seemed to have the > same behavior. The device does restart however you lose connectivity > and state of what you were doing. Any transmission protocol should be able to handle loss of connectivity. Furthermore all connection managers [wpa_supplicant, NetworkManager, wicd] will automatically reestablish the link if the device was put out by a catastrophic failure. >>> void handle_cmd(struct carl9170_rsp *resp) in src/cmd.c >>> >>> case CARL9170_CMD_WREG: >>> esp->hdr.len = 0; >>> for (i = 0; i < (cmd->hdr.len / 8); i++) >>> set(cmd->wreg.regs[i].addr, cmd->wreg.regs[i].val); >>> break; >>> >>> That code appears to handle event 1 which is a write into a register. In >>> some cases that write appeared to cause a failure and a reset into the card. >>> I added a simple delay loop before the switch statement and that seemed to >>> fix the issue and I don't lose the card anymore even under a lot of load. >>> Obviously that's not a real fix and something else more reliable needs to be >>> in place. >> Any idea what this "something" else might be? > > I'm not very familiar with how USB works, maybe someone with more > experience can shed some light here? It seems to me that the event > handling needs to be slowed down a little or add some kind of > verification. the usb protocol already incorporates some verification http://www.beyondlogic.org/usbnutshell/usb3.shtml furthermore, the driver counts each command frame, therefore it can detect whenever a frame was lost. Regards, Chr -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
