Re: Gnome Pilot Causing USB Drive problems (version 2.0.10)

[JP Rosevear <jpr novell com>]

On Mon, 2004-09-06 at 10:30 -0500, Sam Williams wrote:
> On Sun, 2004-09-05 at 22:59, JP Rosevear wrote:
> > On Wed, 2004-09-01 at 21:52 -0500, Sam Williams wrote:
> > > I'm running Fedora Core 2, but I've been having this problem at least
> > > since Fedora Core 1. First, of all I have a Sony Clie that takes an act
> > > of God to hotsync using gpilotd. I've found that I can general
> > > accomplish the task if I stop gpilotd, start the hotsync from the clie,
> > > then restart gpilotd. May take a couple of times to get it to sync...
> > > 
> > > However two days ago I discovered that gpilotd is causing problems with
> > > my usb drives. I can easy mount and use any usbdrive that is 128 Mbytes
> > > or less with gpilotd running. If gpilotd is running and I try to mount a
> > > 256 Mbyte usbdrive the story is different. It tries multiple times to
> > > mount and the ultimately times out with an error. In the rare occasion
> > > that it will mount the device is mounted read only. 
> > > 
> > > If I stop or pause gpilotd and then try to use a 256 Mbyte usbdrive it
> > > will work as flawlessly as the 128 Mbyte one. Now for the record this
> > > behavior is 100% reproducible and has been demonstrated with both a
> > > SanDisk Minicruiser and a Lexar Jumpdrive, both are 256 Mbytes in size.
> > > 
> > > There is a serious problem with gpilotd that would allow this
> > > interaction to occur. First, the daemon doesn't allow easy or flawless
> > > hotsyncing for my Clie and now I find that it gets in the way of normal
> > > usbdrive operation....
> > > 
> > > Please look into this and see where the problem might exist.
> > 
> > Gnome Pilot does not interact directly with USB in the kernel, it simply
> > accesses a serial to usb device bridge provided by the visor module, the
> > existence of which it detects by polling /proc/bus/usb/devices and
> > matching pilot vendor/product ids.  I'm not clear why you think this
> > behaviour is the fault of gnome-pilot (unless the usb drives are
> > stupidly reporting a matching product/vendor id to some pilot device).
> 
> Actually its very simple. I thought my initial documentation explained
> it, but I'll try to be a little more succinct. If I try to mount a
> usbdrive of 128 Mbytes or less, I can mount and use it regardless of
> what other things are running on my system. If I try and mount a
> usbbrive of 256Mbytes while I have gpilotd running I get tons of
> messages suggesting a control timeout on ep0in. It might eventually
> mount, but if it does the device is read only and can not be used. 
> 
> If I kill or pause gpilotd then I can mount and use all usbdrives
> without issue. Why do I think gpilotd is the problem? If it runs things
> don't work, if it isn't running everything works.

I understood that from your first message, but it doesn't necessarily
mean its the fault of gnome-pilot :-).  As I tried to explain, gnome-
pilot simply accesses the device (in the same manner as pilot-link I
might add, since it uses pilot-link once it detects the device via
polling).  So, it would narrow the problem to polling. Some quick
googling found http://www.mail-archive.com/linux-usb-
users lists sourceforge net/msg11221.html

However, I have no idea why this would be a problem since gnome pilot
opens the file in "r" mode and always closes it after checking for the
device.  Its seems goofy if this affects mass storage mounting - maybe
something in the kernel is trying access that file in some exclusive
manner and error out?  However that wouldn't explain why a 128MB device
works and a 256MB device doesn't.

Does the gpilotd debug spew provide any insight?  What is the gnome-
pilot configuration you are using?  It seems relevant that in other
googling these types of errors didn't start appearing until kernel 2.6
showed up (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128602).

I dug the warning message out of the 2.6.5 kernel source tree
(drivers/usb/core/message.c:timeout_kill) but saw nothing obvious to me,
I'll see about pinging a kernel hacker tomorrow.

-JP
-- 
JP Rosevear <jpr novell com>
Novell, Inc.