From owner-freebsd-usb@FreeBSD.ORG Sun Sep 20 20:42:20 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5DA2106566C for ; Sun, 20 Sep 2009 20:42:20 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id 83FA68FC0A for ; Sun, 20 Sep 2009 20:42:20 +0000 (UTC) Received: from mdaemon.pldrouin.net (CPE0023695b905f-CM001a666aca96.cpe.net.cable.rogers.com [99.246.67.95]) by smtp.cyberfingers.net (Postfix) with ESMTP id 2A439AB6C6F for ; Sun, 20 Sep 2009 16:22:45 -0400 (EDT) Message-ID: <4AB68F11.2080202@pldrouin.net> Date: Sun, 20 Sep 2009 16:22:41 -0400 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: freebsd-usb@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Are asynchronous transfers supported by uftdi? X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2009 20:42:20 -0000 Hi, Are asynchronous transfers supported by uftdi? I am trying to modify a linux tool (tbancontrol) to control a fan controller on FreeBSD and SIGIO behaviour seems to be a bit random on FreeBSD compared to linux. Here are the main lines of the tool related to initialization: tban->port = open("/dev/ttyU0", O_RDWR | O_NOCTTY | O_NONBLOCK); ... saio.sa_handler = tban_signal_handler_IO; result = sigemptyset(&saio.sa_mask); saio.sa_flags = 0; result = sigaction(SIGIO, &saio, NULL); result = fcntl(tban->port, F_SETFL, FASYNC); ... tcgetattr(tban->port, &(tban->oldtio)); ... memcpy(&newtio,&tban->oldtio,sizeof(struct termios)); /*I added this line to avoid the error EINVAL when calling tcsetattr below. This is probably not enough to set all flags properly :S */ ... newtio.c_cflag = intToBaud(tban->baudrate) /*baudrate is 19200*/ | CRTSCTS | intToDataBits(tban->databits) /*databits is 8*/ | intToStopBits(tban->stopBits) /*stopBits is 0*/ | CLOCAL | CREAD; newtio.c_iflag = IGNPAR; newtio.c_oflag = 0; newtio.c_lflag = 0; newtio.c_cc[VMIN] = 1; newtio.c_cc[VTIME] = 0; ... result = tcsetattr(tban->port, TCSANOW, &newtio); */*SIGIO is generated (?)*/ * ... result = write(tban->port, sndBuf, cmdLen); /*request device status*/ ... /*Initialize data availability flag to false*/ /*Wait in a loop using sleep until availability flag is set to true by the callback function*/ /*SIGIO is generated */ bytesread = read(tban->port, local_buf, sizeof(local_buf)); */*bytesread is -1, EINTR is generated*/ *Although this code works fine with Linux, is there something in it that is missing for FreeBSD? Or is it a bug/limitation of the uftdi driver? Thanks a lot! From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 01:44:28 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D211F1065670 for ; Mon, 21 Sep 2009 01:44:28 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id 916A58FC12 for ; Mon, 21 Sep 2009 01:44:28 +0000 (UTC) Received: from mdaemon.pldrouin.net (CPE0023695b905f-CM001a666aca96.cpe.net.cable.rogers.com [99.246.67.95]) by smtp.cyberfingers.net (Postfix) with ESMTP id 21B5FAB6C12; Sun, 20 Sep 2009 21:44:26 -0400 (EDT) Message-ID: <4AB6DA79.7050209@pldrouin.net> Date: Sun, 20 Sep 2009 21:44:25 -0400 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: freebsd-usb@freebsd.org, hselasky@c2i.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 01:44:28 -0000 Hi, I am also having troubles with the uftdi driver on 8.0-BETA4. I am trying to use a fan controller (mCubed bigNG) that uses a FT232BL chip and it does not seem to be responding on FreeBSD 8.0 while the same code works perfectly on Linux (I have not tried the code on RELENG_7 yet but I could install it if necessary). Here is the very simple code I am using for testing: #include #include #include #include #include int main(); #define DEV "/dev/ttyU0" #define TBAN_SER_SOURCE1 0x05 /* Primary source */ #define TBAN_SER_SOURCE2 0x06 /* Alternative source (miniNG...) */ #define TBAN_SER_REQUEST 0x36 int main() { int fd; int result; struct termios oldtio, newtio; unsigned char buf[285]; printf("Opening device\n"); fd=open(DEV, O_RDWR | O_NOCTTY); if(fd<0) { perror(DEV); return 1; } result=tcgetattr(fd,&oldtio); if(result<0) { perror("tcgetattr"); return 1; } memcpy(&newtio,&oldtio,sizeof(struct termios)); newtio.c_cflag = B19200 | CRTSCTS | CS8 | CREAD; newtio.c_iflag = IGNPAR; newtio.c_oflag = 0; newtio.c_lflag = 0; newtio.c_cc[VMIN] = 1; newtio.c_cc[VTIME] = 0; result=tcflush(fd, TCIFLUSH); if(result<0) { perror("tcflush"); return 1; } result=tcsetattr(fd,TCSANOW,&newtio); if(result<0) { perror("tcsetattr"); return 1; } sleep(1); printf("Performing initial query\n"); buf[0]=TBAN_SER_SOURCE1; buf[1]=TBAN_SER_REQUEST; printf("Requesting status\n"); result=write(fd,buf,2); if(result<0) { perror("write"); return 1; } sleep(1); printf("Reading status\n"); result=read(fd,buf,32); if(result<0) { perror("read"); return 1; } result=tcsetattr(fd,TCSANOW,&oldtio); if(result<0) { perror("tcsetattr"); return 1; } result=close(fd); if(result<0) { perror("close"); return 1; } return 0; } It hangs while reading independently of the number of bits I am reading. Here is the output from dmesg when I load the uftdi module: Sep 20 21:31:31 ldaemon kernel: uftdi0: on usbus6 Sep 20 21:31:31 ldaemon kernel: ucom_attach_tty:317: tp = 0xffffff001f12b400, unit = 0 Sep 20 21:31:31 ldaemon kernel: ucom_attach_tty:346: ttycreate: U0 Sep 20 21:31:34 ldaemon root: Unknown USB device: vendor 0x051d product 0x0002 bus uhub0 Here is the output in /var/log/messages when I enable the debug output for ucom and uftdi: Sep 20 21:33:30 ldaemon kernel: ucom_open:554: tp = 0xffffff001f12b400 Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = 1 Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_break:816: onoff = 0 Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 Sep 20 21:33:30 ldaemon kernel: ucom_status_change:901: Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 Sep 20 21:33:30 ldaemon kernel: uftdi_pre_param:653: Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = 1 Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_cfg_open:520: Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_open:354: Sep 20 21:33:30 ldaemon kernel: uftdi_read_callback:459: status change msr=0xf0 (0x00) lsr=0x60 (0x00) Sep 20 21:33:30 ldaemon kernel: ucom_status_change:901: Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 lsr=0x60 Sep 20 21:33:30 ldaemon kernel: ucom_cfg_status_change:887: DCD changed to 1 Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 Sep 20 21:33:30 ldaemon kernel: uftdi_pre_param:653: Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 lsr=0x60 Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: Sep 20 21:33:30 ldaemon kernel: ucom_get_data:1064: cnt=0 Sep 20 21:33:31 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 Sep 20 21:33:32 ldaemon kernel: ucom_outwakeup:1009: sc = 0xffffff001f12ac58 Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: cnt=2 Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: cnt=0 I really need to get this working so I am ready to test things as much as I can... Thanks a lot! Pierre-Luc Drouin From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 04:29:23 2009 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5491F106566B; Mon, 21 Sep 2009 04:29:23 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2C3528FC0A; Mon, 21 Sep 2009 04:29:23 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8L4TMV3088350; Mon, 21 Sep 2009 04:29:22 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8L4TM69088346; Mon, 21 Sep 2009 04:29:22 GMT (envelope-from linimon) Date: Mon, 21 Sep 2009 04:29:22 GMT Message-Id: <200909210429.n8L4TM69088346@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-usb@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: usb/138882: [ohci] [panic] Can't install FreeBSD 7.2 due to ohci panic X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 04:29:23 -0000 Old Synopsis: Can't install FreeBSD 7.2 New Synopsis: [ohci] [panic] Can't install FreeBSD 7.2 due to ohci panic Responsible-Changed-From-To: freebsd-amd64->freebsd-usb Responsible-Changed-By: linimon Responsible-Changed-When: Mon Sep 21 04:28:05 UTC 2009 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=138882 From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 04:29:37 2009 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D55A1065672; Mon, 21 Sep 2009 04:29:37 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D9A068FC0A; Mon, 21 Sep 2009 04:29:36 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8L4Tan2088397; Mon, 21 Sep 2009 04:29:36 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8L4TaSA088393; Mon, 21 Sep 2009 04:29:36 GMT (envelope-from linimon) Date: Mon, 21 Sep 2009 04:29:36 GMT Message-Id: <200909210429.n8L4TaSA088393@freefall.freebsd.org> To: kazham@mail.ru, linimon@FreeBSD.org, freebsd-usb@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: usb/138882: [ohci] [panic] Can't install FreeBSD 7.2 due to ohci panic X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 04:29:37 -0000 Synopsis: [ohci] [panic] Can't install FreeBSD 7.2 due to ohci panic State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Mon Sep 21 04:29:25 UTC 2009 State-Changed-Why: Note that feedback was requested. http://www.freebsd.org/cgi/query-pr.cgi?pr=138882 From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 08:10:04 2009 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13CE3106566B for ; Mon, 21 Sep 2009 08:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DC6B88FC12 for ; Mon, 21 Sep 2009 08:10:03 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8L8A3Yr045327 for ; Mon, 21 Sep 2009 08:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8L8A3Le045326; Mon, 21 Sep 2009 08:10:03 GMT (envelope-from gnats) Date: Mon, 21 Sep 2009 08:10:03 GMT Message-Id: <200909210810.n8L8A3Le045326@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: =?ISO-8859-15?Q?Dorian_B=FCttner?= Cc: Subject: Re: usb/138882: [ohci] [panic] Can't install FreeBSD 7.2 due to ohci panic X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-15?Q?Dorian_B=FCttner?= List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 08:10:04 -0000 The following reply was made to PR usb/138882; it has been noted by GNATS. From: =?ISO-8859-15?Q?Dorian_B=FCttner?= To: bug-followup@FreeBSD.org, kazham@mail.ru Cc: Subject: Re: usb/138882: [ohci] [panic] Can't install FreeBSD 7.2 due to ohci panic Date: Mon, 21 Sep 2009 09:34:41 +0200 1) dup, see here: http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/107827 2) actually, I use a kernel with everything usb disabled, then load related modules via kldload-instructions in /etc/rc. That is somewhat working, or I can boot without keyboard attached, then once up reattach everything. From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 11:07:08 2009 Return-Path: Delivered-To: freebsd-usb@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28FDF106568B for ; Mon, 21 Sep 2009 11:07:08 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1685D8FC1C for ; Mon, 21 Sep 2009 11:07:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8LB78J3030461 for ; Mon, 21 Sep 2009 11:07:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8LB77M2030457 for freebsd-usb@FreeBSD.org; Mon, 21 Sep 2009 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Sep 2009 11:07:07 GMT Message-Id: <200909211107.n8LB77M2030457@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-usb@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-usb@FreeBSD.org X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 11:07:08 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o usb/138915 usb [patch][usb8][usb67] add support for SheevaPlug serial o usb/138904 usb [rum] unpluging USB wifi card panics system f usb/138882 usb [ohci] [panic] Can't install FreeBSD 7.2 due to ohci p o usb/138879 usb [uftdi] [patch] Patch to add support for CTI USB-Mini o usb/138798 usb 8.0-BETA4 can't boot from USB flash drive o usb/138675 usb [usb8] [panic] page fault, perhaps in USB o usb/138659 usb [usb8][uftdi] driver broken in RELENG_8/CURRENT o usb/138563 usb [usb8] [patch] Increase buffer sizes to accomodate lon o usb/138389 usb [usb8] [patch] NULL pointer dereference in usb_endpoin o usb/138175 usb [usb67] [boot] System cannot boot, when USB reader wit o usb/138172 usb Additional dev id for u3g (Option mini PCIe) o usb/138138 usb Novatel U760 for u3g (Verizon and Bell Canada) o usb/138124 usb [usb8] Axed uaudio functionality in the usbng (alterna o usb/138119 usb MultiBay CDROM (propably on USB bus) is not recognized o usb/137872 usb slow booting on usb flash drive f usb/137848 usb Page fault when using an USB bluetooth adapter o usb/137806 usb [ukbd] USB keyboard doesn't work until it's unplugged o usb/137763 usb [usb67][ukbd] Logitech wireless keyboard media keys no o usb/137616 usb [usb67][usb8][usbdevs] [patch]: usbdevs update: Please o usb/137377 usb [usb8] Support for Huawei E180 o usb/137341 usb [usb8][rum] driver if_rum doesn't work at all and thro p usb/137226 usb [usb67][patch] quirk for Philips extern USB disk o usb/137191 usb [usb8][patch] export ums(4) output report parser data o usb/137190 usb [usb8][patch] inhibit spurious button releases for som o usb/137189 usb [usb8][patch] create and use sysctl nodes for HID repo p usb/137188 usb [usb8][patch] correctly handle USB report descriptors o usb/137129 usb SteelSeries Ikari USB laser mouse not attaching o usb/137035 usb Sony cyber-shot DSC-P72 not accessible - cam quirks p usb/136761 usb [usbdevs][usb67][patch] Teach usbdevs / u3g(4) about H o usb/135938 usb [aue] aue driver only passes traffic in promisc mode f usb/135857 usb RTL8187 Wireless Adapter o usb/135575 usb [usbdevs] [patch] Add HTC Wizard phone vid/pid informa o usb/135542 usb [keyboard] boot loader does not work with a usb keyboa p usb/135372 usb [usb67][umass] Quirk report for Teclast TL-C300 usb me o usb/135348 usb [umass] USB Drive Hangs with ZFS (JMicron USB2/eSata) o usb/135206 usb machine reboots when inserted USB device o usb/135200 usb SAMSUNG i740 usb mass: Synchronize cache failed, statu o usb/135182 usb UMASS quirk - Olympus FE20 camera o usb/134950 usb Lowering DTR for USB-modem via ubsa is not possible o usb/134633 usb Add support for WILLCOM03(SHARP smart phone) o usb/134631 usb [usbdevs] [patch] WiSPY DBx support requires usb tweak o usb/134299 usb Kernel Panic plugging in MF626 USB UMTS Stick u3g o usb/134193 usb System freeze on usb MP3 player insertion o usb/134117 usb [Patch] Add support for 'Option GlobeTrotter HSDPA Mod o usb/134085 usb [umass] Adding usb quirk for Sony USB flash drive o usb/133989 usb [newusb] [ukbd] USB keyboard dead at mountroot> prompt o usb/133712 usb [ural] [patch] RE: Fixed an issue with ural(4) that wa o usb/133390 usb umass crashes system in 7.1 when Olympus D-540 attache o usb/133296 usb [rum] driver not working properly in hostap mode p usb/132799 usb [usb][patch]GENESYS USB2IDE requires NO_SYNCHRONIZE_CA o usb/132785 usb [usb] [patch] Gemtech remote powersocket is classed as o usb/132594 usb USB subsystem causes page fault and crashes o usb/132312 usb Xorg 7.4 halts USB controller o usb/132080 usb [patch] [usb] [rum] Kernel panic after NOMEM caused by o usb/132066 usb [ukbd] Keyboard failure USB keyboard DELL 760 o usb/132036 usb [panic] page fault when connecting Olympus C740 camera o usb/131912 usb [uslcom] [patch] New devices using Silicon Labs chips o usb/131900 usb [usbdevs] [patch] Additional product identification co o usb/131583 usb [umass] Failure when detaching umass Device o usb/131576 usb [aue] ADMtek USB To LAN Converter can't send data o usb/131521 usb Registering Belkin UPS to usb_quirks.c o usb/131123 usb [patch] re-add UQ_ASSUME_CM_OVER_DATA USB quirk o usb/131074 usb no run-time detection of usb devices plugged into exte o usb/130736 usb Page fault unplugging USB stick o usb/130325 usb [usb] [patch] fix tools/tools/usb/print-usb-if-vids.sh o usb/130230 usb Samsung Electronics YP-U3 does not attach in 7.1-RELEA o usb/130208 usb Boot process severely hampered by umass0 error o usb/130122 usb [newusb] DVD drive detects as 'da' device o usb/129945 usb [usbdevs] [patch] add u3g support for Longcheer WM66 U o usb/129766 usb [usb] plugging in usb modem HUAWEI E226 panics system o usb/129758 usb [uftdi] [patch] add Pyramid LCD usb support o usb/129673 usb [uhci] uhci (uhub) confused on replugging USB 1.1 scan o usb/129522 usb [ubsa] [patch] add support for ZTE AC8700 modem o usb/129500 usb [umass] [panic] FreeBSD Crashes when connecting SanDis o usb/129311 usb [usb] [panic] Instant crash with an USB card reader o usb/129251 usb [usbdevs] [patch] Liebert UPS being assigned uhid and o usb/129173 usb [uplcom] [patch] Add support for Corega CG-USBRS232R a s usb/128990 usb [usb] u3g does not handle RTS/CTS available on for exa o usb/128977 usb [usb] [patch] uaudio is not full duplex o usb/128803 usb [usbdevs] [patch] Quirk for I-Tuner Networks USBLCD4X2 o usb/128485 usb [umodem] [patch] Nokia N80 modem support o usb/128425 usb [umass] Cannot Connect Maxtor Onetouch 4 USB drive o usb/128418 usb [panic] [rum] loading if_rum causes panic, looks like o usb/128324 usb [uplcom] [patch] remove baud rate restriction for PL23 o usb/127980 usb [umass] [patch] Fix Samsung YP U2 MP3 player on 7.x an o usb/127926 usb [boot] USB Timeout during bootup s usb/127549 usb [umass] [patch] Meizu MiniPlayer M6 (SL) requires some s usb/127453 usb [request] ubsa, uark, ubser, uftdi, and friends should o usb/127423 usb [boot] BTX halted on Gigabyte GA-MA69VM-S2 / AMD Sempr o usb/127342 usb [boot] [panic] enabling usb keyboard and mouse support o usb/127248 usb [ucom] panic while uplcom devices attaach and detach o usb/127222 usb [ohci] Regression in 7.0 usb storage generic driver o usb/126884 usb [ugen] [patch] Bug in buffer handling in ugen.c o usb/126848 usb [usb]: USB Keyboard hangs during Installation o usb/126740 usb [ulpt] doesn't work on 7.0-RELEASE, 10 second stall be o usb/126519 usb [usb] [panic] panic when plugging in an iphone o kern/126396 usb [panic] kernel panic after unplug USB Bluetooth device o usb/125736 usb [ukbd] [hang] system hangs after AT keyboard detect if o usb/125631 usb [ums] [panic] kernel panic during bootup while 'Logite o usb/125510 usb [panic] repeated plug and unplug of USB mass storage d o usb/125450 usb [panic] Removing USB flash card while being accessed c p usb/125264 usb [patch] sysctl for set usb mouse rate (very useful for o usb/125238 usb [ums] Habu Mouse turns off in X o usb/125088 usb [keyboard] Touchpad not detected on Adesso AKB-430UG U o usb/124980 usb [panic] kernel panic on detaching unmounted umass devi o kern/124777 usb [ucom] USB cua devices don't revert to tty devices whe o usb/124758 usb [rum] [panic] rum panics SMP kernel o usb/124708 usb [panic] Kernel panic on USB KVM reattach o usb/124604 usb [ums] Microsoft combo wireless mouse doesn't work o kern/124130 usb [usb] gmirror fails to start usb devices that were pre o usb/123969 usb [usb] Supermicro H8SMi-2 usb problem: port reset faile o usb/123714 usb [usb] [panic] Panic when hald-storage-probe runs with o usb/123691 usb usbd(8): usbd hangs o usb/123690 usb [usb] [panic] Panic on USB device insertion when usb l o usb/123611 usb [usb] BBB reset failed, STALLED from Imation/Mitsumi U o usb/123509 usb [umass] continuous reset Samsung SGH-G600 phone o usb/123352 usb [usbdevs] [patch] Add Option GTMAX3.6/7.2 and Quallcom o usb/123351 usb [usbdevs] [patch] Add Reiner SCT cyberJack, Omnikey [2 o usb/122992 usb [umass] [patch] MotoROKR Z6 Phone not recognised by um o usb/122956 usb [ubsa] [patch] add support for Novatel Wireless XU870 o usb/122936 usb [ucom] [ubsa] Device does not receive interrupt o usb/122905 usb [ubsa] [patch] add Huawei E220 to ubsa o usb/122819 usb [usb] [patch] Patch to provide dynamic additions to th o usb/122813 usb [udbp] [request] udbp driver should be removed in favo o usb/122621 usb [new driver] [patch] New driver for Sierra Wireless 3G o usb/122547 usb [ehci] USB Printer not being recognized after reboot o usb/122539 usb [ohci] [panic] AnyDATA ADU-E1000D - kernel panic: ohci o usb/122483 usb [panic] [ulpt] Repeatable panic in 7.0-STABLE o usb/122119 usb [umass] umass device causes creation of daX but not da o usb/122025 usb [uscanner] [patch] uscanner does not attach to Epson R o usb/121755 usb [ohci] [patch] Fix panic after ohci/uhub cardbus devic o usb/121734 usb [ugen] ugen HP1022 printer device not working since up o usb/121708 usb [keyboard] nforce 650i mobo w/ usb keyboard infinite k o usb/121474 usb [cam] [patch] QUIRK: SAMSUNG HM250JI in LaCie usb hard o usb/121426 usb [patch] [uscanner] add HP ScanJet 3570C o usb/121275 usb [boot] [panic] FreeBSD fails to boot with usb legacy s o usb/121232 usb [usb] [panic] USB CardBus card removal causes reboot s p usb/121184 usb [uipaq] [patch] add ids from linux ipaq driver (plus a o usb/121169 usb [umass] Issues with usb mp3 player o usb/121045 usb [uftdi] [patch] Add support for PC-OP-RS1 and KURO-RS o usb/120786 usb [usb] [panic] Kernel panic when forced umount of a det o usb/120729 usb [panic] fault while in kernel mode with connecting USB o usb/120572 usb [umass] [patch] quirk to support ASUS P535 as umass (a o usb/120321 usb [hang] System hangs when transferring data to WD MyBoo o usb/120283 usb [panic] Automation reboot with wireless keyboard & mou o usb/120034 usb [hang] 6.2 & 6.3 hangs on boot at usb0: OHCI with 1.5 o usb/119981 usb [axe] [patch] add support for LOGITEC LAN-GTJ/U2 gigab o usb/119977 usb [ums] Mouse does not work in a Cherry-USB keyboard/mou o usb/119653 usb [cam] [patch] iriver s7 player sync cache error patch o usb/119633 usb [umass] umass0: BBB reset failed, IOERROR [regression] o usb/119513 usb [irq] inserting dlink dwl-g630 wireless card results i o usb/119509 usb [usb] USB flaky on Dell Optiplex 755 o usb/119481 usb [hang] FreeBSD not responding after connecting USB-Mas o usb/119389 usb [umass] Sony DSC-W1 CBI reset failed, STALLED [regress o usb/119227 usb [ubsa] [patch] ubsa buffer is too small; should be tun o usb/119201 usb [cam] [patch] Quirks for Olympus FE-210 camera, LG and o usb/118485 usb [usbdevs] [patch] Logitech Headset Workaround o usb/118480 usb [umass] Timeout in USB mass storage freezes vfs layer o usb/118353 usb [panic] [ppp] repeatable kernel panic during ppp(4) se o usb/118141 usb [ucom] usb serial and nokia phones ucomreadcb ucomread o usb/118140 usb [ucom] [patch] quick hack for ucom to get it behave wi o usb/118098 usb [umass] 6th gen iPod causes problems when disconnectin o usb/117955 usb [umass] [panic] inserting minolta dimage a2 crashes OS o usb/117946 usb [panic] D-Link DUB-E100 rev. B1 crashes FreeBSD 7.0-BE o usb/117938 usb [ums] [patch] Adding support for MS WL Natural and MS o usb/117911 usb [ums] [request] Mouse Gembird MUSWC not work o usb/117893 usb [umass] Lacie USB DVD writing failing o usb/117613 usb [uhci] [irq] uhci interrupt storm & USB leaked memory o usb/117598 usb [uaudio] [patch] Not possible to record with Plantroni o usb/117313 usb [umass] [panic] panic on usb camera insertion o usb/117200 usb [ugen] ugen0 prints strange string on attach if detach o usb/117183 usb [panic] USB/fusefs -- panic while transferring large a o usb/116947 usb [ukbd] [patch] [regression] enable boot protocol on th o usb/116699 usb [usbhid] USB HID devices do not initialize at system b o usb/116561 usb [umodem] [panic] RELENG_6 umodem panic "trying to slee o usb/116282 usb [ulpt] Cannot print on USB HP LJ1018 or LJ1300 o usb/115935 usb [usbdevs] [patch] kernel counterproductively attaches o usb/115933 usb [uftdi] [patch] RATOC REX-USB60F (usb serial converter o usb/115400 usb [ehci] Problem with EHCI on ASUS M2N4-SLI o usb/115298 usb [ulpt] [panic] Turning off USB printer panics kernel o usb/114916 usb [umass] [patch] USB Maxtor drive (L300RO) requires qui o kern/114780 usb [uplcom] [panic] Panics while stress testing the uplco o usb/114682 usb [umass] generic USB media-card reader unusable o usb/114310 usb [libusb] [patch] [panic] USB hub attachment panics ker o usb/114068 usb [usb67] [usb8] [umass] [patch] Problem with connection o conf/114013 usb [patch] WITHOUT_USB allow to compil a lot of USB stuff o usb/113060 usb [usb67] [ulpt] [patch] Samsung printer not working in o usb/110856 usb [usb67] [ugen] [patch] interrupt in msgs are truncated s usb/108344 usb [usb67] [atausb] [panic] kernel with atausb panics whe o usb/107935 usb [usb67] [uplcom] [panic] panic while accessing /dev/cu o usb/107924 usb [usb67] usbd(8) does not call detach o usb/107827 usb [usb67] [ohci] [panic] ohci_add_done addr not found o usb/107388 usb [usb67] [usb8] [new driver] [patch] add utoppy device o usb/107243 usb [usb67] [cam] [quirk] [patch] Apacer USB Flash Drive q o usb/106041 usb [usb67] [usb8] [request] FreeBSD does not recognise Mu o usb/105361 usb [usb67] [panic] Kernel panic during unmounting mass st s usb/103917 usb [usb67] [uhub] USB driver reports "Addr 0 should never o usb/103418 usb [usb67] [usb8] [patch] [request] usbhidctl(8) add abil o usb/103046 usb [usb67] [ulpt] [patch] ulpt event driven I/O with sele o usb/101775 usb [usb67] [usb8] [libusbhid] [patch] possible error in r o usb/101761 usb [usb67] [patch] [request] usb.h: increase maximal size o usb/100746 usb [usb67] [ukbd] system does not boot due to USB keyboar o usb/99538 usb [keyboard] while using USB keyboard default params of o usb/99431 usb [keyboard] FreeBSD on MSI 6566E (Intel 845E motherboar o kern/99200 usb [bluetooth] SMP-Kernel crashes reliably when Bluetooth o usb/98343 usb [boot] BBB reset failed errors with Creative Muvo MP3 o usb/97472 usb [cam] [patch] add support for Olympus C150,D390 s usb/97286 usb [mouse] [request] MS Wireless Intellimouse Explorer 2. o usb/97175 usb [umass] [hang] USB cardreader hangs system o usb/96457 usb [umass] [panic] fatback on umass = reboot o usb/96381 usb [cam] [patch] add a quirk table entry for a flash ram o usb/96224 usb [usb] [msdosfs] mount_msdosfs cause page fault in sync s usb/96120 usb [ums] [request] USB mouse not always detected s usb/95636 usb [umass] [boot] 5 minute delay at boot when using VT620 o usb/95562 usb [umass] Write Stress in USB Mass drive causes "vinvalb s usb/95348 usb [keyboard] USB keyboard unplug causes noise on screen o usb/95037 usb [umass] USB disk not recognized on hot-plug. o usb/94897 usb [panic] Kernel Panic when cleanly unmounting USB disk o usb/94717 usb [ulpt] Reading from /dev/ulpt can break work of a UHCI o usb/94384 usb [panic] kernel panic with usb2 hardware o usb/93872 usb [cam] [patch] SCSI quirk required for ELTA 8061 OL USB o usb/93828 usb [ohci] [panic] ohci causes panic on boot (HP Pavillion o usb/93389 usb [umass] [patch] Digital Camera Pentax S60 don't work o usb/93155 usb [ulpt] /dev/ulpt0: device busy, USB printer does not w o usb/92852 usb [ums] [patch] Vertical scroll not working properly on o usb/92171 usb [panic] panic unplugging Vodafone Mobile Connect (UMTS o usb/92142 usb [uhub] SET_ADDR_FAILED and SHORT_XFER errors from usb o usb/92083 usb [ural] [panic] panic using WPA on ural NIC in 6.0-RELE o usb/92052 usb [ulpt] usbd causes defunct process with busy file-hand o usb/91906 usb [ehci] [hang] FreeBSD hangs while booting with USB leg o usb/91896 usb camcontrol(8): Serial Number of USB Memory Sticks is n o usb/91811 usb [umass] Compact Flash in HP Photosmart 2610 return " o usb/91629 usb [usb] usbd_abort_pipe() may result in infinite loop o usb/91546 usb [umodem] [patch] Nokia 6630 mobile phone does not work o usb/91538 usb [ulpt] [patch] Unable to print to EPSON CX3500 o usb/91283 usb [boot] [regression] booting very slow with usb devices o usb/91238 usb [umass] USB tape unit fails to write a second tape fil o usb/90700 usb [umass] [panic] Kernel panic on connect/mount/use umas o usb/89954 usb [umass] [panic] USB Disk driver race condition? s usb/89003 usb [request] LaCie Firewire drive not properly supported o usb/88743 usb [hang] [regression] USB makes kernel hang at boot (reg o usb/88408 usb [axe] axe0 read PHY failed o usb/87648 usb [mouse] Logitech USB-optical mouse problem. o usb/87224 usb [usb] Cannot mount USB Zip750 o usb/86767 usb [umass] [patch] bogus "slice starts beyond end of the o usb/86298 usb [mouse] Known good USB mouse won't work with correct s s usb/85067 usb [uscanner] Cannot attach ScanJet 4300C to usb device f usb/84750 usb [hang] 6-BETA2 reboot/shutdown with root_fs on externa s usb/84336 usb [usb] [reboot] instant system reboot when unmounting a o usb/83977 usb [ucom] [panic] ucom1: open bulk out error (addr 2): IN o usb/83863 usb [ugen] Communication problem between opensc/openct via o usb/83756 usb [ums] [patch] Microsoft Intellimouse Explorer 4.0A doe o usb/83563 usb [umass] [panic] Page Fault while detaching Mpman Usb d o usb/83504 usb [kernel] [patch] SpeedTouch USB stop working on recent o usb/82660 usb [ehci] [panic] EHCI: I/O stuck in state 'physrd'/panic s usb/82569 usb [umass] [panic] USB mass storage plug/unplug causes sy o usb/82520 usb [udbp] [reboot] Reboot when USL101 connected o usb/82350 usb [ucom] [panic] null pointer dereference in USB stack o usb/81621 usb [ehci] [hang] external hd hangs under load on ehci o usb/80935 usb [uvisor] [patch] uvisor.c is not work with CLIE TH55. o usb/80862 usb [patch] USB locking issues: missing some Giant calls o usb/80854 usb [patch] [request] suggestion for new iface-no-probe me o usb/80829 usb [modules] [panic] possible panic when loading USB-modu s usb/80777 usb [request] usb_rem_task() should wait for callback to c s usb/80776 usb [udav] [request] UDAV device driver shouldn't use usb_ o usb/80774 usb [patch] have "usbd_find_desc" in line with the other " o usb/80361 usb [umass] [patch] mounting of Dell usb-stick fails o usb/80040 usb [sound] [hang] Use of sound mixer causes system freeze o usb/79723 usb [usb] [request] prepare for high speed isochronous tra o usb/79722 usb [ehci] wrong alignments in ehci.h a usb/79656 usb [ehci] RHSC interrupts lost o usb/79524 usb [ulpt] printing to Minolta PagePro 1[23]xxW via USB fa o usb/79287 usb [uhci] [hang] UHCI hang after interrupt transfer o usb/79269 usb [ohci] USB ohci da0 plug/unplug causes crashes and loc o usb/78984 usb [umass] [patch] Creative MUVO umass failure o usb/77294 usb [ucom] [panic] ucom + ulpcom panic o usb/77184 usb [umass] [panic] kernel panic on USB device disconnect, o usb/76732 usb [ums] Mouse problems with USB KVM Switch o usb/76653 usb [umass] [patch] Problem with Asahi Optical usb device o usb/76461 usb [umass] disklabel of umass(4)-CAM(4)-da(4) not used by o usb/76395 usb [uhci] USB printer does not work, usbdevs says "addr 0 s usb/75928 usb [umass] [request] Cytronix SmartMedia card (SMC) reade o usb/75800 usb [ucom] ucom1: init failed STALLED error in time of syn o usb/75797 usb [sound] [regression] 5.3-STABLE(2005 1/4) detect USB h o usb/75764 usb [umass] [patch] "umass0: Phase Error" - no device for o usb/75705 usb [umass] [panic] da0 attach / Optio S4 (with backtrace) o usb/74771 usb [umass] [hang] mounting write-protected umass device a s usb/74453 usb [umass] [patch] Q-lity CD-RW USB ECW-043 (ScanLogic SL o usb/74211 usb [umass] USB flash drive causes CAM status 0x4 on 4.10R o usb/73307 usb [panic] Kernel panics on USB disconnect s usb/72733 usb [ucom] [request] Kyocera 7135 Palm OS connection probl o usb/71455 usb [umass] Slow USB umass performance of 5.3 o usb/71417 usb [ugen] Cryptoflex e-gate USB token (ugen0) communicati o usb/71416 usb [ugen] Cryptoflex e-gate USB token (ugen0) detach is n o usb/71280 usb [aue] aue0 device (linksys usb100tx) doesn't work in 1 o usb/71155 usb [ulpt] misbehaving usb-printer hangs processes, causes o usb/70523 usb [umct] [patch] umct sending/receiving wrong characters o usb/69006 usb [usbdevs] [patch] Apple Cinema Display hangs USB ports o usb/68232 usb [ugen] [patch] ugen(4) isochronous handling correction o usb/67301 usb [uftdi] [panic] RTS and system panic o usb/66547 usb [ucom] Palm Tungsten T USB does not initialize correct o usb/63621 usb [umass] [panic] USB MemoryStick Reader stalls/crashes s usb/62257 usb [umass] [request] card reader UCR-61S2B is only half-s o usb/59698 usb [keyboard] [patch] Rework of ukbd HID to AT code trans s bin/57255 usb [patch] usbd(8) and multi-function devices s usb/52026 usb [usb] [request] umass driver support for InSystem ISD2 s usb/51958 usb [urio] [patch] update for urio driver o i386/46371 usb USB controller cannot be initialized on IBM Netfinity o usb/40948 usb [umass] [request] USB HP CDW8200 does not work o usb/30929 usb [usb] [patch] use usbd to initialize USB ADSL modem 310 problems total. From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 12:10:31 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37B8C10656A6 for ; Mon, 21 Sep 2009 12:10:31 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id AE9DE8FC0A for ; Mon, 21 Sep 2009 12:10:30 +0000 (UTC) Received: from park.js.berklix.net (p549A7E2E.dip.t-dialin.net [84.154.126.46]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id n8LCAQ6s070724 for ; Mon, 21 Sep 2009 12:10:28 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id n8LCAIdv030067 for ; Mon, 21 Sep 2009 14:10:18 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id n8LCCtnl098153 for ; Mon, 21 Sep 2009 14:13:00 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200909211213.n8LCCtnl098153@fire.js.berklix.net> cc: freebsd-usb@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 17 Sep 2009 17:30:55 +0200." <200909171531.n8HFUtYw038501@fire.js.berklix.net> Date: Mon, 21 Sep 2009 14:12:55 +0200 Sender: jhs@berklix.com Subject: Re: How to get /dev/uscanner0 to use ehci at USB2 speed, not uhci ? X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 12:10:31 -0000 Hi, Reference: > From: "Julian H. Stacey" > Date: Thu, 17 Sep 2009 17:30:55 +0200 > Message-id: <200909171531.n8HFUtYw038501@fire.js.berklix.net> "Julian H. Stacey" wrote: > Hi FreeBSD-USB@ people, > With 7.2-RELEASE, how should I get > /dev/uscanner0 to use ehci at USB2 speed, not uhci at USB1 ? > (Please feel free to reply RTFM ... URL= ) > > Logs & My config & what I've tried / looked at: > > My USB scanner works, but its agoning slow in high res. > > devd: > Processing event '+uscanner0 vendor=0x04b8 product=0x011d devclass=0xff > devsubclass=0x00 release=0x0100 sernum="" intclass=0xff intsubclass=0x00 > at port=0 interface=0 vendor=0x04b8 product=0x011d devclass=0xff > devsubclass=0x00 release=0x0100 sernum="" intclass=0xff intsubclass=0x00 > on uhub1' > > dmesg extract: > ------ > uhci0: port 0xd400-0xd41f irq 21 at device 16.0 on pci0 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > > uhci1: port 0xd800-0xd81f irq 21 at device 16.1 on pci0 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > > uhci2: port 0xe000-0xe01f irq 21 at device 16.2 on pci0 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > > uhci3: port 0xe400-0xe41f irq 21 at device 16.3 on pci0 > uhci3: [GIANT-LOCKED] > uhci3: [ITHREAD] > usb3: on uhci3 > usb3: USB revision 1.0 > uhub3: on usb3 > uhub3: 2 ports with 2 removable, self powered > > ehci0: mem 0xfae00000-0xfae000ff irq 21 at device 16.4 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb4: EHCI version 1.0 > usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 > usb4: on ehci0 > usb4: USB revision 2.0 > uhub4: on usb4 > uhub4: 8 ports with 8 removable, self powered > > uscanner0: on uhub1 > uscanner0: at uhub1 port 1 (addr 2) disconnected > uscanner0: detached > uscanner0: on uhub1 > uscanner0: at uhub1 port 1 (addr 2) disconnected > uscanner0: detached > uscanner0: on uhub1 > ------ > > config -x /boot/kernel/kernel # includes all of > device uhci > device ehci > device uscanner > > uname -a > FreeBSD john.js.berklix.net 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Tue May 5 00:41:36 CEST 2009 jhs@@@john.js.berklix.net:/usr1/src/sys/amd64/compile/JOHN64.small amd64 > > sane-find-scanner -q > found USB scanner (vendor=0x04b8, product=0x011d) at /dev/uscanner0 > > PS I had a quick look at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/scanners.html > but nothing I noticed. The scanner manufacturer documents hardware as USB-1 :-( Idealy /var/log/messages might have issued a simple clear warning about that. > cd /usr/src ; find . -name \*devctl\* > /share/man/man4/devctl.4 > # no binary just the manual. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail ASCII plain text not HTML & Base64. http://asciiribbon.org Virused Microsoft PCs cause spam. http://berklix.com/free/ From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 16:27:17 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAF88106566C for ; Mon, 21 Sep 2009 16:27:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe15.swip.net [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id 317FB8FC08 for ; Mon, 21 Sep 2009 16:27:16 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=6U-Pe18MTAwA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=bbMlDPGCR69EmjQgKfEA:9 a=P1xrWtePKS_yNps8AkttgA8bJ0cA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 566164196; Mon, 21 Sep 2009 18:27:15 +0200 From: Hans Petter Selasky To: "Pierre-Luc Drouin" , ed@freebsd.org Date: Mon, 21 Sep 2009 18:27:52 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <4AB6DA79.7050209@pldrouin.net> In-Reply-To: <4AB6DA79.7050209@pldrouin.net> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909211827.53014.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 16:27:17 -0000 On Monday 21 September 2009 03:44:25 Pierre-Luc Drouin wrote: > Hi, > > I am also having troubles with the uftdi driver on 8.0-BETA4. > I am trying to use a fan controller (mCubed bigNG) that uses a FT232BL chip > and it does not seem to be responding on FreeBSD 8.0 while the same code > works perfectly on Linux (I have not tried the code on RELENG_7 yet but I > could install it if necessary). > > Here is the very simple code I am using for testing: > #include > #include > #include > #include > #include > > int main(); > > #define DEV "/dev/ttyU0" > > #define TBAN_SER_SOURCE1 0x05 /* Primary source */ > #define TBAN_SER_SOURCE2 0x06 /* Alternative source (miniNG...) */ > > #define TBAN_SER_REQUEST 0x36 > > int main() > { > int fd; > int result; > struct termios oldtio, newtio; > unsigned char buf[285]; > > printf("Opening device\n"); > fd=open(DEV, O_RDWR | O_NOCTTY); > > if(fd<0) { > perror(DEV); > return 1; > } > > result=tcgetattr(fd,&oldtio); > if(result<0) { > perror("tcgetattr"); > return 1; > } > > memcpy(&newtio,&oldtio,sizeof(struct termios)); > newtio.c_cflag = B19200 > > | CRTSCTS > | CS8 > | CREAD; > > newtio.c_iflag = IGNPAR; > newtio.c_oflag = 0; > newtio.c_lflag = 0; > newtio.c_cc[VMIN] = 1; > newtio.c_cc[VTIME] = 0; > > result=tcflush(fd, TCIFLUSH); > if(result<0) { > perror("tcflush"); > return 1; > } > > result=tcsetattr(fd,TCSANOW,&newtio); > if(result<0) { > perror("tcsetattr"); > return 1; > } > > sleep(1); > > printf("Performing initial query\n"); > buf[0]=TBAN_SER_SOURCE1; > buf[1]=TBAN_SER_REQUEST; > > printf("Requesting status\n"); > result=write(fd,buf,2); > if(result<0) { > perror("write"); > return 1; > } > > sleep(1); > > printf("Reading status\n"); > result=read(fd,buf,32); > if(result<0) { > perror("read"); > return 1; > } > > result=tcsetattr(fd,TCSANOW,&oldtio); > if(result<0) { > perror("tcsetattr"); > return 1; > } > > result=close(fd); > if(result<0) { > perror("close"); > return 1; > } > return 0; > } > > It hangs while reading independently of the number of bits I am reading. > > Here is the output from dmesg when I load the uftdi module: > Sep 20 21:31:31 ldaemon kernel: uftdi0: on usbus6 > Sep 20 21:31:31 ldaemon kernel: ucom_attach_tty:317: tp = > 0xffffff001f12b400, unit = 0 Sep 20 21:31:31 ldaemon kernel: > ucom_attach_tty:346: ttycreate: U0 Sep 20 21:31:34 ldaemon root: Unknown > USB device: vendor 0x051d product 0x0002 bus uhub0 > > Here is the output in /var/log/messages when I enable the debug output for > ucom and uftdi: Sep 20 21:33:30 ldaemon kernel: ucom_open:554: tp = > 0xffffff001f12b400 Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = 1 > Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 > Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 > Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 > Sep 20 21:33:30 ldaemon kernel: ucom_break:816: onoff = 0 > Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 > Sep 20 21:33:30 ldaemon kernel: ucom_status_change:901: > Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 > Sep 20 21:33:30 ldaemon kernel: uftdi_pre_param:653: > Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = 1 > Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 > Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 > Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 > Sep 20 21:33:30 ldaemon kernel: ucom_cfg_open:520: > Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_open:354: > Sep 20 21:33:30 ldaemon kernel: uftdi_read_callback:459: status change > msr=0xf0 (0x00) lsr=0x60 (0x00) Sep 20 21:33:30 ldaemon kernel: > ucom_status_change:901: > Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 lsr=0x60 > Sep 20 21:33:30 ldaemon kernel: ucom_cfg_status_change:887: DCD changed to > 1 Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: > Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 > Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 > Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 > Sep 20 21:33:30 ldaemon kernel: uftdi_pre_param:653: > Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 lsr=0x60 > Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: > Sep 20 21:33:30 ldaemon kernel: ucom_get_data:1064: cnt=0 > Sep 20 21:33:31 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > Sep 20 21:33:32 ldaemon kernel: ucom_outwakeup:1009: sc = > 0xffffff001f12ac58 Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: > cnt=2 > Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: cnt=0 > > I really need to get this working so I am ready to test things as much as I > can... Hi, You need to set raw mode for the TTY device I think. Maybe Ed can give you the function name you need to call to do that? --HPS From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 17:29:12 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03CCB1065697 for ; Mon, 21 Sep 2009 17:29:12 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id 8F8038FC24 for ; Mon, 21 Sep 2009 17:29:11 +0000 (UTC) Received: from mdaemon.pldrouin.net (pldrouinlap2-pc.physics.carleton.ca [134.117.23.34]) by smtp.cyberfingers.net (Postfix) with ESMTP id 0A176AB6C14; Mon, 21 Sep 2009 13:26:19 -0400 (EDT) Message-ID: <4AB7B7E6.9070005@pldrouin.net> Date: Mon, 21 Sep 2009 13:29:10 -0400 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: Hans Petter Selasky References: <4AB6DA79.7050209@pldrouin.net> <200909211827.53014.hselasky@c2i.net> In-Reply-To: <200909211827.53014.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ed@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 17:29:12 -0000 Hans Petter Selasky wrote: > On Monday 21 September 2009 03:44:25 Pierre-Luc Drouin wrote: > >> Hi, >> >> I am also having troubles with the uftdi driver on 8.0-BETA4. >> I am trying to use a fan controller (mCubed bigNG) that uses a FT232BL chip >> and it does not seem to be responding on FreeBSD 8.0 while the same code >> works perfectly on Linux (I have not tried the code on RELENG_7 yet but I >> could install it if necessary). >> >> Here is the very simple code I am using for testing: >> #include >> #include >> #include >> #include >> #include >> >> int main(); >> >> #define DEV "/dev/ttyU0" >> >> #define TBAN_SER_SOURCE1 0x05 /* Primary source */ >> #define TBAN_SER_SOURCE2 0x06 /* Alternative source (miniNG...) */ >> >> #define TBAN_SER_REQUEST 0x36 >> >> int main() >> { >> int fd; >> int result; >> struct termios oldtio, newtio; >> unsigned char buf[285]; >> >> printf("Opening device\n"); >> fd=open(DEV, O_RDWR | O_NOCTTY); >> >> if(fd<0) { >> perror(DEV); >> return 1; >> } >> >> result=tcgetattr(fd,&oldtio); >> if(result<0) { >> perror("tcgetattr"); >> return 1; >> } >> >> memcpy(&newtio,&oldtio,sizeof(struct termios)); >> newtio.c_cflag = B19200 >> >> | CRTSCTS >> | CS8 >> | CREAD; >> >> newtio.c_iflag = IGNPAR; >> newtio.c_oflag = 0; >> newtio.c_lflag = 0; >> newtio.c_cc[VMIN] = 1; >> newtio.c_cc[VTIME] = 0; >> >> result=tcflush(fd, TCIFLUSH); >> if(result<0) { >> perror("tcflush"); >> return 1; >> } >> >> result=tcsetattr(fd,TCSANOW,&newtio); >> if(result<0) { >> perror("tcsetattr"); >> return 1; >> } >> >> sleep(1); >> >> printf("Performing initial query\n"); >> buf[0]=TBAN_SER_SOURCE1; >> buf[1]=TBAN_SER_REQUEST; >> >> printf("Requesting status\n"); >> result=write(fd,buf,2); >> if(result<0) { >> perror("write"); >> return 1; >> } >> >> sleep(1); >> >> printf("Reading status\n"); >> result=read(fd,buf,32); >> if(result<0) { >> perror("read"); >> return 1; >> } >> >> result=tcsetattr(fd,TCSANOW,&oldtio); >> if(result<0) { >> perror("tcsetattr"); >> return 1; >> } >> >> result=close(fd); >> if(result<0) { >> perror("close"); >> return 1; >> } >> return 0; >> } >> >> It hangs while reading independently of the number of bits I am reading. >> >> Here is the output from dmesg when I load the uftdi module: >> Sep 20 21:31:31 ldaemon kernel: uftdi0: on usbus6 >> Sep 20 21:31:31 ldaemon kernel: ucom_attach_tty:317: tp = >> 0xffffff001f12b400, unit = 0 Sep 20 21:31:31 ldaemon kernel: >> ucom_attach_tty:346: ttycreate: U0 Sep 20 21:31:34 ldaemon root: Unknown >> USB device: vendor 0x051d product 0x0002 bus uhub0 >> >> Here is the output in /var/log/messages when I enable the debug output for >> ucom and uftdi: Sep 20 21:33:30 ldaemon kernel: ucom_open:554: tp = >> 0xffffff001f12b400 Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = 1 >> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 >> Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 >> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 >> Sep 20 21:33:30 ldaemon kernel: ucom_break:816: onoff = 0 >> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 >> Sep 20 21:33:30 ldaemon kernel: ucom_status_change:901: >> Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 >> Sep 20 21:33:30 ldaemon kernel: uftdi_pre_param:653: >> Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = 1 >> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 >> Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 >> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 >> Sep 20 21:33:30 ldaemon kernel: ucom_cfg_open:520: >> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_open:354: >> Sep 20 21:33:30 ldaemon kernel: uftdi_read_callback:459: status change >> msr=0xf0 (0x00) lsr=0x60 (0x00) Sep 20 21:33:30 ldaemon kernel: >> ucom_status_change:901: >> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 lsr=0x60 >> Sep 20 21:33:30 ldaemon kernel: ucom_cfg_status_change:887: DCD changed to >> 1 Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: >> Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 >> Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >> Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 >> Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 >> Sep 20 21:33:30 ldaemon kernel: uftdi_pre_param:653: >> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 lsr=0x60 >> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: >> Sep 20 21:33:30 ldaemon kernel: ucom_get_data:1064: cnt=0 >> Sep 20 21:33:31 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >> Sep 20 21:33:32 ldaemon kernel: ucom_outwakeup:1009: sc = >> 0xffffff001f12ac58 Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: >> cnt=2 >> Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: cnt=0 >> >> I really need to get this working so I am ready to test things as much as I >> can... >> > > Hi, > > You need to set raw mode for the TTY device I think. Maybe Ed can give you the > function name you need to call to do that? > > --HPS > Do I need to do something like that? ioctl(fileno(stdin), TIOCGETP, &tty_org); tty = tty_org; /* set terminal to raw mode ... */ tty.sg_flags |= CRMOD; tty.sg_flags &= ~ECHO; tty.sg_flags &= ~XTABS; tty.sg_flags |= RAW; Thanks! Pierre-Luc Drouin From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 17:32:03 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D32B106566B for ; Mon, 21 Sep 2009 17:32:03 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 58B0E8FC0A for ; Mon, 21 Sep 2009 17:32:01 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=6U-Pe18MTAwA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=MjWnJEQqbsKpB2t2Ec4A:9 a=c3_tBq54FzU5S8p38AAA:7 a=miSVSJ7hUBQieyiELOC7QWufVPsA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1301258920; Mon, 21 Sep 2009 19:32:00 +0200 From: Hans Petter Selasky To: "Pierre-Luc Drouin" Date: Mon, 21 Sep 2009 19:32:35 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <4AB6DA79.7050209@pldrouin.net> <200909211827.53014.hselasky@c2i.net> <4AB7B7E6.9070005@pldrouin.net> In-Reply-To: <4AB7B7E6.9070005@pldrouin.net> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909211932.37015.hselasky@c2i.net> Cc: ed@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 17:32:03 -0000 On Monday 21 September 2009 19:29:10 Pierre-Luc Drouin wrote: > Hans Petter Selasky wrote: > > On Monday 21 September 2009 03:44:25 Pierre-Luc Drouin wrote: > >> Hi, > >> > >> I am also having troubles with the uftdi driver on 8.0-BETA4. > >> I am trying to use a fan controller (mCubed bigNG) that uses a FT232BL > >> chip and it does not seem to be responding on FreeBSD 8.0 while the same > >> code works perfectly on Linux (I have not tried the code on RELENG_7 yet > >> but I could install it if necessary). > >> > >> Here is the very simple code I am using for testing: > >> #include > >> #include > >> #include > >> #include > >> #include > >> > >> int main(); > >> > >> #define DEV "/dev/ttyU0" > >> > >> #define TBAN_SER_SOURCE1 0x05 /* Primary source */ > >> #define TBAN_SER_SOURCE2 0x06 /* Alternative source (miniNG...) > >> */ > >> > >> #define TBAN_SER_REQUEST 0x36 > >> > >> int main() > >> { > >> int fd; > >> int result; > >> struct termios oldtio, newtio; > >> unsigned char buf[285]; > >> > >> printf("Opening device\n"); > >> fd=open(DEV, O_RDWR | O_NOCTTY); > >> > >> if(fd<0) { > >> perror(DEV); > >> return 1; > >> } > >> > >> result=tcgetattr(fd,&oldtio); > >> if(result<0) { > >> perror("tcgetattr"); > >> return 1; > >> } > >> > >> memcpy(&newtio,&oldtio,sizeof(struct termios)); > >> newtio.c_cflag = B19200 > >> > >> | CRTSCTS > >> | CS8 > >> | CREAD; > >> > >> newtio.c_iflag = IGNPAR; > >> newtio.c_oflag = 0; > >> newtio.c_lflag = 0; > >> newtio.c_cc[VMIN] = 1; > >> newtio.c_cc[VTIME] = 0; > >> > >> result=tcflush(fd, TCIFLUSH); > >> if(result<0) { > >> perror("tcflush"); > >> return 1; > >> } > >> > >> result=tcsetattr(fd,TCSANOW,&newtio); > >> if(result<0) { > >> perror("tcsetattr"); > >> return 1; > >> } > >> > >> sleep(1); > >> > >> printf("Performing initial query\n"); > >> buf[0]=TBAN_SER_SOURCE1; > >> buf[1]=TBAN_SER_REQUEST; > >> > >> printf("Requesting status\n"); > >> result=write(fd,buf,2); > >> if(result<0) { > >> perror("write"); > >> return 1; > >> } > >> > >> sleep(1); > >> > >> printf("Reading status\n"); > >> result=read(fd,buf,32); > >> if(result<0) { > >> perror("read"); > >> return 1; > >> } > >> > >> result=tcsetattr(fd,TCSANOW,&oldtio); > >> if(result<0) { > >> perror("tcsetattr"); > >> return 1; > >> } > >> > >> result=close(fd); > >> if(result<0) { > >> perror("close"); > >> return 1; > >> } > >> return 0; > >> } > >> > >> It hangs while reading independently of the number of bits I am reading. > >> > >> Here is the output from dmesg when I load the uftdi module: > >> Sep 20 21:31:31 ldaemon kernel: uftdi0: on usbus6 > >> Sep 20 21:31:31 ldaemon kernel: ucom_attach_tty:317: tp = > >> 0xffffff001f12b400, unit = 0 Sep 20 21:31:31 ldaemon kernel: > >> ucom_attach_tty:346: ttycreate: U0 Sep 20 21:31:34 ldaemon root: Unknown > >> USB device: vendor 0x051d product 0x0002 bus uhub0 > >> > >> Here is the output in /var/log/messages when I enable the debug output > >> for ucom and uftdi: Sep 20 21:33:30 ldaemon kernel: ucom_open:554: tp = > >> 0xffffff001f12b400 Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = > >> 1 Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 > >> Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 > >> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 > >> Sep 20 21:33:30 ldaemon kernel: ucom_break:816: onoff = 0 > >> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 > >> Sep 20 21:33:30 ldaemon kernel: ucom_status_change:901: > >> Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 > >> Sep 20 21:33:30 ldaemon kernel: uftdi_pre_param:653: > >> Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = 1 > >> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 > >> Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 > >> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 > >> Sep 20 21:33:30 ldaemon kernel: ucom_cfg_open:520: > >> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_open:354: > >> Sep 20 21:33:30 ldaemon kernel: uftdi_read_callback:459: status change > >> msr=0xf0 (0x00) lsr=0x60 (0x00) Sep 20 21:33:30 ldaemon kernel: > >> ucom_status_change:901: > >> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 > >> lsr=0x60 Sep 20 21:33:30 ldaemon kernel: ucom_cfg_status_change:887: DCD > >> changed to 1 Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: > >> Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 > >> Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > >> Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 > >> Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 > >> Sep 20 21:33:30 ldaemon kernel: uftdi_pre_param:653: > >> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 > >> lsr=0x60 Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: > >> Sep 20 21:33:30 ldaemon kernel: ucom_get_data:1064: cnt=0 > >> Sep 20 21:33:31 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > >> Sep 20 21:33:32 ldaemon kernel: ucom_outwakeup:1009: sc = > >> 0xffffff001f12ac58 Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: > >> cnt=2 > >> Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: cnt=0 > >> > >> I really need to get this working so I am ready to test things as much > >> as I can... > > > > Hi, > > > > You need to set raw mode for the TTY device I think. Maybe Ed can give > > you the function name you need to call to do that? > > > > --HPS > > Do I need to do something like that? > ioctl(fileno(stdin), TIOCGETP, &tty_org); > tty = tty_org; > > /* set terminal to raw mode ... */ > tty.sg_flags |= CRMOD; > tty.sg_flags &= ~ECHO; > tty.sg_flags &= ~XTABS; > tty.sg_flags |= RAW; > > Thanks! > Pierre-Luc Drouin Hi, You need to call this function: void cfmakeraw(struct termios *t); --HPS From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 17:52:13 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B21EF1065672; Mon, 21 Sep 2009 17:52:13 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id 5CA678FC08; Mon, 21 Sep 2009 17:52:13 +0000 (UTC) Received: from mdaemon.pldrouin.net (pldrouinlap2-pc.physics.carleton.ca [134.117.23.34]) by smtp.cyberfingers.net (Postfix) with ESMTP id 9687FAB6C0F; Mon, 21 Sep 2009 13:49:22 -0400 (EDT) Message-ID: <4AB7BD4D.4020703@pldrouin.net> Date: Mon, 21 Sep 2009 13:52:13 -0400 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: Hans Petter Selasky References: <4AB6DA79.7050209@pldrouin.net> <200909211827.53014.hselasky@c2i.net> <4AB7B7E6.9070005@pldrouin.net> <200909211932.37015.hselasky@c2i.net> In-Reply-To: <200909211932.37015.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ed@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 17:52:13 -0000 Hans Petter Selasky wrote: > On Monday 21 September 2009 19:29:10 Pierre-Luc Drouin wrote: > >> Hans Petter Selasky wrote: >> >>> On Monday 21 September 2009 03:44:25 Pierre-Luc Drouin wrote: >>> >>>> Hi, >>>> >>>> I am also having troubles with the uftdi driver on 8.0-BETA4. >>>> I am trying to use a fan controller (mCubed bigNG) that uses a FT232BL >>>> chip and it does not seem to be responding on FreeBSD 8.0 while the same >>>> code works perfectly on Linux (I have not tried the code on RELENG_7 yet >>>> but I could install it if necessary). >>>> >>>> Here is the very simple code I am using for testing: >>>> #include >>>> #include >>>> #include >>>> #include >>>> #include >>>> >>>> int main(); >>>> >>>> #define DEV "/dev/ttyU0" >>>> >>>> #define TBAN_SER_SOURCE1 0x05 /* Primary source */ >>>> #define TBAN_SER_SOURCE2 0x06 /* Alternative source (miniNG...) >>>> */ >>>> >>>> #define TBAN_SER_REQUEST 0x36 >>>> >>>> int main() >>>> { >>>> int fd; >>>> int result; >>>> struct termios oldtio, newtio; >>>> unsigned char buf[285]; >>>> >>>> printf("Opening device\n"); >>>> fd=open(DEV, O_RDWR | O_NOCTTY); >>>> >>>> if(fd<0) { >>>> perror(DEV); >>>> return 1; >>>> } >>>> >>>> result=tcgetattr(fd,&oldtio); >>>> if(result<0) { >>>> perror("tcgetattr"); >>>> return 1; >>>> } >>>> >>>> memcpy(&newtio,&oldtio,sizeof(struct termios)); >>>> newtio.c_cflag = B19200 >>>> >>>> | CRTSCTS >>>> | CS8 >>>> | CREAD; >>>> >>>> newtio.c_iflag = IGNPAR; >>>> newtio.c_oflag = 0; >>>> newtio.c_lflag = 0; >>>> newtio.c_cc[VMIN] = 1; >>>> newtio.c_cc[VTIME] = 0; >>>> >>>> result=tcflush(fd, TCIFLUSH); >>>> if(result<0) { >>>> perror("tcflush"); >>>> return 1; >>>> } >>>> >>>> result=tcsetattr(fd,TCSANOW,&newtio); >>>> if(result<0) { >>>> perror("tcsetattr"); >>>> return 1; >>>> } >>>> >>>> sleep(1); >>>> >>>> printf("Performing initial query\n"); >>>> buf[0]=TBAN_SER_SOURCE1; >>>> buf[1]=TBAN_SER_REQUEST; >>>> >>>> printf("Requesting status\n"); >>>> result=write(fd,buf,2); >>>> if(result<0) { >>>> perror("write"); >>>> return 1; >>>> } >>>> >>>> sleep(1); >>>> >>>> printf("Reading status\n"); >>>> result=read(fd,buf,32); >>>> if(result<0) { >>>> perror("read"); >>>> return 1; >>>> } >>>> >>>> result=tcsetattr(fd,TCSANOW,&oldtio); >>>> if(result<0) { >>>> perror("tcsetattr"); >>>> return 1; >>>> } >>>> >>>> result=close(fd); >>>> if(result<0) { >>>> perror("close"); >>>> return 1; >>>> } >>>> return 0; >>>> } >>>> >>>> It hangs while reading independently of the number of bits I am reading. >>>> >>>> Here is the output from dmesg when I load the uftdi module: >>>> Sep 20 21:31:31 ldaemon kernel: uftdi0: on usbus6 >>>> Sep 20 21:31:31 ldaemon kernel: ucom_attach_tty:317: tp = >>>> 0xffffff001f12b400, unit = 0 Sep 20 21:31:31 ldaemon kernel: >>>> ucom_attach_tty:346: ttycreate: U0 Sep 20 21:31:34 ldaemon root: Unknown >>>> USB device: vendor 0x051d product 0x0002 bus uhub0 >>>> >>>> Here is the output in /var/log/messages when I enable the debug output >>>> for ucom and uftdi: Sep 20 21:33:30 ldaemon kernel: ucom_open:554: tp = >>>> 0xffffff001f12b400 Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = >>>> 1 Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 >>>> Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 >>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 >>>> Sep 20 21:33:30 ldaemon kernel: ucom_break:816: onoff = 0 >>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 >>>> Sep 20 21:33:30 ldaemon kernel: ucom_status_change:901: >>>> Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 >>>> Sep 20 21:33:30 ldaemon kernel: uftdi_pre_param:653: >>>> Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = 1 >>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 >>>> Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 >>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 >>>> Sep 20 21:33:30 ldaemon kernel: ucom_cfg_open:520: >>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_open:354: >>>> Sep 20 21:33:30 ldaemon kernel: uftdi_read_callback:459: status change >>>> msr=0xf0 (0x00) lsr=0x60 (0x00) Sep 20 21:33:30 ldaemon kernel: >>>> ucom_status_change:901: >>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 >>>> lsr=0x60 Sep 20 21:33:30 ldaemon kernel: ucom_cfg_status_change:887: DCD >>>> changed to 1 Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: >>>> Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 >>>> Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >>>> Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 >>>> Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 >>>> Sep 20 21:33:30 ldaemon kernel: uftdi_pre_param:653: >>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 >>>> lsr=0x60 Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: >>>> Sep 20 21:33:30 ldaemon kernel: ucom_get_data:1064: cnt=0 >>>> Sep 20 21:33:31 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >>>> Sep 20 21:33:32 ldaemon kernel: ucom_outwakeup:1009: sc = >>>> 0xffffff001f12ac58 Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: >>>> cnt=2 >>>> Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: cnt=0 >>>> >>>> I really need to get this working so I am ready to test things as much >>>> as I can... >>>> >>> Hi, >>> >>> You need to set raw mode for the TTY device I think. Maybe Ed can give >>> you the function name you need to call to do that? >>> >>> --HPS >>> >> Do I need to do something like that? >> ioctl(fileno(stdin), TIOCGETP, &tty_org); >> tty = tty_org; >> >> /* set terminal to raw mode ... */ >> tty.sg_flags |= CRMOD; >> tty.sg_flags &= ~ECHO; >> tty.sg_flags &= ~XTABS; >> tty.sg_flags |= RAW; >> >> Thanks! >> Pierre-Luc Drouin >> > > Hi, > > You need to call this function: > > void > cfmakeraw(struct termios *t); > > --HPS > Hi, it still does not work. I have added the line cfmakeraw(&newtio); just before the call to tcflush and I get the following output in /var/log/messages: Sep 21 13:38:46 ldaemon kernel: ucom_open:554: tp = 0xffffff001f12b400 Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: onoff = 1 Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 Sep 21 13:38:46 ldaemon kernel: ucom_break:816: onoff = 0 Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 Sep 21 13:38:46 ldaemon kernel: ucom_status_change:901: Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 Sep 21 13:38:46 ldaemon kernel: uftdi_pre_param:653: Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: onoff = 1 Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 Sep 21 13:38:46 ldaemon kernel: ucom_cfg_open:520: Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_open:354: uftdi_cfg_get_status:705: msr=0xf0 lsr=0x60 Sep 21 13:38:46 ldaemon kernel: ucom_cfg_status_change:887: DCD changed to 1 Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 Sep 21 13:38:46 ldaemon kernel: uftdi_pre_param:653: Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: Sep 21 13:38:46 ldaemon kernel: ucom_get_data:1064: cnt=0 Sep 21 13:38:47 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 Sep 21 13:38:48 ldaemon kernel: ucom_outwakeup:1009: sc = 0xffffff001f12ac58 Sep 21 13:38:48 ldaemon kernel: ucom_get_data:1064: cnt=2 Sep 21 13:38:48 ldaemon kernel: ucom_get_data:1064: cnt=0 Thanks! Pierre-Luc From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 18:14:01 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3F59106568B; Mon, 21 Sep 2009 18:14:01 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swipnet.se [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 08F8F8FC1C; Mon, 21 Sep 2009 18:14:00 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=6U-Pe18MTAwA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=-CGS2k2TXTb61kRWAFMA:9 a=uFOVGaHZlF09kYd-Lx0A:7 a=xaFwmV-oBsW-Wt2FdJ1TNLcRku8A:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1138936927; Mon, 21 Sep 2009 20:13:59 +0200 From: Hans Petter Selasky To: "Pierre-Luc Drouin" Date: Mon, 21 Sep 2009 20:14:35 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <4AB6DA79.7050209@pldrouin.net> <200909211932.37015.hselasky@c2i.net> <4AB7BD4D.4020703@pldrouin.net> In-Reply-To: <4AB7BD4D.4020703@pldrouin.net> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909212014.36874.hselasky@c2i.net> Cc: ed@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 18:14:02 -0000 On Monday 21 September 2009 19:52:13 Pierre-Luc Drouin wrote: > Hans Petter Selasky wrote: > > On Monday 21 September 2009 19:29:10 Pierre-Luc Drouin wrote: > >> Hans Petter Selasky wrote: > >>> On Monday 21 September 2009 03:44:25 Pierre-Luc Drouin wrote: > >>>> Hi, > >>>> > >>>> I am also having troubles with the uftdi driver on 8.0-BETA4. > >>>> I am trying to use a fan controller (mCubed bigNG) that uses a FT232BL > >>>> chip and it does not seem to be responding on FreeBSD 8.0 while the > >>>> same code works perfectly on Linux (I have not tried the code on > >>>> RELENG_7 yet but I could install it if necessary). > >>>> > >>>> Here is the very simple code I am using for testing: > >>>> #include > >>>> #include > >>>> #include > >>>> #include > >>>> #include > >>>> > >>>> int main(); > >>>> > >>>> #define DEV "/dev/ttyU0" > >>>> > >>>> #define TBAN_SER_SOURCE1 0x05 /* Primary source */ > >>>> #define TBAN_SER_SOURCE2 0x06 /* Alternative source (miniNG...) > >>>> */ > >>>> > >>>> #define TBAN_SER_REQUEST 0x36 > >>>> > >>>> int main() > >>>> { > >>>> int fd; > >>>> int result; > >>>> struct termios oldtio, newtio; > >>>> unsigned char buf[285]; > >>>> > >>>> printf("Opening device\n"); > >>>> fd=open(DEV, O_RDWR | O_NOCTTY); > >>>> > >>>> if(fd<0) { > >>>> perror(DEV); > >>>> return 1; > >>>> } > >>>> > >>>> result=tcgetattr(fd,&oldtio); > >>>> if(result<0) { > >>>> perror("tcgetattr"); > >>>> return 1; > >>>> } > >>>> > >>>> memcpy(&newtio,&oldtio,sizeof(struct termios)); > >>>> newtio.c_cflag = B19200 > >>>> > >>>> | CRTSCTS > >>>> | CS8 > >>>> | CREAD; > >>>> > >>>> newtio.c_iflag = IGNPAR; > >>>> newtio.c_oflag = 0; > >>>> newtio.c_lflag = 0; > >>>> newtio.c_cc[VMIN] = 1; > >>>> newtio.c_cc[VTIME] = 0; > >>>> > >>>> result=tcflush(fd, TCIFLUSH); > >>>> if(result<0) { > >>>> perror("tcflush"); > >>>> return 1; > >>>> } > >>>> > >>>> result=tcsetattr(fd,TCSANOW,&newtio); > >>>> if(result<0) { > >>>> perror("tcsetattr"); > >>>> return 1; > >>>> } > >>>> > >>>> sleep(1); > >>>> > >>>> printf("Performing initial query\n"); > >>>> buf[0]=TBAN_SER_SOURCE1; > >>>> buf[1]=TBAN_SER_REQUEST; > >>>> > >>>> printf("Requesting status\n"); > >>>> result=write(fd,buf,2); > >>>> if(result<0) { > >>>> perror("write"); > >>>> return 1; > >>>> } > >>>> > >>>> sleep(1); > >>>> > >>>> printf("Reading status\n"); > >>>> result=read(fd,buf,32); > >>>> if(result<0) { > >>>> perror("read"); > >>>> return 1; > >>>> } > >>>> > >>>> result=tcsetattr(fd,TCSANOW,&oldtio); > >>>> if(result<0) { > >>>> perror("tcsetattr"); > >>>> return 1; > >>>> } > >>>> > >>>> result=close(fd); > >>>> if(result<0) { > >>>> perror("close"); > >>>> return 1; > >>>> } > >>>> return 0; > >>>> } > >>>> > >>>> It hangs while reading independently of the number of bits I am > >>>> reading. > >>>> > >>>> Here is the output from dmesg when I load the uftdi module: > >>>> Sep 20 21:31:31 ldaemon kernel: uftdi0: on usbus6 > >>>> Sep 20 21:31:31 ldaemon kernel: ucom_attach_tty:317: tp = > >>>> 0xffffff001f12b400, unit = 0 Sep 20 21:31:31 ldaemon kernel: > >>>> ucom_attach_tty:346: ttycreate: U0 Sep 20 21:31:34 ldaemon root: > >>>> Unknown USB device: vendor 0x051d product 0x0002 bus uhub0 > >>>> > >>>> Here is the output in /var/log/messages when I enable the debug output > >>>> for ucom and uftdi: Sep 20 21:33:30 ldaemon kernel: ucom_open:554: tp > >>>> = 0xffffff001f12b400 Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: > >>>> onoff = 1 Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: > >>>> on=0x01, off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff > >>>> = 1 > >>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 > >>>> Sep 20 21:33:30 ldaemon kernel: ucom_break:816: onoff = 0 > >>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 > >>>> Sep 20 21:33:30 ldaemon kernel: ucom_status_change:901: > >>>> Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = > >>>> 0xffffff001f12ac58 Sep 20 21:33:30 ldaemon kernel: > >>>> uftdi_pre_param:653: > >>>> Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = 1 > >>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 > >>>> Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 > >>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 > >>>> Sep 20 21:33:30 ldaemon kernel: ucom_cfg_open:520: > >>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_open:354: > >>>> Sep 20 21:33:30 ldaemon kernel: uftdi_read_callback:459: status change > >>>> msr=0xf0 (0x00) lsr=0x60 (0x00) Sep 20 21:33:30 ldaemon kernel: > >>>> ucom_status_change:901: > >>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 > >>>> lsr=0x60 Sep 20 21:33:30 ldaemon kernel: ucom_cfg_status_change:887: > >>>> DCD changed to 1 Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: > >>>> Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 Sep > >>>> 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 Sep 20 > >>>> 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 Sep 20 > >>>> 21:33:30 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 Sep > >>>> 20 21:33:30 ldaemon kernel: uftdi_pre_param:653: > >>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 > >>>> lsr=0x60 Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: > >>>> Sep 20 21:33:30 ldaemon kernel: ucom_get_data:1064: cnt=0 > >>>> Sep 20 21:33:31 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > >>>> Sep 20 21:33:32 ldaemon kernel: ucom_outwakeup:1009: sc = > >>>> 0xffffff001f12ac58 Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: > >>>> cnt=2 > >>>> Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: cnt=0 > >>>> > >>>> I really need to get this working so I am ready to test things as much > >>>> as I can... > >>> > >>> Hi, > >>> > >>> You need to set raw mode for the TTY device I think. Maybe Ed can give > >>> you the function name you need to call to do that? > >>> > >>> --HPS > >> > >> Do I need to do something like that? > >> ioctl(fileno(stdin), TIOCGETP, &tty_org); > >> tty = tty_org; > >> > >> /* set terminal to raw mode ... */ > >> tty.sg_flags |= CRMOD; > >> tty.sg_flags &= ~ECHO; > >> tty.sg_flags &= ~XTABS; > >> tty.sg_flags |= RAW; > >> > >> Thanks! > >> Pierre-Luc Drouin > > > > Hi, > > > > You need to call this function: > > > > void > > cfmakeraw(struct termios *t); > > > > --HPS > > Hi, > > it still does not work. I have added the line > cfmakeraw(&newtio); > > just before the call to tcflush and I get the following output in > /var/log/messages: > Sep 21 13:38:46 ldaemon kernel: ucom_open:554: tp = 0xffffff001f12b400 > Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: onoff = 1 > Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 > Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 > Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 > Sep 21 13:38:46 ldaemon kernel: ucom_break:816: onoff = 0 > Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 > Sep 21 13:38:46 ldaemon kernel: ucom_status_change:901: > Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 > Sep 21 13:38:46 ldaemon kernel: uftdi_pre_param:653: > Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: onoff = 1 > Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 > Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 > Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 > Sep 21 13:38:46 ldaemon kernel: ucom_cfg_open:520: > Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_open:354: > uftdi_cfg_get_status:705: msr=0xf0 lsr=0x60 > Sep 21 13:38:46 ldaemon kernel: ucom_cfg_status_change:887: DCD changed to > 1 Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: > Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 > Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 > Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 > Sep 21 13:38:46 ldaemon kernel: uftdi_pre_param:653: > Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: > Sep 21 13:38:46 ldaemon kernel: ucom_get_data:1064: cnt=0 > Sep 21 13:38:47 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > Sep 21 13:38:48 ldaemon kernel: ucom_outwakeup:1009: sc = > 0xffffff001f12ac58 Sep 21 13:38:48 ldaemon kernel: ucom_get_data:1064: > cnt=2 > Sep 21 13:38:48 ldaemon kernel: ucom_get_data:1064: cnt=0 > Can you try adding a delay after setting the baud rate? --HPS From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 18:28:58 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86C5D106568F; Mon, 21 Sep 2009 18:28:58 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4BDA48FC1C; Mon, 21 Sep 2009 18:28:58 +0000 (UTC) Received: from mdaemon.pldrouin.net (pldrouinlap2-pc.physics.carleton.ca [134.117.23.34]) by smtp.cyberfingers.net (Postfix) with ESMTP id B0709AB6C1B; Mon, 21 Sep 2009 14:26:07 -0400 (EDT) Message-ID: <4AB7C5EA.5090008@pldrouin.net> Date: Mon, 21 Sep 2009 14:28:58 -0400 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: Hans Petter Selasky References: <4AB6DA79.7050209@pldrouin.net> <200909211932.37015.hselasky@c2i.net> <4AB7BD4D.4020703@pldrouin.net> <200909212014.36874.hselasky@c2i.net> In-Reply-To: <200909212014.36874.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ed@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 18:28:58 -0000 Hans Petter Selasky wrote: > On Monday 21 September 2009 19:52:13 Pierre-Luc Drouin wrote: > >> Hans Petter Selasky wrote: >> >>> On Monday 21 September 2009 19:29:10 Pierre-Luc Drouin wrote: >>> >>>> Hans Petter Selasky wrote: >>>> >>>>> On Monday 21 September 2009 03:44:25 Pierre-Luc Drouin wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I am also having troubles with the uftdi driver on 8.0-BETA4. >>>>>> I am trying to use a fan controller (mCubed bigNG) that uses a FT232BL >>>>>> chip and it does not seem to be responding on FreeBSD 8.0 while the >>>>>> same code works perfectly on Linux (I have not tried the code on >>>>>> RELENG_7 yet but I could install it if necessary). >>>>>> >>>>>> Here is the very simple code I am using for testing: >>>>>> #include >>>>>> #include >>>>>> #include >>>>>> #include >>>>>> #include >>>>>> >>>>>> int main(); >>>>>> >>>>>> #define DEV "/dev/ttyU0" >>>>>> >>>>>> #define TBAN_SER_SOURCE1 0x05 /* Primary source */ >>>>>> #define TBAN_SER_SOURCE2 0x06 /* Alternative source (miniNG...) >>>>>> */ >>>>>> >>>>>> #define TBAN_SER_REQUEST 0x36 >>>>>> >>>>>> int main() >>>>>> { >>>>>> int fd; >>>>>> int result; >>>>>> struct termios oldtio, newtio; >>>>>> unsigned char buf[285]; >>>>>> >>>>>> printf("Opening device\n"); >>>>>> fd=open(DEV, O_RDWR | O_NOCTTY); >>>>>> >>>>>> if(fd<0) { >>>>>> perror(DEV); >>>>>> return 1; >>>>>> } >>>>>> >>>>>> result=tcgetattr(fd,&oldtio); >>>>>> if(result<0) { >>>>>> perror("tcgetattr"); >>>>>> return 1; >>>>>> } >>>>>> >>>>>> memcpy(&newtio,&oldtio,sizeof(struct termios)); >>>>>> newtio.c_cflag = B19200 >>>>>> >>>>>> | CRTSCTS >>>>>> | CS8 >>>>>> | CREAD; >>>>>> >>>>>> newtio.c_iflag = IGNPAR; >>>>>> newtio.c_oflag = 0; >>>>>> newtio.c_lflag = 0; >>>>>> newtio.c_cc[VMIN] = 1; >>>>>> newtio.c_cc[VTIME] = 0; >>>>>> >>>>>> result=tcflush(fd, TCIFLUSH); >>>>>> if(result<0) { >>>>>> perror("tcflush"); >>>>>> return 1; >>>>>> } >>>>>> >>>>>> result=tcsetattr(fd,TCSANOW,&newtio); >>>>>> if(result<0) { >>>>>> perror("tcsetattr"); >>>>>> return 1; >>>>>> } >>>>>> >>>>>> sleep(1); >>>>>> >>>>>> printf("Performing initial query\n"); >>>>>> buf[0]=TBAN_SER_SOURCE1; >>>>>> buf[1]=TBAN_SER_REQUEST; >>>>>> >>>>>> printf("Requesting status\n"); >>>>>> result=write(fd,buf,2); >>>>>> if(result<0) { >>>>>> perror("write"); >>>>>> return 1; >>>>>> } >>>>>> >>>>>> sleep(1); >>>>>> >>>>>> printf("Reading status\n"); >>>>>> result=read(fd,buf,32); >>>>>> if(result<0) { >>>>>> perror("read"); >>>>>> return 1; >>>>>> } >>>>>> >>>>>> result=tcsetattr(fd,TCSANOW,&oldtio); >>>>>> if(result<0) { >>>>>> perror("tcsetattr"); >>>>>> return 1; >>>>>> } >>>>>> >>>>>> result=close(fd); >>>>>> if(result<0) { >>>>>> perror("close"); >>>>>> return 1; >>>>>> } >>>>>> return 0; >>>>>> } >>>>>> >>>>>> It hangs while reading independently of the number of bits I am >>>>>> reading. >>>>>> >>>>>> Here is the output from dmesg when I load the uftdi module: >>>>>> Sep 20 21:31:31 ldaemon kernel: uftdi0: on usbus6 >>>>>> Sep 20 21:31:31 ldaemon kernel: ucom_attach_tty:317: tp = >>>>>> 0xffffff001f12b400, unit = 0 Sep 20 21:31:31 ldaemon kernel: >>>>>> ucom_attach_tty:346: ttycreate: U0 Sep 20 21:31:34 ldaemon root: >>>>>> Unknown USB device: vendor 0x051d product 0x0002 bus uhub0 >>>>>> >>>>>> Here is the output in /var/log/messages when I enable the debug output >>>>>> for ucom and uftdi: Sep 20 21:33:30 ldaemon kernel: ucom_open:554: tp >>>>>> = 0xffffff001f12b400 Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: >>>>>> onoff = 1 Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: >>>>>> on=0x01, off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff >>>>>> = 1 >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_break:816: onoff = 0 >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_status_change:901: >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = >>>>>> 0xffffff001f12ac58 Sep 20 21:33:30 ldaemon kernel: >>>>>> uftdi_pre_param:653: >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = 1 >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_cfg_open:520: >>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_open:354: >>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_read_callback:459: status change >>>>>> msr=0xf0 (0x00) lsr=0x60 (0x00) Sep 20 21:33:30 ldaemon kernel: >>>>>> ucom_status_change:901: >>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 >>>>>> lsr=0x60 Sep 20 21:33:30 ldaemon kernel: ucom_cfg_status_change:887: >>>>>> DCD changed to 1 Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 Sep >>>>>> 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 Sep 20 >>>>>> 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 Sep 20 >>>>>> 21:33:30 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 Sep >>>>>> 20 21:33:30 ldaemon kernel: uftdi_pre_param:653: >>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 >>>>>> lsr=0x60 Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_get_data:1064: cnt=0 >>>>>> Sep 20 21:33:31 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >>>>>> Sep 20 21:33:32 ldaemon kernel: ucom_outwakeup:1009: sc = >>>>>> 0xffffff001f12ac58 Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: >>>>>> cnt=2 >>>>>> Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: cnt=0 >>>>>> >>>>>> I really need to get this working so I am ready to test things as much >>>>>> as I can... >>>>>> >>>>> Hi, >>>>> >>>>> You need to set raw mode for the TTY device I think. Maybe Ed can give >>>>> you the function name you need to call to do that? >>>>> >>>>> --HPS >>>>> >>>> Do I need to do something like that? >>>> ioctl(fileno(stdin), TIOCGETP, &tty_org); >>>> tty = tty_org; >>>> >>>> /* set terminal to raw mode ... */ >>>> tty.sg_flags |= CRMOD; >>>> tty.sg_flags &= ~ECHO; >>>> tty.sg_flags &= ~XTABS; >>>> tty.sg_flags |= RAW; >>>> >>>> Thanks! >>>> Pierre-Luc Drouin >>>> >>> Hi, >>> >>> You need to call this function: >>> >>> void >>> cfmakeraw(struct termios *t); >>> >>> --HPS >>> >> Hi, >> >> it still does not work. I have added the line >> cfmakeraw(&newtio); >> >> just before the call to tcflush and I get the following output in >> /var/log/messages: >> Sep 21 13:38:46 ldaemon kernel: ucom_open:554: tp = 0xffffff001f12b400 >> Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: onoff = 1 >> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 >> Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 >> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 >> Sep 21 13:38:46 ldaemon kernel: ucom_break:816: onoff = 0 >> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 >> Sep 21 13:38:46 ldaemon kernel: ucom_status_change:901: >> Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 >> Sep 21 13:38:46 ldaemon kernel: uftdi_pre_param:653: >> Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: onoff = 1 >> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 >> Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 >> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 >> Sep 21 13:38:46 ldaemon kernel: ucom_cfg_open:520: >> Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_open:354: >> uftdi_cfg_get_status:705: msr=0xf0 lsr=0x60 >> Sep 21 13:38:46 ldaemon kernel: ucom_cfg_status_change:887: DCD changed to >> 1 Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: >> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 >> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 >> Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 >> Sep 21 13:38:46 ldaemon kernel: uftdi_pre_param:653: >> Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: >> Sep 21 13:38:46 ldaemon kernel: ucom_get_data:1064: cnt=0 >> Sep 21 13:38:47 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >> Sep 21 13:38:48 ldaemon kernel: ucom_outwakeup:1009: sc = >> 0xffffff001f12ac58 Sep 21 13:38:48 ldaemon kernel: ucom_get_data:1064: >> cnt=2 >> Sep 21 13:38:48 ldaemon kernel: ucom_get_data:1064: cnt=0 >> >> > > Can you try adding a delay after setting the baud rate? > > --HPS > The code already sleeps for 1 second after I applying the baud rate (via tcsetattr(fd,TCSANOW,&newtio)). I am not sure to understand what you mean... Thanks From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 18:44:45 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C79A106566C; Mon, 21 Sep 2009 18:44:45 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 2D5B38FC0C; Mon, 21 Sep 2009 18:44:43 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=6U-Pe18MTAwA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=m7lBX3-ARKsg1kWO6hYA:9 a=RH0_KsYfR3Ynlcsu7SMA:7 a=9o5o-u7TH0s5mO8gHGeZCQ-AkpYA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1301281811; Mon, 21 Sep 2009 20:44:42 +0200 From: Hans Petter Selasky To: "Pierre-Luc Drouin" Date: Mon, 21 Sep 2009 20:45:19 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <4AB6DA79.7050209@pldrouin.net> <200909212014.36874.hselasky@c2i.net> <4AB7C5EA.5090008@pldrouin.net> In-Reply-To: <4AB7C5EA.5090008@pldrouin.net> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909212045.20657.hselasky@c2i.net> Cc: ed@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 18:44:45 -0000 On Monday 21 September 2009 20:28:58 Pierre-Luc Drouin wrote: > Hans Petter Selasky wrote: > > On Monday 21 September 2009 19:52:13 Pierre-Luc Drouin wrote: > >> Hans Petter Selasky wrote: > >>> On Monday 21 September 2009 19:29:10 Pierre-Luc Drouin wrote: > >>>> Hans Petter Selasky wrote: > >>>>> On Monday 21 September 2009 03:44:25 Pierre-Luc Drouin wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I am also having troubles with the uftdi driver on 8.0-BETA4. > >>>>>> I am trying to use a fan controller (mCubed bigNG) that uses a > >>>>>> FT232BL chip and it does not seem to be responding on FreeBSD 8.0 > >>>>>> while the same code works perfectly on Linux (I have not tried the > >>>>>> code on RELENG_7 yet but I could install it if necessary). > >>>>>> > >>>>>> Here is the very simple code I am using for testing: > >>>>>> #include > >>>>>> #include > >>>>>> #include > >>>>>> #include > >>>>>> #include > >>>>>> > >>>>>> int main(); > >>>>>> > >>>>>> #define DEV "/dev/ttyU0" > >>>>>> > >>>>>> #define TBAN_SER_SOURCE1 0x05 /* Primary source */ > >>>>>> #define TBAN_SER_SOURCE2 0x06 /* Alternative source > >>>>>> (miniNG...) */ > >>>>>> > >>>>>> #define TBAN_SER_REQUEST 0x36 > >>>>>> > >>>>>> int main() > >>>>>> { > >>>>>> int fd; > >>>>>> int result; > >>>>>> struct termios oldtio, newtio; > >>>>>> unsigned char buf[285]; > >>>>>> > >>>>>> printf("Opening device\n"); > >>>>>> fd=open(DEV, O_RDWR | O_NOCTTY); > >>>>>> > >>>>>> if(fd<0) { > >>>>>> perror(DEV); > >>>>>> return 1; > >>>>>> } > >>>>>> > >>>>>> result=tcgetattr(fd,&oldtio); > >>>>>> if(result<0) { > >>>>>> perror("tcgetattr"); > >>>>>> return 1; > >>>>>> } > >>>>>> > >>>>>> memcpy(&newtio,&oldtio,sizeof(struct termios)); > >>>>>> newtio.c_cflag = B19200 > >>>>>> > >>>>>> | CRTSCTS > >>>>>> | CS8 > >>>>>> | CREAD; > >>>>>> > >>>>>> newtio.c_iflag = IGNPAR; > >>>>>> newtio.c_oflag = 0; > >>>>>> newtio.c_lflag = 0; > >>>>>> newtio.c_cc[VMIN] = 1; > >>>>>> newtio.c_cc[VTIME] = 0; > >>>>>> > >>>>>> result=tcflush(fd, TCIFLUSH); > >>>>>> if(result<0) { > >>>>>> perror("tcflush"); > >>>>>> return 1; > >>>>>> } > >>>>>> > >>>>>> result=tcsetattr(fd,TCSANOW,&newtio); > >>>>>> if(result<0) { > >>>>>> perror("tcsetattr"); > >>>>>> return 1; > >>>>>> } > >>>>>> > >>>>>> sleep(1); > >>>>>> > >>>>>> printf("Performing initial query\n"); > >>>>>> buf[0]=TBAN_SER_SOURCE1; > >>>>>> buf[1]=TBAN_SER_REQUEST; > >>>>>> > >>>>>> printf("Requesting status\n"); > >>>>>> result=write(fd,buf,2); > >>>>>> if(result<0) { > >>>>>> perror("write"); > >>>>>> return 1; > >>>>>> } > >>>>>> > >>>>>> sleep(1); > >>>>>> > >>>>>> printf("Reading status\n"); > >>>>>> result=read(fd,buf,32); > >>>>>> if(result<0) { > >>>>>> perror("read"); > >>>>>> return 1; > >>>>>> } > >>>>>> > >>>>>> result=tcsetattr(fd,TCSANOW,&oldtio); > >>>>>> if(result<0) { > >>>>>> perror("tcsetattr"); > >>>>>> return 1; > >>>>>> } > >>>>>> > >>>>>> result=close(fd); > >>>>>> if(result<0) { > >>>>>> perror("close"); > >>>>>> return 1; > >>>>>> } > >>>>>> return 0; > >>>>>> } > >>>>>> > >>>>>> It hangs while reading independently of the number of bits I am > >>>>>> reading. > >>>>>> > >>>>>> Here is the output from dmesg when I load the uftdi module: > >>>>>> Sep 20 21:31:31 ldaemon kernel: uftdi0: on usbus6 > >>>>>> Sep 20 21:31:31 ldaemon kernel: ucom_attach_tty:317: tp = > >>>>>> 0xffffff001f12b400, unit = 0 Sep 20 21:31:31 ldaemon kernel: > >>>>>> ucom_attach_tty:346: ttycreate: U0 Sep 20 21:31:34 ldaemon root: > >>>>>> Unknown USB device: vendor 0x051d product 0x0002 bus uhub0 > >>>>>> > >>>>>> Here is the output in /var/log/messages when I enable the debug > >>>>>> output for ucom and uftdi: Sep 20 21:33:30 ldaemon kernel: > >>>>>> ucom_open:554: tp = 0xffffff001f12b400 Sep 20 21:33:30 ldaemon > >>>>>> kernel: ucom_dtr:827: onoff = 1 Sep 20 21:33:30 ldaemon kernel: > >>>>>> ucom_line_state:799: on=0x01, off=0x00 Sep 20 21:33:30 ldaemon > >>>>>> kernel: ucom_rts:838: onoff = 1 > >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, > >>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_break:816: onoff = 0 > >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x00, > >>>>>> off=0x04 Sep 20 21:33:30 ldaemon kernel: ucom_status_change:901: > >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = > >>>>>> 0xffffff001f12ac58 Sep 20 21:33:30 ldaemon kernel: > >>>>>> uftdi_pre_param:653: > >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = 1 > >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, > >>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 > >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, > >>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_cfg_open:520: > >>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_open:354: > >>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_read_callback:459: status > >>>>>> change msr=0xf0 (0x00) lsr=0x60 (0x00) Sep 20 21:33:30 ldaemon > >>>>>> kernel: ucom_status_change:901: > >>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 > >>>>>> lsr=0x60 Sep 20 21:33:30 ldaemon kernel: ucom_cfg_status_change:887: > >>>>>> DCD changed to 1 Sep 20 21:33:30 ldaemon kernel: > >>>>>> uftdi_cfg_param:672: Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: > >>>>>> cmd = 0x402c7413 Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd > >>>>>> = 0x80047410 Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = > >>>>>> 0x802c7414 Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = > >>>>>> 0xffffff001f12ac58 Sep 20 21:33:30 ldaemon kernel: > >>>>>> uftdi_pre_param:653: > >>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 > >>>>>> lsr=0x60 Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: > >>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_get_data:1064: cnt=0 > >>>>>> Sep 20 21:33:31 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > >>>>>> Sep 20 21:33:32 ldaemon kernel: ucom_outwakeup:1009: sc = > >>>>>> 0xffffff001f12ac58 Sep 20 21:33:32 ldaemon kernel: > >>>>>> ucom_get_data:1064: cnt=2 > >>>>>> Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: cnt=0 > >>>>>> > >>>>>> I really need to get this working so I am ready to test things as > >>>>>> much as I can... > >>>>> > >>>>> Hi, > >>>>> > >>>>> You need to set raw mode for the TTY device I think. Maybe Ed can > >>>>> give you the function name you need to call to do that? > >>>>> > >>>>> --HPS > >>>> > >>>> Do I need to do something like that? > >>>> ioctl(fileno(stdin), TIOCGETP, &tty_org); > >>>> tty = tty_org; > >>>> > >>>> /* set terminal to raw mode ... */ > >>>> tty.sg_flags |= CRMOD; > >>>> tty.sg_flags &= ~ECHO; > >>>> tty.sg_flags &= ~XTABS; > >>>> tty.sg_flags |= RAW; > >>>> > >>>> Thanks! > >>>> Pierre-Luc Drouin > >>> > >>> Hi, > >>> > >>> You need to call this function: > >>> > >>> void > >>> cfmakeraw(struct termios *t); > >>> > >>> --HPS > >> > >> Hi, > >> > >> it still does not work. I have added the line > >> cfmakeraw(&newtio); > >> > >> just before the call to tcflush and I get the following output in > >> /var/log/messages: > >> Sep 21 13:38:46 ldaemon kernel: ucom_open:554: tp = 0xffffff001f12b400 > >> Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: onoff = 1 > >> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 > >> Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 > >> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 > >> Sep 21 13:38:46 ldaemon kernel: ucom_break:816: onoff = 0 > >> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 > >> Sep 21 13:38:46 ldaemon kernel: ucom_status_change:901: > >> Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 > >> Sep 21 13:38:46 ldaemon kernel: uftdi_pre_param:653: > >> Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: onoff = 1 > >> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 > >> Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 > >> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 > >> Sep 21 13:38:46 ldaemon kernel: ucom_cfg_open:520: > >> Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_open:354: > >> uftdi_cfg_get_status:705: msr=0xf0 lsr=0x60 > >> Sep 21 13:38:46 ldaemon kernel: ucom_cfg_status_change:887: DCD changed > >> to 1 Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: > >> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 > >> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > >> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 > >> Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 > >> Sep 21 13:38:46 ldaemon kernel: uftdi_pre_param:653: > >> Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: > >> Sep 21 13:38:46 ldaemon kernel: ucom_get_data:1064: cnt=0 > >> Sep 21 13:38:47 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > >> Sep 21 13:38:48 ldaemon kernel: ucom_outwakeup:1009: sc = > >> 0xffffff001f12ac58 Sep 21 13:38:48 ldaemon kernel: ucom_get_data:1064: > >> cnt=2 > >> Sep 21 13:38:48 ldaemon kernel: ucom_get_data:1064: cnt=0 > > > > Can you try adding a delay after setting the baud rate? > > > > --HPS > > The code already sleeps for 1 second after I applying the baud rate (via > tcsetattr(fd,TCSANOW,&newtio)). I am not sure to understand what you > mean... Hi, I mean try adding some: usleep(1000000); To your code to see if that changes anything. Also try reading one byte instead of 32. Last, try adding a printout to: src/sys/dev/usb/serial/uftdi.c uftdi_read_callback() and printout the actlen variable. --HPS From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 18:58:43 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5976C106566B; Mon, 21 Sep 2009 18:58:43 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id 056B68FC1B; Mon, 21 Sep 2009 18:58:42 +0000 (UTC) Received: from mdaemon.pldrouin.net (pldrouinlap2-pc.physics.carleton.ca [134.117.23.34]) by smtp.cyberfingers.net (Postfix) with ESMTP id 5254DAB6C16; Mon, 21 Sep 2009 14:55:52 -0400 (EDT) Message-ID: <4AB7CCE0.2000703@pldrouin.net> Date: Mon, 21 Sep 2009 14:58:40 -0400 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: Hans Petter Selasky References: <4AB6DA79.7050209@pldrouin.net> <200909212014.36874.hselasky@c2i.net> <4AB7C5EA.5090008@pldrouin.net> <200909212045.20657.hselasky@c2i.net> In-Reply-To: <200909212045.20657.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ed@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 18:58:43 -0000 Hans Petter Selasky wrote: > On Monday 21 September 2009 20:28:58 Pierre-Luc Drouin wrote: > >> Hans Petter Selasky wrote: >> >>> On Monday 21 September 2009 19:52:13 Pierre-Luc Drouin wrote: >>> >>>> Hans Petter Selasky wrote: >>>> >>>>> On Monday 21 September 2009 19:29:10 Pierre-Luc Drouin wrote: >>>>> >>>>>> Hans Petter Selasky wrote: >>>>>> >>>>>>> On Monday 21 September 2009 03:44:25 Pierre-Luc Drouin wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I am also having troubles with the uftdi driver on 8.0-BETA4. >>>>>>>> I am trying to use a fan controller (mCubed bigNG) that uses a >>>>>>>> FT232BL chip and it does not seem to be responding on FreeBSD 8.0 >>>>>>>> while the same code works perfectly on Linux (I have not tried the >>>>>>>> code on RELENG_7 yet but I could install it if necessary). >>>>>>>> >>>>>>>> Here is the very simple code I am using for testing: >>>>>>>> #include >>>>>>>> #include >>>>>>>> #include >>>>>>>> #include >>>>>>>> #include >>>>>>>> >>>>>>>> int main(); >>>>>>>> >>>>>>>> #define DEV "/dev/ttyU0" >>>>>>>> >>>>>>>> #define TBAN_SER_SOURCE1 0x05 /* Primary source */ >>>>>>>> #define TBAN_SER_SOURCE2 0x06 /* Alternative source >>>>>>>> (miniNG...) */ >>>>>>>> >>>>>>>> #define TBAN_SER_REQUEST 0x36 >>>>>>>> >>>>>>>> int main() >>>>>>>> { >>>>>>>> int fd; >>>>>>>> int result; >>>>>>>> struct termios oldtio, newtio; >>>>>>>> unsigned char buf[285]; >>>>>>>> >>>>>>>> printf("Opening device\n"); >>>>>>>> fd=open(DEV, O_RDWR | O_NOCTTY); >>>>>>>> >>>>>>>> if(fd<0) { >>>>>>>> perror(DEV); >>>>>>>> return 1; >>>>>>>> } >>>>>>>> >>>>>>>> result=tcgetattr(fd,&oldtio); >>>>>>>> if(result<0) { >>>>>>>> perror("tcgetattr"); >>>>>>>> return 1; >>>>>>>> } >>>>>>>> >>>>>>>> memcpy(&newtio,&oldtio,sizeof(struct termios)); >>>>>>>> newtio.c_cflag = B19200 >>>>>>>> >>>>>>>> | CRTSCTS >>>>>>>> | CS8 >>>>>>>> | CREAD; >>>>>>>> >>>>>>>> newtio.c_iflag = IGNPAR; >>>>>>>> newtio.c_oflag = 0; >>>>>>>> newtio.c_lflag = 0; >>>>>>>> newtio.c_cc[VMIN] = 1; >>>>>>>> newtio.c_cc[VTIME] = 0; >>>>>>>> >>>>>>>> result=tcflush(fd, TCIFLUSH); >>>>>>>> if(result<0) { >>>>>>>> perror("tcflush"); >>>>>>>> return 1; >>>>>>>> } >>>>>>>> >>>>>>>> result=tcsetattr(fd,TCSANOW,&newtio); >>>>>>>> if(result<0) { >>>>>>>> perror("tcsetattr"); >>>>>>>> return 1; >>>>>>>> } >>>>>>>> >>>>>>>> sleep(1); >>>>>>>> >>>>>>>> printf("Performing initial query\n"); >>>>>>>> buf[0]=TBAN_SER_SOURCE1; >>>>>>>> buf[1]=TBAN_SER_REQUEST; >>>>>>>> >>>>>>>> printf("Requesting status\n"); >>>>>>>> result=write(fd,buf,2); >>>>>>>> if(result<0) { >>>>>>>> perror("write"); >>>>>>>> return 1; >>>>>>>> } >>>>>>>> >>>>>>>> sleep(1); >>>>>>>> >>>>>>>> printf("Reading status\n"); >>>>>>>> result=read(fd,buf,32); >>>>>>>> if(result<0) { >>>>>>>> perror("read"); >>>>>>>> return 1; >>>>>>>> } >>>>>>>> >>>>>>>> result=tcsetattr(fd,TCSANOW,&oldtio); >>>>>>>> if(result<0) { >>>>>>>> perror("tcsetattr"); >>>>>>>> return 1; >>>>>>>> } >>>>>>>> >>>>>>>> result=close(fd); >>>>>>>> if(result<0) { >>>>>>>> perror("close"); >>>>>>>> return 1; >>>>>>>> } >>>>>>>> return 0; >>>>>>>> } >>>>>>>> >>>>>>>> It hangs while reading independently of the number of bits I am >>>>>>>> reading. >>>>>>>> >>>>>>>> Here is the output from dmesg when I load the uftdi module: >>>>>>>> Sep 20 21:31:31 ldaemon kernel: uftdi0: on usbus6 >>>>>>>> Sep 20 21:31:31 ldaemon kernel: ucom_attach_tty:317: tp = >>>>>>>> 0xffffff001f12b400, unit = 0 Sep 20 21:31:31 ldaemon kernel: >>>>>>>> ucom_attach_tty:346: ttycreate: U0 Sep 20 21:31:34 ldaemon root: >>>>>>>> Unknown USB device: vendor 0x051d product 0x0002 bus uhub0 >>>>>>>> >>>>>>>> Here is the output in /var/log/messages when I enable the debug >>>>>>>> output for ucom and uftdi: Sep 20 21:33:30 ldaemon kernel: >>>>>>>> ucom_open:554: tp = 0xffffff001f12b400 Sep 20 21:33:30 ldaemon >>>>>>>> kernel: ucom_dtr:827: onoff = 1 Sep 20 21:33:30 ldaemon kernel: >>>>>>>> ucom_line_state:799: on=0x01, off=0x00 Sep 20 21:33:30 ldaemon >>>>>>>> kernel: ucom_rts:838: onoff = 1 >>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, >>>>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_break:816: onoff = 0 >>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x00, >>>>>>>> off=0x04 Sep 20 21:33:30 ldaemon kernel: ucom_status_change:901: >>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = >>>>>>>> 0xffffff001f12ac58 Sep 20 21:33:30 ldaemon kernel: >>>>>>>> uftdi_pre_param:653: >>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = 1 >>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, >>>>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 >>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, >>>>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_cfg_open:520: >>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_open:354: >>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_read_callback:459: status >>>>>>>> change msr=0xf0 (0x00) lsr=0x60 (0x00) Sep 20 21:33:30 ldaemon >>>>>>>> kernel: ucom_status_change:901: >>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 >>>>>>>> lsr=0x60 Sep 20 21:33:30 ldaemon kernel: ucom_cfg_status_change:887: >>>>>>>> DCD changed to 1 Sep 20 21:33:30 ldaemon kernel: >>>>>>>> uftdi_cfg_param:672: Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: >>>>>>>> cmd = 0x402c7413 Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd >>>>>>>> = 0x80047410 Sep 20 21:33:30 ldaemon kernel: ucom_ioctl:653: cmd = >>>>>>>> 0x802c7414 Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = >>>>>>>> 0xffffff001f12ac58 Sep 20 21:33:30 ldaemon kernel: >>>>>>>> uftdi_pre_param:653: >>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 >>>>>>>> lsr=0x60 Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: >>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_get_data:1064: cnt=0 >>>>>>>> Sep 20 21:33:31 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >>>>>>>> Sep 20 21:33:32 ldaemon kernel: ucom_outwakeup:1009: sc = >>>>>>>> 0xffffff001f12ac58 Sep 20 21:33:32 ldaemon kernel: >>>>>>>> ucom_get_data:1064: cnt=2 >>>>>>>> Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: cnt=0 >>>>>>>> >>>>>>>> I really need to get this working so I am ready to test things as >>>>>>>> much as I can... >>>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> You need to set raw mode for the TTY device I think. Maybe Ed can >>>>>>> give you the function name you need to call to do that? >>>>>>> >>>>>>> --HPS >>>>>>> >>>>>> Do I need to do something like that? >>>>>> ioctl(fileno(stdin), TIOCGETP, &tty_org); >>>>>> tty = tty_org; >>>>>> >>>>>> /* set terminal to raw mode ... */ >>>>>> tty.sg_flags |= CRMOD; >>>>>> tty.sg_flags &= ~ECHO; >>>>>> tty.sg_flags &= ~XTABS; >>>>>> tty.sg_flags |= RAW; >>>>>> >>>>>> Thanks! >>>>>> Pierre-Luc Drouin >>>>>> >>>>> Hi, >>>>> >>>>> You need to call this function: >>>>> >>>>> void >>>>> cfmakeraw(struct termios *t); >>>>> >>>>> --HPS >>>>> >>>> Hi, >>>> >>>> it still does not work. I have added the line >>>> cfmakeraw(&newtio); >>>> >>>> just before the call to tcflush and I get the following output in >>>> /var/log/messages: >>>> Sep 21 13:38:46 ldaemon kernel: ucom_open:554: tp = 0xffffff001f12b400 >>>> Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: onoff = 1 >>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 >>>> Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 >>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 >>>> Sep 21 13:38:46 ldaemon kernel: ucom_break:816: onoff = 0 >>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 >>>> Sep 21 13:38:46 ldaemon kernel: ucom_status_change:901: >>>> Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 >>>> Sep 21 13:38:46 ldaemon kernel: uftdi_pre_param:653: >>>> Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: onoff = 1 >>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 >>>> Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 >>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 >>>> Sep 21 13:38:46 ldaemon kernel: ucom_cfg_open:520: >>>> Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_open:354: >>>> uftdi_cfg_get_status:705: msr=0xf0 lsr=0x60 >>>> Sep 21 13:38:46 ldaemon kernel: ucom_cfg_status_change:887: DCD changed >>>> to 1 Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: >>>> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 >>>> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >>>> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 >>>> Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = 0xffffff001f12ac58 >>>> Sep 21 13:38:46 ldaemon kernel: uftdi_pre_param:653: >>>> Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: >>>> Sep 21 13:38:46 ldaemon kernel: ucom_get_data:1064: cnt=0 >>>> Sep 21 13:38:47 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >>>> Sep 21 13:38:48 ldaemon kernel: ucom_outwakeup:1009: sc = >>>> 0xffffff001f12ac58 Sep 21 13:38:48 ldaemon kernel: ucom_get_data:1064: >>>> cnt=2 >>>> Sep 21 13:38:48 ldaemon kernel: ucom_get_data:1064: cnt=0 >>>> >>> Can you try adding a delay after setting the baud rate? >>> >>> --HPS >>> >> The code already sleeps for 1 second after I applying the baud rate (via >> tcsetattr(fd,TCSANOW,&newtio)). I am not sure to understand what you >> mean... >> > > Hi, > > I mean try adding some: > > usleep(1000000); > > To your code to see if that changes anything. > > Also try reading one byte instead of 32. > > Last, try adding a printout to: > > src/sys/dev/usb/serial/uftdi.c > > uftdi_read_callback() > > and printout the actlen variable. > > --HPS > > ok, so I added the usleep statement right after the existing sleep statement. I also tried reading a single byte. It did not make any difference... I added a print statement to print the value of actlen right after it is set via usbd_xfer_status(xfer, &actlen, NULL, NULL, NULL); Here is the new output in /var/log/messages: Sep 21 14:55:28 ldaemon kernel: ucom_open:554: tp = 0xffffff0139488800 Sep 21 14:55:28 ldaemon kernel: ucom_dtr:827: onoff = 1 Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 Sep 21 14:55:28 ldaemon kernel: ucom_rts:838: onoff = 1 Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 Sep 21 14:55:28 ldaemon kernel: ucom_break:816: onoff = 0 Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 Sep 21 14:55:28 ldaemon kernel: ucom_status_change:901: Sep 21 14:55:28 ldaemon kernel: ucom_param:950: sc = 0xffffff013bcac458 Sep 21 14:55:28 ldaemon kernel: ucom_dtr:827: onoff = 1 Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 Sep 21 14:55:28 ldaemon kernel: ucom_rts:838: onoff = 1 Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 Sep 21 14:55:28 ldaemon kernel: ucom_cfg_open:520: Sep 21 14:55:28 ldaemon kernel: actlen is 0 Sep 21 14:55:28 ldaemon kernel: actlen is 2 Sep 21 14:55:28 ldaemon kernel: actlen is 2 Sep 21 14:55:28 ldaemon kernel: ucom_cfg_status_change:887: DCD changed to 1 Sep 21 14:55:28 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 Sep 21 14:55:28 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 Sep 21 14:55:28 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 Sep 21 14:55:28 ldaemon kernel: ucom_param:950: sc = 0xffffff013bcac458 Sep 21 14:55:28 ldaemon kernel: actlen is 2 Sep 21 14:55:28 ldaemon last message repeated 12 times Sep 21 14:55:28 ldaemon kernel: ucom_get_data:1064: cnt=0 Sep 21 14:55:28 ldaemon kernel: actlen is 2 Sep 21 14:55:30 ldaemon last message repeated 111 times Sep 21 14:55:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 Sep 21 14:55:30 ldaemon kernel: actlen is 2 Sep 21 14:55:31 ldaemon last message repeated 62 times Sep 21 14:55:31 ldaemon kernel: ucom_outwakeup:1009: sc = 0xffffff013bcac458 Sep 21 14:55:31 ldaemon kernel: ucom_get_data:1064: cnt=2 Sep 21 14:55:31 ldaemon kernel: ucom_get_data:1064: cnt=0 Sep 21 14:55:31 ldaemon kernel: actlen is 2 From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 19:43:51 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C17C1065672 for ; Mon, 21 Sep 2009 19:43:51 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 0F3D58FC12 for ; Mon, 21 Sep 2009 19:43:50 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KQC00EGI410LVB0@osl1smout1.broadpark.no> for freebsd-usb@freebsd.org; Mon, 21 Sep 2009 20:43:48 +0200 (CEST) Received: from kg-v2.kg4.no ([84.48.215.119]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KQC00L1I410AI40@osl1sminn1.broadpark.no> for freebsd-usb@freebsd.org; Mon, 21 Sep 2009 20:43:48 +0200 (CEST) Date: Mon, 21 Sep 2009 20:43:47 +0200 From: Torfinn Ingolfsen To: freebsd-usb@freebsd.org Message-id: <20090921204347.8f26bd21.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; amd64-portbld-freebsd7.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: PLease trim your quotes! X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 19:43:51 -0000 Everybody. please, PLEASE trim your quotes to the bare minimum when replying to any message. Thank you. -- Regards, Torfinn Ingolfsen From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 19:48:51 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82E801065693 for ; Mon, 21 Sep 2009 19:48:51 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC2D8FC1A for ; Mon, 21 Sep 2009 19:48:51 +0000 (UTC) Received: from mdaemon.pldrouin.net (pldrouinlap2-pc.physics.carleton.ca [134.117.23.34]) by smtp.cyberfingers.net (Postfix) with ESMTP id EDAA1AB6C1B; Mon, 21 Sep 2009 15:46:00 -0400 (EDT) Message-ID: <4AB7D8A3.3070809@pldrouin.net> Date: Mon, 21 Sep 2009 15:48:51 -0400 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: Ed Schouten References: <4AB6DA79.7050209@pldrouin.net> <200909211827.53014.hselasky@c2i.net> <20090921194342.GA95398@hoeg.nl> In-Reply-To: <20090921194342.GA95398@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 19:48:51 -0000 Hi, In my case I cvsuped the sources on September 14th. I can cvsup them again and make buildworld with the latest sources if necessary. Thank you Pierre-Luc Drouin Ed Schouten wrote: > Hi, > > Sorry for being ignorant. I still have to catch up with the emails, but > I just read this: > > after i upgraded one of the machines to then 8-CURRENT on Aug 19 > 2009, i noticed the following problems: > > Keep in mind that MPSAFE TTY was imported on August 20. > > Will read the rest of the messages now. > > From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 19:55:57 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2795B1065670 for ; Mon, 21 Sep 2009 19:55:57 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id 040EA8FC2D for ; Mon, 21 Sep 2009 19:55:55 +0000 (UTC) Received: from mdaemon.pldrouin.net (pldrouinlap2-pc.physics.carleton.ca [134.117.23.34]) by smtp.cyberfingers.net (Postfix) with ESMTP id D0AF9AB6C0F; Mon, 21 Sep 2009 15:53:04 -0400 (EDT) Message-ID: <4AB7DA4B.8050105@pldrouin.net> Date: Mon, 21 Sep 2009 15:55:55 -0400 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: Ed Schouten References: <4AB6DA79.7050209@pldrouin.net> <200909211827.53014.hselasky@c2i.net> <20090921194933.GB95398@hoeg.nl> In-Reply-To: <20090921194933.GB95398@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 19:55:57 -0000 Ed Schouten wrote: > Hi Pierre-Luc, Hans, > > * Hans Petter Selasky wrote: > >> You need to set raw mode for the TTY device I think. Maybe Ed can give you the >> function name you need to call to do that? >> > > Yes. You need cfmakeraw() to do that (or do everything yourself). See > src/lib/libc/gen/termios.c to see what it does. > > So what I'm interested in, is the following: > > "even that device is answering requests slower and slower until > it stalls completely within 1 hour" > > Could you run `pstat -t' to see what's going on when it stalls? This > nifty tool just gives some random statistics on TTYs. Very useful to see > what's going on. Where data is stuck, etc. etc. > > Here is what I get from pstat when I run my executable: while ( 1 ) while? pstat -t ttyU0 | grep ttyU0 while? sleep 1 while? end LINE INQ CAN LIN LOW OUTQ USE LOW COL SESS PGID STATE ttyU0 0 0 0 0 0 0 0 4 0 0 ICl ttyU0 0 0 0 0 0 0 0 4 0 0 ICl ttyU0 0 0 0 0 0 0 0 4 0 0 ICl ttyU0 0 0 0 0 0 0 0 4 0 0 ICl ttyU0 0 0 0 0 0 0 0 4 0 0 ICl ttyU0 0 0 0 0 0 0 0 4 0 0 ICl ttyU0 0 0 0 0 0 0 0 4 0 0 ICl ttyU0 0 0 0 0 0 0 0 4 0 0 ICl ttyU0 1920 0 0 192 1984 0 199 4 0 0 ICOil ttyU0 1920 0 0 192 1984 0 199 4 0 0 ICOil ttyU0 1920 0 0 192 1984 0 199 4 0 0 ICOil ttyU0 1920 0 0 192 1984 0 199 6 0 0 ICOil ttyU0 1920 0 0 192 1984 0 199 6 0 0 ICOil ttyU0 1920 0 0 192 1984 0 199 6 0 0 ICOil ttyU0 1920 0 0 192 1984 0 199 6 0 0 ICOil ttyU0 1920 0 0 192 1984 0 199 6 0 0 ICOil ttyU0 1920 0 0 192 1984 0 199 6 0 0 ICOil ttyU0 1920 0 0 192 1984 0 199 6 0 0 ICOil ttyU0 1920 0 0 192 1984 0 199 6 0 0 ICOil ttyU0 1920 0 0 192 1984 0 199 6 0 0 ICOil ttyU0 1920 0 0 192 1984 0 199 6 0 0 ICOil ttyU0 1920 0 0 192 1984 0 199 6 0 0 ICOil ttyU0 1920 0 0 192 1984 0 199 6 0 0 ICOil From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 19:59:28 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20B071065676 for ; Mon, 21 Sep 2009 19:59:28 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [87.251.61.211]) by mx1.freebsd.org (Postfix) with ESMTP id DBBA28FC0C for ; Mon, 21 Sep 2009 19:59:27 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 886401CFC1; Mon, 21 Sep 2009 21:43:42 +0200 (CEST) Date: Mon, 21 Sep 2009 21:43:42 +0200 From: Ed Schouten To: Hans Petter Selasky Message-ID: <20090921194342.GA95398@hoeg.nl> References: <4AB6DA79.7050209@pldrouin.net> <200909211827.53014.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GhOjTe89cQfBPqWP" Content-Disposition: inline In-Reply-To: <200909211827.53014.hselasky@c2i.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 19:59:28 -0000 --GhOjTe89cQfBPqWP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Sorry for being ignorant. I still have to catch up with the emails, but I just read this: after i upgraded one of the machines to then 8-CURRENT on Aug 19 2009, i noticed the following problems: Keep in mind that MPSAFE TTY was imported on August 20. Will read the rest of the messages now. --=20 Ed Schouten WWW: http://80386.nl/ --GhOjTe89cQfBPqWP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkq3124ACgkQ52SDGA2eCwUwrACfUJkkj+Q5QlS4ETX0juRqgLAw hFIAn2L/sINgGOMLl5oFe4wjUsZGOvQi =dclw -----END PGP SIGNATURE----- --GhOjTe89cQfBPqWP-- From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 20:04:36 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC7D0106568B for ; Mon, 21 Sep 2009 20:04:36 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [87.251.61.211]) by mx1.freebsd.org (Postfix) with ESMTP id 821898FC16 for ; Mon, 21 Sep 2009 20:04:36 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 7047B1D18D; Mon, 21 Sep 2009 21:59:20 +0200 (CEST) Date: Mon, 21 Sep 2009 21:59:20 +0200 From: Ed Schouten To: Pierre-Luc Drouin Message-ID: <20090921195920.GE95398@hoeg.nl> References: <4AB6DA79.7050209@pldrouin.net> <200909211827.53014.hselasky@c2i.net> <20090921194933.GB95398@hoeg.nl> <4AB7DA4B.8050105@pldrouin.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mr6Y9adkPWMVljTv" Content-Disposition: inline In-Reply-To: <4AB7DA4B.8050105@pldrouin.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 20:04:36 -0000 --mr6Y9adkPWMVljTv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Pierre-Luc, * Pierre-Luc Drouin wrote: > Here is what I get from pstat when I run my executable: >=20 > while ( 1 ) > while? pstat -t ttyU0 | grep ttyU0 > while? sleep 1 > while? end > LINE INQ CAN LIN LOW OUTQ USE LOW COL SESS PGID STATE > ttyU0 0 0 0 0 0 0 0 4 0 0 ICl > ttyU0 1920 0 0 192 1984 0 199 6 0 0 ICOil That all makes sense. Just let me know what it looks like when things go sour. If it still displays the above mentioned lines, then I suspect it to be a more complex problem... --=20 Ed Schouten WWW: http://80386.nl/ --mr6Y9adkPWMVljTv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkq32xgACgkQ52SDGA2eCwW4VACbB4Xjcj8PyQxvief9RnXFKv8C EosAoIECbkFCFI0swSd79u1H6E3D8C5N =88jo -----END PGP SIGNATURE----- --mr6Y9adkPWMVljTv-- From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 20:09:14 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B953106566B for ; Mon, 21 Sep 2009 20:09:14 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [87.251.61.211]) by mx1.freebsd.org (Postfix) with ESMTP id 02B238FC08 for ; Mon, 21 Sep 2009 20:09:13 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 62F2A1D0D6; Mon, 21 Sep 2009 21:49:33 +0200 (CEST) Date: Mon, 21 Sep 2009 21:49:33 +0200 From: Ed Schouten To: Hans Petter Selasky Message-ID: <20090921194933.GB95398@hoeg.nl> References: <4AB6DA79.7050209@pldrouin.net> <200909211827.53014.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2zue9K3IhLF/3KAd" Content-Disposition: inline In-Reply-To: <200909211827.53014.hselasky@c2i.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 20:09:14 -0000 --2zue9K3IhLF/3KAd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Pierre-Luc, Hans, * Hans Petter Selasky wrote: > You need to set raw mode for the TTY device I think. Maybe Ed can give yo= u the=20 > function name you need to call to do that? Yes. You need cfmakeraw() to do that (or do everything yourself). See src/lib/libc/gen/termios.c to see what it does. So what I'm interested in, is the following: "even that device is answering requests slower and slower until it stalls completely within 1 hour" Could you run `pstat -t' to see what's going on when it stalls? This nifty tool just gives some random statistics on TTYs. Very useful to see what's going on. Where data is stuck, etc. etc. --=20 Ed Schouten WWW: http://80386.nl/ --2zue9K3IhLF/3KAd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkq32M0ACgkQ52SDGA2eCwUbJQCbBC0jZTf2LS9jbO5ITvDqR4ds m5sAn0HJnlFnL4YJNpGtzTjlvXAjAI4/ =2P0a -----END PGP SIGNATURE----- --2zue9K3IhLF/3KAd-- From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 20:09:14 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A7A31065670 for ; Mon, 21 Sep 2009 20:09:14 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [87.251.61.211]) by mx1.freebsd.org (Postfix) with ESMTP id 1046F8FC0C for ; Mon, 21 Sep 2009 20:09:14 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 969FA1D178; Mon, 21 Sep 2009 21:50:32 +0200 (CEST) Date: Mon, 21 Sep 2009 21:50:32 +0200 From: Ed Schouten To: Pierre-Luc Drouin Message-ID: <20090921195032.GC95398@hoeg.nl> References: <4AB6DA79.7050209@pldrouin.net> <200909211827.53014.hselasky@c2i.net> <20090921194342.GA95398@hoeg.nl> <4AB7D8A3.3070809@pldrouin.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X8oaj2qX3NXXvcHN" Content-Disposition: inline In-Reply-To: <4AB7D8A3.3070809@pldrouin.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 20:09:14 -0000 --X8oaj2qX3NXXvcHN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Pierre-Luc Drouin wrote: > In my case I cvsuped the sources on September 14th. I can cvsup them > again and make buildworld with the latest sources if necessary. Oh wait. Misread. It's already late. MPSAFE TTY got committed on August 19 2008, not 2009. --=20 Ed Schouten WWW: http://80386.nl/ --X8oaj2qX3NXXvcHN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkq32QgACgkQ52SDGA2eCwUruACfdWaQEOlioZ0kM7koAoSaE2sY EWQAnjOix4JU5u/+T507RmRyprGgglId =fIee -----END PGP SIGNATURE----- --X8oaj2qX3NXXvcHN-- From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 20:10:02 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8FBE1065679 for ; Mon, 21 Sep 2009 20:10:02 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id C081E8FC20 for ; Mon, 21 Sep 2009 20:10:02 +0000 (UTC) Received: from mdaemon.pldrouin.net (pldrouinlap2-pc.physics.carleton.ca [134.117.23.34]) by smtp.cyberfingers.net (Postfix) with ESMTP id 811A8AB6C24; Mon, 21 Sep 2009 16:07:12 -0400 (EDT) Message-ID: <4AB7DD9B.8070707@pldrouin.net> Date: Mon, 21 Sep 2009 16:10:03 -0400 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: Ed Schouten References: <4AB6DA79.7050209@pldrouin.net> <200909211827.53014.hselasky@c2i.net> <20090921194933.GB95398@hoeg.nl> <4AB7DA4B.8050105@pldrouin.net> <20090921195920.GE95398@hoeg.nl> In-Reply-To: <20090921195920.GE95398@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 20:10:03 -0000 Ed Schouten wrote: > Hello Pierre-Luc, > > * Pierre-Luc Drouin wrote: > >> Here is what I get from pstat when I run my executable: >> >> while ( 1 ) >> while? pstat -t ttyU0 | grep ttyU0 >> while? sleep 1 >> while? end >> LINE INQ CAN LIN LOW OUTQ USE LOW COL SESS PGID STATE >> ttyU0 0 0 0 0 0 0 0 4 0 0 ICl >> > > >> ttyU0 1920 0 0 192 1984 0 199 6 0 0 ICOil >> > > That all makes sense. Just let me know what it looks like when things go > sour. If it still displays the above mentioned lines, then I suspect it > to be a more complex problem... > > Well in my case (not to be confused with the starter of this thread), I simply cannot read any data. It hangs forever at the first read statement on FreeBSD in synchronous mode, or I get EINTR if I try reading in ASYNC mode after SIGIO is sent, independently of the number of bytes I try reading. All these tests run smoothly on Linux. Pierre-Luc Drouin From owner-freebsd-usb@FreeBSD.ORG Mon Sep 21 22:38:47 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6EB9106566B for ; Mon, 21 Sep 2009 22:38:47 +0000 (UTC) (envelope-from tlb@tlb.org) Received: from anybots.com (mail.anybots.com [64.142.12.96]) by mx1.freebsd.org (Postfix) with SMTP id B23AE8FC14 for ; Mon, 21 Sep 2009 22:38:47 +0000 (UTC) Received: (qmail 51216 invoked from network); 21 Sep 2009 22:38:47 -0000 Received: from unknown (HELO ?10.10.10.66?) (10.10.10.66) by 10.10.10.20 with SMTP; 21 Sep 2009 22:38:47 -0000 Message-Id: <2C0D6269-1296-4D34-8029-828A0FE281CB@tlb.org> From: Trevor Blackwell To: freebsd-usb@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 21 Sep 2009 15:38:46 -0700 X-Mailer: Apple Mail (2.935.3) Subject: libusb20 api X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 22:38:48 -0000 This always fails: char devname[256]; if (libusb20_dev_get_iface_desc(pdev, n, devname, sizeof(devname))) break; while this works: char devname[128]; if (libusb20_dev_get_iface_desc(pdev, n, devname, sizeof(devname))) break; Because this function takes a uint8_t for length: : static int ugen20_dev_get_iface_desc(struct libusb20_device *pdev, uint8_t iface_index, char *buf, uint8_t len) even though the kernel ioctl structure has a 16-bit length. Hans, why not just use size_t for such arguments? -- Trevor Blackwell 650 776 7870 tlb@tlb.org From owner-freebsd-usb@FreeBSD.ORG Tue Sep 22 07:16:15 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 755F91065695 for ; Tue, 22 Sep 2009 07:16:15 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.tele2.se [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 971F88FC1D for ; Tue, 22 Sep 2009 07:16:14 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=6U-Pe18MTAwA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=DYnwDPQg9WSBy7-Ou0YA:9 a=YKD6klEn2zUVrU1FUc4A:7 a=OkpX7u55Lb3TR7NgJrd0ZriAHxUA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1135247661; Tue, 22 Sep 2009 09:16:08 +0200 From: Hans Petter Selasky To: "Pierre-Luc Drouin" Date: Tue, 22 Sep 2009 09:16:44 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <4AB6DA79.7050209@pldrouin.net> <200909212045.20657.hselasky@c2i.net> <4AB7CCE0.2000703@pldrouin.net> In-Reply-To: <4AB7CCE0.2000703@pldrouin.net> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909220916.46186.hselasky@c2i.net> Cc: ed@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 07:16:15 -0000 On Monday 21 September 2009 20:58:40 Pierre-Luc Drouin wrote: > Hans Petter Selasky wrote: > > On Monday 21 September 2009 20:28:58 Pierre-Luc Drouin wrote: > >> Hans Petter Selasky wrote: > >>> On Monday 21 September 2009 19:52:13 Pierre-Luc Drouin wrote: > >>>> Hans Petter Selasky wrote: > >>>>> On Monday 21 September 2009 19:29:10 Pierre-Luc Drouin wrote: > >>>>>> Hans Petter Selasky wrote: > >>>>>>> On Monday 21 September 2009 03:44:25 Pierre-Luc Drouin wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I am also having troubles with the uftdi driver on 8.0-BETA4. > >>>>>>>> I am trying to use a fan controller (mCubed bigNG) that uses a > >>>>>>>> FT232BL chip and it does not seem to be responding on FreeBSD 8.0 > >>>>>>>> while the same code works perfectly on Linux (I have not tried the > >>>>>>>> code on RELENG_7 yet but I could install it if necessary). > >>>>>>>> > >>>>>>>> Here is the very simple code I am using for testing: > >>>>>>>> #include > >>>>>>>> #include > >>>>>>>> #include > >>>>>>>> #include > >>>>>>>> #include > >>>>>>>> > >>>>>>>> int main(); > >>>>>>>> > >>>>>>>> #define DEV "/dev/ttyU0" > >>>>>>>> > >>>>>>>> #define TBAN_SER_SOURCE1 0x05 /* Primary source */ > >>>>>>>> #define TBAN_SER_SOURCE2 0x06 /* Alternative source > >>>>>>>> (miniNG...) */ > >>>>>>>> > >>>>>>>> #define TBAN_SER_REQUEST 0x36 > >>>>>>>> > >>>>>>>> int main() > >>>>>>>> { > >>>>>>>> int fd; > >>>>>>>> int result; > >>>>>>>> struct termios oldtio, newtio; > >>>>>>>> unsigned char buf[285]; > >>>>>>>> > >>>>>>>> printf("Opening device\n"); > >>>>>>>> fd=open(DEV, O_RDWR | O_NOCTTY); > >>>>>>>> > >>>>>>>> if(fd<0) { > >>>>>>>> perror(DEV); > >>>>>>>> return 1; > >>>>>>>> } > >>>>>>>> > >>>>>>>> result=tcgetattr(fd,&oldtio); > >>>>>>>> if(result<0) { > >>>>>>>> perror("tcgetattr"); > >>>>>>>> return 1; > >>>>>>>> } > >>>>>>>> > >>>>>>>> memcpy(&newtio,&oldtio,sizeof(struct termios)); > >>>>>>>> newtio.c_cflag = B19200 > >>>>>>>> > >>>>>>>> | CRTSCTS > >>>>>>>> | CS8 > >>>>>>>> | CREAD; > >>>>>>>> > >>>>>>>> newtio.c_iflag = IGNPAR; > >>>>>>>> newtio.c_oflag = 0; > >>>>>>>> newtio.c_lflag = 0; > >>>>>>>> newtio.c_cc[VMIN] = 1; > >>>>>>>> newtio.c_cc[VTIME] = 0; > >>>>>>>> > >>>>>>>> result=tcflush(fd, TCIFLUSH); > >>>>>>>> if(result<0) { > >>>>>>>> perror("tcflush"); > >>>>>>>> return 1; > >>>>>>>> } > >>>>>>>> > >>>>>>>> result=tcsetattr(fd,TCSANOW,&newtio); > >>>>>>>> if(result<0) { > >>>>>>>> perror("tcsetattr"); > >>>>>>>> return 1; > >>>>>>>> } > >>>>>>>> > >>>>>>>> sleep(1); > >>>>>>>> > >>>>>>>> printf("Performing initial query\n"); > >>>>>>>> buf[0]=TBAN_SER_SOURCE1; > >>>>>>>> buf[1]=TBAN_SER_REQUEST; > >>>>>>>> > >>>>>>>> printf("Requesting status\n"); > >>>>>>>> result=write(fd,buf,2); > >>>>>>>> if(result<0) { > >>>>>>>> perror("write"); > >>>>>>>> return 1; > >>>>>>>> } > >>>>>>>> > >>>>>>>> sleep(1); > >>>>>>>> > >>>>>>>> printf("Reading status\n"); > >>>>>>>> result=read(fd,buf,32); > >>>>>>>> if(result<0) { > >>>>>>>> perror("read"); > >>>>>>>> return 1; > >>>>>>>> } > >>>>>>>> > >>>>>>>> result=tcsetattr(fd,TCSANOW,&oldtio); > >>>>>>>> if(result<0) { > >>>>>>>> perror("tcsetattr"); > >>>>>>>> return 1; > >>>>>>>> } > >>>>>>>> > >>>>>>>> result=close(fd); > >>>>>>>> if(result<0) { > >>>>>>>> perror("close"); > >>>>>>>> return 1; > >>>>>>>> } > >>>>>>>> return 0; > >>>>>>>> } > >>>>>>>> > >>>>>>>> It hangs while reading independently of the number of bits I am > >>>>>>>> reading. > >>>>>>>> > >>>>>>>> Here is the output from dmesg when I load the uftdi module: > >>>>>>>> Sep 20 21:31:31 ldaemon kernel: uftdi0: on usbus6 > >>>>>>>> Sep 20 21:31:31 ldaemon kernel: ucom_attach_tty:317: tp = > >>>>>>>> 0xffffff001f12b400, unit = 0 Sep 20 21:31:31 ldaemon kernel: > >>>>>>>> ucom_attach_tty:346: ttycreate: U0 Sep 20 21:31:34 ldaemon root: > >>>>>>>> Unknown USB device: vendor 0x051d product 0x0002 bus uhub0 > >>>>>>>> > >>>>>>>> Here is the output in /var/log/messages when I enable the debug > >>>>>>>> output for ucom and uftdi: Sep 20 21:33:30 ldaemon kernel: > >>>>>>>> ucom_open:554: tp = 0xffffff001f12b400 Sep 20 21:33:30 ldaemon > >>>>>>>> kernel: ucom_dtr:827: onoff = 1 Sep 20 21:33:30 ldaemon kernel: > >>>>>>>> ucom_line_state:799: on=0x01, off=0x00 Sep 20 21:33:30 ldaemon > >>>>>>>> kernel: ucom_rts:838: onoff = 1 > >>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, > >>>>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_break:816: onoff = 0 > >>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x00, > >>>>>>>> off=0x04 Sep 20 21:33:30 ldaemon kernel: ucom_status_change:901: > >>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = > >>>>>>>> 0xffffff001f12ac58 Sep 20 21:33:30 ldaemon kernel: > >>>>>>>> uftdi_pre_param:653: > >>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = 1 > >>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, > >>>>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 > >>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, > >>>>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_cfg_open:520: > >>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_open:354: > >>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_read_callback:459: status > >>>>>>>> change msr=0xf0 (0x00) lsr=0x60 (0x00) Sep 20 21:33:30 ldaemon > >>>>>>>> kernel: ucom_status_change:901: > >>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 > >>>>>>>> lsr=0x60 Sep 20 21:33:30 ldaemon kernel: > >>>>>>>> ucom_cfg_status_change:887: DCD changed to 1 Sep 20 21:33:30 > >>>>>>>> ldaemon kernel: > >>>>>>>> uftdi_cfg_param:672: Sep 20 21:33:30 ldaemon kernel: > >>>>>>>> ucom_ioctl:653: cmd = 0x402c7413 Sep 20 21:33:30 ldaemon kernel: > >>>>>>>> ucom_ioctl:653: cmd = 0x80047410 Sep 20 21:33:30 ldaemon kernel: > >>>>>>>> ucom_ioctl:653: cmd = 0x802c7414 Sep 20 21:33:30 ldaemon kernel: > >>>>>>>> ucom_param:950: sc = 0xffffff001f12ac58 Sep 20 21:33:30 ldaemon > >>>>>>>> kernel: > >>>>>>>> uftdi_pre_param:653: > >>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 > >>>>>>>> lsr=0x60 Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: > >>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_get_data:1064: cnt=0 > >>>>>>>> Sep 20 21:33:31 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > >>>>>>>> Sep 20 21:33:32 ldaemon kernel: ucom_outwakeup:1009: sc = > >>>>>>>> 0xffffff001f12ac58 Sep 20 21:33:32 ldaemon kernel: > >>>>>>>> ucom_get_data:1064: cnt=2 > >>>>>>>> Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: cnt=0 > >>>>>>>> > >>>>>>>> I really need to get this working so I am ready to test things as > >>>>>>>> much as I can... > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> You need to set raw mode for the TTY device I think. Maybe Ed can > >>>>>>> give you the function name you need to call to do that? > >>>>>>> > >>>>>>> --HPS > >>>>>> > >>>>>> Do I need to do something like that? > >>>>>> ioctl(fileno(stdin), TIOCGETP, &tty_org); > >>>>>> tty = tty_org; > >>>>>> > >>>>>> /* set terminal to raw mode ... */ > >>>>>> tty.sg_flags |= CRMOD; > >>>>>> tty.sg_flags &= ~ECHO; > >>>>>> tty.sg_flags &= ~XTABS; > >>>>>> tty.sg_flags |= RAW; > >>>>>> > >>>>>> Thanks! > >>>>>> Pierre-Luc Drouin > >>>>> > >>>>> Hi, > >>>>> > >>>>> You need to call this function: > >>>>> > >>>>> void > >>>>> cfmakeraw(struct termios *t); > >>>>> > >>>>> --HPS > >>>> > >>>> Hi, > >>>> > >>>> it still does not work. I have added the line > >>>> cfmakeraw(&newtio); > >>>> > >>>> just before the call to tcflush and I get the following output in > >>>> /var/log/messages: > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_open:554: tp = 0xffffff001f12b400 > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: onoff = 1 > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_break:816: onoff = 0 > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_status_change:901: > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = > >>>> 0xffffff001f12ac58 Sep 21 13:38:46 ldaemon kernel: > >>>> uftdi_pre_param:653: > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: onoff = 1 > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_cfg_open:520: > >>>> Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_open:354: > >>>> uftdi_cfg_get_status:705: msr=0xf0 lsr=0x60 > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_cfg_status_change:887: DCD > >>>> changed to 1 Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = > >>>> 0xffffff001f12ac58 Sep 21 13:38:46 ldaemon kernel: > >>>> uftdi_pre_param:653: > >>>> Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: > >>>> Sep 21 13:38:46 ldaemon kernel: ucom_get_data:1064: cnt=0 > >>>> Sep 21 13:38:47 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > >>>> Sep 21 13:38:48 ldaemon kernel: ucom_outwakeup:1009: sc = > >>>> 0xffffff001f12ac58 Sep 21 13:38:48 ldaemon kernel: ucom_get_data:1064: > >>>> cnt=2 > >>>> Sep 21 13:38:48 ldaemon kernel: ucom_get_data:1064: cnt=0 > >>> > >>> Can you try adding a delay after setting the baud rate? > >>> > >>> --HPS > >> > >> The code already sleeps for 1 second after I applying the baud rate (via > >> tcsetattr(fd,TCSANOW,&newtio)). I am not sure to understand what you > >> mean... > > > > Hi, > > > > I mean try adding some: > > > > usleep(1000000); > > > > To your code to see if that changes anything. > > > > Also try reading one byte instead of 32. > > > > Last, try adding a printout to: > > > > src/sys/dev/usb/serial/uftdi.c > > > > uftdi_read_callback() > > > > and printout the actlen variable. > > > > --HPS > > ok, so I added the usleep statement right after the existing sleep > statement. I also tried reading a single byte. It did not make any > difference... I added a print statement to print the value of actlen > right after it is set via > usbd_xfer_status(xfer, &actlen, NULL, NULL, NULL); > > Here is the new output in /var/log/messages: > Sep 21 14:55:28 ldaemon kernel: ucom_open:554: tp = 0xffffff0139488800 > Sep 21 14:55:28 ldaemon kernel: ucom_dtr:827: onoff = 1 > Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 > Sep 21 14:55:28 ldaemon kernel: ucom_rts:838: onoff = 1 > Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 > Sep 21 14:55:28 ldaemon kernel: ucom_break:816: onoff = 0 > Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 > Sep 21 14:55:28 ldaemon kernel: ucom_status_change:901: > Sep 21 14:55:28 ldaemon kernel: ucom_param:950: sc = 0xffffff013bcac458 > Sep 21 14:55:28 ldaemon kernel: ucom_dtr:827: onoff = 1 > Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 > Sep 21 14:55:28 ldaemon kernel: ucom_rts:838: onoff = 1 > Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 > Sep 21 14:55:28 ldaemon kernel: ucom_cfg_open:520: > Sep 21 14:55:28 ldaemon kernel: actlen is 0 > Sep 21 14:55:28 ldaemon kernel: actlen is 2 > Sep 21 14:55:28 ldaemon kernel: actlen is 2 > Sep 21 14:55:28 ldaemon kernel: ucom_cfg_status_change:887: DCD changed to > 1 Sep 21 14:55:28 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 > Sep 21 14:55:28 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > Sep 21 14:55:28 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 > Sep 21 14:55:28 ldaemon kernel: ucom_param:950: sc = 0xffffff013bcac458 > Sep 21 14:55:28 ldaemon kernel: actlen is 2 > Sep 21 14:55:28 ldaemon last message repeated 12 times > Sep 21 14:55:28 ldaemon kernel: ucom_get_data:1064: cnt=0 > Sep 21 14:55:28 ldaemon kernel: actlen is 2 > Sep 21 14:55:30 ldaemon last message repeated 111 times > Sep 21 14:55:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > Sep 21 14:55:30 ldaemon kernel: actlen is 2 > Sep 21 14:55:31 ldaemon last message repeated 62 times > Sep 21 14:55:31 ldaemon kernel: ucom_outwakeup:1009: sc = > 0xffffff013bcac458 Sep 21 14:55:31 ldaemon kernel: ucom_get_data:1064: > cnt=2 > Sep 21 14:55:31 ldaemon kernel: ucom_get_data:1064: cnt=0 > Sep 21 14:55:31 ldaemon kernel: actlen is 2 If actlen is 2 then no modem data is transferred from the device. --HPS From owner-freebsd-usb@FreeBSD.ORG Tue Sep 22 12:57:52 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC584106566C; Tue, 22 Sep 2009 12:57:52 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id 8CA488FC1C; Tue, 22 Sep 2009 12:57:52 +0000 (UTC) Received: from ldaemon.pldrouin.net (CPE0023695b905f-CM001a666aca96.cpe.net.cable.rogers.com [99.246.67.95]) by smtp.cyberfingers.net (Postfix) with ESMTP id 2BC09AB6C0F; Tue, 22 Sep 2009 08:55:01 -0400 (EDT) Message-ID: <4AB8C9CA.407@pldrouin.net> Date: Tue, 22 Sep 2009 08:57:46 -0400 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Hans Petter Selasky References: <4AB6DA79.7050209@pldrouin.net> <200909212045.20657.hselasky@c2i.net> <4AB7CCE0.2000703@pldrouin.net> <200909220916.46186.hselasky@c2i.net> In-Reply-To: <200909220916.46186.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ed@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 12:57:52 -0000 Hans Petter Selasky wrote: > On Monday 21 September 2009 20:58:40 Pierre-Luc Drouin wrote: > >> Hans Petter Selasky wrote: >> >>> On Monday 21 September 2009 20:28:58 Pierre-Luc Drouin wrote: >>> >>>> Hans Petter Selasky wrote: >>>> >>>>> On Monday 21 September 2009 19:52:13 Pierre-Luc Drouin wrote: >>>>> >>>>>> Hans Petter Selasky wrote: >>>>>> >>>>>>> On Monday 21 September 2009 19:29:10 Pierre-Luc Drouin wrote: >>>>>>> >>>>>>>> Hans Petter Selasky wrote: >>>>>>>> >>>>>>>>> On Monday 21 September 2009 03:44:25 Pierre-Luc Drouin wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I am also having troubles with the uftdi driver on 8.0-BETA4. >>>>>>>>>> I am trying to use a fan controller (mCubed bigNG) that uses a >>>>>>>>>> FT232BL chip and it does not seem to be responding on FreeBSD 8.0 >>>>>>>>>> while the same code works perfectly on Linux (I have not tried the >>>>>>>>>> code on RELENG_7 yet but I could install it if necessary). >>>>>>>>>> >>>>>>>>>> Here is the very simple code I am using for testing: >>>>>>>>>> #include >>>>>>>>>> #include >>>>>>>>>> #include >>>>>>>>>> #include >>>>>>>>>> #include >>>>>>>>>> >>>>>>>>>> int main(); >>>>>>>>>> >>>>>>>>>> #define DEV "/dev/ttyU0" >>>>>>>>>> >>>>>>>>>> #define TBAN_SER_SOURCE1 0x05 /* Primary source */ >>>>>>>>>> #define TBAN_SER_SOURCE2 0x06 /* Alternative source >>>>>>>>>> (miniNG...) */ >>>>>>>>>> >>>>>>>>>> #define TBAN_SER_REQUEST 0x36 >>>>>>>>>> >>>>>>>>>> int main() >>>>>>>>>> { >>>>>>>>>> int fd; >>>>>>>>>> int result; >>>>>>>>>> struct termios oldtio, newtio; >>>>>>>>>> unsigned char buf[285]; >>>>>>>>>> >>>>>>>>>> printf("Opening device\n"); >>>>>>>>>> fd=open(DEV, O_RDWR | O_NOCTTY); >>>>>>>>>> >>>>>>>>>> if(fd<0) { >>>>>>>>>> perror(DEV); >>>>>>>>>> return 1; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> result=tcgetattr(fd,&oldtio); >>>>>>>>>> if(result<0) { >>>>>>>>>> perror("tcgetattr"); >>>>>>>>>> return 1; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> memcpy(&newtio,&oldtio,sizeof(struct termios)); >>>>>>>>>> newtio.c_cflag = B19200 >>>>>>>>>> >>>>>>>>>> | CRTSCTS >>>>>>>>>> | CS8 >>>>>>>>>> | CREAD; >>>>>>>>>> >>>>>>>>>> newtio.c_iflag = IGNPAR; >>>>>>>>>> newtio.c_oflag = 0; >>>>>>>>>> newtio.c_lflag = 0; >>>>>>>>>> newtio.c_cc[VMIN] = 1; >>>>>>>>>> newtio.c_cc[VTIME] = 0; >>>>>>>>>> >>>>>>>>>> result=tcflush(fd, TCIFLUSH); >>>>>>>>>> if(result<0) { >>>>>>>>>> perror("tcflush"); >>>>>>>>>> return 1; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> result=tcsetattr(fd,TCSANOW,&newtio); >>>>>>>>>> if(result<0) { >>>>>>>>>> perror("tcsetattr"); >>>>>>>>>> return 1; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> sleep(1); >>>>>>>>>> >>>>>>>>>> printf("Performing initial query\n"); >>>>>>>>>> buf[0]=TBAN_SER_SOURCE1; >>>>>>>>>> buf[1]=TBAN_SER_REQUEST; >>>>>>>>>> >>>>>>>>>> printf("Requesting status\n"); >>>>>>>>>> result=write(fd,buf,2); >>>>>>>>>> if(result<0) { >>>>>>>>>> perror("write"); >>>>>>>>>> return 1; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> sleep(1); >>>>>>>>>> >>>>>>>>>> printf("Reading status\n"); >>>>>>>>>> result=read(fd,buf,32); >>>>>>>>>> if(result<0) { >>>>>>>>>> perror("read"); >>>>>>>>>> return 1; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> result=tcsetattr(fd,TCSANOW,&oldtio); >>>>>>>>>> if(result<0) { >>>>>>>>>> perror("tcsetattr"); >>>>>>>>>> return 1; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> result=close(fd); >>>>>>>>>> if(result<0) { >>>>>>>>>> perror("close"); >>>>>>>>>> return 1; >>>>>>>>>> } >>>>>>>>>> return 0; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> It hangs while reading independently of the number of bits I am >>>>>>>>>> reading. >>>>>>>>>> >>>>>>>>>> Here is the output from dmesg when I load the uftdi module: >>>>>>>>>> Sep 20 21:31:31 ldaemon kernel: uftdi0: on usbus6 >>>>>>>>>> Sep 20 21:31:31 ldaemon kernel: ucom_attach_tty:317: tp = >>>>>>>>>> 0xffffff001f12b400, unit = 0 Sep 20 21:31:31 ldaemon kernel: >>>>>>>>>> ucom_attach_tty:346: ttycreate: U0 Sep 20 21:31:34 ldaemon root: >>>>>>>>>> Unknown USB device: vendor 0x051d product 0x0002 bus uhub0 >>>>>>>>>> >>>>>>>>>> Here is the output in /var/log/messages when I enable the debug >>>>>>>>>> output for ucom and uftdi: Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>> ucom_open:554: tp = 0xffffff001f12b400 Sep 20 21:33:30 ldaemon >>>>>>>>>> kernel: ucom_dtr:827: onoff = 1 Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>> ucom_line_state:799: on=0x01, off=0x00 Sep 20 21:33:30 ldaemon >>>>>>>>>> kernel: ucom_rts:838: onoff = 1 >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, >>>>>>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_break:816: onoff = 0 >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x00, >>>>>>>>>> off=0x04 Sep 20 21:33:30 ldaemon kernel: ucom_status_change:901: >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = >>>>>>>>>> 0xffffff001f12ac58 Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>> uftdi_pre_param:653: >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = 1 >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, >>>>>>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, >>>>>>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_cfg_open:520: >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_open:354: >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_read_callback:459: status >>>>>>>>>> change msr=0xf0 (0x00) lsr=0x60 (0x00) Sep 20 21:33:30 ldaemon >>>>>>>>>> kernel: ucom_status_change:901: >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 >>>>>>>>>> lsr=0x60 Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>> ucom_cfg_status_change:887: DCD changed to 1 Sep 20 21:33:30 >>>>>>>>>> ldaemon kernel: >>>>>>>>>> uftdi_cfg_param:672: Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>> ucom_ioctl:653: cmd = 0x402c7413 Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>> ucom_ioctl:653: cmd = 0x80047410 Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>> ucom_ioctl:653: cmd = 0x802c7414 Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>> ucom_param:950: sc = 0xffffff001f12ac58 Sep 20 21:33:30 ldaemon >>>>>>>>>> kernel: >>>>>>>>>> uftdi_pre_param:653: >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: msr=0xf0 >>>>>>>>>> lsr=0x60 Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_param:672: >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_get_data:1064: cnt=0 >>>>>>>>>> Sep 20 21:33:31 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >>>>>>>>>> Sep 20 21:33:32 ldaemon kernel: ucom_outwakeup:1009: sc = >>>>>>>>>> 0xffffff001f12ac58 Sep 20 21:33:32 ldaemon kernel: >>>>>>>>>> ucom_get_data:1064: cnt=2 >>>>>>>>>> Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: cnt=0 >>>>>>>>>> >>>>>>>>>> I really need to get this working so I am ready to test things as >>>>>>>>>> much as I can... >>>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> You need to set raw mode for the TTY device I think. Maybe Ed can >>>>>>>>> give you the function name you need to call to do that? >>>>>>>>> >>>>>>>>> --HPS >>>>>>>>> >>>>>>>> Do I need to do something like that? >>>>>>>> ioctl(fileno(stdin), TIOCGETP, &tty_org); >>>>>>>> tty = tty_org; >>>>>>>> >>>>>>>> /* set terminal to raw mode ... */ >>>>>>>> tty.sg_flags |= CRMOD; >>>>>>>> tty.sg_flags &= ~ECHO; >>>>>>>> tty.sg_flags &= ~XTABS; >>>>>>>> tty.sg_flags |= RAW; >>>>>>>> >>>>>>>> Thanks! >>>>>>>> Pierre-Luc Drouin >>>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> You need to call this function: >>>>>>> >>>>>>> void >>>>>>> cfmakeraw(struct termios *t); >>>>>>> >>>>>>> --HPS >>>>>>> >>>>>> Hi, >>>>>> >>>>>> it still does not work. I have added the line >>>>>> cfmakeraw(&newtio); >>>>>> >>>>>> just before the call to tcflush and I get the following output in >>>>>> /var/log/messages: >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_open:554: tp = 0xffffff001f12b400 >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: onoff = 1 >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_break:816: onoff = 0 >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_status_change:901: >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = >>>>>> 0xffffff001f12ac58 Sep 21 13:38:46 ldaemon kernel: >>>>>> uftdi_pre_param:653: >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: onoff = 1 >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_cfg_open:520: >>>>>> Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_open:354: >>>>>> uftdi_cfg_get_status:705: msr=0xf0 lsr=0x60 >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_cfg_status_change:887: DCD >>>>>> changed to 1 Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = >>>>>> 0xffffff001f12ac58 Sep 21 13:38:46 ldaemon kernel: >>>>>> uftdi_pre_param:653: >>>>>> Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_get_data:1064: cnt=0 >>>>>> Sep 21 13:38:47 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >>>>>> Sep 21 13:38:48 ldaemon kernel: ucom_outwakeup:1009: sc = >>>>>> 0xffffff001f12ac58 Sep 21 13:38:48 ldaemon kernel: ucom_get_data:1064: >>>>>> cnt=2 >>>>>> Sep 21 13:38:48 ldaemon kernel: ucom_get_data:1064: cnt=0 >>>>>> >>>>> Can you try adding a delay after setting the baud rate? >>>>> >>>>> --HPS >>>>> >>>> The code already sleeps for 1 second after I applying the baud rate (via >>>> tcsetattr(fd,TCSANOW,&newtio)). I am not sure to understand what you >>>> mean... >>>> >>> Hi, >>> >>> I mean try adding some: >>> >>> usleep(1000000); >>> >>> To your code to see if that changes anything. >>> >>> Also try reading one byte instead of 32. >>> >>> Last, try adding a printout to: >>> >>> src/sys/dev/usb/serial/uftdi.c >>> >>> uftdi_read_callback() >>> >>> and printout the actlen variable. >>> >>> --HPS >>> >> ok, so I added the usleep statement right after the existing sleep >> statement. I also tried reading a single byte. It did not make any >> difference... I added a print statement to print the value of actlen >> right after it is set via >> usbd_xfer_status(xfer, &actlen, NULL, NULL, NULL); >> >> Here is the new output in /var/log/messages: >> Sep 21 14:55:28 ldaemon kernel: ucom_open:554: tp = 0xffffff0139488800 >> Sep 21 14:55:28 ldaemon kernel: ucom_dtr:827: onoff = 1 >> Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 >> Sep 21 14:55:28 ldaemon kernel: ucom_rts:838: onoff = 1 >> Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 >> Sep 21 14:55:28 ldaemon kernel: ucom_break:816: onoff = 0 >> Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 >> Sep 21 14:55:28 ldaemon kernel: ucom_status_change:901: >> Sep 21 14:55:28 ldaemon kernel: ucom_param:950: sc = 0xffffff013bcac458 >> Sep 21 14:55:28 ldaemon kernel: ucom_dtr:827: onoff = 1 >> Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 >> Sep 21 14:55:28 ldaemon kernel: ucom_rts:838: onoff = 1 >> Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 >> Sep 21 14:55:28 ldaemon kernel: ucom_cfg_open:520: >> Sep 21 14:55:28 ldaemon kernel: actlen is 0 >> Sep 21 14:55:28 ldaemon kernel: actlen is 2 >> Sep 21 14:55:28 ldaemon kernel: actlen is 2 >> Sep 21 14:55:28 ldaemon kernel: ucom_cfg_status_change:887: DCD changed to >> 1 Sep 21 14:55:28 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 >> Sep 21 14:55:28 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >> Sep 21 14:55:28 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 >> Sep 21 14:55:28 ldaemon kernel: ucom_param:950: sc = 0xffffff013bcac458 >> Sep 21 14:55:28 ldaemon kernel: actlen is 2 >> Sep 21 14:55:28 ldaemon last message repeated 12 times >> Sep 21 14:55:28 ldaemon kernel: ucom_get_data:1064: cnt=0 >> Sep 21 14:55:28 ldaemon kernel: actlen is 2 >> Sep 21 14:55:30 ldaemon last message repeated 111 times >> Sep 21 14:55:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >> Sep 21 14:55:30 ldaemon kernel: actlen is 2 >> Sep 21 14:55:31 ldaemon last message repeated 62 times >> Sep 21 14:55:31 ldaemon kernel: ucom_outwakeup:1009: sc = >> 0xffffff013bcac458 Sep 21 14:55:31 ldaemon kernel: ucom_get_data:1064: >> cnt=2 >> Sep 21 14:55:31 ldaemon kernel: ucom_get_data:1064: cnt=0 >> Sep 21 14:55:31 ldaemon kernel: actlen is 2 >> > > If actlen is 2 then no modem data is transferred from the device. > > --HPS > Hmm, so does it indicate a bug in uftdi? In asynchronous mode, SIGIO is generated but when try reading I get error EINTR... Thanks! From owner-freebsd-usb@FreeBSD.ORG Tue Sep 22 14:38:14 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FD75106568B; Tue, 22 Sep 2009 14:38:14 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.tele2.se [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id 418568FC18; Tue, 22 Sep 2009 14:38:12 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=6U-Pe18MTAwA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=URg1EGsdCo64yniQHhcA:9 a=luPe3I6dKCg5W3J52IQA:7 a=n4RtH8b3OKC2HeOVnC93Cz46k-wA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe13.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 921957086; Tue, 22 Sep 2009 16:38:09 +0200 From: Hans Petter Selasky To: "Pierre-Luc Drouin" Date: Tue, 22 Sep 2009 16:38:46 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <4AB6DA79.7050209@pldrouin.net> <200909220916.46186.hselasky@c2i.net> <4AB8C9CA.407@pldrouin.net> In-Reply-To: <4AB8C9CA.407@pldrouin.net> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909221638.47642.hselasky@c2i.net> Cc: ed@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 14:38:14 -0000 On Tuesday 22 September 2009 14:57:46 Pierre-Luc Drouin wrote: > Hans Petter Selasky wrote: > > On Monday 21 September 2009 20:58:40 Pierre-Luc Drouin wrote: > >> Hans Petter Selasky wrote: > >>> On Monday 21 September 2009 20:28:58 Pierre-Luc Drouin wrote: > >>>> Hans Petter Selasky wrote: > >>>>> On Monday 21 September 2009 19:52:13 Pierre-Luc Drouin wrote: > >>>>>> Hans Petter Selasky wrote: > >>>>>>> On Monday 21 September 2009 19:29:10 Pierre-Luc Drouin wrote: > >>>>>>>> Hans Petter Selasky wrote: > >>>>>>>>> On Monday 21 September 2009 03:44:25 Pierre-Luc Drouin wrote: > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> I am also having troubles with the uftdi driver on 8.0-BETA4. > >>>>>>>>>> I am trying to use a fan controller (mCubed bigNG) that uses a > >>>>>>>>>> FT232BL chip and it does not seem to be responding on FreeBSD > >>>>>>>>>> 8.0 while the same code works perfectly on Linux (I have not > >>>>>>>>>> tried the code on RELENG_7 yet but I could install it if > >>>>>>>>>> necessary). > >>>>>>>>>> > >>>>>>>>>> Here is the very simple code I am using for testing: > >>>>>>>>>> #include > >>>>>>>>>> #include > >>>>>>>>>> #include > >>>>>>>>>> #include > >>>>>>>>>> #include > >>>>>>>>>> > >>>>>>>>>> int main(); > >>>>>>>>>> > >>>>>>>>>> #define DEV "/dev/ttyU0" > >>>>>>>>>> > >>>>>>>>>> #define TBAN_SER_SOURCE1 0x05 /* Primary source */ > >>>>>>>>>> #define TBAN_SER_SOURCE2 0x06 /* Alternative source > >>>>>>>>>> (miniNG...) */ > >>>>>>>>>> > >>>>>>>>>> #define TBAN_SER_REQUEST 0x36 > >>>>>>>>>> > >>>>>>>>>> int main() > >>>>>>>>>> { > >>>>>>>>>> int fd; > >>>>>>>>>> int result; > >>>>>>>>>> struct termios oldtio, newtio; > >>>>>>>>>> unsigned char buf[285]; > >>>>>>>>>> > >>>>>>>>>> printf("Opening device\n"); > >>>>>>>>>> fd=open(DEV, O_RDWR | O_NOCTTY); > >>>>>>>>>> > >>>>>>>>>> if(fd<0) { > >>>>>>>>>> perror(DEV); > >>>>>>>>>> return 1; > >>>>>>>>>> } > >>>>>>>>>> > >>>>>>>>>> result=tcgetattr(fd,&oldtio); > >>>>>>>>>> if(result<0) { > >>>>>>>>>> perror("tcgetattr"); > >>>>>>>>>> return 1; > >>>>>>>>>> } > >>>>>>>>>> > >>>>>>>>>> memcpy(&newtio,&oldtio,sizeof(struct termios)); > >>>>>>>>>> newtio.c_cflag = B19200 > >>>>>>>>>> > >>>>>>>>>> | CRTSCTS > >>>>>>>>>> | CS8 > >>>>>>>>>> | CREAD; > >>>>>>>>>> > >>>>>>>>>> newtio.c_iflag = IGNPAR; > >>>>>>>>>> newtio.c_oflag = 0; > >>>>>>>>>> newtio.c_lflag = 0; > >>>>>>>>>> newtio.c_cc[VMIN] = 1; > >>>>>>>>>> newtio.c_cc[VTIME] = 0; > >>>>>>>>>> > >>>>>>>>>> result=tcflush(fd, TCIFLUSH); > >>>>>>>>>> if(result<0) { > >>>>>>>>>> perror("tcflush"); > >>>>>>>>>> return 1; > >>>>>>>>>> } > >>>>>>>>>> > >>>>>>>>>> result=tcsetattr(fd,TCSANOW,&newtio); > >>>>>>>>>> if(result<0) { > >>>>>>>>>> perror("tcsetattr"); > >>>>>>>>>> return 1; > >>>>>>>>>> } > >>>>>>>>>> > >>>>>>>>>> sleep(1); > >>>>>>>>>> > >>>>>>>>>> printf("Performing initial query\n"); > >>>>>>>>>> buf[0]=TBAN_SER_SOURCE1; > >>>>>>>>>> buf[1]=TBAN_SER_REQUEST; > >>>>>>>>>> > >>>>>>>>>> printf("Requesting status\n"); > >>>>>>>>>> result=write(fd,buf,2); > >>>>>>>>>> if(result<0) { > >>>>>>>>>> perror("write"); > >>>>>>>>>> return 1; > >>>>>>>>>> } > >>>>>>>>>> > >>>>>>>>>> sleep(1); > >>>>>>>>>> > >>>>>>>>>> printf("Reading status\n"); > >>>>>>>>>> result=read(fd,buf,32); > >>>>>>>>>> if(result<0) { > >>>>>>>>>> perror("read"); > >>>>>>>>>> return 1; > >>>>>>>>>> } > >>>>>>>>>> > >>>>>>>>>> result=tcsetattr(fd,TCSANOW,&oldtio); > >>>>>>>>>> if(result<0) { > >>>>>>>>>> perror("tcsetattr"); > >>>>>>>>>> return 1; > >>>>>>>>>> } > >>>>>>>>>> > >>>>>>>>>> result=close(fd); > >>>>>>>>>> if(result<0) { > >>>>>>>>>> perror("close"); > >>>>>>>>>> return 1; > >>>>>>>>>> } > >>>>>>>>>> return 0; > >>>>>>>>>> } > >>>>>>>>>> > >>>>>>>>>> It hangs while reading independently of the number of bits I am > >>>>>>>>>> reading. > >>>>>>>>>> > >>>>>>>>>> Here is the output from dmesg when I load the uftdi module: > >>>>>>>>>> Sep 20 21:31:31 ldaemon kernel: uftdi0: on usbus6 > >>>>>>>>>> Sep 20 21:31:31 ldaemon kernel: ucom_attach_tty:317: tp = > >>>>>>>>>> 0xffffff001f12b400, unit = 0 Sep 20 21:31:31 ldaemon kernel: > >>>>>>>>>> ucom_attach_tty:346: ttycreate: U0 Sep 20 21:31:34 ldaemon root: > >>>>>>>>>> Unknown USB device: vendor 0x051d product 0x0002 bus uhub0 > >>>>>>>>>> > >>>>>>>>>> Here is the output in /var/log/messages when I enable the debug > >>>>>>>>>> output for ucom and uftdi: Sep 20 21:33:30 ldaemon kernel: > >>>>>>>>>> ucom_open:554: tp = 0xffffff001f12b400 Sep 20 21:33:30 ldaemon > >>>>>>>>>> kernel: ucom_dtr:827: onoff = 1 Sep 20 21:33:30 ldaemon kernel: > >>>>>>>>>> ucom_line_state:799: on=0x01, off=0x00 Sep 20 21:33:30 ldaemon > >>>>>>>>>> kernel: ucom_rts:838: onoff = 1 > >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, > >>>>>>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_break:816: onoff = > >>>>>>>>>> 0 Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x00, > >>>>>>>>>> off=0x04 Sep 20 21:33:30 ldaemon kernel: ucom_status_change:901: > >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = > >>>>>>>>>> 0xffffff001f12ac58 Sep 20 21:33:30 ldaemon kernel: > >>>>>>>>>> uftdi_pre_param:653: > >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = 1 > >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, > >>>>>>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 > >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, > >>>>>>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_cfg_open:520: > >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_open:354: > >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_read_callback:459: status > >>>>>>>>>> change msr=0xf0 (0x00) lsr=0x60 (0x00) Sep 20 21:33:30 ldaemon > >>>>>>>>>> kernel: ucom_status_change:901: > >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: > >>>>>>>>>> msr=0xf0 lsr=0x60 Sep 20 21:33:30 ldaemon kernel: > >>>>>>>>>> ucom_cfg_status_change:887: DCD changed to 1 Sep 20 21:33:30 > >>>>>>>>>> ldaemon kernel: > >>>>>>>>>> uftdi_cfg_param:672: Sep 20 21:33:30 ldaemon kernel: > >>>>>>>>>> ucom_ioctl:653: cmd = 0x402c7413 Sep 20 21:33:30 ldaemon kernel: > >>>>>>>>>> ucom_ioctl:653: cmd = 0x80047410 Sep 20 21:33:30 ldaemon kernel: > >>>>>>>>>> ucom_ioctl:653: cmd = 0x802c7414 Sep 20 21:33:30 ldaemon kernel: > >>>>>>>>>> ucom_param:950: sc = 0xffffff001f12ac58 Sep 20 21:33:30 ldaemon > >>>>>>>>>> kernel: > >>>>>>>>>> uftdi_pre_param:653: > >>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: > >>>>>>>>>> msr=0xf0 lsr=0x60 Sep 20 21:33:30 ldaemon kernel: > >>>>>>>>>> uftdi_cfg_param:672: Sep 20 21:33:30 ldaemon kernel: > >>>>>>>>>> ucom_get_data:1064: cnt=0 Sep 20 21:33:31 ldaemon kernel: > >>>>>>>>>> ucom_ioctl:653: cmd = 0x80047410 Sep 20 21:33:32 ldaemon kernel: > >>>>>>>>>> ucom_outwakeup:1009: sc = 0xffffff001f12ac58 Sep 20 21:33:32 > >>>>>>>>>> ldaemon kernel: > >>>>>>>>>> ucom_get_data:1064: cnt=2 > >>>>>>>>>> Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: cnt=0 > >>>>>>>>>> > >>>>>>>>>> I really need to get this working so I am ready to test things > >>>>>>>>>> as much as I can... > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> You need to set raw mode for the TTY device I think. Maybe Ed can > >>>>>>>>> give you the function name you need to call to do that? > >>>>>>>>> > >>>>>>>>> --HPS > >>>>>>>> > >>>>>>>> Do I need to do something like that? > >>>>>>>> ioctl(fileno(stdin), TIOCGETP, &tty_org); > >>>>>>>> tty = tty_org; > >>>>>>>> > >>>>>>>> /* set terminal to raw mode ... */ > >>>>>>>> tty.sg_flags |= CRMOD; > >>>>>>>> tty.sg_flags &= ~ECHO; > >>>>>>>> tty.sg_flags &= ~XTABS; > >>>>>>>> tty.sg_flags |= RAW; > >>>>>>>> > >>>>>>>> Thanks! > >>>>>>>> Pierre-Luc Drouin > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> You need to call this function: > >>>>>>> > >>>>>>> void > >>>>>>> cfmakeraw(struct termios *t); > >>>>>>> > >>>>>>> --HPS > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> it still does not work. I have added the line > >>>>>> cfmakeraw(&newtio); > >>>>>> > >>>>>> just before the call to tcflush and I get the following output in > >>>>>> /var/log/messages: > >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_open:554: tp = > >>>>>> 0xffffff001f12b400 Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: > >>>>>> onoff = 1 > >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, > >>>>>> off=0x00 Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 > >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, > >>>>>> off=0x00 Sep 21 13:38:46 ldaemon kernel: ucom_break:816: onoff = 0 > >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x00, > >>>>>> off=0x04 Sep 21 13:38:46 ldaemon kernel: ucom_status_change:901: > >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = > >>>>>> 0xffffff001f12ac58 Sep 21 13:38:46 ldaemon kernel: > >>>>>> uftdi_pre_param:653: > >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: onoff = 1 > >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, > >>>>>> off=0x00 Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 > >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, > >>>>>> off=0x00 Sep 21 13:38:46 ldaemon kernel: ucom_cfg_open:520: > >>>>>> Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_open:354: > >>>>>> uftdi_cfg_get_status:705: msr=0xf0 lsr=0x60 > >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_cfg_status_change:887: DCD > >>>>>> changed to 1 Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: > >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 > >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 > >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = > >>>>>> 0xffffff001f12ac58 Sep 21 13:38:46 ldaemon kernel: > >>>>>> uftdi_pre_param:653: > >>>>>> Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: > >>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_get_data:1064: cnt=0 > >>>>>> Sep 21 13:38:47 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > >>>>>> Sep 21 13:38:48 ldaemon kernel: ucom_outwakeup:1009: sc = > >>>>>> 0xffffff001f12ac58 Sep 21 13:38:48 ldaemon kernel: > >>>>>> ucom_get_data:1064: cnt=2 > >>>>>> Sep 21 13:38:48 ldaemon kernel: ucom_get_data:1064: cnt=0 > >>>>> > >>>>> Can you try adding a delay after setting the baud rate? > >>>>> > >>>>> --HPS > >>>> > >>>> The code already sleeps for 1 second after I applying the baud rate > >>>> (via tcsetattr(fd,TCSANOW,&newtio)). I am not sure to understand what > >>>> you mean... > >>> > >>> Hi, > >>> > >>> I mean try adding some: > >>> > >>> usleep(1000000); > >>> > >>> To your code to see if that changes anything. > >>> > >>> Also try reading one byte instead of 32. > >>> > >>> Last, try adding a printout to: > >>> > >>> src/sys/dev/usb/serial/uftdi.c > >>> > >>> uftdi_read_callback() > >>> > >>> and printout the actlen variable. > >>> > >>> --HPS > >> > >> ok, so I added the usleep statement right after the existing sleep > >> statement. I also tried reading a single byte. It did not make any > >> difference... I added a print statement to print the value of actlen > >> right after it is set via > >> usbd_xfer_status(xfer, &actlen, NULL, NULL, NULL); > >> > >> Here is the new output in /var/log/messages: > >> Sep 21 14:55:28 ldaemon kernel: ucom_open:554: tp = 0xffffff0139488800 > >> Sep 21 14:55:28 ldaemon kernel: ucom_dtr:827: onoff = 1 > >> Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 > >> Sep 21 14:55:28 ldaemon kernel: ucom_rts:838: onoff = 1 > >> Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 > >> Sep 21 14:55:28 ldaemon kernel: ucom_break:816: onoff = 0 > >> Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 > >> Sep 21 14:55:28 ldaemon kernel: ucom_status_change:901: > >> Sep 21 14:55:28 ldaemon kernel: ucom_param:950: sc = 0xffffff013bcac458 > >> Sep 21 14:55:28 ldaemon kernel: ucom_dtr:827: onoff = 1 > >> Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 > >> Sep 21 14:55:28 ldaemon kernel: ucom_rts:838: onoff = 1 > >> Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 > >> Sep 21 14:55:28 ldaemon kernel: ucom_cfg_open:520: > >> Sep 21 14:55:28 ldaemon kernel: actlen is 0 > >> Sep 21 14:55:28 ldaemon kernel: actlen is 2 > >> Sep 21 14:55:28 ldaemon kernel: actlen is 2 > >> Sep 21 14:55:28 ldaemon kernel: ucom_cfg_status_change:887: DCD changed > >> to 1 Sep 21 14:55:28 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 > >> Sep 21 14:55:28 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 Sep 21 > >> 14:55:28 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 Sep 21 > >> 14:55:28 ldaemon kernel: ucom_param:950: sc = 0xffffff013bcac458 Sep 21 > >> 14:55:28 ldaemon kernel: actlen is 2 > >> Sep 21 14:55:28 ldaemon last message repeated 12 times > >> Sep 21 14:55:28 ldaemon kernel: ucom_get_data:1064: cnt=0 > >> Sep 21 14:55:28 ldaemon kernel: actlen is 2 > >> Sep 21 14:55:30 ldaemon last message repeated 111 times > >> Sep 21 14:55:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 > >> Sep 21 14:55:30 ldaemon kernel: actlen is 2 > >> Sep 21 14:55:31 ldaemon last message repeated 62 times > >> Sep 21 14:55:31 ldaemon kernel: ucom_outwakeup:1009: sc = > >> 0xffffff013bcac458 Sep 21 14:55:31 ldaemon kernel: ucom_get_data:1064: > >> cnt=2 > >> Sep 21 14:55:31 ldaemon kernel: ucom_get_data:1064: cnt=0 > >> Sep 21 14:55:31 ldaemon kernel: actlen is 2 > > > > If actlen is 2 then no modem data is transferred from the device. > > > > --HPS > > Hmm, so does it indicate a bug in uftdi? In asynchronous mode, SIGIO is > generated but when try reading I get error EINTR... > > Thanks! It indicates that your device is not sending any data. --HPS From owner-freebsd-usb@FreeBSD.ORG Tue Sep 22 15:21:30 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ED871065670; Tue, 22 Sep 2009 15:21:30 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id EFA868FC1D; Tue, 22 Sep 2009 15:21:29 +0000 (UTC) Received: from mdaemon.pldrouin.net (pldrouinlap2-pc.physics.carleton.ca [134.117.23.34]) by smtp.cyberfingers.net (Postfix) with ESMTP id 452F7AB6C1A; Tue, 22 Sep 2009 11:18:39 -0400 (EDT) Message-ID: <4AB8EB78.2020809@pldrouin.net> Date: Tue, 22 Sep 2009 11:21:28 -0400 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: Hans Petter Selasky References: <4AB6DA79.7050209@pldrouin.net> <200909220916.46186.hselasky@c2i.net> <4AB8C9CA.407@pldrouin.net> <200909221638.47642.hselasky@c2i.net> In-Reply-To: <200909221638.47642.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ed@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 15:21:30 -0000 Hans Petter Selasky wrote: > On Tuesday 22 September 2009 14:57:46 Pierre-Luc Drouin wrote: > >> Hans Petter Selasky wrote: >> >>> On Monday 21 September 2009 20:58:40 Pierre-Luc Drouin wrote: >>> >>>> Hans Petter Selasky wrote: >>>> >>>>> On Monday 21 September 2009 20:28:58 Pierre-Luc Drouin wrote: >>>>> >>>>>> Hans Petter Selasky wrote: >>>>>> >>>>>>> On Monday 21 September 2009 19:52:13 Pierre-Luc Drouin wrote: >>>>>>> >>>>>>>> Hans Petter Selasky wrote: >>>>>>>> >>>>>>>>> On Monday 21 September 2009 19:29:10 Pierre-Luc Drouin wrote: >>>>>>>>> >>>>>>>>>> Hans Petter Selasky wrote: >>>>>>>>>> >>>>>>>>>>> On Monday 21 September 2009 03:44:25 Pierre-Luc Drouin wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I am also having troubles with the uftdi driver on 8.0-BETA4. >>>>>>>>>>>> I am trying to use a fan controller (mCubed bigNG) that uses a >>>>>>>>>>>> FT232BL chip and it does not seem to be responding on FreeBSD >>>>>>>>>>>> 8.0 while the same code works perfectly on Linux (I have not >>>>>>>>>>>> tried the code on RELENG_7 yet but I could install it if >>>>>>>>>>>> necessary). >>>>>>>>>>>> >>>>>>>>>>>> Here is the very simple code I am using for testing: >>>>>>>>>>>> #include >>>>>>>>>>>> #include >>>>>>>>>>>> #include >>>>>>>>>>>> #include >>>>>>>>>>>> #include >>>>>>>>>>>> >>>>>>>>>>>> int main(); >>>>>>>>>>>> >>>>>>>>>>>> #define DEV "/dev/ttyU0" >>>>>>>>>>>> >>>>>>>>>>>> #define TBAN_SER_SOURCE1 0x05 /* Primary source */ >>>>>>>>>>>> #define TBAN_SER_SOURCE2 0x06 /* Alternative source >>>>>>>>>>>> (miniNG...) */ >>>>>>>>>>>> >>>>>>>>>>>> #define TBAN_SER_REQUEST 0x36 >>>>>>>>>>>> >>>>>>>>>>>> int main() >>>>>>>>>>>> { >>>>>>>>>>>> int fd; >>>>>>>>>>>> int result; >>>>>>>>>>>> struct termios oldtio, newtio; >>>>>>>>>>>> unsigned char buf[285]; >>>>>>>>>>>> >>>>>>>>>>>> printf("Opening device\n"); >>>>>>>>>>>> fd=open(DEV, O_RDWR | O_NOCTTY); >>>>>>>>>>>> >>>>>>>>>>>> if(fd<0) { >>>>>>>>>>>> perror(DEV); >>>>>>>>>>>> return 1; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> result=tcgetattr(fd,&oldtio); >>>>>>>>>>>> if(result<0) { >>>>>>>>>>>> perror("tcgetattr"); >>>>>>>>>>>> return 1; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> memcpy(&newtio,&oldtio,sizeof(struct termios)); >>>>>>>>>>>> newtio.c_cflag = B19200 >>>>>>>>>>>> >>>>>>>>>>>> | CRTSCTS >>>>>>>>>>>> | CS8 >>>>>>>>>>>> | CREAD; >>>>>>>>>>>> >>>>>>>>>>>> newtio.c_iflag = IGNPAR; >>>>>>>>>>>> newtio.c_oflag = 0; >>>>>>>>>>>> newtio.c_lflag = 0; >>>>>>>>>>>> newtio.c_cc[VMIN] = 1; >>>>>>>>>>>> newtio.c_cc[VTIME] = 0; >>>>>>>>>>>> >>>>>>>>>>>> result=tcflush(fd, TCIFLUSH); >>>>>>>>>>>> if(result<0) { >>>>>>>>>>>> perror("tcflush"); >>>>>>>>>>>> return 1; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> result=tcsetattr(fd,TCSANOW,&newtio); >>>>>>>>>>>> if(result<0) { >>>>>>>>>>>> perror("tcsetattr"); >>>>>>>>>>>> return 1; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> sleep(1); >>>>>>>>>>>> >>>>>>>>>>>> printf("Performing initial query\n"); >>>>>>>>>>>> buf[0]=TBAN_SER_SOURCE1; >>>>>>>>>>>> buf[1]=TBAN_SER_REQUEST; >>>>>>>>>>>> >>>>>>>>>>>> printf("Requesting status\n"); >>>>>>>>>>>> result=write(fd,buf,2); >>>>>>>>>>>> if(result<0) { >>>>>>>>>>>> perror("write"); >>>>>>>>>>>> return 1; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> sleep(1); >>>>>>>>>>>> >>>>>>>>>>>> printf("Reading status\n"); >>>>>>>>>>>> result=read(fd,buf,32); >>>>>>>>>>>> if(result<0) { >>>>>>>>>>>> perror("read"); >>>>>>>>>>>> return 1; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> result=tcsetattr(fd,TCSANOW,&oldtio); >>>>>>>>>>>> if(result<0) { >>>>>>>>>>>> perror("tcsetattr"); >>>>>>>>>>>> return 1; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> result=close(fd); >>>>>>>>>>>> if(result<0) { >>>>>>>>>>>> perror("close"); >>>>>>>>>>>> return 1; >>>>>>>>>>>> } >>>>>>>>>>>> return 0; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> It hangs while reading independently of the number of bits I am >>>>>>>>>>>> reading. >>>>>>>>>>>> >>>>>>>>>>>> Here is the output from dmesg when I load the uftdi module: >>>>>>>>>>>> Sep 20 21:31:31 ldaemon kernel: uftdi0: on usbus6 >>>>>>>>>>>> Sep 20 21:31:31 ldaemon kernel: ucom_attach_tty:317: tp = >>>>>>>>>>>> 0xffffff001f12b400, unit = 0 Sep 20 21:31:31 ldaemon kernel: >>>>>>>>>>>> ucom_attach_tty:346: ttycreate: U0 Sep 20 21:31:34 ldaemon root: >>>>>>>>>>>> Unknown USB device: vendor 0x051d product 0x0002 bus uhub0 >>>>>>>>>>>> >>>>>>>>>>>> Here is the output in /var/log/messages when I enable the debug >>>>>>>>>>>> output for ucom and uftdi: Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>>>> ucom_open:554: tp = 0xffffff001f12b400 Sep 20 21:33:30 ldaemon >>>>>>>>>>>> kernel: ucom_dtr:827: onoff = 1 Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>>>> ucom_line_state:799: on=0x01, off=0x00 Sep 20 21:33:30 ldaemon >>>>>>>>>>>> kernel: ucom_rts:838: onoff = 1 >>>>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, >>>>>>>>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_break:816: onoff = >>>>>>>>>>>> 0 Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x00, >>>>>>>>>>>> off=0x04 Sep 20 21:33:30 ldaemon kernel: ucom_status_change:901: >>>>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_param:950: sc = >>>>>>>>>>>> 0xffffff001f12ac58 Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>>>> uftdi_pre_param:653: >>>>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_dtr:827: onoff = 1 >>>>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x01, >>>>>>>>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_rts:838: onoff = 1 >>>>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: ucom_line_state:799: on=0x02, >>>>>>>>>>>> off=0x00 Sep 20 21:33:30 ldaemon kernel: ucom_cfg_open:520: >>>>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_open:354: >>>>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_read_callback:459: status >>>>>>>>>>>> change msr=0xf0 (0x00) lsr=0x60 (0x00) Sep 20 21:33:30 ldaemon >>>>>>>>>>>> kernel: ucom_status_change:901: >>>>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: >>>>>>>>>>>> msr=0xf0 lsr=0x60 Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>>>> ucom_cfg_status_change:887: DCD changed to 1 Sep 20 21:33:30 >>>>>>>>>>>> ldaemon kernel: >>>>>>>>>>>> uftdi_cfg_param:672: Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>>>> ucom_ioctl:653: cmd = 0x402c7413 Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>>>> ucom_ioctl:653: cmd = 0x80047410 Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>>>> ucom_ioctl:653: cmd = 0x802c7414 Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>>>> ucom_param:950: sc = 0xffffff001f12ac58 Sep 20 21:33:30 ldaemon >>>>>>>>>>>> kernel: >>>>>>>>>>>> uftdi_pre_param:653: >>>>>>>>>>>> Sep 20 21:33:30 ldaemon kernel: uftdi_cfg_get_status:705: >>>>>>>>>>>> msr=0xf0 lsr=0x60 Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>>>> uftdi_cfg_param:672: Sep 20 21:33:30 ldaemon kernel: >>>>>>>>>>>> ucom_get_data:1064: cnt=0 Sep 20 21:33:31 ldaemon kernel: >>>>>>>>>>>> ucom_ioctl:653: cmd = 0x80047410 Sep 20 21:33:32 ldaemon kernel: >>>>>>>>>>>> ucom_outwakeup:1009: sc = 0xffffff001f12ac58 Sep 20 21:33:32 >>>>>>>>>>>> ldaemon kernel: >>>>>>>>>>>> ucom_get_data:1064: cnt=2 >>>>>>>>>>>> Sep 20 21:33:32 ldaemon kernel: ucom_get_data:1064: cnt=0 >>>>>>>>>>>> >>>>>>>>>>>> I really need to get this working so I am ready to test things >>>>>>>>>>>> as much as I can... >>>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> You need to set raw mode for the TTY device I think. Maybe Ed can >>>>>>>>>>> give you the function name you need to call to do that? >>>>>>>>>>> >>>>>>>>>>> --HPS >>>>>>>>>>> >>>>>>>>>> Do I need to do something like that? >>>>>>>>>> ioctl(fileno(stdin), TIOCGETP, &tty_org); >>>>>>>>>> tty = tty_org; >>>>>>>>>> >>>>>>>>>> /* set terminal to raw mode ... */ >>>>>>>>>> tty.sg_flags |= CRMOD; >>>>>>>>>> tty.sg_flags &= ~ECHO; >>>>>>>>>> tty.sg_flags &= ~XTABS; >>>>>>>>>> tty.sg_flags |= RAW; >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> Pierre-Luc Drouin >>>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> You need to call this function: >>>>>>>>> >>>>>>>>> void >>>>>>>>> cfmakeraw(struct termios *t); >>>>>>>>> >>>>>>>>> --HPS >>>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> it still does not work. I have added the line >>>>>>>> cfmakeraw(&newtio); >>>>>>>> >>>>>>>> just before the call to tcflush and I get the following output in >>>>>>>> /var/log/messages: >>>>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_open:554: tp = >>>>>>>> 0xffffff001f12b400 Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: >>>>>>>> onoff = 1 >>>>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, >>>>>>>> off=0x00 Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 >>>>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, >>>>>>>> off=0x00 Sep 21 13:38:46 ldaemon kernel: ucom_break:816: onoff = 0 >>>>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x00, >>>>>>>> off=0x04 Sep 21 13:38:46 ldaemon kernel: ucom_status_change:901: >>>>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = >>>>>>>> 0xffffff001f12ac58 Sep 21 13:38:46 ldaemon kernel: >>>>>>>> uftdi_pre_param:653: >>>>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_dtr:827: onoff = 1 >>>>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x01, >>>>>>>> off=0x00 Sep 21 13:38:46 ldaemon kernel: ucom_rts:838: onoff = 1 >>>>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_line_state:799: on=0x02, >>>>>>>> off=0x00 Sep 21 13:38:46 ldaemon kernel: ucom_cfg_open:520: >>>>>>>> Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_open:354: >>>>>>>> uftdi_cfg_get_status:705: msr=0xf0 lsr=0x60 >>>>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_cfg_status_change:887: DCD >>>>>>>> changed to 1 Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: >>>>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 >>>>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >>>>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 >>>>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_param:950: sc = >>>>>>>> 0xffffff001f12ac58 Sep 21 13:38:46 ldaemon kernel: >>>>>>>> uftdi_pre_param:653: >>>>>>>> Sep 21 13:38:46 ldaemon kernel: uftdi_cfg_param:672: >>>>>>>> Sep 21 13:38:46 ldaemon kernel: ucom_get_data:1064: cnt=0 >>>>>>>> Sep 21 13:38:47 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >>>>>>>> Sep 21 13:38:48 ldaemon kernel: ucom_outwakeup:1009: sc = >>>>>>>> 0xffffff001f12ac58 Sep 21 13:38:48 ldaemon kernel: >>>>>>>> ucom_get_data:1064: cnt=2 >>>>>>>> Sep 21 13:38:48 ldaemon kernel: ucom_get_data:1064: cnt=0 >>>>>>>> >>>>>>> Can you try adding a delay after setting the baud rate? >>>>>>> >>>>>>> --HPS >>>>>>> >>>>>> The code already sleeps for 1 second after I applying the baud rate >>>>>> (via tcsetattr(fd,TCSANOW,&newtio)). I am not sure to understand what >>>>>> you mean... >>>>>> >>>>> Hi, >>>>> >>>>> I mean try adding some: >>>>> >>>>> usleep(1000000); >>>>> >>>>> To your code to see if that changes anything. >>>>> >>>>> Also try reading one byte instead of 32. >>>>> >>>>> Last, try adding a printout to: >>>>> >>>>> src/sys/dev/usb/serial/uftdi.c >>>>> >>>>> uftdi_read_callback() >>>>> >>>>> and printout the actlen variable. >>>>> >>>>> --HPS >>>>> >>>> ok, so I added the usleep statement right after the existing sleep >>>> statement. I also tried reading a single byte. It did not make any >>>> difference... I added a print statement to print the value of actlen >>>> right after it is set via >>>> usbd_xfer_status(xfer, &actlen, NULL, NULL, NULL); >>>> >>>> Here is the new output in /var/log/messages: >>>> Sep 21 14:55:28 ldaemon kernel: ucom_open:554: tp = 0xffffff0139488800 >>>> Sep 21 14:55:28 ldaemon kernel: ucom_dtr:827: onoff = 1 >>>> Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 >>>> Sep 21 14:55:28 ldaemon kernel: ucom_rts:838: onoff = 1 >>>> Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 >>>> Sep 21 14:55:28 ldaemon kernel: ucom_break:816: onoff = 0 >>>> Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x00, off=0x04 >>>> Sep 21 14:55:28 ldaemon kernel: ucom_status_change:901: >>>> Sep 21 14:55:28 ldaemon kernel: ucom_param:950: sc = 0xffffff013bcac458 >>>> Sep 21 14:55:28 ldaemon kernel: ucom_dtr:827: onoff = 1 >>>> Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x01, off=0x00 >>>> Sep 21 14:55:28 ldaemon kernel: ucom_rts:838: onoff = 1 >>>> Sep 21 14:55:28 ldaemon kernel: ucom_line_state:799: on=0x02, off=0x00 >>>> Sep 21 14:55:28 ldaemon kernel: ucom_cfg_open:520: >>>> Sep 21 14:55:28 ldaemon kernel: actlen is 0 >>>> Sep 21 14:55:28 ldaemon kernel: actlen is 2 >>>> Sep 21 14:55:28 ldaemon kernel: actlen is 2 >>>> Sep 21 14:55:28 ldaemon kernel: ucom_cfg_status_change:887: DCD changed >>>> to 1 Sep 21 14:55:28 ldaemon kernel: ucom_ioctl:653: cmd = 0x402c7413 >>>> Sep 21 14:55:28 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 Sep 21 >>>> 14:55:28 ldaemon kernel: ucom_ioctl:653: cmd = 0x802c7414 Sep 21 >>>> 14:55:28 ldaemon kernel: ucom_param:950: sc = 0xffffff013bcac458 Sep 21 >>>> 14:55:28 ldaemon kernel: actlen is 2 >>>> Sep 21 14:55:28 ldaemon last message repeated 12 times >>>> Sep 21 14:55:28 ldaemon kernel: ucom_get_data:1064: cnt=0 >>>> Sep 21 14:55:28 ldaemon kernel: actlen is 2 >>>> Sep 21 14:55:30 ldaemon last message repeated 111 times >>>> Sep 21 14:55:30 ldaemon kernel: ucom_ioctl:653: cmd = 0x80047410 >>>> Sep 21 14:55:30 ldaemon kernel: actlen is 2 >>>> Sep 21 14:55:31 ldaemon last message repeated 62 times >>>> Sep 21 14:55:31 ldaemon kernel: ucom_outwakeup:1009: sc = >>>> 0xffffff013bcac458 Sep 21 14:55:31 ldaemon kernel: ucom_get_data:1064: >>>> cnt=2 >>>> Sep 21 14:55:31 ldaemon kernel: ucom_get_data:1064: cnt=0 >>>> Sep 21 14:55:31 ldaemon kernel: actlen is 2 >>>> >>> If actlen is 2 then no modem data is transferred from the device. >>> >>> --HPS >>> >> Hmm, so does it indicate a bug in uftdi? In asynchronous mode, SIGIO is >> generated but when try reading I get error EINTR... >> >> Thanks! >> > > It indicates that your device is not sending any data. > > --HPS > > So does it mean that the write statement (a status request) is not transmitted to the device either? Because this write statement should be followed by data sent from the device and it effectively does on Linux. And about SIGIO, shouldn't this signal be generated only when there is data available to read? Why is it generated in asynchronous mode and then the read statement returns EINTR? Thanks! Pierre-Luc From owner-freebsd-usb@FreeBSD.ORG Tue Sep 22 15:35:22 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E28F51065670; Tue, 22 Sep 2009 15:35:22 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4C1408FC22; Tue, 22 Sep 2009 15:35:21 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=6U-Pe18MTAwA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=gz_K4MfN8Pwl7vPYsh0A:9 a=Dseo-QWBhIYLJrIiVcUA:7 a=7idNN5VBspv4lzxQPXk0trebHF4A:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1319915294; Tue, 22 Sep 2009 17:35:19 +0200 From: Hans Petter Selasky To: "Pierre-Luc Drouin" Date: Tue, 22 Sep 2009 17:35:56 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <4AB6DA79.7050209@pldrouin.net> <200909221638.47642.hselasky@c2i.net> <4AB8EB78.2020809@pldrouin.net> In-Reply-To: <4AB8EB78.2020809@pldrouin.net> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909221735.57680.hselasky@c2i.net> Cc: ed@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 15:35:23 -0000 On Tuesday 22 September 2009 17:21:28 Pierre-Luc Drouin wrote: > >> Thanks! > > > > It indicates that your device is not sending any data. > > > > --HPS > > So does it mean that the write statement (a status request) is not > transmitted to the device either? No, the "xxx_get()" message means that the data you write is sent and transmitted. BTW: I have a FTDI adapter here, and it works fine with loopback when the baudrate is set correctly. > Because this write statement should be > followed by data sent from the device and it effectively does on Linux. > And about SIGIO, shouldn't this signal be generated only when there is > data available to read? Why is it generated in asynchronous mode and > then the read statement returns EINTR? Ed has to answer these questions. This stuff is not handled in the USB stack for FTDI devices. --HPS From owner-freebsd-usb@FreeBSD.ORG Tue Sep 22 15:40:14 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B3831065742 for ; Tue, 22 Sep 2009 15:40:14 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.tele2.se [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 015E48FC27 for ; Tue, 22 Sep 2009 15:40:13 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=VVfX8VgzZO4GLFTQO80A:9 a=724ilAVQdRK5f0VThoHGM7T9QrAA:4 a=W-g0cnAyS_RkOye6:21 a=3egbkXFzQ-Kodxah:21 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1135387619; Tue, 22 Sep 2009 17:40:11 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Tue, 22 Sep 2009 17:40:48 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <2C0D6269-1296-4D34-8029-828A0FE281CB@tlb.org> In-Reply-To: <2C0D6269-1296-4D34-8029-828A0FE281CB@tlb.org> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909221740.49279.hselasky@c2i.net> Cc: Subject: Re: libusb20 api X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 15:40:14 -0000 On Tuesday 22 September 2009 00:38:46 Trevor Blackwell wrote: > This always fails: > > char devname[256]; > if (libusb20_dev_get_iface_desc(pdev, n, devname, > sizeof(devname))) break; > > while this works: > > char devname[128]; > if (libusb20_dev_get_iface_desc(pdev, n, devname, > sizeof(devname))) break; > > Because this function takes a uint8_t for length: > > : > static int > ugen20_dev_get_iface_desc(struct libusb20_device *pdev, > uint8_t iface_index, char *buf, uint8_t len) > > even though the kernel ioctl structure has a 16-bit length. > > Hans, why not just use size_t for such arguments? Your point is valid. Currently USB string descriptors are always limited to 255 bytes. Setting up a larger buffer does not make sense. I will see what I can do. --HPS From owner-freebsd-usb@FreeBSD.ORG Tue Sep 22 16:15:17 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B292106566B; Tue, 22 Sep 2009 16:15:17 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id 257528FC17; Tue, 22 Sep 2009 16:15:17 +0000 (UTC) Received: from mdaemon.pldrouin.net (pldrouinlap2-pc.physics.carleton.ca [134.117.23.34]) by smtp.cyberfingers.net (Postfix) with ESMTP id D3745AB6C1A; Tue, 22 Sep 2009 12:12:26 -0400 (EDT) Message-ID: <4AB8F817.1040703@pldrouin.net> Date: Tue, 22 Sep 2009 12:15:19 -0400 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: Hans Petter Selasky References: <4AB6DA79.7050209@pldrouin.net> <200909221638.47642.hselasky@c2i.net> <4AB8EB78.2020809@pldrouin.net> <200909221735.57680.hselasky@c2i.net> In-Reply-To: <200909221735.57680.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ed@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 16:15:17 -0000 Hans Petter Selasky wrote: > On Tuesday 22 September 2009 17:21:28 Pierre-Luc Drouin wrote: > > >>>> Thanks! >>>> >>> It indicates that your device is not sending any data. >>> >>> --HPS >>> >> So does it mean that the write statement (a status request) is not >> transmitted to the device either? >> > > No, the "xxx_get()" message means that the data you write is sent and > transmitted. > > BTW: I have a FTDI adapter here, and it works fine with loopback when the > baudrate is set correctly. > > >> Because this write statement should be >> followed by data sent from the device and it effectively does on Linux. >> And about SIGIO, shouldn't this signal be generated only when there is >> data available to read? Why is it generated in asynchronous mode and >> then the read statement returns EINTR? >> > > Ed has to answer these questions. This stuff is not handled in the USB stack > for FTDI devices. > > --HPS > > In the manual page for the uftdi driver, the chip I am using (FT232BL) is not listed. According to the FTDI website, it is based on FT8U232AM, but it has extra functionalities. Have you had the chance to test an device that uses either a FT232BM, FT232BL or FT232BQ chip? I just tested the device on FreeBSD 7.2 and it does not work either... Thanks Pierre-Luc Drouin From owner-freebsd-usb@FreeBSD.ORG Tue Sep 22 16:32:21 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 744F7106566C; Tue, 22 Sep 2009 16:32:21 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.tele2.se [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id D23068FC0A; Tue, 22 Sep 2009 16:32:20 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=6U-Pe18MTAwA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=iUV8EKD_c1rD5WRaTq4A:9 a=Qa9utn3zGSLP6tp8Y6cA:7 a=zT_VQ58tYyIJRjXs3ouBTdTqd_0A:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 567291388; Tue, 22 Sep 2009 18:32:18 +0200 From: Hans Petter Selasky To: "Pierre-Luc Drouin" Date: Tue, 22 Sep 2009 18:32:55 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <4AB6DA79.7050209@pldrouin.net> <200909221735.57680.hselasky@c2i.net> <4AB8F817.1040703@pldrouin.net> In-Reply-To: <4AB8F817.1040703@pldrouin.net> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909221832.56540.hselasky@c2i.net> Cc: ed@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 16:32:21 -0000 On Tuesday 22 September 2009 18:15:19 Pierre-Luc Drouin wrote: > Hans Petter Selasky wrote: > > On Tuesday 22 September 2009 17:21:28 Pierre-Luc Drouin wrote: > >>>> Thanks! > >>> > >>> It indicates that your device is not sending any data. > >>> > >>> --HPS > >> > >> So does it mean that the write statement (a status request) is not > >> transmitted to the device either? > > > > No, the "xxx_get()" message means that the data you write is sent and > > transmitted. > > > > BTW: I have a FTDI adapter here, and it works fine with loopback when the > > baudrate is set correctly. > > > >> Because this write statement should be > >> followed by data sent from the device and it effectively does on Linux. > >> And about SIGIO, shouldn't this signal be generated only when there is > >> data available to read? Why is it generated in asynchronous mode and > >> then the read statement returns EINTR? > > > > Ed has to answer these questions. This stuff is not handled in the USB > > stack for FTDI devices. > > > > --HPS > > In the manual page for the uftdi driver, the chip I am using (FT232BL) > is not listed. According to the FTDI website, it is based on FT8U232AM, > but it has extra functionalities. Have you had the chance to test an > device that uses either a FT232BM, FT232BL or FT232BQ chip? I just > tested the device on FreeBSD 7.2 and it does not work either... No, I haven't. --HPS From owner-freebsd-usb@FreeBSD.ORG Tue Sep 22 16:38:06 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18C7F1065670 for ; Tue, 22 Sep 2009 16:38:06 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.swip.net [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id 9CE358FC18 for ; Tue, 22 Sep 2009 16:38:05 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=ZsU00AtvC4qczHK_PhMA:9 a=b8DmBnQgBDWjI3E6FIeHLvlp8wUA:4 a=p6-se_fFCm7sBxGW:21 a=hoH4u6ILCsGuHcb_:21 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe13.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 922014458; Tue, 22 Sep 2009 18:38:02 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Tue, 22 Sep 2009 18:38:41 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <2C0D6269-1296-4D34-8029-828A0FE281CB@tlb.org> <200909221740.49279.hselasky@c2i.net> In-Reply-To: <200909221740.49279.hselasky@c2i.net> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909221838.42182.hselasky@c2i.net> Cc: Subject: Re: libusb20 api X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 16:38:06 -0000 On Tuesday 22 September 2009 17:40:48 Hans Petter Selasky wrote: > On Tuesday 22 September 2009 00:38:46 Trevor Blackwell wrote: > > This always fails: > > > > char devname[256]; > > if (libusb20_dev_get_iface_desc(pdev, n, devname, > > sizeof(devname))) break; > > > > while this works: > > > > char devname[128]; > > if (libusb20_dev_get_iface_desc(pdev, n, devname, > > sizeof(devname))) break; > > > > Because this function takes a uint8_t for length: > > > > : > > static int > > ugen20_dev_get_iface_desc(struct libusb20_device *pdev, > > uint8_t iface_index, char *buf, uint8_t len) > > > > even though the kernel ioctl structure has a 16-bit length. > > > > Hans, why not just use size_t for such arguments? > > Your point is valid. Currently USB string descriptors are always limited to > 255 bytes. Setting up a larger buffer does not make sense. > > I will see what I can do. > s/string/interface/ > --HPS From owner-freebsd-usb@FreeBSD.ORG Tue Sep 22 16:40:40 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4FE21065676; Tue, 22 Sep 2009 16:40:40 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id 8F2218FC0A; Tue, 22 Sep 2009 16:40:40 +0000 (UTC) Received: from mdaemon.pldrouin.net (pldrouinlap2-pc.physics.carleton.ca [134.117.23.34]) by smtp.cyberfingers.net (Postfix) with ESMTP id 199C5AB6C1D; Tue, 22 Sep 2009 12:37:50 -0400 (EDT) Message-ID: <4AB8FE08.7040007@pldrouin.net> Date: Tue, 22 Sep 2009 12:40:40 -0400 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: Hans Petter Selasky References: <4AB6DA79.7050209@pldrouin.net> <200909221735.57680.hselasky@c2i.net> <4AB8F817.1040703@pldrouin.net> <200909221832.56540.hselasky@c2i.net> In-Reply-To: <200909221832.56540.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ed@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 16:40:40 -0000 Hans Petter Selasky wrote: > On Tuesday 22 September 2009 18:15:19 Pierre-Luc Drouin wrote: > >> Hans Petter Selasky wrote: >> >>> On Tuesday 22 September 2009 17:21:28 Pierre-Luc Drouin wrote: >>> >>>>>> Thanks! >>>>>> >>>>> It indicates that your device is not sending any data. >>>>> >>>>> --HPS >>>>> >>>> So does it mean that the write statement (a status request) is not >>>> transmitted to the device either? >>>> >>> No, the "xxx_get()" message means that the data you write is sent and >>> transmitted. >>> >>> BTW: I have a FTDI adapter here, and it works fine with loopback when the >>> baudrate is set correctly. >>> >>> >>>> Because this write statement should be >>>> followed by data sent from the device and it effectively does on Linux. >>>> And about SIGIO, shouldn't this signal be generated only when there is >>>> data available to read? Why is it generated in asynchronous mode and >>>> then the read statement returns EINTR? >>>> >>> Ed has to answer these questions. This stuff is not handled in the USB >>> stack for FTDI devices. >>> >>> --HPS >>> >> In the manual page for the uftdi driver, the chip I am using (FT232BL) >> is not listed. According to the FTDI website, it is based on FT8U232AM, >> but it has extra functionalities. Have you had the chance to test an >> device that uses either a FT232BM, FT232BL or FT232BQ chip? I just >> tested the device on FreeBSD 7.2 and it does not work either... >> > > No, I haven't. > > --HPS > > Are there additional tests I can do in synchronous mode to try pinning down the problem? Thanks! From owner-freebsd-usb@FreeBSD.ORG Tue Sep 22 16:41:58 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4F031065679; Tue, 22 Sep 2009 16:41:58 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.swipnet.se [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id F37228FC0A; Tue, 22 Sep 2009 16:41:57 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=zrZ_yKK0mYZgR30UgiAA:9 a=CDv_QkzGBN8kou5bb350XfBRJK0A:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 567293943; Tue, 22 Sep 2009 18:41:56 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org, thompsa@freebsd.org, alfred@freebsd.org Date: Tue, 22 Sep 2009 18:42:35 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <2C0D6269-1296-4D34-8029-828A0FE281CB@tlb.org> <200909221740.49279.hselasky@c2i.net> In-Reply-To: <200909221740.49279.hselasky@c2i.net> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909221842.36202.hselasky@c2i.net> Cc: Subject: Re: libusb20 api X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 16:41:58 -0000 On Tuesday 22 September 2009 17:40:48 Hans Petter Selasky wrote: > On Tuesday 22 September 2009 00:38:46 Trevor Blackwell wrote: > > This always fails: > > Your comment could be applied to other functions being passed lengths aswell. However, if you compile your code with -Wall, you should be safe from such errors when passing too big constants. I'm not sure if I will push an API change like this at the current moment. --HPS From owner-freebsd-usb@FreeBSD.ORG Tue Sep 22 16:46:49 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68A47106568D; Tue, 22 Sep 2009 16:46:49 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.swip.net [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id C31468FC08; Tue, 22 Sep 2009 16:46:48 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=6U-Pe18MTAwA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=Qx5o19XNqxyMbwOXjA0A:9 a=vYRQ-6nK_KfbgbR_-g0A:7 a=-rBYjB7pHcokTlg8mahpdxmbx5oA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 567294896; Tue, 22 Sep 2009 18:46:47 +0200 From: Hans Petter Selasky To: "Pierre-Luc Drouin" Date: Tue, 22 Sep 2009 18:47:25 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <4AB6DA79.7050209@pldrouin.net> <200909221832.56540.hselasky@c2i.net> <4AB8FE08.7040007@pldrouin.net> In-Reply-To: <4AB8FE08.7040007@pldrouin.net> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909221847.26679.hselasky@c2i.net> Cc: ed@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/138659: uftdi driver broken in RELENG_8/CURRENT X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 16:46:49 -0000 On Tuesday 22 September 2009 18:40:40 Pierre-Luc Drouin wrote: > Hans Petter Selasky wrote: > > On Tuesday 22 September 2009 18:15:19 Pierre-Luc Drouin wrote: > >> Hans Petter Selasky wrote: > >>> On Tuesday 22 September 2009 17:21:28 Pierre-Luc Drouin wrote: > >>>>>> Thanks! > >>>>> > >>>>> It indicates that your device is not sending any data. > >>>>> > >>>>> --HPS > >>>> > >>>> So does it mean that the write statement (a status request) is not > >>>> transmitted to the device either? > >>> > >>> No, the "xxx_get()" message means that the data you write is sent and > >>> transmitted. > >>> > >>> BTW: I have a FTDI adapter here, and it works fine with loopback when > >>> the baudrate is set correctly. > >>> > >>>> Because this write statement should be > >>>> followed by data sent from the device and it effectively does on > >>>> Linux. And about SIGIO, shouldn't this signal be generated only when > >>>> there is data available to read? Why is it generated in asynchronous > >>>> mode and then the read statement returns EINTR? > >>> > >>> Ed has to answer these questions. This stuff is not handled in the USB > >>> stack for FTDI devices. > >>> > >>> --HPS > >> > >> In the manual page for the uftdi driver, the chip I am using (FT232BL) > >> is not listed. According to the FTDI website, it is based on FT8U232AM, > >> but it has extra functionalities. Have you had the chance to test an > >> device that uses either a FT232BM, FT232BL or FT232BQ chip? I just > >> tested the device on FreeBSD 7.2 and it does not work either... > > > > No, I haven't. > > > > --HPS > > Are there additional tests I can do in synchronous mode to try pinning > down the problem? Hi, If the device doesn't work, then there are probably some FTDI USB registers which are not programmed correctly. If you could debug that it would be great. --HPS From owner-freebsd-usb@FreeBSD.ORG Wed Sep 23 14:54:44 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40E751065676; Wed, 23 Sep 2009 14:54:44 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 44F3B8FC16; Wed, 23 Sep 2009 14:54:42 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA29906; Wed, 23 Sep 2009 17:54:41 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4ABA36B1.9070706@icyb.net.ua> Date: Wed, 23 Sep 2009 17:54:41 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: freebsd-usb@freebsd.org, freebsd-current@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: sb600/sb700 ohci experimental patch X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 14:54:44 -0000 If you have a system with SB600, SB700, etc chipset and you have problems with low speed USB devices attached during boot (keyboard, mouse), could you please try the following experimental patch and report back? I am primarily interested in the first several lines produced during boot with printfs that are introduced by the patch. Preferably in the context of surrounding USB-related dmesg messages. No need to report subsequent same-looking ever-repeating messages (if any). WARNING: this is an experimental patch, it is probably not even close to what a real fix could be, it might not fix the problem (but perhaps it would), it might introduce instabilities into OHCI driver and it is noisy (unconditional printf). The primary purpose of this patch is to gather information necessary for a real fix. Thank you! diff --git a/sys/dev/usb/controller/ohci.c b/sys/dev/usb/controller/ohci.c index 30592c1..fb6ba34 100644 --- a/sys/dev/usb/controller/ohci.c +++ b/sys/dev/usb/controller/ohci.c @@ -247,8 +249,8 @@ reset: OWRITE4(sc, OHCI_INTERRUPT_ENABLE, sc->sc_eintrs | OHCI_MIE); /* switch on desired functional features */ ctl = OREAD4(sc, OHCI_CONTROL); - ctl &= ~(OHCI_CBSR_MASK | OHCI_LES | OHCI_HCFS_MASK | OHCI_IR); - ctl |= OHCI_PLE | OHCI_IE | OHCI_CLE | OHCI_BLE | + ctl &= ~(OHCI_CBSR_MASK | OHCI_LES | OHCI_HCFS_MASK | OHCI_IR | OHCI_CLE | OHCI_CLF); + ctl |= OHCI_PLE | OHCI_IE | /*OHCI_CLE |*/ OHCI_BLE | OHCI_RATIO_1_4 | OHCI_HCFS_OPERATIONAL; /* And finally start it! */ OWRITE4(sc, OHCI_CONTROL, ctl); @@ -2727,8 +2729,17 @@ ohci_set_hw_power(struct usb_bus *bus) temp = OREAD4(sc, OHCI_CONTROL); temp &= ~(OHCI_PLE | OHCI_IE | OHCI_CLE | OHCI_BLE); - if (flags & USB_HW_POWER_CONTROL) + if (flags & USB_HW_POWER_CONTROL) { + struct usb_page_search buf_res; + + buf_res.physaddr = OREAD4(sc, OHCI_CONTROL_HEAD_ED); + printf("(hw power) control head <= %p\n", (void*)buf_res.physaddr); + usbd_get_page(&sc->sc_hw.ctrl_start_pc, 0, &buf_res); + printf("(hw power) control head => %p\n", (void*)buf_res.physaddr); + OWRITE4(sc, OHCI_CONTROL_HEAD_ED, buf_res.physaddr); + temp |= OHCI_CLE; + } if (flags & USB_HW_POWER_BULK) temp |= OHCI_BLE; -- Andriy Gapon From owner-freebsd-usb@FreeBSD.ORG Wed Sep 23 22:50:03 2009 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3260C1065679 for ; Wed, 23 Sep 2009 22:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 21F978FC1D for ; Wed, 23 Sep 2009 22:50:03 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8NMo26a037853 for ; Wed, 23 Sep 2009 22:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8NMo2UC037852; Wed, 23 Sep 2009 22:50:02 GMT (envelope-from gnats) Date: Wed, 23 Sep 2009 22:50:02 GMT Message-Id: <200909232250.n8NMo2UC037852@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Tom Judge Cc: Subject: Re: usb/116947: [ukbd] [patch] [regression] enable boot protocol on the USB keyboards X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Judge List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 22:50:03 -0000 The following reply was made to PR usb/116947; it has been noted by GNATS. From: Tom Judge To: bug-followup@FreeBSD.org, rea-fbsd@codelabs.ru Cc: Subject: Re: usb/116947: [ukbd] [patch] [regression] enable boot protocol on the USB keyboards Date: Wed, 23 Sep 2009 22:22:16 +0000 This is a multi-part message in MIME format. --------------070601060402040600080702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here is a simple patch against 8.0 Beta 3 to make the Function keys work. This adds a quirk UQ_KBD_BOOTPROTO, than can be set to force the keyboard to use the boot protocol. --------------070601060402040600080702 Content-Type: text/plain; name="usb-natural4000.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="usb-natural4000.patch" Index: quirk/usb_quirk.c =================================================================== --- quirk/usb_quirk.c (revision 196574) +++ quirk/usb_quirk.c (working copy) @@ -122,6 +122,7 @@ {USB_QUIRK_ENTRY(USB_VENDOR_METAGEEK, USB_PRODUCT_METAGEEK_WISPY1B, 0x0000, 0xFFFF, UQ_KBD_IGNORE, UQ_HID_IGNORE, UQ_NONE)}, {USB_QUIRK_ENTRY(USB_VENDOR_TENX, USB_PRODUCT_TENX_UAUDIO0, 0x0101, 0x0101, UQ_AUDIO_SWAP_LR, UQ_NONE)}, /* MS keyboards do weird things */ + {USB_QUIRK_ENTRY(USB_VENDOR_MICROSOFT, USB_PRODUCT_MICROSOFT_NATURAL4000, 0x0000, 0xFFFF, UQ_KBD_BOOTPROTO, UQ_NONE)}, {USB_QUIRK_ENTRY(USB_VENDOR_MICROSOFT, USB_PRODUCT_MICROSOFT_WLINTELLIMOUSE, 0x0000, 0xFFFF, UQ_MS_LEADING_BYTE, UQ_NONE)}, {USB_QUIRK_ENTRY(USB_VENDOR_METAGEEK, USB_PRODUCT_METAGEEK_WISPY24X, 0x0000, 0xFFFF, UQ_KBD_IGNORE, UQ_HID_IGNORE, UQ_NONE)}, }; @@ -138,6 +139,7 @@ [UQ_BUS_POWERED] = "UQ_BUS_POWERED", [UQ_HID_IGNORE] = "UQ_HID_IGNORE", [UQ_KBD_IGNORE] = "UQ_KBD_IGNORE", + [UQ_KBD_BOOTPROTO] = "UQ_KBD_BOOTPROTO", [UQ_MS_BAD_CLASS] = "UQ_MS_BAD_CLASS", [UQ_MS_LEADING_BYTE] = "UQ_MS_LEADING_BYTE", [UQ_MS_REVZ] = "UQ_MS_REVZ", Index: quirk/usb_quirk.h =================================================================== --- quirk/usb_quirk.h (revision 196574) +++ quirk/usb_quirk.h (working copy) @@ -40,6 +40,7 @@ UQ_BUS_POWERED, /* device is bus powered, despite claim */ UQ_HID_IGNORE, /* device should be ignored by hid class */ UQ_KBD_IGNORE, /* device should be ignored by kbd class */ + UQ_KBD_BOOTPROTO, /* kbd should use the boot proto. */ UQ_MS_BAD_CLASS, /* doesn't identify properly */ UQ_MS_LEADING_BYTE, /* mouse sends an unknown leading byte */ UQ_MS_REVZ, /* mouse has Z-axis reversed */ Index: input/ukbd.c =================================================================== --- input/ukbd.c (revision 196574) +++ input/ukbd.c (working copy) @@ -789,6 +789,17 @@ * according to the BIOS data? */ KBD_PROBE_DONE(kbd); + /* + * Set boot protocol if we need the quirk. + */ + + if (usb_test_quirk(uaa, UQ_KBD_BOOTPROTO)) { + err = usbd_req_set_protocol(sc->sc_udev, &Giant, sc->sc_iface_index, 0); + if (err != USB_ERR_NORMAL_COMPLETION) { + DPRINTF("set protocol error=%s\n", usbd_errstr(err)); + goto detach; + } + } /* figure out if there is an ID byte in the data */ err = usbd_req_get_hid_desc(uaa->device, NULL, &hid_ptr, Index: usbdevs =================================================================== --- usbdevs (revision 196574) +++ usbdevs (working copy) @@ -1751,6 +1751,7 @@ product MICROSOFT WLNOTEBOOK3 0x00d2 Wireless Optical Mouse 3000 (Model 1049) product MICROSOFT WLUSBMOUSE 0x00b9 Wireless USB Mouse product MICROSOFT XBOX360 0x0292 XBOX 360 WLAN +product MICROSOFT NATURAL4000 0x00db Natural Ergonomic Keyboard 4000 /* Microtech products */ product MICROTECH SCSIDB25 0x0004 USB-SCSI-DB25 --------------070601060402040600080702-- From owner-freebsd-usb@FreeBSD.ORG Wed Sep 23 23:01:46 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00EB4106566B; Wed, 23 Sep 2009 23:01:46 +0000 (UTC) (envelope-from hinokind@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 55D188FC0A; Wed, 23 Sep 2009 23:01:45 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e21so1476890fga.13 for ; Wed, 23 Sep 2009 16:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:to:cc:subject :references:date:mime-version:content-transfer-encoding:from :message-id:in-reply-to:user-agent; bh=O1bwGRjZehdnPQqpJcJTuY/jHk0DhNY9MWPcUVQOqT4=; b=Y7zYkA0YjG07ClFjps/sKarsny93JwXPmUglUDs3eCDpFu2QptP11ELtUtqFsTc/1j 2UxdtI0bTeLSE1Bu5hR/9OOjQgCbASuXG46D1FnKAETIp/Dfh5K8kOLhgsXW8nJgowyN cnuQGURtoIkYfBMLI8eUfbbCbiptvYFKgZxis= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; b=BinD//LXMzvUb94NUI5ImzDhevyqd5Aaz1Ohm4E6Jz5atyaIiFbhNaHZq1dqmE4Q0r On2zFXLBYaVfRSpcJF2EBXbSNzwNwDWcopu+IobdcJVwi3dJII3fHwjNne+L4kk/K4pb wPA6YW5M5R3/rUptjPiJmrSpokRXQBnsujzS8= Received: by 10.86.220.9 with SMTP id s9mr2458196fgg.40.1253745052966; Wed, 23 Sep 2009 15:30:52 -0700 (PDT) Received: from klevas (hst-17-80.splius.lt [77.79.17.80]) by mx.google.com with ESMTPS id e11sm618526fga.11.2009.09.23.15.30.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 23 Sep 2009 15:30:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Andriy Gapon" References: <4ABA36B1.9070706@icyb.net.ua> Date: Fri, 25 Sep 2009 01:31:17 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: =?utf-8?B?QW5kcml1cyBNb3JrxatuYXM=?= Message-ID: In-Reply-To: <4ABA36B1.9070706@icyb.net.ua> User-Agent: Opera Mail/10.00 (FreeBSD) Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: sb600/sb700 ohci experimental patch X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 23:01:46 -0000 On Wed, 23 Sep 2009 17:54:41 +0300, Andriy Gapon wrote: > If you have a system with SB600, SB700, etc chipset and you have problems with low > speed USB devices attached during boot (keyboard, mouse), could you please try the > following experimental patch and report back? > I am primarily interested in the first several lines produced during boot with > printfs that are introduced by the patch. Preferably in the context of surrounding > USB-related dmesg messages. No need to report subsequent same-looking > ever-repeating messages (if any). I hope this helps: Test box: FreeBSD 8.0-RC1 amd64 r197323M on Asus M2A-VM (SB600) Without your patch, if mouse is plugged into one of the back USB ports and umass device is present on any USB port, mouse won't work. It has to be connected to front USB port to be friendly with other devices. With your patch, mouse can be plugged anywhere, it won't complain about umass devices connected to front USB port, but it still doesn't play nice with devices on back ports during boot. If I connect storage device after boot, both mouse and storage devices work fine. Parts of dmesg with mouse connected to back and storage to front USB ports. Everything works. usbus0: 12Mbps Full Speed USB v1.0 (hw power) control head <= 0xcfef1e30 (hw power) control head => 0x2329000 usbus1: 12Mbps Full Speed USB v1.0 (hw power) control head <= 0x4143000 (hw power) control head => 0x4143000 usbus2: 12Mbps Full Speed USB v1.0 (hw power) control head <= 0x4186000 (hw power) control head => 0x4186000 usbus3: 12Mbps Full Speed USB v1.0 (hw power) control head <= 0x41aa000 (hw power) control head => 0x41aa000 usbus4: 12Mbps Full Speed USB v1.0 (hw power) control head <= 0x4201000 (hw power) control head => 0x4201000 usbus5: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 Root mount waiting for: usbus5 usbus4 usbus3 usbus2 usbus1 usbus0 uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus5 Root mount waiting for: usbus5 Root mount waiting for: usbus5 Root mount waiting for: usbus5 uhub5: 10 ports with 10 removable, self powered Root mount waiting for: usbus5 (hw power) control head <= 0x2329000 (hw power) control head => 0x2329000 ugen0.2: at usbus0 ums0: on usbus0 ums0: 16 buttons and [XYZ] coordinates ID=0 uhid0: on usbus0 (hw power) control head <= 0x2329000 (hw power) control head => 0x2329000 ugen5.2: at usbus5 umass0: on usbus5 umass0: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus5 (hw power) control head <= 0x2329000 (hw power) control head => 0x2329000 umass0:1:0:-1: Attached to scbus1 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 1967MB (4030463 512 byte sectors: 255H 63S/T 250C) Connected another device to back USB port after booting was finished: (hw power) control head <= 0x4143000 (hw power) control head => 0x4143000 ugen1.2: at usbus1 umass1: on usbus1 umass1: SCSI over Bulk-Only; quirks = 0x0000 umass1:2:1:-1: Attached to scbus2 (hw power) control head <= 0x4143000 (hw power) control head => 0x4143000 (hw power) control head <= 0x4143000 (hw power) control head => 0x4143000 (probe0:umass-sim1:1:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim1:1:0:0): CAM Status: SCSI Status Error (probe0:umass-sim1:1:0:0): SCSI Status: Check Condition (probe0:umass-sim1:1:0:0): UNIT ATTENTION asc:28,0 (probe0:umass-sim1:1:0:0): Not ready to ready change, medium may have changed (probe0:umass-sim1:1:0:0): Retrying Command (per Sense Data) da1 at umass-sim1 bus 1 target 0 lun 0 da1: Removable Direct Access SCSI-0 device da1: 1.000MB/s transfers da1: 964MB (1974272 512 byte sectors: 64H 32S/T 964C) Another dmesg, booting with storage device and mouse both connected to back USB ports. Mouse works, storage doesn't. usbus0: 12Mbps Full Speed USB v1.0 (hw power) control head <= 0xcfef1e30 (hw power) control head => 0x2329000 usbus1: 12Mbps Full Speed USB v1.0 (hw power) control head <= 0xcfef1e40 (hw power) control head => 0x4143000 (hw power) control head <= 0x2329000 (hw power) control head => 0x2329000 ugen0.2: at usbus0 ums0: on usbus0 ums0: 16 buttons and [XYZ] coordinates ID=0 uhid0: on usbus0 (hw power) control head <= 0x2329000 (hw power) control head => 0x2329000 (hw power) control head <= 0x2329000 (hw power) control head => 0x2329000 (hw power) control head <= 0x4143000 (hw power) control head => 0x4143000 ugen1.2: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:1:0:-1: Attached to scbus1 (hw power) control head <= 0x4143000 (hw power) control head => 0x4143000 If you need anything else, let me know. And thanks for the patch. -- Andrius From owner-freebsd-usb@FreeBSD.ORG Thu Sep 24 06:22:31 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87657106566B for ; Thu, 24 Sep 2009 06:22:31 +0000 (UTC) (envelope-from dorian.buettner@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 066568FC1D for ; Thu, 24 Sep 2009 06:22:30 +0000 (UTC) Received: (qmail invoked by alias); 24 Sep 2009 06:22:29 -0000 Received: from port-92-192-53-134.dynamic.qsc.de (EHLO zock.doris.net) [92.192.53.134] by mail.gmx.net (mp025) with SMTP; 24 Sep 2009 08:22:29 +0200 X-Authenticated: #1682771 X-Provags-ID: V01U2FsdGVkX18y1/4iCL4yP7/CkjKCNda20auV11sANzWIbQb3oG USNM6UaiajHhyp From: Dorian =?utf-8?q?B=C3=BCttner?= To: freebsd-usb@freebsd.org Date: Thu, 24 Sep 2009 08:22:28 +0200 User-Agent: KMail/1.12.1 (FreeBSD/8.0-RC1; KDE/4.3.1; amd64; ; ) References: <4ABA36B1.9070706@icyb.net.ua> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200909240822.28180.dorian.buettner@gmx.de> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: sb600/sb700 ohci experimental patch X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 06:22:31 -0000 On Friday 25 September 2009 00:31:17 Andrius Mork=C5=ABnas wrote: > On Wed, 23 Sep 2009 17:54:41 +0300, Andriy Gapon wrote: > > If you have a system with SB600, SB700, etc chipset and you have proble= ms > > with low speed USB devices attached during boot (keyboard, mouse), could > > you please try the following experimental patch and report back? > > I am primarily interested in the first several lines produced during bo= ot > > with printfs that are introduced by the patch. Preferably in the context > > of surrounding USB-related dmesg messages. No need to report subsequent > > same-looking ever-repeating messages (if any). >=20 > I hope this helps: >=20 > Test box: FreeBSD 8.0-RC1 amd64 r197323M on Asus M2A-VM (SB600) >=20 > Without your patch, if mouse is plugged into one of the back USB ports and > umass device is present on any USB port, mouse won't work. It has to be > connected to front USB port to be friendly with other devices. >=20 > With your patch, mouse can be plugged anywhere, it won't complain about > umass devices connected to front USB port, but it still doesn't play nice > with devices on back ports during boot. If I connect storage device after > boot, both mouse and storage devices work fine. >=20 >=20 > Parts of dmesg with mouse connected to back and storage to front USB port= s. > Everything works. >=20 > usbus0: 12Mbps Full Speed USB v1.0 > (hw power) control head <=3D 0xcfef1e30 > (hw power) control head =3D> 0x2329000 > usbus1: 12Mbps Full Speed USB v1.0 > (hw power) control head <=3D 0x4143000 > (hw power) control head =3D> 0x4143000 > usbus2: 12Mbps Full Speed USB v1.0 > (hw power) control head <=3D 0x4186000 > (hw power) control head =3D> 0x4186000 > usbus3: 12Mbps Full Speed USB v1.0 > (hw power) control head <=3D 0x41aa000 > (hw power) control head =3D> 0x41aa000 > usbus4: 12Mbps Full Speed USB v1.0 > (hw power) control head <=3D 0x4201000 > (hw power) control head =3D> 0x4201000 > usbus5: 480Mbps High Speed USB v2.0 >=20 > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > ugen4.1: at usbus4 > uhub4: on usbus4 > ugen5.1: at usbus5 > uhub5: on usbus5 > Root mount waiting for: usbus5 usbus4 usbus3 usbus2 usbus1 usbus0 > uhub2: 2 ports with 2 removable, self powered > uhub3: 2 ports with 2 removable, self powered > uhub0: 2 ports with 2 removable, self powered > uhub4: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > Root mount waiting for: usbus5 > Root mount waiting for: usbus5 > Root mount waiting for: usbus5 > Root mount waiting for: usbus5 > uhub5: 10 ports with 10 removable, self powered > Root mount waiting for: usbus5 > (hw power) control head <=3D 0x2329000 > (hw power) control head =3D> 0x2329000 > ugen0.2: at usbus0 > ums0: on > usbus0 ums0: 16 buttons and [XYZ] coordinates ID=3D0 > uhid0: on > usbus0 (hw power) control head <=3D 0x2329000 > (hw power) control head =3D> 0x2329000 > ugen5.2: at usbus5 > umass0: on > usbus5 umass0: SCSI over Bulk-Only; quirks =3D 0x0000 > Root mount waiting for: usbus5 > (hw power) control head <=3D 0x2329000 > (hw power) control head =3D> 0x2329000 > umass0:1:0:-1: Attached to scbus1 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-2 device > da0: 40.000MB/s transfers > da0: 1967MB (4030463 512 byte sectors: 255H 63S/T 250C) >=20 >=20 > Connected another device to back USB port after booting was finished: >=20 > (hw power) control head <=3D 0x4143000 > (hw power) control head =3D> 0x4143000 > ugen1.2: at usbus1 > umass1: on usbus1 > umass1: SCSI over Bulk-Only; quirks =3D 0x0000 > umass1:2:1:-1: Attached to scbus2 > (hw power) control head <=3D 0x4143000 > (hw power) control head =3D> 0x4143000 > (hw power) control head <=3D 0x4143000 > (hw power) control head =3D> 0x4143000 > (probe0:umass-sim1:1:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:umass-sim1:1:0:0): CAM Status: SCSI Status Error > (probe0:umass-sim1:1:0:0): SCSI Status: Check Condition > (probe0:umass-sim1:1:0:0): UNIT ATTENTION asc:28,0 > (probe0:umass-sim1:1:0:0): Not ready to ready change, medium may have > changed (probe0:umass-sim1:1:0:0): Retrying Command (per Sense Data) > da1 at umass-sim1 bus 1 target 0 lun 0 > da1: Removable Direct Access SCSI-0 device > da1: 1.000MB/s transfers > da1: 964MB (1974272 512 byte sectors: 64H 32S/T 964C) >=20 >=20 >=20 > Another dmesg, booting with storage device and mouse both connected to ba= ck > USB ports. Mouse works, storage doesn't. >=20 > usbus0: 12Mbps Full Speed USB v1.0 > (hw power) control head <=3D 0xcfef1e30 > (hw power) control head =3D> 0x2329000 > usbus1: 12Mbps Full Speed USB v1.0 > (hw power) control head <=3D 0xcfef1e40 > (hw power) control head =3D> 0x4143000 >=20 > >=20 > (hw power) control head <=3D 0x2329000 > (hw power) control head =3D> 0x2329000 > ugen0.2: at usbus0 > ums0: on > usbus0 ums0: 16 buttons and [XYZ] coordinates ID=3D0 > uhid0: on > usbus0 (hw power) control head <=3D 0x2329000 > (hw power) control head =3D> 0x2329000 > (hw power) control head <=3D 0x2329000 > (hw power) control head =3D> 0x2329000 > (hw power) control head <=3D 0x4143000 > (hw power) control head =3D> 0x4143000 > ugen1.2: at usbus1 > umass0: on usbus1 > umass0: SCSI over Bulk-Only; quirks =3D 0x0000 > umass0:1:0:-1: Attached to scbus1 > (hw power) control head <=3D 0x4143000 > (hw power) control head =3D> 0x4143000 > >=20 >=20 > If you need anything else, let me know. >=20 > And thanks for the patch. >=20 That slightly reminds, back earlier I had the board in a different case whe= re=20 the fron port showed some other (better but also not useful) weirdness,=20 propably something to do with the pinout chart. I don't remember exactly. Also, it appears that you are using 1MB capable usb flash on front, 40MB/s = at=20 the rear port? That brings me to the idea, do you have legacy usb enabled i= n=20 bios or not? Cause, when I disable, I get other head power values than with= =20 legacy enabled. Legacy disabled: Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 (hw power) control head <=3D 0x3ed8000 (hw power) control head =3D> 0x3ed8000 usbus1: 12Mbps Full Speed USB v1.0 (hw power) control head <=3D 0x3f28000 (hw power) control head =3D> 0x3f28000 usbus2: 12Mbps Full Speed USB v1.0 (hw power) control head <=3D 0x3f84000 (hw power) control head =3D> 0x3f84000 usbus3: 12Mbps Full Speed USB v1.0 (hw power) control head <=3D 0x3fc3000 (hw power) control head =3D> 0x3fc3000 usbus4: 12Mbps Full Speed USB v1.0 (hw power) control head <=3D 0x2e02000 (hw power) control head =3D> 0x2e02000 Legacy enabled was: Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 (hw power) control head <=3D 0xcfef1690 (hw power) control head =3D> 0x3edf000 usbus1: 12Mbps Full Speed USB v1.0 (hw power) control head <=3D 0x3f27000 (hw power) control head =3D> 0x3f27000 usbus2: 12Mbps Full Speed USB v1.0 (hw power) control head <=3D 0x3f6f000 (hw power) control head =3D> 0x3f6f000 usbus3: 12Mbps Full Speed USB v1.0 (hw power) control head <=3D 0x403a000 (hw power) control head =3D> 0x403a000 usbus4: 12Mbps Full Speed USB v1.0 (hw power) control head <=3D 0x4083000 (hw power) control head =3D> 0x4083000 usbus5: 480Mbps High Speed USB v2.0 From owner-freebsd-usb@FreeBSD.ORG Thu Sep 24 06:38:41 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75191106566B; Thu, 24 Sep 2009 06:38:41 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 836DA8FC15; Thu, 24 Sep 2009 06:38:40 +0000 (UTC) Received: from porto.topspin.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 JAA14917; Thu, 24 Sep 2009 09:38:37 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1MqhyP-000Gtf-7I; Thu, 24 Sep 2009 09:38:37 +0300 Message-ID: <4ABB13EC.3020202@icyb.net.ua> Date: Thu, 24 Sep 2009 09:38:36 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090823) MIME-Version: 1.0 To: =?UTF-8?B?QW5kcml1cyBNb3JrxatuYXM=?= References: <4ABA36B1.9070706@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: sb600/sb700 ohci experimental patch X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 06:38:41 -0000 on 25/09/2009 01:31 Andrius Morkūnas said the following: > usbus0: 12Mbps Full Speed USB v1.0 > (hw power) control head <= 0xcfef1e30 > (hw power) control head => 0x2329000 > usbus1: 12Mbps Full Speed USB v1.0 > (hw power) control head <= 0xcfef1e40 > (hw power) control head => 0x4143000 These were the messages that I looked for the most. > If you need anything else, let me know. > > And thanks for the patch. Thank you very much for the testing and the detailed report! Unfortunately I have no clue about the umass issue. >From comparing attach after boot and attach during boot messages it seems that USB part worked almost identical, it's the CAM part that didn't happen in the second case. BTW, how many ports do you have at the back? If more than 2, could you please try connecting the mouse to a port that is not connected to uhub0 (this could be verified with usbconfig)? And then see if you still get a mouse attachment problem during boot? (No other devices during boot please :-) to simplify the testcase.) -- Andriy Gapon From owner-freebsd-usb@FreeBSD.ORG Thu Sep 24 08:30:47 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57FFC1065693; Thu, 24 Sep 2009 08:30:47 +0000 (UTC) (envelope-from hinokind@gmail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id B00F78FC17; Thu, 24 Sep 2009 08:30:46 +0000 (UTC) Received: by fxm22 with SMTP id 22so1320009fxm.36 for ; Thu, 24 Sep 2009 01:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:to:cc:subject :references:date:mime-version:content-transfer-encoding:from :message-id:in-reply-to:user-agent; bh=9MXhKVsuaDgtGq3Ma5HvFdUNv/Hce+bTgn0G9HGlrFQ=; b=i8GZylLJ3ustkxkhFQNXD7KTVnJoCKUZvz6BYh4cutg4q1QbeYH7G58Ky5YhQfeQlU fJ2d+HpNK+GH57IuJhdIObOIDv9mEW8iMd/pA3C60iB/5s0W8tusJ+nkeCrrDbxQVQYd WxhWRi3ix1b2sGsRZ1SOs0dBrT9L3tOY/DzxI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; b=fbYXHtRPhN712aTAV02CKUTS6hVFoRPG2zV4vNPyaUwxvfFwi5yRFUEHgEudhJOh19 T9/aAsrn9xxRy9qVNFKULQb/+zzTYSxFn/r9pL6EAjo4J5GTT9sErCGQIZkO8yt+tLid 3fKZ47yj55tAhskIBI7zg2SRM/DSpCSmFkIww= Received: by 10.86.238.30 with SMTP id l30mr2760666fgh.75.1253781045661; Thu, 24 Sep 2009 01:30:45 -0700 (PDT) Received: from klevas (hst-17-80.splius.lt [77.79.17.80]) by mx.google.com with ESMTPS id l12sm1194290fgb.19.2009.09.24.01.30.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 24 Sep 2009 01:30:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Andriy Gapon" References: <4ABA36B1.9070706@icyb.net.ua> <4ABB13EC.3020202@icyb.net.ua> Date: Thu, 24 Sep 2009 11:30:40 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: =?utf-8?B?QW5kcml1cyBNb3JrxatuYXM=?= Message-ID: In-Reply-To: <4ABB13EC.3020202@icyb.net.ua> User-Agent: Opera Mail/10.00 (FreeBSD) Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: sb600/sb700 ohci experimental patch X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 08:30:47 -0000 On Thu, 24 Sep 2009 09:38:36 +0300, Andriy Gapon wrote= : > BTW, how many ports do you have at the back? > If more than 2, could you please try connecting the mouse to a port th= at is not > connected to uhub0 (this could be verified with usbconfig)? > And then see if you still get a mouse attachment problem during boot? > (No other devices during boot please :-) to simplify the testcase.) If I have USB Legacy disabled, mouse works in any port (with or without = your patch). When USB Legacy is enabled, without your patch mouse only works = if I unplug and plug it into a different port after boot. With your patch it = works in any port and doesn't care about USB legacy stuff. On Thu, 24 Sep 2009 09:22:28 +0300, Dorian B=C3=BCttner wrote: > Also, it appears that you are using 1MB capable usb flash on front, 40= MB/s at > the rear port? That brings me to the idea, do you have legacy usb enab= led in > bios or not? Cause, when I disable, I get other head power values than= with > legacy enabled. I forgot to mention that my tests were done with USB legacy disabled. No= w I looked at the values with it enabled, but unlike in your case, the value= s are the same in both cases. -- = Andrius From owner-freebsd-usb@FreeBSD.ORG Thu Sep 24 14:51:12 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03713106566B; Thu, 24 Sep 2009 14:51:12 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 3857C8FC13; Thu, 24 Sep 2009 14:51:10 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=et49sEvzLegA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=Hxkus8EOlPmee2Otn8gA:9 a=HZPOj_pWmBhg_LoUYgYA:7 a=oAWoRoMsvHUyuSFcmq_dneDhLCoA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1305994898; Thu, 24 Sep 2009 16:51:09 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Thu, 24 Sep 2009 16:51:46 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <4ABA36B1.9070706@icyb.net.ua> In-Reply-To: <4ABA36B1.9070706@icyb.net.ua> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909241651.47850.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: sb600/sb700 ohci experimental patch X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 14:51:12 -0000 On Wednesday 23 September 2009 16:54:41 Andriy Gapon wrote: > If you have a system with SB600, SB700, etc chipset and you have problems > with low speed USB devices attached during boot (keyboard, mouse), could > you please try the following experimental patch and report back? > I am primarily interested in the first several lines produced during boot > with printfs that are introduced by the patch. Preferably in the context of > surrounding USB-related dmesg messages. No need to report subsequent > same-looking ever-repeating messages (if any). > > WARNING: this is an experimental patch, it is probably not even close to > what a real fix could be, it might not fix the problem (but perhaps it > would), it might introduce instabilities into OHCI driver and it is noisy > (unconditional printf). The primary purpose of this patch is to gather > information necessary for a real fix. > > Thank you! > > diff --git a/sys/dev/usb/controller/ohci.c b/sys/dev/usb/controller/ohci.c > index 30592c1..fb6ba34 100644 > --- a/sys/dev/usb/controller/ohci.c > +++ b/sys/dev/usb/controller/ohci.c > @@ -247,8 +249,8 @@ reset: > OWRITE4(sc, OHCI_INTERRUPT_ENABLE, sc->sc_eintrs | OHCI_MIE); > /* switch on desired functional features */ > ctl = OREAD4(sc, OHCI_CONTROL); > - ctl &= ~(OHCI_CBSR_MASK | OHCI_LES | OHCI_HCFS_MASK | OHCI_IR); > - ctl |= OHCI_PLE | OHCI_IE | OHCI_CLE | OHCI_BLE | > + ctl &= ~(OHCI_CBSR_MASK | OHCI_LES | OHCI_HCFS_MASK | OHCI_IR | OHCI_CLE > | OHCI_CLF); > + ctl |= OHCI_PLE | OHCI_IE | /*OHCI_CLE |*/ OHCI_BLE | > OHCI_RATIO_1_4 | OHCI_HCFS_OPERATIONAL; > /* And finally start it! */ > OWRITE4(sc, OHCI_CONTROL, ctl); > @@ -2727,8 +2729,17 @@ ohci_set_hw_power(struct usb_bus *bus) > temp = OREAD4(sc, OHCI_CONTROL); > temp &= ~(OHCI_PLE | OHCI_IE | OHCI_CLE | OHCI_BLE); > > - if (flags & USB_HW_POWER_CONTROL) > + if (flags & USB_HW_POWER_CONTROL) { > + struct usb_page_search buf_res; > + > + buf_res.physaddr = OREAD4(sc, OHCI_CONTROL_HEAD_ED); > + printf("(hw power) control head <= %p\n", (void*)buf_res.physaddr); > + usbd_get_page(&sc->sc_hw.ctrl_start_pc, 0, &buf_res); > + printf("(hw power) control head => %p\n", (void*)buf_res.physaddr); > + OWRITE4(sc, OHCI_CONTROL_HEAD_ED, buf_res.physaddr); > + > temp |= OHCI_CLE; > + } > > if (flags & USB_HW_POWER_BULK) > temp |= OHCI_BLE; Hi, Your patch looks good. Send me the final version when it is ready and testers report OK. I will then review and commit it. I think that if you need to reload the control head, you will also need to reload the other head list pointers? Could you check that? --HPS From owner-freebsd-usb@FreeBSD.ORG Fri Sep 25 06:34:27 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B7AE106566C; Fri, 25 Sep 2009 06:34:27 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0B1988FC0A; Fri, 25 Sep 2009 06:34:25 +0000 (UTC) Received: from porto.topspin.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 JAA10554; Fri, 25 Sep 2009 09:34:23 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Mr4Nq-000LWg-OZ; Fri, 25 Sep 2009 09:34:22 +0300 Message-ID: <4ABC646D.4070604@icyb.net.ua> Date: Fri, 25 Sep 2009 09:34:21 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090823) MIME-Version: 1.0 To: Hans Petter Selasky References: <4ABA36B1.9070706@icyb.net.ua> <200909241651.47850.hselasky@c2i.net> In-Reply-To: <200909241651.47850.hselasky@c2i.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: sb600/sb700 ohci experimental patch X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 06:34:27 -0000 on 24/09/2009 17:51 Hans Petter Selasky said the following: > > Your patch looks good. Send me the final version when it is ready and testers > report OK. I will then review and commit it. > > I think that if you need to reload the control head, you will also need to > reload the other head list pointers? Could you check that? I am just thinking that maybe there is a more clever / proper approach to fixing this. I did some additional debugging, maybe you'd find this interesting. First debugging setup: diff --git a/sys/dev/usb/controller/ohci.c b/sys/dev/usb/controller/ohci.c index fb6ba34..83cb4bb 100644 --- a/sys/dev/usb/controller/ohci.c +++ b/sys/dev/usb/controller/ohci.c @@ -80,6 +80,8 @@ __FBSDID("$FreeBSD$"); #ifdef USB_DEBUG static int ohcidebug = 0; +extern devclass_t ohci_devclass; /* XXX */ + SYSCTL_NODE(_hw_usb, OID_AUTO, ohci, CTLFLAG_RW, 0, "USB ohci"); SYSCTL_INT(_hw_usb_ohci, OID_AUTO, debug, CTLFLAG_RW, &ohcidebug, 0, "ohci debug level"); @@ -227,9 +229,9 @@ reset: return (USB_ERR_IOERROR); } #ifdef USB_DEBUG - if (ohcidebug > 15) { +// if (ohcidebug > 15) { ohci_dumpregs(sc); - } +// } #endif /* The controller is now in SUSPEND state, we have 2ms to finish. */ @@ -286,8 +289,15 @@ reset: } #ifdef USB_DEBUG - if (ohcidebug > 5) { +// if (ohcidebug > 5) { ohci_dumpregs(sc); +// } + int unit = device_get_unit(sc->sc_dev); + if (unit != 0) { + DPRINTFN(0, "dump of ohci0 regs:\n"); + sc = devclass_get_softc(ohci_devclass, 0); + if (sc != NULL) + ohci_dumpregs(sc); } #endif return (USB_ERR_NORMAL_COMPLETION); diff --git a/sys/dev/usb/controller/ohci_pci.c b/sys/dev/usb/controller/ohci_pci.c index 3be6e42..755a90b 100644 --- a/sys/dev/usb/controller/ohci_pci.c +++ b/sys/dev/usb/controller/ohci_pci.c @@ -400,7 +400,7 @@ static driver_t ohci_driver = .size = sizeof(struct ohci_softc), }; -static devclass_t ohci_devclass; +devclass_t ohci_devclass; /* XXX */ DRIVER_MODULE(ohci, pci, ohci_driver, ohci_devclass, 0, 0); MODULE_DEPEND(ohci, usb, 1, 1, 1); The idea is to always dump all HW regs just after reset, after HW programming and additionally dump HW regs of ohci0 after each of the subsequent controllers gets programmed. So, now the results: ohci0: mem 0xfe02e000-0xfe02efff irq 16 at device 18.0 on pci0 ohci0: [ITHREAD] ohci_dumpregs:540: ohci_dumpregs: rev=0x00000110 control=0x000000c0 command=0x00000000 ohci_dumpregs:544: intrstat=0x00000040 intre=0x00000000 intrd=0x00000000 ohci_dumpregs:548: hcca=0x00000000 percur=0x00000000 ctrlhd=0x00000000 ohci_dumpregs:552: ctrlcur=0x00000000 bulkhd=0x00000000 bulkcur=0x00000000 ohci_dumpregs:556: done=0x00000000 fmival=0x00002edf fmrem=0x00000000 ohci_dumpregs:560: fmnum=0x00000000 perst=0x00000000 lsthrs=0x00000628 ohci_dumpregs:564: desca=0x02000b03 descb=0x00000000 stat=0x00000000 ohci_dumpregs:567: port1=0x00010301 port2=0x00000100 ohci_dumpregs:573: HCCA: frame_number=0x0000 done_head=0x00000000 ohci_dumpregs:540: ohci_dumpregs: rev=0x00000110 control=0x000000af command=0x00000000 ohci_dumpregs:544: intrstat=0x00000044 intre=0x8000005a intrd=0x8000005a ohci_dumpregs:548: hcca=0x0304b000 percur=0x00000000 ctrlhd=0x03082000 ohci_dumpregs:552: ctrlcur=0x00000000 bulkhd=0x03083000 bulkcur=0x00000000 ohci_dumpregs:556: done=0x00000000 fmival=0xa7782edf fmrem=0x800013dd ohci_dumpregs:560: fmnum=0x0000000d perst=0x00002a2f lsthrs=0x00000628 ohci_dumpregs:564: desca=0x02000b03 descb=0x00000000 stat=0x00000000 ohci_dumpregs:567: port1=0x00010301 port2=0x00000100 ohci_dumpregs:573: HCCA: frame_number=0x000e done_head=0x00000000 usbus0: on ohci0 ohci1: mem 0xfe02d000-0xfe02dfff irq 16 at device 18.1 on pci0 ohci1: [ITHREAD] ohci_dumpregs:540: ohci_dumpregs: rev=0x00000110 control=0x000000c0 command=0x00000000 ohci_dumpregs:544: intrstat=0x00000000 intre=0x00000000 intrd=0x00000000 ohci_dumpregs:548: hcca=0x00000000 percur=0x00000000 ctrlhd=0x00000000 ohci_dumpregs:552: ctrlcur=0x00000000 bulkhd=0x00000000 bulkcur=0x00000000 ohci_dumpregs:556: done=0x00000000 fmival=0x00002edf fmrem=0x00000000 ohci_dumpregs:560: fmnum=0x00000000 perst=0x00000000 lsthrs=0x00000628 ohci_dumpregs:564: desca=0x02000b03 descb=0x00000000 stat=0x00000000 ohci_dumpregs:567: port1=0x00000100 port2=0x00000100 ohci_dumpregs:573: HCCA: frame_number=0x0000 done_head=0x00000000 ohci_dumpregs:540: ohci_dumpregs: rev=0x00000110 control=0x000000af command=0x00000000 ohci_dumpregs:544: intrstat=0x00000004 intre=0x8000005a intrd=0x8000005a ohci_dumpregs:548: hcca=0x030a8000 percur=0x00000000 ctrlhd=0x030a9000 ohci_dumpregs:552: ctrlcur=0x00000000 bulkhd=0x030b1000 bulkcur=0x00000000 ohci_dumpregs:556: done=0x00000000 fmival=0xa7782edf fmrem=0x800013d5 ohci_dumpregs:560: fmnum=0x0000000d perst=0x00002a2f lsthrs=0x00000628 ohci_dumpregs:564: desca=0x02000b03 descb=0x00000000 stat=0x00000000 ohci_dumpregs:567: port1=0x00000100 port2=0x00000100 ohci_dumpregs:573: HCCA: frame_number=0x000e done_head=0x00000000 ohci_controller_init:297: dump of ohci0 regs: ohci_dumpregs:540: ohci_dumpregs: rev=0x00000110 control=0x000000af command=0x00000000 ohci_dumpregs:544: intrstat=0x00000004 intre=0x8000005a intrd=0x8000005a ohci_dumpregs:548: hcca=0x0304b000 percur=0x00000000 ctrlhd=0xbfdf1c50 ohci_dumpregs:552: ctrlcur=0x00000000 bulkhd=0x03083000 bulkcur=0x00000000 ohci_dumpregs:556: done=0xbfdf1ca0 fmival=0xa7782edf fmrem=0x80002e51 ohci_dumpregs:560: fmnum=0x0000019f perst=0x00002a2f lsthrs=0x00000628 ohci_dumpregs:564: desca=0x02000b03 descb=0x00000000 stat=0x00000000 ohci_dumpregs:567: port1=0x00000303 port2=0x00000100 ohci_dumpregs:573: HCCA: frame_number=0x019f done_head=0x00000000 So, as expected, reset does clear the registers, programming does set them correctly. But as soon as we are done programming ohci1, ctrlhd of ohci0 gets re-programmed to 0xbfdf1c50. BTW, to answer your question, other lists seem to be unaffected, head/cur values seem to be preserved intact. hcca register is also OK. Not sure how to interpret this. Either a timing issue, i.e. the register gets over-written some time after we program it. Or perhaps a bug in SMM code, i.e. when we generate an SMI (e.g. while doing ohci1 takeover) SMM code erroneously writes something to ohci0 ctrlhead. Or something else... :) -- Andriy Gapon From owner-freebsd-usb@FreeBSD.ORG Fri Sep 25 07:28:14 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FAA6106566B; Fri, 25 Sep 2009 07:28:14 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swipnet.se [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 9C3CC8FC0A; Fri, 25 Sep 2009 07:28:13 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=et49sEvzLegA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=rnr42OFa6D61SBmgBJgA:9 a=4WR7OQmbq8TQ_UFqknlD0LXuybAA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1140675727; Fri, 25 Sep 2009 09:28:11 +0200 From: Hans Petter Selasky To: Andriy Gapon Date: Fri, 25 Sep 2009 09:28:50 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <4ABA36B1.9070706@icyb.net.ua> <200909241651.47850.hselasky@c2i.net> <4ABC646D.4070604@icyb.net.ua> In-Reply-To: <4ABC646D.4070604@icyb.net.ua> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909250928.51515.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: sb600/sb700 ohci experimental patch X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 07:28:14 -0000 On Friday 25 September 2009 08:34:21 Andriy Gapon wrote: > Not sure how to interpret this. In ohci_controller_init() try to disable the DPRINTF("SMM active, request owner change\n"); part of the code for !(ohci_unit == 0) or (ohci_unit == 2) and see what happens. Your clue might also indicate that we should request owner change for all OHCI's before resetting any of them. Possibly a BIOS bug! --HPS From owner-freebsd-usb@FreeBSD.ORG Fri Sep 25 08:11:50 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F5481065694; Fri, 25 Sep 2009 08:11:50 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2EA4F8FC18; Fri, 25 Sep 2009 08:11:48 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA12289; Fri, 25 Sep 2009 11:11:41 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4ABC7B3C.6090803@icyb.net.ua> Date: Fri, 25 Sep 2009 11:11:40 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: "Svein Skogen (listmail account)" References: <4ABA36B1.9070706@icyb.net.ua> <200909241651.47850.hselasky@c2i.net> <4ABC646D.4070604@icyb.net.ua> <4ABC7912.6070301@stillbilde.net> In-Reply-To: <4ABC7912.6070301@stillbilde.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: sb600/sb700 ohci experimental patch X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 08:11:50 -0000 on 25/09/2009 11:02 Svein Skogen (listmail account) said the following: > Andriy Gapon wrote: >> on 24/09/2009 17:51 Hans Petter Selasky said the following: > > *SNIP!* > >> Not sure how to interpret this. >> Either a timing issue, i.e. the register gets over-written some time after we >> program it. >> Or perhaps a bug in SMM code, i.e. when we generate an SMI (e.g. while doing >> ohci1 takeover) SMM code erroneously writes something to ohci0 ctrlhead. >> Or something else... :) > > Could it be related to "USB Legacy Devices" in bios, and thus be the > same problem that was discussed recently (regarding HZ larger than 1000)? > > An usb-legacy setup might explain both the register-changing _AND_ the > timing issue... It very well could, but... We do perform proper OHCI takeover, so we don't expect firmware to mess with the controllers after it is finished. Also, I personally have everything "USB legacy" disabled in my BIOS ("USB Legacy Support", "USB Keyboard support", "USB Mouse support"). Although, Gigabyte BIOSes are known to be sometimes smarter than they appear and to "autodetect" things when they are explicitly turned off in settings. Last point. Explaining is half the job. Fixing / working around is the other half. P.S. I am not sure what "timing issue" you referred to. -- Andriy Gapon From owner-freebsd-usb@FreeBSD.ORG Fri Sep 25 08:18:06 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53F6A1065676 for ; Fri, 25 Sep 2009 08:18:06 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from mail.stillbilde.net (d80.iso100.no [81.175.61.195]) by mx1.freebsd.org (Postfix) with ESMTP id 118FF8FC1D for ; Fri, 25 Sep 2009 08:18:05 +0000 (UTC) Received: from [192.168.4.2] (unknown [192.168.4.2]) (Authenticated sender: svein) by mail.stillbilde.net (Familien Skogens mail) with ESMTPSA id F3C3F56; Fri, 25 Sep 2009 10:02:27 +0200 (CEST) Message-ID: <4ABC7912.6070301@stillbilde.net> Date: Fri, 25 Sep 2009 10:02:26 +0200 From: "Svein Skogen (listmail account)" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andriy Gapon References: <4ABA36B1.9070706@icyb.net.ua> <200909241651.47850.hselasky@c2i.net> <4ABC646D.4070604@icyb.net.ua> In-Reply-To: <4ABC646D.4070604@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: sb600/sb700 ohci experimental patch X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 08:18:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andriy Gapon wrote: > on 24/09/2009 17:51 Hans Petter Selasky said the following: *SNIP!* > > Not sure how to interpret this. > Either a timing issue, i.e. the register gets over-written some time after we > program it. > Or perhaps a bug in SMM code, i.e. when we generate an SMI (e.g. while doing > ohci1 takeover) SMM code erroneously writes something to ohci0 ctrlhead. > Or something else... :) Could it be related to "USB Legacy Devices" in bios, and thus be the same problem that was discussed recently (regarding HZ larger than 1000)? An usb-legacy setup might explain both the register-changing _AND_ the timing issue... //Svein - -- - --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg Østli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE - --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq8eREACgkQODUnwSLUlKS6QgCeM/4e26Hs8VeBnfySo/cKpxNQ RYsAnA6Cu72Rb4by0VTQ98DwLURdaZ79 =Urht -----END PGP SIGNATURE----- From owner-freebsd-usb@FreeBSD.ORG Fri Sep 25 08:22:24 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8DCB1065693; Fri, 25 Sep 2009 08:22:24 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from mail.stillbilde.net (d80.iso100.no [81.175.61.195]) by mx1.freebsd.org (Postfix) with ESMTP id 64CD18FC1F; Fri, 25 Sep 2009 08:22:24 +0000 (UTC) Received: from [192.168.4.5] (unknown [192.168.4.5]) (Authenticated sender: svein) by mail.stillbilde.net (Familien Skogens mail) with ESMTPSA id ACB0F56; Fri, 25 Sep 2009 10:22:25 +0200 (CEST) Message-ID: <4ABC7DBF.30607@stillbilde.net> Date: Fri, 25 Sep 2009 10:22:23 +0200 From: "Svein Skogen (listmail account)" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andriy Gapon References: <4ABA36B1.9070706@icyb.net.ua> <200909241651.47850.hselasky@c2i.net> <4ABC646D.4070604@icyb.net.ua> <4ABC7912.6070301@stillbilde.net> <4ABC7B3C.6090803@icyb.net.ua> In-Reply-To: <4ABC7B3C.6090803@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: sb600/sb700 ohci experimental patch X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 08:22:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andriy Gapon wrote: > on 25/09/2009 11:02 Svein Skogen (listmail account) said the following: >> Andriy Gapon wrote: >>> on 24/09/2009 17:51 Hans Petter Selasky said the following: >> *SNIP!* >> >>> Not sure how to interpret this. >>> Either a timing issue, i.e. the register gets over-written some time after we >>> program it. >>> Or perhaps a bug in SMM code, i.e. when we generate an SMI (e.g. while doing >>> ohci1 takeover) SMM code erroneously writes something to ohci0 ctrlhead. >>> Or something else... :) >> Could it be related to "USB Legacy Devices" in bios, and thus be the >> same problem that was discussed recently (regarding HZ larger than 1000)? >> >> An usb-legacy setup might explain both the register-changing _AND_ the >> timing issue... > > It very well could, but... > > We do perform proper OHCI takeover, so we don't expect firmware to mess with the > controllers after it is finished. > > Also, I personally have everything "USB legacy" disabled in my BIOS ("USB Legacy > Support", "USB Keyboard support", "USB Mouse support"). Although, Gigabyte BIOSes > are known to be sometimes smarter than they appear and to "autodetect" things when > they are explicitly turned off in settings. > > Last point. Explaining is half the job. Fixing / working around is the other half. > > P.S. I am not sure what "timing issue" you referred to. http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051812.html //Svein - -- - --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg Østli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE - --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq8fb8ACgkQODUnwSLUlKSqXQCgiIvShHz0AoLx7U5M3v29hgHc 5egAnjdPqAQdWeVxx26oZiKxXdLsW0vl =hcEc -----END PGP SIGNATURE----- From owner-freebsd-usb@FreeBSD.ORG Fri Sep 25 09:47:30 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4008C106566C for ; Fri, 25 Sep 2009 09:47:30 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id C1D128FC08 for ; Fri, 25 Sep 2009 09:47:28 +0000 (UTC) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n8P9CCAP013684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 25 Sep 2009 18:42:12 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: avg@icyb.net.ua Date: Fri, 25 Sep 2009 18:41:53 +0930 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2418065.sghOnb65vu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200909251842.08223.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-usb@freebsd.org Subject: sb600/sb700 ohci experimental patch X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 09:47:30 -0000 --nextPart2418065.sghOnb65vu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline This patch works for me, I get.. usbus0: 12Mbps Full Speed USB v1.0 (hw power) control head <=3D 0xcfdf1c50 (hw power) control head =3D> 0x3f7a000 usbus1: 12Mbps Full Speed USB v1.0 (hw power) control head <=3D 0x3dd6000 (hw power) control head =3D> 0x3dd6000 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 (hw power) control head <=3D 0x2961000 (hw power) control head =3D> 0x2961000 usbus4: 12Mbps Full Speed USB v1.0 (hw power) control head <=3D 0x29a9000 (hw power) control head =3D> 0x29a9000 usbus5: 480Mbps High Speed USB v2.0 usbus6: 12Mbps Full Speed USB v1.0 (hw power) control head <=3D 0x41de000 (hw power) control head =3D> 0x41de000 =2E.. uhub2: 6 ports with 6 removable, self powered uhub5: 6 ports with 6 removable, self powered (hw power) control head <=3D 0x3f7a000 (hw power) control head =3D> 0x3f7a000 ugen0.2: at usbus0 ums0: = on usbus0 ums0: 8 buttons and [XYZ] coordinates ID=3D0 (hw power) control head <=3D 0x3f7a000 (hw power) control head =3D> 0x3f7a000 (hw power) control head <=3D 0x3f7a000 (hw power) control head =3D> 0x3f7a000 (hw power) control head <=3D 0x3f7a000 (hw power) control head =3D> 0x3f7a000 Thanks! :) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2418065.sghOnb65vu Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBKvIlo5ZPcIHs/zowRAlzUAJ9Rx6xKPoBy0n2MAVBYqn0ylVVHIwCeKKsu PF7AW3bkAxJXznxkw6syEdw= =n2yp -----END PGP SIGNATURE----- --nextPart2418065.sghOnb65vu-- From owner-freebsd-usb@FreeBSD.ORG Fri Sep 25 16:20:04 2009 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10D15106566C for ; Fri, 25 Sep 2009 16:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DAE9B8FC16 for ; Fri, 25 Sep 2009 16:20:03 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8PGK3xE096605 for ; Fri, 25 Sep 2009 16:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8PGK3Gn096604; Fri, 25 Sep 2009 16:20:03 GMT (envelope-from gnats) Date: Fri, 25 Sep 2009 16:20:03 GMT Message-Id: <200909251620.n8PGK3Gn096604@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Graham Todd Cc: Subject: Re: usb/79269: [ohci] USB ohci da0 plug/unplug causes crashes and lockups. X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Graham Todd List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 16:20:04 -0000 The following reply was made to PR usb/79269; it has been noted by GNATS. From: Graham Todd To: bug-followup@FreeBSD.org, murray_baker@ihug.com.au Cc: Subject: Re: usb/79269: [ohci] USB ohci da0 plug/unplug causes crashes and lockups. Date: Fri, 25 Sep 2009 12:12:41 -0400 At least one release with improvements in USB robustness has occurred since the report. As well, the FreeBSD Foundation sponsored project to fix the long standing USB mass storage panic. Is this bug a duplicate of usb/46176? Can it be closed? From owner-freebsd-usb@FreeBSD.ORG Fri Sep 25 17:08:52 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B9861065672; Fri, 25 Sep 2009 17:08:52 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id EB8E98FC19; Fri, 25 Sep 2009 17:08:51 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=spRtIwgkR_kA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=TxFuUoO8vUBO-65CmaAA:9 a=yjnYa-nRA7_IFHc2aAS2W4QeLVUA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1321085496; Fri, 25 Sep 2009 19:08:50 +0200 Received-SPF: softfail receiver=mailfe02.swip.net; client-ip=188.126.201.140; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Date: Fri, 25 Sep 2009 19:09:30 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909251909.31503.hselasky@freebsd.org> Cc: Subject: Polling support for USB serial port adapters X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 17:08:52 -0000 Hi, At EuroBSDcon 2009 I was requested to add support for polling mode to the USB serial port adapters alike UKBD and UMASS. Which USB serial port adapters should have this support at first? And I also need someone to volunteers testing this! --HPS From owner-freebsd-usb@FreeBSD.ORG Fri Sep 25 17:26:55 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC0EE106568D; Fri, 25 Sep 2009 17:26:55 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 50C3B8FC22; Fri, 25 Sep 2009 17:26:55 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id DFEDE1CD41; Fri, 25 Sep 2009 19:26:53 +0200 (CEST) Date: Fri, 25 Sep 2009 19:26:53 +0200 From: Ed Schouten To: Hans Petter Selasky Message-ID: <20090925172653.GT95398@hoeg.nl> References: <200909251909.31503.hselasky@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1Rp7a2AgasIge6Lv" Content-Disposition: inline In-Reply-To: <200909251909.31503.hselasky@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Polling support for USB serial port adapters X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 17:26:55 -0000 --1Rp7a2AgasIge6Lv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Hans, * Hans Petter Selasky wrote: > At EuroBSDcon 2009 I was requested to add support for polling mode to the= USB=20 > serial port adapters alike UKBD and UMASS. >=20 > Which USB serial port adapters should have this support at first? And I a= lso=20 > need someone to volunteers testing this! I guess uplcom and uftdi are the most common ones, right? --=20 Ed Schouten WWW: http://80386.nl/ --1Rp7a2AgasIge6Lv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkq8/V0ACgkQ52SDGA2eCwXyewCfTMQvBLOFSVu4iCzvnD8pFMvA wz4AnAgxJSaKbO/Pak31cYFPd6ixotKs =4TyI -----END PGP SIGNATURE----- --1Rp7a2AgasIge6Lv-- From owner-freebsd-usb@FreeBSD.ORG Fri Sep 25 18:36:13 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBFDE106566B; Fri, 25 Sep 2009 18:36:13 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7DB3E8FC2C; Fri, 25 Sep 2009 18:36:13 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n8PIWSoZ013693; Fri, 25 Sep 2009 14:32:28 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200909251832.n8PIWSoZ013693@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Sep 2009 14:36:35 -0400 To: Hans Petter Selasky , freebsd-current@freebsd.org, freebsd-usb@freebsd.org From: Mike Tancsa In-Reply-To: <200909251909.31503.hselasky@freebsd.org> References: <200909251909.31503.hselasky@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: Polling support for USB serial port adapters X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 18:36:13 -0000 At 01:09 PM 9/25/2009, Hans Petter Selasky wrote: >Hi, > >At EuroBSDcon 2009 I was requested to add support for polling mode to the USB >serial port adapters alike UKBD and UMASS. > >Which USB serial port adapters should have this support at first? And I also >need someone to volunteers testing this! uftdi is the most common around here. I have a couple of manufacturers that I would be happy to try in some high speed and low speed apps. ---Mike From owner-freebsd-usb@FreeBSD.ORG Fri Sep 25 18:53:24 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 460E71065672; Fri, 25 Sep 2009 18:53:24 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (gloom.rink.nu [213.34.49.2]) by mx1.freebsd.org (Postfix) with ESMTP id 09ACC8FC0C; Fri, 25 Sep 2009 18:53:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id 69A246D423; Fri, 25 Sep 2009 20:34:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.2]) by localhost (gloom.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7itq6oNH8JC; Fri, 25 Sep 2009 20:34:03 +0200 (CEST) Received: by mx1.rink.nu (Postfix, from userid 1000) id C56046D41E; Fri, 25 Sep 2009 20:34:03 +0200 (CEST) Date: Fri, 25 Sep 2009 20:34:03 +0200 From: Rink Springer To: Ed Schouten Message-ID: <20090925183403.GA6563@rink.nu> References: <200909251909.31503.hselasky@freebsd.org> <20090925172653.GT95398@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090925172653.GT95398@hoeg.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, Hans Petter Selasky , freebsd-usb@freebsd.org Subject: Re: Polling support for USB serial port adapters X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 18:53:24 -0000 On Fri, Sep 25, 2009 at 07:26:53PM +0200, Ed Schouten wrote: > * Hans Petter Selasky wrote: > > At EuroBSDcon 2009 I was requested to add support for polling mode to the USB > > serial port adapters alike UKBD and UMASS. > > > > Which USB serial port adapters should have this support at first? And I also > > need someone to volunteers testing this! > > I guess uplcom and uftdi are the most common ones, right? Yeah, these are very easy to obtain; in any case, I would start with these. Regards, -- Rink P.W. Springer - http://rink.nu "Beauty often seduces us on the road to truth." - Dr. Wilson From owner-freebsd-usb@FreeBSD.ORG Fri Sep 25 20:40:02 2009 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF8661065670 for ; Fri, 25 Sep 2009 20:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8B9E18FC22 for ; Fri, 25 Sep 2009 20:40:02 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8PKe24X076733 for ; Fri, 25 Sep 2009 20:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8PKe2IU076732; Fri, 25 Sep 2009 20:40:02 GMT (envelope-from gnats) Resent-Date: Fri, 25 Sep 2009 20:40:02 GMT Resent-Message-Id: <200909252040.n8PKe2IU076732@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-usb@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Olivier Cochard-Labbe Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEEA9106566B for ; Fri, 25 Sep 2009 20:38:15 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 9C8F38FC14 for ; Fri, 25 Sep 2009 20:38:15 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n8PKcECr066088 for ; Fri, 25 Sep 2009 20:38:14 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n8PKcEch066064; Fri, 25 Sep 2009 20:38:14 GMT (envelope-from nobody) Message-Id: <200909252038.n8PKcEch066064@www.freebsd.org> Date: Fri, 25 Sep 2009 20:38:14 GMT From: Olivier Cochard-Labbe To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: usb/139142: [regression] ehci drivers (NVIDIA nForce4 USB 2.0 controller ) not working with 8.0-RC1 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 20:40:02 -0000 >Number: 139142 >Category: usb >Synopsis: [regression] ehci drivers (NVIDIA nForce4 USB 2.0 controller ) not working with 8.0-RC1 >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Sep 25 20:40:02 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Olivier Cochard-Labbe >Release: 8.0 RC1 >Organization: FreeNAS/BSDRP >Environment: >Description: I meet a problem since 8.0 Beta1 to 8.0-RC1 (amd64 and i386) on an Asus K8N4-E Deluxe motherboard: During the kernel load, my system hang (no dump, no error message). The last messages are (hand copy) in verbose mode: ohci0: irq 21 at device 2.0 on pci0 ohci0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80000000 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x80000000 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 49 ohci0: [MPSAFE] ohci0: [ITHREAD] usbus0: SMM does not respond, resetting usbus0: reset timeout ohci0: USB init failed device_attach: ohci0 attach returned 6 ehci0: irq 22 at device 2.1 on pci0 ehci0: Lazy allocation of 0x4000 bytes rid 0x10 type 3 at 0x80000000 ehci0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0x80000000 ioapci0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 49 ehci0: [MPSAFE] ehci0: [ITHREAD] If I disable the USB 2.0 controller in the BIOS: The system can continue to load the kernel. The ehci drivers works great with FreeBSD 7.2: The file attached include the dmesg and pciconf -lv under FreeBSD 7.2. Thanks, >How-To-Repeat: Using 8.0-RC1 on an Asus K8N4-E Delux motherboard >Fix: Disable USB 2.0 controller in the BIOS. Patch attached with submission follows: [olivier@dev64]~>dmesg Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:14:35 UTC 2009 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3000+ (2010.31-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20fc2 Stepping = 2 Features=0x78bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x1 usable memory = 2134417408 (2035 MB) avail memory = 2058027008 (1962 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xd3003000-0xd3003fff irq 21 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 6.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd800-0xd80f mem 0xd3002000-0xd3002fff irq 22 at device 7.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc400-0xc40f mem 0xd3001000-0xd3001fff irq 23 at device 8.0 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] pcib1: at device 9.0 on pci0 pci5: on pcib1 nfe0: port 0xb000-0xb007 mem 0xd3000000-0xd3000fff irq 21 at device 10.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 15 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe0: Ethernet address: 00:13:d4:d6:3a:7b nfe0: [FILTER] pcib2: at device 11.0 on pci0 pci4: on pcib2 pcib3: at device 12.0 on pci0 pci3: on pcib3 pcib4: at device 13.0 on pci0 pci2: on pcib4 pcib5: at device 14.0 on pci0 pci1: on pcib5 vgapci0: mem 0xd0000000-0xd0ffffff,0xc0000000-0xcfffffff,0xd1000000-0xd1ffffff irq 18 at device 0.0 on pci1 acpi_tz0: on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] cpu0: on acpi0 acpi_throttle0: on cpu0 powernow0: on cpu0 orm0: at iomem 0xd0000-0xd3fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 uhub1: on uhub0 uhub1: 2 ports with 1 removable, bus powered ukbd0: on uhub1 kbd2 at ukbd0 uhid0: on uhub1 ums0: on uhub1 ums0: 3 buttons and Z dir. Timecounter "TSC" frequency 2010312369 Hz quality 800 Timecounters tick every 1.000 msec ad0: 286168MB at ata0-master UDMA100 ad8: 953869MB at ata4-master SATA150 GEOM: ad0: the secondary GPT table is corrupt or invalid. GEOM: ad0: using the primary only -- recovery suggested. GEOM_LABEL: Label for provider ad0p1 is ufsid/477f45096d16161b. GEOM_LABEL: Label for provider ad0p1 is ufs/Disque1. GEOM_LABEL: Label for provider ad0s1a is ufsid/4a675b954a5764b7. GEOM_LABEL: Label for provider ad8p1 is ufsid/499c8ec590cbe4cd. GEOM_LABEL: Label for provider ad8p1 is ufs/1TB3. Trying to mount root from ufs:/dev/ad0s1a GEOM_LABEL: Label ufs/Disque1 removed. GEOM_LABEL: Label ufsid/477f45096d16161b removed. GEOM_LABEL: Label ufsid/4a675b954a5764b7 removed. GEOM_LABEL: Label for provider ad0s1a is ufsid/4a675b954a5764b7. GEOM_LABEL: Label ufsid/4a675b954a5764b7 removed. GEOM_LABEL: Label ufsid/499c8ec590cbe4cd removed. WARNING: /mnt was not properly dismounted kqemu version 0x00010400 kqemu: KQEMU installed, max_locked_mem=1042196kB. [olivier@dev64]~>pciconf -lv none0@pci0:0:0:0: class=0x058000 card=0x815a1043 chip=0x005e10de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce4 Memory Controller' class = memory isab0@pci0:0:1:0: class=0x060100 card=0x815a1043 chip=0x005010de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce4 PCI to ISA Bridge' class = bridge subclass = PCI-ISA none1@pci0:0:1:1: class=0x0c0500 card=0x815a1043 chip=0x005210de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce4 SMBus' class = serial bus subclass = SMBus ohci0@pci0:0:2:0: class=0x0c0310 card=0x815a1043 chip=0x005a10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce4 USB Controller' class = serial bus subclass = USB atapci0@pci0:0:6:0: class=0x01018a card=0x815a1043 chip=0x005310de rev=0xf2 hdr=0x00 vendor = 'Nvidia Corp' device = 'NVidia nForce 4 SLI IDE Controller' class = mass storage subclass = ATA atapci1@pci0:0:7:0: class=0x010185 card=0x815a1043 chip=0x005410de rev=0xf3 hdr=0x00 vendor = 'Nvidia Corp' device = 'NVidia nForce 4 SLI IDE Controller' class = mass storage subclass = ATA atapci2@pci0:0:8:0: class=0x010185 card=0x815a1043 chip=0x005510de rev=0xf3 hdr=0x00 vendor = 'Nvidia Corp' device = 'NVidia nForce 4 SLI IDE Controller' class = mass storage subclass = ATA pcib1@pci0:0:9:0: class=0x060401 card=0x00000000 chip=0x005c10de rev=0xa2 hdr=0x01 vendor = 'Nvidia Corp' device = 'nForce4 PCI Bridge' class = bridge subclass = PCI-PCI nfe0@pci0:0:10:0: class=0x068000 card=0x81411043 chip=0x005710de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce4 Ultra NVidia Network Bus Enumerator' class = bridge pcib2@pci0:0:11:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xa3 hdr=0x01 vendor = 'Nvidia Corp' device = 'nForce4 PCIe Bridge' class = bridge subclass = PCI-PCI pcib3@pci0:0:12:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xa3 hdr=0x01 vendor = 'Nvidia Corp' device = 'nForce4 PCIe Bridge' class = bridge subclass = PCI-PCI pcib4@pci0:0:13:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xa3 hdr=0x01 vendor = 'Nvidia Corp' device = 'nForce4 PCIe Bridge' class = bridge subclass = PCI-PCI pcib5@pci0:0:14:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xa3 hdr=0x01 vendor = 'Nvidia Corp' device = 'nForce4 PCIe Bridge' class = bridge subclass = PCI-PCI hostb0@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb1@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron Address Map' class = bridge subclass = HOST-PCI hostb2@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron DRAM Controller' class = bridge subclass = HOST-PCI hostb3@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron Miscellaneous Control' class = bridge subclass = HOST-PCI vgapci0@pci0:1:0:0: class=0x030000 card=0x00000000 chip=0x01d310de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'GeForce 7300 SE' class = display subclass = VGA >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-usb@FreeBSD.ORG Fri Sep 25 21:28:21 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C5E0106568B; Fri, 25 Sep 2009 21:28:21 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id 488968FC1B; Fri, 25 Sep 2009 21:28:21 +0000 (UTC) Received: by syn.atarininja.org (Postfix, from userid 1001) id E486B5C2D; Fri, 25 Sep 2009 17:12:57 -0400 (EDT) Date: Fri, 25 Sep 2009 17:12:57 -0400 From: Wesley Shields To: Hans Petter Selasky Message-ID: <20090925211257.GA17421@atarininja.org> References: <200909251909.31503.hselasky@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200909251909.31503.hselasky@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Polling support for USB serial port adapters X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 21:28:21 -0000 On Fri, Sep 25, 2009 at 07:09:30PM +0200, Hans Petter Selasky wrote: > Hi, > > At EuroBSDcon 2009 I was requested to add support for polling mode to the USB > serial port adapters alike UKBD and UMASS. > > Which USB serial port adapters should have this support at first? And I also > need someone to volunteers testing this! I have a device I just plugged in for the first time ever and it is apparently a uftdi device. I'd be willing to test any patches you have. -- WXS From owner-freebsd-usb@FreeBSD.ORG Fri Sep 25 23:42:10 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EC591065670 for ; Fri, 25 Sep 2009 23:42:10 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id E1B058FC14 for ; Fri, 25 Sep 2009 23:42:09 +0000 (UTC) Received: (qmail 22389 invoked from network); 25 Sep 2009 23:15:28 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.45.64) by acm.poly.edu with AES256-SHA encrypted SMTP; 25 Sep 2009 23:15:28 -0000 Message-ID: <4ABD4EDF.4040807@acm.poly.edu> Date: Fri, 25 Sep 2009 19:14:39 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.23 (X11/20090910) MIME-Version: 1.0 To: Hans Petter Selasky References: <200909251909.31503.hselasky@freebsd.org> In-Reply-To: <200909251909.31503.hselasky@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Polling support for USB serial port adapters X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 23:42:10 -0000 Hans Petter Selasky wrote: > Hi, > > At EuroBSDcon 2009 I was requested to add support for polling mode to the USB > serial port adapters alike UKBD and UMASS. > > Which USB serial port adapters should have this support at first? And I also > need someone to volunteers testing this! > > --HPS > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > We have a bunch of uplcom adapters, and I can test patches. -Boris From owner-freebsd-usb@FreeBSD.ORG Sat Sep 26 02:56:10 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC53D106566C; Sat, 26 Sep 2009 02:56:10 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from roadkill.tharned.org (roadkill.tharned.org [75.145.12.185]) by mx1.freebsd.org (Postfix) with ESMTP id 713528FC0A; Sat, 26 Sep 2009 02:56:10 +0000 (UTC) Received: from blue.tharned.org (blue.tharned.org [10.10.10.8]) (authenticated bits=0) by roadkill.tharned.org (8.14.3/8.14.3) with ESMTP id n8Q2YA3t082110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Sep 2009 21:34:10 -0500 (CDT) (envelope-from gcr+freebsd-current@tharned.org) Date: Fri, 25 Sep 2009 21:34:09 -0500 (CDT) From: Greg Rivers To: Hans Petter Selasky In-Reply-To: <200909251909.31503.hselasky@freebsd.org> Message-ID: References: <200909251909.31503.hselasky@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (roadkill.tharned.org [75.145.12.185]); Fri, 25 Sep 2009 21:34:10 -0500 (CDT) Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Polling support for USB serial port adapters X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2009 02:56:10 -0000 On Fri, 25 Sep 2009, Hans Petter Selasky wrote: > At EuroBSDcon 2009 I was requested to add support for polling mode to > the USB serial port adapters alike UKBD and UMASS. > > Which USB serial port adapters should have this support at first? And I > also need someone to volunteers testing this! > I'd be happy to test the umct driver that you repaired last week. Thanks again for that. I've been trying to use the recently added VirtualBox serial pass-through feature with the umct driver to allow a program running in a Windows guest OS to load data onto an old GPS, but no luck. Might it be the lack of polling support that prevents this from working? -- Greg Rivers From owner-freebsd-usb@FreeBSD.ORG Sat Sep 26 04:53:20 2009 Return-Path: Delivered-To: usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DDC81065670 for ; Sat, 26 Sep 2009 04:53:20 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 006238FC0C for ; Sat, 26 Sep 2009 04:53:19 +0000 (UTC) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id n8Q4ON7H013338 for ; Sat, 26 Sep 2009 12:24:23 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id n8Q4ONc3013337 for usb@freebsd.org; Sat, 26 Sep 2009 12:24:23 +0800 (KRAST) (envelope-from eugen) Date: Sat, 26 Sep 2009 12:24:23 +0800 From: Eugene Grosbein To: usb@freebsd.org Message-ID: <20090926042423.GA12216@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: 8.0-RC1: AMD CS5536 (Geode) USB 2.0 controller strange behavour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2009 04:53:20 -0000 Hi! I have got fanless computer named NICE 3120, it is based on EBC 420-LX8 motherboard and AMD Geode LX800 processor. I've installed 8.0-RC1 here and it runs just fine as a router using internal CompactFlash 256Mb card. Now I'm trying to use USB 2.0 HDD that gives me stable 27 megabyte/sec write speed to /dev/da0 using dd when connected to another 8.0-RC1 system with ICH7 but with this CS5536 its behavour is very strange. "dd if=/dev/zero bs=256k of=/dev/da0 count=100" may result in 1.7MBytes/s or 16Mbytes/s or 400Kbyte/s (sic!) write speed. dd measures speed right, very often it writes way too slow. "systat -vm 1" shows that most of time nothing is written in process; then suddenly lots of bytes are written, then it sits idle again for long time. As for timecounting, kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-1000000) ACPI-safe is non-functional here (3 seconds for 30 minutes of real time), so I use TSC, it works just fine. I've tried i8254 but found no differences. Ntpd drift is about 148.331 for both of TSC and i8254 and ntpd keeps time correct. "pciconf -lv" shows for EHCI: ehci0@pci0:0:15:5: class=0x0c0320 card=0x20951022 chip=0x20951022 rev=0x02 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'CS5536 EHCI USB Host Controller (CS5536)' class = serial bus subclass = USB This machine is used as home router only and I'm ready to debug. Remote access is available on request. The kernel is built with options: machine i386 cpu I586_CPU cpu I686_CPU options NO_F00F_HACK options CPU_GEODE options CPU_SOEKRIS options SCHED_ULE options PREEMPTION $ dmesg -a | fgrep -i Geode CPU: Geode(TM) Integrated Processor by AMD PCS (499.90-MHz 586-class CPU) glxsb0: mem 0xef010000-0xef013fff at device 1.2 on pci0 ehci0: mem 0xef018000-0xef018fff irq 10 at device 15.5 on pci0 usbus1: on ehci0 $ sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-1000000) kern.timecounter.hardware: TSC kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 4294967295 kern.timecounter.tc.i8254.counter: 3806 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-safe.mask: 16777215 kern.timecounter.tc.ACPI-safe.counter: 4294967295 kern.timecounter.tc.ACPI-safe.frequency: 3579545 kern.timecounter.tc.ACPI-safe.quality: 850 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 1502810203 kern.timecounter.tc.TSC.frequency: 499904675 kern.timecounter.tc.TSC.quality: 800 kern.timecounter.invariant_tsc: 0 Please help. Eugene Grosbein From owner-freebsd-usb@FreeBSD.ORG Sat Sep 26 07:08:15 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F14E1065672 for ; Sat, 26 Sep 2009 07:08:15 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id F41C48FC08 for ; Sat, 26 Sep 2009 07:08:14 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=pZqXNPWrx7QA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=MSF5SMQSjKHbHzp52YAA:9 a=jeZ5L_81YZZv4xmzEhHHWQgU1kQA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1210872101; Sat, 26 Sep 2009 09:08:10 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Sat, 26 Sep 2009 09:08:46 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20090926042423.GA12216@svzserv.kemerovo.su> In-Reply-To: <20090926042423.GA12216@svzserv.kemerovo.su> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909260908.48389.hselasky@c2i.net> Cc: Eugene Grosbein Subject: Re: 8.0-RC1: AMD CS5536 (Geode) USB 2.0 controller strange behavour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2009 07:08:15 -0000 On Saturday 26 September 2009 06:24:23 Eugene Grosbein wrote: > Hi! > > I have got fanless computer named NICE 3120, > it is based on EBC 420-LX8 motherboard and AMD Geode LX800 processor. > > I've installed 8.0-RC1 here and it runs just fine as a router > using internal CompactFlash 256Mb card. Now I'm trying to use USB 2.0 HDD > that gives me stable 27 megabyte/sec > write speed to /dev/da0 using dd when connected to another 8.0-RC1 system > with ICH7 but with this CS5536 its behavour is very strange. > > "dd if=/dev/zero bs=256k of=/dev/da0 count=100" may result in 1.7MBytes/s > or 16Mbytes/s or 400Kbyte/s (sic!) write speed. dd measures speed right, > very often it writes way too slow. Hi, Try using bs=65536 Any difference. Output from "usbconfig" would also be nice. Might sound like your device is sometimes connected at FULL speed. Have you taken spin-up time into account? --HPS From owner-freebsd-usb@FreeBSD.ORG Sat Sep 26 07:16:09 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32BF6106566C for ; Sat, 26 Sep 2009 07:16:09 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swip.net [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 2ABB08FC18 for ; Sat, 26 Sep 2009 07:16:07 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=f3GbyprX-2wA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=s9oXJcMGAAAA:8 a=n9D7W5_RIkdjBLTowpwA:9 a=Sb43M3VFQ6GaTgJ5qdYA:7 a=J3PU8QErd1OTnL0elY-hdEFKEr0A:4 a=f6O2YbFhSxR-Tgj0:21 a=Hi_pn8sU99XHxWJt:21 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1141124834; Sat, 26 Sep 2009 09:16:04 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Sat, 26 Sep 2009 09:16:43 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200909252038.n8PKcEch066064@www.freebsd.org> In-Reply-To: <200909252038.n8PKcEch066064@www.freebsd.org> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909260916.45106.hselasky@c2i.net> Cc: Olivier Cochard-Labbe , freebsd-gnats-submit@freebsd.org Subject: Re: usb/139142: [regression] ehci drivers (NVIDIA nForce4 USB 2.0 controller ) not working with 8.0-RC1 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2009 07:16:09 -0000 On Friday 25 September 2009 22:38:14 Olivier Cochard-Labbe wrote: > >Number: 139142 > >Category: usb > >Synopsis: [regression] ehci drivers (NVIDIA nForce4 USB 2.0 > > controller ) not working with 8.0-RC1 Confidential: no > >Severity: serious > >Priority: low > >Responsible: freebsd-usb > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Fri Sep 25 20:40:02 UTC 2009 > >Closed-Date: > >Last-Modified: > >Originator: Olivier Cochard-Labbe > >Release: 8.0 RC1 > >Organization: > > FreeNAS/BSDRP > > >Environment: > >Description: > > I meet a problem since 8.0 Beta1 to 8.0-RC1 (amd64 and i386) on an Asus > K8N4-E Deluxe motherboard: > > During the kernel load, my system hang (no dump, no error message). > The last messages are (hand copy) in verbose mode: > > ohci0: irq 21 at device 2.0 on pci0 > ohci0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80000000 > ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x80000000 > ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 49 > ohci0: [MPSAFE] > ohci0: [ITHREAD] > usbus0: SMM does not respond, resetting > usbus0: reset timeout > ohci0: USB init failed > device_attach: ohci0 attach returned 6 > ehci0: irq 22 at device 2.1 on pci0 > ehci0: Lazy allocation of 0x4000 bytes rid 0x10 type 3 at 0x80000000 > ehci0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0x80000000 > ioapci0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 49 > ehci0: [MPSAFE] > ehci0: [ITHREAD] > > If I disable the USB 2.0 controller in the BIOS: The system can > continue to load the kernel. > > The ehci drivers works great with FreeBSD 7.2: The file attached include > the dmesg and pciconf -lv under FreeBSD 7.2. > > Thanks, > > >How-To-Repeat: > > Using 8.0-RC1 on an Asus K8N4-E Delux motherboard > > >Fix: > > Disable USB 2.0 controller in the BIOS. > > Patch attached with submission follows: > > [olivier@dev64]~>dmesg > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:14:35 UTC 2009 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(tm) 64 Processor 3000+ (2010.31-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x20fc2 Stepping = 2 > > Features=0x78bfbff,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> Features2=0x1 > AMD Features=0xe2500800 > AMD Features2=0x1 > usable memory = 2134417408 (2035 MB) > avail memory = 2058027008 (1962 MB) > ACPI APIC Table: > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 7fef0000 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.0 (no driver attached) > isab0: at device 1.0 on pci0 > isa0: on isab0 > pci0: at device 1.1 (no driver attached) > ohci0: mem 0xd3003000-0xd3003fff irq 21 at > device 2.0 on pci0 ohci0: [GIANT-LOCKED] > ohci0: [ITHREAD] > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 10 ports with 10 removable, self powered > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 6.0 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > atapci1: port > 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd800-0xd80f mem > 0xd3002000-0xd3002fff irq 22 at device 7.0 on pci0 atapci1: [ITHREAD] > ata2: on atapci1 > ata2: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > atapci2: port > 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc400-0xc40f mem > 0xd3001000-0xd3001fff irq 23 at device 8.0 on pci0 atapci2: [ITHREAD] > ata4: on atapci2 > ata4: [ITHREAD] > ata5: on atapci2 > ata5: [ITHREAD] > pcib1: at device 9.0 on pci0 > pci5: on pcib1 > nfe0: port 0xb000-0xb007 mem > 0xd3000000-0xd3000fff irq 21 at device 10.0 on pci0 miibus0: on > nfe0 > e1000phy0: PHY 15 on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, > auto nfe0: Ethernet address: 00:13:d4:d6:3a:7b > nfe0: [FILTER] > pcib2: at device 11.0 on pci0 > pci4: on pcib2 > pcib3: at device 12.0 on pci0 > pci3: on pcib3 > pcib4: at device 13.0 on pci0 > pci2: on pcib4 > pcib5: at device 14.0 on pci0 > pci1: on pcib5 > vgapci0: mem > 0xd0000000-0xd0ffffff,0xc0000000-0xcfffffff,0xd1000000-0xd1ffffff irq 18 at > device 0.0 on pci1 acpi_tz0: on acpi0 > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 sio0: type 16550A > sio0: [FILTER] > cpu0: on acpi0 > acpi_throttle0: on cpu0 > powernow0: on cpu0 > orm0: at iomem 0xd0000-0xd3fff on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > ppc0: cannot reserve I/O port range > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > uhub1: on uhub0 > uhub1: 2 ports with 1 removable, bus powered > ukbd0: on uhub1 > kbd2 at ukbd0 > uhid0: on uhub1 > ums0: > on uhub1 ums0: 3 buttons and Z dir. > Timecounter "TSC" frequency 2010312369 Hz quality 800 > Timecounters tick every 1.000 msec > ad0: 286168MB at ata0-master UDMA100 > ad8: 953869MB at ata4-master SATA150 > GEOM: ad0: the secondary GPT table is corrupt or invalid. > GEOM: ad0: using the primary only -- recovery suggested. > GEOM_LABEL: Label for provider ad0p1 is ufsid/477f45096d16161b. > GEOM_LABEL: Label for provider ad0p1 is ufs/Disque1. > GEOM_LABEL: Label for provider ad0s1a is ufsid/4a675b954a5764b7. > GEOM_LABEL: Label for provider ad8p1 is ufsid/499c8ec590cbe4cd. > GEOM_LABEL: Label for provider ad8p1 is ufs/1TB3. > Trying to mount root from ufs:/dev/ad0s1a > GEOM_LABEL: Label ufs/Disque1 removed. > GEOM_LABEL: Label ufsid/477f45096d16161b removed. > GEOM_LABEL: Label ufsid/4a675b954a5764b7 removed. > GEOM_LABEL: Label for provider ad0s1a is ufsid/4a675b954a5764b7. > GEOM_LABEL: Label ufsid/4a675b954a5764b7 removed. > GEOM_LABEL: Label ufsid/499c8ec590cbe4cd removed. > WARNING: /mnt was not properly dismounted > kqemu version 0x00010400 > kqemu: KQEMU installed, max_locked_mem=1042196kB. > [olivier@dev64]~>pciconf -lv > none0@pci0:0:0:0: class=0x058000 card=0x815a1043 chip=0x005e10de rev=0xa3 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'nForce4 Memory Controller' > class = memory > isab0@pci0:0:1:0: class=0x060100 card=0x815a1043 chip=0x005010de rev=0xa3 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'nForce4 PCI to ISA Bridge' > class = bridge > subclass = PCI-ISA > none1@pci0:0:1:1: class=0x0c0500 card=0x815a1043 chip=0x005210de rev=0xa2 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'nForce4 SMBus' > class = serial bus > subclass = SMBus > ohci0@pci0:0:2:0: class=0x0c0310 card=0x815a1043 chip=0x005a10de rev=0xa2 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'nForce4 USB Controller' > class = serial bus > subclass = USB > atapci0@pci0:0:6:0: class=0x01018a card=0x815a1043 chip=0x005310de rev=0xf2 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'NVidia nForce 4 SLI IDE Controller' > class = mass storage > subclass = ATA > atapci1@pci0:0:7:0: class=0x010185 card=0x815a1043 chip=0x005410de rev=0xf3 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'NVidia nForce 4 SLI IDE Controller' > class = mass storage > subclass = ATA > atapci2@pci0:0:8:0: class=0x010185 card=0x815a1043 chip=0x005510de rev=0xf3 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'NVidia nForce 4 SLI IDE Controller' > class = mass storage > subclass = ATA > pcib1@pci0:0:9:0: class=0x060401 card=0x00000000 chip=0x005c10de rev=0xa2 > hdr=0x01 vendor = 'Nvidia Corp' > device = 'nForce4 PCI Bridge' > class = bridge > subclass = PCI-PCI > nfe0@pci0:0:10:0: class=0x068000 card=0x81411043 chip=0x005710de rev=0xa3 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'nForce4 Ultra NVidia Network Bus Enumerator' > class = bridge > pcib2@pci0:0:11:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xa3 > hdr=0x01 vendor = 'Nvidia Corp' > device = 'nForce4 PCIe Bridge' > class = bridge > subclass = PCI-PCI > pcib3@pci0:0:12:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xa3 > hdr=0x01 vendor = 'Nvidia Corp' > device = 'nForce4 PCIe Bridge' > class = bridge > subclass = PCI-PCI > pcib4@pci0:0:13:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xa3 > hdr=0x01 vendor = 'Nvidia Corp' > device = 'nForce4 PCIe Bridge' > class = bridge > subclass = PCI-PCI > pcib5@pci0:0:14:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xa3 > hdr=0x01 vendor = 'Nvidia Corp' > device = 'nForce4 PCIe Bridge' > class = bridge > subclass = PCI-PCI > hostb0@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 > hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' > device = '(K8) Athlon 64/Opteron HyperTransport Technology > Configuration' class = bridge > subclass = HOST-PCI > hostb1@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 > hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' > device = '(K8) Athlon 64/Opteron Address Map' > class = bridge > subclass = HOST-PCI > hostb2@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 > hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' > device = '(K8) Athlon 64/Opteron DRAM Controller' > class = bridge > subclass = HOST-PCI > hostb3@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 > hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' > device = '(K8) Athlon 64/Opteron Miscellaneous Control' > class = bridge > subclass = HOST-PCI > vgapci0@pci0:1:0:0: class=0x030000 card=0x00000000 chip=0x01d310de rev=0xa1 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'GeForce 7300 SE' > class = display > subclass = VGA > > >Release-Note: > >Audit-Trail: > >Unformatted: Have you tried only disabling USB Legacy support? There is another USB related thread going on: "sb600/sb700 ohci experimental patch" on -current. Have you tried any patches from there? diff --git a/sys/dev/usb/controller/ohci.c b/sys/dev/usb/controller/ohci.c index 30592c1..fb6ba34 100644 --- a/sys/dev/usb/controller/ohci.c +++ b/sys/dev/usb/controller/ohci.c @@ -247,8 +249,8 @@ reset: OWRITE4(sc, OHCI_INTERRUPT_ENABLE, sc->sc_eintrs | OHCI_MIE); /* switch on desired functional features */ ctl = OREAD4(sc, OHCI_CONTROL); - ctl &= ~(OHCI_CBSR_MASK | OHCI_LES | OHCI_HCFS_MASK | OHCI_IR); - ctl |= OHCI_PLE | OHCI_IE | OHCI_CLE | OHCI_BLE | + ctl &= ~(OHCI_CBSR_MASK | OHCI_LES | OHCI_HCFS_MASK | OHCI_IR | OHCI_CLE | OHCI_CLF); + ctl |= OHCI_PLE | OHCI_IE | /*OHCI_CLE |*/ OHCI_BLE | OHCI_RATIO_1_4 | OHCI_HCFS_OPERATIONAL; /* And finally start it! */ OWRITE4(sc, OHCI_CONTROL, ctl); @@ -2727,8 +2729,17 @@ ohci_set_hw_power(struct usb_bus *bus) temp = OREAD4(sc, OHCI_CONTROL); temp &= ~(OHCI_PLE | OHCI_IE | OHCI_CLE | OHCI_BLE); - if (flags & USB_HW_POWER_CONTROL) + if (flags & USB_HW_POWER_CONTROL) { + struct usb_page_search buf_res; + + buf_res.physaddr = OREAD4(sc, OHCI_CONTROL_HEAD_ED); + printf("(hw power) control head <= %p\n", (void*)buf_res.physaddr); + usbd_get_page(&sc->sc_hw.ctrl_start_pc, 0, &buf_res); + printf("(hw power) control head => %p\n", (void*)buf_res.physaddr); + OWRITE4(sc, OHCI_CONTROL_HEAD_ED, buf_res.physaddr); + temp |= OHCI_CLE; + } --HPS From owner-freebsd-usb@FreeBSD.ORG Sat Sep 26 08:17:44 2009 Return-Path: Delivered-To: usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E3321065695 for ; Sat, 26 Sep 2009 08:17:44 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id EE35E8FC1C for ; Sat, 26 Sep 2009 08:17:43 +0000 (UTC) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id n8Q8HY4g024369; Sat, 26 Sep 2009 16:17:34 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id n8Q8HXLX024368; Sat, 26 Sep 2009 16:17:33 +0800 (KRAST) (envelope-from eugen) Date: Sat, 26 Sep 2009 16:17:33 +0800 From: Eugene Grosbein To: usb@freebsd.org Message-ID: <20090926081733.GA24121@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200909260908.48389.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: 8.0-RC1: AMD CS5536 (Geode) USB 2.0 controller strange behavour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2009 08:17:44 -0000 > Try using bs=65536 > Any difference. Not better. > Output from "usbconfig" would also be nice %usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON HDD has only one cable connection, so it is powered from USB. > Have you taken spin-up time into account? I made severals tests in a row, speed varies greatly stiil. And there is no such problem with ICH7-based system (975XBX motherboard). Please CC: me as I'm not in list. Eugene Grosbein From owner-freebsd-usb@FreeBSD.ORG Sat Sep 26 08:20:06 2009 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6261D1065670 for ; Sat, 26 Sep 2009 08:20:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 474F38FC16 for ; Sat, 26 Sep 2009 08:20:06 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8Q8K5x7035640 for ; Sat, 26 Sep 2009 08:20:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8Q8K5s3035639; Sat, 26 Sep 2009 08:20:05 GMT (envelope-from gnats) Date: Sat, 26 Sep 2009 08:20:05 GMT Message-Id: <200909260820.n8Q8K5s3035639@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Hans Petter Selasky Cc: Subject: Re: usb/139142: [regression] ehci drivers (NVIDIA nForce4 USB 2.0 controller ) not working with 8.0-RC1 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Hans Petter Selasky List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2009 08:20:06 -0000 The following reply was made to PR usb/139142; it has been noted by GNATS. From: Hans Petter Selasky To: freebsd-usb@freebsd.org Cc: "Olivier Cochard-Labbe" , freebsd-gnats-submit@freebsd.org Subject: Re: usb/139142: [regression] ehci drivers (NVIDIA nForce4 USB 2.0 controller ) not working with 8.0-RC1 Date: Sat, 26 Sep 2009 09:16:43 +0200 On Friday 25 September 2009 22:38:14 Olivier Cochard-Labbe wrote: > >Number: 139142 > >Category: usb > >Synopsis: [regression] ehci drivers (NVIDIA nForce4 USB 2.0 > > controller ) not working with 8.0-RC1 Confidential: no > >Severity: serious > >Priority: low > >Responsible: freebsd-usb > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Fri Sep 25 20:40:02 UTC 2009 > >Closed-Date: > >Last-Modified: > >Originator: Olivier Cochard-Labbe > >Release: 8.0 RC1 > >Organization: > > FreeNAS/BSDRP > > >Environment: > >Description: > > I meet a problem since 8.0 Beta1 to 8.0-RC1 (amd64 and i386) on an Asus > K8N4-E Deluxe motherboard: > > During the kernel load, my system hang (no dump, no error message). > The last messages are (hand copy) in verbose mode: > > ohci0: irq 21 at device 2.0 on pci0 > ohci0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80000000 > ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x80000000 > ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 49 > ohci0: [MPSAFE] > ohci0: [ITHREAD] > usbus0: SMM does not respond, resetting > usbus0: reset timeout > ohci0: USB init failed > device_attach: ohci0 attach returned 6 > ehci0: irq 22 at device 2.1 on pci0 > ehci0: Lazy allocation of 0x4000 bytes rid 0x10 type 3 at 0x80000000 > ehci0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0x80000000 > ioapci0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 49 > ehci0: [MPSAFE] > ehci0: [ITHREAD] > > If I disable the USB 2.0 controller in the BIOS: The system can > continue to load the kernel. > > The ehci drivers works great with FreeBSD 7.2: The file attached include > the dmesg and pciconf -lv under FreeBSD 7.2. > > Thanks, > > >How-To-Repeat: > > Using 8.0-RC1 on an Asus K8N4-E Delux motherboard > > >Fix: > > Disable USB 2.0 controller in the BIOS. > > Patch attached with submission follows: > > [olivier@dev64]~>dmesg > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:14:35 UTC 2009 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(tm) 64 Processor 3000+ (2010.31-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x20fc2 Stepping = 2 > > Features=0x78bfbff,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> Features2=0x1 > AMD Features=0xe2500800 > AMD Features2=0x1 > usable memory = 2134417408 (2035 MB) > avail memory = 2058027008 (1962 MB) > ACPI APIC Table: > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 7fef0000 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.0 (no driver attached) > isab0: at device 1.0 on pci0 > isa0: on isab0 > pci0: at device 1.1 (no driver attached) > ohci0: mem 0xd3003000-0xd3003fff irq 21 at > device 2.0 on pci0 ohci0: [GIANT-LOCKED] > ohci0: [ITHREAD] > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 10 ports with 10 removable, self powered > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 6.0 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > atapci1: port > 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd800-0xd80f mem > 0xd3002000-0xd3002fff irq 22 at device 7.0 on pci0 atapci1: [ITHREAD] > ata2: on atapci1 > ata2: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > atapci2: port > 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc400-0xc40f mem > 0xd3001000-0xd3001fff irq 23 at device 8.0 on pci0 atapci2: [ITHREAD] > ata4: on atapci2 > ata4: [ITHREAD] > ata5: on atapci2 > ata5: [ITHREAD] > pcib1: at device 9.0 on pci0 > pci5: on pcib1 > nfe0: port 0xb000-0xb007 mem > 0xd3000000-0xd3000fff irq 21 at device 10.0 on pci0 miibus0: on > nfe0 > e1000phy0: PHY 15 on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, > auto nfe0: Ethernet address: 00:13:d4:d6:3a:7b > nfe0: [FILTER] > pcib2: at device 11.0 on pci0 > pci4: on pcib2 > pcib3: at device 12.0 on pci0 > pci3: on pcib3 > pcib4: at device 13.0 on pci0 > pci2: on pcib4 > pcib5: at device 14.0 on pci0 > pci1: on pcib5 > vgapci0: mem > 0xd0000000-0xd0ffffff,0xc0000000-0xcfffffff,0xd1000000-0xd1ffffff irq 18 at > device 0.0 on pci1 acpi_tz0: on acpi0 > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 sio0: type 16550A > sio0: [FILTER] > cpu0: on acpi0 > acpi_throttle0: on cpu0 > powernow0: on cpu0 > orm0: at iomem 0xd0000-0xd3fff on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > ppc0: cannot reserve I/O port range > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > uhub1: on uhub0 > uhub1: 2 ports with 1 removable, bus powered > ukbd0: on uhub1 > kbd2 at ukbd0 > uhid0: on uhub1 > ums0: > on uhub1 ums0: 3 buttons and Z dir. > Timecounter "TSC" frequency 2010312369 Hz quality 800 > Timecounters tick every 1.000 msec > ad0: 286168MB at ata0-master UDMA100 > ad8: 953869MB at ata4-master SATA150 > GEOM: ad0: the secondary GPT table is corrupt or invalid. > GEOM: ad0: using the primary only -- recovery suggested. > GEOM_LABEL: Label for provider ad0p1 is ufsid/477f45096d16161b. > GEOM_LABEL: Label for provider ad0p1 is ufs/Disque1. > GEOM_LABEL: Label for provider ad0s1a is ufsid/4a675b954a5764b7. > GEOM_LABEL: Label for provider ad8p1 is ufsid/499c8ec590cbe4cd. > GEOM_LABEL: Label for provider ad8p1 is ufs/1TB3. > Trying to mount root from ufs:/dev/ad0s1a > GEOM_LABEL: Label ufs/Disque1 removed. > GEOM_LABEL: Label ufsid/477f45096d16161b removed. > GEOM_LABEL: Label ufsid/4a675b954a5764b7 removed. > GEOM_LABEL: Label for provider ad0s1a is ufsid/4a675b954a5764b7. > GEOM_LABEL: Label ufsid/4a675b954a5764b7 removed. > GEOM_LABEL: Label ufsid/499c8ec590cbe4cd removed. > WARNING: /mnt was not properly dismounted > kqemu version 0x00010400 > kqemu: KQEMU installed, max_locked_mem=1042196kB. > [olivier@dev64]~>pciconf -lv > none0@pci0:0:0:0: class=0x058000 card=0x815a1043 chip=0x005e10de rev=0xa3 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'nForce4 Memory Controller' > class = memory > isab0@pci0:0:1:0: class=0x060100 card=0x815a1043 chip=0x005010de rev=0xa3 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'nForce4 PCI to ISA Bridge' > class = bridge > subclass = PCI-ISA > none1@pci0:0:1:1: class=0x0c0500 card=0x815a1043 chip=0x005210de rev=0xa2 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'nForce4 SMBus' > class = serial bus > subclass = SMBus > ohci0@pci0:0:2:0: class=0x0c0310 card=0x815a1043 chip=0x005a10de rev=0xa2 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'nForce4 USB Controller' > class = serial bus > subclass = USB > atapci0@pci0:0:6:0: class=0x01018a card=0x815a1043 chip=0x005310de rev=0xf2 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'NVidia nForce 4 SLI IDE Controller' > class = mass storage > subclass = ATA > atapci1@pci0:0:7:0: class=0x010185 card=0x815a1043 chip=0x005410de rev=0xf3 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'NVidia nForce 4 SLI IDE Controller' > class = mass storage > subclass = ATA > atapci2@pci0:0:8:0: class=0x010185 card=0x815a1043 chip=0x005510de rev=0xf3 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'NVidia nForce 4 SLI IDE Controller' > class = mass storage > subclass = ATA > pcib1@pci0:0:9:0: class=0x060401 card=0x00000000 chip=0x005c10de rev=0xa2 > hdr=0x01 vendor = 'Nvidia Corp' > device = 'nForce4 PCI Bridge' > class = bridge > subclass = PCI-PCI > nfe0@pci0:0:10:0: class=0x068000 card=0x81411043 chip=0x005710de rev=0xa3 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'nForce4 Ultra NVidia Network Bus Enumerator' > class = bridge > pcib2@pci0:0:11:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xa3 > hdr=0x01 vendor = 'Nvidia Corp' > device = 'nForce4 PCIe Bridge' > class = bridge > subclass = PCI-PCI > pcib3@pci0:0:12:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xa3 > hdr=0x01 vendor = 'Nvidia Corp' > device = 'nForce4 PCIe Bridge' > class = bridge > subclass = PCI-PCI > pcib4@pci0:0:13:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xa3 > hdr=0x01 vendor = 'Nvidia Corp' > device = 'nForce4 PCIe Bridge' > class = bridge > subclass = PCI-PCI > pcib5@pci0:0:14:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xa3 > hdr=0x01 vendor = 'Nvidia Corp' > device = 'nForce4 PCIe Bridge' > class = bridge > subclass = PCI-PCI > hostb0@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 > hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' > device = '(K8) Athlon 64/Opteron HyperTransport Technology > Configuration' class = bridge > subclass = HOST-PCI > hostb1@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 > hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' > device = '(K8) Athlon 64/Opteron Address Map' > class = bridge > subclass = HOST-PCI > hostb2@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 > hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' > device = '(K8) Athlon 64/Opteron DRAM Controller' > class = bridge > subclass = HOST-PCI > hostb3@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 > hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' > device = '(K8) Athlon 64/Opteron Miscellaneous Control' > class = bridge > subclass = HOST-PCI > vgapci0@pci0:1:0:0: class=0x030000 card=0x00000000 chip=0x01d310de rev=0xa1 > hdr=0x00 vendor = 'Nvidia Corp' > device = 'GeForce 7300 SE' > class = display > subclass = VGA > > >Release-Note: > >Audit-Trail: > >Unformatted: Have you tried only disabling USB Legacy support? There is another USB related thread going on: "sb600/sb700 ohci experimental patch" on -current. Have you tried any patches from there? diff --git a/sys/dev/usb/controller/ohci.c b/sys/dev/usb/controller/ohci.c index 30592c1..fb6ba34 100644 --- a/sys/dev/usb/controller/ohci.c +++ b/sys/dev/usb/controller/ohci.c @@ -247,8 +249,8 @@ reset: OWRITE4(sc, OHCI_INTERRUPT_ENABLE, sc->sc_eintrs | OHCI_MIE); /* switch on desired functional features */ ctl = OREAD4(sc, OHCI_CONTROL); - ctl &= ~(OHCI_CBSR_MASK | OHCI_LES | OHCI_HCFS_MASK | OHCI_IR); - ctl |= OHCI_PLE | OHCI_IE | OHCI_CLE | OHCI_BLE | + ctl &= ~(OHCI_CBSR_MASK | OHCI_LES | OHCI_HCFS_MASK | OHCI_IR | OHCI_CLE | OHCI_CLF); + ctl |= OHCI_PLE | OHCI_IE | /*OHCI_CLE |*/ OHCI_BLE | OHCI_RATIO_1_4 | OHCI_HCFS_OPERATIONAL; /* And finally start it! */ OWRITE4(sc, OHCI_CONTROL, ctl); @@ -2727,8 +2729,17 @@ ohci_set_hw_power(struct usb_bus *bus) temp = OREAD4(sc, OHCI_CONTROL); temp &= ~(OHCI_PLE | OHCI_IE | OHCI_CLE | OHCI_BLE); - if (flags & USB_HW_POWER_CONTROL) + if (flags & USB_HW_POWER_CONTROL) { + struct usb_page_search buf_res; + + buf_res.physaddr = OREAD4(sc, OHCI_CONTROL_HEAD_ED); + printf("(hw power) control head <= %p\n", (void*)buf_res.physaddr); + usbd_get_page(&sc->sc_hw.ctrl_start_pc, 0, &buf_res); + printf("(hw power) control head => %p\n", (void*)buf_res.physaddr); + OWRITE4(sc, OHCI_CONTROL_HEAD_ED, buf_res.physaddr); + temp |= OHCI_CLE; + } --HPS From owner-freebsd-usb@FreeBSD.ORG Sat Sep 26 09:53:35 2009 Return-Path: Delivered-To: usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA4801065670 for ; Sat, 26 Sep 2009 09:53:35 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id 6B8CA8FC1B for ; Sat, 26 Sep 2009 09:53:35 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=pZqXNPWrx7QA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=8WmVPGx2yDDg4Yc3a8AA:9 a=8dB6D4_ybVmlcxm04ZYA:7 a=eB58GUQNnT1FEaWaBd3RnKZdKBUA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1210902066; Sat, 26 Sep 2009 10:53:32 +0200 Received-SPF: softfail receiver=mailfe05.swip.net; client-ip=188.126.201.140; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: Eugene Grosbein Date: Sat, 26 Sep 2009 10:54:12 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20090926081733.GA24121@svzserv.kemerovo.su> In-Reply-To: <20090926081733.GA24121@svzserv.kemerovo.su> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909261054.13174.hselasky@freebsd.org> Cc: usb@freebsd.org Subject: Re: 8.0-RC1: AMD CS5536 (Geode) USB 2.0 controller strange behavour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2009 09:53:35 -0000 On Saturday 26 September 2009 10:17:33 Eugene Grosbein wrote: > > Try using bs=65536 > > Any difference. > > Not better. > > > Output from "usbconfig" would also be nice > > %usbconfig > ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) > pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=ON ugen1.2: at usbus1, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=ON > > HDD has only one cable connection, so it is powered from USB. > > > Have you taken spin-up time into account? > > I made severals tests in a row, speed varies greatly stiil. > And there is no such problem with ICH7-based system (975XBX motherboard). Hi, Could you check if these are due to device timeouts in the CAM layer? There is some debugging you can turn on: sysctl hw.usb.umass.debug=-1 Probably it will flood the console. Maybe you could add some prints to /sys/dev/usb/storage/umass.c in all the "default:" cases in the USB callbacks and print out the "error" code. That would quickly indicate if your device has an issue with timing, I.E. that the firmware in the USB device part is hanging. --HPS From owner-freebsd-usb@FreeBSD.ORG Sat Sep 26 15:12:44 2009 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9603106566B; Sat, 26 Sep 2009 15:12:44 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 99D248FC19; Sat, 26 Sep 2009 15:12:44 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 6D847489A2; Sat, 26 Sep 2009 15:55:46 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VRQ3PwwHEZN; Sat, 26 Sep 2009 15:55:35 +0100 (BST) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 48FDE48984; Sat, 26 Sep 2009 15:55:34 +0100 (BST) Message-ID: <4ABE2B4F.6080104@tomjudge.com> Date: Sat, 26 Sep 2009 14:55:11 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 References: <200909251909.31503.hselasky@freebsd.org> <4ABD4EDF.4040807@acm.poly.edu> In-Reply-To: <4ABD4EDF.4040807@acm.poly.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Hans Petter Selasky , freebsd-usb@freebsd.org Subject: Re: Polling support for USB serial port adapters X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2009 15:12:44 -0000 Boris Kochergin wrote: > Hans Petter Selasky wrote: >> Hi, >> >> At EuroBSDcon 2009 I was requested to add support for polling mode to >> the USB serial port adapters alike UKBD and UMASS. >> >> Which USB serial port adapters should have this support at first? And >> I also need someone to volunteers testing this! >> >> --HPS >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> > We have a bunch of uplcom adapters, and I can test patches. > > -Boris > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" +1 for testing uplcom. Tom