USB device insertion causes total system lockup on Ubuntu 9.10

[phickel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 affects udev

 affects hotplug

 affects ubuntu 9.10

On two separate systems I have upgraded from 9.04 to 9.10 I get a
complete, immediate and total system lockup when I install a specific
device in a USB port. The device is an AT&T Quicksilver GSM/HSDPA
Cellular modem, on 8.10 and 9.04 systems, lsusb shows the device as "Bus
002 Device 006: ID 0af0:d033 Option".

On 8.10 and 9.04 systems the device initially shows up as a CDROM
containing the driver and application software needed on an MS Windows
box. There is a linux package ( Ozerocdoff found at
http://pharscape.org/Quicksilver.html ) from the real device
Manufacturer "Option" which uses udev to disable this "zerocd" and then
the Option Cellular Modem appears which works with the linux hso kernel
module. On a 9.10 system with or without Ozerocdoff installed I get
the lockup even before the CDROM or Modem appears or is logged.

The device worked fine in the same systems before the 9.04 to 9.10
upgrade. Other USB devices work fine under 9.04 and 9.10. I have not
yet tried on a fresh 9.10 install only 9.04 to 9.10 upgrades.

The lockup is immediate and total. The only way I have found to
regain access to the systems is to remove the device, then do a hard
power cycle.

I cannot identify or recover any meaningful details from the log files
in /var/log.

I would appreciate any clues on how I can capture better debug
information on this situation. The immediate and total system lockup
has me stumped for where to go from here. I do realize the above is
insufficient to work with, I am asking for how to capture better
information for a proper bug report.

Thank you;

Patrick Hickel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrt7YcACgkQGcFsRP9ZxTqsmQCfW99eDBuSwZKd1NWfnrdr9NZu
/KcAnA86BvzDb0k78zJvnfQOIH1e4ia8
=Q/Vp
-----END PGP SIGNATURE-----

[phickel (pat-hickel)]

Finally got a chance to come back to this. After swapping in a freshly wiped disk ( mke2fs -c -c ), I then did a total clean default Ubuntu 9.10 Desktop i386 install. So I am absolutely sure I am starting with a totally clean base. I wanted this because the two systems I worked with previously were both 9.04 to 9.10 upgrades as opposed to new clean installs.
So this time I know for sure there is nothing accidently carried forward through the upgrade process.

At this point I opened a terminal window and did "cd /var/adm ; tail -f messages" and left it running.

I then plugged the Option/AT&T Quicksilver GSM modem into the USB port.

My terminal window captured 10 new lines of /var/adm/messages after the device was inserted but before the system locked up and had to be power cycled. I had to hand write them on paper to save them for entry here, so please forgive any minor transcription errors.

usb 1-5: USB disconnect, address 5
usb 1-5: new high speed USB device using ehci_hcd and address 9
usb 1-5: configuration #1 chosen from 1 choice
scsi 4: SCSI emulation for USB Mass Storage devices
usb 1-5: USB disconnect, address 9
hso: /build/buildd/linux-2.6.31/drivers/net/usb/hso.c: 1.2 Option Wireless
usbcore: registered new interface driver hso
usb 1-5: new high speed USB device using ehci_hcd and address 10
usb 1-5: configuration #1 chosen from 1 choice
hso0: Disabled Privacy Extensions

So it would appear the system is actually recognizing the initial ZeroCD function correctly, then correctly disconnects the ZeroCD device, and then somehow hands off to the hso driver to disable the ZeroCD and then re-registers the device as a new interface tied to the hso driver, at some point after the hso driver disables the Privacy Extensions I got the expected total system lockup.

Hopefully, this will provide a clue to someone.

[phickel (pat-hickel)]

I have pretty much come to the conclusion this is a udev problem. The only way the hso driver could have been called into play to replace SCSI emulation for USB on the ZeroCD is via a udev action, and this udev action is clearly where the breakage is located.

Done properly the ZeroCD in the Option/AT&T Quicksilver 3G Modem should be disabled long before SCSI emulation for USB is invoked. For a working example of how this should be performed see the Ozerocdoff package at http://pharscape.org/Quicksilver.html. The readme file in the tarball is quite informative as to how and when disabling the ZeroCD should be performed by udev and why it must be done that way.

For now, as the Ozerocdoff package exists and works, the current Ubuntu 9.10 default udev behavior for this device should be disabled allowing the ZeroCD to remain untouched and automount as a CDROM ( revert back to what was done for this device in 9.04 ). Then interested users can elect to apply the Ozerocdoff package and get the proper behavior rather than the total system lockup, requiring a hard power cycle to clear, which is all we can get now.

If someone whats to take a different view, I am willing to listen, but at the moment this is how I view this bug and how to fix it.

[phickel (pat-hickel)]

Today I updated to the latest udev patch offered by Update Manager, still no joy consistently locks system when inserting this USB device. ID 0af0:d033 Option

[Mike N (midgen768)]

A photo of the contents of /var/log/syslog that were visible on the screen after the system crashed when inserting the ATT Quicksilver into my Dell running Ubuntu 9.10 updated on 11/15/09

[phickel (pat-hickel)]

Finally some progress, I can stop the act of inserting the AT&T Quicksilver in the USB port from locking the system,
and I may have just isolated what is really causing the lockup under Ubuntu 9.10.

Go ahead download, build and install the Ozerocdoff package from http://pharscape.org/Quicksilver.html

To stop the lockup from happening before you insert the Quicksilver, fire up the Synaptic Package Manager
Find the modemmanager application and mark it for complete removal, then have Synaptic apply the change

The modem-manager application is grabbing the ttyHS* ports, specifically ttyHS2 which is causing the lockup.

Nov 19 19:21:07 dragon modem-manager: Added modem /sys/devices/pci0000:00/0000:00:1e.0/0000:02:07.2/usb1/1-5
Nov 19 19:21:07 dragon modem-manager: data_available (ttyHS2): response buffer filled before repsonse received
Nov 19 19:21:07 dragon modem-manager: data_available (ttyHS2): response buffer filled before repsonse received
Nov 19 19:21:07 dragon modem-manager: data_available (ttyHS2): response buffer filled before repsonse received
Nov 19 19:21:07 dragon modem-manager: data_available (ttyHS2): response buffer filled before repsonse received

After you remove modem-manager this is what happens in /var/log/messages when you insert the AT&T Quicksilver

Nov 19 19:57:44 dragon kernel: [ 2093.880060] usb 1-5: new high speed USB device using ehci_hcd and address 8
Nov 19 19:57:44 dragon kernel: [ 2094.014102] usb 1-5: configuration #1 chosen from 1 choice
Nov 19 19:57:44 dragon kernel: [ 2094.016719] scsi3 : SCSI emulation for USB Mass Storage devices
Nov 19 19:57:46 dragon kernel: [ 2095.180193] usb 1-5: USB disconnect, address 8
Nov 19 19:57:46 dragon kernel: [ 2095.432102] usb 1-5: new high speed USB device using ehci_hcd and address 9
Nov 19 19:57:46 dragon kernel: [ 2095.570090] usb 1-5: configuration #1 chosen from 1 choice
Nov 19 19:57:47 dragon kernel: [ 2096.244377] hso: /build/buildd/linux-2.6.31/drivers/net/usb/hso.c: 1.2 Option Wireless
Nov 19 19:57:47 dragon kernel: [ 2096.245439] hso0: Disabled Privacy Extensions
Nov 19 19:57:47 dragon kernel: [ 2096.246866] usbcore: registered new interface driver hso
Nov 19 19:57:52 dragon kernel: [ 2101.596257] Modules linked in: hso binfmt_misc usblp snd_intel8x0 snd_ac97_codec pcmcia hostap_pci hostap lib80211 yenta_socket ac97_bus snd_pcm_oss orinoco_pci rsrc_nonstatic joydev snd_mixer_oss orinoco pcmcia_core shpchp snd_pcm snd_seq_dummy snd_seq_oss nls_iso8859_1 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq nls_cp437 psmouse serio_raw ppdev snd_timer vfat lp iptable_filter snd_seq_device fat sony_laptop ip_tables parport snd soundcore snd_page_alloc x_tables usbhid usb_storage e100 mii ohci1394 ieee1394 radeon ttm drm i2c_algo_bit intel_agp agpgart
Nov 19 19:57:52 dragon kernel: [ 2101.596368]
Nov 19 19:57:52 dragon kernel: [ 2101.596380] Pid: 537, comm: modem-manager Tainted: G W (2.6.31-14-generic #48-Ubuntu) PCG-V505BX(UC)
Nov 19 19:57:52 dragon kernel: [ 2101.596391] EIP: 0073:[<00383b07>] EFLAGS: 00010246 CPU: 0
Nov 19 19:57:52 dragon kernel: [ 2101.596405] EIP is at 0x383b07
Nov 19 19:57:52 dragon kernel: [ 2101.596413] EAX: 00000000 EBX: 0044eff4 E...

[kevinsickles (kevin-sickles)]

Is anyone going to work this?

USB causes Kernel failure?

[phickel (pat-hickel)]

I reported this problem quite some time ago, and considering it causes a
total system lockup, I am surprised I cannot seem get anyone interested
to actually do anything to get this fixed, but I have now confirmed what
is actually happening.

In a nutshell, when the USB subsystem detects the Quicksilver modem, it
hands off to the "Gnome Network Manager", which in turn hands off to the
new "Gnome Modem Manager". The "Gnome Modem Manager" then grabs the
ttyHS* ports even though it has no idea how to handle the Quicksilver
ttyHS* devices correctly and proceeds to lock up the entire computer in
it's persistant efforts to do exactly the wrong thing.

I have not found a way to tell Gnome Network Manager and/or it's partner
in this abuse Gnome Modem Manager to back off and do not touch the
Quicksilver ttyHS* devices because they obviously do not know how to
handle and control these devices correctly.

A drakonian approach is to simply completely uninstall Gnome Network
Manager and Gnome Modem Manager. However this also eliminates the
good things they do for wired and wifi connections. Unfortunately I
have not yet found a better way to address this issue.

For some more into on the topic you can check out this URL
> http://www.pharscape.org/forum/index.php/topic,802.0.html
This is the forum for the HSOconnect gui tool for the hso driver.

[phickel (pat-hickel)]

As a workaround you can go to the following URL

http://www.pharscape.org/Quicksilver.html

There are three packages you will need to download from the Pharscape
site. Don't build/install then yet, just find and download them to a
directory on your system for now.

 1) ozerocdoff ( udev.tar.gz )
 This uses udev to auto-disable the zero cd on Option devices.

 2) hsolink_1.0.118-1_i386.deb
 Scripts & stuff needed for the hsoconnect gui tool

 3) hsoconnect-1.2.18.tar.gz
 The gui tool to control the Quicksilver HSDPA modem.
 ( Remember ubuntu 9.10 had python 2.6 so you need the
 beta package which is the tarball above not the *.deb )

