blackberry 8830 problems - 2.6.23.10

[Matt LaPlante]

I have a blackberry 8830 that I'm attempting to charge via USB with the 2.6.23.10 kernel. Unfortunately, when I plugged the device into the machine, all hell broke loose. In short, the load on the machine shot up, dmesg was full of usb & scsi messages, and udev was sucking cpu like there was no tomorrow. Here's the head and tail output from dmesg, snipped since it's a good several hundred lines in total:

Dec 15 18:07:50 prizm kernel: [ 555.334175] usb 1-2: USB disconnect, address 4
Dec 15 18:08:00 prizm kernel: [ 565.089586] usb 1-1: new full speed USB device using uhci_hcd and address 5
Dec 15 18:08:00 prizm kernel: [ 565.252857] usb 1-1: configuration #1 chosen from 1 choice
Dec 15 18:08:00 prizm kernel: [ 565.259731] scsi30496 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:00 prizm kernel: [ 565.260395] usb-storage: device found at 5
Dec 15 18:08:00 prizm kernel: [ 565.260398] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:00 prizm kernel: [ 565.268727] scsi30497 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:00 prizm kernel: [ 565.269280] usb-storage: device found at 5
Dec 15 18:08:00 prizm kernel: [ 565.269283] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:00 prizm kernel: [ 565.275726] scsi30498 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:00 prizm kernel: [ 565.276282] usb-storage: device found at 5
Dec 15 18:08:00 prizm kernel: [ 565.276285] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:00 prizm kernel: [ 565.282749] scsi30499 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:00 prizm kernel: [ 565.283326] usb-storage: device found at 5
Dec 15 18:08:00 prizm kernel: [ 565.283329] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:00 prizm kernel: [ 565.291473] scsi30500 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:00 prizm kernel: [ 565.292055] usb-storage: device found at 5
Dec 15 18:08:00 prizm kernel: [ 565.292059] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:00 prizm kernel: [ 565.297727] scsi30501 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:00 prizm kernel: [ 565.298281] usb-storage: device found at 5
Dec 15 18:08:00 prizm kernel: [ 565.298284] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:00 prizm kernel: [ 565.304728] scsi30502 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:00 prizm kernel: [ 565.305343] usb-storage: device found at 5
Dec 15 18:08:00 prizm kernel: [ 565.305346] usb-storage: waiting for device to settle before scanning
.....
Dec 15 18:08:52 prizm kernel: [ 617.293704] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:52 prizm kernel: [ 617.300326] scsi37674 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:52 prizm kernel: [ 617.300896] usb-storage: device found at 5
Dec 15 18:08:52 prizm kernel: [ 617.300899] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:52 prizm kernel: [ 617.307141] scsi37675 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:52 prizm kernel: [ 617.307842] usb-storage: device found at 5
Dec 15 18:08:52 prizm kernel: [ 617.307845] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:52 prizm kernel: [ 617.314106] scsi37676 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:52 prizm kernel: [ 617.314676] usb-storage: device found at 5
Dec 15 18:08:52 prizm kernel: [ 617.314679] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:52 prizm kernel: [ 617.321129] scsi37677 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:52 prizm kernel: [ 617.321703] usb-storage: device found at 5
Dec 15 18:08:52 prizm kernel: [ 617.321706] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:52 prizm kernel: [ 617.329121] scsi37678 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:52 prizm kernel: [ 617.329696] usb-storage: device found at 5
Dec 15 18:08:52 prizm kernel: [ 617.329699] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:52 prizm kernel: [ 617.335118] scsi37679 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:52 prizm kernel: [ 617.335698] usb-storage: device found at 5
Dec 15 18:08:52 prizm kernel: [ 617.335702] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:52 prizm kernel: [ 617.342546] scsi37680 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:52 prizm kernel: [ 617.343143] usb-storage: device found at 5
Dec 15 18:08:52 prizm kernel: [ 617.343146] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:53 prizm kernel: [ 617.578512] usb 1-1: USB disconnect, address 5


This machine is running Ubuntu Gutsy, udev version 113-0ubuntu16. As the phone is new, I believe this is the first time I've attempted to connect it to this machine. I used to connect my old blackberry without problems on the same hardware, but that was a slightly older kernel (2.6.22?). This behavior repeated across system reboots, and could only be solved by disconnecting the device.
--
Matt LaPlante

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Martin Owens]

The device continues to reset it's self, disable bcharge or
berry_charge kernel module from udev/blacklist and try and find out
why bcharge fails to set the phone correctly.

