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

[Sam Williams <sam-williams insightbb com>]

On Mon, 2004-09-06 at 21:37, JP Rosevear wrote:
> 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

That certainly seems like a similar problem. 
> 
> 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.

The size issue I couldn't explain either, unless the size translated
into some type of additional device processing time. I was thinking that
perhaps it could be some type of time dependent issue... 

> 
> 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).

No messages to speak of. I do have a question about this issue though.
Is it possible to tell gpilotd to enhance its log messages? Is there an
additional commandline flag I can set to increase the debugging?

Dang.... I know in one post somewhere, I noted my kernel version....
I've had problems with this issue only with 2.6.X kernels. My current
kernel is the default from Fedora 2.8.6.1-521. Normally I don't use the
vendor kernels, but I've had problems with the pda since I made the
break to the 2.6 tree over a year ago. 

Coincident to the upgrade to 2.6 I also upgraded my pda to the Sony
Clie. Perhaps it was bad timing all the way around, but since upgrading
I've had consistent trouble hotsyncing, and the other issue I just
pinned down a week or so back..
> 
> 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.

Excellent news. I really do appreciate the help. I tend to get
frustrated because it doesn't seem like there is a way to acquire
additional information.... ie enhanced logging, etc....


-- 
Sam Williams                                             samurai acm org
+----------------------------------------------------------------------+
+"It is easy to be blinded to the essential uselessness of computers   +
+ by the sense of accomplishment you get from getting them to work at  +
+ all."                                                                +
+                                                     - Douglas Adams  +
+----------------------------------------------------------------------+