From owner-freebsd-gnome@FreeBSD.ORG Sun Apr 1 21:19:13 2012 Return-Path: Delivered-To: gnome@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22FC31065670; Sun, 1 Apr 2012 21:19:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 481038FC0C; Sun, 1 Apr 2012 21:19:12 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA16149; Mon, 02 Apr 2012 00:19:08 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SESB1-000DFU-QN; Mon, 02 Apr 2012 00:19:07 +0300 Message-ID: <4F78C64B.8080704@FreeBSD.org> Date: Mon, 02 Apr 2012 00:19:07 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: Hans Petter Selasky References: <4F749AD1.7020703@FreeBSD.org> <4F749FFD.7020707@FreeBSD.org> <4F775927.1030400@freebsd.org> <201204012311.57974.hselasky@c2i.net> In-Reply-To: <201204012311.57974.hselasky@c2i.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: gnome , Joe Marcus Clarke Subject: Re: Fwd: Re: calibre: kindle usb connection problem X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 21:19:13 -0000 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: at usbus2 >>> Mar 29 20:37:20 trant kernel: umass0: on usbus2 >>> Mar 29 20:37:20 trant kernel: ugen2.2: 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: at usbus2 >>> Mar 29 20:37:22 trant kernel: umass0: 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: >>> 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