Date: Mon, 02 Apr 2012 00:19:07 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: gnome <gnome@FreeBSD.org>, Joe Marcus Clarke <marcus@FreeBSD.org> Subject: Re: Fwd: Re: calibre: kindle usb connection problem Message-ID: <4F78C64B.8080704@FreeBSD.org> In-Reply-To: <201204012311.57974.hselasky@c2i.net> References: <4F749AD1.7020703@FreeBSD.org> <4F749FFD.7020707@FreeBSD.org> <4F775927.1030400@freebsd.org> <201204012311.57974.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
on 02/04/2012 00:11 Hans Petter Selasky said the following: > On Saturday 31 March 2012 21:21:11 Joe Marcus Clarke wrote: >> On 3/29/12 1:46 PM, Andriy Gapon wrote: >> >> I wonder if this is a conflict between what hal is doing when it probes >> the device and interface vs. what USB wants to do to attach the device. >> I'm copying hps to see if he can shed some light on this. hps, please >> see below where I attempt to highlight what hald is doing. From reading >> the USB code, I think hald might be triggering an error on attach and >> causing the USB stack to free the device. Perhaps some USB-level >> debugging is required. >> >> Joe >> >>> Not sure if the problem is caused by something in the device or by one of >>> the hal's utilities. >>> This is what I see in the system log: >>> Mar 29 20:37:20 trant kernel: ugen2.2: <Amazon> at usbus2 >>> Mar 29 20:37:20 trant kernel: umass0: <Mass Storage> on usbus2 >>> Mar 29 20:37:20 trant kernel: ugen2.2: <Amazon> at usbus2 (disconnected) >>> Mar 29 20:37:20 trant kernel: umass0: at uhub2, port 6, addr 2 >>> (disconnected) Mar 29 20:37:22 trant kernel: ugen2.2: <Amazon> at usbus2 >>> Mar 29 20:37:22 trant kernel: umass0: <Mass Storage> on usbus2 >>> Mar 29 20:37:22 trant kernel: da0 at umass-sim0 bus 0 scbus8 target 0 lun >>> 0 Mar 29 20:37:22 trant kernel: da0: <Kindle Internal Storage 0100> >>> Removable Direct Access SCSI-2 device >>> Mar 29 20:37:22 trant kernel: da0: 40.000MB/s transfers >>> Mar 29 20:37:22 trant kernel: da0: 3090MB (6328768 512 byte sectors: 255H >>> 63S/T 393C) >>> >>> Note how the umass driver attaches, then immediately detaches and two >>> seconds later attaches again. >>> Here's hald output from that period: >>> >>> 20:37:17.378 [I] hf-devd.c:316: received devd event: !system=DEVFS >>> subsystem=CDEV type=CREATE cdev=usb/2.2.0^M >>> 20:37:17.378 [I] hf-devd.c:316: received devd event: !system=DEVFS >>> subsystem=CDEV type=CREATE cdev=ugen2.2^M >>> 20:37:19.448 [I] hf-devd.c:316: received devd event: !system=DEVFS >>> subsystem=CDEV type=CREATE cdev=usb/2.2.1^M >>> 20:37:20.576 [I] hf-devd.c:316: received devd event: !system=USB >>> subsystem=DEVICE type=ATTACH ugen=ugen2.2 cdev=ugen2.2 vendor=0x1949 >>> product=0x0004 devclass=0x00 devsubclass=0x00 sernum="B008A0A00527517D" >>> release=0x0100 mode=host port=6 parent=ugen2.1^M >>> 20:37:20.577 [I] hf-usb2.c:213: received devd attach event, device >>> ugen=ugen2.2^M Run started hald-probe-usb2-device (20000) (0) ^M >>> ! full path is '/usr/local/libexec/hald-probe-usb2-device', program_dir >>> is '/usr/local/libexec'^M >> >> At this point, hald probes the ugen device and calls the following >> functions: >> >> libusb20_be_alloc_default >> libusb20_be_device_foreach >> libusb20_dev_get_bus_number >> libusb20_dev_get_address >> libusb20_dev_open >> libusb20_dev_get_device_desc >> libusb20_dev_get_config_index >> libusb20_dev_alloc_config >> libusb20_dev_req_string_simple_sync >> libusb20_dev_get_speed >> libusb20_dev_close >> libusb20_be_free >> >>> pid 70609: rc=0 signaled=0: /usr/local/libexec/hald-probe-usb2-device^M >>> 20:37:22.640 [I] hald.c:108: Added device to GDL; >> >> After the device probe runs, the interface prober will execute. These >> probe helpers run synchronously. >> >>> udi=/org/freedesktop/Hal/devices/usb_device_1949_4_B008A0A00527517D^M >>> Run started hald-probe-usb2-interface (20000) (0) ^M >> >> The interface prober runs the following functions: >> >> libusb20_be_alloc_default >> libusb20_be_device_foreach >> libusb20_dev_get_bus_number >> libusb20_dev_get_address >> libusb20_dev_get_config_index >> libusb20_dev_get_config_index > > Hi, > > I think you need to open the device to be allowed to call > libusb20_dev_req_string_simple_sync, like shown in the previous function call > list. > > Does that make sense to you? Not really... :-) How does that cause the disconnect and reconnect? [snip] -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F78C64B.8080704>