Remember to get everything needed to build the packages above.

sudo apt-get install build-essential libusb-dev linux-headers-$(uname -r)

Now we will eliminate the lockup.

Fire up Synaptic package manager find and install the following package

 1) wicd

find the following packages in Synaptic and mark for complete removal

 1) gnome network manager
( this should have been auto-removed when wicd was installed - verify )

 2) modem manager
( This is what actually causes the lockup - mark for complete removal )

This will stop the total system lockup on USB insertion of the
Quicksilver device and replace the Gnome Network Manager / Modem Manager
combination with a usable alternative ( wicd ) which does not suffer
from Delusions of Grandure demanding total control of devices they have
no idea how to operate.

Now to get the Quicksilver running

Read the web pages on the Pharscale site for how to build/install each
of the three packages downloaded above. NOTE: To make hsoconnect
successfully manually pre-create the following two directories.

/usr/share/hsoconnect
/usr/share/hsoconnect/hsoc

Build and install the 3 Pharscape downloaded packages in the same order
they were downloaded above.

This will ultimately give you wicd in control of all wired and wifi
network links, while only the hsoconnect package gui tool will be in
control of the AT&T Quicksilver 3G GSM/HSDPA modem device and links.

I have given up any hope of straightening out the Gnome Network Manager
and Modem Manager combination, they have no idea nor it seems any
concern their packages are causing the total lockup of systems, leaving
the only way forward as their complete removal and replacement by wicd.

