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
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
** Attachment added: System info attached
http://launchpadlibrarian.net/40937719/diag.tar.bz2
--
Blackberry 7730, possibly others
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
This is still an issue. Btw. AFAIK bcharge is now renamed or a part of
the barry package.
--
Blackberry 7730, possibly others don't work in at least Edgy Eft, Gutsy Gibbon
https://bugs.launchpad.net/bugs/152742
You received this bug notification because you are a member of Ubuntu
Bugs, which is
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
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
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
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
Files attached as requested.
** Attachment added: requestedfiles.tar.gz
http://launchpadlibrarian.net/11120048/requestedfiles.tar.gz
--
Blackberry 7730, possibly others don't work in at least Edgy Eft, Gutsy Gibbon
https://bugs.launchpad.net/bugs/152742
You received this bug notification
** Changed in: linux (Ubuntu)
Importance: Undecided = Medium
Assignee: (unassigned) = Ubuntu Kernel Team (ubuntu-kernel-team)
Status: Incomplete = Triaged
--
Blackberry 7730, possibly others don't work in at least Edgy Eft, Gutsy Gibbon
https://bugs.launchpad.net/bugs/152742
You
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
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.
--
Blackberry 7730, possibly others don't work in at least Edgy Eft, Gutsy Gibbon
https://bugs.launchpad.net/bugs/152742
You received this bug
** Tags removed: hardy-alpha2
--
Blackberry 7730, possibly others don't work in at least Edgy Eft, Gutsy Gibbon
https://bugs.launchpad.net/bugs/152742
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
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
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!
** Also affects: linux (Ubuntu)
Importance: Undecided
Status:
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 .
Bug confirmed.
--
Blackberry 7730, possibly others don't work in at least Edgy Eft, Gutsy Gibbon
https://bugs.launchpad.net/bugs/152742
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
Cool, thanks.
Is there anything we can do to help fix it?
--
Blackberry 7730, possibly others don't work in at least Edgy Eft, Gutsy Gibbon
https://bugs.launchpad.net/bugs/152742
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
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
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
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
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
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 :-(
--
Blackberry 7730, possibly others don't work in at least Edgy Eft, Gutsy Gibbon
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?
** Changed in: linux-source-2.6.22
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
25 matches
Mail list logo