Post by Matt LaPlante
Dec 15 18:07:50 prizm kernel: [ 555.334175] usb 1-2: USB disconnect, address 4
Dec 15 18:08:00 prizm kernel: [ 565.089586] usb 1-1: new full speed USB device using uhci_hcd and address 5
Dec 15 18:08:00 prizm kernel: [ 565.252857] usb 1-1: configuration #1 chosen from 1 choice
Dec 15 18:08:00 prizm kernel: [ 565.259731] scsi30496 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:00 prizm kernel: [ 565.260395] usb-storage: device found at 5
Dec 15 18:08:00 prizm kernel: [ 565.260398] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:00 prizm kernel: [ 565.268727] scsi30497 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:00 prizm kernel: [ 565.269280] usb-storage: device found at 5
Dec 15 18:08:00 prizm kernel: [ 565.269283] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:00 prizm kernel: [ 565.275726] scsi30498 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:00 prizm kernel: [ 565.276282] usb-storage: device found at 5
Dec 15 18:08:00 prizm kernel: [ 565.276285] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:00 prizm kernel: [ 565.282749] scsi30499 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:00 prizm kernel: [ 565.283326] usb-storage: device found at 5
Dec 15 18:08:00 prizm kernel: [ 565.283329] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:00 prizm kernel: [ 565.291473] scsi30500 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:00 prizm kernel: [ 565.292055] usb-storage: device found at 5
Dec 15 18:08:00 prizm kernel: [ 565.292059] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:00 prizm kernel: [ 565.297727] scsi30501 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:00 prizm kernel: [ 565.298281] usb-storage: device found at 5
Dec 15 18:08:00 prizm kernel: [ 565.298284] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:00 prizm kernel: [ 565.304728] scsi30502 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:00 prizm kernel: [ 565.305343] usb-storage: device found at 5
Dec 15 18:08:00 prizm kernel: [ 565.305346] usb-storage: waiting for device to settle before scanning
.....
Dec 15 18:08:52 prizm kernel: [ 617.293704] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:52 prizm kernel: [ 617.300326] scsi37674 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:52 prizm kernel: [ 617.300896] usb-storage: device found at 5
Dec 15 18:08:52 prizm kernel: [ 617.300899] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:52 prizm kernel: [ 617.307141] scsi37675 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:52 prizm kernel: [ 617.307842] usb-storage: device found at 5
Dec 15 18:08:52 prizm kernel: [ 617.307845] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:52 prizm kernel: [ 617.314106] scsi37676 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:52 prizm kernel: [ 617.314676] usb-storage: device found at 5
Dec 15 18:08:52 prizm kernel: [ 617.314679] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:52 prizm kernel: [ 617.321129] scsi37677 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:52 prizm kernel: [ 617.321703] usb-storage: device found at 5
Dec 15 18:08:52 prizm kernel: [ 617.321706] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:52 prizm kernel: [ 617.329121] scsi37678 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:52 prizm kernel: [ 617.329696] usb-storage: device found at 5
Dec 15 18:08:52 prizm kernel: [ 617.329699] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:52 prizm kernel: [ 617.335118] scsi37679 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:52 prizm kernel: [ 617.335698] usb-storage: device found at 5
Dec 15 18:08:52 prizm kernel: [ 617.335702] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:52 prizm kernel: [ 617.342546] scsi37680 : SCSI emulation for USB Mass Storage devices
Dec 15 18:08:52 prizm kernel: [ 617.343143] usb-storage: device found at 5
Dec 15 18:08:52 prizm kernel: [ 617.343146] usb-storage: waiting for device to settle before scanning
Dec 15 18:08:53 prizm kernel: [ 617.578512] usb 1-1: USB disconnect, address 5
This machine is running Ubuntu Gutsy, udev version 113-0ubuntu16. As the phone is new, I believe this is the first time I've attempted to connect it to this machine. I used to connect my old blackberry without problems on the same hardware, but that was a slightly older kernel (2.6.22?). This behavior repeated across system reboots, and could only be solved by disconnecting the device.
--
Matt LaPlante
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Matt LaPlante]

On Sat, 15 Dec 2007 18:46:34 -0500

Post by Martin Owens
The device continues to reset it's self, disable bcharge or
berry_charge kernel module from udev/blacklist and try and find out
why bcharge fails to set the phone correctly.

Sorry I have to plead a bit of ignorance here. I don't believe I'm using bcharge. I've got the berry_charge module built and loaded, which is the same as I used for the old blackberry. That's all I've needed in the past, so it's all I'm using now, and I had assumed it would support this device. I don't have any additional blackberry related software installed that I know of. Hence, I had assumed the problem was related to berry_charge, and I posted here.

