I did experience this problem before, when the E220 first came on the market. It was caused by hald firing off an application that probed the virtual CDROM device.
I worked around it initially by adding a blacklist to the hald rules (which I see is included in the default rules now, and in the installed Ubuntu, so it is not the problem now).
Since the device is still blacklisted, I have no idea where the probe is coming from now. I am also not sure why the kernel issues a device reset when the ioctl generates an error, but I think this is wrong.
There was also a patch at some stage that prevented usbstorage from detecting the Huawei device, which also solved the problem.
For now, the only way I have network access is to revert to the 2.6.31.11 kernel, and use usbserial, instead of the option driver.
These are exactly the symptoms I am experiencing.
I upgraded to 2.6.31-14 #48 to work around bug #406312. After the update, my modem would continuously reset.
As part of my testing, I blacklisted the option module. The modem still resets, and this is the log that always precedes the reset:
[ 228.378573] sr1: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00 20 00
I did experience this problem before, when the E220 first came on the market. It was caused by hald firing off an application that probed the virtual CDROM device.
I worked around it initially by adding a blacklist to the hald rules (which I see is included in the default rules now, and in the installed Ubuntu, so it is not the problem now).
Since the device is still blacklisted, I have no idea where the probe is coming from now. I am also not sure why the kernel issues a device reset when the ioctl generates an error, but I think this is wrong.
There was also a patch at some stage that prevented usbstorage from detecting the Huawei device, which also solved the problem.
For now, the only way I have network access is to revert to the 2.6.31.11 kernel, and use usbserial, instead of the option driver.