Blackberry 7730, possibly others don't work in at least Edgy Eft, Gutsy Gibbon

[Raphael J. Schmid]

When I plug in my Blackberry 7730 to either an Efty Eft or a Gutsy Gibbon PC, the following happens in dmesg:

Oct 14 13:20:27 momo kernel: [13131.488000] usb 2-1: new full speed USB device using uhci_hcd and address 2
Oct 14 13:20:28 momo kernel: [13131.672000] usb 2-1: configuration #1 chosen from 1 choice
Oct 14 13:20:28 momo kernel: [13131.748000] usb 2-1: USB disconnect, address 2
Oct 14 13:20:28 momo kernel: [13132.508000] usb 2-1: new full speed USB device using uhci_hcd and address 3
Oct 14 13:20:29 momo kernel: [13132.700000] usb 2-1: configuration #1 chosen from 1 choice
Oct 14 13:20:29 momo kernel: [13132.760000] usb 2-1: USB disconnect, address 3
Oct 14 13:20:29 momo kernel: [13133.516000] usb 2-1: new full speed USB device using uhci_hcd and address 4
Oct 14 13:20:30 momo kernel: [13133.696000] usb 2-1: configuration #1 chosen from 1 choice
Oct 14 13:20:30 momo kernel: [13133.768000] usb 2-1: USB disconnect, address 4
Oct 14 13:20:30 momo kernel: [13134.516000] usb 2-1: new full speed USB device using uhci_hcd and address 5
Oct 14 13:20:31 momo kernel: [13134.700000] usb 2-1: configuration #1 chosen from 1 choice
Oct 14 13:20:31 momo kernel: [13134.704000] usb 2-1: USB disconnect, address 5
Oct 14 13:20:31 momo kernel: [13135.320000] usb 2-1: new full speed USB device using uhci_hcd and address 6
Oct 14 13:20:31 momo kernel: [13135.504000] usb 2-1: configuration #1 chosen from 1 choice
Oct 14 13:20:31 momo kernel: [13135.544000] usb 2-1: USB disconnect, address 6
Oct 14 13:20:32 momo kernel: [13136.292000] usb 2-1: new full speed USB device using uhci_hcd and address 7
Oct 14 13:20:32 momo kernel: [13136.480000] usb 2-1: configuration #1 chosen from 1 choice
Oct 14 13:20:32 momo kernel: [13136.484000] usb 2-1: USB disconnect, address 7
Oct 14 13:20:33 momo kernel: [13137.300000] usb 2-1: new full speed USB device using uhci_hcd and address 8
Oct 14 13:20:33 momo kernel: [13137.480000] usb 2-1: configuration #1 chosen from 1 choice
Oct 14 13:20:33 momo kernel: [13137.484000] usb 2-1: USB disconnect, address 8
Oct 14 13:20:34 momo kernel: [13138.104000] usb 2-1: new full speed USB device using uhci_hcd and address 9
Oct 14 13:20:34 momo kernel: [13138.284000] usb 2-1: configuration #1 chosen from 1 choice
Oct 14 13:20:34 momo kernel: [13138.316000] usb 2-1: USB disconnect, address 9
Oct 14 13:20:35 momo kernel: [13139.068000] usb 2-1: new full speed USB device using uhci_hcd and address 10
Oct 14 13:20:35 momo kernel: [13139.260000] usb 2-1: configuration #1 chosen from 1 choice
Oct 14 13:20:35 momo kernel: [13139.264000] usb 2-1: USB disconnect, address 10
Oct 14 13:20:36 momo kernel: [13140.072000] usb 2-1: new full speed USB device using uhci_hcd and address 11
Oct 14 13:20:36 momo kernel: [13140.256000] usb 2-1: configuration #1 chosen from 1 choice
Oct 14 13:20:36 momo kernel: [13140.260000] usb 2-1: USB disconnect, address 11

Among Blackberry Linux users it is known that such behaviour might be caused by the berry_charge kernel module. Despite many tries to rmmod it, I could not get rid of the continuous connects and disconnects. I discovered then that disabling udevd and _then_ rmmod'ing berry_charge would solve the problem; my quickfix for now is to rename berry_charge.ko but this needs to be addressed in a proper manner. The other distributions I tried this with (Slax and openSUSE namely) got it right, whatever they're doing differently...