The usb cable is known working, and the port is a dedicated usb port with no other connected devices.

As far as troubleshooting goes, I rebuilt with USB debugging support and tried again. I'll need guidance if I'm to gather additional information. The syslog output from connecting the device can be found here (much too long for pasting into email):

http://www.cyberdogtech.com/download/pub/berry_charge_debug.txt

Post by Martin Owens

Post by Matt LaPlante
This machine is running Ubuntu Gutsy, udev version 113-0ubuntu16. As the phone is new, I believe this is the first time I've attempted to connect it to this machine. I used to connect my old blackberry without problems on the same hardware, but that was a slightly older kernel (2.6.22?). This behavior repeated across system reboots, and could only be solved by disconnecting the device.
--
Matt LaPlante

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Martin Owens]

Post by Matt LaPlante
Sorry I have to plead a bit of ignorance here. I don't believe I'm using bcharge. I've got the berry_charge module built and loaded, which is the same as I used for the old blackberry. That's all I've needed in the past, so it's all I'm using now, and I had assumed it would support this device. I don't have any additional blackberry related software installed that I know of. Hence, I had assumed the problem was related to berry_charge, and I posted here.

no the berry_charge kernel module isn't up to date, bcharge is the
most advanced tool for managing the backberry range. various
blackberry ranges require different resets and different settings.

If you want to patch berry_charge with the bcharge logic, this would
help. but for all distributions I recommend removing berry_charge and
installing barry by default.

Best Regards, Martin Owens

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Greg KH]

Post by Martin Owens

Post by Matt LaPlante
Sorry I have to plead a bit of ignorance here. I don't believe I'm using bcharge. I've got the berry_charge module built and loaded, which is the same as I used for the old blackberry. That's all I've needed in the past, so it's all I'm using now, and I had assumed it would support this device. I don't have any additional blackberry related software installed that I know of. Hence, I had assumed the problem was related to berry_charge, and I posted here.

no the berry_charge kernel module isn't up to date, bcharge is the
most advanced tool for managing the backberry range. various
blackberry ranges require different resets and different settings.
If you want to patch berry_charge with the bcharge logic, this would
help. but for all distributions I recommend removing berry_charge and
installing barry by default.

Why? Why not just update the berry_charge module with the needed
information? How about sending such a patch to the current berry_charge
maintainer? :)

Or, if you really think we should be doing all of this in userspace, and
barry is good enough to be shipped in distros today, then can you send
me a pointer to the release you feel is stable for the new devices, and
a patch that removes berry_charge from the kernel?

Having two different packages fighting it out for things like this is
just not nice. Right now, the "simple" berry_charge module for just
charging the device seems the best thing, that way the berry userspace
program can then, if the user wants, come along and do more "advanced"
things to the device (syncing, changing modes, etc.)

thanks,

greg k-h

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Martin Owens]

Post by Greg KH
Having two different packages fighting it out for things like this is
just not nice. Right now, the "simple" berry_charge module for just
charging the device seems the best thing, that way the berry userspace
program can then, if the user wants, come along and do more "advanced"
things to the device (syncing, changing modes, etc.)

I agree, but there are complications, every time you have to set the
mode of the device it resets, causing the power management to screw
up; there are reasons the device setting and the power management were
put in the same code.

Weather it's a kernel module or the user space bcharge, I don't care.
What I do care for is that the bcharge program accounts for many more
phones than berry_charge. So while you've gone off on one explaining
how things should be, I've simply told you how things are

Your welcome to email Chris (barry) or who ever maintains the
berry_charge kernel module and get them to fix their code in the way
you require.

Best Regards, Martin Owens.

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Greg KH]

Post by Martin Owens

Post by Greg KH
Having two different packages fighting it out for things like this is
just not nice. Right now, the "simple" berry_charge module for just
charging the device seems the best thing, that way the berry userspace
program can then, if the user wants, come along and do more "advanced"
things to the device (syncing, changing modes, etc.)

I agree, but there are complications, every time you have to set the
mode of the device it resets, causing the power management to screw
up; there are reasons the device setting and the power management were
put in the same code.

I agree, that's why the kernel module should probably handle all of
this, right?

Post by Martin Owens
Weather it's a kernel module or the user space bcharge, I don't care.
What I do care for is that the bcharge program accounts for many more
phones than berry_charge. So while you've gone off on one explaining
how things should be, I've simply told you how things are
Your welcome to email Chris (barry) or who ever maintains the
berry_charge kernel module and get them to fix their code in the way
you require.

I maintain the berry_charge module, that's why I was asking for a patch
:)

thanks,

greg k-h

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel