From owner-freebsd-usb@FreeBSD.ORG Mon Mar 26 05:03:36 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D263C16A401 for ; Mon, 26 Mar 2007 05:03:36 +0000 (UTC) (envelope-from xistence@0x58.com) Received: from mailexchange.osnn.net (1e.66.5646.static.theplanet.com [70.86.102.30]) by mx1.freebsd.org (Postfix) with SMTP id 7B77713C465 for ; Mon, 26 Mar 2007 05:03:36 +0000 (UTC) (envelope-from xistence@0x58.com) Received: (qmail 80406 invoked by uid 0); 26 Mar 2007 04:27:33 -0000 Received: from unknown (HELO ?10.10.10.22?) (xistence@0x58.com@72.208.132.56) by mailexchange.osnn.net with SMTP; 26 Mar 2007 04:27:33 -0000 Mime-Version: 1.0 (Apple Message framework v752.3) To: freebsd-usb@freebsd.org Message-Id: <7D8AF0B7-6BA9-461A-8CE1-89FE418B46B6@0x58.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--992218753; protocol="application/pkcs7-signature" From: Bert JW Regeer Date: Sun, 25 Mar 2007 21:31:16 -0700 X-Mailer: Apple Mail (2.752.3) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: uhub0: device problem (SET_ADDR_FAILED), disabling port 1 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, 26 Mar 2007 05:03:36 -0000 --Apple-Mail-8--992218753 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I am unable to use any USB devices on my 6.2-RELEASE-p3. I get the following errors: uhub0: device problem (SET_ADDR_FAILED), disabling port 1 uhub2: device problem (SET_ADDR_FAILED), disabling port 2 I have tried with a multitude of USB items: Bluetooth dongle USB da supported mass storage device Web camera Mouse USB is enabled in the BIOS. If any more information is required please let me know. I have been unable to find any answer to this problem using Google, however it seemed that many people had the same issue and never got it resolved. Cheers, Bert JW Regeer keyhole# dmesg Copyright (c) 1992-2007 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 6.2-RELEASE-p3 #0: Mon Mar 19 16:51:04 MST 2007 xistence@keyhole.network.lan:/usr/media/Downloads/obj/usr/src/ sys/KEYHOLE ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 2000+ (1666.74-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383fbff AMD Features=0xc0400800 real memory = 1073676288 (1023 MB) avail memory = 1041674240 (993 MB) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xc0000000-0xcfffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) skc0: port 0x9000-0x90ff mem 0xe3000000-0xe3003fff irq 21 at device 9.0 on pci0 skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x9) sk0: on skc0 sk0: Ethernet address: 00:17:9a:b9:5a:f5 miibus0: on sk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto skc1: port 0x9400-0x94ff mem 0xe3004000-0xe3007fff irq 18 at device 10.0 on pci0 skc1: DGE-530T Gigabit Ethernet Adapter rev. (0x9) sk1: on skc1 sk1: Ethernet address: 00:17:9a:b9:5a:e1 miibus1: on sk1 e1000phy1: on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto ahc0: port 0x9800-0x98ff mem 0xe3008000-0xe3008fff irq 20 at device 12.0 on pci0 ahc0: [GIANT-LOCKED] aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs atapci0: port 0x9c00-0x9c07,0xa000-0xa003,0xa400-0xa407,0xa800-0xa803,0xac00-0xac0f, 0xb000-0xb0ff irq 20 at device 15.0 on pci0 ata2: on atapci0 ata3: on atapci0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xb400-0xb40f at device 15.1 on pci0 ata0: on atapci1 ata1: on atapci1 uhci0: port 0xb800-0xb81f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xbc00-0xbc1f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xc000-0xc01f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xc400-0xc41f irq 21 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xe3009000-0xe30090ff irq 21 at device 16.4 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 vr0: port 0xc800-0xc8ff mem 0xe300a000-0xe300a0ff irq 23 at device 18.0 on pci0 miibus2: on vr0 ukphy0: on miibus2 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:50:2c:a3:84:40 acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] 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 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcefff,0xd8000-0xd87ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] Timecounter "TSC" frequency 1666739742 Hz quality 800 Timecounters tick every 1.000 msec ad0: 78167MB at ata0-master UDMA133 ad1: 38166MB at ata0-slave UDMA100 ad2: 95611MB at ata1-master UDMA133 ad3: 57241MB at ata1-slave UDMA100 ad4: 152627MB at ata2-master UDMA100 ad6: 78167MB at ata3-master UDMA100 Waiting 5 seconds for SCSI devices to settle GEOM_MIRROR: Device home created (id=1379058640). GEOM_MIRROR: Device home: provider ad1 detected. GEOM_CONCAT: Device 160gb created (id=4221988118). GEOM_CONCAT: Disk ad2 attached to 160gb. GEOM_CONCAT: Disk ad3 attached to 160gb. GEOM_CONCAT: Device 160gb activated. GEOM_MIRROR: Device home: provider ad0s1g detected. GEOM_MIRROR: Device home: provider ad0s1g activated. GEOM_MIRROR: Device home: provider ad1 activated. GEOM_MIRROR: Device home: provider mirror/home launched. cd0 at ahc0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-4 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad0s1a bridge0: Ethernet address: fe:7c:b5:72:73:1f Limiting closed port RST response from 223 to 200 packets/sec Limiting closed port RST response from 211 to 200 packets/sec Limiting closed port RST response from 221 to 200 packets/sec vr0: link state changed to UP sk0: link state changed to DOWN sk0: link state changed to UP uhub0: device problem (SET_ADDR_FAILED), disabling port 2 uhub0: device problem (SET_ADDR_FAILED), disabling port 1 uhub2: device problem (SET_ADDR_FAILED), disabling port 2 keyhole# pciconf -l agp0@pci0:0:0: class=0x060000 card=0x31891106 chip=0x31891106 rev=0x80 hdr=0x00 pcib1@pci0:1:0: class=0x060400 card=0x00000080 chip=0xb1981106 rev=0x00 hdr=0x01 skc0@pci0:9:0: class=0x020000 card=0x4b011186 chip=0x4b011186 rev=0x11 hdr=0x00 skc1@pci0:10:0: class=0x020000 card=0x4b011186 chip=0x4b011186 rev=0x11 hdr=0x00 ahc0@pci0:12:0: class=0x010000 card=0x38699004 chip=0x38609004 rev=0x03 hdr=0x00 atapci0@pci0:15:0: class=0x010400 card=0x31491106 chip=0x31491106 rev=0x80 hdr=0x00 atapci1@pci0:15:1: class=0x01018a card=0x05711106 chip=0x05711106 rev=0x06 hdr=0x00 uhci0@pci0:16:0: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0x81 hdr=0x00 uhci1@pci0:16:1: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0x81 hdr=0x00 uhci2@pci0:16:2: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0x81 hdr=0x00 uhci3@pci0:16:3: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0x81 hdr=0x00 ehci0@pci0:16:4: class=0x0c0320 card=0x31041106 chip=0x31041106 rev=0x86 hdr=0x00 isab0@pci0:17:0: class=0x060100 card=0x32271106 chip=0x32271106 rev=0x00 hdr=0x00 vr0@pci0:18:0: class=0x020000 card=0x01021106 chip=0x30651106 rev=0x78 hdr=0x00 none0@pci1:0:0: class=0x030000 card=0x12801682 chip=0x032210de rev=0xa1 hdr=0x00 keyhole# usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), VIA (0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), VIA (0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), VIA (0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb3: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), VIA (0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb4: addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), VIA (0x0000), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered port 7 powered port 8 powered --Apple-Mail-8--992218753-- From owner-freebsd-usb@FreeBSD.ORG Mon Mar 26 11:08:35 2007 Return-Path: X-Original-To: freebsd-usb@FreeBSD.org Delivered-To: freebsd-usb@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B25B016A510 for ; Mon, 26 Mar 2007 11:08:35 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 9B61B13C4AE for ; Mon, 26 Mar 2007 11:08:35 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2QB8Zge049466 for ; Mon, 26 Mar 2007 11:08:35 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2QB8Yck049462 for freebsd-usb@FreeBSD.org; Mon, 26 Mar 2007 11:08:34 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Mar 2007 11:08:34 GMT Message-Id: <200703261108.l2QB8Yck049462@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-usb@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 26 Mar 2007 11:08:35 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o usb/84750 usb [hang] 6-BETA2 reboot/shutdown with root_fs on externa o usb/91629 usb usbd_abort_pipe() may result in infinite loop 2 problems total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o usb/40792 usb signals lead to data loss on device ugen o usb/46176 usb [panic] umass causes kernel panic if device removed be o i386/46371 usb USB controller cannot be initialized on IBM Netfinity f usb/55555 usb [ums] system freezes with access to /dev/ums0 o bin/57255 usb usbd and multi-function devices o usb/62088 usb [usb] Logitech Cordless/Optical Mouse not working o usb/62309 usb [ugen] [panic] panic: ugen(4) driver o usb/63621 usb [usb] USB MemoryStick Reader stalls/crashes system o usb/69006 usb [patch] Apple Cinema Display hangs USB ports o usb/71155 usb [usb] misbehaving usb-printer hangs processes, causes o usb/73307 usb [panic] Kernel panics on USB disconnect o usb/74771 usb [umass] mounting write-protected umass device as read/ o usb/75705 usb [panic] da0 attach / Optio S4 (with backtrace) o usb/75797 usb 5.3-STABLE(2005 1/4) detect USB headset, But can not f f usb/76204 usb panic while using usb attached modem o usb/76395 usb USB printer does not work, usbdevs says "addr 0 should o usb/77184 usb kernel panic on USB device disconnect o usb/77294 usb ucom + ulpcom panic o usb/77940 usb [patch] [panic] insertion of usb keyboard panics syste f i386/78218 usb [kue] kue not detected on Sony PCG-F370 VAIO o usb/78989 usb please add USB keyboard support to install CD's o usb/79140 usb WD Firewire/USB Combo hangs under load on USB interfac o usb/79269 usb USB ohci da0 plug/unplug causes crashes and lockups. o usb/79287 usb UHCI hang after interrupt transfer o usb/79524 usb printing to Minolta PagePro 1[23]xxW via USB fails wit f usb/79656 usb [usb] RHSC interrupts lost o usb/79722 usb [usb] wrong alignments in ehci.h o usb/80040 usb [hang] Use of sound mixer causes system freeze with ua f usb/80260 usb Travan USB tape drive fails to write o usb/80361 usb mounting of usb-stick fails o usb/80373 usb usb keyboard does not respond o usb/80829 usb possible panic when loading USB-modules o usb/80862 usb [patch] USB locking issues: missing some Giant calls o usb/81308 usb [ugen] [patch] polling a ugen(4) control endpoint caus f usb/82198 usb Panic on attaching of ONKI N-338 USB MP3 player f usb/82272 usb Can not recognize Casio camera EX-Z40 as a umass devic o usb/82350 usb [usb] null pointer dereference in USB stack o usb/82520 usb Reboot when USL101 connected o usb/82569 usb [usb] USB mass storage plug/unplug causes system panic o usb/82660 usb EHCI: I/O stuck in state 'physrd'/panic o usb/83504 usb [usb] SpeedTouch USB stop working on recent current (a o usb/83563 usb [panic] Page Fault while detaching Mpman Usb device o usb/83677 usb [usb] usb controller often not detected (Sun W2100z) o usb/83756 usb Microsoft Intellimouse Explorer 4.0A doesn't work. o usb/83977 usb [ucom] [panic] ucom1: open bulk out error (addr 2): IN o usb/84326 usb [umass] Panic trying to connect SCSI tape drive via US o usb/84336 usb [usb] [reboot] instant system reboot when unmounting a o usb/84936 usb install - usb keyboard not recognized o usb/86031 usb need support usb nic rt2500 in my 5.4 STABLE o usb/86767 usb [usb] bogus "slice starts beyond end of the disk:..." o usb/87099 usb panic: ohci_add_done: addr 0x000d1bf0 not found o usb/87565 usb [PATCH] Support for Vodaphone 3G/UMTS cards o usb/88743 usb [hang] USB makes kernel hang at boot (regression in 6. o usb/88966 usb kldunload ucom.ko returns "Device busy" error. o usb/89003 usb LaCie Firewire drive not properly supported under 6.0 o usb/89218 usb flash disk o usb/89954 usb [usb] USB Disk driver race condition? f usb/89997 usb [umass] [panic] panic on iPod mini detach o usb/90162 usb [usb] [patch] Add support for the MS Wireless USB Mous o usb/90700 usb Kernel panic on connect/mount/use umass device o usb/91238 usb USB tape unit fails to write a second tape file to the o usb/91263 usb [patch] USB quirk needed for Logitec USB Hard disk LHD o usb/91283 usb booting very slow with usb devices connection (regress o usb/91538 usb Unable to print to EPSON CX3500 o usb/91906 usb FreeBSD hangs while booting with USB legacy support on o usb/92052 usb usbd causes defunct process with busy file-handle o kern/92083 usb [ural] [panic] panic using WPA on ural NIC in 6.0-RELE o usb/92142 usb SET_ADDR_FAILED and SHORT_XFER errors from usb drivers o usb/92171 usb [panic] panic unplugging Vodafone Mobile Connect (UMTS o usb/93155 usb /dev/ulpt0: device busy USB printer does not work o usb/93408 usb hw.acpi.cpu.cx_lowest=C3 on AMD Turion causes choppy m f usb/93496 usb USB2.0 umass stalls on VIA o usb/93640 usb device ehci causes interrupt storm on this MSI amd64 m o usb/93828 usb ohci causes panic on boot (HP Pavillion d4100e) o usb/93949 usb ugen(4)-related repeatable kernel panic in 6.1-PRERELE o usb/94166 usb btx halted with a flashcard plugged o usb/94384 usb kernel panic with usb2 hardware o usb/94717 usb Reading from /dev/ulpt can break work of a UHCI hub o usb/94742 usb [umass] [patch] umass driver does not recognise YANO e o usb/94813 usb mounting write-protected umass device freezes computer o usb/94897 usb Kernel Panic when cleanly unmounting USB disk o usb/95131 usb Boot/setup process does not accept key strokes o usb/95348 usb USB keyboard unplug causes noise on screen o usb/95562 usb Write Stress in USB Mass drive cause: [vinvalbuf: dir o usb/95636 usb [boot] 5 minute delay at boot when using VT6205 based o usb/96120 usb USB mouse not always detected o usb/96224 usb [usb] mount_msdosfs cause page fault in syncer process o usb/96457 usb fatback on umass = reboot o usb/97286 usb MS Wireless Intellimouse Explorer 2.0 doesn't work o usb/99431 usb FreeBSD on MSI 6566E (Intel 845E motherboards) doesn't o usb/101096 usb USB WLAN occasionally causes kernel-panics during larg o usb/101752 usb [panic] 6.1-RELEASE kernel panic on usb device inserti o usb/102066 usb [ukbd] usb keyboard and multimedia keys don't work o usb/102096 usb /usr/sbin/usbd does not handle multiple devices in one o i386/103025 usb [USB] the wrong in USB device for freeBSD 6.1 and AMD o usb/104292 usb system lockup on forced umount of usb-storage device o usb/104830 usb system crashes when copying data to umass devices o usb/105186 usb USB 2.0/ehci on FreeBSD 6.2-PRE/AMD64 crashes box o usb/106615 usb uftdi module does not automatically load with the FTDI o usb/106648 usb USB Floppy on D1950 10 min Hang on Insert w/o Floppy D o usb/106832 usb USB HP printer is not detected by kernel when ACPI ena o usb/107101 usb [umass] [patch] Quirk for Denver MP3 player o usb/107116 usb [usb] panic while accessing usb msdos pccard o usb/107128 usb [usb] panic while accessing usb msdos flashkey o usb/107248 usb [PATCH] scsi_da.c quirk for Cowon iAUDIO X5 MP3 player o usb/107446 usb [umass] umass problems (usb and fw disks) o usb/107827 usb [panic] ohci_add_done addr not found o usb/107848 usb problem with samsung flash o usb/107924 usb usbd does not call detach o usb/108097 usb [usbgen] [patch] ADMtek 851X USB-to-LAN adapter o usb/108513 usb umass: Creative MuVo TX FM fails in 6.2-RELEASE (regre o usb/109274 usb [usb] MCP55 USB Controller fails to attach in AMD64 Cu o usb/109397 usb [panic] on boot from USB flash o usb/110031 usb usb_interrupt_read does not respect timeout o usb/110122 usb usb_interrupt_read does not respect timeout 115 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/30929 usb [usb] [patch] use usbd to initialize USB ADSL modem s usb/32653 usb Added patches to improve USB scanner supportOB o usb/40948 usb [usb] USB HP CDW8200 does not work f usb/41415 usb [usb] [patch] Some USB scanners cannot talk to uscanne o usb/48342 usb [PATCH] usbd dynamic device list. o kern/51958 usb [usb] [patch] update for urio driver o kern/52026 usb [usb] feature request: umass driver support for InSyst o usb/53025 usb [ugen] [patch] ugen does not allow O_NONBLOCK for inte o usb/56095 usb [usb] [patch] QUIRK: Apacer Pen Drive fails to work o kern/59698 usb [kbd] [patch] Rework of ukbd HID to AT code translatio f usb/60248 usb [patch] Problem with USB printer HP LaserJet 1300 o usb/61234 usb [usb] [patch] usbhidaction(1) doesn't support using an o usb/63837 usb [uhid] [patch] USB: hid_is_collection() only looks for o kern/65769 usb [usb] Call to tcflush(x, TCIFLUSH) stops input on usb- o kern/66547 usb [usb] Palm Tungsten T USB does not initialize correctl o usb/68232 usb [ugen] [patch] ugen(4) isochronous handling correction o usb/68412 usb [usb] [patch] QUIRK: Philips KEY013 USB MP3 player o usb/70523 usb [usb] [patch] umct sending/receiving wrong characters o usb/70942 usb [usb] Genius Wireless USB mouse: moused doesn't work c o usb/71416 usb [usb] Cryptoflex e-gate USB token (ugen0) detach is no o usb/71417 usb [usb] Cryptoflex e-gate USB token (ugen0) communicatio o usb/71455 usb [usb] Slow USB umass performance of 5.3 o usb/71605 usb [umass] [patch] umass doesn't recognize multiple slots o usb/72380 usb [usb] USB does not work [dual Celeron Abit] o usb/72732 usb [patch] Kyocera 7135 quirk. o usb/72733 usb Kyocera 7135 Palm OS connection problem. o usb/73056 usb [usb] Sun Microsystems Type 6 USB mouse not working in f usb/73553 usb [usb] Microsoft USB Internet Keyboard not recongized o usb/74211 usb USB flash drive causes CAM status 0x4 on 4.10Release f usb/74358 usb [umass] unplugging at boot time an umass device crashe o usb/74453 usb Q-lity CD-RW USB ECW-043 (ScanLogic SL11R chipset) doe o usb/74557 usb imation 500mb usb key can only be written halfway on f o usb/74609 usb [usb] [patch] allowing cdma modems to work at full spe o usb/74849 usb [usb] [patch] Samsung SPH-i500 does not attach properl o usb/74880 usb [usb] [patch] Samsung N400 cellphone/acm fails to atac o kern/75764 usb [umass] [patch] "umass0: Phase Error" - no device for o usb/75800 usb ucom1: init failed STALLED error in time of sync with o usb/75928 usb Cytronix SmartMedia card (SMC) reader has problems whe o usb/76461 usb [umass] disklabel of umass(4)-CAM(4)-da(4) not used by o usb/76732 usb Mouse problems with USB KVM Switch f usb/78371 usb Philips Wearable Audio Player (128) fails to attach f usb/78984 usb Creative MUVO umass failure o usb/79723 usb [usb] prepare for high speed isochronous transfers o usb/79725 usb [usb] [patch] USB device speed is not double-checked o usb/79893 usb [umass] [patch] new usbdevs/umass quirks derived from o usb/80010 usb [aue] [patch] add support for the AEI USB to LAN adapt f usb/80420 usb atapicam stops iPod functionality f usb/80773 usb "usbd_get_string()" could have taken a length paramete o usb/80774 usb have "usbd_find_desc" in line with the other "usbd_fin o usb/80776 usb [udav] UDAV device driver shouldn't use usb_add_task o usb/80777 usb usb_rem_task() should wait for callback to complete? o usb/80854 usb suggestion for new iface-no-probe mechanism o usb/80935 usb uvisor.c is not work with CLIE TH55. o usb/81191 usb Support for Curitel HX-550C USB modem to 5.4 RELEASE. f usb/81621 usb external hd hangs under load on ehci o usb/82436 usb [patch] USL101 Host-to-Host bridge support on FreeBSD o usb/83022 usb ALI USB 2.0 EHCI Controller is not detected o usb/83863 usb Communication problem between opensc/openct via USB wi o usb/85067 usb Cannot attach ScanJet 4300C to usb device o usb/85992 usb [uhid] [patch] USB stops working when trying to read f o usb/86195 usb [patch] allow USB Ethernet Adaptor "ELECOM LD-USB20" t o usb/86298 usb Known good USB mouse won't work with correct settings o usb/86438 usb Fix for non-working iPod over USB is in NetBSD CVS o usb/87224 usb Cannot mount USB Zip750 o usb/87648 usb [mouse] Logitech USB-optical mouse problem. o usb/88408 usb axe0 read PHY failed o usb/88939 usb Fix cheapy Myson USB-IDE adapter f usb/89087 usb usb external harddrive hangs with BBB reset failed, TI f usb/91191 usb HP LaserJet 1020 (USB printer) not recognized f usb/91516 usb [umass] umass0 problems, with Freecom Classic SL Hard o usb/91546 usb [umodem] [patch] Nokia 6630 mobile phone does not work o usb/91811 usb Compact Flash in HP Photosmart 2610 return " Medium n o usb/91896 usb Serial Number of USB Memory Sticks is not passed throu o usb/92306 usb [quirk] [patch] Support for iRiver U10 USB media playe o usb/92403 usb [uplcom] uplcom.c needs new entry for 4.00 revision of o usb/92852 usb Vertical scroll not working properly on A4Tech WOP-49 f usb/93011 usb HP ScanJet 6200C & uscanner problem o usb/93389 usb Digital Camera Pentax S60 don't work o usb/93872 usb [patch] SCSI quirk required for ELTA 8061 OL USB memor o usb/94132 usb USB QUIRK for CENTURY EX35QUAT disk enclosure f usb/94147 usb doesn't recognise my USB keyboard o usb/94148 usb Make if_cdce work with ARM linux handhelds o usb/94311 usb [ugen][PATCH] allow interrupt IN transactions to be af o usb/94439 usb [patch] Add support for JNC MP3 Player o usb/94946 usb [uhub][patch] code dynamic status size for status chan o usb/95037 usb USB disk didnt recognized on hot-plug. o usb/95173 usb [usb] cannot mount external usb harddisk VIA Technolog o usb/95241 usb Patch to add USB ID for OEM Pharos 360 GPS o usb/95803 usb Add support for AnyData ADU-E100H o usb/95805 usb Add Support for Siemens ES75 modem o usb/96381 usb [patch] add a quirk table entry for a flash ram usb st p usb/96546 usb [usb] [patch] Add support (quirk) for EasyMP3 EM732X U o usb/96714 usb Update uvisor to support the Fossil Abacus Wrist PDA o usb/97175 usb USB cardreader hangs system o usb/97472 usb [patch] add support for Olympus C150,D390 o usb/98343 usb BBB reset failed errors with Creative Muvo MP3 player; o usb/99419 usb external usb harddrive slow to accept o usb/99538 usb [kbd] while using USB keyboard default params of atkbd o usb/100746 usb [kbd] system does not boot due to USB keyboard problem o usb/101757 usb [patch] uhid.4: correct structure field names to match o usb/101761 usb [patch] usb.h: increase maximal size of report descrip o usb/101775 usb [libusbhid] [patch] possible error in report descripto o usb/102976 usb Casio Exilim Digital Camera cause panic o usb/103046 usb [patch] ulpt event driven I/O with select(2) and nonbl o usb/103289 usb USB 2.0 problems on AMD LX-800 CPU and CS-5536 chipset o usb/103418 usb [usb] [patch] usbhidctl: add ability to write output a o usb/103917 usb USB driver reports "Addr 0 should never happen" o usb/104290 usb QUIRK: TOSHIBA DVD-RAM drive (libretto DVD Dock) o usb/104352 usb [ural] ural driver doesnt work o usb/104645 usb QUIRK: Rave C-201 MP3 player o usb/105065 usb SATA - USB Bridge o usb/105361 usb Kernel panic during unmounting mass storage (Creative o usb/105518 usb epson perfection 3490 usb scanner def o usb/106041 usb FreeBSD does not recognise Mustek BearPaw 2400TA usb s o usb/106070 usb devd recognizes ucom, but ttyU is the device actually o usb/106462 usb Motorola U6 PEBL not recognized by system via USB [pat o usb/106538 usb [patch] Can not burn DVD on Sony DRX-820UL external US o usb/106621 usb [usb] DLINK DUB-E100 support broken o usb/106861 usb [PATCH]: usbdevs update: Add product ACER Zeevo BT-500 o usb/107243 usb [patch] Apacer USB Flash Drive quirk o usb/107388 usb [PATCH] Add utoppy device from NetBSD o usb/107496 usb USB device problem on RELENG_6_2 (SHORT_XFER) (regress o usb/107526 usb Patch to support the Crystalfontz CFA-635 20x4 USB LCD o usb/107642 usb [patch]Ralink Technology RT2501USB/RT2601USB chipset d o kern/107665 usb [usb] [patch] uscanner support for epson stylus DX5050 o usb/107701 usb usbd ignores "detach" o usb/107935 usb [uplcom] panic while accessing /dev/cuaU0 o usb/108056 usb Mouse gets powered off during device probe when plugge o usb/108344 usb kernel with atausb panics when unplugging USB Flash o usb/108427 usb QUIRK-SAMSUNG MP0402H o usb/108509 usb Freebsd hang at startup after ehci0 detected (CD Loade o usb/108810 usb quirk for I/O Magic USB flash drive "Giga Bank" p usb/109613 usb Unsupported USB-Serial Controller for Sagem Mobile Pho p usb/109838 usb [PATCH] Support for various CDMA-2000 USB-modems o usb/110197 usb Sony PSP umass device does not detach from EHCI port o usb/110477 usb [patch] add Benq 3300U/4300U support to FreeBSD o usb/110681 usb [ukbd][patch] multiple keys will be repeated 137 problems total. From owner-freebsd-usb@FreeBSD.ORG Mon Mar 26 14:20:04 2007 Return-Path: X-Original-To: freebsd-usb@hub.freebsd.org Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF54D16A405 for ; Mon, 26 Mar 2007 14:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id BFEDA13C480 for ; Mon, 26 Mar 2007 14:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2QEK4vT080693 for ; Mon, 26 Mar 2007 14:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2QEK4no080692; Mon, 26 Mar 2007 14:20:04 GMT (envelope-from gnats) Resent-Date: Mon, 26 Mar 2007 14:20:04 GMT Resent-Message-Id: <200703261420.l2QEK4no080692@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, Markus Henschel Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9305A16A401 for ; Mon, 26 Mar 2007 14:18:33 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [69.147.83.33]) by mx1.freebsd.org (Postfix) with ESMTP id 6A71B13C45D for ; Mon, 26 Mar 2007 14:18:33 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id l2QEIW4Q073986 for ; Mon, 26 Mar 2007 14:18:33 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id l2QEDUNQ060832; Mon, 26 Mar 2007 14:13:30 GMT (envelope-from nobody) Message-Id: <200703261413.l2QEDUNQ060832@www.freebsd.org> Date: Mon, 26 Mar 2007 14:13:30 GMT From: Markus Henschel To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.0 Cc: Subject: usb/110855: ugen: interrupt in msgs are truncated when buffer is full 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, 26 Mar 2007 14:20:05 -0000 >Number: 110855 >Category: usb >Synopsis: ugen: interrupt in msgs are truncated when buffer is full >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Mon Mar 26 14:20:04 GMT 2007 >Closed-Date: >Last-Modified: >Originator: Markus Henschel >Release: 6.2 custom kernel >Organization: Bally Wulff Automaten GmbH >Environment: FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri Mar 23 21:28:38 CET 2007 prog@freebsd-1.bally.de:/usr/obj/usr/src/sys/BALLYWULFF i386 >Description: We use ugen for some user space drivers. When an interrupt in endpoint is used ugen creates a queue that is filled by the kernel. The user space driver is responsible for reading data from the device file. If this happens too slow the queue is full and new msgs arriving from the usb device are lost. This behavior is OK. The problem is that the queue is not a multiple of the interrupt in endpoints msgs size. So it is possible that the last msg in the queue is truncated. This is very hard to detect for a user space driver. The data stream seen by the user space driver will contain an incomplete msgs directly followed by the next message without knowing truncation happened (except when using some data corruption detection mechanism). It would be much better if ugen would fill the queues of interrupt in endpoints until there is no more space for a complete msg. This way the user space driver will not loose sync with the incoming msgs. >How-To-Repeat: 1. Attach a device served by the ugen driver 2. Open an interrupt in endpoint 3. read data in chunk equivalent to the endpoints msg size 4. pause the reading to fill the ugen kernel msg queue 5. resume reading chunks, the last chunk that comes from the queue will probably be truncated directly followed by the next new chunk (tested with a msgs size of the interrupt in endpoint of 16) >Fix: I use the attached patch in our company and it works as expected. Patch attached with submission follows: --- /usr/src/sys/dev/usb/ugen.c.old Mon Mar 26 15:56:18 2007 +++ /usr/src/sys/dev/usb/ugen.c Fri Mar 23 21:27:13 2007 @@ -1081,6 +1081,7 @@ /*struct ugen_softc *sc = sce->sc;*/ u_int32_t count; u_char *ibuf; + int iSize; if (status == USBD_CANCELLED) return; @@ -1100,6 +1101,10 @@ DPRINTFN(5, (" data = %02x %02x %02x\n", ibuf[0], ibuf[1], ibuf[2])); + // begin changes MH@BW + iSize = UGETW(sce->edesc->wMaxPacketSize); + if (count <= ( (UGEN_IBSIZE/iSize)*iSize - sce->q.c_cc)) + // end changes MH@BW (void)b_to_q(ibuf, count, &sce->q); if (sce->state & UGEN_ASLP) { >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-usb@FreeBSD.ORG Mon Mar 26 14:30:13 2007 Return-Path: X-Original-To: freebsd-usb@hub.freebsd.org Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB22B16A408 for ; Mon, 26 Mar 2007 14:30:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id B9E6613C4C5 for ; Mon, 26 Mar 2007 14:30:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2QEUD5l081811 for ; Mon, 26 Mar 2007 14:30:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2QEUD4o081806; Mon, 26 Mar 2007 14:30:13 GMT (envelope-from gnats) Resent-Date: Mon, 26 Mar 2007 14:30:13 GMT Resent-Message-Id: <200703261430.l2QEUD4o081806@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, Markus Henschel Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B5D216A403 for ; Mon, 26 Mar 2007 14:25:55 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [69.147.83.33]) by mx1.freebsd.org (Postfix) with ESMTP id E600913C44B for ; Mon, 26 Mar 2007 14:25:54 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id l2QEPskD078681 for ; Mon, 26 Mar 2007 14:25:54 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id l2QEKrOw077240; Mon, 26 Mar 2007 14:20:53 GMT (envelope-from nobody) Message-Id: <200703261420.l2QEKrOw077240@www.freebsd.org> Date: Mon, 26 Mar 2007 14:20:53 GMT From: Markus Henschel To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.0 Cc: Subject: usb/110856: ugen: interrupt in msgs are truncated when buffer is full 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, 26 Mar 2007 14:30:13 -0000 >Number: 110856 >Category: usb >Synopsis: ugen: interrupt in msgs are truncated when buffer is full >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Mon Mar 26 14:30:13 GMT 2007 >Closed-Date: >Last-Modified: >Originator: Markus Henschel >Release: 6.2 custom kernel >Organization: Bally Wulff Automaten GmbH >Environment: FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri Mar 23 21:28:38 CET 2007 prog@freebsd-1.bally.de:/usr/obj/usr/src/sys/BALLYWULFF i386 >Description: We use ugen for some user space drivers. When an interrupt in endpoint is used ugen creates a queue that is filled by the kernel. The user space driver is responsible for reading data from the device file. If this happens too slow the queue is full and new msgs arriving from the usb device are lost. This behavior is OK. The problem is that the queue is not a multiple of the interrupt in endpoints msgs size. So it is possible that the last msg in the queue is truncated. This is very hard to detect for a user space driver. The data stream seen by the user space driver will contain an incomplete msgs directly followed by the next message without knowing truncation happened (except when using some data corruption detection mechanism). It would be much better if ugen would fill the queues of interrupt in endpoints until there is no more space for a complete msg. This way the user space driver will not loose sync with the incoming msgs. >How-To-Repeat: 1. Attach a device served by the ugen driver 2. Open an interrupt in endpoint 3. read data in chunk equivalent to the endpoints msg size 4. pause the reading to fill the ugen kernel msg queue 5. resume reading chunks, the last chunk that comes from the queue will probably be truncated directly followed by the next new chunk (tested with a msgs size of the interrupt in endpoint of 16) >Fix: I use the attached patch in our company and it works as expected. Patch attached with submission follows: --- /usr/src/sys/dev/usb/ugen.c.old Mon Mar 26 15:56:18 2007 +++ /usr/src/sys/dev/usb/ugen.c Fri Mar 23 21:27:13 2007 @@ -1081,6 +1081,7 @@ /*struct ugen_softc *sc = sce->sc;*/ u_int32_t count; u_char *ibuf; + int iSize; if (status == USBD_CANCELLED) return; @@ -1100,6 +1101,10 @@ DPRINTFN(5, (" data = %02x %02x %02x\n", ibuf[0], ibuf[1], ibuf[2])); + // begin changes MH@BW + iSize = UGETW(sce->edesc->wMaxPacketSize); + if (count <= ( (UGEN_IBSIZE/iSize)*iSize - sce->q.c_cc)) + // end changes MH@BW (void)b_to_q(ibuf, count, &sce->q); if (sce->state & UGEN_ASLP) { >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-usb@FreeBSD.ORG Mon Mar 26 14:30:48 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3ED9F16A400 for ; Mon, 26 Mar 2007 14:30:48 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swip.net [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 736D813C4C5 for ; Mon, 26 Mar 2007 14:30:47 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe12.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 277466539; Mon, 26 Mar 2007 16:30:43 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Mon, 26 Mar 2007 16:30:23 +0200 User-Agent: KMail/1.9.5 References: <200703261413.l2QEDUNQ060832@www.freebsd.org> In-Reply-To: <200703261413.l2QEDUNQ060832@www.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703261630.23223.hselasky@c2i.net> Cc: Markus Henschel , freebsd-gnats-submit@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full 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, 26 Mar 2007 14:30:48 -0000 On Monday 26 March 2007 16:13, Markus Henschel wrote: > >Number: 110855 > >Category: usb > >Synopsis: ugen: interrupt in msgs are truncated when buffer is full > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-usb > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: change-request > >Submitter-Id: current-users > >Arrival-Date: Mon Mar 26 14:20:04 GMT 2007 > >Closed-Date: > >Last-Modified: > >Originator: Markus Henschel > >Release: 6.2 custom kernel > >Organization: > > Bally Wulff Automaten GmbH > > >Environment: > > FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri Mar 23 > 21:28:38 CET 2007 > prog@freebsd-1.bally.de:/usr/obj/usr/src/sys/BALLYWULFF i386 > > >Description: > > We use ugen for some user space drivers. When an interrupt in endpoint is > used ugen creates a queue that is filled by the kernel. The user space > driver is responsible for reading data from the device file. If this > happens too slow the queue is full and new msgs arriving from the usb > device are lost. This behavior is OK. > > The problem is that the queue is not a multiple of the interrupt in > endpoints msgs size. So it is possible that the last msg in the queue is > truncated. This is very hard to detect for a user space driver. The data > stream seen by the user space driver will contain an incomplete msgs > directly followed by the next message without knowing truncation happened > (except when using some data corruption detection mechanism). > > It would be much better if ugen would fill the queues of interrupt in > endpoints until there is no more space for a complete msg. This way the > user space driver will not loose sync with the incoming msgs. The new USB stack has this fixed already. What I do is that the USB driver stops polling the interrupt endpoint when the user-land application does not read data. When the user-land application has read a packet, the interrupt endpoint is started again. The only problem is that some devices, like a Microsoft mouse I have, stops working immediately when its internal buffer overflows. Bad hardware design. But if your hardware is not like that, the new ugen, which is part of the new USB driver, will work great for you. Also packet alignment is kept between reads: Only one packet per read. See: http://www.turbocat.net/~hselasky/usb4bsd --HPS From owner-freebsd-usb@FreeBSD.ORG Mon Mar 26 15:40:08 2007 Return-Path: X-Original-To: freebsd-usb@hub.freebsd.org Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B80C916A400 for ; Mon, 26 Mar 2007 15:40:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8D9D113C487 for ; Mon, 26 Mar 2007 15:40:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2QFe8Ik092880 for ; Mon, 26 Mar 2007 15:40:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2QFe7ip092879; Mon, 26 Mar 2007 15:40:07 GMT (envelope-from gnats) Date: Mon, 26 Mar 2007 15:40:07 GMT Message-Id: <200703261540.l2QFe7ip092879@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Hans Petter Selasky Cc: Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full 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: Mon, 26 Mar 2007 15:40:08 -0000 The following reply was made to PR usb/110855; it has been noted by GNATS. From: Hans Petter Selasky To: freebsd-usb@freebsd.org Cc: Markus Henschel , freebsd-gnats-submit@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full Date: Mon, 26 Mar 2007 16:30:23 +0200 On Monday 26 March 2007 16:13, Markus Henschel wrote: > >Number: 110855 > >Category: usb > >Synopsis: ugen: interrupt in msgs are truncated when buffer is full > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-usb > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: change-request > >Submitter-Id: current-users > >Arrival-Date: Mon Mar 26 14:20:04 GMT 2007 > >Closed-Date: > >Last-Modified: > >Originator: Markus Henschel > >Release: 6.2 custom kernel > >Organization: > > Bally Wulff Automaten GmbH > > >Environment: > > FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri Mar 23 > 21:28:38 CET 2007 > prog@freebsd-1.bally.de:/usr/obj/usr/src/sys/BALLYWULFF i386 > > >Description: > > We use ugen for some user space drivers. When an interrupt in endpoint is > used ugen creates a queue that is filled by the kernel. The user space > driver is responsible for reading data from the device file. If this > happens too slow the queue is full and new msgs arriving from the usb > device are lost. This behavior is OK. > > The problem is that the queue is not a multiple of the interrupt in > endpoints msgs size. So it is possible that the last msg in the queue is > truncated. This is very hard to detect for a user space driver. The data > stream seen by the user space driver will contain an incomplete msgs > directly followed by the next message without knowing truncation happened > (except when using some data corruption detection mechanism). > > It would be much better if ugen would fill the queues of interrupt in > endpoints until there is no more space for a complete msg. This way the > user space driver will not loose sync with the incoming msgs. The new USB stack has this fixed already. What I do is that the USB driver stops polling the interrupt endpoint when the user-land application does not read data. When the user-land application has read a packet, the interrupt endpoint is started again. The only problem is that some devices, like a Microsoft mouse I have, stops working immediately when its internal buffer overflows. Bad hardware design. But if your hardware is not like that, the new ugen, which is part of the new USB driver, will work great for you. Also packet alignment is kept between reads: Only one packet per read. See: http://www.turbocat.net/~hselasky/usb4bsd --HPS From owner-freebsd-usb@FreeBSD.ORG Tue Mar 27 09:53:05 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E385B16A402; Tue, 27 Mar 2007 09:53:04 +0000 (UTC) (envelope-from m.henschel@bally-wulff.de) Received: from mail2.bally-wulff-berlin.de (mail2.bally-wulff-berlin.de [212.144.118.9]) by mx1.freebsd.org (Postfix) with ESMTP id CCFFF13C46C; Tue, 27 Mar 2007 09:53:03 +0000 (UTC) (envelope-from m.henschel@bally-wulff.de) Message-ID: <4608E431.1030809@bally-wulff.de> Date: Tue, 27 Mar 2007 11:30:25 +0200 From: Markus Henschel MIME-Version: 1.0 To: Hans Petter Selasky References: <200703261413.l2QEDUNQ060832@www.freebsd.org> <200703261630.23223.hselasky@c2i.net> In-Reply-To: <200703261630.23223.hselasky@c2i.net> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2007 09:30:19.0565 (UTC) FILETIME=[893FFDD0:01C77052] Cc: freebsd-gnats-submit@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full 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, 27 Mar 2007 09:53:05 -0000 Hans Petter Selasky schrieb: > On Monday 26 March 2007 16:13, Markus Henschel wrote: >>> Number: 110855 >>> Category: usb >>> Synopsis: ugen: interrupt in msgs are truncated when buffer is full >>> Confidential: no >>> Severity: serious >>> Priority: medium >>> Responsible: freebsd-usb >>> State: open >>> Quarter: >>> Keywords: >>> Date-Required: >>> Class: change-request >>> Submitter-Id: current-users >>> Arrival-Date: Mon Mar 26 14:20:04 GMT 2007 >>> Closed-Date: >>> Last-Modified: >>> Originator: Markus Henschel >>> Release: 6.2 custom kernel >>> Organization: >> Bally Wulff Automaten GmbH >> >>> Environment: >> FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri Mar 23 >> 21:28:38 CET 2007 >> prog@freebsd-1.bally.de:/usr/obj/usr/src/sys/BALLYWULFF i386 >> >>> Description: >> We use ugen for some user space drivers. When an interrupt in endpoint is >> used ugen creates a queue that is filled by the kernel. The user space >> driver is responsible for reading data from the device file. If this >> happens too slow the queue is full and new msgs arriving from the usb >> device are lost. This behavior is OK. >> >> The problem is that the queue is not a multiple of the interrupt in >> endpoints msgs size. So it is possible that the last msg in the queue is >> truncated. This is very hard to detect for a user space driver. The data >> stream seen by the user space driver will contain an incomplete msgs >> directly followed by the next message without knowing truncation happened >> (except when using some data corruption detection mechanism). >> >> It would be much better if ugen would fill the queues of interrupt in >> endpoints until there is no more space for a complete msg. This way the >> user space driver will not loose sync with the incoming msgs. > > The new USB stack has this fixed already. What I do is that the USB driver > stops polling the interrupt endpoint when the user-land application does not > read data. When the user-land application has read a packet, the interrupt > endpoint is started again. The only problem is that some devices, like a > Microsoft mouse I have, stops working immediately when its internal buffer > overflows. Bad hardware design. But if your hardware is not like that, the > new ugen, which is part of the new USB driver, will work great for you. > > Also packet alignment is kept between reads: Only one packet per read. > > See: > > http://www.turbocat.net/~hselasky/usb4bsd > > --HPS > Thanks, I gave it a try and it seems to work fine :-). Could you please explain how reading an interrupt in endpoint works internally with the new ugen? Is there still a buffer that recieves data from the endpoint or is each read request from user land synchronously triggering a read data request on the interrupt endpoint? Why isn't O_NONBLOCK working anymore? -- Regards, Markus Henschel Development BALLY WULFF Automaten GmbH Maybachufer 48-51 12045 Berlin Phone: +49(30)62002 161 FAX: +49(30)62002 230 http://www.ballywulff.de From owner-freebsd-usb@FreeBSD.ORG Tue Mar 27 10:00:16 2007 Return-Path: X-Original-To: freebsd-usb@hub.freebsd.org Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D188916A403 for ; Tue, 27 Mar 2007 10:00:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8F92E13C4C3 for ; Tue, 27 Mar 2007 10:00:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2RA0G9N057078 for ; Tue, 27 Mar 2007 10:00:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2RA0GHg057077; Tue, 27 Mar 2007 10:00:16 GMT (envelope-from gnats) Date: Tue, 27 Mar 2007 10:00:16 GMT Message-Id: <200703271000.l2RA0GHg057077@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Markus Henschel Cc: Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Markus Henschel List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 10:00:16 -0000 The following reply was made to PR usb/110855; it has been noted by GNATS. From: Markus Henschel To: Hans Petter Selasky Cc: freebsd-usb@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full Date: Tue, 27 Mar 2007 11:30:25 +0200 Hans Petter Selasky schrieb: > On Monday 26 March 2007 16:13, Markus Henschel wrote: >>> Number: 110855 >>> Category: usb >>> Synopsis: ugen: interrupt in msgs are truncated when buffer is full >>> Confidential: no >>> Severity: serious >>> Priority: medium >>> Responsible: freebsd-usb >>> State: open >>> Quarter: >>> Keywords: >>> Date-Required: >>> Class: change-request >>> Submitter-Id: current-users >>> Arrival-Date: Mon Mar 26 14:20:04 GMT 2007 >>> Closed-Date: >>> Last-Modified: >>> Originator: Markus Henschel >>> Release: 6.2 custom kernel >>> Organization: >> Bally Wulff Automaten GmbH >> >>> Environment: >> FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri Mar 23 >> 21:28:38 CET 2007 >> prog@freebsd-1.bally.de:/usr/obj/usr/src/sys/BALLYWULFF i386 >> >>> Description: >> We use ugen for some user space drivers. When an interrupt in endpoint is >> used ugen creates a queue that is filled by the kernel. The user space >> driver is responsible for reading data from the device file. If this >> happens too slow the queue is full and new msgs arriving from the usb >> device are lost. This behavior is OK. >> >> The problem is that the queue is not a multiple of the interrupt in >> endpoints msgs size. So it is possible that the last msg in the queue is >> truncated. This is very hard to detect for a user space driver. The data >> stream seen by the user space driver will contain an incomplete msgs >> directly followed by the next message without knowing truncation happened >> (except when using some data corruption detection mechanism). >> >> It would be much better if ugen would fill the queues of interrupt in >> endpoints until there is no more space for a complete msg. This way the >> user space driver will not loose sync with the incoming msgs. > > The new USB stack has this fixed already. What I do is that the USB driver > stops polling the interrupt endpoint when the user-land application does not > read data. When the user-land application has read a packet, the interrupt > endpoint is started again. The only problem is that some devices, like a > Microsoft mouse I have, stops working immediately when its internal buffer > overflows. Bad hardware design. But if your hardware is not like that, the > new ugen, which is part of the new USB driver, will work great for you. > > Also packet alignment is kept between reads: Only one packet per read. > > See: > > http://www.turbocat.net/~hselasky/usb4bsd > > --HPS > Thanks, I gave it a try and it seems to work fine :-). Could you please explain how reading an interrupt in endpoint works internally with the new ugen? Is there still a buffer that recieves data from the endpoint or is each read request from user land synchronously triggering a read data request on the interrupt endpoint? Why isn't O_NONBLOCK working anymore? -- Regards, Markus Henschel Development BALLY WULFF Automaten GmbH Maybachufer 48-51 12045 Berlin Phone: +49(30)62002 161 FAX: +49(30)62002 230 http://www.ballywulff.de From owner-freebsd-usb@FreeBSD.ORG Tue Mar 27 10:03:50 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BAABE16A405; Tue, 27 Mar 2007 10:03:50 +0000 (UTC) (envelope-from a.bittau@cs.ucl.ac.uk) Received: from darkircop.org (thug.cs.ucl.ac.uk [128.16.68.86]) by mx1.freebsd.org (Postfix) with ESMTP id 5F05813C4C6; Tue, 27 Mar 2007 10:03:50 +0000 (UTC) (envelope-from a.bittau@cs.ucl.ac.uk) Received: by darkircop.org (Postfix, from userid 0) id 9A9266D732; Tue, 27 Mar 2007 10:53:01 +0100 (BST) Date: Tue, 27 Mar 2007 10:53:01 +0100 From: Andrea Bittau To: freebsd-usb@freebsd.org Message-ID: <20070327095301.GA1439@shorty.sorbonet.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Echelon: Bush Bomb War KGB Cc: iedowse@freebsd.org Subject: fix uhci suspend 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, 27 Mar 2007 10:03:50 -0000 To suspend, you need to: 1) stop the controller 2) set the global suspend bit The current code does: cmd = UREAD2(sc, UHCI_CMD); ... uhci_run(sc, 0); /* stop the controller */ ... UHCICMD(sc, cmd | UHCI_CMD_EGSM); /* enter global suspend */ The problem is that cmd is not re-read after stopping the controller, so cmd will still have the run bit set to 1 instead of 0. Thus, when entering suspend, the controller's run bit will be put back to 1 and the controller will freak out. The attached patch fixes this. I don't know if the resume branch of the code suffers from this problem too---I'm working on suspend for now. With my patch, I can get ICH7 82801G to suspend, otherwise, suspend would just hang the box. --- Index: uhci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/uhci.c,v retrieving revision 1.172 diff -u -p -r1.172 uhci.c --- uhci.c 19 Oct 2006 01:15:58 -0000 1.172 +++ uhci.c 27 Mar 2007 09:33:48 -0000 @@ -723,6 +723,7 @@ uhci_power(int why, void *v) sc->sc_intr_xfer); sc->sc_bus.use_polling++; uhci_run(sc, 0); /* stop the controller */ + cmd &= ~UHCI_CMD_RS; /* save some state if BIOS doesn't */ sc->sc_saved_frnum = UREAD2(sc, UHCI_FRNUM); From owner-freebsd-usb@FreeBSD.ORG Tue Mar 27 16:43:31 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3390116A404; Tue, 27 Mar 2007 16:43:31 +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 67C7C13C45B; Tue, 27 Mar 2007 16:43:30 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe13.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 56917903; Tue, 27 Mar 2007 18:43:27 +0200 From: Hans Petter Selasky To: Markus Henschel Date: Tue, 27 Mar 2007 18:43:08 +0200 User-Agent: KMail/1.9.5 References: <200703261413.l2QEDUNQ060832@www.freebsd.org> <200703261630.23223.hselasky@c2i.net> <4608E431.1030809@bally-wulff.de> In-Reply-To: <4608E431.1030809@bally-wulff.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703271843.08145.hselasky@c2i.net> Cc: freebsd-gnats-submit@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full 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, 27 Mar 2007 16:43:31 -0000 On Tuesday 27 March 2007 11:30, Markus Henschel wrote: > Hans Petter Selasky schrieb: > > On Monday 26 March 2007 16:13, Markus Henschel wrote: > >>> Number: 110855 > >>> Category: usb > >>> Synopsis: ugen: interrupt in msgs are truncated when buffer is > >>> full Confidential: no > >>> Severity: serious > >>> Priority: medium > >>> Responsible: freebsd-usb > >>> State: open > >>> Quarter: > >>> Keywords: > >>> Date-Required: > >>> Class: change-request > >>> Submitter-Id: current-users > >>> Arrival-Date: Mon Mar 26 14:20:04 GMT 2007 > >>> Closed-Date: > >>> Last-Modified: > >>> Originator: Markus Henschel > >>> Release: 6.2 custom kernel > >>> Organization: > >> > >> Bally Wulff Automaten GmbH > >> > >>> Environment: > >> > >> FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri Mar > >> 23 21:28:38 CET 2007 > >> prog@freebsd-1.bally.de:/usr/obj/usr/src/sys/BALLYWULFF i386 > >> > >>> Description: > >> > >> We use ugen for some user space drivers. When an interrupt in endpoint > >> is used ugen creates a queue that is filled by the kernel. The user > >> space driver is responsible for reading data from the device file. If > >> this happens too slow the queue is full and new msgs arriving from the > >> usb device are lost. This behavior is OK. > >> > >> The problem is that the queue is not a multiple of the interrupt in > >> endpoints msgs size. So it is possible that the last msg in the queue is > >> truncated. This is very hard to detect for a user space driver. The data > >> stream seen by the user space driver will contain an incomplete msgs > >> directly followed by the next message without knowing truncation > >> happened (except when using some data corruption detection mechanism). > >> > >> It would be much better if ugen would fill the queues of interrupt in > >> endpoints until there is no more space for a complete msg. This way the > >> user space driver will not loose sync with the incoming msgs. > > > > The new USB stack has this fixed already. What I do is that the USB > > driver stops polling the interrupt endpoint when the user-land > > application does not read data. When the user-land application has read a > > packet, the interrupt endpoint is started again. The only problem is that > > some devices, like a Microsoft mouse I have, stops working immediately > > when its internal buffer overflows. Bad hardware design. But if your > > hardware is not like that, the new ugen, which is part of the new USB > > driver, will work great for you. > > > > Also packet alignment is kept between reads: Only one packet per read. > > > > See: > > > > http://www.turbocat.net/~hselasky/usb4bsd > > > > --HPS > > Thanks, > > I gave it a try and it seems to work fine :-). Could you please explain > how reading an interrupt in endpoint works internally with the new ugen? > Is there still a buffer that recieves data from the endpoint or is each > read request from user land synchronously triggering a read data request > on the interrupt endpoint? Yes, there is a buffer, but the buffer is packet-based, and not a "ring" based, so you will never get problem with packet alignment. > Why isn't O_NONBLOCK working anymore? It is implemented, and it should work. Can you explain more what is not working? --HPS From owner-freebsd-usb@FreeBSD.ORG Tue Mar 27 16:50:12 2007 Return-Path: X-Original-To: freebsd-usb@hub.freebsd.org Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76BB816A404 for ; Tue, 27 Mar 2007 16:50:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 6676913C45A for ; Tue, 27 Mar 2007 16:50:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2RGoBA3029674 for ; Tue, 27 Mar 2007 16:50:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2RGoBVm029672; Tue, 27 Mar 2007 16:50:11 GMT (envelope-from gnats) Date: Tue, 27 Mar 2007 16:50:11 GMT Message-Id: <200703271650.l2RGoBVm029672@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Hans Petter Selasky Cc: Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full 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: Tue, 27 Mar 2007 16:50:12 -0000 The following reply was made to PR usb/110855; it has been noted by GNATS. From: Hans Petter Selasky To: Markus Henschel Cc: freebsd-usb@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full Date: Tue, 27 Mar 2007 18:43:08 +0200 On Tuesday 27 March 2007 11:30, Markus Henschel wrote: > Hans Petter Selasky schrieb: > > On Monday 26 March 2007 16:13, Markus Henschel wrote: > >>> Number: 110855 > >>> Category: usb > >>> Synopsis: ugen: interrupt in msgs are truncated when buffer is > >>> full Confidential: no > >>> Severity: serious > >>> Priority: medium > >>> Responsible: freebsd-usb > >>> State: open > >>> Quarter: > >>> Keywords: > >>> Date-Required: > >>> Class: change-request > >>> Submitter-Id: current-users > >>> Arrival-Date: Mon Mar 26 14:20:04 GMT 2007 > >>> Closed-Date: > >>> Last-Modified: > >>> Originator: Markus Henschel > >>> Release: 6.2 custom kernel > >>> Organization: > >> > >> Bally Wulff Automaten GmbH > >> > >>> Environment: > >> > >> FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri Mar > >> 23 21:28:38 CET 2007 > >> prog@freebsd-1.bally.de:/usr/obj/usr/src/sys/BALLYWULFF i386 > >> > >>> Description: > >> > >> We use ugen for some user space drivers. When an interrupt in endpoint > >> is used ugen creates a queue that is filled by the kernel. The user > >> space driver is responsible for reading data from the device file. If > >> this happens too slow the queue is full and new msgs arriving from the > >> usb device are lost. This behavior is OK. > >> > >> The problem is that the queue is not a multiple of the interrupt in > >> endpoints msgs size. So it is possible that the last msg in the queue is > >> truncated. This is very hard to detect for a user space driver. The data > >> stream seen by the user space driver will contain an incomplete msgs > >> directly followed by the next message without knowing truncation > >> happened (except when using some data corruption detection mechanism). > >> > >> It would be much better if ugen would fill the queues of interrupt in > >> endpoints until there is no more space for a complete msg. This way the > >> user space driver will not loose sync with the incoming msgs. > > > > The new USB stack has this fixed already. What I do is that the USB > > driver stops polling the interrupt endpoint when the user-land > > application does not read data. When the user-land application has read a > > packet, the interrupt endpoint is started again. The only problem is that > > some devices, like a Microsoft mouse I have, stops working immediately > > when its internal buffer overflows. Bad hardware design. But if your > > hardware is not like that, the new ugen, which is part of the new USB > > driver, will work great for you. > > > > Also packet alignment is kept between reads: Only one packet per read. > > > > See: > > > > http://www.turbocat.net/~hselasky/usb4bsd > > > > --HPS > > Thanks, > > I gave it a try and it seems to work fine :-). Could you please explain > how reading an interrupt in endpoint works internally with the new ugen? > Is there still a buffer that recieves data from the endpoint or is each > read request from user land synchronously triggering a read data request > on the interrupt endpoint? Yes, there is a buffer, but the buffer is packet-based, and not a "ring" based, so you will never get problem with packet alignment. > Why isn't O_NONBLOCK working anymore? It is implemented, and it should work. Can you explain more what is not working? --HPS From owner-freebsd-usb@FreeBSD.ORG Tue Mar 27 16:54:59 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BFD6D16A534 for ; Tue, 27 Mar 2007 16:54:59 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 5C13113C43E for ; Tue, 27 Mar 2007 16:54:58 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe08.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 447854395; Tue, 27 Mar 2007 18:54:57 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Tue, 27 Mar 2007 18:54:38 +0200 User-Agent: KMail/1.9.5 References: <20070327095301.GA1439@shorty.sorbonet.org> In-Reply-To: <20070327095301.GA1439@shorty.sorbonet.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703271854.38239.hselasky@c2i.net> Cc: Andrea Bittau Subject: Re: fix uhci suspend 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, 27 Mar 2007 16:54:59 -0000 On Tuesday 27 March 2007 11:53, Andrea Bittau wrote: > To suspend, you need to: > 1) stop the controller > 2) set the global suspend bit > > The current code does: > cmd = UREAD2(sc, UHCI_CMD); > ... > uhci_run(sc, 0); /* stop the controller */ > ... > UHCICMD(sc, cmd | UHCI_CMD_EGSM); /* enter global suspend */ > > The problem is that cmd is not re-read after stopping the controller, so > cmd will still have the run bit set to 1 instead of 0. Thus, when entering > suspend, the controller's run bit will be put back to 1 and the controller > will freak out. The attached patch fixes this. I don't know if the resume > branch of the code suffers from this problem too---I'm working on suspend > for now. With my patch, I can get ICH7 82801G to suspend, otherwise, > suspend would just hang the box. That is correctly noticed. In my new USB stack I simply do: /* enter global suspend */ UHCICMD(sc, UHCI_CMD_EGSM); Clearing all other bits. Could you have tried the SVN version of the new USB stack and see if suspend/resume works there? http://www.turbocat.net/~hselasky/usb4bsd --HPS From owner-freebsd-usb@FreeBSD.ORG Tue Mar 27 16:56:06 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E79F16A402; Tue, 27 Mar 2007 16:56:06 +0000 (UTC) (envelope-from m.henschel@bally-wulff.de) Received: from mail2.bally-wulff-berlin.de (mail2.bally-wulff-berlin.de [212.144.118.9]) by mx1.freebsd.org (Postfix) with ESMTP id 175DC13C465; Tue, 27 Mar 2007 16:56:03 +0000 (UTC) (envelope-from m.henschel@bally-wulff.de) Message-ID: <46094C9E.7000301@bally-wulff.de> Date: Tue, 27 Mar 2007 18:55:58 +0200 From: Markus Henschel MIME-Version: 1.0 To: Hans Petter Selasky References: <200703261413.l2QEDUNQ060832@www.freebsd.org> <200703261630.23223.hselasky@c2i.net> <4608E431.1030809@bally-wulff.de> <200703271843.08145.hselasky@c2i.net> In-Reply-To: <200703271843.08145.hselasky@c2i.net> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2007 16:55:58.0975 (UTC) FILETIME=[CB2E28F0:01C77090] Cc: freebsd-gnats-submit@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full 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, 27 Mar 2007 16:56:06 -0000 Hans Petter Selasky schrieb: > On Tuesday 27 March 2007 11:30, Markus Henschel wrote: >> Hans Petter Selasky schrieb: >>> On Monday 26 March 2007 16:13, Markus Henschel wrote: >>>>> Number: 110855 >>>>> Category: usb >>>>> Synopsis: ugen: interrupt in msgs are truncated when buffer is >>>>> full Confidential: no >>>>> Severity: serious >>>>> Priority: medium >>>>> Responsible: freebsd-usb >>>>> State: open >>>>> Quarter: >>>>> Keywords: >>>>> Date-Required: >>>>> Class: change-request >>>>> Submitter-Id: current-users >>>>> Arrival-Date: Mon Mar 26 14:20:04 GMT 2007 >>>>> Closed-Date: >>>>> Last-Modified: >>>>> Originator: Markus Henschel >>>>> Release: 6.2 custom kernel >>>>> Organization: >>>> Bally Wulff Automaten GmbH >>>> >>>>> Environment: >>>> FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri Mar >>>> 23 21:28:38 CET 2007 >>>> prog@freebsd-1.bally.de:/usr/obj/usr/src/sys/BALLYWULFF i386 >>>> >>>>> Description: >>>> We use ugen for some user space drivers. When an interrupt in endpoint >>>> is used ugen creates a queue that is filled by the kernel. The user >>>> space driver is responsible for reading data from the device file. If >>>> this happens too slow the queue is full and new msgs arriving from the >>>> usb device are lost. This behavior is OK. >>>> >>>> The problem is that the queue is not a multiple of the interrupt in >>>> endpoints msgs size. So it is possible that the last msg in the queue is >>>> truncated. This is very hard to detect for a user space driver. The data >>>> stream seen by the user space driver will contain an incomplete msgs >>>> directly followed by the next message without knowing truncation >>>> happened (except when using some data corruption detection mechanism). >>>> >>>> It would be much better if ugen would fill the queues of interrupt in >>>> endpoints until there is no more space for a complete msg. This way the >>>> user space driver will not loose sync with the incoming msgs. >>> The new USB stack has this fixed already. What I do is that the USB >>> driver stops polling the interrupt endpoint when the user-land >>> application does not read data. When the user-land application has read a >>> packet, the interrupt endpoint is started again. The only problem is that >>> some devices, like a Microsoft mouse I have, stops working immediately >>> when its internal buffer overflows. Bad hardware design. But if your >>> hardware is not like that, the new ugen, which is part of the new USB >>> driver, will work great for you. >>> >>> Also packet alignment is kept between reads: Only one packet per read. >>> >>> See: >>> >>> http://www.turbocat.net/~hselasky/usb4bsd >>> >>> --HPS >> Thanks, >> >> I gave it a try and it seems to work fine :-). Could you please explain >> how reading an interrupt in endpoint works internally with the new ugen? >> Is there still a buffer that recieves data from the endpoint or is each >> read request from user land synchronously triggering a read data request >> on the interrupt endpoint? > > Yes, there is a buffer, but the buffer is packet-based, and not a "ring" > based, so you will never get problem with packet alignment. > >> Why isn't O_NONBLOCK working anymore? > > It is implemented, and it should work. Can you explain more what is not > working? > > --HPS > With the old ugen I did something like: int iDevice=open("/dev/ugen0.4", O_RDONLY); fcntl(iDevice, F_SETFL, O_NONBLOCK); Now the fcntl call fails. But instead this works and does the same: int iDevice=open("/dev/ugen0.4", O_RDONLY|O_NONBLOCK); I thought the O_NONBLOCK flag was just for the open call itself?!? Whatever, it does what I need :-) The only thing that keeps me from using the new usb stack is umass now. When inserting an usb flash memory stick it is detected and says umass attached to ii but then it takes ages (more that 30s) for the device files to become available. A "camcontrol rescan all" hangs during this time too.Is it possible to use the old umass with the new stack or just revert umass to an older version from you like 1.6.1? BTW: The performance of the new usb stack is great. umass throughput with the memory stick nearly increased by 50%!! -- Regards, Markus Henschel Development BALLY WULFF Automaten GmbH Maybachufer 48-51 12045 Berlin Phone: +49(30)62002 161 FAX: +49(30)62002 230 http://www.ballywulff.de From owner-freebsd-usb@FreeBSD.ORG Tue Mar 27 17:00:27 2007 Return-Path: X-Original-To: freebsd-usb@hub.freebsd.org Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E7ED16A403 for ; Tue, 27 Mar 2007 17:00:27 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 2E59213C4B8 for ; Tue, 27 Mar 2007 17:00:27 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2RH0QTV031174 for ; Tue, 27 Mar 2007 17:00:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2RH0QNR031173; Tue, 27 Mar 2007 17:00:26 GMT (envelope-from gnats) Date: Tue, 27 Mar 2007 17:00:26 GMT Message-Id: <200703271700.l2RH0QNR031173@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Markus Henschel Cc: Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Markus Henschel List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 17:00:27 -0000 The following reply was made to PR usb/110855; it has been noted by GNATS. From: Markus Henschel To: Hans Petter Selasky Cc: freebsd-usb@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full Date: Tue, 27 Mar 2007 18:55:58 +0200 Hans Petter Selasky schrieb: > On Tuesday 27 March 2007 11:30, Markus Henschel wrote: >> Hans Petter Selasky schrieb: >>> On Monday 26 March 2007 16:13, Markus Henschel wrote: >>>>> Number: 110855 >>>>> Category: usb >>>>> Synopsis: ugen: interrupt in msgs are truncated when buffer is >>>>> full Confidential: no >>>>> Severity: serious >>>>> Priority: medium >>>>> Responsible: freebsd-usb >>>>> State: open >>>>> Quarter: >>>>> Keywords: >>>>> Date-Required: >>>>> Class: change-request >>>>> Submitter-Id: current-users >>>>> Arrival-Date: Mon Mar 26 14:20:04 GMT 2007 >>>>> Closed-Date: >>>>> Last-Modified: >>>>> Originator: Markus Henschel >>>>> Release: 6.2 custom kernel >>>>> Organization: >>>> Bally Wulff Automaten GmbH >>>> >>>>> Environment: >>>> FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri Mar >>>> 23 21:28:38 CET 2007 >>>> prog@freebsd-1.bally.de:/usr/obj/usr/src/sys/BALLYWULFF i386 >>>> >>>>> Description: >>>> We use ugen for some user space drivers. When an interrupt in endpoint >>>> is used ugen creates a queue that is filled by the kernel. The user >>>> space driver is responsible for reading data from the device file. If >>>> this happens too slow the queue is full and new msgs arriving from the >>>> usb device are lost. This behavior is OK. >>>> >>>> The problem is that the queue is not a multiple of the interrupt in >>>> endpoints msgs size. So it is possible that the last msg in the queue is >>>> truncated. This is very hard to detect for a user space driver. The data >>>> stream seen by the user space driver will contain an incomplete msgs >>>> directly followed by the next message without knowing truncation >>>> happened (except when using some data corruption detection mechanism). >>>> >>>> It would be much better if ugen would fill the queues of interrupt in >>>> endpoints until there is no more space for a complete msg. This way the >>>> user space driver will not loose sync with the incoming msgs. >>> The new USB stack has this fixed already. What I do is that the USB >>> driver stops polling the interrupt endpoint when the user-land >>> application does not read data. When the user-land application has read a >>> packet, the interrupt endpoint is started again. The only problem is that >>> some devices, like a Microsoft mouse I have, stops working immediately >>> when its internal buffer overflows. Bad hardware design. But if your >>> hardware is not like that, the new ugen, which is part of the new USB >>> driver, will work great for you. >>> >>> Also packet alignment is kept between reads: Only one packet per read. >>> >>> See: >>> >>> http://www.turbocat.net/~hselasky/usb4bsd >>> >>> --HPS >> Thanks, >> >> I gave it a try and it seems to work fine :-). Could you please explain >> how reading an interrupt in endpoint works internally with the new ugen? >> Is there still a buffer that recieves data from the endpoint or is each >> read request from user land synchronously triggering a read data request >> on the interrupt endpoint? > > Yes, there is a buffer, but the buffer is packet-based, and not a "ring" > based, so you will never get problem with packet alignment. > >> Why isn't O_NONBLOCK working anymore? > > It is implemented, and it should work. Can you explain more what is not > working? > > --HPS > With the old ugen I did something like: int iDevice=open("/dev/ugen0.4", O_RDONLY); fcntl(iDevice, F_SETFL, O_NONBLOCK); Now the fcntl call fails. But instead this works and does the same: int iDevice=open("/dev/ugen0.4", O_RDONLY|O_NONBLOCK); I thought the O_NONBLOCK flag was just for the open call itself?!? Whatever, it does what I need :-) The only thing that keeps me from using the new usb stack is umass now. When inserting an usb flash memory stick it is detected and says umass attached to ii but then it takes ages (more that 30s) for the device files to become available. A "camcontrol rescan all" hangs during this time too.Is it possible to use the old umass with the new stack or just revert umass to an older version from you like 1.6.1? BTW: The performance of the new usb stack is great. umass throughput with the memory stick nearly increased by 50%!! -- Regards, Markus Henschel Development BALLY WULFF Automaten GmbH Maybachufer 48-51 12045 Berlin Phone: +49(30)62002 161 FAX: +49(30)62002 230 http://www.ballywulff.de From owner-freebsd-usb@FreeBSD.ORG Tue Mar 27 19:34:01 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC49116A403; Tue, 27 Mar 2007 19:34:01 +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 9433413C4AD; Tue, 27 Mar 2007 19:34:00 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe11.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 280535199; Tue, 27 Mar 2007 21:33:57 +0200 From: Hans Petter Selasky To: Markus Henschel Date: Tue, 27 Mar 2007 21:33:37 +0200 User-Agent: KMail/1.9.5 References: <200703261413.l2QEDUNQ060832@www.freebsd.org> <200703271843.08145.hselasky@c2i.net> <46094C9E.7000301@bally-wulff.de> In-Reply-To: <46094C9E.7000301@bally-wulff.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703272133.37865.hselasky@c2i.net> Cc: freebsd-gnats-submit@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full 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, 27 Mar 2007 19:34:01 -0000 On Tuesday 27 March 2007 18:55, Markus Henschel wrote: > Hans Petter Selasky schrieb: > > On Tuesday 27 March 2007 11:30, Markus Henschel wrote: > >> Hans Petter Selasky schrieb: > >>> On Monday 26 March 2007 16:13, Markus Henschel wrote: > >>>>> Number: 110855 > >>>>> Category: usb > >>>>> Synopsis: ugen: interrupt in msgs are truncated when buffer is > >>>>> full Confidential: no > >>>>> Severity: serious > >>>>> Priority: medium > >>>>> Responsible: freebsd-usb > >>>>> State: open > >>>>> Quarter: > >>>>> Keywords: > >>>>> Date-Required: > >>>>> Class: change-request > >>>>> Submitter-Id: current-users > >>>>> Arrival-Date: Mon Mar 26 14:20:04 GMT 2007 > >>>>> Closed-Date: > >>>>> Last-Modified: > >>>>> Originator: Markus Henschel > >>>>> Release: 6.2 custom kernel > >>>>> Organization: > >>>> > >>>> Bally Wulff Automaten GmbH > >>>> > >>>>> Environment: > >>>> > >>>> FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri > >>>> Mar 23 21:28:38 CET 2007 > >>>> prog@freebsd-1.bally.de:/usr/obj/usr/src/sys/BALLYWULFF i386 > >>>> > >>>>> Description: > >>>> > >>>> We use ugen for some user space drivers. When an interrupt in endpoint > >>>> is used ugen creates a queue that is filled by the kernel. The user > >>>> space driver is responsible for reading data from the device file. If > >>>> this happens too slow the queue is full and new msgs arriving from the > >>>> usb device are lost. This behavior is OK. > >>>> > >>>> The problem is that the queue is not a multiple of the interrupt in > >>>> endpoints msgs size. So it is possible that the last msg in the queue > >>>> is truncated. This is very hard to detect for a user space driver. The > >>>> data stream seen by the user space driver will contain an incomplete > >>>> msgs directly followed by the next message without knowing truncation > >>>> happened (except when using some data corruption detection mechanism). > >>>> > >>>> It would be much better if ugen would fill the queues of interrupt in > >>>> endpoints until there is no more space for a complete msg. This way > >>>> the user space driver will not loose sync with the incoming msgs. > >>> > >>> The new USB stack has this fixed already. What I do is that the USB > >>> driver stops polling the interrupt endpoint when the user-land > >>> application does not read data. When the user-land application has read > >>> a packet, the interrupt endpoint is started again. The only problem is > >>> that some devices, like a Microsoft mouse I have, stops working > >>> immediately when its internal buffer overflows. Bad hardware design. > >>> But if your hardware is not like that, the new ugen, which is part of > >>> the new USB driver, will work great for you. > >>> > >>> Also packet alignment is kept between reads: Only one packet per read. > >>> > >>> See: > >>> > >>> http://www.turbocat.net/~hselasky/usb4bsd > >>> > >>> --HPS > >> > >> Thanks, > >> > >> I gave it a try and it seems to work fine :-). Could you please explain > >> how reading an interrupt in endpoint works internally with the new ugen? > >> Is there still a buffer that recieves data from the endpoint or is each > >> read request from user land synchronously triggering a read data request > >> on the interrupt endpoint? > > > > Yes, there is a buffer, but the buffer is packet-based, and not a "ring" > > based, so you will never get problem with packet alignment. > > > >> Why isn't O_NONBLOCK working anymore? > > > > It is implemented, and it should work. Can you explain more what is not > > working? > > > > --HPS > > With the old ugen I did something like: > > int iDevice=open("/dev/ugen0.4", O_RDONLY); > fcntl(iDevice, F_SETFL, O_NONBLOCK); I've just committed a patch for that to the P4 tree. It will be in SVN in not too long. It was just the matter of a missing IOCTL that F_SETFL uses. Usually the following works when you want to set/clear non-blocking mode: int t = 1; fcntl(iDevice, FIONBIO, &t) > > Now the fcntl call fails. But instead this works and does the same: > > int iDevice=open("/dev/ugen0.4", O_RDONLY|O_NONBLOCK); > > > I thought the O_NONBLOCK flag was just for the open call itself?!? > Whatever, it does what I need :-) > > The only thing that keeps me from using the new usb stack is umass now. > When inserting an usb flash memory stick it is detected and says umass > attached to ii but then it takes ages (more that 30s) for the device > files to become available. A "camcontrol rescan all" hangs during this > time too.Is it possible to use the old umass with the new stack or just > revert umass to an older version from you like 1.6.1? If you use the SVN version, reverting won't help much. Could you turn on debugging: sysctl hw.usb.umass.debug=-1 And see what is going on when you plug your umass device. > > BTW: The performance of the new usb stack is great. umass throughput > with the memory stick nearly increased by 50%!! Cool. --HPS From owner-freebsd-usb@FreeBSD.ORG Tue Mar 27 19:40:10 2007 Return-Path: X-Original-To: freebsd-usb@hub.freebsd.org Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0633616A54E for ; Tue, 27 Mar 2007 19:40:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 9D66213C44B for ; Tue, 27 Mar 2007 19:40:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2RJe9CH058559 for ; Tue, 27 Mar 2007 19:40:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2RJe90x058558; Tue, 27 Mar 2007 19:40:09 GMT (envelope-from gnats) Date: Tue, 27 Mar 2007 19:40:09 GMT Message-Id: <200703271940.l2RJe90x058558@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Hans Petter Selasky Cc: Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full 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: Tue, 27 Mar 2007 19:40:10 -0000 The following reply was made to PR usb/110855; it has been noted by GNATS. From: Hans Petter Selasky To: Markus Henschel Cc: freebsd-usb@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full Date: Tue, 27 Mar 2007 21:33:37 +0200 On Tuesday 27 March 2007 18:55, Markus Henschel wrote: > Hans Petter Selasky schrieb: > > On Tuesday 27 March 2007 11:30, Markus Henschel wrote: > >> Hans Petter Selasky schrieb: > >>> On Monday 26 March 2007 16:13, Markus Henschel wrote: > >>>>> Number: 110855 > >>>>> Category: usb > >>>>> Synopsis: ugen: interrupt in msgs are truncated when buffer is > >>>>> full Confidential: no > >>>>> Severity: serious > >>>>> Priority: medium > >>>>> Responsible: freebsd-usb > >>>>> State: open > >>>>> Quarter: > >>>>> Keywords: > >>>>> Date-Required: > >>>>> Class: change-request > >>>>> Submitter-Id: current-users > >>>>> Arrival-Date: Mon Mar 26 14:20:04 GMT 2007 > >>>>> Closed-Date: > >>>>> Last-Modified: > >>>>> Originator: Markus Henschel > >>>>> Release: 6.2 custom kernel > >>>>> Organization: > >>>> > >>>> Bally Wulff Automaten GmbH > >>>> > >>>>> Environment: > >>>> > >>>> FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE #11: Fri > >>>> Mar 23 21:28:38 CET 2007 > >>>> prog@freebsd-1.bally.de:/usr/obj/usr/src/sys/BALLYWULFF i386 > >>>> > >>>>> Description: > >>>> > >>>> We use ugen for some user space drivers. When an interrupt in endpoint > >>>> is used ugen creates a queue that is filled by the kernel. The user > >>>> space driver is responsible for reading data from the device file. If > >>>> this happens too slow the queue is full and new msgs arriving from the > >>>> usb device are lost. This behavior is OK. > >>>> > >>>> The problem is that the queue is not a multiple of the interrupt in > >>>> endpoints msgs size. So it is possible that the last msg in the queue > >>>> is truncated. This is very hard to detect for a user space driver. The > >>>> data stream seen by the user space driver will contain an incomplete > >>>> msgs directly followed by the next message without knowing truncation > >>>> happened (except when using some data corruption detection mechanism). > >>>> > >>>> It would be much better if ugen would fill the queues of interrupt in > >>>> endpoints until there is no more space for a complete msg. This way > >>>> the user space driver will not loose sync with the incoming msgs. > >>> > >>> The new USB stack has this fixed already. What I do is that the USB > >>> driver stops polling the interrupt endpoint when the user-land > >>> application does not read data. When the user-land application has read > >>> a packet, the interrupt endpoint is started again. The only problem is > >>> that some devices, like a Microsoft mouse I have, stops working > >>> immediately when its internal buffer overflows. Bad hardware design. > >>> But if your hardware is not like that, the new ugen, which is part of > >>> the new USB driver, will work great for you. > >>> > >>> Also packet alignment is kept between reads: Only one packet per read. > >>> > >>> See: > >>> > >>> http://www.turbocat.net/~hselasky/usb4bsd > >>> > >>> --HPS > >> > >> Thanks, > >> > >> I gave it a try and it seems to work fine :-). Could you please explain > >> how reading an interrupt in endpoint works internally with the new ugen? > >> Is there still a buffer that recieves data from the endpoint or is each > >> read request from user land synchronously triggering a read data request > >> on the interrupt endpoint? > > > > Yes, there is a buffer, but the buffer is packet-based, and not a "ring" > > based, so you will never get problem with packet alignment. > > > >> Why isn't O_NONBLOCK working anymore? > > > > It is implemented, and it should work. Can you explain more what is not > > working? > > > > --HPS > > With the old ugen I did something like: > > int iDevice=open("/dev/ugen0.4", O_RDONLY); > fcntl(iDevice, F_SETFL, O_NONBLOCK); I've just committed a patch for that to the P4 tree. It will be in SVN in not too long. It was just the matter of a missing IOCTL that F_SETFL uses. Usually the following works when you want to set/clear non-blocking mode: int t = 1; fcntl(iDevice, FIONBIO, &t) > > Now the fcntl call fails. But instead this works and does the same: > > int iDevice=open("/dev/ugen0.4", O_RDONLY|O_NONBLOCK); > > > I thought the O_NONBLOCK flag was just for the open call itself?!? > Whatever, it does what I need :-) > > The only thing that keeps me from using the new usb stack is umass now. > When inserting an usb flash memory stick it is detected and says umass > attached to ii but then it takes ages (more that 30s) for the device > files to become available. A "camcontrol rescan all" hangs during this > time too.Is it possible to use the old umass with the new stack or just > revert umass to an older version from you like 1.6.1? If you use the SVN version, reverting won't help much. Could you turn on debugging: sysctl hw.usb.umass.debug=-1 And see what is going on when you plug your umass device. > > BTW: The performance of the new usb stack is great. umass throughput > with the memory stick nearly increased by 50%!! Cool. --HPS From owner-freebsd-usb@FreeBSD.ORG Tue Mar 27 23:52:00 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F05BA16A403 for ; Tue, 27 Mar 2007 23:52:00 +0000 (UTC) (envelope-from akropel1@rochester.rr.com) Received: from ms-smtp-04.nyroc.rr.com (ms-smtp-04.nyroc.rr.com [24.24.2.58]) by mx1.freebsd.org (Postfix) with ESMTP id B0FAA13C44B for ; Tue, 27 Mar 2007 23:52:00 +0000 (UTC) (envelope-from akropel1@rochester.rr.com) Received: from mail.kroptech.com (cpe-74-69-97-211.rochester.res.rr.com [74.69.97.211]) by ms-smtp-04.nyroc.rr.com (8.13.6/8.13.6) with ESMTP id l2RMantV028244; Tue, 27 Mar 2007 18:36:49 -0400 (EDT) Received: from pia (pia.kroptech.com [192.168.200.3]) by mail.kroptech.com (Postfix) with SMTP id 453A91138A1; Tue, 27 Mar 2007 17:36:48 -0500 (EST) Message-ID: <121101c770c0$67e79350$84163e05@kroptech.com> From: "Adam Kropelin" To: "Hans Petter Selasky" , References: <200703261413.l2QEDUNQ060832@www.freebsd.org> <200703261630.23223.hselasky@c2i.net> Date: Tue, 27 Mar 2007 18:36:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full 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, 27 Mar 2007 23:52:01 -0000 Hans Petter Selasky wrote: > The new USB stack has this fixed already. What I do is that the USB > driver stops polling the interrupt endpoint when the user-land > application does not read data. When the user-land application has > read a packet, the interrupt endpoint is started again. The only > problem is that some devices, like a Microsoft mouse I have, stops > working immediately when its internal buffer overflows. Bad hardware > design. But if your hardware is not like that, the new ugen, which is > part of the new USB driver, will work great for you. > > Also packet alignment is kept between reads: Only one packet per read. And there was much rejoicing! The old ugen behavior of returning multiple reports in a single read() -- or a report-and-a-half if your buffer was unfortunately sized -- has caused me untold anguish. I look forward to the new stack going mainline... --Adam From owner-freebsd-usb@FreeBSD.ORG Wed Mar 28 03:05:27 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C13716A401 for ; Wed, 28 Mar 2007 03:05:27 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: from mail.bindone.de (sidewinder.bindone.de [62.146.109.98]) by mx1.freebsd.org (Postfix) with SMTP id 6B20813C4BD for ; Wed, 28 Mar 2007 03:05:26 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: (qmail 25204 invoked from network); 28 Mar 2007 02:49:56 -0000 Received: from unknown (HELO bombat.bindone.de) (84.151.241.193) by mail.bindone.de with SMTP; 28 Mar 2007 02:49:56 -0000 Message-ID: <4609D885.8070505@bindone.de> Date: Wed, 28 Mar 2007 04:52:53 +0200 From: grem User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.2) Gecko/20070318 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-usb@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Support for new device, important fix and enhancement to umass.c 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, 28 Mar 2007 03:05:27 -0000 Hello, I had trouble using a Raidsonic ICY BOX IB-220U-Wh external USB HDD case (fdisk, disklabel, newfs, mount etc. fail with all kinds of weird error messages). It uses a "SuperTop IDEDEVICE" controller (VendorId 0x14cd, ProductId 0x6600), which - after googling around - seems to be used in different USB-to-IDE adaptors from different vendors. As I learned from Linux/OpenBSD sources, this device needs the IGNORE_RESIDUE quirk to be set. After adding an entry in usbdevs and an entry to umass_devdescrs in umass.c things still didn't work. After a lot of trial and error I figured that the IGNORE_RESIDUE quirk is not used at all in umass.c. The critical lines are 1668-1672 in umass.c: int Residue; Residue = UGETDW(sc->csw.dCSWDataResidue); if (Residue == 0 && sc->transfer_datalen - sc->transfer_actlen != 0) Residue = sc->transfer_datalen - sc->transfer_actlen; since these trust the residue returned by the device, even so it's wrong [and != 0] (as indicated by IGNORE_RESIDUE). I added the following lines in front of the code above: if (sc->quirks & IGNORE_RESIDUE) USETDW(sc->csw.dCSWDataResidue, 0); (which might be not the most elegant way to do it) and hooray the device finally works without any problems. I also added a convinience #define UMASS_PROTO_PROBE 0xffff, which can be used in entries to umass_devdescrs to make umass_match_proto(...) only set the quirks and still get the protocol details from the device (eases adding new "unusual" devices). See below for patches to usbdevs and umass.c (against RELENG_6_2) for the new device, fix for IGNORE_RESIDUE and the (maybe poorly named) UMASS_PROTO_PROBE extension. I would really like to see at least the former two submitted to the source tree, since these devices seem to be relatively common. Any feedback is welcome, since I'm not an expert in how USB works/is implemented in FreeBSD. /michael --- usbdevs.orig Thu Mar 15 16:23:52 2007 +++ usbdevs Wed Mar 28 03:16:24 2007 @@ -514,6 +514,7 @@ vendor RALINK 0x148f Ralink Technology vendor IMAGINATION 0x149a Imagination Technologies vendor CONCEPTRONIC 0x14b2 Conceptronic +vendor SUPERTOP 0x14cd Super Top vendor SILICONPORTALS 0x1527 Silicon Portals vendor PNY 0x154b PNY vendor SOHOWARE 0x15e8 SOHOware @@ -1596,6 +1597,9 @@ product DIAMOND2 SUPRA2890 0x0b4a SupraMax 2890 56K Modem product DIAMOND2 RIO600USB 0x5001 Rio 600 USB product DIAMOND2 RIO800USB 0x5002 Rio 800 USB + +/* Super Top products */ +product SUPERTOP IDEDEVICE 0x6600 Icybox disk enclosure /* System TALKS, Inc. */ product SYSTEMTALKS SGCX2UL 0x1920 SGC-X2UL ------------------------------------------------------------------ --- umass.c.orig Thu Mar 15 17:17:30 2007 +++ umass.c Wed Mar 28 04:08:27 2007 @@ -282,6 +282,7 @@ # define UMASS_PROTO_UFI 0x0400 # define UMASS_PROTO_RBC 0x0800 # define UMASS_PROTO_COMMAND 0xff00 /* command protocol mask */ +# define UMASS_PROTO_PROBE 0xffff /* probe the protocol, even if found in umass_devdescr) */ /* Device specific quirks */ u_int16_t quirks; @@ -494,6 +495,10 @@ UMASS_PROTO_RBC | UMASS_PROTO_CBI, NO_QUIRKS }, + { USB_VENDOR_SUPERTOP, USB_PRODUCT_SUPERTOP_IDEDEVICE, RID_WILDCARD, + UMASS_PROTO_PROBE, + IGNORE_RESIDUE + }, { USB_VENDOR_TREK, USB_PRODUCT_TREK_THUMBDRIVE_8MB, RID_WILDCARD, UMASS_PROTO_ATAPI | UMASS_PROTO_BBB, IGNORE_RESIDUE @@ -845,7 +850,10 @@ if (umass_devdescrs[i].rid == RID_WILDCARD) { sc->proto = umass_devdescrs[i].proto; sc->quirks = umass_devdescrs[i].quirks; - return (UMATCH_VENDOR_PRODUCT); + if (sc->proto == UMASS_PROTO_PROBE) + sc->proto = 0; + else + return (UMATCH_VENDOR_PRODUCT); } else if (umass_devdescrs[i].rid == UGETW(dd->bcdDevice)) { sc->proto = umass_devdescrs[i].proto; @@ -1665,6 +1673,8 @@ USETDW(sc->csw.dCSWSignature, CSWSIGNATURE); } + if (sc->quirks & IGNORE_RESIDUE) + USETDW(sc->csw.dCSWDataResidue, 0); int Residue; Residue = UGETDW(sc->csw.dCSWDataResidue); if (Residue == 0 && From owner-freebsd-usb@FreeBSD.ORG Wed Mar 28 06:17:46 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2167D16A401 for ; Wed, 28 Mar 2007 06:17:46 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id C88C113C48C for ; Wed, 28 Mar 2007 06:17:45 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54a5f07f.dip.t-dialin.net [84.165.240.127]) by redbull.bpaserver.net (Postfix) with ESMTP id 9A5002E215; Wed, 28 Mar 2007 08:00:03 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id CA30B5B4817; Wed, 28 Mar 2007 08:00:00 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l2S600fX022713; Wed, 28 Mar 2007 08:00:00 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 28 Mar 2007 08:00:00 +0200 Message-ID: <20070328080000.bhakk1rou88ww8ks@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 28 Mar 2007 08:00:00 +0200 From: Alexander Leidinger To: grem References: <4609D885.8070505@bindone.de> In-Reply-To: <4609D885.8070505@bindone.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.864, required 8, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-usb@freebsd.org Subject: Re: Support for new device, important fix and enhancement to umass.c 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, 28 Mar 2007 06:17:46 -0000 Quoting grem (from Wed, 28 Mar 2007 04:52:53 +0200): [analysis of the problem] > Any feedback is welcome, since I'm not an expert in how USB works/is =20 > implemented in FreeBSD. Please submit this as a problem report. Quirks have to be registered =20 in GNATS before we can commit them so that we are able to reevaluate =20 them if the need arises. > @@ -1665,6 +1673,8 @@ > USETDW(sc->csw.dCSWSignature, CSWSIGNATURE= ); > } > > + if (sc->quirks & IGNORE_RESIDUE) > + USETDW(sc->csw.dCSWDataResidue, 0); > int Residue; > Residue =3D UGETDW(sc->csw.dCSWDataResidue); > if (Residue =3D=3D 0 && Wrong indent for the USETDW line. I don't know much about the USB =20 code. If the residue is not used somewhere else, wouldn't it be better =20 to do "if quirk set the Residue variable to 0 else get it from the =20 device" instead of setting it? Bye, Alexander. --=20 BOFH excuse #71: The file system is full of it http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-usb@FreeBSD.ORG Wed Mar 28 09:42:02 2007 Return-Path: X-Original-To: freebsd-usb@FreeBSD.org Delivered-To: freebsd-usb@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 144A616A407 for ; Wed, 28 Mar 2007 09:42:02 +0000 (UTC) (envelope-from m.henschel@bally-wulff.de) Received: from mail2.bally-wulff-berlin.de (mail2.bally-wulff-berlin.de [212.144.118.9]) by mx1.freebsd.org (Postfix) with ESMTP id 04AC313C459 for ; Wed, 28 Mar 2007 09:41:58 +0000 (UTC) (envelope-from m.henschel@bally-wulff.de) Message-ID: <460A3861.3000207@bally-wulff.de> Date: Wed, 28 Mar 2007 11:41:53 +0200 From: Markus Henschel MIME-Version: 1.0 To: Hans Petter Selasky References: <200703271940.l2RJe90x058558@freefall.freebsd.org> In-Reply-To: <200703271940.l2RJe90x058558@freefall.freebsd.org> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2007 09:41:53.0899 (UTC) FILETIME=[5184B3B0:01C7711D] Cc: freebsd-usb@FreeBSD.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full 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, 28 Mar 2007 09:42:02 -0000 Hans Petter Selasky schrieb: > The following reply was made to PR usb/110855; it has been noted by > GNATS. > > From: Hans Petter Selasky To: Markus Henschel > Cc: freebsd-usb@freebsd.org, > freebsd-gnats-submit@freebsd.org Subject: Re: usb/110855: ugen: > interrupt in msgs are truncated when buffer is full Date: Tue, 27 Mar > 2007 21:33:37 +0200 > > On Tuesday 27 March 2007 18:55, Markus Henschel wrote: >> Hans Petter Selasky schrieb: >>> On Tuesday 27 March 2007 11:30, Markus Henschel wrote: >>>> Hans Petter Selasky schrieb: >>>>> On Monday 26 March 2007 16:13, Markus Henschel wrote: >>>>>>> Number: 110855 Category: usb Synopsis: >>>>>>> ugen: interrupt in msgs are truncated when buffer is full >>>>>>> Confidential: no Severity: serious Priority: >>>>>>> medium Responsible: freebsd-usb State: open >>>>>>> Quarter: Keywords: Date-Required: Class: change-request >>>>>>> Submitter-Id: current-users Arrival-Date: Mon Mar 26 >>>>>>> 14:20:04 GMT 2007 Closed-Date: Last-Modified: Originator: >>>>>>> Markus Henschel Release: 6.2 custom kernel Organization: >>>>>>> >>>>>> >>>>>> Bally Wulff Automaten GmbH >>>>>> >>>>>>> Environment: >>>>>> >>>>>> FreeBSD freebsd-1.bally.de 6.2-RELEASE FreeBSD 6.2-RELEASE >>>>>> #11: Fri Mar 23 21:28:38 CET 2007 >>>>>> prog@freebsd-1.bally.de:/usr/obj/usr/src/sys/BALLYWULFF >>>>>> i386 >>>>>> >>>>>>> Description: >>>>>> >>>>>> We use ugen for some user space drivers. When an interrupt >>>>>> in endpoint is used ugen creates a queue that is filled by >>>>>> the kernel. The user space driver is responsible for >>>>>> reading data from the device file. If this happens too slow >>>>>> the queue is full and new msgs arriving from the usb >>>>>> device are lost. This behavior is OK. >>>>>> >>>>>> The problem is that the queue is not a multiple of the >>>>>> interrupt in endpoints msgs size. So it is possible that >>>>>> the last msg in the queue is truncated. This is very hard >>>>>> to detect for a user space driver. The data stream seen by >>>>>> the user space driver will contain an incomplete msgs >>>>>> directly followed by the next message without knowing >>>>>> truncation happened (except when using some data corruption >>>>>> detection mechanism). >>>>>> >>>>>> It would be much better if ugen would fill the queues of >>>>>> interrupt in endpoints until there is no more space for a >>>>>> complete msg. This way the user space driver will not loose >>>>>> sync with the incoming msgs. >>>>> >>>>> The new USB stack has this fixed already. What I do is that >>>>> the USB driver stops polling the interrupt endpoint when the >>>>> user-land application does not read data. When the user-land >>>>> application has read a packet, the interrupt endpoint is >>>>> started again. The only problem is that some devices, like a >>>>> Microsoft mouse I have, stops working immediately when its >>>>> internal buffer overflows. Bad hardware design. But if your >>>>> hardware is not like that, the new ugen, which is part of the >>>>> new USB driver, will work great for you. >>>>> >>>>> Also packet alignment is kept between reads: Only one packet >>>>> per read. >>>>> >>>>> See: >>>>> >>>>> http://www.turbocat.net/~hselasky/usb4bsd >>>>> >>>>> --HPS >>>> >>>> Thanks, >>>> >>>> I gave it a try and it seems to work fine :-). Could you please >>>> explain how reading an interrupt in endpoint works internally >>>> with the new ugen? Is there still a buffer that recieves data >>>> from the endpoint or is each read request from user land >>>> synchronously triggering a read data request on the interrupt >>>> endpoint? >>> >>> Yes, there is a buffer, but the buffer is packet-based, and not a >>> "ring" based, so you will never get problem with packet >>> alignment. >>> >>>> Why isn't O_NONBLOCK working anymore? >>> >>> It is implemented, and it should work. Can you explain more what >>> is not working? >>> >>> --HPS >> >> With the old ugen I did something like: >> >> int iDevice=open("/dev/ugen0.4", O_RDONLY); fcntl(iDevice, F_SETFL, >> O_NONBLOCK); > > I've just committed a patch for that to the P4 tree. It will be in > SVN in not too long. It was just the matter of a missing IOCTL that > F_SETFL uses. Usually the following works when you want to set/clear > non-blocking mode: > > int t = 1; fcntl(iDevice, FIONBIO, &t) > >> >> Now the fcntl call fails. But instead this works and does the same: >> >> >> >> >> int iDevice=open("/dev/ugen0.4", O_RDONLY|O_NONBLOCK); >> >> >> I thought the O_NONBLOCK flag was just for the open call itself?!? >> Whatever, it does what I need :-) >> >> The only thing that keeps me from using the new usb stack is umass >> now. When inserting an usb flash memory stick it is detected and >> says umass attached to ii but then it takes ages (more that 30s) >> for the device files to become available. A "camcontrol rescan all" >> hangs during this time too.Is it possible to use the old umass >> with the new stack or just revert umass to an older version from >> you like 1.6.1? > > If you use the SVN version, reverting won't help much. Could you turn > on debugging: sysctl hw.usb.umass.debug=-1 > > And see what is going on when you plug your umass device. > >> >> BTW: The performance of the new usb stack is great. umass >> throughput with the memory stick nearly increased by 50%!! > > Cool. > > --HPS _______________________________________________ > freebsd-usb@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, > send any mail to "freebsd-usb-unsubscribe@freebsd.org" > Hi, here is the dmesg output with hw.usb.umass.debug=-1: umass0: umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0: Get Max Lun not supported (USBD_STALLED) umass0:umass_cam_action: 0:-1:-1:XPT_PATH_INQ:. umass0:0:0:-1: Attached to scbus0 umass0:umass_cam_rescan: scbus0: scanning for 0:0:-1 umass0:umass_cam_action: 0:-1:-1:XPT_PATH_INQ:. umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense umass0:umass_bbb_dump_cbw: CBW 1: cmd = 6b (0x120000002400), data = 36b, lun = 0, dir = in umass0:umass_attach: Attach finishedumass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=36 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 274: sig = 0x28120799 (invalid), tag = 274, res = 134217728, status = 0x8f () umass0:umass_t_bbb_status_callback: truncating residue from 134217728 to 36 bytes umass0:umass_t_bbb_status_callback: bad CSW signature 0x28120799 != 0x53425355 umass0:umass_t_bbb_status_callback: Failed to read CSW: USBD_NORMAL_COMPLETION, try 0 umass0:umass_transfer_start: transfer index = 5 umass0:umass_transfer_start: transfer index = 8 umass0:umass_t_bbb_status_callback: Failed to read CSW: USBD_TIMEOUT, try 1 umass0:umass_tr_error: transfer error, USBD_TIMEOUT -> reset umass0:umass_transfer_start: transfer index = 0 umass0:umass_t_bbb_reset1_callback: BBB reset! umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense umass0:umass_transfer_start: transfer index = 1 umass0:umass_transfer_start: transfer index = 2 umass0:umass_transfer_start: transfer index = 3 umass0:umass_bbb_dump_cbw: CBW 2: cmd = 6b (0x120000002400), data = 36b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=36 umass0:umass_transfer_start: transfer index = 5 umass0:umass_transfer_start: transfer index = 8 umass0:umass_t_bbb_status_callback: Failed to read CSW: USBD_TIMEOUT, try 0 umass0:umass_transfer_start: transfer index = 5 umass0:umass_transfer_start: transfer index = 8 umass0:umass_t_bbb_status_callback: Failed to read CSW: USBD_TIMEOUT, try 1 umass0:umass_tr_error: transfer error, USBD_TIMEOUT -> reset umass0:umass_transfer_start: transfer index = 0 umass0:umass_t_bbb_reset1_callback: BBB reset! umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense umass0:umass_transfer_start: transfer index = 1 umass0:umass_transfer_start: transfer index = 2 umass0:umass_transfer_start: transfer index = 3 umass0:umass_bbb_dump_cbw: CBW 3: cmd = 6b (0x120000002400), data = 36b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=36 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 3: sig = 0x53425355 (valid), tag = 3, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense umass0:umass_bbb_dump_cbw: CBW 4: cmd = 6b (0x12018000ff00), data = 255b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=255 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 4: sig = 0x53425355 (valid), tag = 4, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_GET_TRAN_SETTINGS:. umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. umass0:umass_cam_action: 0:0:0:XPT_GET_TRAN_SETTINGS:. umass0:umass_cam_action: 0:0:0:XPT_SET_TRAN_SETTINGS:. umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 5: cmd = 6b (0x000000000000), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 5: sig = 0x53425355 (valid), tag = 5, res = 0, status = 0x01 (failed) umass0:umass_t_bbb_status_callback: Command failed, residue = 0 umass0:umass_cam_cb: Fetching 32 bytes of sense data umass0:umass_bbb_dump_cbw: CBW 6: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 6: sig = 0x53425355 (valid), tag = 6, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense umass0:umass_bbb_dump_cbw: CBW 7: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in umassX:umass_cam_rescan_callback: xpt0: Rescan succeeded umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 7: sig = 0x53425355 (valid), tag = 7, res = 0, status = 0x00 (good) da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device umass0:umass_cam_action: 0:0:0:XPT_GET_TRAN_SETTINGS:. umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. da0: 40.000MB/s transfers da0: 484MB (991232 512 byte sectors: 64H 32S/T 484C) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense umass0:umass_bbb_dump_cbw: CBW 8: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 8: sig = 0x53425355 (valid), tag = 8, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 9: cmd = 6b (0x1e0000000100), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 9: sig = 0x53425355 (valid), tag = 9, res = 0, status = 0x01 (failed) umass0:umass_t_bbb_status_callback: Command failed, residue = 0 umass0:umass_cam_cb: Fetching 32 bytes of sense data umass0:umass_bbb_dump_cbw: CBW 10: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 10: sig = 0x53425355 (valid), tag = 10, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense umass0:umass_bbb_dump_cbw: CBW 11: cmd = 10b (0x280000000000...), data = 512b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=512 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 11: sig = 0x53425355 (valid), tag = 11, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 12: cmd = 10b (0x350000000000...), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 12: sig = 0x53425355 (valid), tag = 12, res = 0, status = 0x01 (failed) umass0:umass_t_bbb_status_callback: Command failed, residue = 0 umass0:umass_cam_cb: Fetching 32 bytes of sense data umass0:umass_bbb_dump_cbw: CBW 13: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 13: sig = 0x53425355 (valid), tag = 13, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 14: cmd = 6b (0x1e0000000000), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 14: sig = 0x53425355 (valid), tag = 14, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense umass0:umass_bbb_dump_cbw: CBW 15: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 15: sig = 0x53425355 (valid), tag = 15, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 16: cmd = 6b (0x1e0000000100), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 16: sig = 0x53425355 (valid), tag = 16, res = 0, status = 0x01 (failed) umass0:umass_t_bbb_status_callback: Command failed, residue = 0 umass0:umass_cam_cb: Fetching 32 bytes of sense data umass0:umass_bbb_dump_cbw: CBW 17: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 17: sig = 0x53425355 (valid), tag = 17, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense umass0:umass_bbb_dump_cbw: CBW 18: cmd = 10b (0x280000000001...), data = 512b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=512 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 18: sig = 0x53425355 (valid), tag = 18, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense umass0:umass_bbb_dump_cbw: CBW 19: cmd = 10b (0x280000000000...), data = 512b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=512 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 19: sig = 0x53425355 (valid), tag = 19, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 20: cmd = 10b (0x350000000000...), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 20: sig = 0x53425355 (valid), tag = 20, res = 0, status = 0x01 (failed) umass0:umass_t_bbb_status_callback: Command failed, residue = 0 umass0:umass_cam_cb: Fetching 32 bytes of sense data umass0:umass_bbb_dump_cbw: CBW 21: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 21: sig = 0x53425355 (valid), tag = 21, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 22: cmd = 6b (0x1e0000000000), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 22: sig = 0x53425355 (valid), tag = 22, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense umass0:umass_bbb_dump_cbw: CBW 23: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 23: sig = 0x53425355 (valid), tag = 23, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 24: cmd = 6b (0x1e0000000100), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 24: sig = 0x53425355 (valid), tag = 24, res = 0, status = 0x01 (failed) umass0:umass_t_bbb_status_callback: Command failed, residue = 0 umass0:umass_cam_cb: Fetching 32 bytes of sense data umass0:umass_bbb_dump_cbw: CBW 25: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 25: sig = 0x53425355 (valid), tag = 25, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 26: cmd = 10b (0x350000000000...), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 26: sig = 0x53425355 (valid), tag = 26, res = 0, status = 0x01 (failed) umass0:umass_t_bbb_status_callback: Command failed, residue = 0 umass0:umass_cam_cb: Fetching 32 bytes of sense data umass0:umass_bbb_dump_cbw: CBW 27: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 27: sig = 0x53425355 (valid), tag = 27, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 28: cmd = 6b (0x1e0000000000), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 28: sig = 0x53425355 (valid), tag = 28, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense umass0:umass_bbb_dump_cbw: CBW 29: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 29: sig = 0x53425355 (valid), tag = 29, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 30: cmd = 6b (0x1e0000000100), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 30: sig = 0x53425355 (valid), tag = 30, res = 0, status = 0x01 (failed) umass0:umass_t_bbb_status_callback: Command failed, residue = 0 umass0:umass_cam_cb: Fetching 32 bytes of sense data umass0:umass_bbb_dump_cbw: CBW 31: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 31: sig = 0x53425355 (valid), tag = 31, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 32: cmd = 10b (0x350000000000...), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 32: sig = 0x53425355 (valid), tag = 32, res = 0, status = 0x01 (failed) umass0:umass_t_bbb_status_callback: Command failed, residue = 0 umass0:umass_cam_cb: Fetching 32 bytes of sense data umass0:umass_bbb_dump_cbw: CBW 33: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 33: sig = 0x53425355 (valid), tag = 33, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 34: cmd = 6b (0x1e0000000000), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 34: sig = 0x53425355 (valid), tag = 34, res = 0, status = 0x00 (good) I tried a memory stick from another manufacturer that worked without problems. Here is the output for comparison: umass0: umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:umass_cam_action: 0:-1:-1:XPT_PATH_INQ:. umass0:0:0:-1: Attached to scbus0 umass0:umass_cam_rescan: scbus0: scanning for 0:0:-1 umass0:umass_cam_action: 0:-1:-1:XPT_PATH_INQ:. umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense umass0:umass_bbb_dump_cbw: CBW 1: cmd = 6b (0x120000002400), data = 36b, lun = 0, dir = in umass0:umass_attach: Attach finished umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=36 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 1: sig = 0x53425355 (valid), tag = 1, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense umass0:umass_bbb_dump_cbw: CBW 2: cmd = 6b (0x12018000ff00), data = 255b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=255 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 2: sig = 0x53425355 (valid), tag = 2, res = 219, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_GET_TRAN_SETTINGS:. umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. umass0:umass_cam_action: 0:0:0:XPT_GET_TRAN_SETTINGS:. umass0:umass_cam_action: 0:0:0:XPT_SET_TRAN_SETTINGS:. umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 3: cmd = 6b (0x000000000000), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 3: sig = 0x53425355 (valid), tag = 3, res = 0, status = 0x01 (failed) umass0:umass_t_bbb_status_callback: Command failed, residue = 0 umass0:umass_cam_cb: Fetching 32 bytes of sense data umass0:umass_bbb_dump_cbw: CBW 4: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 4: sig = 0x53425355 (valid), tag = 4, res = 14, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense umass0:umass_bbb_dump_cbw: CBW 5: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in umassX:umass_cam_rescan_callback: xpt0: Rescan succeeded umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 5: sig = 0x53425355 (valid), tag = 5, res = 0, status = 0x00 (good) da0 at umass-sim0 bus 0 target 0 lun 0 da0: < > Fixed Direct Access SCSI-0 device umass0:umass_cam_action: 0:0:0:XPT_GET_TRAN_SETTINGS:. umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. da0: 40.000MB/s transfers da0: 1000MB (2048000 512 byte sectors: 64H 32S/T 1000C) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense umass0:umass_bbb_dump_cbw: CBW 6: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 6: sig = 0x53425355 (valid), tag = 6, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense umass0:umass_bbb_dump_cbw: CBW 7: cmd = 10b (0x280000000000...), data = 512b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=512 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 7: sig = 0x53425355 (valid), tag = 7, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 8: cmd = 10b (0x350000000000...), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 8: sig = 0x53425355 (valid), tag = 8, res = 0, status = 0x01 (failed) umass0:umass_t_bbb_status_callback: Command failed, residue = 0 umass0:umass_cam_cb: Fetching 32 bytes of sense data umass0:umass_bbb_dump_cbw: CBW 9: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 9: sig = 0x53425355 (valid), tag = 9, res = 14, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense umass0:umass_bbb_dump_cbw: CBW 10: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 10: sig = 0x53425355 (valid), tag = 10, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense umass0:umass_bbb_dump_cbw: CBW 11: cmd = 10b (0x280000000001...), data = 512b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=512 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 11: sig = 0x53425355 (valid), tag = 11, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense umass0:umass_bbb_dump_cbw: CBW 12: cmd = 10b (0x280000000000...), data = 512b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=512 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 12: sig = 0x53425355 (valid), tag = 12, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 13: cmd = 10b (0x350000000000...), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 13: sig = 0x53425355 (valid), tag = 13, res = 0, status = 0x01 (failed) umass0:umass_t_bbb_status_callback: Command failed, residue = 0 umass0:umass_cam_cb: Fetching 32 bytes of sense data umass0:umass_bbb_dump_cbw: CBW 14: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 14: sig = 0x53425355 (valid), tag = 14, res = 14, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense umass0:umass_bbb_dump_cbw: CBW 15: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 15: sig = 0x53425355 (valid), tag = 15, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 16: cmd = 10b (0x350000000000...), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 16: sig = 0x53425355 (valid), tag = 16, res = 0, status = 0x01 (failed) umass0:umass_t_bbb_status_callback: Command failed, residue = 0 umass0:umass_cam_cb: Fetching 32 bytes of sense data umass0:umass_bbb_dump_cbw: CBW 17: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 17: sig = 0x53425355 (valid), tag = 17, res = 14, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense umass0:umass_bbb_dump_cbw: CBW 18: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 18: sig = 0x53425355 (valid), tag = 18, res = 0, status = 0x00 (good) umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense umass0:umass_bbb_dump_cbw: CBW 19: cmd = 10b (0x350000000000...), data = 0b, lun = 0, dir = out umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 19: sig = 0x53425355 (valid), tag = 19, res = 0, status = 0x01 (failed) umass0:umass_t_bbb_status_callback: Command failed, residue = 0 umass0:umass_cam_cb: Fetching 32 bytes of sense data umass0:umass_bbb_dump_cbw: CBW 20: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in umass0:umass_transfer_start: transfer index = 4 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass0:umass_transfer_start: transfer index = 8 umass0:umass_bbb_dump_csw: CSW 20: sig = 0x53425355 (valid), tag = 20, res = 14, status = 0x00 (good) Tell me if you need more information. -- Regards, Markus Henschel Development BALLY WULFF Automaten GmbH Maybachufer 48-51 12045 Berlin Phone: +49(30)62002 161 FAX: +49(30)62002 230 http://www.ballywulff.de From owner-freebsd-usb@FreeBSD.ORG Wed Mar 28 14:28:54 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33D8F16A403 for ; Wed, 28 Mar 2007 14:28:54 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id C11F913C469 for ; Wed, 28 Mar 2007 14:28:52 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe04.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 449495317; Wed, 28 Mar 2007 16:28:50 +0200 From: Hans Petter Selasky To: Markus Henschel Date: Wed, 28 Mar 2007 16:28:30 +0200 User-Agent: KMail/1.9.5 References: <200703271940.l2RJe90x058558@freefall.freebsd.org> <460A3861.3000207@bally-wulff.de> In-Reply-To: <460A3861.3000207@bally-wulff.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703281628.30878.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full 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, 28 Mar 2007 14:28:54 -0000 On Wednesday 28 March 2007 11:41, Markus Henschel wrote: > Hans Petter Selasky schrieb: > > The following reply was made to PR usb/110855; it has been noted by > > GNATS. > > > > Hi, > Could you edit /sys/dev/usb/umass.c Then lookup: usbd_delay_ms(uaa->device, 1000); Change it into: usbd_delay_ms(uaa->device, 5000); Then lookup in the function "umass_attach()": sc->sc_last_xfer_index = UMASS_T_BBB_COMMAND; and change it into: sc->sc_last_xfer_index = UMASS_T_BBB_RESET2; Compile a new kernel and see what happens when you plug the stick again. --HPS From owner-freebsd-usb@FreeBSD.ORG Wed Mar 28 15:05:35 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A84F16A401 for ; Wed, 28 Mar 2007 15:05:35 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: from mail.bindone.de (sidewinder.bindone.de [62.146.109.98]) by mx1.freebsd.org (Postfix) with SMTP id C296D13C457 for ; Wed, 28 Mar 2007 15:05:34 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: (qmail 53482 invoked from network); 28 Mar 2007 15:02:32 -0000 Received: from unknown (HELO bombat.bindone.de) (84.151.241.193) by mail.bindone.de with SMTP; 28 Mar 2007 15:02:32 -0000 Message-ID: <460A8439.70107@bindone.de> Date: Wed, 28 Mar 2007 17:05:29 +0200 From: grem User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.2) Gecko/20070318 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-usb@freebsd.org References: <4609D885.8070505@bindone.de> <20070328080000.bhakk1rou88ww8ks@webmail.leidinger.net> In-Reply-To: <20070328080000.bhakk1rou88ww8ks@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Support for new device, important fix and enhancement to umass.c 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, 28 Mar 2007 15:05:35 -0000 Hi Alexander, Alexander Leidinger wrote: > Quoting grem (from Wed, 28 Mar 2007 04:52:53 > +0200): > > [analysis of the problem] > >> Any feedback is welcome, since I'm not an expert in how USB works/is >> implemented in FreeBSD. > > Please submit this as a problem report. Quirks have to be registered in > GNATS before we can commit them so that we are able to reevaluate them > if the need arises. I thought that is only true for new quirks (IGNORE_RESIDUE is an already existing quirk). Do you have a link that describes how to do it (in the least possible amount of time), PR + potentially GNATS. Then again, I would have to file different PRs, cause one is critical while the others are feature requests? > >> @@ -1665,6 +1673,8 @@ >> USETDW(sc->csw.dCSWSignature, >> CSWSIGNATURE); >> } >> >> + if (sc->quirks & IGNORE_RESIDUE) >> + USETDW(sc->csw.dCSWDataResidue, 0); >> int Residue; >> Residue = UGETDW(sc->csw.dCSWDataResidue); >> if (Residue == 0 && > > Wrong indent for the USETDW line. Hey c'mon, copy and paste :) > I don't know much about the USB code. > If the residue is not used somewhere else, wouldn't it be better to do > "if quirk set the Residue variable to 0 else get it from the device" The logic is: "If quirk is set, calculate residue, otherwise get it and if it's not 0 calculate it" Although maybe the original logic is suboptimal, and it would be best todo sth like: int Residue; if ((sc->quirks & IGNORE_RESIDUE) || !(Residue = UGETDW(sc->csw.dCSWDataResidue))) Residue = sc->transfer_datalen - sc->transfer_actlen; Since the extra check for (sc->transfer_datalen - sc->transfer_actlen) in the original code seems redundant. /michael From owner-freebsd-usb@FreeBSD.ORG Wed Mar 28 15:43:30 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C322E16A404 for ; Wed, 28 Mar 2007 15:43:30 +0000 (UTC) (envelope-from m.henschel@bally-wulff.de) Received: from mail2.bally-wulff-berlin.de (mail2.bally-wulff-berlin.de [212.144.118.9]) by mx1.freebsd.org (Postfix) with ESMTP id 7D46413C4BF for ; Wed, 28 Mar 2007 15:43:28 +0000 (UTC) (envelope-from m.henschel@bally-wulff.de) Message-ID: <460A8D1C.7090604@bally-wulff.de> Date: Wed, 28 Mar 2007 17:43:24 +0200 From: Markus Henschel MIME-Version: 1.0 To: Hans Petter Selasky References: <200703271940.l2RJe90x058558@freefall.freebsd.org> <460A3861.3000207@bally-wulff.de> <200703281628.30878.hselasky@c2i.net> In-Reply-To: <200703281628.30878.hselasky@c2i.net> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2007 15:43:24.0345 (UTC) FILETIME=[D2081A90:01C7714F] Cc: freebsd-usb@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full 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, 28 Mar 2007 15:43:30 -0000 Hans Petter Selasky schrieb: > On Wednesday 28 March 2007 11:41, Markus Henschel wrote: >> Hans Petter Selasky schrieb: >>> The following reply was made to PR usb/110855; it has been noted by >>> GNATS. >>> >> Hi, >> > > Could you edit /sys/dev/usb/umass.c > > Then lookup: > > usbd_delay_ms(uaa->device, 1000); > > Change it into: > > usbd_delay_ms(uaa->device, 5000); > > Then lookup in the function "umass_attach()": > > sc->sc_last_xfer_index = UMASS_T_BBB_COMMAND; > > and change it into: > > sc->sc_last_xfer_index = UMASS_T_BBB_RESET2; > > Compile a new kernel and see what happens when you plug the stick again. > > --HPS > Hello again, the 1st stick is working now ("JetFlash Mass Storage Device") but the other stick that worked fine before ("LG USB DRIVE) has problems being detected now. The "main" device node /dev/da0 is created but not the node for the 1st partition /dev/da0s1, even after minutes. But when I try to mount /dev/da0 directly (which doesn't make sense) the command fails but suddenly /dev/da0s1 appears and is usable. Should I try to decrease the delay again? Here is the dmesg output: > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0: Max Lun is 0 > umass0:0:-1:-1:XPT_PATH_INQ:. > umass0:0:0:-1: Attached to scbus0 > umass0: Attach finished > scbus0: scanning for umass0:0:0:-1 > umass0:0:-1:-1:XPT_PATH_INQ:. > umass0:0:0:0:XPT_PATH_INQ:. > umass0:0:0:0:XPT_PATH_INQ:. > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense > umass0: CBW 1: cmd = 6b (0x120000002400), data = 36b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 008002021f0000004c47202020202020 buffer=0xc425ee84, buflen=36 > umass0: 0x 55534220445249564520202020202020 > umass0: 0x 322e3030 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 1: sig = 0x53425355 (valid), tag = 1, res = 0, status = 0x00 (good) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense > umass0: CBW 2: cmd = 6b (0x12018000ff00), data = 255b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 008002021f0000004c47202020202020 buffer=0xc4686e00, buflen=255 > umass0: 0x 55534220445249564520202020202020 > umass0: 0x 322e3030000000000000000000000000 ... > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 2: sig = 0x53425355 (valid), tag = 2, res = 219, status = 0x00 (good) > umass0:0:0:0:XPT_GET_TRAN_SETTINGS:. > umass0:0:0:0:XPT_PATH_INQ:. > umass0:0:0:0:XPT_GET_TRAN_SETTINGS:. > umass0:0:0:0:XPT_SET_TRAN_SETTINGS:. > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense > umass0: CBW 3: cmd = 6b (0x000000000000), data = 0b, dir = out > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: no data phase > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 3: sig = 0x53425355 (valid), tag = 3, res = 0, status = 0x01 (failed) > umass0: Command Failed, res = 0 > umass0: Fetching 32b sense data > umass0: CBW 4: cmd = 6b (0x030000002000), data = 32b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 700006000000000a0000000028000000 buffer=0xc3cbe870, buflen=32 > umass0: 0x 00000000000000000000000000000000 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 4: sig = 0x53425355 (valid), tag = 4, res = 14, status = 0x00 (good) > umass0:0:0:0:XPT_PATH_INQ:. > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0: CBW 5: cmd = 10b (0x250000000000...), data = 8b, dir = in > xpt0: Rescan succeeded > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_STALLED > umass0: Data-in 8b failed, USBD_STALLED > umass0: Clear endpoint 0x81 stall > umass0: Handling BBB state 4 (BBB Data bulk-in/-out clear stall), xfer=0xc4687100, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 5: sig = 0x53425355 (valid), tag = 5, res = 8, status = 0x01 (failed) > umass0: Command Failed, res = 8 > umass0: Fetching 32b sense data > umass0: CBW 6: cmd = 6b (0x030000002000), data = 32b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 700006000000000a0000000028000000 buffer=0xc3cbe870, buflen=32 > umass0: 0x 00000000000000000000000000000000 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 6: sig = 0x53425355 (valid), tag = 6, res = 14, status = 0x00 (good) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0: CBW 7: cmd = 10b (0x250000000000...), data = 8b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_STALLED > umass0: Data-in 8b failed, USBD_STALLED > umass0: Clear endpoint 0x81 stall > umass0: Handling BBB state 4 (BBB Data bulk-in/-out clear stall), xfer=0xc4687100, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 7: sig = 0x53425355 (valid), tag = 7, res = 8, status = 0x01 (failed) > umass0: Command Failed, res = 8 > umass0: Fetching 32b sense data > umass0: CBW 8: cmd = 6b (0x030000002000), data = 32b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 700006000000000a0000000028000000 buffer=0xc3cbe870, buflen=32 > umass0: 0x 00000000000000000000000000000000 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 8: sig = 0x53425355 (valid), tag = 8, res = 14, status = 0x00 (good) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0: CBW 9: cmd = 10b (0x250000000000...), data = 8b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_STALLED > umass0: Data-in 8b failed, USBD_STALLED > umass0: Clear endpoint 0x81 stall > umass0: Handling BBB state 4 (BBB Data bulk-in/-out clear stall), xfer=0xc4687100, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 9: sig = 0x53425355 (valid), tag = 9, res = 8, status = 0x01 (failed) > umass0: Command Failed, res = 8 > umass0: Fetching 32b sense data > umass0: CBW 10: cmd = 6b (0x030000002000), data = 32b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 700006000000000a0000000028000000 buffer=0xc3cbe870, buflen=32 > umass0: 0x 00000000000000000000000000000000 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 10: sig = 0x53425355 (valid), tag = 10, res = 14, status = 0x00 (good) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0: CBW 11: cmd = 10b (0x250000000000...), data = 8b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_STALLED > umass0: Data-in 8b failed, USBD_STALLED > umass0: Clear endpoint 0x81 stall > umass0: Handling BBB state 4 (BBB Data bulk-in/-out clear stall), xfer=0xc4687100, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 11: sig = 0x53425355 (valid), tag = 11, res = 8, status = 0x01 (failed) > umass0: Command Failed, res = 8 > umass0: Fetching 32b sense data > umass0: CBW 12: cmd = 6b (0x030000002000), data = 32b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 700006000000000a0000000028000000 buffer=0xc3cbe870, buflen=32 > umass0: 0x 00000000000000000000000000000000 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 12: sig = 0x53425355 (valid), tag = 12, res = 14, status = 0x00 (good) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0: CBW 13: cmd = 10b (0x250000000000...), data = 8b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_STALLED > umass0: Data-in 8b failed, USBD_STALLED > umass0: Clear endpoint 0x81 stall > umass0: Handling BBB state 4 (BBB Data bulk-in/-out clear stall), xfer=0xc4687100, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 13: sig = 0x53425355 (valid), tag = 13, res = 8, status = 0x01 (failed) > umass0: Command Failed, res = 8 > umass0: Fetching 32b sense data > umass0: CBW 14: cmd = 6b (0x030000002000), data = 32b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 700006000000000a0000000028000000 buffer=0xc3cbe870, buflen=32 > umass0: 0x 00000000000000000000000000000000 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 14: sig = 0x53425355 (valid), tag = 14, res = 14, status = 0x00 (good) > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-2 device > umass0:0:0:0:XPT_GET_TRAN_SETTINGS:. > umass0:0:0:0:XPT_PATH_INQ:. > da0: 40.000MB/s transfers > da0: Attempt to query device size failed: UNIT ATTENTION, Not ready to ready change, > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0: CBW 15: cmd = 10b (0x250000000000...), data = 8b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_STALLED > umass0: Data-in 8b failed, USBD_STALLED > umass0: Clear endpoint 0x81 stall > umass0: Handling BBB state 4 (BBB Data bulk-in/-out clear stall), xfer=0xc4687100, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 15: sig = 0x53425355 (valid), tag = 15, res = 8, status = 0x01 (failed) > umass0: Command Failed, res = 8 > umass0: Fetching 32b sense data > umass0: CBW 16: cmd = 6b (0x030000002000), data = 32b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 700006000000000a0000000028000000 buffer=0xc3cbe870, buflen=32 > umass0: 0x 00000000000000000000000000000000 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 16: sig = 0x53425355 (valid), tag = 16, res = 14, status = 0x00 (good) > (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > (da0:umass-sim0:0:0:0): SCSI Status: Check Condition > (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 > (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed > (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0: CBW 17: cmd = 10b (0x250000000000...), data = 8b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_STALLED > umass0: Data-in 8b failed, USBD_STALLED > umass0: Clear endpoint 0x81 stall > umass0: Handling BBB state 4 (BBB Data bulk-in/-out clear stall), xfer=0xc4687100, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 17: sig = 0x53425355 (valid), tag = 17, res = 8, status = 0x01 (failed) > umass0: Command Failed, res = 8 > umass0: Fetching 32b sense data > umass0: CBW 18: cmd = 6b (0x030000002000), data = 32b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 700006000000000a0000000028000000 buffer=0xc3cbe870, buflen=32 > umass0: 0x 00000000000000000000000000000000 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 18: sig = 0x53425355 (valid), tag = 18, res = 14, status = 0x00 (good) > (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > (da0:umass-sim0:0:0:0): SCSI Status: Check Condition > (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 > (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed > (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0: CBW 19: cmd = 10b (0x250000000000...), data = 8b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_STALLED > umass0: Data-in 8b failed, USBD_STALLED > umass0: Clear endpoint 0x81 stall > umass0: Handling BBB state 4 (BBB Data bulk-in/-out clear stall), xfer=0xc4687100, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 19: sig = 0x53425355 (valid), tag = 19, res = 8, status = 0x01 (failed) > umass0: Command Failed, res = 8 > umass0: Fetching 32b sense data > umass0: CBW 20: cmd = 6b (0x030000002000), data = 32b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 700006000000000a0000000028000000 buffer=0xc3cbe870, buflen=32 > umass0: 0x 00000000000000000000000000000000 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 20: sig = 0x53425355 (valid), tag = 20, res = 14, status = 0x00 (good) > (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > (da0:umass-sim0:0:0:0): SCSI Status: Check Condition > (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 > (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed > (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0: CBW 21: cmd = 10b (0x250000000000...), data = 8b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_STALLED > umass0: Data-in 8b failed, USBD_STALLED > umass0: Clear endpoint 0x81 stall > umass0: Handling BBB state 4 (BBB Data bulk-in/-out clear stall), xfer=0xc4687100, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 21: sig = 0x53425355 (valid), tag = 21, res = 8, status = 0x01 (failed) > umass0: Command Failed, res = 8 > umass0: Fetching 32b sense data > umass0: CBW 22: cmd = 6b (0x030000002000), data = 32b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 700006000000000a0000000028000000 buffer=0xc3cbe870, buflen=32 > umass0: 0x 00000000000000000000000000000000 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 22: sig = 0x53425355 (valid), tag = 22, res = 14, status = 0x00 (good) > (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > (da0:umass-sim0:0:0:0): SCSI Status: Check Condition > (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 > (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed > (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0: CBW 23: cmd = 10b (0x250000000000...), data = 8b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_STALLED > umass0: Data-in 8b failed, USBD_STALLED > umass0: Clear endpoint 0x81 stall > umass0: Handling BBB state 4 (BBB Data bulk-in/-out clear stall), xfer=0xc4687100, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 23: sig = 0x53425355 (valid), tag = 23, res = 8, status = 0x01 (failed) > umass0: Command Failed, res = 8 > umass0: Fetching 32b sense data > umass0: CBW 24: cmd = 6b (0x030000002000), data = 32b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 700006000000000a0000000028000000 buffer=0xc3cbe870, buflen=32 > umass0: 0x 00000000000000000000000000000000 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 24: sig = 0x53425355 (valid), tag = 24, res = 14, status = 0x00 (good) > (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > (da0:umass-sim0:0:0:0): SCSI Status: Check Condition > (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 > (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed > (da0:umass-sim0:0:0:0): Retries Exhausted > Opened disk da0 -> 6 > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0: CBW 25: cmd = 10b (0x250000000000...), data = 8b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 001f3fff00000200 buffer=0xc3cdfa50, buflen=8 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 25: sig = 0x53425355 (valid), tag = 25, res = 0, status = 0x00 (good) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0: CBW 26: cmd = 6b (0x1e0000000100), data = 0b, dir = out > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: no data phase > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 26: sig = 0x53425355 (valid), tag = 26, res = 0, status = 0x01 (failed) > umass0: Command Failed, res = 0 > umass0: Fetching 32b sense data > umass0: CBW 27: cmd = 6b (0x030000002000), data = 32b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 700005000000000a0000000024000000 buffer=0xc3cbe870, buflen=32 > umass0: 0x 00000000000000000000000000000000 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 27: sig = 0x53425355 (valid), tag = 27, res = 14, status = 0x00 (good) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense > umass0: CBW 28: cmd = 10b (0x280000000001...), data = 512b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 00000000000000000000000000000000 buffer=0xc446ac00, buflen=512 > umass0: 0x 00000000000000000000000000000000 > umass0: 0x 00000000000000000000000000000000 ... > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 28: sig = 0x53425355 (valid), tag = 28, res = 0, status = 0x00 (good) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense > umass0: CBW 29: cmd = 10b (0x280000000000...), data = 512b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x fa33c08ed0bc007c8bf45007501ffbfc buffer=0xc446a400, buflen=512 > umass0: 0x bf0006b90001f2a5ea1d060000bebe07 > umass0: 0x b304803c80740e803c00751c83c610fe ... > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 29: sig = 0x53425355 (valid), tag = 29, res = 0, status = 0x00 (good) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense > umass0: CBW 30: cmd = 10b (0x350000000000...), data = 0b, dir = out > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: no data phase > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 30: sig = 0x53425355 (valid), tag = 30, res = 0, status = 0x01 (failed) > umass0: Command Failed, res = 0 > umass0: Fetching 32b sense data > umass0: CBW 31: cmd = 6b (0x030000002000), data = 32b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 700005000000000a0000000020000000 buffer=0xc3cbe870, buflen=32 > umass0: 0x 00000000000000000000000000000000 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 31: sig = 0x53425355 (valid), tag = 31, res = 14, status = 0x00 (good) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0: CBW 32: cmd = 6b (0x1e0000000000), data = 0b, dir = out > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: no data phase > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 32: sig = 0x53425355 (valid), tag = 32, res = 0, status = 0x00 (good) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0: CBW 33: cmd = 10b (0x250000000000...), data = 8b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 001f3fff00000200 buffer=0xc3cdf7a0, buflen=8 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 33: sig = 0x53425355 (valid), tag = 33, res = 0, status = 0x00 (good) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0: CBW 34: cmd = 6b (0x1e0000000100), data = 0b, dir = out > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: no data phase > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 34: sig = 0x53425355 (valid), tag = 34, res = 0, status = 0x01 (failed) > umass0: Command Failed, res = 0 > umass0: Fetching 32b sense data > umass0: CBW 35: cmd = 6b (0x030000002000), data = 32b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 700005000000000a0000000024000000 buffer=0xc3cbe870, buflen=32 > umass0: 0x 00000000000000000000000000000000 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 35: sig = 0x53425355 (valid), tag = 35, res = 14, status = 0x00 (good) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/1024b data/32b sense > umass0: CBW 36: cmd = 10b (0x280000000000...), data = 1024b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x fa33c08ed0bc007c8bf45007501ffbfc buffer=0xc3be7800, buflen=1024 > umass0: 0x bf0006b90001f2a5ea1d060000bebe07 > umass0: 0x b304803c80740e803c00751c83c610fe ... > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 36: sig = 0x53425355 (valid), tag = 36, res = 0, status = 0x00 (good) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense > umass0: CBW 37: cmd = 10b (0x350000000000...), data = 0b, dir = out > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: no data phase > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 37: sig = 0x53425355 (valid), tag = 37, res = 0, status = 0x01 (failed) > umass0: Command Failed, res = 0 > umass0: Fetching 32b sense data > umass0: CBW 38: cmd = 6b (0x030000002000), data = 32b, dir = in > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: Handling BBB state 3 (BBB Data), xfer=0xc4687e00, USBD_NORMAL_COMPLETION > umass0: 0x 700005000000000a0000000020000000 buffer=0xc3cbe870, buflen=32 > umass0: 0x 00000000000000000000000000000000 > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 38: sig = 0x53425355 (valid), tag = 38, res = 14, status = 0x00 (good) > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0: CBW 39: cmd = 6b (0x1e0000000000), data = 0b, dir = out > umass0: Handling BBB state 2 (BBB CBW), xfer=0xc4688500, USBD_NORMAL_COMPLETION > umass0: no data phase > umass0: Handling BBB state 5 (BBB CSW, 1st attempt), xfer=0xc4687c00, USBD_NORMAL_COMPLETION > umass0: CSW 39: sig = 0x53425355 (valid), tag = 39, res = 0, status = 0x00 (good) -- Regards, Markus Henschel Development BALLY WULFF Automaten GmbH Maybachufer 48-51 12045 Berlin Phone: +49(30)62002 161 FAX: +49(30)62002 230 http://www.ballywulff.de From owner-freebsd-usb@FreeBSD.ORG Wed Mar 28 16:32:44 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B72BD16A400 for ; Wed, 28 Mar 2007 16:32:44 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 263B313C457 for ; Wed, 28 Mar 2007 16:32:43 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe08.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 448829025; Wed, 28 Mar 2007 18:32:42 +0200 From: Hans Petter Selasky To: Markus Henschel Date: Wed, 28 Mar 2007 18:32:22 +0200 User-Agent: KMail/1.9.5 References: <200703271940.l2RJe90x058558@freefall.freebsd.org> <200703281628.30878.hselasky@c2i.net> <460A8D1C.7090604@bally-wulff.de> In-Reply-To: <460A8D1C.7090604@bally-wulff.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703281832.22527.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full 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, 28 Mar 2007 16:32:44 -0000 On Wednesday 28 March 2007 17:43, Markus Henschel wrote: > Hans Petter Selasky schrieb: > > On Wednesday 28 March 2007 11:41, Markus Henschel wrote: > >> Hans Petter Selasky schrieb: > >>> The following reply was made to PR usb/110855; it has been noted by > >>> GNATS. > >> > >> Hi, > > > > Could you edit /sys/dev/usb/umass.c > > > > Then lookup: > > > > usbd_delay_ms(uaa->device, 1000); > > > > Change it into: > > > > usbd_delay_ms(uaa->device, 5000); > > > > Then lookup in the function "umass_attach()": > > > > sc->sc_last_xfer_index = UMASS_T_BBB_COMMAND; > > > > and change it into: > > > > sc->sc_last_xfer_index = UMASS_T_BBB_RESET2; > > > > Compile a new kernel and see what happens when you plug the stick again. > > > > --HPS > > Hello again, > > the 1st stick is working now ("JetFlash Mass Storage Device") but the > other stick that worked fine before ("LG USB DRIVE) has problems being > detected now. The "main" device node /dev/da0 is created but not the > node for the 1st partition /dev/da0s1, even after minutes. But when I > try to mount /dev/da0 directly (which doesn't make sense) the command > fails but suddenly /dev/da0s1 appears and is usable. Should I try to > This dmesg looks like it is from the old umass driver? > decrease the delay again? Here is the dmesg output: > > umass0: SCSI over Bulk-Only; quirks = 0x0000 > > umass0: Max Lun is 0 > > umass0:0:-1:-1:XPT_PATH_INQ:. > > umass0:0:0:-1: Attached to scbus0 > > umass0: Attach finished > > scbus0: scanning for umass0:0:0:-1 > > umass0:0:-1:-1:XPT_PATH_INQ:. > > umass0:0:0:0:XPT_PATH_INQ:. > > umass0:0:0:0:XPT_PATH_INQ:. > > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b Can you revert the changes you made to "umass.c" ? You can do this for example by copying "sys/dev/usb/umass.c" from the SVN repo to where you have your kernel sources. Then edit "sys/dev/usb/umass.c" again. Lookup the function "umass_t_bbb_status_callback()". Right below the label "tr_transferred" you add like this: tr_transferred: /* don't retry the status, but do a full reset if * there is something wrong with the CSW: */ sc->sc_status_try = 1; Compile a new kernel (or if you are smart, leave "device umass" out of the kernel config file and just recompile the "umass" module: sys/modules/umass) What happens now? --HPS From owner-freebsd-usb@FreeBSD.ORG Wed Mar 28 17:03:19 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6CBE16A405 for ; Wed, 28 Mar 2007 17:03:19 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: from mail.bindone.de (sidewinder.bindone.de [62.146.109.98]) by mx1.freebsd.org (Postfix) with SMTP id 393BD13C457 for ; Wed, 28 Mar 2007 17:03:18 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: (qmail 57629 invoked from network); 28 Mar 2007 17:00:16 -0000 Received: from unknown (HELO bombat.bindone.de) (84.151.241.193) by mail.bindone.de with SMTP; 28 Mar 2007 17:00:16 -0000 Message-ID: <460A9FD1.1040707@bindone.de> Date: Wed, 28 Mar 2007 19:03:13 +0200 From: grem User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.2) Gecko/20070318 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-usb@freebsd.org References: <4609D885.8070505@bindone.de> <20070328080000.bhakk1rou88ww8ks@webmail.leidinger.net> <460A71C8.4030005@bindone.de> <20070328174958.7000fbd3@Magellan.Leidinger.net> In-Reply-To: <20070328174958.7000fbd3@Magellan.Leidinger.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: Support for new device, important fix and enhancement to umass.c 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, 28 Mar 2007 17:03:19 -0000 Hi, I'll continue in English, just in case someone else is interested in this thread... Alexander Leidinger wrote: > Quoting grem (Wed, 28 Mar 2007 15:46:48 +0200): > >> Hi Alexander, >> >> Alexander Leidinger wrote: >>> Quoting grem (from Wed, 28 Mar 2007 04:52:53 >>> +0200): >>> >>> [analysis of the problem] >>> >>>> Any feedback is welcome, since I'm not an expert in how USB works/is >>>> implemented in FreeBSD. >>> Please submit this as a problem report. Quirks have to be registered in >>> GNATS before we can commit them so that we are able to reevaluate them >>> if the need arises. >> I thought that is only true for new quirks (IGNORE_RESIDUE is an already existing quirk). >> Do you have a link that describes how to do it (in the least possible amount of time), PR >> + potentially GNATS. > > Ok, ich formuliere um: Ein Quirk Eintrag für ein Device hat einen PR zu > haben. Du hast unten einen neues Device fuer den Quirk also brauchen > wir noch einen PR Eintrag. Ok, so all I have todo is find out how to post PRs (but I'm sure freebsd.org can help) > >> Then again, I would have to file different PRs, cause one is critical while the others are >> feature requests? > > Zwei PR wäre gut. Einmal der, der das Quirk-Handling fixt, und dann den > der den Quirk für Dein Device einträgt. Letzterer sollte den ersten als > Abhängigkeit referenzieren (es kann ein bischen dauern bis die Mail von > GNATS mit der PR Nummer des ersten PR ankommt). ok > >>>> @@ -1665,6 +1673,8 @@ >>>> USETDW(sc->csw.dCSWSignature, >>>> CSWSIGNATURE); >>>> } >>>> >>>> + if (sc->quirks & IGNORE_RESIDUE) >>>> + USETDW(sc->csw.dCSWDataResidue, 0); >>>> int Residue; >>>> Residue = UGETDW(sc->csw.dCSWDataResidue); >>>> if (Residue == 0 && >>> Wrong indent for the USETDW line. >> Hey c'mon, copy and paste :) >> >>> I don't know much about the USB code. >>> If the residue is not used somewhere else, wouldn't it be better to do >>> "if quirk set the Residue variable to 0 else get it from the device" >> The logic is: >> "If quirk is set, calculate residue, otherwise get it and if it's not 0 calculate it" >> Although maybe the original logic is suboptimal, and it would be best todo sth like: >> >> int Residue; >> if ((sc->quirks & IGNORE_RESIDUE) || !(Residue = UGETDW(sc->csw.dCSWDataResidue))) >> Residue = sc->transfer_datalen - sc->transfer_actlen; > > Ich dachte an > ---snip--- > int Residue; > if (sc->quirks & IGNORE_RESIDUE) > Residue = 0; > else > Residue = UGETDW(sc->csw.dCSWDataResidue); > ---snip--- > > Und der Rest unverändert. Ist das nicht OK? Geht natuerlich genauso :) The question is, if it wouldn't be better to fix sc->csw.dCSWDataResidue to the correct value, because it might be used somewhere else in the future and introduce obscure bugs (right now it's only used in a debug function). But that's beyond my knowledge of the sources. > > Bye, > Alexander. > bye michael ps: hab grad erfolgreich einen 100GB dump/restore cycle durchgefuehrt, laeuft also stabil. From owner-freebsd-usb@FreeBSD.ORG Wed Mar 28 18:27:25 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD1F916A400 for ; Wed, 28 Mar 2007 18:27:25 +0000 (UTC) (envelope-from m.henschel@bally-wulff.de) Received: from mail2.bally-wulff-berlin.de (mail2.bally-wulff-berlin.de [212.144.118.9]) by mx1.freebsd.org (Postfix) with ESMTP id AE85613C48C for ; Wed, 28 Mar 2007 18:27:24 +0000 (UTC) (envelope-from m.henschel@bally-wulff.de) Message-ID: <460AB387.20304@bally-wulff.de> Date: Wed, 28 Mar 2007 20:27:19 +0200 From: Markus Henschel MIME-Version: 1.0 To: Hans Petter Selasky References: <200703271940.l2RJe90x058558@freefall.freebsd.org> <200703281628.30878.hselasky@c2i.net> <460A8D1C.7090604@bally-wulff.de> <200703281832.22527.hselasky@c2i.net> In-Reply-To: <200703281832.22527.hselasky@c2i.net> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2007 18:27:19.0977 (UTC) FILETIME=[B8867190:01C77166] Cc: freebsd-usb@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full 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, 28 Mar 2007 18:27:26 -0000 Hans Petter Selasky schrieb: > > > Can you revert the changes you made to "umass.c" ? > > You can do this for example by copying "sys/dev/usb/umass.c" from the SVN repo > to where you have your kernel sources. > > Then edit "sys/dev/usb/umass.c" again. > > Lookup the function "umass_t_bbb_status_callback()". > > Right below the label "tr_transferred" you add like this: > > tr_transferred: > /* don't retry the status, but do a full reset if > * there is something wrong with the CSW: > */ > sc->sc_status_try = 1; > > Compile a new kernel (or if you are smart, leave "device umass" out of the > kernel config file and just recompile the "umass" module: sys/modules/umass) > > What happens now? > > --HPS > Mmmm, seems like I must have messed something up before. So I reapplied the changes to a clean system. The first stick says now. The !!!! mark the point where the hanging occurs. Changes: tr_transferred: /* don't retry the status, but do a full reset if * there is something wrong with the CSW: */ sc->sc_status_try = 1; Result: > umass0: > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0: Get Max Lun not supported (USBD_STALLED) > umass0:umass_cam_action: 0:-1:-1:XPT_PATH_INQ:. > umass0:0:0:-1: Attached to scbus0 > umass0:umass_cam_rescan: scbus0: scanning for 0:0:-1 > umass0:umass_cam_action: 0:-1:-1:XPT_PATH_INQ:. > umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. > umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense > umass0:umass_bbb_dump_cbw: CBW 1: cmd = 6b (0x120000002400), data = 36b, lun = 0, dir = in > umass0:umass_attach: Attach finishedumass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=36 > > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 274: sig = 0x28120799 (invalid), tag = 274, res = 134217728, status = 0x8f () > umass0:umass_t_bbb_status_callback: truncating residue from 134217728 to 36 bytes > umass0:umass_t_bbb_status_callback: bad CSW signature 0x28120799 != 0x53425355 > umass0:umass_t_bbb_status_callback: Failed to read CSW: USBD_NORMAL_COMPLETION, try 1 > umass0:umass_tr_error: transfer error, USBD_NORMAL_COMPLETION -> reset > umass0:umass_transfer_start: transfer index = 0 > umass0:umass_t_bbb_reset1_callback: BBB reset! > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense > umass0:umass_transfer_start: transfer index = 1 > umass0:umass_transfer_start: transfer index = 2 > umass0:umass_transfer_start: transfer index = 3 > umass0:umass_bbb_dump_cbw: CBW 2: cmd = 6b (0x120000002400), data = 36b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=36 !!!!! It hangs here for several seconds > umass0:umass_transfer_start: transfer index = 5 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_t_bbb_status_callback: Failed to read CSW: USBD_TIMEOUT, try 0 > umass0:umass_transfer_start: transfer index = 5 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_t_bbb_status_callback: Failed to read CSW: USBD_TIMEOUT, try 1 > umass0:umass_tr_error: transfer error, USBD_TIMEOUT -> reset > umass0:umass_transfer_start: transfer index = 0 > umass0:umass_t_bbb_reset1_callback: BBB reset! > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense > umass0:umass_transfer_start: transfer index = 1 > umass0:umass_transfer_start: transfer index = 2 > umass0:umass_transfer_start: transfer index = 3 > umass0:umass_bbb_dump_cbw: CBW 3: cmd = 6b (0x120000002400), data = 36b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=36 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 3: sig = 0x53425355 (valid), tag = 3, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense > umass0:umass_bbb_dump_cbw: CBW 4: cmd = 6b (0x12018000ff00), data = 255b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=255 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 4: sig = 0x53425355 (valid), tag = 4, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_GET_TRAN_SETTINGS:. > umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. > umass0:umass_cam_action: 0:0:0:XPT_GET_TRAN_SETTINGS:. > umass0:umass_cam_action: 0:0:0:XPT_SET_TRAN_SETTINGS:. > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 5: cmd = 6b (0x000000000000), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 5: sig = 0x53425355 (valid), tag = 5, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 6: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 6: sig = 0x53425355 (valid), tag = 6, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 7: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in > umassX:umass_cam_rescan_callback: xptumass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 > 0: Rescan suumass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > cceededumass0:umass_bbb_dump_csw: CSW 7: sig = 0x53425355 (valid), tag = 7, res = 0, status = 0x00 (good) > > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-2 device > umass0:umass_cam_action: 0:0:0:XPT_GET_TRAN_SETTINGS:. > umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. > da0: 40.000MB/s transfers > da0: 484MB (991232 512 byte sectors: 64H 32S/T 484C) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 8: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 8: sig = 0x53425355 (valid), tag = 8, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 9: cmd = 6b (0x1e0000000100), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 9: sig = 0x53425355 (valid), tag = 9, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 10: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 10: sig = 0x53425355 (valid), tag = 10, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 11: cmd = 10b (0x280000000000...), data = 512b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=512 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 11: sig = 0x53425355 (valid), tag = 11, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 12: cmd = 10b (0x350000000000...), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 12: sig = 0x53425355 (valid), tag = 12, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 13: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 13: sig = 0x53425355 (valid), tag = 13, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 14: cmd = 6b (0x1e0000000000), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 14: sig = 0x53425355 (valid), tag = 14, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 15: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 15: sig = 0x53425355 (valid), tag = 15, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 16: cmd = 6b (0x1e0000000100), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 16: sig = 0x53425355 (valid), tag = 16, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 17: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 17: sig = 0x53425355 (valid), tag = 17, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 18: cmd = 10b (0x280000000001...), data = 512b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=512 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 18: sig = 0x53425355 (valid), tag = 18, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 19: cmd = 10b (0x280000000000...), data = 512b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=512 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 19: sig = 0x53425355 (valid), tag = 19, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 20: cmd = 10b (0x350000000000...), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 20: sig = 0x53425355 (valid), tag = 20, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 21: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 21: sig = 0x53425355 (valid), tag = 21, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 22: cmd = 6b (0x1e0000000000), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 22: sig = 0x53425355 (valid), tag = 22, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 23: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 23: sig = 0x53425355 (valid), tag = 23, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 24: cmd = 6b (0x1e0000000100), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 24: sig = 0x53425355 (valid), tag = 24, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 25: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 25: sig = 0x53425355 (valid), tag = 25, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 26: cmd = 10b (0x350000000000...), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 26: sig = 0x53425355 (valid), tag = 26, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 27: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 27: sig = 0x53425355 (valid), tag = 27, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 28: cmd = 6b (0x1e0000000000), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 28: sig = 0x53425355 (valid), tag = 28, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 29: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 29: sig = 0x53425355 (valid), tag = 29, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 30: cmd = 6b (0x1e0000000100), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 30: sig = 0x53425355 (valid), tag = 30, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 31: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 31: sig = 0x53425355 (valid), tag = 31, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 32: cmd = 10b (0x350000000000...), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 32: sig = 0x53425355 (valid), tag = 32, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 33: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 33: sig = 0x53425355 (valid), tag = 33, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 34: cmd = 6b (0x1e0000000000), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 34: sig = 0x53425355 (valid), tag = 34, res = 0, status = 0x00 (good) Changes: usbd_delay_ms(uaa->device, 1000); --> usbd_delay_ms(uaa->device, 5000) sc->sc_last_xfer_index = UMASS_T_BBB_COMMAND; --> sc->sc_last_xfer_index = UMASS_T_BBB_RESET2; Result: > > umass0: detached > umass0: > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0: Get Max Lun not supported (USBD_STALLED) > umass0:umass_cam_action: 0:-1:-1:XPT_PATH_INQ:. > umass0:0:0:-1: Attached to scbus0 > umass0:umass_cam_rescan: scbus0: scanning for 0:0:-1 > umass0:umass_cam_action: 0:-1:-1:XPT_PATH_INQ:. > umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. > umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense > umass0:umass_attach: Attach finishedumass0:umass_transfer_start: transfer index = 2 > > umass0:umass_transfer_start: transfer index = 3 > umass0:umass_bbb_dump_cbw: CBW 1: cmd = 6b (0x120000002400), data = 36b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=36 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 274: sig = 0x28120799 (invalid), tag = 274, res = 134217728, status = 0x8f () > umass0:umass_t_bbb_status_callback: truncating residue from 134217728 to 36 bytes > umass0:umass_t_bbb_status_callback: bad CSW signature 0x28120799 != 0x53425355 > umass0:umass_t_bbb_status_callback: Failed to read CSW: USBD_NORMAL_COMPLETION, try 0 > umass0:umass_transfer_start: transfer index = 5 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_t_bbb_status_callback: Failed to read CSW: USBD_TIMEOUT, try 1 > umass0:umass_tr_error: transfer error, USBD_TIMEOUT -> reset > umass0:umass_transfer_start: transfer index = 0 > umass0:umass_t_bbb_reset1_callback: BBB reset! > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense > umass0:umass_transfer_start: transfer index = 1 > umass0:umass_transfer_start: transfer index = 2 > umass0:umass_transfer_start: transfer index = 3 > umass0:umass_bbb_dump_cbw: CBW 2: cmd = 6b (0x120000002400), data = 36b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=36 !!!!! It hangs here for several seconds > umass0:umass_transfer_start: transfer index = 5 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_t_bbb_status_callback: Failed to read CSW: USBD_TIMEOUT, try 0 > umass0:umass_transfer_start: transfer index = 5 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_t_bbb_status_callback: Failed to read CSW: USBD_TIMEOUT, try 1 > umass0:umass_tr_error: transfer error, USBD_TIMEOUT -> reset > umass0:umass_transfer_start: transfer index = 0 > umass0:umass_t_bbb_reset1_callback: BBB reset! > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense > umass0:umass_transfer_start: transfer index = 1 > umass0:umass_transfer_start: transfer index = 2 > umass0:umass_transfer_start: transfer index = 3 > umass0:umass_bbb_dump_cbw: CBW 3: cmd = 6b (0x120000002400), data = 36b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=36 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 3: sig = 0x53425355 (valid), tag = 3, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense > umass0:umass_bbb_dump_cbw: CBW 4: cmd = 6b (0x12018000ff00), data = 255b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=255 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 4: sig = 0x53425355 (valid), tag = 4, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_GET_TRAN_SETTINGS:. > umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. > umass0:umass_cam_action: 0:0:0:XPT_GET_TRAN_SETTINGS:. > umass0:umass_cam_action: 0:0:0:XPT_SET_TRAN_SETTINGS:. > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 5: cmd = 6b (0x000000000000), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 5: sig = 0x53425355 (valid), tag = 5, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 6: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 6: sig = 0x53425355 (valid), tag = 6, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 7: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in > umassX:umass_cam_rescan_callback:umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 > xpt0: Rescan suumass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > cceededumass0:umass_bbb_dump_csw: CSW 7: sig = 0x53425355 (valid), tag = 7, res = 0, status = 0x00 (good) > > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-2 device > umass0:umass_cam_action: 0:0:0:XPT_GET_TRAN_SETTINGS:. > umass0:umass_cam_action: 0:0:0:XPT_PATH_INQ:. > da0: 40.000MB/s transfers > da0: 484MB (991232 512 byte sectors: 64H 32S/T 484C) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 8: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 8: sig = 0x53425355 (valid), tag = 8, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 9: cmd = 6b (0x1e0000000100), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 9: sig = 0x53425355 (valid), tag = 9, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 10: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 10: sig = 0x53425355 (valid), tag = 10, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 11: cmd = 10b (0x280000000000...), data = 512b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=512 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 11: sig = 0x53425355 (valid), tag = 11, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 12: cmd = 10b (0x350000000000...), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 12: sig = 0x53425355 (valid), tag = 12, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 13: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 13: sig = 0x53425355 (valid), tag = 13, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 14: cmd = 6b (0x1e0000000000), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 14: sig = 0x53425355 (valid), tag = 14, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 15: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 15: sig = 0x53425355 (valid), tag = 15, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 16: cmd = 6b (0x1e0000000100), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 16: sig = 0x53425355 (valid), tag = 16, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 17: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 17: sig = 0x53425355 (valid), tag = 17, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 18: cmd = 10b (0x280000000001...), data = 512b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=512 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 18: sig = 0x53425355 (valid), tag = 18, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 19: cmd = 10b (0x280000000000...), data = 512b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=512 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 19: sig = 0x53425355 (valid), tag = 19, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 20: cmd = 10b (0x350000000000...), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 20: sig = 0x53425355 (valid), tag = 20, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 21: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 21: sig = 0x53425355 (valid), tag = 21, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 22: cmd = 6b (0x1e0000000000), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 22: sig = 0x53425355 (valid), tag = 22, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 23: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 23: sig = 0x53425355 (valid), tag = 23, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 24: cmd = 6b (0x1e0000000100), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 24: sig = 0x53425355 (valid), tag = 24, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 25: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 25: sig = 0x53425355 (valid), tag = 25, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 26: cmd = 10b (0x350000000000...), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 26: sig = 0x53425355 (valid), tag = 26, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 27: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 27: sig = 0x53425355 (valid), tag = 27, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 28: cmd = 6b (0x1e0000000000), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 28: sig = 0x53425355 (valid), tag = 28, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 29: cmd = 10b (0x250000000000...), data = 8b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=8 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 29: sig = 0x53425355 (valid), tag = 29, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 30: cmd = 6b (0x1e0000000100), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 30: sig = 0x53425355 (valid), tag = 30, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 31: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 31: sig = 0x53425355 (valid), tag = 31, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 32: cmd = 10b (0x350000000000...), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 32: sig = 0x53425355 (valid), tag = 32, res = 0, status = 0x01 (failed) > umass0:umass_t_bbb_status_callback: Command failed, residue = 0 > umass0:umass_cam_cb: Fetching 32 bytes of sense data > umass0:umass_bbb_dump_cbw: CBW 33: cmd = 6b (0x030000002000), data = 32b, lun = 0, dir = in > umass0:umass_transfer_start: transfer index = 4 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 > umass0:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 33: sig = 0x53425355 (valid), tag = 33, res = 0, status = 0x00 (good) > umass0:umass_cam_action: 0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:umass_bbb_dump_cbw: CBW 34: cmd = 6b (0x1e0000000000), data = 0b, lun = 0, dir = out > umass0:umass_transfer_start: transfer index = 8 > umass0:umass_bbb_dump_csw: CSW 34: sig = 0x53425355 (valid), tag = 34, res = 0, status = 0x00 (good) Thank you for your time. Let me know if you want me to try other changes. May be it would be easier if you could create a branch in svn with the changes needed? -- Regards, Markus Henschel Development BALLY WULFF Automaten GmbH Maybachufer 48-51 12045 Berlin Phone: +49(30)62002 161 FAX: +49(30)62002 230 http://www.ballywulff.de From owner-freebsd-usb@FreeBSD.ORG Thu Mar 29 00:20:03 2007 Return-Path: X-Original-To: freebsd-usb@hub.freebsd.org Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 515AC16A409 for ; Thu, 29 Mar 2007 00:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 3284013C44B for ; Thu, 29 Mar 2007 00:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2T0K3Nj010141 for ; Thu, 29 Mar 2007 00:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2T0K2pa010139; Thu, 29 Mar 2007 00:20:02 GMT (envelope-from gnats) Resent-Date: Thu, 29 Mar 2007 00:20:02 GMT Resent-Message-Id: <200703290020.l2T0K2pa010139@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, Michael Gmelin Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF1B716A401 for ; Thu, 29 Mar 2007 00:16:11 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [69.147.83.33]) by mx1.freebsd.org (Postfix) with ESMTP id D0EBE13C459 for ; Thu, 29 Mar 2007 00:16:11 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id l2T0GBUA037127 for ; Thu, 29 Mar 2007 00:16:11 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id l2T0BAKa035949; Thu, 29 Mar 2007 00:11:10 GMT (envelope-from nobody) Message-Id: <200703290011.l2T0BAKa035949@www.freebsd.org> Date: Thu, 29 Mar 2007 00:11:10 GMT From: Michael Gmelin To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.0 Cc: Subject: usb/110988: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken 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, 29 Mar 2007 00:20:03 -0000 >Number: 110988 >Category: usb >Synopsis: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Mar 29 00:20:02 GMT 2007 >Closed-Date: >Last-Modified: >Originator: Michael Gmelin >Release: FreeBSD 6.2-RELEASE-p3 i386 >Organization: /bin/done digital solutions GmbH >Environment: FreeBSD bombat.bindone.de 6.2-RELEASE-p3 FreeBSD 6.2-RELEASE-p3 #21: Wed Mar 28 04:08:44 CEST 2007 root@bombat.bindone.de:/usr/src/sys/i386/compile/bombat i386 >Description: I had to add a new device to usbdevs/umass.c which requires the IGNORE_RESIDUE quirk to be set (extra PR will follow). It didn't work, because IGNORE_RESIDUE isn't handled properly in umass.c (it isn't really handled at all, since Residue is set in lines are 1668-1672 in umass.c in the following was: int Residue; Residue = UGETDW(sc->csw.dCSWDataResidue); if (Residue == 0 && sc->transfer_datalen - sc->transfer_actlen != 0) Residue = sc->transfer_datalen - sc->transfer_actlen; The patch below fixes this issue (tested and proven to work). >How-To-Repeat: Use a really broken USB device which returns "random" values for sc->csw.dCSWDataResidue (like devices that use the SuperTop IDEDEVICE USB controller, e.g. the ICY BOX IB-220U-Wh). Every attempt to use the device will lead to error messages, like: dd if=/dev/zero of=/dev/da0 count=10 da0: end of device or disklabel da0 read: Unknown error etc. >Fix: Apply the attached patch, which forces residue to be calculated if IGNORE_RESIDUE is set. Patch attached with submission follows: --- umass.c.orig Thu Mar 29 02:07:04 2007 +++ umass.c Thu Mar 29 02:08:06 2007 @@ -1666,7 +1666,10 @@ } int Residue; - Residue = UGETDW(sc->csw.dCSWDataResidue); + if (sc->quirks & IGNORE_RESIDUE) + Residue = 0; + else + Residue = UGETDW(sc->csw.dCSWDataResidue); if (Residue == 0 && sc->transfer_datalen - sc->transfer_actlen != 0) Residue = sc->transfer_datalen - sc->transfer_actlen; >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-usb@FreeBSD.ORG Thu Mar 29 00:30:09 2007 Return-Path: X-Original-To: freebsd-usb@hub.freebsd.org Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E77B716A408 for ; Thu, 29 Mar 2007 00:30:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id C95ED13C46C for ; Thu, 29 Mar 2007 00:30:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2T0U9FL011272 for ; Thu, 29 Mar 2007 00:30:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2T0U9K9011271; Thu, 29 Mar 2007 00:30:09 GMT (envelope-from gnats) Resent-Date: Thu, 29 Mar 2007 00:30:09 GMT Resent-Message-Id: <200703290030.l2T0U9K9011271@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, Michael Gmelin Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8A5F16A400 for ; Thu, 29 Mar 2007 00:22:35 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [69.147.83.33]) by mx1.freebsd.org (Postfix) with ESMTP id BA4D113C459 for ; Thu, 29 Mar 2007 00:22:35 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id l2T0MZ1O038123 for ; Thu, 29 Mar 2007 00:22:35 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id l2T0HXe9037447; Thu, 29 Mar 2007 00:17:33 GMT (envelope-from nobody) Message-Id: <200703290017.l2T0HXe9037447@www.freebsd.org> Date: Thu, 29 Mar 2007 00:17:33 GMT From: Michael Gmelin To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.0 Cc: Subject: usb/110989: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken 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, 29 Mar 2007 00:30:10 -0000 >Number: 110989 >Category: usb >Synopsis: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Mar 29 00:30:09 GMT 2007 >Closed-Date: >Last-Modified: >Originator: Michael Gmelin >Release: FreeBSD 6.2-RELEASE-p3 i386 >Organization: /bin/done digital solutions GmbH >Environment: FreeBSD bombat.bindone.de 6.2-RELEASE-p3 FreeBSD 6.2-RELEASE-p3 #21: Wed Mar 28 04:08:44 CEST 2007 root@bombat.bindone.de:/usr/src/sys/i386/compile/bombat i386 >Description: I had to add a new device to usbdevs/umass.c which requires the IGNORE_RESIDUE quirk to be set (extra PR will follow). It didn't work, because IGNORE_RESIDUE isn't handled properly in umass.c (it isn't really handled at all, since Residue is set in lines are 1668-1672 in umass.c in the following was: int Residue; Residue = UGETDW(sc->csw.dCSWDataResidue); if (Residue == 0 && sc->transfer_datalen - sc->transfer_actlen != 0) Residue = sc->transfer_datalen - sc->transfer_actlen; The patch below fixes this issue (tested and proven to work). >How-To-Repeat: Use a really broken USB device which returns "random" values for sc->csw.dCSWDataResidue (like devices that use the SuperTop IDEDEVICE USB controller, e.g. the ICY BOX IB-220U-Wh). Every attempt to use the device will lead to error messages, like: dd if=/dev/zero of=/dev/da0 count=10 da0: end of device or disklabel da0 read: Unknown error etc. >Fix: Apply the attached patch, which forces residue to be calculated if IGNORE_RESIDUE is set. Patch attached with submission follows: --- umass.c.orig Thu Mar 29 02:07:04 2007 +++ umass.c Thu Mar 29 02:08:06 2007 @@ -1666,7 +1666,10 @@ } int Residue; - Residue = UGETDW(sc->csw.dCSWDataResidue); + if (sc->quirks & IGNORE_RESIDUE) + Residue = 0; + else + Residue = UGETDW(sc->csw.dCSWDataResidue); if (Residue == 0 && sc->transfer_datalen - sc->transfer_actlen != 0) Residue = sc->transfer_datalen - sc->transfer_actlen; >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-usb@FreeBSD.ORG Thu Mar 29 01:10:15 2007 Return-Path: X-Original-To: freebsd-usb@hub.freebsd.org Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF19216A406 for ; Thu, 29 Mar 2007 01:10:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id B5DD813C459 for ; Thu, 29 Mar 2007 01:10:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2T1AFWI019183 for ; Thu, 29 Mar 2007 01:10:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2T1AF8r019182; Thu, 29 Mar 2007 01:10:15 GMT (envelope-from gnats) Date: Thu, 29 Mar 2007 01:10:15 GMT Message-Id: <200703290110.l2T1AF8r019182@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: grem Cc: Subject: Re: usb/110989: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: grem List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 01:10:16 -0000 The following reply was made to PR usb/110989; it has been noted by GNATS. From: grem To: bug-followup@FreeBSD.org, freebsdusb@bindone.de Cc: Subject: Re: usb/110989: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken Date: Thu, 29 Mar 2007 02:42:04 +0200 This is a duplicate of usb/110988, please close. (sorry, but the send-pr webform seems broken, never returned, neither opera nor firefox) /michael From owner-freebsd-usb@FreeBSD.ORG Thu Mar 29 01:20:04 2007 Return-Path: X-Original-To: freebsd-usb@hub.freebsd.org Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F65516A401 for ; Thu, 29 Mar 2007 01:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 718CA13C487 for ; Thu, 29 Mar 2007 01:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2T1K4Ss020162 for ; Thu, 29 Mar 2007 01:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2T1K47Y020161; Thu, 29 Mar 2007 01:20:04 GMT (envelope-from gnats) Resent-Date: Thu, 29 Mar 2007 01:20:04 GMT Resent-Message-Id: <200703290120.l2T1K47Y020161@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, Michael Gmelin Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1A3B16A413 for ; Thu, 29 Mar 2007 01:18:05 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [69.147.83.33]) by mx1.freebsd.org (Postfix) with ESMTP id 7A61813C480 for ; Thu, 29 Mar 2007 01:18:05 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id l2T1I5ZE045723 for ; Thu, 29 Mar 2007 01:18:05 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id l2T1D3Bw045123; Thu, 29 Mar 2007 01:13:03 GMT (envelope-from nobody) Message-Id: <200703290113.l2T1D3Bw045123@www.freebsd.org> Date: Thu, 29 Mar 2007 01:13:03 GMT From: Michael Gmelin To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.0 Cc: Subject: usb/110991: [patch] QUIRK: Super Top IDE DEVICE (depends on usb/110988) 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, 29 Mar 2007 01:20:04 -0000 >Number: 110991 >Category: usb >Synopsis: [patch] QUIRK: Super Top IDE DEVICE (depends on usb/110988) >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu Mar 29 01:20:04 GMT 2007 >Closed-Date: >Last-Modified: >Originator: Michael Gmelin >Release: FreeBSD 6.2-RELEASE-p3 i386 >Organization: /bin/done digital solutions GmbH >Environment: FreeBSD bombat.bindone.de 6.2-RELEASE-p3 FreeBSD 6.2-RELEASE-p3 #21: Wed Mar 28 04:08:44 CEST 2007 root@bombat.bindone.de:/usr/src/sys/i386/compile/bombat i386 (CURRENT is affected as well) [root@bombat ~]# camcontrol inquiry da0 pass1: Fixed Direct Access SCSI-0 device pass1: Serial Number pass1: 40.000MB/s transfers Raidsonic ICY BOX IB-220U-Wh USB PATA/SATA-to-USB adaptor. The chipset is also used in other IDE-to-USB that are broken in the same way, thus I stick with "Super Top IDE DEVICE". UMASS device over SCSI (the output below is from an already patched umass.c, but besides the quirk info it doesn't differ at all) umass0: Super Top USB 2.0 IDE DEVICE, rev 2.00/2.01, addr 2 umass0: SCSI over Bulk-Only; quirks = 0x0080 umass0:2:0:-1: Attached to scbus2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C) >Description: Device can be attached without problems, but every attempt to write on it fails with error messages. E.g.: dd if=/dev/zero of=/dev/da0 count=10 da0: end of device 0+0 records in 0+0 records out disklabel da0 read: Unknow error 0 newfs /dev/da0s1 (some error message like newfs: wtfs: invalid sector blabla) Writing on a already formatted drive works, but the files disappear (most probably read not possible) The chipset has the same problems on Linux and OpenBSD (read reports from users using the ICY BOX and other products and other releases of the chipset) >How-To-Repeat: >Fix: The attached patches rely on the patch suggested in PR usb/110988(!!!) Patch for usbdevs adds vendor and product (vendorId 0x14cd, productId 0x6600). Patch for umass.c adds the following: - New entry to umass_devdescrs - New command protocol define: UMASS_PROTO_PROBE, which causes umass_match_proto to continue getting the correct protocol from the device, after quirks have been applied (this seems to be quite practical for maintenance) + make use of UMASS_PROTO_PROBE in umass_match_proto again, this patch is against the patched umass.c that results from usb/110988, otherwise there is no change in (broken) behaviour. Patch attached with submission follows: --- usbdevs.orig Thu Mar 15 16:23:52 2007 +++ usbdevs Thu Mar 29 03:09:07 2007 @@ -514,6 +514,7 @@ vendor RALINK 0x148f Ralink Technology vendor IMAGINATION 0x149a Imagination Technologies vendor CONCEPTRONIC 0x14b2 Conceptronic +vendor SUPERTOP 0x14cd Super Top vendor SILICONPORTALS 0x1527 Silicon Portals vendor PNY 0x154b PNY vendor SOHOWARE 0x15e8 SOHOware @@ -1596,6 +1597,9 @@ product DIAMOND2 SUPRA2890 0x0b4a SupraMax 2890 56K Modem product DIAMOND2 RIO600USB 0x5001 Rio 600 USB product DIAMOND2 RIO800USB 0x5002 Rio 800 USB + +/* Super Top products */ +product SUPERTOP IDEDEVICE 0x6600 Super Top IDE DEVICE (e.g. ICY BOX) /* System TALKS, Inc. */ product SYSTEMTALKS SGCX2UL 0x1920 SGC-X2UL --- umass.c.orig Thu Mar 29 02:08:06 2007 +++ umass.c Thu Mar 29 03:10:20 2007 @@ -282,6 +282,7 @@ # define UMASS_PROTO_UFI 0x0400 # define UMASS_PROTO_RBC 0x0800 # define UMASS_PROTO_COMMAND 0xff00 /* command protocol mask */ +# define UMASS_PROTO_PROBE 0xffff /* probe the protocol, even if found in umass_devdescr) */ /* Device specific quirks */ u_int16_t quirks; @@ -494,6 +495,10 @@ UMASS_PROTO_RBC | UMASS_PROTO_CBI, NO_QUIRKS }, + { USB_VENDOR_SUPERTOP, USB_PRODUCT_SUPERTOP_IDEDEVICE, RID_WILDCARD, + UMASS_PROTO_PROBE, + IGNORE_RESIDUE + }, { USB_VENDOR_TREK, USB_PRODUCT_TREK_THUMBDRIVE_8MB, RID_WILDCARD, UMASS_PROTO_ATAPI | UMASS_PROTO_BBB, IGNORE_RESIDUE @@ -845,12 +850,18 @@ if (umass_devdescrs[i].rid == RID_WILDCARD) { sc->proto = umass_devdescrs[i].proto; sc->quirks = umass_devdescrs[i].quirks; - return (UMATCH_VENDOR_PRODUCT); + if (sc->proto == UMASS_PROTO_PROBE) + sc->proto = 0; + else + return (UMATCH_VENDOR_PRODUCT); } else if (umass_devdescrs[i].rid == UGETW(dd->bcdDevice)) { sc->proto = umass_devdescrs[i].proto; sc->quirks = umass_devdescrs[i].quirks; - return (UMATCH_VENDOR_PRODUCT_REV); + if (sc->proto == UMASS_PROTO_PROBE) + sc->proto = 0; + else + return (UMATCH_VENDOR_PRODUCT_REV); } /* else RID does not match */ } } >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-usb@FreeBSD.ORG Thu Mar 29 03:10:04 2007 Return-Path: X-Original-To: freebsd-usb@hub.freebsd.org Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 336BE16A406 for ; Thu, 29 Mar 2007 03:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 15E6D13C468 for ; Thu, 29 Mar 2007 03:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2T3A3oc034757 for ; Thu, 29 Mar 2007 03:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2T3A3FP034756; Thu, 29 Mar 2007 03:10:03 GMT (envelope-from gnats) Resent-Date: Thu, 29 Mar 2007 03:10:03 GMT Resent-Message-Id: <200703290310.l2T3A3FP034756@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, Jonathan Charest Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 726E016A400 for ; Thu, 29 Mar 2007 03:04:54 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [69.147.83.33]) by mx1.freebsd.org (Postfix) with ESMTP id 4AE1E13C43E for ; Thu, 29 Mar 2007 03:04:54 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id l2T34q5o040585 for ; Thu, 29 Mar 2007 03:04:52 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id l2T2xp1p039648; Thu, 29 Mar 2007 02:59:51 GMT (envelope-from nobody) Message-Id: <200703290259.l2T2xp1p039648@www.freebsd.org> Date: Thu, 29 Mar 2007 02:59:51 GMT From: Jonathan Charest To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.0 Cc: Subject: usb/110992: Add Tactrix Openport support in 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: Thu, 29 Mar 2007 03:10:04 -0000 >Number: 110992 >Category: usb >Synopsis: Add Tactrix Openport support in uftdi >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Mar 29 03:10:03 GMT 2007 >Closed-Date: >Last-Modified: >Originator: Jonathan Charest >Release: RELENG_6 >Organization: >Environment: FreeBSD deimos.verse.org 6.2-STABLE FreeBSD 6.2-STABLE #2: Wed Mar 28 22:19:27 EDT 2007 root@deimos.verse.org:/usr/obj/usr/src/sys/DEIMOS i386 >Description: Tactrix make a cable that provides an interface to some car ECUs (mostly Subarus). They use a FTDI chip and It does not get recognized by the uftdi driver. I have verified that this product is not on HEAD. >How-To-Repeat: N/A >Fix: Add the following in /sys/dev/usb/usbdevs: /* Tactrix OpenPort (ECU) devices. */ product FTDI TACTRIX_OPENPORT_13M 0xCC48 OpenPort 1.3 Mitsubishi product FTDI TACTRIX_OPENPORT_13S 0xCC49 OpenPort 1.3 Subaru product FTDI TACTRIX_OPENPORT_13U 0xCC4A OpenPort 1.3 Universal and patch /sys/dev/usb/uftdi.c Patch attached with submission follows: --- uftdi.c.orig Wed Mar 28 22:54:08 2007 +++ uftdi.c Wed Mar 28 22:11:10 2007 @@ -37,7 +37,7 @@ */ #include -__FBSDID("$FreeBSD: /repoman/r/ncvs/src/sys/dev/usb/uftdi.c,v 1.22 2005/04/05 22:09:18 ticso Exp $"); +__FBSDID("$FreeBSD: src/sys/dev/usb/uftdi.c,v 1.22 2005/04/05 22:09:18 ticso Exp $"); /* * FTDI FT8U100AX serial adapter driver @@ -167,7 +167,10 @@ uaa->product == USB_PRODUCT_FTDI_MX2_3 || uaa->product == USB_PRODUCT_FTDI_MX4_5 || uaa->product == USB_PRODUCT_FTDI_LK202 || - uaa->product == USB_PRODUCT_FTDI_LK204)) + uaa->product == USB_PRODUCT_FTDI_LK204 || + uaa->product == USB_PRODUCT_FTDI_TACTRIX_OPENPORT_13M || + uaa->product == USB_PRODUCT_FTDI_TACTRIX_OPENPORT_13S || + uaa->product == USB_PRODUCT_FTDI_TACTRIX_OPENPORT_13U)) return (UMATCH_VENDOR_PRODUCT); if (uaa->vendor == USB_VENDOR_SIIG2 && (uaa->product == USB_PRODUCT_SIIG2_US2308)) @@ -247,6 +250,9 @@ case USB_PRODUCT_FTDI_MX4_5: case USB_PRODUCT_FTDI_LK202: case USB_PRODUCT_FTDI_LK204: + case USB_PRODUCT_FTDI_TACTRIX_OPENPORT_13M: + case USB_PRODUCT_FTDI_TACTRIX_OPENPORT_13S: + case USB_PRODUCT_FTDI_TACTRIX_OPENPORT_13U: sc->sc_type = UFTDI_TYPE_8U232AM; sc->sc_hdrlen = 0; break; >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-usb@FreeBSD.ORG Thu Mar 29 06:39:18 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F4E516A408 for ; Thu, 29 Mar 2007 06:39:18 +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 1A59813C448 for ; Thu, 29 Mar 2007 06:39:17 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe13.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 58316921; Thu, 29 Mar 2007 08:39:16 +0200 From: Hans Petter Selasky To: Markus Henschel Date: Thu, 29 Mar 2007 08:38:57 +0200 User-Agent: KMail/1.9.5 References: <200703271940.l2RJe90x058558@freefall.freebsd.org> <200703281832.22527.hselasky@c2i.net> <460AB387.20304@bally-wulff.de> In-Reply-To: <460AB387.20304@bally-wulff.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703290838.57458.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full 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, 29 Mar 2007 06:39:18 -0000 On Wednesday 28 March 2007 20:27, Markus Henschel wrote: > Hans Petter Selasky schrieb: > > > > > > Can you revert the changes you made to "umass.c" ? > > > > You can do this for example by copying "sys/dev/usb/umass.c" from the SVN > > repo to where you have your kernel sources. > > > > Then edit "sys/dev/usb/umass.c" again. > > > > Lookup the function "umass_t_bbb_status_callback()". > > > > Right below the label "tr_transferred" you add like this: > > > > tr_transferred: > > /* don't retry the status, but do a full reset if > > * there is something wrong with the CSW: > > */ > > sc->sc_status_try = 1; > > > > Compile a new kernel (or if you are smart, leave "device umass" out of > > the kernel config file and just recompile the "umass" module: > > sys/modules/umass) > > > > What happens now? > > > > --HPS > > Mmmm, seems like I must have messed something up before. So I reapplied > the changes to a clean system. The first stick says now. The !!!! mark > the point where the hanging occurs. Does it hang as long as before ? If you try to increase the delay again, does that help? Edit sys/dev/usb/umass.c Then lookup: usbd_delay_ms(uaa->device, 1000); Change it into: usbd_delay_ms(uaa->device, 5000); > > Thank you for your time. Let me know if you want me to try other > changes. May be it would be easier if you could create a branch in svn > with the changes needed? Maybe. --HPS From owner-freebsd-usb@FreeBSD.ORG Thu Mar 29 06:45:38 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 292C516A401 for ; Thu, 29 Mar 2007 06:45:38 +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 8E4D713C448 for ; Thu, 29 Mar 2007 06:45:37 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe03.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 458070985; Thu, 29 Mar 2007 08:45:35 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Thu, 29 Mar 2007 08:45:16 +0200 User-Agent: KMail/1.9.5 References: <200703290017.l2T0HXe9037447@www.freebsd.org> In-Reply-To: <200703290017.l2T0HXe9037447@www.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703290845.16382.hselasky@c2i.net> Cc: Subject: Re: usb/110989: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken 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, 29 Mar 2007 06:45:38 -0000 On Thursday 29 March 2007 02:17, Michael Gmelin wrote: > >Number: 110989 > >Category: usb > >Synopsis: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is > > broken Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-usb > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Thu Mar 29 00:30:09 GMT 2007 > >Closed-Date: > >Last-Modified: > >Originator: Michael Gmelin > >Release: FreeBSD 6.2-RELEASE-p3 i386 > >Organization: > > /bin/done digital solutions GmbH > > >Environment: > > FreeBSD bombat.bindone.de 6.2-RELEASE-p3 FreeBSD 6.2-RELEASE-p3 #21: Wed > Mar 28 04:08:44 CEST 2007 > root@bombat.bindone.de:/usr/src/sys/i386/compile/bombat i386 > > >Description: > > I had to add a new device to usbdevs/umass.c which requires the > IGNORE_RESIDUE quirk to be set (extra PR will follow). It didn't work, > because IGNORE_RESIDUE isn't handled properly in umass.c (it isn't really > handled at all, since Residue is set in lines are 1668-1672 in umass.c in > the following was: > > int Residue; > Residue = UGETDW(sc->csw.dCSWDataResidue); > if (Residue == 0 && > sc->transfer_datalen - sc->transfer_actlen != 0) > Residue = sc->transfer_datalen - sc->transfer_actlen; > > The patch below fixes this issue (tested and proven to work). > > >How-To-Repeat: > > Use a really broken USB device which returns "random" values for > sc->csw.dCSWDataResidue (like devices that use the SuperTop IDEDEVICE USB > controller, e.g. the ICY BOX IB-220U-Wh). Every attempt to use the device > will lead to error messages, like: > > dd if=/dev/zero of=/dev/da0 count=10 > da0: end of device > > or > > disklabel da0 > read: Unknown error > etc. > > >Fix: > > Apply the attached patch, which forces residue to be calculated if > IGNORE_RESIDUE is set. > > > > Patch attached with submission follows: > > --- umass.c.orig Thu Mar 29 02:07:04 2007 > +++ umass.c Thu Mar 29 02:08:06 2007 > @@ -1666,7 +1666,10 @@ > } > > int Residue; > - Residue = UGETDW(sc->csw.dCSWDataResidue); > + if (sc->quirks & IGNORE_RESIDUE) > + Residue = 0; > + else > + Residue = UGETDW(sc->csw.dCSWDataResidue); > if (Residue == 0 && > sc->transfer_datalen - sc->transfer_actlen != 0) > Residue = sc->transfer_datalen - sc->transfer_actlen; > > >Release-Note: > >Audit-Trail: > >Unformatted: > The new USB stack doesn't have this fix either, but could you have tried the new USB stack, and then turn on debugging, "sysctl hw.usb.umass.debug=-1", so that we can see what the wrong residues look like. See: http://www.turbocat.net/~hselasky/usb4bsd I recommend the SVN version on a 6-STABLE box. --HPS From owner-freebsd-usb@FreeBSD.ORG Thu Mar 29 06:51:04 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8385916A400 for ; Thu, 29 Mar 2007 06:51:04 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id E6B1D13C43E for ; Thu, 29 Mar 2007 06:51:03 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe04.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 450008904; Thu, 29 Mar 2007 08:51:02 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org User-Agent: KMail/1.9.5 References: <200703290017.l2T0HXe9037447@www.freebsd.org> In-Reply-To: <200703290017.l2T0HXe9037447@www.freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Date: Thu, 29 Mar 2007 08:50:42 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200703290850.42858.hselasky@c2i.net> Cc: Subject: Re: usb/110989: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken 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, 29 Mar 2007 06:51:04 -0000 On Thursday 29 March 2007 02:17, Michael Gmelin wrote: > >Number: 110989 > >Category: usb > >Synopsis: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is > > broken Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-usb > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Thu Mar 29 00:30:09 GMT 2007 > >Closed-Date: > >Last-Modified: > >Originator: Michael Gmelin > >Release: FreeBSD 6.2-RELEASE-p3 i386 > >Organization: > > /bin/done digital solutions GmbH > > >Environment: > > FreeBSD bombat.bindone.de 6.2-RELEASE-p3 FreeBSD 6.2-RELEASE-p3 #21: Wed > Mar 28 04:08:44 CEST 2007 > root@bombat.bindone.de:/usr/src/sys/i386/compile/bombat i386 > > >Description: > > I had to add a new device to usbdevs/umass.c which requires the > IGNORE_RESIDUE quirk to be set (extra PR will follow). It didn't work, > because IGNORE_RESIDUE isn't handled properly in umass.c (it isn't really > handled at all, since Residue is set in lines are 1668-1672 in umass.c in > the following was: > > int Residue; > Residue = UGETDW(sc->csw.dCSWDataResidue); > if (Residue == 0 && > sc->transfer_datalen - sc->transfer_actlen != 0) > Residue = sc->transfer_datalen - sc->transfer_actlen; > > The patch below fixes this issue (tested and proven to work). > > >How-To-Repeat: > > Use a really broken USB device which returns "random" values for > sc->csw.dCSWDataResidue (like devices that use the SuperTop IDEDEVICE USB > controller, e.g. the ICY BOX IB-220U-Wh). Every attempt to use the device > will lead to error messages, like: > > dd if=/dev/zero of=/dev/da0 count=10 > da0: end of device > > or > > disklabel da0 > read: Unknown error > etc. > > >Fix: > > Apply the attached patch, which forces residue to be calculated if > IGNORE_RESIDUE is set. > > > > Patch attached with submission follows: > > --- umass.c.orig Thu Mar 29 02:07:04 2007 > +++ umass.c Thu Mar 29 02:08:06 2007 > @@ -1666,7 +1666,10 @@ > } > > int Residue; > - Residue = UGETDW(sc->csw.dCSWDataResidue); > + if (sc->quirks & IGNORE_RESIDUE) > + Residue = 0; > + else > + Residue = UGETDW(sc->csw.dCSWDataResidue); > if (Residue == 0 && > sc->transfer_datalen - sc->transfer_actlen != 0) > Residue = sc->transfer_datalen - sc->transfer_actlen; > > >Release-Note: > >Audit-Trail: > >Unformatted: > I think that we should auto-detect bad residue. If the residue is some fixed constant way off the actual length, then maybe something like this is better: Residue = UGETDW(sc->csw.dCSWDataResidue); if (Residue > sc->transfer_datalen) { Residue = sc->transfer_datalen - sc->transfer_actlen; } --HPS From owner-freebsd-usb@FreeBSD.ORG Thu Mar 29 07:41:41 2007 Return-Path: X-Original-To: freebsd-usb@hub.freebsd.org Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B5DD16A402; Thu, 29 Mar 2007 07:41:41 +0000 (UTC) (envelope-from jmg@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id D806113C459; Thu, 29 Mar 2007 07:41:40 +0000 (UTC) (envelope-from jmg@FreeBSD.org) Received: from freefall.freebsd.org (jmg@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2T7feYG078221; Thu, 29 Mar 2007 07:41:40 GMT (envelope-from jmg@freefall.freebsd.org) Received: (from jmg@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2T7feS2078217; Thu, 29 Mar 2007 07:41:40 GMT (envelope-from jmg) Date: Thu, 29 Mar 2007 07:41:40 GMT From: John-Mark Gurney Message-Id: <200703290741.l2T7feS2078217@freefall.freebsd.org> To: freebsdusb@bindone.de, jmg@FreeBSD.org, freebsd-usb@FreeBSD.org Cc: Subject: Re: usb/110989: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken 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, 29 Mar 2007 07:41:41 -0000 Synopsis: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken State-Changed-From-To: open->closed State-Changed-By: jmg State-Changed-When: Thu Mar 29 07:41:26 UTC 2007 State-Changed-Why: dup http://www.freebsd.org/cgi/query-pr.cgi?pr=110989 From owner-freebsd-usb@FreeBSD.ORG Thu Mar 29 10:00:26 2007 Return-Path: X-Original-To: freebsd-usb@hub.freebsd.org Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81D6B16A400 for ; Thu, 29 Mar 2007 10:00:26 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 0B77613C4C1 for ; Thu, 29 Mar 2007 10:00:26 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2TA0PkO098597 for ; Thu, 29 Mar 2007 10:00:25 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2TA0Pql098596; Thu, 29 Mar 2007 10:00:25 GMT (envelope-from gnats) Date: Thu, 29 Mar 2007 10:00:25 GMT Message-Id: <200703291000.l2TA0Pql098596@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Alexander Leidinger Cc: Subject: Re: usb/110988: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Leidinger List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 10:00:26 -0000 The following reply was made to PR usb/110988; it has been noted by GNATS. From: Alexander Leidinger To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: usb/110988: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken Date: Thu, 29 Mar 2007 11:53:07 +0200 Anyone handling this fix should have a look at the quirks table. As this quirk is not "enabled" ATM, it should probably be removed from the table if it is used there (convert it into a comment and tell in the commit log why this was done). From owner-freebsd-usb@FreeBSD.ORG Thu Mar 29 15:19:13 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E58B316A405 for ; Thu, 29 Mar 2007 15:19:13 +0000 (UTC) (envelope-from m.henschel@bally-wulff.de) Received: from mail2.bally-wulff-berlin.de (mail2.bally-wulff-berlin.de [212.144.118.9]) by mx1.freebsd.org (Postfix) with ESMTP id 143B813C45D for ; Thu, 29 Mar 2007 15:19:12 +0000 (UTC) (envelope-from m.henschel@bally-wulff.de) Message-ID: <460BD8EC.5060900@bally-wulff.de> Date: Thu, 29 Mar 2007 17:19:08 +0200 From: Markus Henschel MIME-Version: 1.0 To: Hans Petter Selasky References: <200703271940.l2RJe90x058558@freefall.freebsd.org> <200703281832.22527.hselasky@c2i.net> <460AB387.20304@bally-wulff.de> <200703290838.57458.hselasky@c2i.net> In-Reply-To: <200703290838.57458.hselasky@c2i.net> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Mar 2007 15:19:08.0183 (UTC) FILETIME=[98812A70:01C77215] Cc: freebsd-usb@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full 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, 29 Mar 2007 15:19:14 -0000 Hans Petter Selasky schrieb: > > Does it hang as long as before ? > > If you try to increase the delay again, does that help? > > Edit sys/dev/usb/umass.c > > Then lookup: > > usbd_delay_ms(uaa->device, 1000); > > Change it into: > > usbd_delay_ms(uaa->device, 5000); > >> Thank you for your time. Let me know if you want me to try other >> changes. May be it would be easier if you could create a branch in svn >> with the changes needed? > > Maybe. > > --HPS > Hi, changing usbd_delay_ms(uaa->device, 1000); to usbd_delay_ms(uaa->device, 5000); increases the overall delay be 4 seconds :-). The value given there doesn't seem to be related to the problem. The first returned CCW is always invalid for that stick. I did some experiments with the other change you suggested. When I change: sc->sc_last_xfer_index = UMASS_T_BBB_COMMAND; to sc->sc_last_xfer_index = UMASS_T_BBB_STATUS; the first CCW is still invalid but the hanging is gone (overall detection time is still much longer than with the old usb stuff). I also tried to use the original umass.c together with the new usb stack. It seems to work. There result is similar to changing sc->sc_last_xfer_index = UMASS_T_BBB_STATUS. -- Regards, Markus Henschel Development BALLY WULFF Automaten GmbH Maybachufer 48-51 12045 Berlin Phone: +49(30)62002 161 FAX: +49(30)62002 230 http://www.ballywulff.de From owner-freebsd-usb@FreeBSD.ORG Thu Mar 29 17:20:50 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A147716A406 for ; Thu, 29 Mar 2007 17:20:50 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: from mail.bindone.de (sidewinder.bindone.de [62.146.109.98]) by mx1.freebsd.org (Postfix) with SMTP id 2546313C46E for ; Thu, 29 Mar 2007 17:20:49 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: (qmail 5059 invoked from network); 29 Mar 2007 17:17:44 -0000 Received: from unknown (HELO bombat.bindone.de) (84.151.231.177) by mail.bindone.de with SMTP; 29 Mar 2007 17:17:44 -0000 Message-ID: <460BF56A.6020707@bindone.de> Date: Thu, 29 Mar 2007 19:20:42 +0200 From: grem User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.2) Gecko/20070318 SeaMonkey/1.1.1 MIME-Version: 1.0 To: Hans Petter Selasky , freebsd-usb@freebsd.org References: <200703290017.l2T0HXe9037447@www.freebsd.org> <200703290850.42858.hselasky@c2i.net> In-Reply-To: <200703290850.42858.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: usb/110988: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken 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, 29 Mar 2007 17:20:50 -0000 PR number changed... see below Hans Petter Selasky wrote: > On Thursday 29 March 2007 02:17, Michael Gmelin wrote: >>> Number: 110989 >>> Category: usb >>> Synopsis: [patch] Handling of quirk IGNORE_RESIDUE is umass.c is >>> broken Confidential: no >>> Severity: serious >>> Priority: medium >>> Responsible: freebsd-usb >>> State: open >>> Quarter: >>> Keywords: >>> Date-Required: >>> Class: sw-bug >>> Submitter-Id: current-users >>> Arrival-Date: Thu Mar 29 00:30:09 GMT 2007 >>> Closed-Date: >>> Last-Modified: >>> Originator: Michael Gmelin >>> Release: FreeBSD 6.2-RELEASE-p3 i386 >>> Organization: >> /bin/done digital solutions GmbH >> >>> Environment: >> FreeBSD bombat.bindone.de 6.2-RELEASE-p3 FreeBSD 6.2-RELEASE-p3 #21: Wed >> Mar 28 04:08:44 CEST 2007 >> root@bombat.bindone.de:/usr/src/sys/i386/compile/bombat i386 >> >>> Description: >> I had to add a new device to usbdevs/umass.c which requires the >> IGNORE_RESIDUE quirk to be set (extra PR will follow). It didn't work, >> because IGNORE_RESIDUE isn't handled properly in umass.c (it isn't really >> handled at all, since Residue is set in lines are 1668-1672 in umass.c in >> the following was: >> >> int Residue; >> Residue = UGETDW(sc->csw.dCSWDataResidue); >> if (Residue == 0 && >> sc->transfer_datalen - sc->transfer_actlen != 0) >> Residue = sc->transfer_datalen - sc->transfer_actlen; >> >> The patch below fixes this issue (tested and proven to work). >> >>> How-To-Repeat: >> Use a really broken USB device which returns "random" values for >> sc->csw.dCSWDataResidue (like devices that use the SuperTop IDEDEVICE USB >> controller, e.g. the ICY BOX IB-220U-Wh). Every attempt to use the device >> will lead to error messages, like: >> >> dd if=/dev/zero of=/dev/da0 count=10 >> da0: end of device >> >> or >> >> disklabel da0 >> read: Unknown error >> etc. >> >>> Fix: >> Apply the attached patch, which forces residue to be calculated if >> IGNORE_RESIDUE is set. >> >> >> >> Patch attached with submission follows: >> >> --- umass.c.orig Thu Mar 29 02:07:04 2007 >> +++ umass.c Thu Mar 29 02:08:06 2007 >> @@ -1666,7 +1666,10 @@ >> } >> >> int Residue; >> - Residue = UGETDW(sc->csw.dCSWDataResidue); >> + if (sc->quirks & IGNORE_RESIDUE) >> + Residue = 0; >> + else >> + Residue = UGETDW(sc->csw.dCSWDataResidue); >> if (Residue == 0 && >> sc->transfer_datalen - sc->transfer_actlen != 0) >> Residue = sc->transfer_datalen - sc->transfer_actlen; >> >>> Release-Note: >>> Audit-Trail: >>> Unformatted: > Hmmm, what I've seen in HEAD looked eactly the same, but anyway... Do you think it's possible to 100% reliably detect bad residue this way? If not (what I assume, imagine a device returning 0 < residue < sc->transfer_datalen - sc->transfer_actlen) I think it's better to stick with an unusual devices list unless you have all devices that require it available for testing. Do you think there are any chances to get this patch into one of the next releases? Personally I'm not really interested, how things will look into the next version of the USB stack, since I have devices that are attached to production machines that have to run RELEASE versions of FreeBSD... > I think that we should auto-detect bad residue. If the residue is some fixed > constant way off the actual length, then maybe something like this is better: > > Residue = UGETDW(sc->csw.dCSWDataResidue); > > if (Residue > sc->transfer_datalen) { > Residue = sc->transfer_datalen - sc->transfer_actlen; > } > > --HPS From owner-freebsd-usb@FreeBSD.ORG Fri Mar 30 07:39:50 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 929D616A406 for ; Fri, 30 Mar 2007 07:39:50 +0000 (UTC) (envelope-from annedent@bigpond.com) Received: from omta05ps.mx.bigpond.com (omta05ps.mx.bigpond.com [144.140.83.195]) by mx1.freebsd.org (Postfix) with ESMTP id 303C913C455 for ; Fri, 30 Mar 2007 07:39:50 +0000 (UTC) (envelope-from annedent@bigpond.com) Received: from oaamta05ps.mx.bigpond.com ([58.170.177.103]) by omta05ps.mx.bigpond.com with ESMTP id <20070330073948.PQMI23363.omta05ps.mx.bigpond.com@oaamta05ps.mx.bigpond.com> for ; Fri, 30 Mar 2007 07:39:48 +0000 Received: from FLINDERS ([58.170.177.103]) by oaamta05ps.mx.bigpond.com with SMTP id <20070330073947.ZQBY14664.oaamta05ps.mx.bigpond.com@FLINDERS> for ; Fri, 30 Mar 2007 07:39:47 +0000 Message-ID: <000c01c7729e$989688f0$67b1aa3a@FLINDERS> From: "Anne" To: Date: Fri, 30 Mar 2007 17:39:47 +1000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Convert NetBSD >> FreeBSD 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, 30 Mar 2007 07:39:50 -0000 Hi, I have now tracked down and got a c file for a driver I think will work = with FreeBSD. What tools do I use to do a conversion from netBSD .c file to FreeBSD .c = file? Cheers John From owner-freebsd-usb@FreeBSD.ORG Fri Mar 30 08:10:52 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B35316A402 for ; Fri, 30 Mar 2007 08:10:52 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by mx1.freebsd.org (Postfix) with ESMTP id 323B913C44C for ; Fri, 30 Mar 2007 08:10:52 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1HXBtj-0003HH-Rw for freebsd-usb@freebsd.org; Fri, 30 Mar 2007 00:51:47 -0700 Message-ID: <9748774.post@talk.nabble.com> Date: Fri, 30 Mar 2007 00:51:47 -0700 (PDT) From: PS To: freebsd-usb@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: ps1981@126.com Subject: about usb of freeBSD 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, 30 Mar 2007 08:10:52 -0000 Dear all, I just read the usb source code of freeBSD, but I can't understand it clearly. Can anybody give me the simple analyse or structure of it ? -- View this message in context: http://www.nabble.com/about-usb-of-freeBSD-tf3490796.html#a9748774 Sent from the freebsd-usb mailing list archive at Nabble.com. From owner-freebsd-usb@FreeBSD.ORG Fri Mar 30 08:42:54 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1290D16A407 for ; Fri, 30 Mar 2007 08:42:54 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id C043413C468 for ; Fri, 30 Mar 2007 08:42:53 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5EE52.dip.t-dialin.net [84.165.238.82]) by redbull.bpaserver.net (Postfix) with ESMTP id 3512A2E09C; Fri, 30 Mar 2007 10:42:48 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 5B8FB5B4817; Fri, 30 Mar 2007 10:42:45 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l2U8gjBE039491; Fri, 30 Mar 2007 10:42:45 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Fri, 30 Mar 2007 10:42:45 +0200 Message-ID: <20070330104245.b6ln6ph1ssss4g0w@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 30 Mar 2007 10:42:45 +0200 From: Alexander Leidinger To: PS References: <9748774.post@talk.nabble.com> In-Reply-To: <9748774.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.864, required 8, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-usb@freebsd.org Subject: Re: about usb of freeBSD 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, 30 Mar 2007 08:42:54 -0000 Quoting PS (from Fri, 30 Mar 2007 00:51:47 -0700 (PDT)): > > Dear all, > I just read the usb source code of freeBSD, but I can't understand it > clearly. > Can anybody give me the simple analyse or structure of it ? Have a look at http://www.leidinger.net/FreeBSD/src_docs/ there's dev_usb.pdf. It is the result of a doxygen run over our usb code. It's all we can provide in this regard. Hope it helps, Alexander. -- The eternal feminine draws us upward. -- Goethe http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-usb@FreeBSD.ORG Fri Mar 30 09:09:18 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0A3F16A400 for ; Fri, 30 Mar 2007 09:09:18 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 3BAC113C455 for ; Fri, 30 Mar 2007 09:09:18 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe01.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 432428799; Fri, 30 Mar 2007 11:09:16 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Fri, 30 Mar 2007 11:08:56 +0200 User-Agent: KMail/1.9.5 References: <000c01c7729e$989688f0$67b1aa3a@FLINDERS> In-Reply-To: <000c01c7729e$989688f0$67b1aa3a@FLINDERS> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703301108.57003.hselasky@c2i.net> Cc: Anne Subject: Re: Convert NetBSD >> FreeBSD 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, 30 Mar 2007 09:09:18 -0000 On Friday 30 March 2007 09:39, Anne wrote: > Hi, > I have now tracked down and got a c file for a driver I think will work > with FreeBSD. > > What tools do I use to do a conversion from netBSD .c file to FreeBSD .c > file? There are not any such tools, which I know of. By the way, what kind of USB driver are we talking about? Also I would recommend that you look at the new USB stack, to save you future work: http://www.turbocat.net/~hselasky/usb4bsd --HPS From owner-freebsd-usb@FreeBSD.ORG Fri Mar 30 09:15:47 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F29316A404 for ; Fri, 30 Mar 2007 09:15:47 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id DD3E313C487 for ; Fri, 30 Mar 2007 09:15:46 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe04.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 451080489; Fri, 30 Mar 2007 11:15:38 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Fri, 30 Mar 2007 11:15:20 +0200 User-Agent: KMail/1.9.5 References: <9748774.post@talk.nabble.com> <20070330104245.b6ln6ph1ssss4g0w@webmail.leidinger.net> In-Reply-To: <20070330104245.b6ln6ph1ssss4g0w@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703301115.20227.hselasky@c2i.net> Cc: PS Subject: Re: about usb of freeBSD 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, 30 Mar 2007 09:15:47 -0000 On Friday 30 March 2007 10:42, Alexander Leidinger wrote: > Quoting PS (from Fri, 30 Mar 2007 00:51:47 -0700 (PDT)): > > Dear all, > > I just read the usb source code of freeBSD, but I can't understand it > > clearly. > > Can anybody give me the simple analyse or structure of it ? > > Have a look at http://www.leidinger.net/FreeBSD/src_docs/ there's > dev_usb.pdf. It is the result of a doxygen run over our usb code. It's > all we can provide in this regard. > Could you generate the same PDF for the new USB stack ? --HPS From owner-freebsd-usb@FreeBSD.ORG Fri Mar 30 11:15:08 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22FCC16A402 for ; Fri, 30 Mar 2007 11:15:08 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id D06B213C45B for ; Fri, 30 Mar 2007 11:15:07 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5EE52.dip.t-dialin.net [84.165.238.82]) by redbull.bpaserver.net (Postfix) with ESMTP id 7FA0B2E1BD; Fri, 30 Mar 2007 13:15:03 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 9D2475B4817; Fri, 30 Mar 2007 13:15:00 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l2UBF060065021; Fri, 30 Mar 2007 13:15:00 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Fri, 30 Mar 2007 13:15:00 +0200 Message-ID: <20070330131500.5qikeh320wwsc0ks@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 30 Mar 2007 13:15:00 +0200 From: Alexander Leidinger To: Hans Petter Selasky References: <9748774.post@talk.nabble.com> <20070330104245.b6ln6ph1ssss4g0w@webmail.leidinger.net> <200703301115.20227.hselasky@c2i.net> In-Reply-To: <200703301115.20227.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.787, required 8, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14, TW_PH 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-usb@freebsd.org Subject: Re: about usb of freeBSD 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, 30 Mar 2007 11:15:08 -0000 Quoting Hans Petter Selasky (from Fri, 30 Mar 2007 =20 11:15:20 +0200): > On Friday 30 March 2007 10:42, Alexander Leidinger wrote: >> Quoting PS (from Fri, 30 Mar 2007 00:51:47 -0700 (PDT)): >> > Dear all, >> > I just read the usb source code of freeBSD, but I can't understand it >> > clearly. >> > Can anybody give me the simple analyse or structure of it ? >> >> Have a look at http://www.leidinger.net/FreeBSD/src_docs/ there's >> dev_usb.pdf. It is the result of a doxygen run over our usb code. It's >> all we can provide in this regard. >> > > Could you generate the same PDF for the new USB stack ? As you have the code merged into your src tree, I would suggest to do =20 it yourself (I don't have the time ATM to merge it). Install doxygen =20 and graphviz (and teTeX if you prefer the PDF docs instead of the HTML =20 ones), go to src/tools/kerneldoc/subsys/ and run "make dev_usb" and/or =20 "make pdf-dev_usb". The HTML docs are not available online on my site, =20 they consume too much space. The HTML docs are much more convenient to =20 use. To generate the docs _again_ you have to run "make clean" first. If there are some problems, show me the error. Bye, Alexander. --=20 "man hier" will explain the way FreeBSD filesystems are normally laid out. =09=09-- David Scheidt http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-usb@FreeBSD.ORG Fri Mar 30 19:19:27 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0DA9816A400 for ; Fri, 30 Mar 2007 19:19:27 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from smtp.vzavenue.net (smtp.vzavenue.net [66.171.59.140]) by mx1.freebsd.org (Postfix) with ESMTP id BBB0A13C4BC for ; Fri, 30 Mar 2007 19:19:26 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from 77.79.171.66.subscriber.vzavenue.net (HELO homobox.opal.com) ([66.171.79.77]) by smtp.vzavenue.net with ESMTP; 30 Mar 2007 14:50:14 -0400 X-REPUTATION: -2.0 X-REMOTE-IP: 66.171.79.77 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FADP1DEZCq09NUGdsb2JhbACPfAEBKg X-IronPort-AV: i="4.14,354,1170651600"; d="scan'208"; a="142394509:sNHT18104625" Received: from linwhf.opal.com (localhost [127.0.0.1]) by homobox.opal.com (8.13.8/8.13.8) with ESMTP id l2UIoD11053657 for ; Fri, 30 Mar 2007 14:50:14 -0400 (EDT) (envelope-from fbsd@opal.com) Received: from 192.168.3.65 ([192.168.3.65] helo=linwhf.opal.com) by ASSP-nospam; 30 Mar 2007 14:50:13 -0400 Received: from linwhf.opal.com (localhost [127.0.0.1]) by linwhf.opal.com (8.13.8/8.13.8) with ESMTP id l2UIo10L002681 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Mar 2007 14:50:01 -0400 (EDT) (envelope-from fbsd@opal.com) Received: (from jr@localhost) by linwhf.opal.com (8.13.8/8.13.8/Submit) id l2UIo08U002680 for freebsd-usb@freebsd.org; Fri, 30 Mar 2007 14:50:00 -0400 (EDT) (envelope-from fbsd@opal.com) X-Authentication-Warning: linwhf.opal.com: jr set sender to fbsd@opal.com using -f Date: Fri, 30 Mar 2007 14:50:00 -0400 From: "J.R. Oldroyd" To: freebsd-usb@freebsd.org Message-ID: <20070330185000.GG1328@linwhf.opal.com> References: <20070216003327.GE1336@linwhf.opal.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070216003327.GE1336@linwhf.opal.com> User-Agent: Mutt/1.4.2.2i Subject: Re: Call For Testers: axe(4) with Ax88178 and Ax88772 support 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, 30 Mar 2007 19:19:27 -0000 On Feb 15, 19:33, J.R. Oldroyd wrote: > I have updated the axe(4) driver with Ax88178 and Ax88772 support. > > Go here to get it: > http://opal.com/jr/freebsd/sys/dev/usb/ > My original version of these Ax88178 and Ax88772 enhancements (back in February) did not use the chips' input frame bursting because the FreeBSD usb_ether framework does not support it. I have now enhanced the driver, removing its use of the usb_ether framework, and doing its own buffer management with large input buffers which can handle bursts of multiple input frames in one buffer. The diffs and files on the web page referenced above have been updated for this new version. The driver appears to work, and I have set it to burst up to 4096 bytes. The device can actually burst up to 16384 bytes. However, if I set it to burst more than 4096 bytes, the usb layer (ehci on my test system) stalls, and all input stops after just a few input frames. I'd appreciate feedback from anyone if larger burst sizes work for you. See the notes on that web page for details of how to change the driver's burst size. -jr From owner-freebsd-usb@FreeBSD.ORG Fri Mar 30 22:30:57 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB1BA16A408 for ; Fri, 30 Mar 2007 22:30:57 +0000 (UTC) (envelope-from laurent@kally.net) Received: from interoute.kally.fr (interoute.kally.fr [195.28.200.95]) by mx1.freebsd.org (Postfix) with ESMTP id 10E0813C46E for ; Fri, 30 Mar 2007 22:30:56 +0000 (UTC) (envelope-from laurent@kally.net) Received: (qmail 68477 invoked from network); 30 Mar 2007 22:00:57 -0000 Received: from dolphin.kally.fr (HELO SPUNKY) (kally@[82.243.145.147]) (envelope-sender ) by interoute.kally.fr (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 30 Mar 2007 22:00:52 -0000 From: "Hofmann, Laurent" To: Date: Sat, 31 Mar 2007 00:02:30 +0200 Message-ID: <008701c77317$1dfbc5f0$59f351d0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcdzFxy1zOjxxsfhQIyABv+QFzl05A== Content-Language: fr X-Bogosity: Ham, tests=bogofilter, spamicity=0.500008, version=1.0.3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Memory leak / Kernel Panic using snd_uaudio (USB Sound Card) 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, 30 Mar 2007 22:30:57 -0000 Hello, I have a strange problem with my USB Sound Card. I found some records using Google, but they are all old and never answered. I'm using the kernel module snd_uaudio to use an USB Sound Card (kldload uaudio) on Freebsd 6.2-RELEASE. Usb Sound Card is a Hercule Muse Pocket LT. When playing audio (using PulseAudio), after around 2 hours, I get a kernel panic followed by a system reboot : "19:33:14 dolphin kernel: usb0: isoc TD alloc failed" And/Or "Mar 30 17:56:58 dolphin kernel: panic: kmem_malloc(12288): kmem_map too small: 42278912 total allocated". I can reproduce it as needed. How can we try to deal with this problem and find out what is wrong ? Thanks for your help, Best Regards, Laurent H. From owner-freebsd-usb@FreeBSD.ORG Sat Mar 31 06:40:35 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F06B16A401 for ; Sat, 31 Mar 2007 06:40:35 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id BF7A913C459 for ; Sat, 31 Mar 2007 06:40:34 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe08.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 451055623; Sat, 31 Mar 2007 08:40:29 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Sat, 31 Mar 2007 08:40:09 +0200 User-Agent: KMail/1.9.5 References: <008701c77317$1dfbc5f0$59f351d0$@net> In-Reply-To: <008701c77317$1dfbc5f0$59f351d0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703310840.09253.hselasky@c2i.net> Cc: Subject: Re: Memory leak / Kernel Panic using snd_uaudio (USB Sound Card) 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, 31 Mar 2007 06:40:35 -0000 On Saturday 31 March 2007 00:02, Hofmann, Laurent wrote: > Hello, > > > > I have a strange problem with my USB Sound Card. I found some records using > Google, but they are all old and never answered. > > > > I'm using the kernel module snd_uaudio to use an USB Sound Card (kldload > uaudio) on Freebsd 6.2-RELEASE. Usb Sound Card is a Hercule Muse Pocket LT. > > When playing audio (using PulseAudio), after around 2 hours, I get a kernel > panic followed by a system reboot : > > > > "19:33:14 dolphin kernel: usb0: isoc TD alloc failed" > > And/Or > > "Mar 30 17:56:58 dolphin kernel: panic: kmem_malloc(12288): kmem_map too > small: 42278912 total allocated". > > > > I can reproduce it as needed. > > > > How can we try to deal with this problem and find out what is wrong ? > The new USB stack has got a new uaudio driver also. I would try that first. How to get the latest sources: svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b # # The following commands will # install the driver on FreeBSD: # cd i4b/trunk/i4b/FreeBSD.usb make S=../src package make install Then edit the file "install_uaudio.sh" and change it as needed, if you are not installing to /usr/src. ./install_uaudio.sh I am not sure what patches they MFC'ed from head to 6.2 release, regarding the sound system, so it might be that my "uaudio.c" won't compile. But that can easily be fixed if you send me the compile log where it breaks. --HPS From owner-freebsd-usb@FreeBSD.ORG Sat Mar 31 09:51:12 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85D9B16A401 for ; Sat, 31 Mar 2007 09:51:12 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by mx1.freebsd.org (Postfix) with ESMTP id 6D34B13C459 for ; Sat, 31 Mar 2007 09:51:12 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1HXaEq-00013C-6s for freebsd-usb@freebsd.org; Sat, 31 Mar 2007 02:51:12 -0700 Message-ID: <9765732.post@talk.nabble.com> Date: Sat, 31 Mar 2007 02:51:12 -0700 (PDT) From: 3s3_l00n3y To: freebsd-usb@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: locote_from_los@yahoo.com Subject: a41x/v32x driver 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, 31 Mar 2007 09:51:12 -0000 would u be able to send me the a41x/v32x driver -- View this message in context: http://www.nabble.com/a41x-v32x-driver-tf3496353.html#a9765732 Sent from the freebsd-usb mailing list archive at Nabble.com. From owner-freebsd-usb@FreeBSD.ORG Sat Mar 31 10:03:43 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3DA816A401 for ; Sat, 31 Mar 2007 10:03:43 +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 5FA7813C457 for ; Sat, 31 Mar 2007 10:03:43 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe11.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 283749264; Sat, 31 Mar 2007 12:03:42 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Sat, 31 Mar 2007 12:03:21 +0200 User-Agent: KMail/1.9.5 References: <9765732.post@talk.nabble.com> In-Reply-To: <9765732.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703311203.21425.hselasky@c2i.net> Cc: 3s3_l00n3y Subject: Re: a41x/v32x driver 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, 31 Mar 2007 10:03:43 -0000 On Saturday 31 March 2007 11:51, 3s3_l00n3y wrote: > would u be able to send me the a41x/v32x driver I see this in usb_quirks.c: { USB_VENDOR_MOTOROLA2, USB_PRODUCT_MOTOROLA2_A41XV32X, ANY, { UQ_ASSUME_CM_OVER_DATA }}, I think your device should be detected by "umodem". Try "kldload umodem". --HPS From owner-freebsd-usb@FreeBSD.ORG Sat Mar 31 10:27:33 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7879516A403 for ; Sat, 31 Mar 2007 10:27:33 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.swip.net [212.247.155.1]) by mx1.freebsd.org (Postfix) with ESMTP id 11F6C13C45A for ; Sat, 31 Mar 2007 10:27:32 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe09.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 283804164; Sat, 31 Mar 2007 12:27:31 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Sat, 31 Mar 2007 12:27:11 +0200 User-Agent: KMail/1.9.5 References: <20070216003327.GE1336@linwhf.opal.com> <20070330185000.GG1328@linwhf.opal.com> In-Reply-To: <20070330185000.GG1328@linwhf.opal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703311227.11217.hselasky@c2i.net> Cc: Subject: Re: Call For Testers: axe(4) with Ax88178 and Ax88772 support 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, 31 Mar 2007 10:27:33 -0000 On Friday 30 March 2007 20:50, J.R. Oldroyd wrote: > On Feb 15, 19:33, J.R. Oldroyd wrote: > > I have updated the axe(4) driver with Ax88178 and Ax88772 support. > > > > Go here to get it: > > http://opal.com/jr/freebsd/sys/dev/usb/ > > My original version of these Ax88178 and Ax88772 enhancements (back > in February) did not use the chips' input frame bursting because > the FreeBSD usb_ether framework does not support it. > > I have now enhanced the driver, removing its use of the usb_ether > framework, and doing its own buffer management with large input > buffers which can handle bursts of multiple input frames in one > buffer. > > The diffs and files on the web page referenced above have been > updated for this new version. > > The driver appears to work, and I have set it to burst up to 4096 > bytes. > > The device can actually burst up to 16384 bytes. However, if I set > it to burst more than 4096 bytes, the usb layer (ehci on my test > system) stalls, and all input stops after just a few input frames. > I'd appreciate feedback from anyone if larger burst sizes work for > you. See the notes on that web page for details of how to change > the driver's burst size. This sounds like a problem with the EHCI driver. If I pull your changes into the new USB stack, which will take some hours, can you do some work to install and test it? --HPS From owner-freebsd-usb@FreeBSD.ORG Sat Mar 31 11:01:57 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 69A2B16A403 for ; Sat, 31 Mar 2007 11:01:57 +0000 (UTC) (envelope-from laurent@kally.net) Received: from interoute.kally.fr (interoute.kally.fr [195.28.200.95]) by mx1.freebsd.org (Postfix) with ESMTP id CC1C313C44B for ; Sat, 31 Mar 2007 11:01:56 +0000 (UTC) (envelope-from laurent@kally.net) Received: (qmail 82454 invoked from network); 31 Mar 2007 10:59:55 -0000 Received: from dolphin.kally.fr (HELO SPUNKY) (kally@[82.243.145.147]) (envelope-sender ) by interoute.kally.fr (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 31 Mar 2007 10:59:54 -0000 From: "Hofmann, Laurent" To: References: <008701c77317$1dfbc5f0$59f351d0$@net> <200703310840.09253.hselasky@c2i.net> In-Reply-To: <200703310840.09253.hselasky@c2i.net> Date: Sat, 31 Mar 2007 13:01:37 +0200 Message-ID: <009c01c77383$f48c64a0$dda52de0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcdzXzrd1eUJhIPqTme0rA7Pg88AFAAJKcOQ Content-Language: fr X-Bogosity: Ham, tests=bogofilter, spamicity=0.499684, version=1.0.3 Subject: RE: Memory leak / Kernel Panic using snd_uaudio (USB Sound Card) 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, 31 Mar 2007 11:01:57 -0000 -----Message d'origine----- De : Hans Petter Selasky [mailto:hselasky@c2i.net] Envoy=E9 : samedi 31 = mars 2007 08:40 =C0 : freebsd-usb@freebsd.org Cc : Hofmann, Laurent Objet : = Re: Memory leak / Kernel Panic using snd_uaudio (USB Sound Card) The new USB stack has got a new uaudio driver also. I would try that = first. How to get the latest sources: svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b # # The following commands will # install the driver on FreeBSD: # cd i4b/trunk/i4b/FreeBSD.usb make S=3D../src package make install Then edit the file "install_uaudio.sh" and change it as needed, if you = are not=20 installing to /usr/src. ./install_uaudio.sh I am not sure what patches they MFC'ed from head to 6.2 release, = regarding the=20 sound system, so it might be that my "uaudio.c" won't compile. But that = can=20 easily be fixed if you send me the compile log where it breaks. --HPS -------------------------------------------------------------------------= --- ------- Thanks. I did what you told me, but when I compile the kernel, it crashes = compiling umass.c (Don't know how it is related ?) cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=3Dc99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth=3D100 --param large-function-growth=3D1000 -mno-align-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/dev/usb/umass.c /usr/src/sys/dev/usb/umass.c: In function `umass_cam_action': /usr/src/sys/dev/usb/umass.c:2626: error: structure has no member named `protocol' /usr/src/sys/dev/usb/umass.c:2626: error: `PROTO_SCSI' undeclared (first = use in this function) /usr/src/sys/dev/usb/umass.c:2626: error: (Each undeclared identifier is reported only once /usr/src/sys/dev/usb/umass.c:2626: error: for each function it appears = in.) /usr/src/sys/dev/usb/umass.c:2627: error: structure has no member named `protocol_version' /usr/src/sys/dev/usb/umass.c:2628: error: structure has no member named `transport' /usr/src/sys/dev/usb/umass.c:2628: error: `XPORT_USB' undeclared (first = use in this function) /usr/src/sys/dev/usb/umass.c:2629: error: structure has no member named `transport_version' /usr/src/sys/dev/usb/umass.c:2629: error: `XPORT_VERSION_UNSPECIFIED' undeclared (first use in this function) /usr/src/sys/dev/usb/umass.c:2630: error: structure has no member named `xport_specific' *** Error code 1 Stop in /usr/obj/usr/src/sys/Arwen. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. When I did "make install" it merged a lot of things in my /usr/src/sys, = not only audio... Is that normal ? Best Regards, Laurent H. From owner-freebsd-usb@FreeBSD.ORG Sat Mar 31 11:15:53 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F15416A403 for ; Sat, 31 Mar 2007 11:15:53 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id A34BD13C480 for ; Sat, 31 Mar 2007 11:15:52 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe01.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 433367175 for freebsd-usb@freebsd.org; Sat, 31 Mar 2007 13:15:51 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Sat, 31 Mar 2007 13:15:31 +0200 User-Agent: KMail/1.9.5 References: <008701c77317$1dfbc5f0$59f351d0$@net> <200703310840.09253.hselasky@c2i.net> <009c01c77383$f48c64a0$dda52de0$@net> In-Reply-To: <009c01c77383$f48c64a0$dda52de0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703311315.31654.hselasky@c2i.net> Subject: Re: Memory leak / Kernel Panic using snd_uaudio (USB Sound Card) 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, 31 Mar 2007 11:15:53 -0000 On Saturday 31 March 2007 13:01, Hofmann, Laurent wrote: > > Thanks. > I did what you told me, but when I compile the kernel, it crashes compiling > umass.c (Don't know how it is related ?) Just do a SVN update and try again. By a mistake I removed a patch for FreeBSD 6.2. By the way, if someone needs uaudio driver files for FreeBSD 7-current, then feel free to contact me, hence they made some changes to the FreeBSD 7-current sound API. > > When I did "make install" it merged a lot of things in my /usr/src/sys, not > only audio... Is that normal ? Yes, that is normal. The new USB stack contains rewritten USB drivers of all kinds. --HPS From owner-freebsd-usb@FreeBSD.ORG Sat Mar 31 12:31:06 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 393AC16A408 for ; Sat, 31 Mar 2007 12:31:06 +0000 (UTC) (envelope-from laurent@kally.net) Received: from interoute.kally.fr (interoute.kally.fr [195.28.200.95]) by mx1.freebsd.org (Postfix) with ESMTP id 9A84F13C469 for ; Sat, 31 Mar 2007 12:31:05 +0000 (UTC) (envelope-from laurent@kally.net) Received: (qmail 83370 invoked from network); 31 Mar 2007 12:29:01 -0000 Received: from dolphin.kally.fr (HELO SPUNKY) (kally@[82.243.145.147]) (envelope-sender ) by interoute.kally.fr (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 31 Mar 2007 12:28:59 -0000 From: "Hofmann, Laurent" To: References: <008701c77317$1dfbc5f0$59f351d0$@net> <200703310840.09253.hselasky@c2i.net> <009c01c77383$f48c64a0$dda52de0$@net> <200703311315.31654.hselasky@c2i.net> In-Reply-To: <200703311315.31654.hselasky@c2i.net> Date: Sat, 31 Mar 2007 14:30:42 +0200 Message-ID: <009d01c77390$66923050$33b690f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acdzha6S4Fyj/ct7QPCirTBJ9pyLuAACgFnA Content-Language: fr X-Bogosity: Ham, tests=bogofilter, spamicity=0.500000, version=1.0.3 Subject: RE: Memory leak / Kernel Panic using snd_uaudio (USB Sound Card) 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, 31 Mar 2007 12:31:06 -0000 -----Message d'origine----- De=A0: owner-freebsd-usb@freebsd.org = [mailto:owner-freebsd-usb@freebsd.org] De la part de Hans Petter Selasky Envoy=E9=A0: samedi 31 mars 2007 13:16 =C0=A0: freebsd-usb@freebsd.org Objet=A0: Re: Memory leak / Kernel Panic using snd_uaudio (USB Sound = Card) Just do a SVN update and try again. By a mistake I removed a patch for FreeBSD=20 6.2. --HPS Thank you very much. It compiled like a charm. I also included the = driver in the kernel instead of using it as a module. I'm now playing some music, I will tell you if the kernel panic still occur... Just one more remark : The driver is not detected as before : uaudio0: uaudio0: Play: 48000 Hz, 2 ch, 16-bit S-LE PCM format uaudio0: Record: 48000 Hz, 2 ch, 16-bit S-LE PCM format uaudio0: No midi sequencer uaudio0: WARNING: Unplugging the device while it is in use will cause a panic! pcm0: on uaudio0 dolphin# cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at ? (1p/1r/0v channels duplex default) Before I had more lines, one of these lines was indicating a 6 channel device. Now I have the feeling that only the front channels are = available ? Best Regards, Laurent H. PS : Do you know when these drivers will be included in Freebsd ? From owner-freebsd-usb@FreeBSD.ORG Sat Mar 31 12:44:34 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7469E16A402; Sat, 31 Mar 2007 12:44:34 +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 ABCED13C44B; Sat, 31 Mar 2007 12:44:33 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe06.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 453368645; Sat, 31 Mar 2007 14:44:32 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org, freebsd-multimedia@freebsd.org Date: Sat, 31 Mar 2007 14:44:12 +0200 User-Agent: KMail/1.9.5 References: <008701c77317$1dfbc5f0$59f351d0$@net> <200703311315.31654.hselasky@c2i.net> <009d01c77390$66923050$33b690f0$@net> In-Reply-To: <009d01c77390$66923050$33b690f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200703311444.12171.hselasky@c2i.net> Cc: Subject: Re: Memory leak / Kernel Panic using snd_uaudio (USB Sound Card) 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, 31 Mar 2007 12:44:34 -0000 On Saturday 31 March 2007 14:30, Hofmann, Laurent wrote: > -----Message d'origine----- > De=A0: owner-freebsd-usb@freebsd.org [mailto:owner-freebsd-usb@freebsd.or= g] > De la part de Hans Petter Selasky > Envoy=E9=A0: samedi 31 mars 2007 13:16 > =C0=A0: freebsd-usb@freebsd.org > Objet=A0: Re: Memory leak / Kernel Panic using snd_uaudio (USB Sound Card) > > > Just do a SVN update and try again. By a mistake I removed a patch for > FreeBSD > 6.2. > > --HPS > > > Thank you very much. It compiled like a charm. I also included the driver > in the kernel instead of using it as a module. > I'm now playing some music, I will tell you if the kernel panic still > occur... Ok. > > Just one more remark : > The driver is not detected as before : > uaudio0: > uaudio0: Play: 48000 Hz, 2 ch, 16-bit S-LE PCM format > uaudio0: Record: 48000 Hz, 2 ch, 16-bit S-LE PCM format > uaudio0: No midi sequencer > uaudio0: WARNING: Unplugging the device while it is in use will cause a > panic! > pcm0: on uaudio0 > > dolphin# cat /dev/sndstat > FreeBSD Audio Driver (newpcm) > Installed devices: > pcm0: at ? (1p/1r/0v channels duplex default) > > Before I had more lines, one of these lines was indicating a 6 channel > device. Now I have the feeling that only the front channels are available= ? I don't know if the current audio system supports more than 2 channels. There is a knob in uaudio.c that you can tune: static u_int8_t uaudio_default_channels =3D 2; But you probably have to add some code to tell the upper sound layers that= =20 there is more than 2 channels! > > PS : Do you know when these drivers will be included in Freebsd ? > I hoped before 7.0 was out, but it might be later. I am not the one decidin= g=20 that. But if many people like you turn up and tell the list how much faster= =20 and how much more solid the new USB stack is, then it might happen faster ;= =2D) =2D-HPS From owner-freebsd-usb@FreeBSD.ORG Sat Mar 31 13:49:21 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FE3816A40E for ; Sat, 31 Mar 2007 13:49:21 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id A07E913C458 for ; Sat, 31 Mar 2007 13:49:20 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe01.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 433463562 for freebsd-usb@freebsd.org; Sat, 31 Mar 2007 15:49:14 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Sat, 31 Mar 2007 15:48:53 +0200 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703311548.53805.hselasky@c2i.net> Subject: Code reference for the new USB stack and its device drivers 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, 31 Mar 2007 13:49:21 -0000 Hi, I have just compiled a code reference for the new USB stack and device drivers. http://www.turbocat.net/~hselasky/usb4bsd/dev_new_usb.pdf Old USB stack: http://www.leidinger.net/FreeBSD/src_docs/dev_usb.pdf For example: Compare "ehci_softc" in the new and the old USB stack. Compare "usbd_xfer" in the new and the old USB stack. Compare "axe_softc" in the new and the old USB stack. Anyone that can analyze the graphs? --HPS From owner-freebsd-usb@FreeBSD.ORG Sat Mar 31 15:34:14 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A43416A402 for ; Sat, 31 Mar 2007 15:34:14 +0000 (UTC) (envelope-from laurent@kally.net) Received: from interoute.kally.fr (interoute.kally.fr [195.28.200.95]) by mx1.freebsd.org (Postfix) with ESMTP id EF18213C4B8 for ; Sat, 31 Mar 2007 15:34:13 +0000 (UTC) (envelope-from laurent@kally.net) Received: (qmail 85512 invoked from network); 31 Mar 2007 15:32:11 -0000 Received: from dolphin.kally.fr (HELO SPUNKY) (kally@[82.243.145.147]) (envelope-sender ) by interoute.kally.fr (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 31 Mar 2007 15:32:09 -0000 From: "Hofmann, Laurent" To: , References: <008701c77317$1dfbc5f0$59f351d0$@net> <200703311315.31654.hselasky@c2i.net> <009d01c77390$66923050$33b690f0$@net> <200703311444.12171.hselasky@c2i.net> In-Reply-To: <200703311444.12171.hselasky@c2i.net> Date: Sat, 31 Mar 2007 17:33:54 +0200 Message-ID: <009f01c773a9$febec190$fc3c44b0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcdzkhPr4yR+0tAGRieVqVb7IbBrjgAF8uQA Content-Language: fr X-Bogosity: Ham, tests=bogofilter, spamicity=0.499999, version=1.0.3 Cc: Subject: RE: Memory leak / Kernel Panic using snd_uaudio (USB Sound Card) 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, 31 Mar 2007 15:34:14 -0000 -----Message d'origine----- > De : Hans Petter Selasky [mailto:hselasky@c2i.net] Envoy=E9 : samedi = 31=20 > mars 2007 14:44 =C0 : freebsd-usb@freebsd.org;=20 > freebsd-multimedia@freebsd.org Cc : Hofmann, Laurent Objet : Re:=20 > Memory leak / Kernel Panic using snd_uaudio (USB Sound Card) >=20 > I don't know if the current audio system supports more than 2 = channels. >=20 > There is a knob in uaudio.c that you can tune: >=20 > static u_int8_t uaudio_default_channels =3D 2; >=20 > But you probably have to add some code to tell the upper sound layers=20 > that there is more than 2 channels! Still not crashed, your new usb stack seems stable now with snd_uaudio ! Thank you very much for that. Aside, I do confirm that I was able to either use 2 or 6 channels with = the former driver. My "upper" sound layer (pulseaudio) was formerly able to start with either 2 or 6 channels using /dev/dsp. Now it crashes if I specify 6 channels. It is a little regression, I do not know if it can be addressed easily. Best Regards, Laurent H.