I also suggest shipping the Barry software with Ubuntu, or at least including it in some repository. It can be found at http://www.netdirect.ca/software/packages/barry/ and has reached a good stability with the recent 0.9 version, allowing users to backup and restore their device.

[Raphael J. Schmid (raphael-j-schmid)]

Okay, I take that quickfix back. After reboot it's all the same again. The connect-disconnect cycle can only be stopped by kill'ing udevd, and now btool doesn't report my BB at all anymore :-(

[Scott James Remnant (Canonical) (canonical-scott)]

Killing udevd just stops the module being loaded after you rmmod it.

You could always just blacklist it:

  echo blacklist berry_charge > /etc/modprobe.d/blackberry

Why does this module cause this problem? Do the other distributions not ship this module?

[Raphael J. Schmid (raphael-j-schmid)]

Hi Scott,

I didn't know about blacklisting; did that now. Like indicated in my second comment though, removing that module obviously didn't _really_ solve the problem. I can only stop the cyclic connecting-and-disconnecting through killing udevd, which then prevents Barry from finding the device at all...

At least Slax doesn't ship berry_charge; I think they don't use udevd, too, but will have to check on that this afternoon. As for openSUSE, that lasted about 10 minutes on my harddrive. If there's no other way to diagnose this, I'll install it again for testing though, but would rather keep this laptop productive (only machine).

[John McCain (mccainj)]

I can partially confirm this behavior. When I attempt to connect a blackberry, the following occurs (dmesg snip)

[ 75.628000] usb 1-1: new full speed USB device using uhci_hcd and address 2
[ 75.788000] usb 1-1: configuration #1 chosen from 1 choice
[ 75.928000] usbcore: registered new interface driver berry_charge
[ 105.960000] usb 1-1: USB disconnect, address 2
[ 106.200000] usb 1-1: new full speed USB device using uhci_hcd and address 3
[ 106.360000] usb 1-1: configuration #1 chosen from 1 choice

I appear to only get one iteration of the loop rapha describes

Then udevd starts using 85-100% processor utilization until it is killed or until the machine is rebooted.

If I blacklist berry_charge, I get the following:

[ 767.984000] usb 1-1: new full speed USB device using uhci_hcd and address 4
[ 768.148000] usb 1-1: configuration #1 chosen from 1 choice

But udev continues to use 85-100% processor utilization.

I am running Gutsy (all updates as of 10/16/2007) with Linux version 2.6.22-14-generic

[Raphael J. Schmid (raphael-j-schmid)]

Hi John, Hi Scott,

