Fwd: Re: calibre: kindle usb connection problem

[Andriy Gapon]

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