[rivviepop]

Every now and then when I plug in my Pearl, it seems to not present itself to the system as a mass storage device; if I pull out the cable and wait a few seconds, then plug it back in it usually starts working.

Obviously it can be a kernel/usb bug but I really don't know but I can share the following observations:

- on FC6 if the device is set to Yes, it happens a lot more. If set to Prompt, it almost never happens

- on FC5 it seems to happen almost all the time, but every now and again it'll work as expected on first-plug

I don't think it's bcharge related as I don't even have that installed on the FC5 workstation (at work). My only thought is if it's in Prompt mode (regarding FC6) that might slow down the process enough that the kernel can catch up or whatnot.

Happening to anyone else, you folks on Ubuntu and SuSE?

[hrhenry]

Originally Posted by rivviepop

Every now and then when I plug in my Pearl, it seems to not present itself to the system as a mass storage device; if I pull out the cable and wait a few seconds, then plug it back in it usually starts working.

Obviously it can be a kernel/usb bug but I really don't know but I can share the following observations:

- on FC6 if the device is set to Yes, it happens a lot more. If set to Prompt, it almost never happens

- on FC5 it seems to happen almost all the time, but every now and again it'll work as expected on first-plug

I don't think it's bcharge related as I don't even have that installed on the FC5 workstation (at work). My only thought is if it's in Prompt mode (regarding FC6) that might slow down the process enough that the kernel can catch up or whatnot.

Happening to anyone else, you folks on Ubuntu and SuSE?

I sometimes get the same thing.