I promised to check SLAX again. Turns out I was wrong about it not using udevd - it does (and it's kernel version is 2.6.16, if that is of any help). My udevd hasn't been spotted consuming more than maybe 3-4% of the CPU. Tell me what other diagnostic information you could use and I'll do my best to acquire it (either under Ubuntu or SLAX).

Cheers,
Raphael

[John McCain (mccainj)]

OK - more info.

If I get into the udev "race condition", I can get out of it thusly:

killall udevd
/etc/init.d/udev stop
rmmod berry_charge
(blacklist berry_charge as previously described)
/etc/init.d/udev start

I can then use bcharge in barry to charge the blackberry.

I don't know enough about the innards of udev to understand what is going on, but it looks like the problem is with the berry_charge module.

[Raphael J. Schmid (raphael-j-schmid)]

Hi John,

charging has always been working for me, whether berry_charge was loaded or not, and also independantly of bcharge. Does, after the procedure described above, work backing up you device with barrybackup work for you?

I tried to replicate your steps exactly, but it doesn't prevent the infinite loop from happening :-(

- Raphael

[oss_test_launchpad (oss-test-launchpad)]

Bug confirmed.

[Raphael J. Schmid (raphael-j-schmid)]

Cool, thanks.

Is there anything we can do to help fix it?

[Leann Ogasawara (leannogasawara)]

The Hardy Heron Alpha2 release will be coming out soon. It would be great if you could test with this new release and verify if this issue still exists. I'll be sure to update this report when Alpha2 is available. Thanks!

[Leann Ogasawara (leannogasawara)]

I'm opened a new task against the actively developed kernel. However, I'm closing the report against linux-source-2.6.22 as it does not meet the criteria for a stable release update. You can learn more about the stable release update process at https://wiki.ubuntu.com/StableReleaseUpdates . Thanks!

[Leann Ogasawara (leannogasawara)]

Hardy Heron Alpha2 was recently released. It contains an updated version of the kernel. You can download and try the new Hardy Heron Alpha2 release from http://cdimage.ubuntu.com/releases/hardy/alpha-2/ . You should be able to then test the new kernel via the LiveCD. If you can, please verify if this bug still exists or not and report back your results. General information regarding the release can also be found here: http://www.ubuntu.com/testing/hardy/alpha2 . Thanks!

[John McCain (mccainj)]

Sorry it took me so long to get back to you on this.

I get the same behavior in Hardy Heron. Udevd runs at very high utilization until udevd is killed.

[Leann Ogasawara (leannogasawara)]

Thanks for testing. Per the kernel team's bug policy, can you please attach the following information. Please be sure to attach each file as a separate attachment.

* uname -a > uname-a.log
* cat /proc/version_signature > version.log
* dmesg > dmesg.log
* sudo lspci -vvnn > lspci-vvnn.log

For more information regarding the kernel team bug policy, please refer to https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks again and we appreciate your help and feedback.

[John McCain (mccainj)]

Files attached as requested.

[Bill Ellis (noncalamari)]

Folks,

Here's a work-around (works for me on my Debian/testing machines):

1. Unplug the Blackberry from the host USB port.
2. As root, do "/etc/init.d/udev restart"
3. As root, do "rmmod berry_charge"
4. Plug the Blackberry in to the host USB port.

This works 100% for me. Would be curious to hear if this works for others...

Bill

[Raphael J. Schmid (raphael-j-schmid)]

Kind of. I have permanently renamed berry_charge.ko to berry_charge.ko_UNUSED. However, when using Barry (barry.sf.net) I still get the connect-disconnect-loop problem. As a workaround, I re-install the Barry .debs each time before using it. That's what works 100% for me, and I guess it is analogous to your solution, Bill.

- Raphael

[Bill Ellis (noncalamari)]

Sorry... I guess I didn't explain that very well. :-/

What I'm seeing is that the high-CPU problem with udevd only happens when I plug in
the Blackberry when the "berry_charge" module is already loaded. The module seems
to work just fine the *first* time it loads (that is to say, when it auto-loads in response
to my plugging in the Blackberry).

To clarify, I'm not using "barry". I'm just using the berry_charge kernel module (on a
2.6.24.2 kernel).

BTW, I found that it was informative to turn on debugging for the module, which I did
by creating a file in "/etc/modprobe.d", containing this line:

  options berry_charge debug=1

With this in effect, the dmesg output shows that the berry_charge module keeps getting
called over and over, successfully sending the "magic" commands to the Blackberry each time.
The problem seems to be that udevd doesn't understand that it doesn't need to keep
trying to reinitialize the module. Again, udevd only seems to get in this mode when a Blackberry
is plugged in when the berry_charge module is already loaded.

From a quick look at the source code of the "berry_charge" module, I'd guess that this is because
the module doesn't finish its initialization like most drivers -- it actually returns a failure ("-ENODEV"),
presumably because it's not *really* a driver at all. Guessing that this doesn't phase udevd when
we're in the "auto-install module" code path, but exposes a bug when it's on the "reinitialize module"
code path.
(I may be talking through my hat on this last part, as I haven't looked at the udevd source...)

Best Regards,

Bill

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[oss_test_launchpad (oss-test-launchpad)]

This is still an issue. Btw. AFAIK bcharge is now renamed or a part of the "barry" package.

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Triaged a while ago but has not had any updated comments for quite some time. Please let us know if this issue remains in the current Ubuntu release, http://www.ubuntu.com/getubuntu/download . If the issue remains, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[John R (john-maxpower)]

This bug still occurs on Ubuntu 9.10.

Attempting to connect a Blackberry Bold 9700 causes the connect / disconnect loop.

berry_charge is not loaded as a module

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu release http://www.ubuntu.com/getubuntu/download . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]