It would be good to know what the default 'delay_use' is on 12.04 and what it was on *previous* Ubuntu versions.

Originally, this was set to 5 seconds in the storage driver, with SCSI hard disks in mind. This may have been changed in the kernel as the main users of the driver nowadays are flash drives.
There may be modems around that need to be ready for use before the "eject" command (no matter if coming from usb_modeswitch or from the command line tool) can actually trigger the mode switch. Others are less critical in that respect.

Owners of this device:
Can you play around with the storage module option, from delay_use=1 to delay_use=5 ?

There is a small delay implemented in the usb_modeswitch wrapper which could be skipped. There is also a config option "WaitBefore=<seconds>" that can be set per device config.

So a longer delay of usb_modeswitch's actions will *not* be a problem if that helps. On the other hand, removing any delay will gain just half a second and probably break other devices.

In a nutshell:
If the default delay_use is too *short* for the Nokia devices, there is very little (500 ms) that can be done.
If the default delay_use is too *long*, just play around with the "WaitBefore" value.

The five-second delay can be rather annoying, and makes the system
appear much less responsive when you connect a USB drive.

It's also not entirely clear that it is needed - the settling delay has
at least historically been an issue on some Apple iPods, for example,
and some devices have been reported to need even more than the old 5s
delay.

But before we penalize them all, let's see how bad it really is. Some
of the reasons for long delays seem to be actual historical kernel bugs
that should probably never have been papered over with a delay in the
first place (there's a Ubuntu bug report for 2.6.20 about a NULL pointer
dereference unless 'delay_use' is 8 or more, for example).

It also looks like some distros have already shipped with delay_use=0,
so the five second default may well be totally historical.

In other words: "Let's see if anybody screams".

Signed-off-by: Linus Torvalds <email address hidden>

which appeared in Ubuntu v2.6.34, but Ubuntu 11.10 contained a 3.0.0 kernel...

@Marius: yes, please open a bug upstream and/or report the issue on the linux kernel mailing list, it is a good thing to do.

Also, it would be useful to know when this started to happen (which kernel version), people affected here can download kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/ and test which version started to show up this issue. So far the greater delay_use helps, but needs investigation (since as reported here 11.10, with 3.0 kernel, worked fine, even with the default delay_use=1).

To sum up, a CS-15 with an "original" firmware (x.62.40) does not work anymore even in current Lucid Lynx (some kind of a regression). CS-15 with updated firmware works in Lucid and Precise, but is unstable, and do not work in Quantal (live session) at all.

I just get a hang of running my nokia internet stick cs-15 (firmware r2.8) on ubuntu 12.04. I removed the module ums_realtek from memory, and insert my cs-15 in usb port, and then it worked (not flashed before).
I searched the usb_storage module:

Glome, could you please confirm this issue exists with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ . If the issue remains, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc4

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

There seems to be different kinds of CS-15 modems out there. For two of my devices lsusb -v gives
"wMaxPacketSize 0x0040 1x 64 bytes" for a modem with bigger IMEI
and
"wMaxPacketSize 0x0200 1x 512 bytes" for a modem with smaller IMEI.

The differences in behaviour with some current kernels can be found in reported bug #496256 in comment #60.