On Wed, 2010-12-22 at 16:45 +0100, Piotr Isajew wrote:
> On Tue, Dec 21, 2010 at 10:40:48AM +0100, Filip Aben wrote:
> > In case you have USB selective suspend enabled, can you disable it and
> > run your test again ?
> I disabled it (power/control set to 'on' for all modems) and made
> some other tests.
>
> After digging deeper in logs I noticed that there is more
> XactErrs, but most of them recover in < 15 tries (does not depend
> on suspend setting). As far as I can check this, it doesn't
> depend on external environmental conditions. For all the modems I
> run the software, that, in test conditions, mostly does repetitive
> polling of the modem (i.e. issues AT+CREG?, then AT+CMGL=4, then
> 15 seconds sleep). When this software is run for 2 modems there
> are no XactErrs at all. If I run it for 16 modems I get
> XactErrs. I don't know the cause. Maybe it's bad USB controller
> (Intel 82801G), but I tested on NEC controller before, and it
> wasn't perfect either.
>
> I increased the number of XactErr retries and if it would recover
> automatically I could probably live with that, but I'm afraid
> that hso crashes after reattachment (one visible at the end of
> dmesg I sent previously) can leave system in unstable state.
>
If you're using a 2.6.36ish version, it's most likely the following in
hso_serial_open:
/* sanity check */
if (serial == NULL || serial->magic != HSO_SERIAL_MAGIC) {
WARN_ON(1);
tty->driver_data = NULL;
D1("Failed to open port");
return -ENODEV;
}
I suppose it's possible that the device is physically gone but the tty
hasn't been closed or torn down yet. Does it leave your system in an
unstable state ? Because it shouldn't.
Also, are you sure you're opening the correct port when the device
reappears and not some stale tty ?
Thanks,
Filip-
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