Pat Hickel

[James King (jlking3)]

Thank you for posting the workaround. I've added the workaround to a question I had regarding the exact same issue (#91686) and have marked it solved, even though technically it isn't solved since the answer is a rather involved workaround. There must not be enough Quicksilver/Ubuntu users for Canonical to make this kernel panic a higher priority. I wonder what the threshold is?

[CJohnston (curtaj)]

I have the same problem, and would greatly appreciate a solution.

I tried Pat's suggestions in note 8 above, and had to re-install the whole system.

Curt Johnston

[James King (jlking3)]

Curt, I wish I had a solution for you. Pat's workaround was successful
for me. In fact, I'm using the Quicksilver connection right now to
send this.

Ideally, it would seem to me that the GNOME folks would see what's
different between GNOME's tools (network-manager and modem-manager)
and wicd, make the appropriate changes and include the functionality
of HSOconnect in it.

On Thu, Jan 14, 2010 at 11:05 AM, CJohnston <email address hidden> wrote:
> I have the same problem, and would greatly appreciate a solution.
>
> I tried Pat's suggestions in note 8 above, and had to re-install the
> whole system.
>
> Curt Johnston
>
> --
> USB device insertion causes total system lockup on Ubuntu 9.10
> https://bugs.launchpad.net/bugs/469376
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Linux Hotplug Scripts: Confirmed
> Status in ModemManager (with NetworkManager support): New
> Status in udev - /dev/ management daemon: Confirmed
> Status in Ubuntu: Confirmed
>
> Bug description:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>  affects udev
>
>  affects hotplug
>
>  affects ubuntu 9.10
>
> On two separate systems I have upgraded from 9.04 to 9.10 I get a
> complete, immediate and total system lockup when I install a specific
> device in a USB port.    The device is an AT&T Quicksilver GSM/HSDPA
> Cellular modem, on 8.10 and 9.04 systems, lsusb shows the device as "Bus
> 002 Device 006: ID 0af0:d033 Option".
>
> On 8.10 and 9.04 systems the device initially shows up as a CDROM
> containing the driver and application software needed on an MS Windows
> box.    There is a linux package ( Ozerocdoff found at
> http://pharscape.org/Quicksilver.html ) from the real device
> Manufacturer "Option" which uses udev to disable this "zerocd" and then
> the Option Cellular Modem appears which works with the linux hso kernel
> module.   On a 9.10 system with or without Ozerocdoff installed I get
> the lockup even before the CDROM or Modem appears or is logged.
>
> The device worked fine in the same systems before the 9.04 to 9.10
> upgrade.  Other USB devices work fine under 9.04 and 9.10.  I have not
> yet tried on a fresh 9.10 install only 9.04 to 9.10 upgrades.
>
> The lockup is immediate and total.    The only way I have found to
> regain access to the systems is to remove the device, then do a hard
> power cycle.
>
> I cannot identify or recover any meaningful details from the log files
> in /var/log.
>
> I would appreciate any clues on how I can capture better debug
> information on this situation.  The immediate and total system lockup
> has me stumped for where to go from here.    I do realize the above is
> insufficient to work with, I am asking for how to capture better
> information for a proper bug report.
>
> Thank you;
>
> Patrick Hickel
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkrt7YcACgkQGcFsRP9ZxTqsmQCfW99eDBuSwZKd1NWfnrdr9NZu
> /KcAnA86BvzDb0k78zJvnfQOIH1e4ia8
> =Q/Vp
> -----END PGP SIGNATURE-----
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/hotplug/+bug/469376/+su...

[CJohnston (curtaj)]

Well, I tried Pat's solution again, and succeeded. The only wrinkle is that once connected, Firefox and Evolution will not connect to the internet unless started with sudo. So I used "Authorizations" to give myself implicit authorization.

Do you know where the problem is?

Curt

[phickel (pat-hickel)]

Curt:

Don't know about Evolution because I use Mozilla Thunderbird, but if I
had to guess, I would almost be willing to bet this will be what you are
looking for, at least from your description of the problem.

Potential fix =======================================================

1) Launch HSOconnect and bring the network up, then open a terminal
window to verify the file permissions on the "/etc/resolv.conf" file.

 ls -l /etc/resolv.conf

 If the mode is 600 (-rw------- )rather than the correct 644