I really think they've changed they way they (RIM) handle USB connections. Back when I had a 7100, I could easily connect that through VMWare and run App loader, sync, backups, etc. with no problem. Can't do it with the Pearl. The only thing I have managed to do is occasionally connect as a mass storage device, and run into the same symptoms you do, on both Ubuntu and SUSE (well, the SUSE laptop was stolen, so now it's just Ubuntu ) I'm sure it has something to do with the fact that you can now connect as mass storage device, whereas pre-Pearl days you couldn't.

R.
==

[LunkHead]

Same situation here on Suse 10.2... I got it to recognize the card but it really is hit and miss.....

[erroneus]

I just got myself a 1GB memory card ($25 at CompUSA!) and dmesg shows the device but goes no further in attempting to mount it. I did a "fdisk /dev/sda" and got an error simply stating "unable to open /dev/sda" without a reason why...

I'm gonna yank the cable for a minute or two and see what happens next...

Okay, here's what happened when I pulled the cable and put it back in:

usb-storage: device scan complete
usb 4-6.1: USB disconnect, address 30
usb 4-6.1: new full speed USB device using ehci_hcd and address 31
usb 4-6.1: config index 0 descriptor too short (expected 69, got 32)
usb 4-6.1: configuration #1 chosen from 1 choice
scsi12 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 31
usb-storage: waiting for device to settle before scanning
usb 4-6.1: usbfs: interface 0 claimed by usb-storage while 'bcharge' sets config #1
usb 4-6.1: reset full speed USB device using ehci_hcd and address 31
usb 4-6.1: usbfs: interface 0 claimed by usb-storage while 'bcharge' sets config #1
usb 4-6.1: reset full speed USB device using ehci_hcd and address 31
usb 4-6.1: device firmware changed
usb 4-6.1: USB disconnect, address 31
usb 4-6.1: new full speed USB device using ehci_hcd and address 32
usb 4-6: clear tt 1 (8200) error -32
usb 4-6: clear tt 1 (8200) error -32
usb 4-6: clear tt 1 (8200) error -32
usb 4-6.1: new full speed USB device using ehci_hcd and address 33
usb 4-6.1: config 1 has 1 interface, different from the descriptor's value: 2
usb 4-6.1: config 1 interface 0 altsetting 0 has 2 endpoint descriptors, different from the interface descriptor's value: 4
usb 4-6.1: configuration #1 chosen from 1 choice
usb 4-6.1: USB disconnect, address 33
usb 4-6.1: new full speed USB device using ehci_hcd and address 34
usb 4-6.1: configuration #1 chosen from 1 choice
scsi13 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 34
usb-storage: waiting for device to settle before scanning
scsi 13:0:0:0: Direct-Access     RIM      BlackBerrySdCard 0001 PQ: 0 ANSI: 4 CCS
sd 13:0:0:0: Attached scsi removable disk sda
sd 13:0:0:0: Attached scsi generic sg0 type 0
usb-storage: device scan complete

The results are very consistant.

Further testing with WindowsXP running in VMware also shows the mass storage device as inaccessible.

** OOOPS! **

I didn't enable the USB mass storage option by going to:

Options -> Advanced Option -> Media Card -> Auto Enable Mass Storage Mode When Connected: Yes/Prompt

[HuwSy]

Calling bcharge via udev script or in the terminal on my 7100 only works on the 2nd connection. The 1st loads the modules but doesnt initiate them in time for the bb's handshake. then by the 2nd connection there already loaded and manage the handshake. I think the only way around this would be to keep the modules loaded in memory or to slow the device down, which is what the prompt on mass storage option will be doing. Unless anyone can change the code so that the handshake is a seporate module which gets called into memory and executed while the other parts of the drivers are still loading.

[rivviepop]

Originally Posted by HuwSy

Calling bcharge via udev script or in the terminal on my 7100 only works on the 2nd connection. The 1st loads the modules but doesnt initiate them in time for the bb's handshake. then by the 2nd connection there already loaded and manage the handshake.

I think you meant 8100 above, yes? Have you tried setting your handset to Prompt mode, rather than Yes, to allow a pause to naturally happen? I've gotten much better results (probably for the reason you outline above) by just leaving my handset in Prompt mode, then manually clicking Yes to mount the disk if desired. This adds that crucial 1 or 2 second pause for usb-storage (&c) to load...

[HuwSy]

Nah, i mean the 7100, its not specifically a mass storage problem its a delay in loading kernel modules and apps such as bcharge. Hopefully if bcharge and parts of barry can be made into a kernel patchs or propper (.ko) modules then they should load fast enough to remove this problem.

[rivviepop]

Originally Posted by HuwSy

Nah, i mean the 7100, its not specifically a mass storage problem its a delay in loading kernel modules and apps such as bcharge. Hopefully if bcharge and parts of barry can be made into a kernel patchs or propper (.ko) modules then they should load fast enough to remove this problem.

OK now you have me confused -- what modules are getting loaded for the 7100 on your system? On mine nothing but usb-storage (and the associated vfat, etc.) modules are loaded for mass storage. bcharge doesn't do *anything* except send a usb control message down the pipe, it has nothing module related about it. With the 7100 nothing should happen - it's just a raw usb device with a /dev entry, waiting to be talked to by some other app. I need a better explanation from you about these mysterious kernel modules...

I smell something wrong with your system. (and this is way off thread topic now, nothing to do with mass storage support )

[HuwSy]

There most be something else going on with bcharge, lika a handshake or that it must up the power within x seconds of connection, otherwise it should be exercutable at any time once the phone is connected and just work, however it only works if its executed slightly before making the connection either manually or by double connecting my phone. So im assuming the power needs to be upped within a certain time of connection for the phone to recognise it. As with the mass storage the handshake should be executed within a certain time frame of connection, the only way i think this could be achieved would be to make parts of the barry project into kernal level modules as apposed to udev loading.

[erroneus]

You know, since I resolved the fact that I had USB mass storage turned off, I haven't noticed any problems with erratic access at all. That "bcharge" thing was an amazing enabler.

[rivviepop]

Originally Posted by erroneus

You know, since I resolved the fact that I had USB mass storage turned off, I haven't noticed any problems with erratic access at all. That "bcharge" thing was an amazing enabler.

Check the sourceforge patches section, new barry.spec to build everything in the project into RPM files. One of the updates are some new udev/console rules to better handle the 8100 and 8800 devices, including setting the ownership in /dev/ to yourself upon device-plugin.

(note: btool/libbarry in 0.6 is broken, you'll need to roll back to something earlier or wait for better fixes in CVS)