(-rw-r--r-- ) it should be, changing the mode of the file to it's
proper setting will provide a quick temporary fix.

 sudo chmod 644 /etc/resolv.conf

 Firefox and Evolution should then work normally without requiring
sudo, but as I said this is only a temporary fix.
 Every time you bring the network up you would have to change the file
mode again.

2) If step 1 above temporarily helped, you can elect to install another
package which will provide a permanent fix.

 sudo apt-get install resolvconf

I have found the HSOconnect tools work best if you also install the
resolvconf package to maintain and update the contents of the
/etc/resolv.conf file. Without the resolvconf package installed
something in the HSOconnect stuff defaults /etc/resolv.conf to 600 every
time you use HSOconnect which breaks a lot of network things.

As a minimum, I would gracefully shutdown hsoconnect and re-boot after
installing resolvconf, but I don't know if this graceful shutdown and
reboot is actually required.

I don't remember if I re-built and re-installed the HSO packages after I
installed the resolvconf package or not. You may need to have the
resolvconf package already installed when you build and install the HSO
stuff, I just do not remember.

This potential resolvconf fix should help Evolution, Firefox and just
about any other network application.

===================================================

I strongly suspect the above will fix your problem. If this really is
the problem then the breakage is a lot bigger than just Evolution and
Firefox.

If this does not fix it, I have something else you can try which is
Firefox specific.

Later

Pat Hickel

[James King (jlking3)]

Pat,

I remember having a ton of DNS issues for a while (they're all cleared
up, but for the life of me I wouldn't be able to tell you how), and
all the resolv.conf stuff sounds all too familiar. I use static DNS
(OpenDNS is a good DNS server, Google has a DNS server too) and I
haven't had any troubles for 3 weeks so far.

James

On Sun, Jan 17, 2010 at 4:23 PM, phickel <email address hidden> wrote:
> Curt:
>
> Don't know about Evolution because I use Mozilla Thunderbird, but if I
> had to guess, I would almost be willing to bet this will be what you are
> looking for, at least from your description of the problem.
>
> Potential fix =======================================================
>
> 1) Launch HSOconnect and bring the network up, then open a terminal
> window to verify the file permissions on the "/etc/resolv.conf" file.
>
>        ls -l /etc/resolv.conf
>
>        If the mode is 600 (-rw------- )rather than the correct 644
> (-rw-r--r-- ) it should be, changing the mode of the file to                    it's
> proper setting will provide a quick temporary fix.
>
>        sudo chmod 644 /etc/resolv.conf
>
>        Firefox and Evolution should then work normally without                         requiring
> sudo, but as I said this is only a temporary fix.
>        Every time you bring the network up you would have to change the        file
> mode again.
>
> 2) If step 1 above temporarily helped, you can elect to install another
> package which will provide a permanent fix.
>
>        sudo apt-get install resolvconf
>
> I have found the HSOconnect tools work best if you also install the
> resolvconf package to maintain and update the contents of the
> /etc/resolv.conf file.    Without the resolvconf package installed
> something in the HSOconnect stuff defaults /etc/resolv.conf to 600 every
> time you use HSOconnect which breaks a lot of network things.
>
> As a minimum, I would gracefully shutdown hsoconnect and re-boot after
> installing resolvconf, but I don't know if this graceful shutdown and
> reboot is actually required.
>
> I don't remember if I re-built and re-installed the HSO packages after I
> installed the resolvconf package or not.    You may need to have the
> resolvconf package already installed when you build and install the HSO
> stuff, I just do not remember.
>
> This potential resolvconf fix should help Evolution, Firefox and just
> about any other network application.
>
> ===================================================
>
> I strongly suspect the above will fix your problem.  If this really is
> the problem then the breakage is a lot bigger than just Evolution and
> Firefox.
>
> If this does not fix it, I have something else you can try which is
> Firefox specific.
>
> Later
>
> Pat Hickel
>
> --
> USB device insertion causes total system lockup on Ubuntu 9.10
> https://bugs.launchpad.net/bugs/469376
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Linux Hotplug Scripts: Confirmed
> Status in ModemManager (with NetworkManager support): New
> Status in udev - /dev/ management daemon: Confirmed
> Status in Ubuntu: Confirmed
>
> Bug description:
> -----BEGIN PGP S...

[Old_J (mountainhome3)]

I am Jeff, and my email is <email address hidden>. I have a compaq presario r3000 series laptop, the usb internet stick named in this issue, and I am a newbie.

When I place this stick in, Ubuntu 9.10 locks up solid, and I am forced to power down to get a reboot.

Has this issue been resolved ?

I have been searching through much documentation and postings but I am unclear whether this issue has been resolved, and what steps I need to take.

[phickel (pat-hickel)]

Not resolved, but we have isolated the cause to Gnome Network Manager
and Modem Manager, and we do have a workaround.

As a workaround you can go to the following URL

http://www.pharscape.org/Quicksilver.html

There are three packages you will need to download from the Pharscape
site. Don't build/install then yet, just find and download them to a
directory on your system for now.

 1) ozerocdoff ( udev.tar.gz )
 This uses udev to auto-disable the zero cd on Option devices.

 2) hsolink_1.0.118-1_i386.deb
 Scripts & stuff needed for the hsoconnect gui tool

 3) hsoconnect-1.2.18.tar.gz
 The gui tool to control the Quicksilver HSDPA modem.
 ( Remember Ubuntu 9.10 has python 2.6 so you need the
 beta package which is the tarball above not the *.deb )

Remember to get everything needed to build the packages above.
( update: newer versions of the packages above are also OK )

sudo apt-get install build-essential libusb-dev linux-headers-$(uname -r)

Now we will eliminate the lockup.

Fire up Synaptic package manager find and install the following package

 1) wicd

find the following packages in Synaptic and mark for complete removal

 1) gnome network manager
( this should have been auto-removed when wicd was installed - verify )

 2) modem manager
( This is what actually causes the lockup - mark for complete removal )

This will stop the total system lockup on USB insertion of the
Quicksilver device and replace the Gnome Network Manager / Modem Manager
combination with a usable alternative ( wicd ) which does not suffer
from Delusions of Grandure demanding total control of devices they have
no idea how to operate.

Now to get the Quicksilver running

Read the web pages on the Pharscale site for how to build/install each
of the three packages downloaded above. NOTE: To make hsoconnect
successfully manually pre-create the following two directories.

/usr/share/hsoconnect
/usr/share/hsoconnect/hsoc

Build and install the 3 Pharscape downloaded packages in the same order
they were downloaded above.

This will ultimately give you wicd in control of all wired and wifi
network links, while only the hsoconnect package gui tool will be in
control of the AT&T Quicksilver 3G GSM/HSDPA modem device and links.

As a final item, the hsoconnect tool works best in combination with the
"resolvconf" package to manage and maintain the contents of the
"/etc/resolv.conf" file. I recommend using synaptic to install the
resolvconf package, or you will end up chasing file permission on the
resolv.conf file which will complicate your hsoconnect usage.

The steps above should get your AT&T/Option modem working cleanly and
they have worked for at least 3 other people besides me.

I was never able to get any help on the Gnome Window Manager or Modem
Manager side of this issue. It could be fixed in a later versions or
whatever, I just do not know.

Pat Hickel

[James King (jlking3)]

The problem still exists with Lucid 10.4 ... In fact, I couldn't install the HSO stuff after the clean install. I had to install 9.10 then do an upgrade to 10.4 ... when connecting now, I get a message that says "not installed properly -- no internet control" but I can still get online. (I'm using the connection to send this.) I'm getting error messages when trying to reinstall everything, so I may just have to accept the error messages and enjoy the internet connection while it lasts. I'd rather not have to accept the error messages.

[phickel (pat-hickel)]

I have not tried 10.04 yet, but probably will in the next week or so.
 If I had to guess right now I suspect what you are experiencing is an
artifact of the somewhat publicized Ubuntu elimination of HAL in 10.04.

In 10.04 Ubuntu totally eliminated the Hardware Abstraction Layer (HAL).
   The ozerocdoff function for Option cellular modems is dependant on
HAL to at least some extent. In your second attempt by electing to
upgrade to 10.04 from 9.10 rather than a fresh 10.04 install you
probably left enough residual of the old 9.10 HAL laying around so
ozerocdoff was still working after the upgrade.

Some 9.10 to 10.04 breakage is to be expected. When I do try 10.04,
the first attempt will be to run it from a totally clean fresh 10.04
install with nothing extra remembering to use the Ubuntu native function
they have now to "supposedly " replace ozerocdoff ( usb-modeswitch ).

The trick is going to be to get usb-modeswitch to disable the zero cd
before the stupid and never to be sufficiently damned Gnome
Modem-Manager function comes bumbling along and locks the computer.

The problem has always been Gnome Modem Manager has never really
understood how to correctly turn off the "zero cd" function on Option
Cellular Modems while blindly and incorrectly assuming it knew
everything needed to correctly identify, initialize and control any
modem device. This faulty assumption proved to be disasterous.

So I will try it with just Ubuntu first, and after exploring every
reasonable means to make it work, then I expect to be forced to go back
to the Pharscape HSO packages and tweak that until it works.

Good luck

Pat Hickel

[phickel (pat-hickel)]

OK, I finally got a chance to try 10.04 and I confirm the lockup still
exists. However, the error you report is easily resolved, you missed
one rather poorly documented step.

Use The Synaptic Package Manager to verify you do not have the default
hsolink package loaded.

Also remember
sudo apt-get install build-essential libusb-dev linux-headers-$(uname -r)

On the Pharscape site download the hsolinkcontrol source tarball.
DO NOT use the *.deb or *.rpm package, get and use the *.tgz file

extract the source tarball using tar xzf

then cd into the hsolinkcontrol source directory
 ./configure
 sudo make clean
 sudo make
 sudo make install

And finally here is the step you missed.

 sudo chmod +s `which hsolinkcontrol`

This chmod step sets the suid/sgid bits needed to actually allow
hsolinkcontrol to work, and get rid of the "not installed properly -- no
internet control"
message.

[Mohamed Amine Ilidrissi (ilidrissi.amine)]

Can you run "apport-collect 469376" in a terminal?

[Alex Chiang (achiang)]

Hello all,

I can confirm that this modem causes a system freeze in Lucid.

As an experiment, I backported modem-manager from Maverick into Lucid, with no other changes (it was a rather trivial backport).

After doing so, I am able to insert the modem without any issues.

[Alex Chiang (achiang)]

This is bizarre.

I did a fresh install of Lucid 10.04.1 onto a netbook, then plugged in my Option modem (0af0:d033).

I confirm that it caused my system to lock up.

I just spent the past 4 hours trying to bisect this issue, and I can't get it to fail reliably.

In my bisection adventure, I found a point where I could checkout and build/install a package, and no system freeze. I then checkout (build, install) the commit immediately before and lo! a system freeze! This makes me think that the package is broken up to the good commit. However, this hypothesis has two problems:

1) Yes, the "bad" commit immediately prior the "good" commit breaks as expected. The "bad" commit happens way after the commit we have in Lucid. So far, so good. Theoretically, all the commits between the "bad" one and the last Lucid one should all result in system freeze. Unfortunately, that is not the case. I picked several random commits between "bad" and "Lucid" and encountered success at each of them.

2) Simply downloading the exact modemmanager source from Lucid, rebuilding it where the only debdiff is in the changelog, and then installing it on my test system simply does not reproduce the failure. This makes no sense, since the code didn't change at all in this experiment. I made sure to reboot and purge the package before installing my test package as well. No luck.

My original intent was to try and find the one good commit to backport as an SRU into Lucid. However, with such unreliable bisection results, there is no way that I can safely do so in good conscience. I would essentially be backporting a random patch into Lucid and hoping that it fixed the problem, which is not allowed by SRU policy. Also, backporting the entire package from Maverick into Lucid is also disallowed by SRU policy.

My best recommendation at this point is to move your systems to Maverick.

If you are stuck on Lucid, please respond and we can try some more testing. Perhaps you can bisect more reliably on your machine than I can on mine which would help us to narrow down the issue.

[Launchpad Janitor (janitor)]

[Expired for udev (Ubuntu) because there has been no activity for 60 days.]