From a_hartwig at fastmail.fm Fri Aug 1 14:00:15 2008 From: a_hartwig at fastmail.fm (Arthur Hartwig) Date: Fri Aug 1 14:00:34 2008 Subject: usb/110988: [umass] [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken Message-ID: <200808011400.m71E0Eqw008482@freefall.freebsd.org> The following reply was made to PR usb/110988; it has been noted by GNATS. From: Arthur Hartwig To: bug-followup@FreeBSD.org, freebsdusb@bindone.de Cc: Subject: Re: usb/110988: [umass] [patch] Handling of quirk IGNORE_RESIDUE is umass.c is broken Date: Fri, 01 Aug 2008 23:45:32 +1000 Concerning the report that some ICY BOX IB-220U-Wh units display the problem described here and in PR 110991 and some don't I'll recount my experience. I recently bought 6 "no name" USB adapters for notebook IDE hard drives. Four of the adapters are silver in colour and came from the same supplier. The two other adapters (one red and one blue) came from a different supplier. Apart from the colour all adapters look the same on the outside. Inside there are small differences in the printed circuit board and the indicator LED. However the adapters behave quite differently. On both FreeBSD 6.3 and 7.0 the silver adapters all successfully dd a few blocks from the start of the disk but the other two adapters exit from the dd command reporting 0 blocks copied. Examination of the reports from usbdevs shows the silver adapters report use of a Initio chipset (Vendor=0x13fd, Product=0x1040) whereas the adapters which don't work report the Super Top chipset (Vendor=0x14cd, product=0x6600). Both sets of adapters work in Windows XP and Linux 2.6.24 Perhaps the Icy Box can contain one of a number different chipsets with the variant in behaviour dependent on the chipset used. I also have some USB adapters for SATA notebook drives. These use a JMicron chipset and work with FreeBSD 7.0. I would be happy to test a patch for FreeBSD 7.0 to make the Super Top based adapters work and verify that it doesn't break support for the other two adapters I have. From chrispetso at cablered.net.mx Sat Aug 2 21:40:05 2008 From: chrispetso at cablered.net.mx (chrispetso@cablered.net.mx) Date: Sat Aug 2 21:40:11 2008 Subject: usb/125238: Habu Mouse turns off in X Message-ID: <200808022140.m72Le4Nk011726@freefall.freebsd.org> The following reply was made to PR usb/125238; it has been noted by GNATS. From: chrispetso@cablered.net.mx To: bug-followup@FreeBSD.org Cc: Subject: Re: usb/125238: Habu Mouse turns off in X Date: Sat, 2 Aug 2008 15:52:24 -0500 (CDT) This issue is also present in FreeBSD 7-Stable 32bit but the issue takes longer to happen. My pc freezes hard in 32bit so theres no way to get any other info and last shows the freeze as a crash. I like the Habu due to it's speed not much of the keyboard shortcuts, they should have a way to turn those off so it acts as just a mouse and not a keyboard/mouse maybe that would fix the issue? Mouse works fine in Console but act's up in X. I have tried to use moused, no moused, Type Auto in Xorg.conf no fix. Very few decent mice are all USB so proper USB support is needed, thats the only issue I have atm. Any issue or other info please email me here. From chuckr at telenix.org Sun Aug 3 01:51:56 2008 From: chuckr at telenix.org (Chuck Robey) Date: Sun Aug 3 01:52:05 2008 Subject: handling a uhid device Message-ID: <48950493.6050407@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [if I don't get an answer here in 2 days, I'll be reposting to hackers, probably] I have been taking a terribly long time figuring out the Xorg code, so that I can start coding the Xorg Xinput tablet input device driver (for FreeBSD) which I'm tackling. I finished all of the Xorg research, which means I know about 85% of the stuff for the Xorg side of the house, however, I need one question answered as far as FreeBSD's uhid driver is concerned. As far as my uhid code goes, after I do the configuration (which is about 75% FreeBSD lib code, but the libusbhid driver, I can't get it to totally work, so I wrote some custom workaround code for parts I couldn't get to work, and they test 100% good. I'm not sure, really, if it's my _my_ problem or FreeBSD's problem on the libusbhid code, and I've made enough screwups so that I won't make assumptions here on other's work. Anyhow, I have gotten to the point in Xorg Xinput code where I'm handling the reading (completely after all of the configuration, and separate from the parsing, separate from the USB descriptor code too). The Xorg code manages the uhid input like a regular serial line, including being able to use signals to tell of there's input waiting on the uhid for a read() to pick up (it doesn't just block like my simple test code does). My *question* is, is the mechanics of the uhid driver, as it relates to reading the input, just like a regular serial tty line, so one could use signals to see if a read()'s going to block or not? If it's like I expect it would be, that's really good news for me. If it's not, I gotta write a lot of special code for it. The test situation I'm in isn't the best, so I thought I would ask, instead of trying to write code to test this (I'm not all that good at such code, it would take me a good while to be sure of it). If you could answer me, I sure would appreciate it, really. Am I being clear in my question? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiVBJMACgkQz62J6PPcoOkhvACfWrLWZKVuIDkGDIu/O2zdl2RQ 9RQAnjf+sGtf8ms7GmcCsJwogsgGzbWM =Bvf9 -----END PGP SIGNATURE----- From bugmaster at FreeBSD.org Mon Aug 4 11:07:04 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 4 11:09:09 2008 Subject: Current problem reports assigned to freebsd-usb@FreeBSD.org Message-ID: <200808041107.m74B73MC082236@freefall.freebsd.org> Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f 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 i386/46371 usb USB controller cannot be initialized on IBM Netfinity o bin/57255 usb usbd(8) and multi-function devices o usb/63621 usb [umass] [panic] USB MemoryStick Reader stalls/crashes o usb/67301 usb [uftdi] [panic] RTS and system panic o usb/69006 usb [usbdevs] [patch] Apple Cinema Display hangs USB ports o usb/71155 usb [ulpt] misbehaving usb-printer hangs processes, causes o usb/73307 usb [panic] Kernel panics on USB disconnect o usb/74771 usb [umass] [hang] mounting write-protected umass device a o usb/75705 usb [umass] [panic] da0 attach / Optio S4 (with backtrace) o usb/75797 usb [sound] 5.3-STABLE(2005 1/4) detect USB headset, But c o usb/76395 usb [uhci] USB printer does not work, usbdevs says "addr 0 o usb/77184 usb [umass] [panic] kernel panic on USB device disconnect, o usb/77294 usb [ucom] [panic] ucom + ulpcom panic o usb/79269 usb [ohci] USB ohci da0 plug/unplug causes crashes and loc o usb/79287 usb [uhci] [hang] UHCI hang after interrupt transfer o usb/79524 usb [ulpt] printing to Minolta PagePro 1[23]xxW via USB fa a usb/79656 usb [ehci] RHSC interrupts lost o usb/79722 usb [ehci] wrong alignments in ehci.h o usb/80040 usb [hang] Use of sound mixer causes system freeze with ua o usb/80361 usb [umass] [patch] mounting of Dell usb-stick fails o usb/80829 usb [modules] [panic] possible panic when loading USB-modu o usb/80862 usb [patch] USB locking issues: missing some Giant calls o usb/82350 usb [ucom] [panic] null pointer dereference in USB stack o usb/82520 usb [udbp] [reboot] Reboot when USL101 connected s usb/82569 usb [umass] [panic] USB mass storage plug/unplug causes sy o usb/82660 usb [ehci] [panic] EHCI: I/O stuck in state 'physrd'/panic o usb/83504 usb [kernel] [patch] SpeedTouch USB stop working on recent o usb/83563 usb [umass] [panic] Page Fault while detaching Mpman Usb d f usb/83677 usb [usb] [request] usb controller often not detected (Sun o usb/83756 usb [ums] [patch] Microsoft Intellimouse Explorer 4.0A doe 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 s usb/84336 usb [usb] [reboot] instant system reboot when unmounting a o usb/86767 usb [umass] [patch] bogus "slice starts beyond end of the o usb/88743 usb [hang] [regression] USB makes kernel hang at boot (reg s usb/89003 usb [request] LaCie Firewire drive not properly supported o usb/89954 usb [umass] [panic] USB Disk driver race condition? o usb/90700 usb [umass] [panic] Kernel panic on connect/mount/use umas o usb/91238 usb [umass] USB tape unit fails to write a second tape fil o usb/91283 usb [boot] [regression] booting very slow with usb devices o usb/91538 usb [ulpt] [patch] Unable to print to EPSON CX3500 o usb/91906 usb [ehci] [hang] FreeBSD hangs while booting with USB leg o usb/92052 usb [ulpt] usbd causes defunct process with busy file-hand o usb/92083 usb [ural] [panic] panic using WPA on ural NIC in 6.0-RELE o usb/92142 usb [uhub] SET_ADDR_FAILED and SHORT_XFER errors from usb o usb/92171 usb [panic] panic unplugging Vodafone Mobile Connect (UMTS o usb/93155 usb [ulpt] /dev/ulpt0: device busy, USB printer does not w o usb/93408 usb [mouse] hw.acpi.cpu.cx_lowest=C3 on AMD Turion causes o usb/93828 usb [ohci] [panic] ohci causes panic on boot (HP Pavillion o usb/94384 usb [panic] kernel panic with usb2 hardware o usb/94717 usb [ulpt] Reading from /dev/ulpt can break work of a UHCI o usb/94897 usb [panic] Kernel Panic when cleanly unmounting USB disk s usb/95348 usb [keyboard] USB keyboard unplug causes noise on screen o usb/95562 usb [umass] Write Stress in USB Mass drive causes "vinvalb s usb/95636 usb [umass] [boot] 5 minute delay at boot when using VT620 s usb/96120 usb [ums] [request] USB mouse not always detected o usb/96224 usb [usb] [msdosfs] mount_msdosfs cause page fault in sync o usb/96457 usb [umass] [panic] fatback on umass = reboot s usb/97286 usb [mouse] [request] MS Wireless Intellimouse Explorer 2. o usb/99431 usb [keyboard] FreeBSD on MSI 6566E (Intel 845E motherboar o usb/101096 usb [ural] [panic] USB WLAN occasionally causes kernel-pan o usb/101448 usb [ohci] FBSD 6.1-STABLE/AMD64 crashes under heavy USB/O o usb/101752 usb [umass] [panic] 6.1-RELEASE kernel panic on usb device o usb/102066 usb [ukbd] usb keyboard and multimedia keys don't work f usb/102096 usb [patch] usbd(8) does not handle multiple devices in on o usb/103025 usb [uhub] [panic] wrong detection of USB device for FreeB o usb/104292 usb [umass] [hang] system lockup on forced umount of usb-s o usb/104830 usb [umass] system crashes when copying data to umass devi o usb/105186 usb [ehci] [panic] USB 2.0/ehci on FreeBSD 6.2-PRE/AMD64 c o usb/106615 usb [uftdi] uftdi module does not automatically load with o usb/106648 usb [umass] [hang] USB Floppy on D1950 10 min Hang on Inse s usb/106832 usb USB HP printer is not detected by kernel when ACPI ena o usb/107248 usb [umass] [patch] scsi_da.c quirk for Cowon iAUDIO X5 MP o usb/107446 usb [umass] umass problems (usb and fw disks) o usb/107827 usb [ohci] [panic] ohci_add_done addr not found o usb/107848 usb [umass] [request] cannot access Samsung flash disk o usb/107924 usb [patch] usbd(8) does not call detach o usb/108513 usb [umass] Creative MuVo TX FM fails in 6.2-RELEASE [regr 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/110856 usb [ugen] [patch] interrupt in msgs are truncated when bu o usb/110988 usb [umass] [patch] Handling of quirk IGNORE_RESIDUE is um o usb/111753 usb [uhid] [panic] Replicable system panic involving UHID s usb/112568 usb [umass] [request] USB mode may wrong when mounting Pla o usb/112631 usb [panic] Problem with SONY DSC-S80 camera on umount o usb/112640 usb [usb] [hang] Kernel freezes when writing a file to an s usb/113629 usb [ukbd] Dropped USB keyboard events on Dell Latitude D6 o usb/113672 usb [ehci] [panic] Kernel panic with AEWIN CB6971 s usb/113977 usb [request] Need a way to set mode of USB disk's write c o usb/114310 usb [libusb] [patch] [panic] USB hub attachment panics ker o usb/114682 usb [umass] generic USB media-card reader unusable o kern/114780 usb [uplcom] [panic] Panics while stress testing the uplco o usb/115298 usb [ulpt] [panic] Turning off USB printer panics kernel o usb/116561 usb [umodem] [panic] RELENG_6 umodem panic "trying to slee o usb/116699 usb [usbhid] USB HID devices do not initialize at system b o usb/116947 usb [ukbd] [patch] [regression] enable boot protocol on th o usb/117200 usb [ugen] ugen0 prints strange string on attach if detach o usb/117313 usb [umass] [panic] panic on usb camera insertion o usb/117613 usb [uhci] [irq] uhci interrupt storm & USB leaked memory o usb/117946 usb [panic] D-Link DUB-E100 rev. B1 crashes FreeBSD 7.0-BE o usb/117955 usb [umass] [panic] inserting minolta dimage a2 crashes OS o usb/118140 usb [ucom] [patch] quick hack for ucom to get it behave wi o usb/118141 usb [ucom] usb serial and nokia phones ucomreadcb ucomread o usb/118353 usb [panic] [ppp] repeatable kernel panic during ppp(4) se o usb/118480 usb [umass] Timeout in USB mass storage freezes vfs layer o usb/119201 usb [cam] [patch] Quirks for Olympus FE-210 camera, LG and o usb/119481 usb [hang] FreeBSD not responding after connecting USB-Mas o usb/119509 usb USB flaky on Dell Optiplex 755 o usb/119513 usb [irq] inserting dlink dwl-g630 wireless card results i o usb/119977 usb [ums] Mouse does not work in a Cherry-USB keyboard/mou o usb/120017 usb [ehci] [patch] CS5536 (AMD Geode) USB 2.0 quirk o usb/120034 usb [hang] 6.2 & 6.3 hangs on boot at usb0: OHCI with 1.5 o usb/120283 usb [panic] Automation reboot with wireless keyboard & mou o usb/120321 usb [hang] System hangs when transferring data to WD MyBoo o usb/120729 usb [panic] fault while in kernel mode with connecting USB o usb/120786 usb Kernel panic when forced umount of a dettached USB Har o usb/121232 usb remove PCCARD rebooted system o usb/121275 usb [boot] FreeBSD fails to boot with usb legacy support e o usb/121474 usb [cam] [patch] QUIRK: SAMSUNG HM250JI in LaCie usb hard o usb/121708 usb [keyboard] nforce 650i mobo w/ usb keyboard infinite k o usb/121734 usb [ugen] ugen HP1022 printer device not working since up o usb/121755 usb [ohci] [patch] Fix panic after ohci/uhub cardbus devic o usb/122483 usb [panic] [ulpt] Repeatable panic in 7.0-STABLE o usb/122539 usb [ohci] [panic] AnyDATA ADU-E1000D - kernel panic: ohci o usb/122905 usb [ubsa] [patch] add Huawei E220 to ubsa o kern/123510 usb [ums] Mouse Wheel Fails to Work [regression] o usb/123690 usb Panic on USB device insertion when usb loaded as a mod o usb/123714 usb Panic when hald-storage-probe runs with umass device i o usb/124708 usb [panic] Kernel panic on USB KVM reattach o usb/124758 usb rum panics SMP kernel o kern/124777 usb [ucom] USB cua devices don't revert to tty devices whe o usb/124980 usb [panic] kernel panic on detaching unmounted umass devi o usb/125088 usb Touchpad not detected on Adesso AKB-430UG USB kbd/pad o usb/125450 usb [panic] Removing USB flash card while being accessed c o usb/125631 usb [usb][ums] kernel panic during bootup while 'Logitech 135 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/30929 usb [usb] [patch] use usbd to initialize USB ADSL modem o usb/40948 usb [umass] [request] USB HP CDW8200 does not work s usb/51958 usb [urio] [patch] update for urio driver s usb/52026 usb [usb] [request] umass driver support for InSystem ISD2 o usb/59698 usb [keyboard] [patch] Rework of ukbd HID to AT code trans s usb/62257 usb [umass] [request] card reader UCR-61S2B is only half-s o usb/66547 usb [ucom] Palm Tungsten T USB does not initialize correct o usb/68232 usb [ugen] [patch] ugen(4) isochronous handling correction o usb/70523 usb [umct] [patch] umct sending/receiving wrong characters o usb/71280 usb [aue] aue0 device (linksys usb100tx) doesn't work in 1 o usb/71416 usb [ugen] Cryptoflex e-gate USB token (ugen0) detach is n o usb/71417 usb [ugen] Cryptoflex e-gate USB token (ugen0) communicati o usb/71455 usb [umass] Slow USB umass performance of 5.3 s usb/72733 usb [ucom] [request] Kyocera 7135 Palm OS connection probl o usb/74211 usb [umass] USB flash drive causes CAM status 0x4 on 4.10R a usb/74453 usb [umass] [patch] Q-lity CD-RW USB ECW-043 (ScanLogic SL o usb/75764 usb [umass] [patch] "umass0: Phase Error" - no device for o usb/75800 usb [ucom] ucom1: init failed STALLED error in time of syn s usb/75928 usb [umass] [request] Cytronix SmartMedia card (SMC) reade o usb/76461 usb [umass] disklabel of umass(4)-CAM(4)-da(4) not used by o usb/76653 usb [umass] [patch] Problem with Asahi Optical usb device o usb/76732 usb Mouse problems with USB KVM Switch o usb/78984 usb [umass] [patch] Creative MUVO umass failure o usb/79723 usb [usb] [request] prepare for high speed isochronous tra o usb/80774 usb [patch] have "usbd_find_desc" in line with the other " s usb/80776 usb [udav] [request] UDAV device driver shouldn't use usb_ s usb/80777 usb [request] usb_rem_task() should wait for callback to c o usb/80854 usb [patch] [request] suggestion for new iface-no-probe me o usb/80935 usb [uvisor] [patch] uvisor.c is not work with CLIE TH55. o usb/81621 usb [ehci] [hang] external hd hangs under load on ehci o usb/83863 usb [ugen] Communication problem between opensc/openct via s usb/85067 usb [uscanner] Cannot attach ScanJet 4300C to usb device o usb/86298 usb [mouse] Known good USB mouse won't work with correct s o usb/87224 usb Cannot mount USB Zip750 o usb/87648 usb [mouse] Logitech USB-optical mouse problem. o usb/88408 usb [axe] axe0 read PHY failed o usb/91546 usb [umodem] [patch] Nokia 6630 mobile phone does not work o usb/91811 usb [umass] Compact Flash in HP Photosmart 2610 return " o usb/91896 usb camcontrol(8): Serial Number of USB Memory Sticks is n o usb/92852 usb [ums] [patch] Vertical scroll not working properly on o usb/93389 usb [umass] [patch] Digital Camera Pentax S60 don't work o usb/93872 usb [cam] [patch] SCSI quirk required for ELTA 8061 OL USB o usb/95037 usb [umass] USB disk not recognized on hot-plug. o usb/96381 usb [cam] [patch] add a quirk table entry for a flash ram o usb/97175 usb [umass] [hang] USB cardreader hangs system o usb/97472 usb [cam] [patch] add support for Olympus C150,D390 o usb/98343 usb [boot] BBB reset failed errors with Creative Muvo MP3 o usb/99538 usb [keyboard] while using USB keyboard default params of o usb/100746 usb [keyboard] system does not boot due to USB keyboard pr o usb/101761 usb [usb] [patch] [request] usb.h: increase maximal size o o usb/101775 usb [libusbhid] [patch] possible error in report descripto o usb/102678 usb [keyboard] Dell PowerEdge DRAC5 USB Keyboard does not o usb/102976 usb [panic] Casio Exilim Digital Camera causes panic on in o usb/103046 usb [ulpt] [patch] ulpt event driven I/O with select(2) an o usb/103289 usb [request] USB 2.0 problems on AMD LX-800 CPU and CS-55 o usb/103418 usb [usbhidctl] [patch] [request] usbhidctl: add ability t o usb/103917 usb [uhub] USB driver reports "Addr 0 should never happen" o usb/104290 usb [umass] [patch] quirk: TOSHIBA DVD-RAM drive (libretto o usb/104352 usb [ural] [patch] ural driver doesnt work o usb/104645 usb [umass] [request] Rave C-201 MP3 player does not commu o usb/105065 usb [ata] SATA - USB Bridge o usb/105361 usb [panic] Kernel panic during unmounting mass storage (C o usb/106041 usb [usb] [request] FreeBSD does not recognise Mustek Bear o usb/106621 usb [axe] [patch] DLINK DUB-E100 support broken o usb/106861 usb [usbdevs] [patch]: usbdevs update: Add product ACER Ze o usb/107243 usb [cam] [patch] Apacer USB Flash Drive quirk o usb/107388 usb [patch] [request] new driver: add utoppy device from N o usb/107496 usb [uhub] USB device problem on RELENG_6_2 (SHORT_XFER) [ o usb/107935 usb [uplcom] [panic] panic while accessing /dev/cuaU0 o usb/108056 usb [ohci] Mouse gets powered off during device probe when s usb/108344 usb [panic] kernel with atausb panics when unplugging USB o usb/110197 usb [umass] Sony PSP umass device does not detach from EHC s usb/110991 usb [usbdevs] [patch] QUIRK: Super Top IDE DEVICE (depends o usb/112461 usb [ehci] [request] ehci USB 2.0 doesn't work on nforce4 o usb/112463 usb [umass] problem with Samsung USB DVD writer, libscg an o usb/112944 usb [ulpt] [patch] Bi-directional access to HP LaserJet 10 o usb/113060 usb [usbdevs] [patch] Samsung printer not working in bidir o usb/113432 usb [ucom] WARNING: attempt to net_add_domain(netgraph) af o conf/114013 usb [patch] WITHOUT_USB allow to compil a lot of USB stuff o usb/114068 usb [umass] [patch] Problems with connection of the umass o usb/114916 usb [umass] [patch] USB Maxtor drive (L300RO) requires qui o usb/115400 usb [ehci] Problem with EHCI on ASUS M2N4-SLI o usb/115933 usb [uftdi] [patch] RATOC REX-USB60F (usb serial converter o usb/115935 usb [usbdevs] [patch] kernel counterproductively attaches o usb/116282 usb [ulpt] Cannot print on USB HP LJ1018 or LJ1300 o usb/117075 usb [scsi_da] [patch] quirk: USB Samsung YP-U3 MP3 o usb/117183 usb [panic] USB/fusefs -- panic while transferring large a o usb/117185 usb [umodem] [patch] Add support for UNION interface descr o usb/117205 usb [uscanner] [patch] uscanner support for HP ScanJet 447 o usb/117546 usb [uftdi] [patch] Add MaxStream ZigBee product ID to uft o usb/117598 usb [uaudio] [patch] Not possible to record with Plantroni o usb/117893 usb [umass] Lacie USB DVD writing failing o usb/117911 usb [ums] [request] Mouse Gembird MUSWC not work o usb/117938 usb [ums] [patch] Adding support for MS WL Natural and MS o usb/118098 usb [umass] 6th gen iPod causes problems when disconnectin o usb/118485 usb [usbdevs] [patch] Logitech Headset Workaround o usb/118686 usb [usbdevs] [patch] teach usbdevs / ubsa(4) about Huawei o usb/119150 usb [usbdevs] [patch] new usbdevs for CDMA 1xEVDO devices o usb/119227 usb [ubsa] [patch] ubsa buffer is too small; should be tun o usb/119389 usb [umass] Sony DSC-W1 CBI reset failed, STALLED [regress o usb/119633 usb [umass] umass0: BBB reset failed, IOERROR [regression] o usb/119653 usb [cam] [patch] iriver s7 player sync cache error patch o usb/119981 usb [axe] [patch] add support for LOGITEC LAN-GTJ/U2 gigab o usb/120572 usb [umass] [patch] quirk to support ASUS P535 as umass (a o usb/121045 usb [uftdi] [patch] Add support for PC-OP-RS1 and KURO-RS o usb/121169 usb [umass] Issues with usb mp3 player o usb/121184 usb [uipaq] [patch] add ids from linux ipaq driver (plus a o usb/121426 usb [patch] [uscanner] add HP ScanJet 3570C o usb/122025 usb [patch] uscanner does not attach to Epson RX620 printe o usb/122119 usb [umass] umass device causes creation of daX but not da o usb/122547 usb [ehci] USB Printer not being recognized after reboot p usb/122610 usb Add Verizon v740 support to ubsa(4) o usb/122621 usb [patch] [request] New driver for Sierra Wireless 3G US o usb/122712 usb [usbdevs] [patch] Sony Vaio RF keyboard/mouse receiver o usb/122813 usb [udbp] [request] udbp driver should be removed in favo o usb/122819 usb Patch to provide dynamic additions to the usb quirks t o usb/122936 usb [ucom][ubsa] Device does not receive interrupt o usb/122956 usb Support for Novatel Wireless XU870 3G Card o usb/122992 usb MotoROKR Z6 Phone not recognised by umass as USB disk. p usb/123148 usb [uscanner] [patch] Epson DX8400/50 needs uscanner to s p usb/123211 usb [udav] if_udav driver doesn't support Davicom 9601 USB o kern/123224 usb [ums] Scroll wheel breakage w/ USB MS Wireless Intelli o usb/123351 usb Add Reiner SCT cyberJack, Omnikey [26]020, Fujitsu Sie o usb/123352 usb Add Option GTMAX3.6/7.2 and Quallcomm MMC module devic o usb/123509 usb [umass] continuous reset Samsung SGH-G600 phone o usb/123611 usb [usb] BBB reset failed, STALLED from Imation/Mitsumi U o usb/123691 usb usbd(8): usbd hangs o usb/123959 usb [ums] add support for Razer Lachesis 4000dpi usb mouse o usb/123969 usb Supermicro H8SMi-2 usb problem o usb/124604 usb Wireless Mouse doesn't work o usb/125072 usb [uplcom] [patch] add Mobile Action MA-620 Infrared Ada o usb/125238 usb Habu Mouse turns off in X o usb/125264 usb [patch] sysctl for set usb mouse rate (very useful for o usb/125510 usb repeated plug and unplug of USB mass storage devices l o usb/125736 usb [ukbd] [hang] system hangs after AT keyboard detect if o usb/125941 usb [ums] not working wheel on my microsoft notebook optic 136 problems total. From magik at back-up.pl Tue Aug 5 15:02:41 2008 From: magik at back-up.pl (magik@back-up.pl) Date: Tue Aug 5 15:03:10 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 In-Reply-To: <200807242330.m6ONU70T091921@freefall.freebsd.org> References: <200807242330.m6ONU70T091921@freefall.freebsd.org> Message-ID: <5d252c1d8f1ddaed55d2467adea536ca@chi.fastbighost.com> On Thu, 24 Jul 2008 23:30:07 GMT, FreeBSD-gnats-submit@FreeBSD.org wrote: > Thank you very much for your problem report. > It has the internal identification `usb/125941'. > The individual assigned to look at your > report is: freebsd-usb. > > You can access the state of your problem report at any time > via this link: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 > >>Category: usb >>Responsible: freebsd-usb >>Synopsis: not working wheel on my microsoft notebook optical mouse > 3000 >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 I just fixed problem with wheel on my mouse and I'm sending in attachment patch for /usr/src/sys/dev/usb/ums.c file. -------------- next part -------------- --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 +++ ums.c 2008-08-05 17:24:51.885277111 +0200 @@ -402,6 +402,7 @@ sc->sc_loc_x.pos = 8; sc->sc_loc_y.pos = 16; sc->sc_loc_z.pos = 24; + sc->sc_loc_z.size = 8; sc->sc_loc_btn[0].pos = 0; sc->sc_loc_btn[1].pos = 1; sc->sc_loc_btn[2].pos = 2; From magik at back-up.pl Tue Aug 5 15:10:04 2008 From: magik at back-up.pl (magik@back-up.pl) Date: Tue Aug 5 15:10:19 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Message-ID: <200808051510.m75FA4Mh072601@freefall.freebsd.org> The following reply was made to PR usb/125941; it has been noted by GNATS. From: To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-usb@FreeBSD.org Cc: Subject: Re: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Date: Tue, 05 Aug 2008 10:03:15 -0400 --=_4e61a2c724f962cdbd164e201c553386 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Thu, 24 Jul 2008 23:30:07 GMT, FreeBSD-gnats-submit@FreeBSD.org wrote: > Thank you very much for your problem report. > It has the internal identification `usb/125941'. > The individual assigned to look at your > report is: freebsd-usb. > > You can access the state of your problem report at any time > via this link: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 > >>Category: usb >>Responsible: freebsd-usb >>Synopsis: not working wheel on my microsoft notebook optical mouse > 3000 >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 I just fixed problem with wheel on my mouse and I'm sending in attachment patch for /usr/src/sys/dev/usb/ums.c file. --=_4e61a2c724f962cdbd164e201c553386 Content-Transfer-Encoding: base64 Content-Type: text/plain; name="ums.c.diff"; charset="UTF-8" Content-Disposition: attachment; filename="ums.c.diff" LS0tIHVtcy5jLm9yaWcJMjAwOC0wOC0wNSAxNzoyNDoyMS44MTU5MzY5MTEgKzAyMDAKKysrIHVt cy5jCTIwMDgtMDgtMDUgMTc6MjQ6NTEuODg1Mjc3MTExICswMjAwCkBAIC00MDIsNiArNDAyLDcg QEAKIAkJc2MtPnNjX2xvY194LnBvcyA9IDg7CiAJCXNjLT5zY19sb2NfeS5wb3MgPSAxNjsKIAkJ c2MtPnNjX2xvY196LnBvcyA9IDI0OworICAgICAgICAgICAgICAgIHNjLT5zY19sb2Nfei5zaXpl ID0gODsKIAkJc2MtPnNjX2xvY19idG5bMF0ucG9zID0gMDsKIAkJc2MtPnNjX2xvY19idG5bMV0u cG9zID0gMTsKIAkJc2MtPnNjX2xvY19idG5bMl0ucG9zID0gMjsK --=_4e61a2c724f962cdbd164e201c553386-- From eugen at grosbein.pp.ru Tue Aug 5 16:30:06 2008 From: eugen at grosbein.pp.ru (Eugene Grosbein) Date: Tue Aug 5 16:30:14 2008 Subject: usb/96599: [usb] [patch] Sony Handycam DCR-HC32E memory stick slot Message-ID: <200808051630.m75GU5b1079779@freefall.freebsd.org> The following reply was made to PR usb/96599; it has been noted by GNATS. From: Eugene Grosbein To: bug-followup@freebsd.org Cc: maxim@freebsd.org Subject: Re: usb/96599: [usb] [patch] Sony Handycam DCR-HC32E memory stick slot Date: Wed, 6 Aug 2008 00:23:07 +0800 Hi! This PR is closed prematurily: iedowse never comitted needed quirk. It seems Maxim intimated src/sys/dev/usb/umass.c,v.1.135 but this very similar change does not cover SB_PRODUCT_SONY_HANDYCAM. The problem is still here in 7.0-STABLE and the patch is still the same and works for 7.0 too. Please reopen this PR. Eugene Grosbein From matthias.apitz at oclc.org Wed Aug 6 09:50:04 2008 From: matthias.apitz at oclc.org (Matthias Apitz) Date: Wed Aug 6 09:50:10 2008 Subject: usb/80361: [umass] [patch] mounting of Dell usb-stick fails Message-ID: <200808060950.m769o31j011075@freefall.freebsd.org> The following reply was made to PR usb/80361; it has been noted by GNATS. From: Matthias Apitz To: bug-followup@FreeBSD.org, fbusse@gmx.de Cc: Subject: Re: usb/80361: [umass] [patch] mounting of Dell usb-stick fails Date: Wed, 6 Aug 2008 11:30:54 +0200 I have the same problem in FreeBSD 7.0-REL with the following USB key: $ usbdevs -v ... port 2 addr 2: high speed, power 94 mA, config 1, Store'n'go(0x0020), Verbatim(0x08ec), rev 2.00 which only works (fine) when plug'ed in at boot time: da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3812MB (7807999 512 byte sectors: 255H 63S/T 486C) if you plug it in later you will get: Aug 6 10:19:36 rebelion kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Aug 6 10:19:36 rebelion kernel: da0: Removable Direct Access SCSI-0 device Aug 6 10:19:36 rebelion kernel: da0: 40.000MB/s transfers Aug 6 10:19:36 rebelion kernel: da0: Attempt to query device size failed: UNIT ATTENTION, Medium not present and the devices /dev/da0s* does not show up; you only may access /dev/da0 with fdisk(8) or even with dd(1); -- Matthias Apitz From info at tecodryer.com Wed Aug 6 21:41:57 2008 From: info at tecodryer.com (TECO DRYER) Date: Wed Aug 6 21:42:28 2008 Subject: Teco Industry is in the business of corn, wheat, paddy, and Message-ID: <20080806214156.1A3988FC1A@mx1.freebsd.org> vegetable dr Sender: "TECO DRYER" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Thu, 7 Aug 2008 00:12:28 +0300 Message-ID: <20080806211228280.5EE82352592F4A71@erkan-e90bf8060> X-Priority: 3 (Normal) Importance: Normal Teco Industry is in the business of corn, wheat, paddy, and vegetable drying machines and the production and marketing of silo & steel construction. Related to the machines that our company produce; Teco Industry has the representatives in Bulgaria, Albania, Ukraine, Tatarstan, Kazakhstan, Russia, Angola and Indonesia. Our partners in these countries are accepted as the leaders in the steel industry. The quality of produced machines is approved by international standards. Teco is guaranteed by CE and ISO 9001-2000 certificates. Teco also contributes to the national economy by creating jobs in designing, project, production, import and export. Teco materializes R&D activities with its professional staff. Quality results are presented to the customers during the production, import and export. Our company takes the leadership of producing and marketing nationally and internationally. For Grain, Oily Seeds, and Pulses: Silos Corn and Soybean Drying Machines Handling Systems like Bucket Elevator, Chain Conveyor and Helix Prop Towers and Catwalks for Handling Systems Unloading Truck Lifts Industrial Foundations, Steel Construction With the expert staff; we take an important target like ‘’Customer Satisfaction and Service Quality’’ and perform service and counseling duties successfully. -------------------------------------------------------------------------------- Contact Us , Teco Dryer Company is ready for a long partnership with you. Sales Engineer Erkan AYMAN eayman@tecodryer.com From dfilter at FreeBSD.ORG Thu Aug 7 19:40:05 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Thu Aug 7 19:40:15 2008 Subject: usb/120017: commit references a PR Message-ID: <200808071940.m77Je5E0030765@freefall.freebsd.org> The following reply was made to PR usb/120017; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: usb/120017: commit references a PR Date: Thu, 7 Aug 2008 19:33:02 +0000 (UTC) ivoras 2008-08-07 19:32:37 UTC FreeBSD src repository Modified files: (Branch: RELENG_7) sys/dev/usb ehci_pci.c Log: SVN rev 181384 on 2008-08-07 19:32:37Z by ivoras MFC 180791: Tweak for AMD GEODE USB/EHCI chip to support EHCI PR: usb/120017 Approved by: gnn (mentor) Revision Changes Path 1.28.2.4 +10 -1 src/sys/dev/usb/ehci_pci.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From eisvogel at embinet.de Thu Aug 7 20:30:07 2008 From: eisvogel at embinet.de (Stephan Eisvogel) Date: Thu Aug 7 20:30:17 2008 Subject: usb/80361: [umass] [patch] mounting of Dell usb-stick fails Message-ID: <200808072030.m77KU7TA034786@freefall.freebsd.org> The following reply was made to PR usb/80361; it has been noted by GNATS. From: Stephan Eisvogel To: bug-followup@FreeBSD.org, fbusse@gmx.de Cc: Matthias Apitz Subject: Re: usb/80361: [umass] [patch] mounting of Dell usb-stick fails Date: Thu, 7 Aug 2008 21:58:47 +0200 I just fished this device port 1 addr 2: high speed, power 140 mA, config 1, DT Elite HS 2.0(0x0015), Kingston(0x08ec), rev 2.00 out of my electronic devices dumpster and got it working with USB hot plugging using an adapted version of the patch by Mark Linimon. This is a 7-STABLE kernel. I tweaked the new quirk to cause a delay before bus rescan of 5000ms. As you can see its a Kingston brand outside, yet the vendor id points to M-Systems. I guess Kingston OEMed those using their own casing. What is interesting is the blue/red dual color LED on this stick, it will blink for a few seconds when you plug the device in and only then begin the idle "glowing" routine (after it has initialized?). My guess is that this particular device takes its time after power on in the order of a handful of seconds before becoming ready. Maybe it is scanning its flash banks or something instead of accepting commands right away. Other operating systems appear to have a retry mechanism (WinXP, Linux) whereas in BSD its all or nothing after 200ms of device attach. Regards, Stephan From az at FreeBSD.org Sat Aug 9 11:40:31 2008 From: az at FreeBSD.org (az@FreeBSD.org) Date: Sat Aug 9 11:40:37 2008 Subject: usb/96599: [usb] [patch] Sony Handycam DCR-HC32E memory stick slot Message-ID: <200808091140.m79BeUhb016061@freefall.freebsd.org> Synopsis: [usb] [patch] Sony Handycam DCR-HC32E memory stick slot State-Changed-From-To: closed->open State-Changed-By: az State-Changed-When: Sat Aug 9 11:40:29 UTC 2008 State-Changed-Why: re-opened since Eugene claims that patch is good and problem still there http://www.freebsd.org/cgi/query-pr.cgi?pr=96599 From linimon at FreeBSD.org Sun Aug 10 23:58:35 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Aug 10 23:58:47 2008 Subject: kern/126396: [panic] kernel panic after unplug USB Bluetooth device Message-ID: <200808102358.m7ANwZrs053283@freefall.freebsd.org> Old Synopsis: kernel panic after unplug USB Bluetooth device New Synopsis: [panic] kernel panic after unplug USB Bluetooth device Responsible-Changed-From-To: freebsd-bugs->freebsd-usb Responsible-Changed-By: linimon Responsible-Changed-When: Sun Aug 10 23:57:30 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126396 From spry at anarchy.in.the.ph Mon Aug 11 06:50:05 2008 From: spry at anarchy.in.the.ph (Mars G Miro) Date: Mon Aug 11 06:50:18 2008 Subject: usb/122905: [ubsa] [patch] add Huawei E220 to ubsa Message-ID: <200808110650.m7B6o5kV095970@freefall.freebsd.org> The following reply was made to PR usb/122905; it has been noted by GNATS. From: "Mars G Miro" To: "Wojciech Puchar" , bug-followup@freebsd.org, Volker , "Per olof Ljungmark" Cc: Subject: Re: usb/122905: [ubsa] [patch] add Huawei E220 to ubsa Date: Mon, 11 Aug 2008 14:45:58 +0800 Hi guys, This patch does work. The only catch is it's only up to 3G speeds (~384K), not HSDPA (~ 1Mbps++, see my comments in usb/118686). Has anyone noticed this? I did try the NetBSD driver, only to find out I'd crash on their latest CURRENT :-( Thanks. -- cheers mars From wojtek at wojtek.tensor.gdynia.pl Mon Aug 11 06:50:08 2008 From: wojtek at wojtek.tensor.gdynia.pl (Wojciech Puchar) Date: Mon Aug 11 06:50:18 2008 Subject: usb/122905: [ubsa] [patch] add Huawei E220 to ubsa Message-ID: <200808110650.m7B6o7Yt096020@freefall.freebsd.org> The following reply was made to PR usb/122905; it has been noted by GNATS. From: Wojciech Puchar To: Mars G Miro Cc: bug-followup@freebsd.org, Volker , Per olof Ljungmark Subject: Re: usb/122905: [ubsa] [patch] add Huawei E220 to ubsa Date: Mon, 11 Aug 2008 08:48:06 +0200 (CEST) > Hi guys, > > This patch does work. The only catch is it's only up to 3G speeds > (~384K), not HSDPA (~ 1Mbps++, see my comments in usb/118686). yes it is. i have no idea how to make it work at fill speed From dbn at bielefeldtsolutions.dk Mon Aug 11 09:37:28 2008 From: dbn at bielefeldtsolutions.dk (Daniel Bielefeldt) Date: Mon Aug 11 09:37:35 2008 Subject: USB Multiplex mode Message-ID: <48A00456.4010702@bielefeldtsolutions.dk> Hi, I've just purchased a samba 75 GSM modem. Unfortunly, I have problems setting it to multiplex mode. I have been searching around for a while now. And the only thig I can find is something about putting "{ 0x0681, 0x0034, ANY, {UQ_ASSUME_CM_OVER_DATA }}," into usb_quirks.c and then rebuild my kernel. But as I can see "CM_ASSUMCE_CM_OVER_DATA" has been removed, according to this: http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/usb_quirks.c Everytime I plug in the GSM modem I get this in my message log. --- snip ---- Aug 6 14:00:41 apollon root: Unknown USB device: vendor 0x0681 product 0x0034 bus uhub0 Aug 6 14:00:42 apollon kernel: ucom0: on uhub0 Aug 6 14:00:42 apollon kernel: ucom0: iclass 2/2 Aug 6 14:00:42 apollon kernel: ucom0: data interface 1, has CM over data, has no break Aug 6 14:00:42 apollon kernel: ucom0: status change notification available Aug 6 14:00:42 apollon kernel: ucom0: at uhub0 port 2 (addr 2) disconnected Aug 6 14:00:42 apollon kernel: ucom0: detached --- snip ---- Thanks in advance and kind regards, Daniel Bielefeldt From bugmaster at FreeBSD.org Mon Aug 11 11:07:11 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 11 11:09:07 2008 Subject: Current problem reports assigned to freebsd-usb@FreeBSD.org Message-ID: <200808111107.m7BB7AQf047363@freefall.freebsd.org> Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f 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 i386/46371 usb USB controller cannot be initialized on IBM Netfinity o bin/57255 usb usbd(8) and multi-function devices o usb/63621 usb [umass] [panic] USB MemoryStick Reader stalls/crashes o usb/67301 usb [uftdi] [panic] RTS and system panic o usb/69006 usb [usbdevs] [patch] Apple Cinema Display hangs USB ports o usb/71155 usb [ulpt] misbehaving usb-printer hangs processes, causes o usb/73307 usb [panic] Kernel panics on USB disconnect o usb/74771 usb [umass] [hang] mounting write-protected umass device a o usb/75705 usb [umass] [panic] da0 attach / Optio S4 (with backtrace) o usb/75797 usb [sound] 5.3-STABLE(2005 1/4) detect USB headset, But c o usb/76395 usb [uhci] USB printer does not work, usbdevs says "addr 0 o usb/77184 usb [umass] [panic] kernel panic on USB device disconnect, o usb/77294 usb [ucom] [panic] ucom + ulpcom panic o usb/79269 usb [ohci] USB ohci da0 plug/unplug causes crashes and loc o usb/79287 usb [uhci] [hang] UHCI hang after interrupt transfer o usb/79524 usb [ulpt] printing to Minolta PagePro 1[23]xxW via USB fa a usb/79656 usb [ehci] RHSC interrupts lost o usb/79722 usb [ehci] wrong alignments in ehci.h o usb/80040 usb [hang] Use of sound mixer causes system freeze with ua o usb/80361 usb [umass] [patch] mounting of Dell usb-stick fails o usb/80829 usb [modules] [panic] possible panic when loading USB-modu o usb/80862 usb [patch] USB locking issues: missing some Giant calls o usb/82350 usb [ucom] [panic] null pointer dereference in USB stack o usb/82520 usb [udbp] [reboot] Reboot when USL101 connected s usb/82569 usb [umass] [panic] USB mass storage plug/unplug causes sy o usb/82660 usb [ehci] [panic] EHCI: I/O stuck in state 'physrd'/panic o usb/83504 usb [kernel] [patch] SpeedTouch USB stop working on recent o usb/83563 usb [umass] [panic] Page Fault while detaching Mpman Usb d f usb/83677 usb [usb] [request] usb controller often not detected (Sun o usb/83756 usb [ums] [patch] Microsoft Intellimouse Explorer 4.0A doe 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 s usb/84336 usb [usb] [reboot] instant system reboot when unmounting a o usb/86767 usb [umass] [patch] bogus "slice starts beyond end of the o usb/88743 usb [hang] [regression] USB makes kernel hang at boot (reg s usb/89003 usb [request] LaCie Firewire drive not properly supported o usb/89954 usb [umass] [panic] USB Disk driver race condition? o usb/90700 usb [umass] [panic] Kernel panic on connect/mount/use umas o usb/91238 usb [umass] USB tape unit fails to write a second tape fil o usb/91283 usb [boot] [regression] booting very slow with usb devices o usb/91538 usb [ulpt] [patch] Unable to print to EPSON CX3500 o usb/91906 usb [ehci] [hang] FreeBSD hangs while booting with USB leg o usb/92052 usb [ulpt] usbd causes defunct process with busy file-hand o usb/92083 usb [ural] [panic] panic using WPA on ural NIC in 6.0-RELE o usb/92142 usb [uhub] SET_ADDR_FAILED and SHORT_XFER errors from usb o usb/92171 usb [panic] panic unplugging Vodafone Mobile Connect (UMTS o usb/93155 usb [ulpt] /dev/ulpt0: device busy, USB printer does not w o usb/93408 usb [mouse] hw.acpi.cpu.cx_lowest=C3 on AMD Turion causes o usb/93828 usb [ohci] [panic] ohci causes panic on boot (HP Pavillion o usb/94384 usb [panic] kernel panic with usb2 hardware o usb/94717 usb [ulpt] Reading from /dev/ulpt can break work of a UHCI o usb/94897 usb [panic] Kernel Panic when cleanly unmounting USB disk s usb/95348 usb [keyboard] USB keyboard unplug causes noise on screen o usb/95562 usb [umass] Write Stress in USB Mass drive causes "vinvalb s usb/95636 usb [umass] [boot] 5 minute delay at boot when using VT620 s usb/96120 usb [ums] [request] USB mouse not always detected o usb/96224 usb [usb] [msdosfs] mount_msdosfs cause page fault in sync o usb/96457 usb [umass] [panic] fatback on umass = reboot s usb/97286 usb [mouse] [request] MS Wireless Intellimouse Explorer 2. o usb/99431 usb [keyboard] FreeBSD on MSI 6566E (Intel 845E motherboar o usb/101096 usb [ural] [panic] USB WLAN occasionally causes kernel-pan o usb/101448 usb [ohci] FBSD 6.1-STABLE/AMD64 crashes under heavy USB/O o usb/101752 usb [umass] [panic] 6.1-RELEASE kernel panic on usb device o usb/102066 usb [ukbd] usb keyboard and multimedia keys don't work f usb/102096 usb [patch] usbd(8) does not handle multiple devices in on o usb/103025 usb [uhub] [panic] wrong detection of USB device for FreeB o usb/104292 usb [umass] [hang] system lockup on forced umount of usb-s o usb/104830 usb [umass] system crashes when copying data to umass devi o usb/105186 usb [ehci] [panic] USB 2.0/ehci on FreeBSD 6.2-PRE/AMD64 c o usb/106615 usb [uftdi] uftdi module does not automatically load with o usb/106648 usb [umass] [hang] USB Floppy on D1950 10 min Hang on Inse s usb/106832 usb USB HP printer is not detected by kernel when ACPI ena o usb/107248 usb [umass] [patch] scsi_da.c quirk for Cowon iAUDIO X5 MP o usb/107446 usb [umass] umass problems (usb and fw disks) o usb/107827 usb [ohci] [panic] ohci_add_done addr not found o usb/107848 usb [umass] [request] cannot access Samsung flash disk o usb/107924 usb [patch] usbd(8) does not call detach o usb/108513 usb [umass] Creative MuVo TX FM fails in 6.2-RELEASE [regr 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/110856 usb [ugen] [patch] interrupt in msgs are truncated when bu o usb/110988 usb [umass] [patch] Handling of quirk IGNORE_RESIDUE is um o usb/111753 usb [uhid] [panic] Replicable system panic involving UHID s usb/112568 usb [umass] [request] USB mode may wrong when mounting Pla o usb/112631 usb [panic] Problem with SONY DSC-S80 camera on umount o usb/112640 usb [usb] [hang] Kernel freezes when writing a file to an s usb/113629 usb [ukbd] Dropped USB keyboard events on Dell Latitude D6 o usb/113672 usb [ehci] [panic] Kernel panic with AEWIN CB6971 s usb/113977 usb [request] Need a way to set mode of USB disk's write c o usb/114310 usb [libusb] [patch] [panic] USB hub attachment panics ker o usb/114682 usb [umass] generic USB media-card reader unusable o kern/114780 usb [uplcom] [panic] Panics while stress testing the uplco o usb/115298 usb [ulpt] [panic] Turning off USB printer panics kernel o usb/116561 usb [umodem] [panic] RELENG_6 umodem panic "trying to slee o usb/116699 usb [usbhid] USB HID devices do not initialize at system b o usb/116947 usb [ukbd] [patch] [regression] enable boot protocol on th o usb/117200 usb [ugen] ugen0 prints strange string on attach if detach o usb/117313 usb [umass] [panic] panic on usb camera insertion o usb/117613 usb [uhci] [irq] uhci interrupt storm & USB leaked memory o usb/117946 usb [panic] D-Link DUB-E100 rev. B1 crashes FreeBSD 7.0-BE o usb/117955 usb [umass] [panic] inserting minolta dimage a2 crashes OS o usb/118140 usb [ucom] [patch] quick hack for ucom to get it behave wi o usb/118141 usb [ucom] usb serial and nokia phones ucomreadcb ucomread o usb/118353 usb [panic] [ppp] repeatable kernel panic during ppp(4) se o usb/118480 usb [umass] Timeout in USB mass storage freezes vfs layer o usb/119201 usb [cam] [patch] Quirks for Olympus FE-210 camera, LG and o usb/119481 usb [hang] FreeBSD not responding after connecting USB-Mas o usb/119509 usb USB flaky on Dell Optiplex 755 o usb/119513 usb [irq] inserting dlink dwl-g630 wireless card results i o usb/119977 usb [ums] Mouse does not work in a Cherry-USB keyboard/mou o usb/120017 usb [ehci] [patch] CS5536 (AMD Geode) USB 2.0 quirk o usb/120034 usb [hang] 6.2 & 6.3 hangs on boot at usb0: OHCI with 1.5 o usb/120283 usb [panic] Automation reboot with wireless keyboard & mou o usb/120321 usb [hang] System hangs when transferring data to WD MyBoo o usb/120729 usb [panic] fault while in kernel mode with connecting USB o usb/120786 usb Kernel panic when forced umount of a dettached USB Har o usb/121232 usb remove PCCARD rebooted system o usb/121275 usb [boot] FreeBSD fails to boot with usb legacy support e o usb/121474 usb [cam] [patch] QUIRK: SAMSUNG HM250JI in LaCie usb hard o usb/121708 usb [keyboard] nforce 650i mobo w/ usb keyboard infinite k o usb/121734 usb [ugen] ugen HP1022 printer device not working since up o usb/121755 usb [ohci] [patch] Fix panic after ohci/uhub cardbus devic o usb/122483 usb [panic] [ulpt] Repeatable panic in 7.0-STABLE o usb/122539 usb [ohci] [panic] AnyDATA ADU-E1000D - kernel panic: ohci o usb/122905 usb [ubsa] [patch] add Huawei E220 to ubsa o kern/123510 usb [ums] Mouse Wheel Fails to Work [regression] o usb/123690 usb Panic on USB device insertion when usb loaded as a mod o usb/123714 usb Panic when hald-storage-probe runs with umass device i o usb/124708 usb [panic] Kernel panic on USB KVM reattach o usb/124758 usb rum panics SMP kernel o kern/124777 usb [ucom] USB cua devices don't revert to tty devices whe o usb/124980 usb [panic] kernel panic on detaching unmounted umass devi o usb/125088 usb Touchpad not detected on Adesso AKB-430UG USB kbd/pad o usb/125450 usb [panic] Removing USB flash card while being accessed c o usb/125631 usb [usb][ums] kernel panic during bootup while 'Logitech o kern/126396 usb [panic] kernel panic after unplug USB Bluetooth device 136 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/30929 usb [usb] [patch] use usbd to initialize USB ADSL modem o usb/40948 usb [umass] [request] USB HP CDW8200 does not work s usb/51958 usb [urio] [patch] update for urio driver s usb/52026 usb [usb] [request] umass driver support for InSystem ISD2 o usb/59698 usb [keyboard] [patch] Rework of ukbd HID to AT code trans s usb/62257 usb [umass] [request] card reader UCR-61S2B is only half-s o usb/66547 usb [ucom] Palm Tungsten T USB does not initialize correct o usb/68232 usb [ugen] [patch] ugen(4) isochronous handling correction o usb/70523 usb [umct] [patch] umct sending/receiving wrong characters o usb/71280 usb [aue] aue0 device (linksys usb100tx) doesn't work in 1 o usb/71416 usb [ugen] Cryptoflex e-gate USB token (ugen0) detach is n o usb/71417 usb [ugen] Cryptoflex e-gate USB token (ugen0) communicati o usb/71455 usb [umass] Slow USB umass performance of 5.3 s usb/72733 usb [ucom] [request] Kyocera 7135 Palm OS connection probl o usb/74211 usb [umass] USB flash drive causes CAM status 0x4 on 4.10R a usb/74453 usb [umass] [patch] Q-lity CD-RW USB ECW-043 (ScanLogic SL o usb/75764 usb [umass] [patch] "umass0: Phase Error" - no device for o usb/75800 usb [ucom] ucom1: init failed STALLED error in time of syn s usb/75928 usb [umass] [request] Cytronix SmartMedia card (SMC) reade o usb/76461 usb [umass] disklabel of umass(4)-CAM(4)-da(4) not used by o usb/76653 usb [umass] [patch] Problem with Asahi Optical usb device o usb/76732 usb Mouse problems with USB KVM Switch o usb/78984 usb [umass] [patch] Creative MUVO umass failure o usb/79723 usb [usb] [request] prepare for high speed isochronous tra o usb/80774 usb [patch] have "usbd_find_desc" in line with the other " s usb/80776 usb [udav] [request] UDAV device driver shouldn't use usb_ s usb/80777 usb [request] usb_rem_task() should wait for callback to c o usb/80854 usb [patch] [request] suggestion for new iface-no-probe me o usb/80935 usb [uvisor] [patch] uvisor.c is not work with CLIE TH55. o usb/81621 usb [ehci] [hang] external hd hangs under load on ehci o usb/83863 usb [ugen] Communication problem between opensc/openct via s usb/85067 usb [uscanner] Cannot attach ScanJet 4300C to usb device o usb/86298 usb [mouse] Known good USB mouse won't work with correct s o usb/87224 usb Cannot mount USB Zip750 o usb/87648 usb [mouse] Logitech USB-optical mouse problem. o usb/88408 usb [axe] axe0 read PHY failed o usb/91546 usb [umodem] [patch] Nokia 6630 mobile phone does not work o usb/91811 usb [umass] Compact Flash in HP Photosmart 2610 return " o usb/91896 usb camcontrol(8): Serial Number of USB Memory Sticks is n o usb/92852 usb [ums] [patch] Vertical scroll not working properly on o usb/93389 usb [umass] [patch] Digital Camera Pentax S60 don't work o usb/93872 usb [cam] [patch] SCSI quirk required for ELTA 8061 OL USB o usb/95037 usb [umass] USB disk not recognized on hot-plug. o usb/96381 usb [cam] [patch] add a quirk table entry for a flash ram o usb/96599 usb [usb] [patch] Sony Handycam DCR-HC32E memory stick slo o usb/97175 usb [umass] [hang] USB cardreader hangs system o usb/97472 usb [cam] [patch] add support for Olympus C150,D390 o usb/98343 usb [boot] BBB reset failed errors with Creative Muvo MP3 o usb/99538 usb [keyboard] while using USB keyboard default params of o usb/100746 usb [keyboard] system does not boot due to USB keyboard pr o usb/101761 usb [usb] [patch] [request] usb.h: increase maximal size o o usb/101775 usb [libusbhid] [patch] possible error in report descripto o usb/102678 usb [keyboard] Dell PowerEdge DRAC5 USB Keyboard does not o usb/102976 usb [panic] Casio Exilim Digital Camera causes panic on in o usb/103046 usb [ulpt] [patch] ulpt event driven I/O with select(2) an o usb/103289 usb [request] USB 2.0 problems on AMD LX-800 CPU and CS-55 o usb/103418 usb [usbhidctl] [patch] [request] usbhidctl: add ability t o usb/103917 usb [uhub] USB driver reports "Addr 0 should never happen" o usb/104290 usb [umass] [patch] quirk: TOSHIBA DVD-RAM drive (libretto o usb/104352 usb [ural] [patch] ural driver doesnt work o usb/104645 usb [umass] [request] Rave C-201 MP3 player does not commu o usb/105065 usb [ata] SATA - USB Bridge o usb/105361 usb [panic] Kernel panic during unmounting mass storage (C o usb/106041 usb [usb] [request] FreeBSD does not recognise Mustek Bear o usb/106621 usb [axe] [patch] DLINK DUB-E100 support broken o usb/106861 usb [usbdevs] [patch]: usbdevs update: Add product ACER Ze o usb/107243 usb [cam] [patch] Apacer USB Flash Drive quirk o usb/107388 usb [patch] [request] new driver: add utoppy device from N o usb/107496 usb [uhub] USB device problem on RELENG_6_2 (SHORT_XFER) [ o usb/107935 usb [uplcom] [panic] panic while accessing /dev/cuaU0 o usb/108056 usb [ohci] Mouse gets powered off during device probe when s usb/108344 usb [panic] kernel with atausb panics when unplugging USB o usb/110197 usb [umass] Sony PSP umass device does not detach from EHC s usb/110991 usb [usbdevs] [patch] QUIRK: Super Top IDE DEVICE (depends o usb/112461 usb [ehci] [request] ehci USB 2.0 doesn't work on nforce4 o usb/112463 usb [umass] problem with Samsung USB DVD writer, libscg an o usb/112944 usb [ulpt] [patch] Bi-directional access to HP LaserJet 10 o usb/113060 usb [usbdevs] [patch] Samsung printer not working in bidir o usb/113432 usb [ucom] WARNING: attempt to net_add_domain(netgraph) af o conf/114013 usb [patch] WITHOUT_USB allow to compil a lot of USB stuff o usb/114068 usb [umass] [patch] Problems with connection of the umass o usb/114916 usb [umass] [patch] USB Maxtor drive (L300RO) requires qui o usb/115400 usb [ehci] Problem with EHCI on ASUS M2N4-SLI o usb/115933 usb [uftdi] [patch] RATOC REX-USB60F (usb serial converter o usb/115935 usb [usbdevs] [patch] kernel counterproductively attaches o usb/116282 usb [ulpt] Cannot print on USB HP LJ1018 or LJ1300 o usb/117075 usb [scsi_da] [patch] quirk: USB Samsung YP-U3 MP3 o usb/117183 usb [panic] USB/fusefs -- panic while transferring large a o usb/117185 usb [umodem] [patch] Add support for UNION interface descr o usb/117205 usb [uscanner] [patch] uscanner support for HP ScanJet 447 o usb/117546 usb [uftdi] [patch] Add MaxStream ZigBee product ID to uft o usb/117598 usb [uaudio] [patch] Not possible to record with Plantroni o usb/117893 usb [umass] Lacie USB DVD writing failing o usb/117911 usb [ums] [request] Mouse Gembird MUSWC not work o usb/117938 usb [ums] [patch] Adding support for MS WL Natural and MS o usb/118098 usb [umass] 6th gen iPod causes problems when disconnectin o usb/118485 usb [usbdevs] [patch] Logitech Headset Workaround o usb/118686 usb [usbdevs] [patch] teach usbdevs / ubsa(4) about Huawei o usb/119150 usb [usbdevs] [patch] new usbdevs for CDMA 1xEVDO devices o usb/119227 usb [ubsa] [patch] ubsa buffer is too small; should be tun o usb/119389 usb [umass] Sony DSC-W1 CBI reset failed, STALLED [regress o usb/119633 usb [umass] umass0: BBB reset failed, IOERROR [regression] o usb/119653 usb [cam] [patch] iriver s7 player sync cache error patch o usb/119981 usb [axe] [patch] add support for LOGITEC LAN-GTJ/U2 gigab o usb/120572 usb [umass] [patch] quirk to support ASUS P535 as umass (a o usb/121045 usb [uftdi] [patch] Add support for PC-OP-RS1 and KURO-RS o usb/121169 usb [umass] Issues with usb mp3 player o usb/121184 usb [uipaq] [patch] add ids from linux ipaq driver (plus a o usb/121426 usb [patch] [uscanner] add HP ScanJet 3570C o usb/122025 usb [patch] uscanner does not attach to Epson RX620 printe o usb/122119 usb [umass] umass device causes creation of daX but not da o usb/122547 usb [ehci] USB Printer not being recognized after reboot p usb/122610 usb Add Verizon v740 support to ubsa(4) o usb/122621 usb [patch] [request] New driver for Sierra Wireless 3G US o usb/122712 usb [usbdevs] [patch] Sony Vaio RF keyboard/mouse receiver o usb/122813 usb [udbp] [request] udbp driver should be removed in favo o usb/122819 usb Patch to provide dynamic additions to the usb quirks t o usb/122936 usb [ucom][ubsa] Device does not receive interrupt o usb/122956 usb Support for Novatel Wireless XU870 3G Card o usb/122992 usb MotoROKR Z6 Phone not recognised by umass as USB disk. p usb/123148 usb [uscanner] [patch] Epson DX8400/50 needs uscanner to s p usb/123211 usb [udav] if_udav driver doesn't support Davicom 9601 USB o kern/123224 usb [ums] Scroll wheel breakage w/ USB MS Wireless Intelli o usb/123351 usb Add Reiner SCT cyberJack, Omnikey [26]020, Fujitsu Sie o usb/123352 usb Add Option GTMAX3.6/7.2 and Quallcomm MMC module devic o usb/123509 usb [umass] continuous reset Samsung SGH-G600 phone o usb/123611 usb [usb] BBB reset failed, STALLED from Imation/Mitsumi U o usb/123691 usb usbd(8): usbd hangs o usb/123959 usb [ums] add support for Razer Lachesis 4000dpi usb mouse o usb/123969 usb Supermicro H8SMi-2 usb problem o usb/124604 usb Wireless Mouse doesn't work o usb/125072 usb [uplcom] [patch] add Mobile Action MA-620 Infrared Ada o usb/125238 usb Habu Mouse turns off in X o usb/125264 usb [patch] sysctl for set usb mouse rate (very useful for o usb/125510 usb repeated plug and unplug of USB mass storage devices l o usb/125736 usb [ukbd] [hang] system hangs after AT keyboard detect if o usb/125941 usb [ums] not working wheel on my microsoft notebook optic 137 problems total. From kaiwang27 at gmail.com Mon Aug 11 13:40:04 2008 From: kaiwang27 at gmail.com (Kai Wang) Date: Mon Aug 11 13:40:11 2008 Subject: kern/123510: [ums] Mouse Wheel Fails to Work [regression] Message-ID: <200808111340.m7BDe3gh067505@freefall.freebsd.org> The following reply was made to PR kern/123510; it has been noted by GNATS. From: Kai Wang To: bug-followup@FreeBSD.org, tmdraney@verizon.net Cc: Subject: Re: kern/123510: [ums] Mouse Wheel Fails to Work [regression] Date: Mon, 11 Aug 2008 15:10:01 +0200 Hello Merritt, Since /usr/src/sys/dev/usb/ums.c rev 1.96.2.1 worked for you, I guess this might be caused by rev 1.97 which removed "TWHEEL" stuff. Could you please try the patch below and see if it also fix the problem? (Patch should apply to latest -STABLE or -CURRENT) Thanks, Kai --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 +0200 +++ ums.c.new 2008-08-11 15:00:37.000000000 +0200 @@ -283,6 +283,9 @@ /* Try the wheel first as the Z activator since it's tradition. */ wheel = hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_WHEEL), + hid_input, &sc->sc_loc_z, &flags) || + hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, + HUG_TWHEEL), hid_input, &sc->sc_loc_z, &flags); if (wheel) { From kaiwang27 at gmail.com Mon Aug 11 14:00:15 2008 From: kaiwang27 at gmail.com (Kai Wang) Date: Mon Aug 11 14:00:21 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Message-ID: <200808111400.m7BE0Ejp068179@freefall.freebsd.org> The following reply was made to PR usb/125941; it has been noted by GNATS. From: Kai Wang To: magik@back-up.pl Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: Re: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Date: Mon, 11 Aug 2008 15:34:34 +0200 On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl wrote: > > > On Thu, 24 Jul 2008 23:30:07 GMT, FreeBSD-gnats-submit@FreeBSD.org wrote: > > Thank you very much for your problem report. > > It has the internal identification `usb/125941'. > > The individual assigned to look at your > > report is: freebsd-usb. > > > > You can access the state of your problem report at any time > > via this link: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 > > > >>Category: usb > >>Responsible: freebsd-usb > >>Synopsis: not working wheel on my microsoft notebook optical mouse > > 3000 > >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 > > I just fixed problem with wheel on my mouse > and I'm sending in attachment patch for /usr/src/sys/dev/usb/ums.c file. > --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 > +++ ums.c 2008-08-05 17:24:51.885277111 +0200 > @@ -402,6 +402,7 @@ > sc->sc_loc_x.pos = 8; > sc->sc_loc_y.pos = 16; > sc->sc_loc_z.pos = 24; > + sc->sc_loc_z.size = 8; > sc->sc_loc_btn[0].pos = 0; > sc->sc_loc_btn[1].pos = 1; > sc->sc_loc_btn[2].pos = 2; Hi, Thanks for submitting the patch. It'd be great if you could also test the patch below for us and paste the result here, just for better understanding the problem. The patch adds some debug printfs: --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 +0200 +++ ums.c 2008-08-11 15:25:44.000000000 +0200 @@ -284,6 +284,7 @@ wheel = hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_WHEEL), hid_input, &sc->sc_loc_z, &flags); + printf("wheel=%d\n", wheel); if (wheel) { if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { @@ -323,6 +324,7 @@ sc->flags |= UMS_Z; } } + printf("sc->flags=0x%04x\n", sc->flags); /* * The Microsoft Wireless Intellimouse 2.0 reports it's wheel @@ -402,6 +404,7 @@ sc->sc_loc_x.pos = 8; sc->sc_loc_y.pos = 16; sc->sc_loc_z.pos = 24; + printf("sc->sc_loc_z.size=%u\n", sc->sc_loc_z.size); sc->sc_loc_btn[0].pos = 0; sc->sc_loc_btn[1].pos = 1; sc->sc_loc_btn[2].pos = 2; From kaiwang27 at gmail.com Mon Aug 11 14:02:49 2008 From: kaiwang27 at gmail.com (Kai Wang) Date: Mon Aug 11 14:02:56 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 In-Reply-To: <5d252c1d8f1ddaed55d2467adea536ca@chi.fastbighost.com> References: <200807242330.m6ONU70T091921@freefall.freebsd.org> <5d252c1d8f1ddaed55d2467adea536ca@chi.fastbighost.com> Message-ID: <20080811133434.GA4224@plan0> On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl wrote: > > > On Thu, 24 Jul 2008 23:30:07 GMT, FreeBSD-gnats-submit@FreeBSD.org wrote: > > Thank you very much for your problem report. > > It has the internal identification `usb/125941'. > > The individual assigned to look at your > > report is: freebsd-usb. > > > > You can access the state of your problem report at any time > > via this link: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 > > > >>Category: usb > >>Responsible: freebsd-usb > >>Synopsis: not working wheel on my microsoft notebook optical mouse > > 3000 > >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 > > I just fixed problem with wheel on my mouse > and I'm sending in attachment patch for /usr/src/sys/dev/usb/ums.c file. > --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 > +++ ums.c 2008-08-05 17:24:51.885277111 +0200 > @@ -402,6 +402,7 @@ > sc->sc_loc_x.pos = 8; > sc->sc_loc_y.pos = 16; > sc->sc_loc_z.pos = 24; > + sc->sc_loc_z.size = 8; > sc->sc_loc_btn[0].pos = 0; > sc->sc_loc_btn[1].pos = 1; > sc->sc_loc_btn[2].pos = 2; Hi, Thanks for submitting the patch. It'd be great if you could also test the patch below for us and paste the result here, just for better understanding the problem. The patch adds some debug printfs: --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 +0200 +++ ums.c 2008-08-11 15:25:44.000000000 +0200 @@ -284,6 +284,7 @@ wheel = hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_WHEEL), hid_input, &sc->sc_loc_z, &flags); + printf("wheel=%d\n", wheel); if (wheel) { if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { @@ -323,6 +324,7 @@ sc->flags |= UMS_Z; } } + printf("sc->flags=0x%04x\n", sc->flags); /* * The Microsoft Wireless Intellimouse 2.0 reports it's wheel @@ -402,6 +404,7 @@ sc->sc_loc_x.pos = 8; sc->sc_loc_y.pos = 16; sc->sc_loc_z.pos = 24; + printf("sc->sc_loc_z.size=%u\n", sc->sc_loc_z.size); sc->sc_loc_btn[0].pos = 0; sc->sc_loc_btn[1].pos = 1; sc->sc_loc_btn[2].pos = 2; From magik at back-up.pl Mon Aug 11 14:19:39 2008 From: magik at back-up.pl (Grzegorz Blach) Date: Mon Aug 11 14:19:46 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 In-Reply-To: <20080811133434.GA4224@plan0> References: <200807242330.m6ONU70T091921@freefall.freebsd.org> <5d252c1d8f1ddaed55d2467adea536ca@chi.fastbighost.com> <20080811133434.GA4224@plan0> Message-ID: <0ed513c9800b730fff47034b86526e5d@chi.fastbighost.com> On Mon, 11 Aug 2008 15:34:34 +0200, Kai Wang wrote: > On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl wrote: >> >> >> On Thu, 24 Jul 2008 23:30:07 GMT, FreeBSD-gnats-submit@FreeBSD.org > wrote: >> > Thank you very much for your problem report. >> > It has the internal identification `usb/125941'. >> > The individual assigned to look at your >> > report is: freebsd-usb. >> > >> > You can access the state of your problem report at any time >> > via this link: >> > >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 >> > >> >>Category: usb >> >>Responsible: freebsd-usb >> >>Synopsis: not working wheel on my microsoft notebook optical > mouse >> > 3000 >> >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 >> >> I just fixed problem with wheel on my mouse >> and I'm sending in attachment patch for /usr/src/sys/dev/usb/ums.c file. > >> --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 >> +++ ums.c 2008-08-05 17:24:51.885277111 +0200 >> @@ -402,6 +402,7 @@ >> sc->sc_loc_x.pos = 8; >> sc->sc_loc_y.pos = 16; >> sc->sc_loc_z.pos = 24; >> + sc->sc_loc_z.size = 8; >> sc->sc_loc_btn[0].pos = 0; >> sc->sc_loc_btn[1].pos = 1; >> sc->sc_loc_btn[2].pos = 2; > > > Hi, > > Thanks for submitting the patch. It'd be great if you could also > test the patch below for us and paste the result here, just for > better understanding the problem. > > The patch adds some debug printfs: > > --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 +0200 > +++ ums.c 2008-08-11 15:25:44.000000000 +0200 > @@ -284,6 +284,7 @@ > wheel = hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, > HUG_WHEEL), > hid_input, &sc->sc_loc_z, &flags); > + printf("wheel=%d\n", wheel); > > if (wheel) { > if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { > @@ -323,6 +324,7 @@ > sc->flags |= UMS_Z; > } > } > + printf("sc->flags=0x%04x\n", sc->flags); > > /* > * The Microsoft Wireless Intellimouse 2.0 reports it's wheel > @@ -402,6 +404,7 @@ > sc->sc_loc_x.pos = 8; > sc->sc_loc_y.pos = 16; > sc->sc_loc_z.pos = 24; > + printf("sc->sc_loc_z.size=%u\n", sc->sc_loc_z.size); > sc->sc_loc_btn[0].pos = 0; > sc->sc_loc_btn[1].pos = 1; > sc->sc_loc_btn[2].pos = 2; this, what I see: ums0: on uhub0 wheel=0 sc->flags=0x0000 ums0: 3 buttons and a TILT dir. sc->sc_loc_z.size=0 From kaiwang27 at gmail.com Mon Aug 11 14:20:05 2008 From: kaiwang27 at gmail.com (Kai Wang) Date: Mon Aug 11 14:20:16 2008 Subject: kern/123224: [ums] Scroll wheel breakage w/ USB MS Wireless Intellimouse Explorer Message-ID: <200808111420.m7BEK5Ze070213@freefall.freebsd.org> The following reply was made to PR kern/123224; it has been noted by GNATS. From: Kai Wang To: bug-followup@FreeBSD.org, coxbrian@msu.edu Cc: Subject: Re: kern/123224: [ums] Scroll wheel breakage w/ USB MS Wireless Intellimouse Explorer Date: Mon, 11 Aug 2008 16:10:55 +0200 Hi Brian, I think the regression you metioned is indeed there. Could you please try the following patch against -CURRENT or -STABLE and see if it fixes the problem? --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 +0200 +++ ums.c.new 2008-08-11 15:00:37.000000000 +0200 @@ -283,6 +283,9 @@ /* Try the wheel first as the Z activator since it's tradition. */ wheel = hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_WHEEL), + hid_input, &sc->sc_loc_z, &flags) || + hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, + HUG_TWHEEL), hid_input, &sc->sc_loc_z, &flags); if (wheel) { From magik at back-up.pl Mon Aug 11 14:20:07 2008 From: magik at back-up.pl (Grzegorz Blach) Date: Mon Aug 11 14:20:17 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Message-ID: <200808111420.m7BEK7U8070263@freefall.freebsd.org> The following reply was made to PR usb/125941; it has been noted by GNATS. From: Grzegorz Blach To: Kai Wang Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: Re: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Date: Mon, 11 Aug 2008 10:19:35 -0400 On Mon, 11 Aug 2008 15:34:34 +0200, Kai Wang wrote: > On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl wrote: >> >> >> On Thu, 24 Jul 2008 23:30:07 GMT, FreeBSD-gnats-submit@FreeBSD.org > wrote: >> > Thank you very much for your problem report. >> > It has the internal identification `usb/125941'. >> > The individual assigned to look at your >> > report is: freebsd-usb. >> > >> > You can access the state of your problem report at any time >> > via this link: >> > >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 >> > >> >>Category: usb >> >>Responsible: freebsd-usb >> >>Synopsis: not working wheel on my microsoft notebook optical > mouse >> > 3000 >> >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 >> >> I just fixed problem with wheel on my mouse >> and I'm sending in attachment patch for /usr/src/sys/dev/usb/ums.c file. > >> --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 >> +++ ums.c 2008-08-05 17:24:51.885277111 +0200 >> @@ -402,6 +402,7 @@ >> sc->sc_loc_x.pos = 8; >> sc->sc_loc_y.pos = 16; >> sc->sc_loc_z.pos = 24; >> + sc->sc_loc_z.size = 8; >> sc->sc_loc_btn[0].pos = 0; >> sc->sc_loc_btn[1].pos = 1; >> sc->sc_loc_btn[2].pos = 2; > > > Hi, > > Thanks for submitting the patch. It'd be great if you could also > test the patch below for us and paste the result here, just for > better understanding the problem. > > The patch adds some debug printfs: > > --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 +0200 > +++ ums.c 2008-08-11 15:25:44.000000000 +0200 > @@ -284,6 +284,7 @@ > wheel = hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, > HUG_WHEEL), > hid_input, &sc->sc_loc_z, &flags); > + printf("wheel=%d\n", wheel); > > if (wheel) { > if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { > @@ -323,6 +324,7 @@ > sc->flags |= UMS_Z; > } > } > + printf("sc->flags=0x%04x\n", sc->flags); > > /* > * The Microsoft Wireless Intellimouse 2.0 reports it's wheel > @@ -402,6 +404,7 @@ > sc->sc_loc_x.pos = 8; > sc->sc_loc_y.pos = 16; > sc->sc_loc_z.pos = 24; > + printf("sc->sc_loc_z.size=%u\n", sc->sc_loc_z.size); > sc->sc_loc_btn[0].pos = 0; > sc->sc_loc_btn[1].pos = 1; > sc->sc_loc_btn[2].pos = 2; this, what I see: ums0: on uhub0 wheel=0 sc->flags=0x0000 ums0: 3 buttons and a TILT dir. sc->sc_loc_z.size=0 From kaiwang27 at gmail.com Mon Aug 11 14:50:04 2008 From: kaiwang27 at gmail.com (Kai Wang) Date: Mon Aug 11 14:50:10 2008 Subject: usb/123959: [ums] add support for Razer Lachesis 4000dpi usb mouse Message-ID: <200808111450.m7BEo3W6073059@freefall.freebsd.org> The following reply was made to PR usb/123959; it has been noted by GNATS. From: Kai Wang To: bug-followup@FreeBSD.org, ehaupt@FreeBSD.org Cc: Subject: Re: usb/123959: [ums] add support for Razer Lachesis 4000dpi usb mouse Date: Mon, 11 Aug 2008 16:43:11 +0200 Hello Emanuel, I believe this mouse is supported now, a patch which was committed by jhb@ should solve the UISUBCLASS problem several Razer mice have. It was solved in a different way, see this PR for details: http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/118670 If you have the mouse, could you please confirm that it is supported now so we can close the PR? Thanks, Kai From kaiwang27 at gmail.com Mon Aug 11 15:19:53 2008 From: kaiwang27 at gmail.com (Kai Wang) Date: Mon Aug 11 15:20:00 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 In-Reply-To: <0ed513c9800b730fff47034b86526e5d@chi.fastbighost.com> References: <200807242330.m6ONU70T091921@freefall.freebsd.org> <5d252c1d8f1ddaed55d2467adea536ca@chi.fastbighost.com> <20080811133434.GA4224@plan0> <0ed513c9800b730fff47034b86526e5d@chi.fastbighost.com> Message-ID: <20080811151941.GA4590@plan0> On Mon, Aug 11, 2008 at 10:19:35AM -0400, Grzegorz Blach wrote: > > > On Mon, 11 Aug 2008 15:34:34 +0200, Kai Wang wrote: > > On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl wrote: > >> > >> > >> On Thu, 24 Jul 2008 23:30:07 GMT, FreeBSD-gnats-submit@FreeBSD.org > > wrote: > >> > Thank you very much for your problem report. > >> > It has the internal identification `usb/125941'. > >> > The individual assigned to look at your > >> > report is: freebsd-usb. > >> > > >> > You can access the state of your problem report at any time > >> > via this link: > >> > > >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 > >> > > >> >>Category: usb > >> >>Responsible: freebsd-usb > >> >>Synopsis: not working wheel on my microsoft notebook optical > > mouse > >> > 3000 > >> >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 > >> > >> I just fixed problem with wheel on my mouse > >> and I'm sending in attachment patch for /usr/src/sys/dev/usb/ums.c file. > > > >> --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 > >> +++ ums.c 2008-08-05 17:24:51.885277111 +0200 > >> @@ -402,6 +402,7 @@ > >> sc->sc_loc_x.pos = 8; > >> sc->sc_loc_y.pos = 16; > >> sc->sc_loc_z.pos = 24; > >> + sc->sc_loc_z.size = 8; > >> sc->sc_loc_btn[0].pos = 0; > >> sc->sc_loc_btn[1].pos = 1; > >> sc->sc_loc_btn[2].pos = 2; > > > > > > Hi, > > > > Thanks for submitting the patch. It'd be great if you could also > > test the patch below for us and paste the result here, just for > > better understanding the problem. > > > > The patch adds some debug printfs: > > > > --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 +0200 > > +++ ums.c 2008-08-11 15:25:44.000000000 +0200 > > @@ -284,6 +284,7 @@ > > wheel = hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, > > HUG_WHEEL), > > hid_input, &sc->sc_loc_z, &flags); > > + printf("wheel=%d\n", wheel); > > > > if (wheel) { > > if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { > > @@ -323,6 +324,7 @@ > > sc->flags |= UMS_Z; > > } > > } > > + printf("sc->flags=0x%04x\n", sc->flags); > > > > /* > > * The Microsoft Wireless Intellimouse 2.0 reports it's wheel > > @@ -402,6 +404,7 @@ > > sc->sc_loc_x.pos = 8; > > sc->sc_loc_y.pos = 16; > > sc->sc_loc_z.pos = 24; > > + printf("sc->sc_loc_z.size=%u\n", sc->sc_loc_z.size); > > sc->sc_loc_btn[0].pos = 0; > > sc->sc_loc_btn[1].pos = 1; > > sc->sc_loc_btn[2].pos = 2; > > this, what I see: > > ums0: 0/0, rev 2.00/1.20, addr 2> on uhub0 > wheel=0 > sc->flags=0x0000 > ums0: 3 buttons and a TILT dir. > sc->sc_loc_z.size=0 > Interesting. Now I suspect that Optical Mouse 3000 model 1049 got different versions. Could you please get krepdump (http://people.freebsd.org/~kaiw/tools/krepdump.tgz) # tar xzvf krepdump.tgz # cd krepdump # make # kldload ./krepdump.ko Then plug in your mouse and paste the result here? There is one version of report desc of this mouse here: http://lists.freebsd.org/pipermail/freebsd-usb/2008-February/004617.html and my guess is your mouse's report desc is different than that... Thanks, Kai From kaiwang27 at gmail.com Mon Aug 11 15:20:03 2008 From: kaiwang27 at gmail.com (Kai Wang) Date: Mon Aug 11 15:20:10 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Message-ID: <200808111520.m7BFK3Ni075218@freefall.freebsd.org> The following reply was made to PR usb/125941; it has been noted by GNATS. From: Kai Wang To: Grzegorz Blach Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: Re: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Date: Mon, 11 Aug 2008 17:19:41 +0200 On Mon, Aug 11, 2008 at 10:19:35AM -0400, Grzegorz Blach wrote: > > > On Mon, 11 Aug 2008 15:34:34 +0200, Kai Wang wrote: > > On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl wrote: > >> > >> > >> On Thu, 24 Jul 2008 23:30:07 GMT, FreeBSD-gnats-submit@FreeBSD.org > > wrote: > >> > Thank you very much for your problem report. > >> > It has the internal identification `usb/125941'. > >> > The individual assigned to look at your > >> > report is: freebsd-usb. > >> > > >> > You can access the state of your problem report at any time > >> > via this link: > >> > > >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 > >> > > >> >>Category: usb > >> >>Responsible: freebsd-usb > >> >>Synopsis: not working wheel on my microsoft notebook optical > > mouse > >> > 3000 > >> >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 > >> > >> I just fixed problem with wheel on my mouse > >> and I'm sending in attachment patch for /usr/src/sys/dev/usb/ums.c file. > > > >> --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 > >> +++ ums.c 2008-08-05 17:24:51.885277111 +0200 > >> @@ -402,6 +402,7 @@ > >> sc->sc_loc_x.pos = 8; > >> sc->sc_loc_y.pos = 16; > >> sc->sc_loc_z.pos = 24; > >> + sc->sc_loc_z.size = 8; > >> sc->sc_loc_btn[0].pos = 0; > >> sc->sc_loc_btn[1].pos = 1; > >> sc->sc_loc_btn[2].pos = 2; > > > > > > Hi, > > > > Thanks for submitting the patch. It'd be great if you could also > > test the patch below for us and paste the result here, just for > > better understanding the problem. > > > > The patch adds some debug printfs: > > > > --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 +0200 > > +++ ums.c 2008-08-11 15:25:44.000000000 +0200 > > @@ -284,6 +284,7 @@ > > wheel = hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, > > HUG_WHEEL), > > hid_input, &sc->sc_loc_z, &flags); > > + printf("wheel=%d\n", wheel); > > > > if (wheel) { > > if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { > > @@ -323,6 +324,7 @@ > > sc->flags |= UMS_Z; > > } > > } > > + printf("sc->flags=0x%04x\n", sc->flags); > > > > /* > > * The Microsoft Wireless Intellimouse 2.0 reports it's wheel > > @@ -402,6 +404,7 @@ > > sc->sc_loc_x.pos = 8; > > sc->sc_loc_y.pos = 16; > > sc->sc_loc_z.pos = 24; > > + printf("sc->sc_loc_z.size=%u\n", sc->sc_loc_z.size); > > sc->sc_loc_btn[0].pos = 0; > > sc->sc_loc_btn[1].pos = 1; > > sc->sc_loc_btn[2].pos = 2; > > this, what I see: > > ums0: 0/0, rev 2.00/1.20, addr 2> on uhub0 > wheel=0 > sc->flags=0x0000 > ums0: 3 buttons and a TILT dir. > sc->sc_loc_z.size=0 > Interesting. Now I suspect that Optical Mouse 3000 model 1049 got different versions. Could you please get krepdump (http://people.freebsd.org/~kaiw/tools/krepdump.tgz) # tar xzvf krepdump.tgz # cd krepdump # make # kldload ./krepdump.ko Then plug in your mouse and paste the result here? There is one version of report desc of this mouse here: http://lists.freebsd.org/pipermail/freebsd-usb/2008-February/004617.html and my guess is your mouse's report desc is different than that... Thanks, Kai From kaiw at FreeBSD.org Mon Aug 11 16:12:06 2008 From: kaiw at FreeBSD.org (kaiw@FreeBSD.org) Date: Mon Aug 11 16:12:13 2008 Subject: usb/123959: [ums] add support for Razer Lachesis 4000dpi usb mouse Message-ID: <200808111612.m7BGC6c7078936@freefall.freebsd.org> Synopsis: [ums] add support for Razer Lachesis 4000dpi usb mouse State-Changed-From-To: open->closed State-Changed-By: kaiw State-Changed-When: Mon Aug 11 16:10:48 UTC 2008 State-Changed-Why: The submitter confirmed that the mouse is supported now. http://www.freebsd.org/cgi/query-pr.cgi?pr=123959 From ehaupt at freebsd.org Mon Aug 11 16:20:05 2008 From: ehaupt at freebsd.org (Emanuel Haupt) Date: Mon Aug 11 16:21:05 2008 Subject: usb/123959: [ums] add support for Razer Lachesis 4000dpi usb mouse Message-ID: <200808111620.m7BGK5bP080398@freefall.freebsd.org> The following reply was made to PR usb/123959; it has been noted by GNATS. From: Emanuel Haupt To: Kai Wang Cc: bug-followup@freebsd.org Subject: Re: usb/123959: [ums] add support for Razer Lachesis 4000dpi usb mouse Date: Mon, 11 Aug 2008 17:53:17 +0200 > Hello Emanuel, > > I believe this mouse is supported now, a patch which was committed by > jhb@ should solve the UISUBCLASS problem several Razer mice have. > > It was solved in a different way, see this PR for details: > http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/118670 > > If you have the mouse, could you please confirm that it is supported > now so we can close the PR? I can confirm that it's solved in RELENG_7. The PR can be closed, thanks. Emanuel From magik at back-up.pl Mon Aug 11 17:31:02 2008 From: magik at back-up.pl (Grzegorz Blach) Date: Mon Aug 11 17:31:08 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 In-Reply-To: <20080811151941.GA4590@plan0> References: <200807242330.m6ONU70T091921@freefall.freebsd.org> <5d252c1d8f1ddaed55d2467adea536ca@chi.fastbighost.com> <20080811133434.GA4224@plan0> <0ed513c9800b730fff47034b86526e5d@chi.fastbighost.com> <20080811151941.GA4590@plan0> Message-ID: <310aef2cb8e5bbcc7cf345f962cb102b@chi.fastbighost.com> On Mon, 11 Aug 2008 17:19:41 +0200, Kai Wang wrote: > On Mon, Aug 11, 2008 at 10:19:35AM -0400, Grzegorz Blach wrote: >> >> >> On Mon, 11 Aug 2008 15:34:34 +0200, Kai Wang > wrote: >> > On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl wrote: >> >> >> >> >> >> On Thu, 24 Jul 2008 23:30:07 GMT, FreeBSD-gnats-submit@FreeBSD.org >> > wrote: >> >> > Thank you very much for your problem report. >> >> > It has the internal identification `usb/125941'. >> >> > The individual assigned to look at your >> >> > report is: freebsd-usb. >> >> > >> >> > You can access the state of your problem report at any time >> >> > via this link: >> >> > >> >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 >> >> > >> >> >>Category: usb >> >> >>Responsible: freebsd-usb >> >> >>Synopsis: not working wheel on my microsoft notebook optical >> > mouse >> >> > 3000 >> >> >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 >> >> >> >> I just fixed problem with wheel on my mouse >> >> and I'm sending in attachment patch for /usr/src/sys/dev/usb/ums.c > file. >> > >> >> --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 >> >> +++ ums.c 2008-08-05 17:24:51.885277111 +0200 >> >> @@ -402,6 +402,7 @@ >> >> sc->sc_loc_x.pos = 8; >> >> sc->sc_loc_y.pos = 16; >> >> sc->sc_loc_z.pos = 24; >> >> + sc->sc_loc_z.size = 8; >> >> sc->sc_loc_btn[0].pos = 0; >> >> sc->sc_loc_btn[1].pos = 1; >> >> sc->sc_loc_btn[2].pos = 2; >> > >> > >> > Hi, >> > >> > Thanks for submitting the patch. It'd be great if you could also >> > test the patch below for us and paste the result here, just for >> > better understanding the problem. >> > >> > The patch adds some debug printfs: >> > >> > --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 +0200 >> > +++ ums.c 2008-08-11 15:25:44.000000000 +0200 >> > @@ -284,6 +284,7 @@ >> > wheel = hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, >> > HUG_WHEEL), >> > hid_input, &sc->sc_loc_z, &flags); >> > + printf("wheel=%d\n", wheel); >> > >> > if (wheel) { >> > if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { >> > @@ -323,6 +324,7 @@ >> > sc->flags |= UMS_Z; >> > } >> > } >> > + printf("sc->flags=0x%04x\n", sc->flags); >> > >> > /* >> > * The Microsoft Wireless Intellimouse 2.0 reports it's wheel >> > @@ -402,6 +404,7 @@ >> > sc->sc_loc_x.pos = 8; >> > sc->sc_loc_y.pos = 16; >> > sc->sc_loc_z.pos = 24; >> > + printf("sc->sc_loc_z.size=%u\n", sc->sc_loc_z.size); >> > sc->sc_loc_btn[0].pos = 0; >> > sc->sc_loc_btn[1].pos = 1; >> > sc->sc_loc_btn[2].pos = 2; >> >> this, what I see: >> >> ums0: > 0/0, rev 2.00/1.20, addr 2> on uhub0 >> wheel=0 >> sc->flags=0x0000 >> ums0: 3 buttons and a TILT dir. >> sc->sc_loc_z.size=0 >> > > Interesting. Now I suspect that Optical Mouse 3000 model 1049 got > different > versions. > > Could you please get krepdump > (http://people.freebsd.org/~kaiw/tools/krepdump.tgz) > > # tar xzvf krepdump.tgz > # cd krepdump > # make > # kldload ./krepdump.ko > > Then plug in your mouse and paste the result here? > > There is one version of report desc of this mouse here: > http://lists.freebsd.org/pipermail/freebsd-usb/2008-February/004617.html > > and my guess is your mouse's report desc is different than that... > > > Thanks, > Kai ---- my krepdump ---- ums0: at uhub0 port 2 (addr 2) disconnected ums0: detached [report desc size=196] USAGE PAGE Consumer(0xc) USAGE Consumer Control(0x1)[Consumer(0xc)] COLLECTION Application(1) USAGE PAGE Generic Desktop(0x1) USAGE Mouse(0x2)[Generic Desktop(0x1)] COLLECTION Logical(2) REPORT ID 19 USAGE PAGE Consumer(0xc) USAGE AC Pan(0x238)[Consumer(0xc)] REPORT COUNT 1 REPORT SIZE 8 LOGICAL MINIMUM -127 LOGICAL MAXIMUM 127 INPUT ( Data Variable Relative ) (6) REPORT ID 23 USAGE PAGE Microsoft(0xff00) USAGE Unknown Usage(0xff06)[Microsoft(0xff00)] LOGICAL MINIMUM 0 LOGICAL MAXIMUM 1 PHYSICAL MINIMUM 1 PHYSICAL MAXIMUM 4 REPORT COUNT 1 REPORT SIZE 2 FEATURE ( Data Variable Absolute ) (2) PHYSICAL MINIMUM 0 PHYSICAL MAXIMUM 0 FEATURE ( Const Array Absolute ) (1) USAGE Unknown Usage(0xff04)[Microsoft(0xff00)] REPORT SIZE 1 FEATURE ( Data Variable Absolute ) (2) REPORT SIZE 3 FEATURE ( Const Array Absolute ) (1) REPORT ID 24 USAGE Unknown Usage(0xff08)[Microsoft(0xff00)] REPORT SIZE 1 FEATURE ( Data Variable Absolute ) (2) REPORT SIZE 7 FEATURE ( Const Array Absolute ) (1) END COLLECTION END COLLECTION USAGE PAGE Generic Desktop(0x1) USAGE Mouse(0x2)[Generic Desktop(0x1)] COLLECTION Application(1) USAGE PAGE Generic Desktop(0x1) USAGE Mouse(0x2)[Generic Desktop(0x1)] COLLECTION Logical(2) REPORT ID 17 USAGE Pointer(0x1)[Generic Desktop(0x1)] COLLECTION Physical(0) USAGE PAGE Button(0x9) USAGE MINIMUM Button1(1) USAGE MAXIMUM Button3(3) REPORT COUNT 3 REPORT SIZE 1 LOGICAL MAXIMUM 1 INPUT ( Data Variable Absolute ) (2) REPORT COUNT 1 INPUT ( Const Array Absolute ) (1) USAGE Button5(0x5)[Button(0x9)] INPUT ( Data Variable Absolute ) (2) REPORT COUNT 3 INPUT ( Const Array Absolute ) (1) USAGE PAGE Generic Desktop(0x1) USAGE X(0x30)[Generic Desktop(0x1)] USAGE Y(0x31)[Generic Desktop(0x1)] REPORT COUNT 2 REPORT SIZE 8 LOGICAL MINIMUM -127 LOGICAL MAXIMUM 127 INPUT ( Data Variable Relative ) (6) COLLECTION Logical(2) REPORT ID 18 USAGE Resolution Multiplier(0x48)[Generic Desktop(0x1)] REPORT COUNT 1 REPORT SIZE 2 LOGICAL MINIMUM 0 LOGICAL MAXIMUM 1 PHYSICAL MINIMUM 1 PHYSICAL MAXIMUM 4 FEATURE ( Data Variable Absolute ) (2) PHYSICAL MINIMUM 0 PHYSICAL MAXIMUM 0 REPORT SIZE 6 FEATURE ( Const Array Absolute ) (1) REPORT ID 17 USAGE Wheel(0x38)[Generic Desktop(0x1)] LOGICAL MINIMUM -127 LOGICAL MAXIMUM 127 REPORT SIZE 8 INPUT ( Data Variable Relative ) (6) END COLLECTION USAGE PAGE Consumer(0xc) REPORT SIZE 8 USAGE AC Pan(0x238)[Consumer(0xc)] INPUT ( Data Variable Relative ) (6) END COLLECTION END COLLECTION END COLLECTION [hexdump] 0000 05 0C 09 01 A1 01 05 01 09 02 A1 02 85 13 05 0C 0010 0A 38 02 95 01 75 08 15 81 25 7F 81 06 85 17 06 0020 00 FF 0A 06 FF 15 00 25 01 35 01 45 04 95 01 75 0030 02 B1 02 35 00 45 00 B1 01 0A 04 FF 75 01 B1 02 0040 75 03 B1 01 85 18 0A 08 FF 75 01 B1 02 75 07 B1 0050 01 C0 C0 05 01 09 02 A1 01 05 01 09 02 A1 02 85 0060 11 09 01 A1 00 05 09 19 01 29 03 95 03 75 01 25 0070 01 81 02 95 01 81 01 09 05 81 02 95 03 81 01 05 0080 01 09 30 09 31 95 02 75 08 15 81 25 7F 81 06 A1 0090 02 85 12 09 48 95 01 75 02 15 00 25 01 35 01 45 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 00C0 06 C0 C0 C0 ums0: on uhub0 wheel=0 sc->flags=0x0000 ums0: 3 buttons and a TILT dir. sc->sc_loc_z.size=0 ---- end of krepdump ---- ---- diff between my report and this from lists.freebsd.org/.../004617.html ---- --- 1.txt 2008-08-11 19:25:56.496820730 +0200 +++ dump.txt 2008-08-11 19:25:59.156847633 +0200 @@ -1,7 +1,7 @@ -ums1: at uhub0 port 4 (addr 4) disconnected -ums1: detached - -[report desc size=3D196] +ums0: at uhub0 port 2 (addr 2) disconnected +ums0: detached + +[report desc size=196] USAGE PAGE Consumer(0xc) USAGE Consumer Control(0x1)[Consumer(0xc)] COLLECTION Application(1) @@ -114,6 +114,9 @@ 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 00C0 06 C0 C0 C0 -ums1: on uhub0 -ums1: 3 buttons and Z dir and a TILT dir. +ums0: on uhub0 +wheel=0 +sc->flags=0x0000 +ums0: 3 buttons and a TILT dir. +sc->sc_loc_z.size=0 ---- end of diff ---- and short info: When I use RELENG_7_0, driver reports that my mouse have Z dir, but on RELENG_7 not. From magik at back-up.pl Mon Aug 11 17:40:04 2008 From: magik at back-up.pl (Grzegorz Blach) Date: Mon Aug 11 17:40:10 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Message-ID: <200808111740.m7BHe3JJ087915@freefall.freebsd.org> The following reply was made to PR usb/125941; it has been noted by GNATS. From: Grzegorz Blach To: Kai Wang Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: Re: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Date: Mon, 11 Aug 2008 13:30:57 -0400 On Mon, 11 Aug 2008 17:19:41 +0200, Kai Wang wrote: > On Mon, Aug 11, 2008 at 10:19:35AM -0400, Grzegorz Blach wrote: >> >> >> On Mon, 11 Aug 2008 15:34:34 +0200, Kai Wang > wrote: >> > On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl wrote: >> >> >> >> >> >> On Thu, 24 Jul 2008 23:30:07 GMT, FreeBSD-gnats-submit@FreeBSD.org >> > wrote: >> >> > Thank you very much for your problem report. >> >> > It has the internal identification `usb/125941'. >> >> > The individual assigned to look at your >> >> > report is: freebsd-usb. >> >> > >> >> > You can access the state of your problem report at any time >> >> > via this link: >> >> > >> >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 >> >> > >> >> >>Category: usb >> >> >>Responsible: freebsd-usb >> >> >>Synopsis: not working wheel on my microsoft notebook optical >> > mouse >> >> > 3000 >> >> >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 >> >> >> >> I just fixed problem with wheel on my mouse >> >> and I'm sending in attachment patch for /usr/src/sys/dev/usb/ums.c > file. >> > >> >> --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 >> >> +++ ums.c 2008-08-05 17:24:51.885277111 +0200 >> >> @@ -402,6 +402,7 @@ >> >> sc->sc_loc_x.pos = 8; >> >> sc->sc_loc_y.pos = 16; >> >> sc->sc_loc_z.pos = 24; >> >> + sc->sc_loc_z.size = 8; >> >> sc->sc_loc_btn[0].pos = 0; >> >> sc->sc_loc_btn[1].pos = 1; >> >> sc->sc_loc_btn[2].pos = 2; >> > >> > >> > Hi, >> > >> > Thanks for submitting the patch. It'd be great if you could also >> > test the patch below for us and paste the result here, just for >> > better understanding the problem. >> > >> > The patch adds some debug printfs: >> > >> > --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 +0200 >> > +++ ums.c 2008-08-11 15:25:44.000000000 +0200 >> > @@ -284,6 +284,7 @@ >> > wheel = hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, >> > HUG_WHEEL), >> > hid_input, &sc->sc_loc_z, &flags); >> > + printf("wheel=%d\n", wheel); >> > >> > if (wheel) { >> > if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { >> > @@ -323,6 +324,7 @@ >> > sc->flags |= UMS_Z; >> > } >> > } >> > + printf("sc->flags=0x%04x\n", sc->flags); >> > >> > /* >> > * The Microsoft Wireless Intellimouse 2.0 reports it's wheel >> > @@ -402,6 +404,7 @@ >> > sc->sc_loc_x.pos = 8; >> > sc->sc_loc_y.pos = 16; >> > sc->sc_loc_z.pos = 24; >> > + printf("sc->sc_loc_z.size=%u\n", sc->sc_loc_z.size); >> > sc->sc_loc_btn[0].pos = 0; >> > sc->sc_loc_btn[1].pos = 1; >> > sc->sc_loc_btn[2].pos = 2; >> >> this, what I see: >> >> ums0: > 0/0, rev 2.00/1.20, addr 2> on uhub0 >> wheel=0 >> sc->flags=0x0000 >> ums0: 3 buttons and a TILT dir. >> sc->sc_loc_z.size=0 >> > > Interesting. Now I suspect that Optical Mouse 3000 model 1049 got > different > versions. > > Could you please get krepdump > (http://people.freebsd.org/~kaiw/tools/krepdump.tgz) > > # tar xzvf krepdump.tgz > # cd krepdump > # make > # kldload ./krepdump.ko > > Then plug in your mouse and paste the result here? > > There is one version of report desc of this mouse here: > http://lists.freebsd.org/pipermail/freebsd-usb/2008-February/004617.html > > and my guess is your mouse's report desc is different than that... > > > Thanks, > Kai ---- my krepdump ---- ums0: at uhub0 port 2 (addr 2) disconnected ums0: detached [report desc size=196] USAGE PAGE Consumer(0xc) USAGE Consumer Control(0x1)[Consumer(0xc)] COLLECTION Application(1) USAGE PAGE Generic Desktop(0x1) USAGE Mouse(0x2)[Generic Desktop(0x1)] COLLECTION Logical(2) REPORT ID 19 USAGE PAGE Consumer(0xc) USAGE AC Pan(0x238)[Consumer(0xc)] REPORT COUNT 1 REPORT SIZE 8 LOGICAL MINIMUM -127 LOGICAL MAXIMUM 127 INPUT ( Data Variable Relative ) (6) REPORT ID 23 USAGE PAGE Microsoft(0xff00) USAGE Unknown Usage(0xff06)[Microsoft(0xff00)] LOGICAL MINIMUM 0 LOGICAL MAXIMUM 1 PHYSICAL MINIMUM 1 PHYSICAL MAXIMUM 4 REPORT COUNT 1 REPORT SIZE 2 FEATURE ( Data Variable Absolute ) (2) PHYSICAL MINIMUM 0 PHYSICAL MAXIMUM 0 FEATURE ( Const Array Absolute ) (1) USAGE Unknown Usage(0xff04)[Microsoft(0xff00)] REPORT SIZE 1 FEATURE ( Data Variable Absolute ) (2) REPORT SIZE 3 FEATURE ( Const Array Absolute ) (1) REPORT ID 24 USAGE Unknown Usage(0xff08)[Microsoft(0xff00)] REPORT SIZE 1 FEATURE ( Data Variable Absolute ) (2) REPORT SIZE 7 FEATURE ( Const Array Absolute ) (1) END COLLECTION END COLLECTION USAGE PAGE Generic Desktop(0x1) USAGE Mouse(0x2)[Generic Desktop(0x1)] COLLECTION Application(1) USAGE PAGE Generic Desktop(0x1) USAGE Mouse(0x2)[Generic Desktop(0x1)] COLLECTION Logical(2) REPORT ID 17 USAGE Pointer(0x1)[Generic Desktop(0x1)] COLLECTION Physical(0) USAGE PAGE Button(0x9) USAGE MINIMUM Button1(1) USAGE MAXIMUM Button3(3) REPORT COUNT 3 REPORT SIZE 1 LOGICAL MAXIMUM 1 INPUT ( Data Variable Absolute ) (2) REPORT COUNT 1 INPUT ( Const Array Absolute ) (1) USAGE Button5(0x5)[Button(0x9)] INPUT ( Data Variable Absolute ) (2) REPORT COUNT 3 INPUT ( Const Array Absolute ) (1) USAGE PAGE Generic Desktop(0x1) USAGE X(0x30)[Generic Desktop(0x1)] USAGE Y(0x31)[Generic Desktop(0x1)] REPORT COUNT 2 REPORT SIZE 8 LOGICAL MINIMUM -127 LOGICAL MAXIMUM 127 INPUT ( Data Variable Relative ) (6) COLLECTION Logical(2) REPORT ID 18 USAGE Resolution Multiplier(0x48)[Generic Desktop(0x1)] REPORT COUNT 1 REPORT SIZE 2 LOGICAL MINIMUM 0 LOGICAL MAXIMUM 1 PHYSICAL MINIMUM 1 PHYSICAL MAXIMUM 4 FEATURE ( Data Variable Absolute ) (2) PHYSICAL MINIMUM 0 PHYSICAL MAXIMUM 0 REPORT SIZE 6 FEATURE ( Const Array Absolute ) (1) REPORT ID 17 USAGE Wheel(0x38)[Generic Desktop(0x1)] LOGICAL MINIMUM -127 LOGICAL MAXIMUM 127 REPORT SIZE 8 INPUT ( Data Variable Relative ) (6) END COLLECTION USAGE PAGE Consumer(0xc) REPORT SIZE 8 USAGE AC Pan(0x238)[Consumer(0xc)] INPUT ( Data Variable Relative ) (6) END COLLECTION END COLLECTION END COLLECTION [hexdump] 0000 05 0C 09 01 A1 01 05 01 09 02 A1 02 85 13 05 0C 0010 0A 38 02 95 01 75 08 15 81 25 7F 81 06 85 17 06 0020 00 FF 0A 06 FF 15 00 25 01 35 01 45 04 95 01 75 0030 02 B1 02 35 00 45 00 B1 01 0A 04 FF 75 01 B1 02 0040 75 03 B1 01 85 18 0A 08 FF 75 01 B1 02 75 07 B1 0050 01 C0 C0 05 01 09 02 A1 01 05 01 09 02 A1 02 85 0060 11 09 01 A1 00 05 09 19 01 29 03 95 03 75 01 25 0070 01 81 02 95 01 81 01 09 05 81 02 95 03 81 01 05 0080 01 09 30 09 31 95 02 75 08 15 81 25 7F 81 06 A1 0090 02 85 12 09 48 95 01 75 02 15 00 25 01 35 01 45 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 00C0 06 C0 C0 C0 ums0: on uhub0 wheel=0 sc->flags=0x0000 ums0: 3 buttons and a TILT dir. sc->sc_loc_z.size=0 ---- end of krepdump ---- ---- diff between my report and this from lists.freebsd.org/.../004617.html ---- --- 1.txt 2008-08-11 19:25:56.496820730 +0200 +++ dump.txt 2008-08-11 19:25:59.156847633 +0200 @@ -1,7 +1,7 @@ -ums1: at uhub0 port 4 (addr 4) disconnected -ums1: detached - -[report desc size=3D196] +ums0: at uhub0 port 2 (addr 2) disconnected +ums0: detached + +[report desc size=196] USAGE PAGE Consumer(0xc) USAGE Consumer Control(0x1)[Consumer(0xc)] COLLECTION Application(1) @@ -114,6 +114,9 @@ 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 00C0 06 C0 C0 C0 -ums1: on uhub0 -ums1: 3 buttons and Z dir and a TILT dir. +ums0: on uhub0 +wheel=0 +sc->flags=0x0000 +ums0: 3 buttons and a TILT dir. +sc->sc_loc_z.size=0 ---- end of diff ---- and short info: When I use RELENG_7_0, driver reports that my mouse have Z dir, but on RELENG_7 not. From kaiwang27 at gmail.com Tue Aug 12 02:27:19 2008 From: kaiwang27 at gmail.com (Kai Wang) Date: Tue Aug 12 02:27:31 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 In-Reply-To: <310aef2cb8e5bbcc7cf345f962cb102b@chi.fastbighost.com> References: <200807242330.m6ONU70T091921@freefall.freebsd.org> <5d252c1d8f1ddaed55d2467adea536ca@chi.fastbighost.com> <20080811133434.GA4224@plan0> <0ed513c9800b730fff47034b86526e5d@chi.fastbighost.com> <20080811151941.GA4590@plan0> <310aef2cb8e5bbcc7cf345f962cb102b@chi.fastbighost.com> Message-ID: <20080812022710.GA7527@plan0> On Mon, Aug 11, 2008 at 01:30:57PM -0400, Grzegorz Blach wrote: > On Mon, 11 Aug 2008 17:19:41 +0200, Kai Wang wrote: > > On Mon, Aug 11, 2008 at 10:19:35AM -0400, Grzegorz Blach wrote: > >> > >> > >> On Mon, 11 Aug 2008 15:34:34 +0200, Kai Wang > > wrote: > >> > On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl wrote: > >> >> > >> >> > >> >> On Thu, 24 Jul 2008 23:30:07 GMT, FreeBSD-gnats-submit@FreeBSD.org > >> > wrote: > >> >> > Thank you very much for your problem report. > >> >> > It has the internal identification `usb/125941'. > >> >> > The individual assigned to look at your > >> >> > report is: freebsd-usb. > >> >> > > >> >> > You can access the state of your problem report at any time > >> >> > via this link: > >> >> > > >> >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 > >> >> > > >> >> >>Category: usb > >> >> >>Responsible: freebsd-usb > >> >> >>Synopsis: not working wheel on my microsoft notebook optical > >> > mouse > >> >> > 3000 > >> >> >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 > >> >> > >> >> I just fixed problem with wheel on my mouse > >> >> and I'm sending in attachment patch for /usr/src/sys/dev/usb/ums.c > > file. > >> > > >> >> --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 > >> >> +++ ums.c 2008-08-05 17:24:51.885277111 +0200 > >> >> @@ -402,6 +402,7 @@ > >> >> sc->sc_loc_x.pos = 8; > >> >> sc->sc_loc_y.pos = 16; > >> >> sc->sc_loc_z.pos = 24; > >> >> + sc->sc_loc_z.size = 8; > >> >> sc->sc_loc_btn[0].pos = 0; > >> >> sc->sc_loc_btn[1].pos = 1; > >> >> sc->sc_loc_btn[2].pos = 2; > >> > > >> > > >> > Hi, > >> > > >> > Thanks for submitting the patch. It'd be great if you could also > >> > test the patch below for us and paste the result here, just for > >> > better understanding the problem. > >> > > >> > The patch adds some debug printfs: > >> > > >> > --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 +0200 > >> > +++ ums.c 2008-08-11 15:25:44.000000000 +0200 > >> > @@ -284,6 +284,7 @@ > >> > wheel = hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, > >> > HUG_WHEEL), > >> > hid_input, &sc->sc_loc_z, &flags); > >> > + printf("wheel=%d\n", wheel); > >> > > >> > if (wheel) { > >> > if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { > >> > @@ -323,6 +324,7 @@ > >> > sc->flags |= UMS_Z; > >> > } > >> > } > >> > + printf("sc->flags=0x%04x\n", sc->flags); > >> > > >> > /* > >> > * The Microsoft Wireless Intellimouse 2.0 reports it's wheel > >> > @@ -402,6 +404,7 @@ > >> > sc->sc_loc_x.pos = 8; > >> > sc->sc_loc_y.pos = 16; > >> > sc->sc_loc_z.pos = 24; > >> > + printf("sc->sc_loc_z.size=%u\n", sc->sc_loc_z.size); > >> > sc->sc_loc_btn[0].pos = 0; > >> > sc->sc_loc_btn[1].pos = 1; > >> > sc->sc_loc_btn[2].pos = 2; > >> > >> this, what I see: > >> > >> ums0: >> 0/0, rev 2.00/1.20, addr 2> on uhub0 > >> wheel=0 > >> sc->flags=0x0000 > >> ums0: 3 buttons and a TILT dir. > >> sc->sc_loc_z.size=0 > >> > > > > Interesting. Now I suspect that Optical Mouse 3000 model 1049 got > > different > > versions. > > > > Could you please get krepdump > > (http://people.freebsd.org/~kaiw/tools/krepdump.tgz) > > > > # tar xzvf krepdump.tgz > > # cd krepdump > > # make > > # kldload ./krepdump.ko > > > > Then plug in your mouse and paste the result here? > > > > There is one version of report desc of this mouse here: > > http://lists.freebsd.org/pipermail/freebsd-usb/2008-February/004617.html > > > > and my guess is your mouse's report desc is different than that... > > > > > > Thanks, > > Kai > > ---- my krepdump ---- > ums0: at uhub0 port 2 (addr 2) disconnected > ums0: detached > > [report desc size=196] > USAGE PAGE Consumer(0xc) > USAGE Consumer Control(0x1)[Consumer(0xc)] > COLLECTION Application(1) > USAGE PAGE Generic Desktop(0x1) > USAGE Mouse(0x2)[Generic Desktop(0x1)] > COLLECTION Logical(2) > REPORT ID 19 > USAGE PAGE Consumer(0xc) > USAGE AC Pan(0x238)[Consumer(0xc)] > REPORT COUNT 1 > REPORT SIZE 8 > LOGICAL MINIMUM -127 > LOGICAL MAXIMUM 127 > INPUT ( Data Variable Relative ) (6) > REPORT ID 23 > USAGE PAGE Microsoft(0xff00) > USAGE Unknown Usage(0xff06)[Microsoft(0xff00)] > LOGICAL MINIMUM 0 > LOGICAL MAXIMUM 1 > PHYSICAL MINIMUM 1 > PHYSICAL MAXIMUM 4 > REPORT COUNT 1 > REPORT SIZE 2 > FEATURE ( Data Variable Absolute ) (2) > PHYSICAL MINIMUM 0 > PHYSICAL MAXIMUM 0 > FEATURE ( Const Array Absolute ) (1) > USAGE Unknown Usage(0xff04)[Microsoft(0xff00)] > REPORT SIZE 1 > FEATURE ( Data Variable Absolute ) (2) > REPORT SIZE 3 > FEATURE ( Const Array Absolute ) (1) > REPORT ID 24 > USAGE Unknown Usage(0xff08)[Microsoft(0xff00)] > REPORT SIZE 1 > FEATURE ( Data Variable Absolute ) (2) > REPORT SIZE 7 > FEATURE ( Const Array Absolute ) (1) > END COLLECTION > END COLLECTION > USAGE PAGE Generic Desktop(0x1) > USAGE Mouse(0x2)[Generic Desktop(0x1)] > COLLECTION Application(1) > USAGE PAGE Generic Desktop(0x1) > USAGE Mouse(0x2)[Generic Desktop(0x1)] > COLLECTION Logical(2) > REPORT ID 17 > USAGE Pointer(0x1)[Generic Desktop(0x1)] > COLLECTION Physical(0) > USAGE PAGE Button(0x9) > USAGE MINIMUM Button1(1) > USAGE MAXIMUM Button3(3) > REPORT COUNT 3 > REPORT SIZE 1 > LOGICAL MAXIMUM 1 > INPUT ( Data Variable Absolute ) (2) > REPORT COUNT 1 > INPUT ( Const Array Absolute ) (1) > USAGE Button5(0x5)[Button(0x9)] > INPUT ( Data Variable Absolute ) (2) > REPORT COUNT 3 > INPUT ( Const Array Absolute ) (1) > USAGE PAGE Generic Desktop(0x1) > USAGE X(0x30)[Generic Desktop(0x1)] > USAGE Y(0x31)[Generic Desktop(0x1)] > REPORT COUNT 2 > REPORT SIZE 8 > LOGICAL MINIMUM -127 > LOGICAL MAXIMUM 127 > INPUT ( Data Variable Relative ) (6) > COLLECTION Logical(2) > REPORT ID 18 > USAGE Resolution Multiplier(0x48)[Generic Desktop(0x1)] > REPORT COUNT 1 > REPORT SIZE 2 > LOGICAL MINIMUM 0 > LOGICAL MAXIMUM 1 > PHYSICAL MINIMUM 1 > PHYSICAL MAXIMUM 4 > FEATURE ( Data Variable Absolute ) (2) > PHYSICAL MINIMUM 0 > PHYSICAL MAXIMUM 0 > REPORT SIZE 6 > FEATURE ( Const Array Absolute ) (1) > REPORT ID 17 > USAGE Wheel(0x38)[Generic Desktop(0x1)] > LOGICAL MINIMUM -127 > LOGICAL MAXIMUM 127 > REPORT SIZE 8 > INPUT ( Data Variable Relative ) (6) > END COLLECTION > USAGE PAGE Consumer(0xc) > REPORT SIZE 8 > USAGE AC Pan(0x238)[Consumer(0xc)] > INPUT ( Data Variable Relative ) (6) > END COLLECTION > END COLLECTION > END COLLECTION > [hexdump] > 0000 05 0C 09 01 A1 01 05 01 09 02 A1 02 85 13 05 0C > 0010 0A 38 02 95 01 75 08 15 81 25 7F 81 06 85 17 06 > 0020 00 FF 0A 06 FF 15 00 25 01 35 01 45 04 95 01 75 > 0030 02 B1 02 35 00 45 00 B1 01 0A 04 FF 75 01 B1 02 > 0040 75 03 B1 01 85 18 0A 08 FF 75 01 B1 02 75 07 B1 > 0050 01 C0 C0 05 01 09 02 A1 01 05 01 09 02 A1 02 85 > 0060 11 09 01 A1 00 05 09 19 01 29 03 95 03 75 01 25 > 0070 01 81 02 95 01 81 01 09 05 81 02 95 03 81 01 05 > 0080 01 09 30 09 31 95 02 75 08 15 81 25 7F 81 06 A1 > 0090 02 85 12 09 48 95 01 75 02 15 00 25 01 35 01 45 > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > 00C0 06 C0 C0 C0 > ums0: 0/0, rev 2.00/1.20, addr 2> on uhub0 > wheel=0 > sc->flags=0x0000 > ums0: 3 buttons and a TILT dir. > sc->sc_loc_z.size=0 > ---- end of krepdump ---- > > > ---- diff between my report and this from lists.freebsd.org/.../004617.html > ---- > --- 1.txt 2008-08-11 19:25:56.496820730 +0200 > +++ dump.txt 2008-08-11 19:25:59.156847633 +0200 > @@ -1,7 +1,7 @@ > -ums1: at uhub0 port 4 (addr 4) disconnected > -ums1: detached > - > -[report desc size=3D196] > +ums0: at uhub0 port 2 (addr 2) disconnected > +ums0: detached > + > +[report desc size=196] > USAGE PAGE Consumer(0xc) > USAGE Consumer Control(0x1)[Consumer(0xc)] > COLLECTION Application(1) > @@ -114,6 +114,9 @@ > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > 00C0 06 C0 C0 C0 > -ums1: 0/0, rev 2.00/1.20, addr 4> on uhub0 > -ums1: 3 buttons and Z dir and a TILT dir. > +ums0: 0/0, rev 2.00/1.20, addr 2> on uhub0 > +wheel=0 > +sc->flags=0x0000 > +ums0: 3 buttons and a TILT dir. > +sc->sc_loc_z.size=0 > ---- end of diff ---- > > and short info: > > When I use RELENG_7_0, driver reports that my mouse have Z dir, but on > RELENG_7 not. The report descriptor is the same. After some experiments, I think the actual problem is inside our hid parser. Could you please try the patch attached against /sys/dev/usb/hid.c along with the debug printf patch for ums.c, and see what the result will be? From kaiwang27 at gmail.com Tue Aug 12 02:30:11 2008 From: kaiwang27 at gmail.com (Kai Wang) Date: Tue Aug 12 02:30:18 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Message-ID: <200808120230.m7C2UBu7034665@freefall.freebsd.org> The following reply was made to PR usb/125941; it has been noted by GNATS. From: Kai Wang To: Grzegorz Blach Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: Re: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Date: Tue, 12 Aug 2008 04:27:10 +0200 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Mon, Aug 11, 2008 at 01:30:57PM -0400, Grzegorz Blach wrote: > On Mon, 11 Aug 2008 17:19:41 +0200, Kai Wang wrote: > > On Mon, Aug 11, 2008 at 10:19:35AM -0400, Grzegorz Blach wrote: > >> > >> > >> On Mon, 11 Aug 2008 15:34:34 +0200, Kai Wang > > wrote: > >> > On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl wrote: > >> >> > >> >> > >> >> On Thu, 24 Jul 2008 23:30:07 GMT, FreeBSD-gnats-submit@FreeBSD.org > >> > wrote: > >> >> > Thank you very much for your problem report. > >> >> > It has the internal identification `usb/125941'. > >> >> > The individual assigned to look at your > >> >> > report is: freebsd-usb. > >> >> > > >> >> > You can access the state of your problem report at any time > >> >> > via this link: > >> >> > > >> >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 > >> >> > > >> >> >>Category: usb > >> >> >>Responsible: freebsd-usb > >> >> >>Synopsis: not working wheel on my microsoft notebook optical > >> > mouse > >> >> > 3000 > >> >> >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 > >> >> > >> >> I just fixed problem with wheel on my mouse > >> >> and I'm sending in attachment patch for /usr/src/sys/dev/usb/ums.c > > file. > >> > > >> >> --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 > >> >> +++ ums.c 2008-08-05 17:24:51.885277111 +0200 > >> >> @@ -402,6 +402,7 @@ > >> >> sc->sc_loc_x.pos = 8; > >> >> sc->sc_loc_y.pos = 16; > >> >> sc->sc_loc_z.pos = 24; > >> >> + sc->sc_loc_z.size = 8; > >> >> sc->sc_loc_btn[0].pos = 0; > >> >> sc->sc_loc_btn[1].pos = 1; > >> >> sc->sc_loc_btn[2].pos = 2; > >> > > >> > > >> > Hi, > >> > > >> > Thanks for submitting the patch. It'd be great if you could also > >> > test the patch below for us and paste the result here, just for > >> > better understanding the problem. > >> > > >> > The patch adds some debug printfs: > >> > > >> > --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 +0200 > >> > +++ ums.c 2008-08-11 15:25:44.000000000 +0200 > >> > @@ -284,6 +284,7 @@ > >> > wheel = hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, > >> > HUG_WHEEL), > >> > hid_input, &sc->sc_loc_z, &flags); > >> > + printf("wheel=%d\n", wheel); > >> > > >> > if (wheel) { > >> > if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { > >> > @@ -323,6 +324,7 @@ > >> > sc->flags |= UMS_Z; > >> > } > >> > } > >> > + printf("sc->flags=0x%04x\n", sc->flags); > >> > > >> > /* > >> > * The Microsoft Wireless Intellimouse 2.0 reports it's wheel > >> > @@ -402,6 +404,7 @@ > >> > sc->sc_loc_x.pos = 8; > >> > sc->sc_loc_y.pos = 16; > >> > sc->sc_loc_z.pos = 24; > >> > + printf("sc->sc_loc_z.size=%u\n", sc->sc_loc_z.size); > >> > sc->sc_loc_btn[0].pos = 0; > >> > sc->sc_loc_btn[1].pos = 1; > >> > sc->sc_loc_btn[2].pos = 2; > >> > >> this, what I see: > >> > >> ums0: >> 0/0, rev 2.00/1.20, addr 2> on uhub0 > >> wheel=0 > >> sc->flags=0x0000 > >> ums0: 3 buttons and a TILT dir. > >> sc->sc_loc_z.size=0 > >> > > > > Interesting. Now I suspect that Optical Mouse 3000 model 1049 got > > different > > versions. > > > > Could you please get krepdump > > (http://people.freebsd.org/~kaiw/tools/krepdump.tgz) > > > > # tar xzvf krepdump.tgz > > # cd krepdump > > # make > > # kldload ./krepdump.ko > > > > Then plug in your mouse and paste the result here? > > > > There is one version of report desc of this mouse here: > > http://lists.freebsd.org/pipermail/freebsd-usb/2008-February/004617.html > > > > and my guess is your mouse's report desc is different than that... > > > > > > Thanks, > > Kai > > ---- my krepdump ---- > ums0: at uhub0 port 2 (addr 2) disconnected > ums0: detached > > [report desc size=196] > USAGE PAGE Consumer(0xc) > USAGE Consumer Control(0x1)[Consumer(0xc)] > COLLECTION Application(1) > USAGE PAGE Generic Desktop(0x1) > USAGE Mouse(0x2)[Generic Desktop(0x1)] > COLLECTION Logical(2) > REPORT ID 19 > USAGE PAGE Consumer(0xc) > USAGE AC Pan(0x238)[Consumer(0xc)] > REPORT COUNT 1 > REPORT SIZE 8 > LOGICAL MINIMUM -127 > LOGICAL MAXIMUM 127 > INPUT ( Data Variable Relative ) (6) > REPORT ID 23 > USAGE PAGE Microsoft(0xff00) > USAGE Unknown Usage(0xff06)[Microsoft(0xff00)] > LOGICAL MINIMUM 0 > LOGICAL MAXIMUM 1 > PHYSICAL MINIMUM 1 > PHYSICAL MAXIMUM 4 > REPORT COUNT 1 > REPORT SIZE 2 > FEATURE ( Data Variable Absolute ) (2) > PHYSICAL MINIMUM 0 > PHYSICAL MAXIMUM 0 > FEATURE ( Const Array Absolute ) (1) > USAGE Unknown Usage(0xff04)[Microsoft(0xff00)] > REPORT SIZE 1 > FEATURE ( Data Variable Absolute ) (2) > REPORT SIZE 3 > FEATURE ( Const Array Absolute ) (1) > REPORT ID 24 > USAGE Unknown Usage(0xff08)[Microsoft(0xff00)] > REPORT SIZE 1 > FEATURE ( Data Variable Absolute ) (2) > REPORT SIZE 7 > FEATURE ( Const Array Absolute ) (1) > END COLLECTION > END COLLECTION > USAGE PAGE Generic Desktop(0x1) > USAGE Mouse(0x2)[Generic Desktop(0x1)] > COLLECTION Application(1) > USAGE PAGE Generic Desktop(0x1) > USAGE Mouse(0x2)[Generic Desktop(0x1)] > COLLECTION Logical(2) > REPORT ID 17 > USAGE Pointer(0x1)[Generic Desktop(0x1)] > COLLECTION Physical(0) > USAGE PAGE Button(0x9) > USAGE MINIMUM Button1(1) > USAGE MAXIMUM Button3(3) > REPORT COUNT 3 > REPORT SIZE 1 > LOGICAL MAXIMUM 1 > INPUT ( Data Variable Absolute ) (2) > REPORT COUNT 1 > INPUT ( Const Array Absolute ) (1) > USAGE Button5(0x5)[Button(0x9)] > INPUT ( Data Variable Absolute ) (2) > REPORT COUNT 3 > INPUT ( Const Array Absolute ) (1) > USAGE PAGE Generic Desktop(0x1) > USAGE X(0x30)[Generic Desktop(0x1)] > USAGE Y(0x31)[Generic Desktop(0x1)] > REPORT COUNT 2 > REPORT SIZE 8 > LOGICAL MINIMUM -127 > LOGICAL MAXIMUM 127 > INPUT ( Data Variable Relative ) (6) > COLLECTION Logical(2) > REPORT ID 18 > USAGE Resolution Multiplier(0x48)[Generic Desktop(0x1)] > REPORT COUNT 1 > REPORT SIZE 2 > LOGICAL MINIMUM 0 > LOGICAL MAXIMUM 1 > PHYSICAL MINIMUM 1 > PHYSICAL MAXIMUM 4 > FEATURE ( Data Variable Absolute ) (2) > PHYSICAL MINIMUM 0 > PHYSICAL MAXIMUM 0 > REPORT SIZE 6 > FEATURE ( Const Array Absolute ) (1) > REPORT ID 17 > USAGE Wheel(0x38)[Generic Desktop(0x1)] > LOGICAL MINIMUM -127 > LOGICAL MAXIMUM 127 > REPORT SIZE 8 > INPUT ( Data Variable Relative ) (6) > END COLLECTION > USAGE PAGE Consumer(0xc) > REPORT SIZE 8 > USAGE AC Pan(0x238)[Consumer(0xc)] > INPUT ( Data Variable Relative ) (6) > END COLLECTION > END COLLECTION > END COLLECTION > [hexdump] > 0000 05 0C 09 01 A1 01 05 01 09 02 A1 02 85 13 05 0C > 0010 0A 38 02 95 01 75 08 15 81 25 7F 81 06 85 17 06 > 0020 00 FF 0A 06 FF 15 00 25 01 35 01 45 04 95 01 75 > 0030 02 B1 02 35 00 45 00 B1 01 0A 04 FF 75 01 B1 02 > 0040 75 03 B1 01 85 18 0A 08 FF 75 01 B1 02 75 07 B1 > 0050 01 C0 C0 05 01 09 02 A1 01 05 01 09 02 A1 02 85 > 0060 11 09 01 A1 00 05 09 19 01 29 03 95 03 75 01 25 > 0070 01 81 02 95 01 81 01 09 05 81 02 95 03 81 01 05 > 0080 01 09 30 09 31 95 02 75 08 15 81 25 7F 81 06 A1 > 0090 02 85 12 09 48 95 01 75 02 15 00 25 01 35 01 45 > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > 00C0 06 C0 C0 C0 > ums0: 0/0, rev 2.00/1.20, addr 2> on uhub0 > wheel=0 > sc->flags=0x0000 > ums0: 3 buttons and a TILT dir. > sc->sc_loc_z.size=0 > ---- end of krepdump ---- > > > ---- diff between my report and this from lists.freebsd.org/.../004617.html > ---- > --- 1.txt 2008-08-11 19:25:56.496820730 +0200 > +++ dump.txt 2008-08-11 19:25:59.156847633 +0200 > @@ -1,7 +1,7 @@ > -ums1: at uhub0 port 4 (addr 4) disconnected > -ums1: detached > - > -[report desc size=3D196] > +ums0: at uhub0 port 2 (addr 2) disconnected > +ums0: detached > + > +[report desc size=196] > USAGE PAGE Consumer(0xc) > USAGE Consumer Control(0x1)[Consumer(0xc)] > COLLECTION Application(1) > @@ -114,6 +114,9 @@ > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > 00C0 06 C0 C0 C0 > -ums1: 0/0, rev 2.00/1.20, addr 4> on uhub0 > -ums1: 3 buttons and Z dir and a TILT dir. > +ums0: 0/0, rev 2.00/1.20, addr 2> on uhub0 > +wheel=0 > +sc->flags=0x0000 > +ums0: 3 buttons and a TILT dir. > +sc->sc_loc_z.size=0 > ---- end of diff ---- > > and short info: > > When I use RELENG_7_0, driver reports that my mouse have Z dir, but on > RELENG_7 not. The report descriptor is the same. After some experiments, I think the actual problem is inside our hid parser. Could you please try the patch attached against /sys/dev/usb/hid.c along with the debug printf patch for ums.c, and see what the result will be? --y0ulUmNC+osPPQO6 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="hid.diff" --- /sys/dev/usb/hid.c 2007-06-20 07:10:52.000000000 +0200 +++ hid.c 2008-08-12 04:14:19.000000000 +0200 @@ -131,6 +131,8 @@ if (s->multi < s->multimax) { c->usage = s->usages[min(s->multi, s->nu-1)]; s->multi++; + if (s->nu > 0) + s->nu--; *h = *c; c->loc.pos += c->loc.size; h->next = 0; @@ -193,8 +195,11 @@ case 0: /* Main */ switch (bTag) { case 8: /* Input */ - if (!(s->kindset & (1 << hid_input))) + if (!(s->kindset & (1 << hid_input))) { + if (s->nu > 0) + s->nu--; continue; + } c->kind = hid_input; c->flags = dval; ret: @@ -223,8 +228,11 @@ return (1); } case 9: /* Output */ - if (!(s->kindset & (1 << hid_output))) + if (!(s->kindset & (1 << hid_output))) { + if (s->nu > 0) + s->nu--; continue; + } c->kind = hid_output; c->flags = dval; goto ret; @@ -237,8 +245,11 @@ s->nu = 0; return (1); case 11: /* Feature */ - if (!(s->kindset & (1 << hid_feature))) + if (!(s->kindset & (1 << hid_feature))) { + if (s->nu > 0) + s->nu--; continue; + } c->kind = hid_feature; c->flags = dval; goto ret; --y0ulUmNC+osPPQO6-- From magik at back-up.pl Tue Aug 12 12:30:25 2008 From: magik at back-up.pl (Grzegorz Blach) Date: Tue Aug 12 12:31:02 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 In-Reply-To: <20080812022710.GA7527@plan0> References: <200807242330.m6ONU70T091921@freefall.freebsd.org> <5d252c1d8f1ddaed55d2467adea536ca@chi.fastbighost.com> <20080811133434.GA4224@plan0> <0ed513c9800b730fff47034b86526e5d@chi.fastbighost.com> <20080811151941.GA4590@plan0> <310aef2cb8e5bbcc7cf345f962cb102b@chi.fastbighost.com> <20080812022710.GA7527@plan0> Message-ID: <20080812143016.2ac5a7a4@silver.doors> On Tue, 12 Aug 2008 04:27:10 +0200 Kai Wang wrote: > On Mon, Aug 11, 2008 at 01:30:57PM -0400, Grzegorz Blach wrote: > > On Mon, 11 Aug 2008 17:19:41 +0200, Kai Wang > > wrote: > > > On Mon, Aug 11, 2008 at 10:19:35AM -0400, Grzegorz Blach wrote: > > >> > > >> > > >> On Mon, 11 Aug 2008 15:34:34 +0200, Kai Wang > > >> > > > wrote: > > >> > On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl > > >> > wrote: > > >> >> > > >> >> > > >> >> On Thu, 24 Jul 2008 23:30:07 GMT, > > >> >> FreeBSD-gnats-submit@FreeBSD.org > > >> > wrote: > > >> >> > Thank you very much for your problem report. > > >> >> > It has the internal identification `usb/125941'. > > >> >> > The individual assigned to look at your > > >> >> > report is: freebsd-usb. > > >> >> > > > >> >> > You can access the state of your problem report at any time > > >> >> > via this link: > > >> >> > > > >> >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 > > >> >> > > > >> >> >>Category: usb > > >> >> >>Responsible: freebsd-usb > > >> >> >>Synopsis: not working wheel on my microsoft notebook > > >> >> >>optical > > >> > mouse > > >> >> > 3000 > > >> >> >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 > > >> >> > > >> >> I just fixed problem with wheel on my mouse > > >> >> and I'm sending in attachment patch > > >> >> for /usr/src/sys/dev/usb/ums.c > > > file. > > >> > > > >> >> --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 > > >> >> +++ ums.c 2008-08-05 17:24:51.885277111 +0200 > > >> >> @@ -402,6 +402,7 @@ > > >> >> sc->sc_loc_x.pos = 8; > > >> >> sc->sc_loc_y.pos = 16; > > >> >> sc->sc_loc_z.pos = 24; > > >> >> + sc->sc_loc_z.size = 8; > > >> >> sc->sc_loc_btn[0].pos = 0; > > >> >> sc->sc_loc_btn[1].pos = 1; > > >> >> sc->sc_loc_btn[2].pos = 2; > > >> > > > >> > > > >> > Hi, > > >> > > > >> > Thanks for submitting the patch. It'd be great if you could > > >> > also test the patch below for us and paste the result here, > > >> > just for better understanding the problem. > > >> > > > >> > The patch adds some debug printfs: > > >> > > > >> > --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 > > >> > +0200 +++ ums.c 2008-08-11 15:25:44.000000000 +0200 > > >> > @@ -284,6 +284,7 @@ > > >> > wheel = hid_locate(desc, size, > > >> > HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_WHEEL), > > >> > hid_input, &sc->sc_loc_z, &flags); > > >> > + printf("wheel=%d\n", wheel); > > >> > > > >> > if (wheel) { > > >> > if ((flags & MOUSE_FLAGS_MASK) != > > >> > MOUSE_FLAGS) { @@ -323,6 +324,7 @@ > > >> > sc->flags |= UMS_Z; > > >> > } > > >> > } > > >> > + printf("sc->flags=0x%04x\n", sc->flags); > > >> > > > >> > /* > > >> > * The Microsoft Wireless Intellimouse 2.0 reports > > >> > it's wheel @@ -402,6 +404,7 @@ > > >> > sc->sc_loc_x.pos = 8; > > >> > sc->sc_loc_y.pos = 16; > > >> > sc->sc_loc_z.pos = 24; > > >> > + printf("sc->sc_loc_z.size=%u\n", > > >> > sc->sc_loc_z.size); sc->sc_loc_btn[0].pos = 0; > > >> > sc->sc_loc_btn[1].pos = 1; > > >> > sc->sc_loc_btn[2].pos = 2; > > >> > > >> this, what I see: > > >> > > >> ums0: > >> Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > >> wheel=0 > > >> sc->flags=0x0000 > > >> ums0: 3 buttons and a TILT dir. > > >> sc->sc_loc_z.size=0 > > >> > > > > > > Interesting. Now I suspect that Optical Mouse 3000 model 1049 got > > > different > > > versions. > > > > > > Could you please get krepdump > > > (http://people.freebsd.org/~kaiw/tools/krepdump.tgz) > > > > > > # tar xzvf krepdump.tgz > > > # cd krepdump > > > # make > > > # kldload ./krepdump.ko > > > > > > Then plug in your mouse and paste the result here? > > > > > > There is one version of report desc of this mouse here: > > > http://lists.freebsd.org/pipermail/freebsd-usb/2008-February/004617.html > > > > > > and my guess is your mouse's report desc is different than that... > > > > > > > > > Thanks, > > > Kai > > > > ---- my krepdump ---- > > ums0: at uhub0 port 2 (addr 2) disconnected > > ums0: detached > > > > [report desc size=196] > > USAGE PAGE Consumer(0xc) > > USAGE Consumer Control(0x1)[Consumer(0xc)] > > COLLECTION Application(1) > > USAGE PAGE Generic Desktop(0x1) > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > COLLECTION Logical(2) > > REPORT ID 19 > > USAGE PAGE Consumer(0xc) > > USAGE AC Pan(0x238)[Consumer(0xc)] > > REPORT COUNT 1 > > REPORT SIZE 8 > > LOGICAL MINIMUM -127 > > LOGICAL MAXIMUM 127 > > INPUT ( Data Variable Relative ) (6) > > REPORT ID 23 > > USAGE PAGE Microsoft(0xff00) > > USAGE Unknown Usage(0xff06)[Microsoft(0xff00)] > > LOGICAL MINIMUM 0 > > LOGICAL MAXIMUM 1 > > PHYSICAL MINIMUM 1 > > PHYSICAL MAXIMUM 4 > > REPORT COUNT 1 > > REPORT SIZE 2 > > FEATURE ( Data Variable Absolute ) (2) > > PHYSICAL MINIMUM 0 > > PHYSICAL MAXIMUM 0 > > FEATURE ( Const Array Absolute ) (1) > > USAGE Unknown Usage(0xff04)[Microsoft(0xff00)] > > REPORT SIZE 1 > > FEATURE ( Data Variable Absolute ) (2) > > REPORT SIZE 3 > > FEATURE ( Const Array Absolute ) (1) > > REPORT ID 24 > > USAGE Unknown Usage(0xff08)[Microsoft(0xff00)] > > REPORT SIZE 1 > > FEATURE ( Data Variable Absolute ) (2) > > REPORT SIZE 7 > > FEATURE ( Const Array Absolute ) (1) > > END COLLECTION > > END COLLECTION > > USAGE PAGE Generic Desktop(0x1) > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > COLLECTION Application(1) > > USAGE PAGE Generic Desktop(0x1) > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > COLLECTION Logical(2) > > REPORT ID 17 > > USAGE Pointer(0x1)[Generic Desktop(0x1)] > > COLLECTION Physical(0) > > USAGE PAGE Button(0x9) > > USAGE MINIMUM Button1(1) > > USAGE MAXIMUM Button3(3) > > REPORT COUNT 3 > > REPORT SIZE 1 > > LOGICAL MAXIMUM 1 > > INPUT ( Data Variable Absolute ) (2) > > REPORT COUNT 1 > > INPUT ( Const Array Absolute ) (1) > > USAGE Button5(0x5)[Button(0x9)] > > INPUT ( Data Variable Absolute ) (2) > > REPORT COUNT 3 > > INPUT ( Const Array Absolute ) (1) > > USAGE PAGE Generic Desktop(0x1) > > USAGE X(0x30)[Generic Desktop(0x1)] > > USAGE Y(0x31)[Generic Desktop(0x1)] > > REPORT COUNT 2 > > REPORT SIZE 8 > > LOGICAL MINIMUM -127 > > LOGICAL MAXIMUM 127 > > INPUT ( Data Variable Relative ) (6) > > COLLECTION Logical(2) > > REPORT ID 18 > > USAGE Resolution Multiplier(0x48)[Generic Desktop(0x1)] > > REPORT COUNT 1 > > REPORT SIZE 2 > > LOGICAL MINIMUM 0 > > LOGICAL MAXIMUM 1 > > PHYSICAL MINIMUM 1 > > PHYSICAL MAXIMUM 4 > > FEATURE ( Data Variable Absolute ) (2) > > PHYSICAL MINIMUM 0 > > PHYSICAL MAXIMUM 0 > > REPORT SIZE 6 > > FEATURE ( Const Array Absolute ) (1) > > REPORT ID 17 > > USAGE Wheel(0x38)[Generic Desktop(0x1)] > > LOGICAL MINIMUM -127 > > LOGICAL MAXIMUM 127 > > REPORT SIZE 8 > > INPUT ( Data Variable Relative ) (6) > > END COLLECTION > > USAGE PAGE Consumer(0xc) > > REPORT SIZE 8 > > USAGE AC Pan(0x238)[Consumer(0xc)] > > INPUT ( Data Variable Relative ) (6) > > END COLLECTION > > END COLLECTION > > END COLLECTION > > [hexdump] > > 0000 05 0C 09 01 A1 01 05 01 09 02 A1 02 85 13 05 0C > > 0010 0A 38 02 95 01 75 08 15 81 25 7F 81 06 85 17 06 > > 0020 00 FF 0A 06 FF 15 00 25 01 35 01 45 04 95 01 75 > > 0030 02 B1 02 35 00 45 00 B1 01 0A 04 FF 75 01 B1 02 > > 0040 75 03 B1 01 85 18 0A 08 FF 75 01 B1 02 75 07 B1 > > 0050 01 C0 C0 05 01 09 02 A1 01 05 01 09 02 A1 02 85 > > 0060 11 09 01 A1 00 05 09 19 01 29 03 95 03 75 01 25 > > 0070 01 81 02 95 01 81 01 09 05 81 02 95 03 81 01 05 > > 0080 01 09 30 09 31 95 02 75 08 15 81 25 7F 81 06 A1 > > 0090 02 85 12 09 48 95 01 75 02 15 00 25 01 35 01 45 > > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > > 00C0 06 C0 C0 C0 > > ums0: > class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > wheel=0 > > sc->flags=0x0000 > > ums0: 3 buttons and a TILT dir. > > sc->sc_loc_z.size=0 > > ---- end of krepdump ---- > > > > > > ---- diff between my report and this from > > lists.freebsd.org/.../004617.html ---- > > --- 1.txt 2008-08-11 19:25:56.496820730 +0200 > > +++ dump.txt 2008-08-11 19:25:59.156847633 +0200 > > @@ -1,7 +1,7 @@ > > -ums1: at uhub0 port 4 (addr 4) disconnected > > -ums1: detached > > - > > -[report desc size=3D196] > > +ums0: at uhub0 port 2 (addr 2) disconnected > > +ums0: detached > > + > > +[report desc size=196] > > USAGE PAGE Consumer(0xc) > > USAGE Consumer Control(0x1)[Consumer(0xc)] > > COLLECTION Application(1) > > @@ -114,6 +114,9 @@ > > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > > 00C0 06 C0 C0 C0 > > -ums1: > class 0/0, rev 2.00/1.20, addr 4> on uhub0 > > -ums1: 3 buttons and Z dir and a TILT dir. > > +ums0: > class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > +wheel=0 > > +sc->flags=0x0000 > > +ums0: 3 buttons and a TILT dir. > > +sc->sc_loc_z.size=0 > > ---- end of diff ---- > > > > and short info: > > > > When I use RELENG_7_0, driver reports that my mouse have Z dir, but > > on RELENG_7 not. > > The report descriptor is the same. After some experiments, I think > the actual problem is inside our hid parser. > > Could you please try the patch attached against /sys/dev/usb/hid.c > along with the debug printf patch for ums.c, and see what the result > will be? > > kernel with appiled this two patches reports that: ums0: on uhub0 ums0: mouse has no Y report device_attach: ums0 attach returned 6 From magik at back-up.pl Tue Aug 12 12:40:04 2008 From: magik at back-up.pl (Grzegorz Blach) Date: Tue Aug 12 12:40:11 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Message-ID: <200808121240.m7CCe3bO021257@freefall.freebsd.org> The following reply was made to PR usb/125941; it has been noted by GNATS. From: Grzegorz Blach To: Kai Wang Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: Re: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Date: Tue, 12 Aug 2008 14:30:16 +0200 On Tue, 12 Aug 2008 04:27:10 +0200 Kai Wang wrote: > On Mon, Aug 11, 2008 at 01:30:57PM -0400, Grzegorz Blach wrote: > > On Mon, 11 Aug 2008 17:19:41 +0200, Kai Wang > > wrote: > > > On Mon, Aug 11, 2008 at 10:19:35AM -0400, Grzegorz Blach wrote: > > >> > > >> > > >> On Mon, 11 Aug 2008 15:34:34 +0200, Kai Wang > > >> > > > wrote: > > >> > On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl > > >> > wrote: > > >> >> > > >> >> > > >> >> On Thu, 24 Jul 2008 23:30:07 GMT, > > >> >> FreeBSD-gnats-submit@FreeBSD.org > > >> > wrote: > > >> >> > Thank you very much for your problem report. > > >> >> > It has the internal identification `usb/125941'. > > >> >> > The individual assigned to look at your > > >> >> > report is: freebsd-usb. > > >> >> > > > >> >> > You can access the state of your problem report at any time > > >> >> > via this link: > > >> >> > > > >> >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 > > >> >> > > > >> >> >>Category: usb > > >> >> >>Responsible: freebsd-usb > > >> >> >>Synopsis: not working wheel on my microsoft notebook > > >> >> >>optical > > >> > mouse > > >> >> > 3000 > > >> >> >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 > > >> >> > > >> >> I just fixed problem with wheel on my mouse > > >> >> and I'm sending in attachment patch > > >> >> for /usr/src/sys/dev/usb/ums.c > > > file. > > >> > > > >> >> --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 > > >> >> +++ ums.c 2008-08-05 17:24:51.885277111 +0200 > > >> >> @@ -402,6 +402,7 @@ > > >> >> sc->sc_loc_x.pos = 8; > > >> >> sc->sc_loc_y.pos = 16; > > >> >> sc->sc_loc_z.pos = 24; > > >> >> + sc->sc_loc_z.size = 8; > > >> >> sc->sc_loc_btn[0].pos = 0; > > >> >> sc->sc_loc_btn[1].pos = 1; > > >> >> sc->sc_loc_btn[2].pos = 2; > > >> > > > >> > > > >> > Hi, > > >> > > > >> > Thanks for submitting the patch. It'd be great if you could > > >> > also test the patch below for us and paste the result here, > > >> > just for better understanding the problem. > > >> > > > >> > The patch adds some debug printfs: > > >> > > > >> > --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 > > >> > +0200 +++ ums.c 2008-08-11 15:25:44.000000000 +0200 > > >> > @@ -284,6 +284,7 @@ > > >> > wheel = hid_locate(desc, size, > > >> > HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_WHEEL), > > >> > hid_input, &sc->sc_loc_z, &flags); > > >> > + printf("wheel=%d\n", wheel); > > >> > > > >> > if (wheel) { > > >> > if ((flags & MOUSE_FLAGS_MASK) != > > >> > MOUSE_FLAGS) { @@ -323,6 +324,7 @@ > > >> > sc->flags |= UMS_Z; > > >> > } > > >> > } > > >> > + printf("sc->flags=0x%04x\n", sc->flags); > > >> > > > >> > /* > > >> > * The Microsoft Wireless Intellimouse 2.0 reports > > >> > it's wheel @@ -402,6 +404,7 @@ > > >> > sc->sc_loc_x.pos = 8; > > >> > sc->sc_loc_y.pos = 16; > > >> > sc->sc_loc_z.pos = 24; > > >> > + printf("sc->sc_loc_z.size=%u\n", > > >> > sc->sc_loc_z.size); sc->sc_loc_btn[0].pos = 0; > > >> > sc->sc_loc_btn[1].pos = 1; > > >> > sc->sc_loc_btn[2].pos = 2; > > >> > > >> this, what I see: > > >> > > >> ums0: > >> Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > >> wheel=0 > > >> sc->flags=0x0000 > > >> ums0: 3 buttons and a TILT dir. > > >> sc->sc_loc_z.size=0 > > >> > > > > > > Interesting. Now I suspect that Optical Mouse 3000 model 1049 got > > > different > > > versions. > > > > > > Could you please get krepdump > > > (http://people.freebsd.org/~kaiw/tools/krepdump.tgz) > > > > > > # tar xzvf krepdump.tgz > > > # cd krepdump > > > # make > > > # kldload ./krepdump.ko > > > > > > Then plug in your mouse and paste the result here? > > > > > > There is one version of report desc of this mouse here: > > > http://lists.freebsd.org/pipermail/freebsd-usb/2008-February/004617.html > > > > > > and my guess is your mouse's report desc is different than that... > > > > > > > > > Thanks, > > > Kai > > > > ---- my krepdump ---- > > ums0: at uhub0 port 2 (addr 2) disconnected > > ums0: detached > > > > [report desc size=196] > > USAGE PAGE Consumer(0xc) > > USAGE Consumer Control(0x1)[Consumer(0xc)] > > COLLECTION Application(1) > > USAGE PAGE Generic Desktop(0x1) > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > COLLECTION Logical(2) > > REPORT ID 19 > > USAGE PAGE Consumer(0xc) > > USAGE AC Pan(0x238)[Consumer(0xc)] > > REPORT COUNT 1 > > REPORT SIZE 8 > > LOGICAL MINIMUM -127 > > LOGICAL MAXIMUM 127 > > INPUT ( Data Variable Relative ) (6) > > REPORT ID 23 > > USAGE PAGE Microsoft(0xff00) > > USAGE Unknown Usage(0xff06)[Microsoft(0xff00)] > > LOGICAL MINIMUM 0 > > LOGICAL MAXIMUM 1 > > PHYSICAL MINIMUM 1 > > PHYSICAL MAXIMUM 4 > > REPORT COUNT 1 > > REPORT SIZE 2 > > FEATURE ( Data Variable Absolute ) (2) > > PHYSICAL MINIMUM 0 > > PHYSICAL MAXIMUM 0 > > FEATURE ( Const Array Absolute ) (1) > > USAGE Unknown Usage(0xff04)[Microsoft(0xff00)] > > REPORT SIZE 1 > > FEATURE ( Data Variable Absolute ) (2) > > REPORT SIZE 3 > > FEATURE ( Const Array Absolute ) (1) > > REPORT ID 24 > > USAGE Unknown Usage(0xff08)[Microsoft(0xff00)] > > REPORT SIZE 1 > > FEATURE ( Data Variable Absolute ) (2) > > REPORT SIZE 7 > > FEATURE ( Const Array Absolute ) (1) > > END COLLECTION > > END COLLECTION > > USAGE PAGE Generic Desktop(0x1) > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > COLLECTION Application(1) > > USAGE PAGE Generic Desktop(0x1) > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > COLLECTION Logical(2) > > REPORT ID 17 > > USAGE Pointer(0x1)[Generic Desktop(0x1)] > > COLLECTION Physical(0) > > USAGE PAGE Button(0x9) > > USAGE MINIMUM Button1(1) > > USAGE MAXIMUM Button3(3) > > REPORT COUNT 3 > > REPORT SIZE 1 > > LOGICAL MAXIMUM 1 > > INPUT ( Data Variable Absolute ) (2) > > REPORT COUNT 1 > > INPUT ( Const Array Absolute ) (1) > > USAGE Button5(0x5)[Button(0x9)] > > INPUT ( Data Variable Absolute ) (2) > > REPORT COUNT 3 > > INPUT ( Const Array Absolute ) (1) > > USAGE PAGE Generic Desktop(0x1) > > USAGE X(0x30)[Generic Desktop(0x1)] > > USAGE Y(0x31)[Generic Desktop(0x1)] > > REPORT COUNT 2 > > REPORT SIZE 8 > > LOGICAL MINIMUM -127 > > LOGICAL MAXIMUM 127 > > INPUT ( Data Variable Relative ) (6) > > COLLECTION Logical(2) > > REPORT ID 18 > > USAGE Resolution Multiplier(0x48)[Generic Desktop(0x1)] > > REPORT COUNT 1 > > REPORT SIZE 2 > > LOGICAL MINIMUM 0 > > LOGICAL MAXIMUM 1 > > PHYSICAL MINIMUM 1 > > PHYSICAL MAXIMUM 4 > > FEATURE ( Data Variable Absolute ) (2) > > PHYSICAL MINIMUM 0 > > PHYSICAL MAXIMUM 0 > > REPORT SIZE 6 > > FEATURE ( Const Array Absolute ) (1) > > REPORT ID 17 > > USAGE Wheel(0x38)[Generic Desktop(0x1)] > > LOGICAL MINIMUM -127 > > LOGICAL MAXIMUM 127 > > REPORT SIZE 8 > > INPUT ( Data Variable Relative ) (6) > > END COLLECTION > > USAGE PAGE Consumer(0xc) > > REPORT SIZE 8 > > USAGE AC Pan(0x238)[Consumer(0xc)] > > INPUT ( Data Variable Relative ) (6) > > END COLLECTION > > END COLLECTION > > END COLLECTION > > [hexdump] > > 0000 05 0C 09 01 A1 01 05 01 09 02 A1 02 85 13 05 0C > > 0010 0A 38 02 95 01 75 08 15 81 25 7F 81 06 85 17 06 > > 0020 00 FF 0A 06 FF 15 00 25 01 35 01 45 04 95 01 75 > > 0030 02 B1 02 35 00 45 00 B1 01 0A 04 FF 75 01 B1 02 > > 0040 75 03 B1 01 85 18 0A 08 FF 75 01 B1 02 75 07 B1 > > 0050 01 C0 C0 05 01 09 02 A1 01 05 01 09 02 A1 02 85 > > 0060 11 09 01 A1 00 05 09 19 01 29 03 95 03 75 01 25 > > 0070 01 81 02 95 01 81 01 09 05 81 02 95 03 81 01 05 > > 0080 01 09 30 09 31 95 02 75 08 15 81 25 7F 81 06 A1 > > 0090 02 85 12 09 48 95 01 75 02 15 00 25 01 35 01 45 > > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > > 00C0 06 C0 C0 C0 > > ums0: > class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > wheel=0 > > sc->flags=0x0000 > > ums0: 3 buttons and a TILT dir. > > sc->sc_loc_z.size=0 > > ---- end of krepdump ---- > > > > > > ---- diff between my report and this from > > lists.freebsd.org/.../004617.html ---- > > --- 1.txt 2008-08-11 19:25:56.496820730 +0200 > > +++ dump.txt 2008-08-11 19:25:59.156847633 +0200 > > @@ -1,7 +1,7 @@ > > -ums1: at uhub0 port 4 (addr 4) disconnected > > -ums1: detached > > - > > -[report desc size=3D196] > > +ums0: at uhub0 port 2 (addr 2) disconnected > > +ums0: detached > > + > > +[report desc size=196] > > USAGE PAGE Consumer(0xc) > > USAGE Consumer Control(0x1)[Consumer(0xc)] > > COLLECTION Application(1) > > @@ -114,6 +114,9 @@ > > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > > 00C0 06 C0 C0 C0 > > -ums1: > class 0/0, rev 2.00/1.20, addr 4> on uhub0 > > -ums1: 3 buttons and Z dir and a TILT dir. > > +ums0: > class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > +wheel=0 > > +sc->flags=0x0000 > > +ums0: 3 buttons and a TILT dir. > > +sc->sc_loc_z.size=0 > > ---- end of diff ---- > > > > and short info: > > > > When I use RELENG_7_0, driver reports that my mouse have Z dir, but > > on RELENG_7 not. > > The report descriptor is the same. After some experiments, I think > the actual problem is inside our hid parser. > > Could you please try the patch attached against /sys/dev/usb/hid.c > along with the debug printf patch for ums.c, and see what the result > will be? > > kernel with appiled this two patches reports that: ums0: on uhub0 ums0: mouse has no Y report device_attach: ums0 attach returned 6 From kaiwang27 at gmail.com Tue Aug 12 13:30:38 2008 From: kaiwang27 at gmail.com (Kai Wang) Date: Tue Aug 12 13:30:44 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 In-Reply-To: <20080812143016.2ac5a7a4@silver.doors> References: <200807242330.m6ONU70T091921@freefall.freebsd.org> <5d252c1d8f1ddaed55d2467adea536ca@chi.fastbighost.com> <20080811133434.GA4224@plan0> <0ed513c9800b730fff47034b86526e5d@chi.fastbighost.com> <20080811151941.GA4590@plan0> <310aef2cb8e5bbcc7cf345f962cb102b@chi.fastbighost.com> <20080812022710.GA7527@plan0> <20080812143016.2ac5a7a4@silver.doors> Message-ID: <20080812133029.GA9576@plan0> On Tue, Aug 12, 2008 at 02:30:16PM +0200, Grzegorz Blach wrote: > On Tue, 12 Aug 2008 04:27:10 +0200 > Kai Wang wrote: > > > On Mon, Aug 11, 2008 at 01:30:57PM -0400, Grzegorz Blach wrote: > > > On Mon, 11 Aug 2008 17:19:41 +0200, Kai Wang > > > wrote: > > > > On Mon, Aug 11, 2008 at 10:19:35AM -0400, Grzegorz Blach wrote: > > > >> > > > >> > > > >> On Mon, 11 Aug 2008 15:34:34 +0200, Kai Wang > > > >> > > > > wrote: > > > >> > On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl > > > >> > wrote: > > > >> >> > > > >> >> > > > >> >> On Thu, 24 Jul 2008 23:30:07 GMT, > > > >> >> FreeBSD-gnats-submit@FreeBSD.org > > > >> > wrote: > > > >> >> > Thank you very much for your problem report. > > > >> >> > It has the internal identification `usb/125941'. > > > >> >> > The individual assigned to look at your > > > >> >> > report is: freebsd-usb. > > > >> >> > > > > >> >> > You can access the state of your problem report at any time > > > >> >> > via this link: > > > >> >> > > > > >> >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 > > > >> >> > > > > >> >> >>Category: usb > > > >> >> >>Responsible: freebsd-usb > > > >> >> >>Synopsis: not working wheel on my microsoft notebook > > > >> >> >>optical > > > >> > mouse > > > >> >> > 3000 > > > >> >> >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 > > > >> >> > > > >> >> I just fixed problem with wheel on my mouse > > > >> >> and I'm sending in attachment patch > > > >> >> for /usr/src/sys/dev/usb/ums.c > > > > file. > > > >> > > > > >> >> --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 > > > >> >> +++ ums.c 2008-08-05 17:24:51.885277111 +0200 > > > >> >> @@ -402,6 +402,7 @@ > > > >> >> sc->sc_loc_x.pos = 8; > > > >> >> sc->sc_loc_y.pos = 16; > > > >> >> sc->sc_loc_z.pos = 24; > > > >> >> + sc->sc_loc_z.size = 8; > > > >> >> sc->sc_loc_btn[0].pos = 0; > > > >> >> sc->sc_loc_btn[1].pos = 1; > > > >> >> sc->sc_loc_btn[2].pos = 2; > > > >> > > > > >> > > > > >> > Hi, > > > >> > > > > >> > Thanks for submitting the patch. It'd be great if you could > > > >> > also test the patch below for us and paste the result here, > > > >> > just for better understanding the problem. > > > >> > > > > >> > The patch adds some debug printfs: > > > >> > > > > >> > --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 > > > >> > +0200 +++ ums.c 2008-08-11 15:25:44.000000000 +0200 > > > >> > @@ -284,6 +284,7 @@ > > > >> > wheel = hid_locate(desc, size, > > > >> > HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_WHEEL), > > > >> > hid_input, &sc->sc_loc_z, &flags); > > > >> > + printf("wheel=%d\n", wheel); > > > >> > > > > >> > if (wheel) { > > > >> > if ((flags & MOUSE_FLAGS_MASK) != > > > >> > MOUSE_FLAGS) { @@ -323,6 +324,7 @@ > > > >> > sc->flags |= UMS_Z; > > > >> > } > > > >> > } > > > >> > + printf("sc->flags=0x%04x\n", sc->flags); > > > >> > > > > >> > /* > > > >> > * The Microsoft Wireless Intellimouse 2.0 reports > > > >> > it's wheel @@ -402,6 +404,7 @@ > > > >> > sc->sc_loc_x.pos = 8; > > > >> > sc->sc_loc_y.pos = 16; > > > >> > sc->sc_loc_z.pos = 24; > > > >> > + printf("sc->sc_loc_z.size=%u\n", > > > >> > sc->sc_loc_z.size); sc->sc_loc_btn[0].pos = 0; > > > >> > sc->sc_loc_btn[1].pos = 1; > > > >> > sc->sc_loc_btn[2].pos = 2; > > > >> > > > >> this, what I see: > > > >> > > > >> ums0: > > >> Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > >> wheel=0 > > > >> sc->flags=0x0000 > > > >> ums0: 3 buttons and a TILT dir. > > > >> sc->sc_loc_z.size=0 > > > >> > > > > > > > > Interesting. Now I suspect that Optical Mouse 3000 model 1049 got > > > > different > > > > versions. > > > > > > > > Could you please get krepdump > > > > (http://people.freebsd.org/~kaiw/tools/krepdump.tgz) > > > > > > > > # tar xzvf krepdump.tgz > > > > # cd krepdump > > > > # make > > > > # kldload ./krepdump.ko > > > > > > > > Then plug in your mouse and paste the result here? > > > > > > > > There is one version of report desc of this mouse here: > > > > http://lists.freebsd.org/pipermail/freebsd-usb/2008-February/004617.html > > > > > > > > and my guess is your mouse's report desc is different than that... > > > > > > > > > > > > Thanks, > > > > Kai > > > > > > ---- my krepdump ---- > > > ums0: at uhub0 port 2 (addr 2) disconnected > > > ums0: detached > > > > > > [report desc size=196] > > > USAGE PAGE Consumer(0xc) > > > USAGE Consumer Control(0x1)[Consumer(0xc)] > > > COLLECTION Application(1) > > > USAGE PAGE Generic Desktop(0x1) > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > COLLECTION Logical(2) > > > REPORT ID 19 > > > USAGE PAGE Consumer(0xc) > > > USAGE AC Pan(0x238)[Consumer(0xc)] > > > REPORT COUNT 1 > > > REPORT SIZE 8 > > > LOGICAL MINIMUM -127 > > > LOGICAL MAXIMUM 127 > > > INPUT ( Data Variable Relative ) (6) > > > REPORT ID 23 > > > USAGE PAGE Microsoft(0xff00) > > > USAGE Unknown Usage(0xff06)[Microsoft(0xff00)] > > > LOGICAL MINIMUM 0 > > > LOGICAL MAXIMUM 1 > > > PHYSICAL MINIMUM 1 > > > PHYSICAL MAXIMUM 4 > > > REPORT COUNT 1 > > > REPORT SIZE 2 > > > FEATURE ( Data Variable Absolute ) (2) > > > PHYSICAL MINIMUM 0 > > > PHYSICAL MAXIMUM 0 > > > FEATURE ( Const Array Absolute ) (1) > > > USAGE Unknown Usage(0xff04)[Microsoft(0xff00)] > > > REPORT SIZE 1 > > > FEATURE ( Data Variable Absolute ) (2) > > > REPORT SIZE 3 > > > FEATURE ( Const Array Absolute ) (1) > > > REPORT ID 24 > > > USAGE Unknown Usage(0xff08)[Microsoft(0xff00)] > > > REPORT SIZE 1 > > > FEATURE ( Data Variable Absolute ) (2) > > > REPORT SIZE 7 > > > FEATURE ( Const Array Absolute ) (1) > > > END COLLECTION > > > END COLLECTION > > > USAGE PAGE Generic Desktop(0x1) > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > COLLECTION Application(1) > > > USAGE PAGE Generic Desktop(0x1) > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > COLLECTION Logical(2) > > > REPORT ID 17 > > > USAGE Pointer(0x1)[Generic Desktop(0x1)] > > > COLLECTION Physical(0) > > > USAGE PAGE Button(0x9) > > > USAGE MINIMUM Button1(1) > > > USAGE MAXIMUM Button3(3) > > > REPORT COUNT 3 > > > REPORT SIZE 1 > > > LOGICAL MAXIMUM 1 > > > INPUT ( Data Variable Absolute ) (2) > > > REPORT COUNT 1 > > > INPUT ( Const Array Absolute ) (1) > > > USAGE Button5(0x5)[Button(0x9)] > > > INPUT ( Data Variable Absolute ) (2) > > > REPORT COUNT 3 > > > INPUT ( Const Array Absolute ) (1) > > > USAGE PAGE Generic Desktop(0x1) > > > USAGE X(0x30)[Generic Desktop(0x1)] > > > USAGE Y(0x31)[Generic Desktop(0x1)] > > > REPORT COUNT 2 > > > REPORT SIZE 8 > > > LOGICAL MINIMUM -127 > > > LOGICAL MAXIMUM 127 > > > INPUT ( Data Variable Relative ) (6) > > > COLLECTION Logical(2) > > > REPORT ID 18 > > > USAGE Resolution Multiplier(0x48)[Generic Desktop(0x1)] > > > REPORT COUNT 1 > > > REPORT SIZE 2 > > > LOGICAL MINIMUM 0 > > > LOGICAL MAXIMUM 1 > > > PHYSICAL MINIMUM 1 > > > PHYSICAL MAXIMUM 4 > > > FEATURE ( Data Variable Absolute ) (2) > > > PHYSICAL MINIMUM 0 > > > PHYSICAL MAXIMUM 0 > > > REPORT SIZE 6 > > > FEATURE ( Const Array Absolute ) (1) > > > REPORT ID 17 > > > USAGE Wheel(0x38)[Generic Desktop(0x1)] > > > LOGICAL MINIMUM -127 > > > LOGICAL MAXIMUM 127 > > > REPORT SIZE 8 > > > INPUT ( Data Variable Relative ) (6) > > > END COLLECTION > > > USAGE PAGE Consumer(0xc) > > > REPORT SIZE 8 > > > USAGE AC Pan(0x238)[Consumer(0xc)] > > > INPUT ( Data Variable Relative ) (6) > > > END COLLECTION > > > END COLLECTION > > > END COLLECTION > > > [hexdump] > > > 0000 05 0C 09 01 A1 01 05 01 09 02 A1 02 85 13 05 0C > > > 0010 0A 38 02 95 01 75 08 15 81 25 7F 81 06 85 17 06 > > > 0020 00 FF 0A 06 FF 15 00 25 01 35 01 45 04 95 01 75 > > > 0030 02 B1 02 35 00 45 00 B1 01 0A 04 FF 75 01 B1 02 > > > 0040 75 03 B1 01 85 18 0A 08 FF 75 01 B1 02 75 07 B1 > > > 0050 01 C0 C0 05 01 09 02 A1 01 05 01 09 02 A1 02 85 > > > 0060 11 09 01 A1 00 05 09 19 01 29 03 95 03 75 01 25 > > > 0070 01 81 02 95 01 81 01 09 05 81 02 95 03 81 01 05 > > > 0080 01 09 30 09 31 95 02 75 08 15 81 25 7F 81 06 A1 > > > 0090 02 85 12 09 48 95 01 75 02 15 00 25 01 35 01 45 > > > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > > > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > > > 00C0 06 C0 C0 C0 > > > ums0: > > class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > wheel=0 > > > sc->flags=0x0000 > > > ums0: 3 buttons and a TILT dir. > > > sc->sc_loc_z.size=0 > > > ---- end of krepdump ---- > > > > > > > > > ---- diff between my report and this from > > > lists.freebsd.org/.../004617.html ---- > > > --- 1.txt 2008-08-11 19:25:56.496820730 +0200 > > > +++ dump.txt 2008-08-11 19:25:59.156847633 +0200 > > > @@ -1,7 +1,7 @@ > > > -ums1: at uhub0 port 4 (addr 4) disconnected > > > -ums1: detached > > > - > > > -[report desc size=3D196] > > > +ums0: at uhub0 port 2 (addr 2) disconnected > > > +ums0: detached > > > + > > > +[report desc size=196] > > > USAGE PAGE Consumer(0xc) > > > USAGE Consumer Control(0x1)[Consumer(0xc)] > > > COLLECTION Application(1) > > > @@ -114,6 +114,9 @@ > > > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > > > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > > > 00C0 06 C0 C0 C0 > > > -ums1: > > class 0/0, rev 2.00/1.20, addr 4> on uhub0 > > > -ums1: 3 buttons and Z dir and a TILT dir. > > > +ums0: > > class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > +wheel=0 > > > +sc->flags=0x0000 > > > +ums0: 3 buttons and a TILT dir. > > > +sc->sc_loc_z.size=0 > > > ---- end of diff ---- > > > > > > and short info: > > > > > > When I use RELENG_7_0, driver reports that my mouse have Z dir, but > > > on RELENG_7 not. > > > > The report descriptor is the same. After some experiments, I think > > the actual problem is inside our hid parser. > > > > Could you please try the patch attached against /sys/dev/usb/hid.c > > along with the debug printf patch for ums.c, and see what the result > > will be? > > > > > > kernel with appiled this two patches reports that: > > ums0: class 0/0, rev 2.00/1.20, addr 2> on uhub0 ums0: mouse has no Y report > device_attach: ums0 attach returned 6 > Sorry I made a mistake in previous patch. How about this one? From kaiwang27 at gmail.com Tue Aug 12 13:40:04 2008 From: kaiwang27 at gmail.com (Kai Wang) Date: Tue Aug 12 13:40:10 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Message-ID: <200808121340.m7CDe3HR026317@freefall.freebsd.org> The following reply was made to PR usb/125941; it has been noted by GNATS. From: Kai Wang To: Grzegorz Blach Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: Re: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Date: Tue, 12 Aug 2008 15:30:29 +0200 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Tue, Aug 12, 2008 at 02:30:16PM +0200, Grzegorz Blach wrote: > On Tue, 12 Aug 2008 04:27:10 +0200 > Kai Wang wrote: > > > On Mon, Aug 11, 2008 at 01:30:57PM -0400, Grzegorz Blach wrote: > > > On Mon, 11 Aug 2008 17:19:41 +0200, Kai Wang > > > wrote: > > > > On Mon, Aug 11, 2008 at 10:19:35AM -0400, Grzegorz Blach wrote: > > > >> > > > >> > > > >> On Mon, 11 Aug 2008 15:34:34 +0200, Kai Wang > > > >> > > > > wrote: > > > >> > On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl > > > >> > wrote: > > > >> >> > > > >> >> > > > >> >> On Thu, 24 Jul 2008 23:30:07 GMT, > > > >> >> FreeBSD-gnats-submit@FreeBSD.org > > > >> > wrote: > > > >> >> > Thank you very much for your problem report. > > > >> >> > It has the internal identification `usb/125941'. > > > >> >> > The individual assigned to look at your > > > >> >> > report is: freebsd-usb. > > > >> >> > > > > >> >> > You can access the state of your problem report at any time > > > >> >> > via this link: > > > >> >> > > > > >> >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 > > > >> >> > > > > >> >> >>Category: usb > > > >> >> >>Responsible: freebsd-usb > > > >> >> >>Synopsis: not working wheel on my microsoft notebook > > > >> >> >>optical > > > >> > mouse > > > >> >> > 3000 > > > >> >> >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 > > > >> >> > > > >> >> I just fixed problem with wheel on my mouse > > > >> >> and I'm sending in attachment patch > > > >> >> for /usr/src/sys/dev/usb/ums.c > > > > file. > > > >> > > > > >> >> --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 > > > >> >> +++ ums.c 2008-08-05 17:24:51.885277111 +0200 > > > >> >> @@ -402,6 +402,7 @@ > > > >> >> sc->sc_loc_x.pos = 8; > > > >> >> sc->sc_loc_y.pos = 16; > > > >> >> sc->sc_loc_z.pos = 24; > > > >> >> + sc->sc_loc_z.size = 8; > > > >> >> sc->sc_loc_btn[0].pos = 0; > > > >> >> sc->sc_loc_btn[1].pos = 1; > > > >> >> sc->sc_loc_btn[2].pos = 2; > > > >> > > > > >> > > > > >> > Hi, > > > >> > > > > >> > Thanks for submitting the patch. It'd be great if you could > > > >> > also test the patch below for us and paste the result here, > > > >> > just for better understanding the problem. > > > >> > > > > >> > The patch adds some debug printfs: > > > >> > > > > >> > --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 > > > >> > +0200 +++ ums.c 2008-08-11 15:25:44.000000000 +0200 > > > >> > @@ -284,6 +284,7 @@ > > > >> > wheel = hid_locate(desc, size, > > > >> > HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_WHEEL), > > > >> > hid_input, &sc->sc_loc_z, &flags); > > > >> > + printf("wheel=%d\n", wheel); > > > >> > > > > >> > if (wheel) { > > > >> > if ((flags & MOUSE_FLAGS_MASK) != > > > >> > MOUSE_FLAGS) { @@ -323,6 +324,7 @@ > > > >> > sc->flags |= UMS_Z; > > > >> > } > > > >> > } > > > >> > + printf("sc->flags=0x%04x\n", sc->flags); > > > >> > > > > >> > /* > > > >> > * The Microsoft Wireless Intellimouse 2.0 reports > > > >> > it's wheel @@ -402,6 +404,7 @@ > > > >> > sc->sc_loc_x.pos = 8; > > > >> > sc->sc_loc_y.pos = 16; > > > >> > sc->sc_loc_z.pos = 24; > > > >> > + printf("sc->sc_loc_z.size=%u\n", > > > >> > sc->sc_loc_z.size); sc->sc_loc_btn[0].pos = 0; > > > >> > sc->sc_loc_btn[1].pos = 1; > > > >> > sc->sc_loc_btn[2].pos = 2; > > > >> > > > >> this, what I see: > > > >> > > > >> ums0: > > >> Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > >> wheel=0 > > > >> sc->flags=0x0000 > > > >> ums0: 3 buttons and a TILT dir. > > > >> sc->sc_loc_z.size=0 > > > >> > > > > > > > > Interesting. Now I suspect that Optical Mouse 3000 model 1049 got > > > > different > > > > versions. > > > > > > > > Could you please get krepdump > > > > (http://people.freebsd.org/~kaiw/tools/krepdump.tgz) > > > > > > > > # tar xzvf krepdump.tgz > > > > # cd krepdump > > > > # make > > > > # kldload ./krepdump.ko > > > > > > > > Then plug in your mouse and paste the result here? > > > > > > > > There is one version of report desc of this mouse here: > > > > http://lists.freebsd.org/pipermail/freebsd-usb/2008-February/004617.html > > > > > > > > and my guess is your mouse's report desc is different than that... > > > > > > > > > > > > Thanks, > > > > Kai > > > > > > ---- my krepdump ---- > > > ums0: at uhub0 port 2 (addr 2) disconnected > > > ums0: detached > > > > > > [report desc size=196] > > > USAGE PAGE Consumer(0xc) > > > USAGE Consumer Control(0x1)[Consumer(0xc)] > > > COLLECTION Application(1) > > > USAGE PAGE Generic Desktop(0x1) > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > COLLECTION Logical(2) > > > REPORT ID 19 > > > USAGE PAGE Consumer(0xc) > > > USAGE AC Pan(0x238)[Consumer(0xc)] > > > REPORT COUNT 1 > > > REPORT SIZE 8 > > > LOGICAL MINIMUM -127 > > > LOGICAL MAXIMUM 127 > > > INPUT ( Data Variable Relative ) (6) > > > REPORT ID 23 > > > USAGE PAGE Microsoft(0xff00) > > > USAGE Unknown Usage(0xff06)[Microsoft(0xff00)] > > > LOGICAL MINIMUM 0 > > > LOGICAL MAXIMUM 1 > > > PHYSICAL MINIMUM 1 > > > PHYSICAL MAXIMUM 4 > > > REPORT COUNT 1 > > > REPORT SIZE 2 > > > FEATURE ( Data Variable Absolute ) (2) > > > PHYSICAL MINIMUM 0 > > > PHYSICAL MAXIMUM 0 > > > FEATURE ( Const Array Absolute ) (1) > > > USAGE Unknown Usage(0xff04)[Microsoft(0xff00)] > > > REPORT SIZE 1 > > > FEATURE ( Data Variable Absolute ) (2) > > > REPORT SIZE 3 > > > FEATURE ( Const Array Absolute ) (1) > > > REPORT ID 24 > > > USAGE Unknown Usage(0xff08)[Microsoft(0xff00)] > > > REPORT SIZE 1 > > > FEATURE ( Data Variable Absolute ) (2) > > > REPORT SIZE 7 > > > FEATURE ( Const Array Absolute ) (1) > > > END COLLECTION > > > END COLLECTION > > > USAGE PAGE Generic Desktop(0x1) > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > COLLECTION Application(1) > > > USAGE PAGE Generic Desktop(0x1) > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > COLLECTION Logical(2) > > > REPORT ID 17 > > > USAGE Pointer(0x1)[Generic Desktop(0x1)] > > > COLLECTION Physical(0) > > > USAGE PAGE Button(0x9) > > > USAGE MINIMUM Button1(1) > > > USAGE MAXIMUM Button3(3) > > > REPORT COUNT 3 > > > REPORT SIZE 1 > > > LOGICAL MAXIMUM 1 > > > INPUT ( Data Variable Absolute ) (2) > > > REPORT COUNT 1 > > > INPUT ( Const Array Absolute ) (1) > > > USAGE Button5(0x5)[Button(0x9)] > > > INPUT ( Data Variable Absolute ) (2) > > > REPORT COUNT 3 > > > INPUT ( Const Array Absolute ) (1) > > > USAGE PAGE Generic Desktop(0x1) > > > USAGE X(0x30)[Generic Desktop(0x1)] > > > USAGE Y(0x31)[Generic Desktop(0x1)] > > > REPORT COUNT 2 > > > REPORT SIZE 8 > > > LOGICAL MINIMUM -127 > > > LOGICAL MAXIMUM 127 > > > INPUT ( Data Variable Relative ) (6) > > > COLLECTION Logical(2) > > > REPORT ID 18 > > > USAGE Resolution Multiplier(0x48)[Generic Desktop(0x1)] > > > REPORT COUNT 1 > > > REPORT SIZE 2 > > > LOGICAL MINIMUM 0 > > > LOGICAL MAXIMUM 1 > > > PHYSICAL MINIMUM 1 > > > PHYSICAL MAXIMUM 4 > > > FEATURE ( Data Variable Absolute ) (2) > > > PHYSICAL MINIMUM 0 > > > PHYSICAL MAXIMUM 0 > > > REPORT SIZE 6 > > > FEATURE ( Const Array Absolute ) (1) > > > REPORT ID 17 > > > USAGE Wheel(0x38)[Generic Desktop(0x1)] > > > LOGICAL MINIMUM -127 > > > LOGICAL MAXIMUM 127 > > > REPORT SIZE 8 > > > INPUT ( Data Variable Relative ) (6) > > > END COLLECTION > > > USAGE PAGE Consumer(0xc) > > > REPORT SIZE 8 > > > USAGE AC Pan(0x238)[Consumer(0xc)] > > > INPUT ( Data Variable Relative ) (6) > > > END COLLECTION > > > END COLLECTION > > > END COLLECTION > > > [hexdump] > > > 0000 05 0C 09 01 A1 01 05 01 09 02 A1 02 85 13 05 0C > > > 0010 0A 38 02 95 01 75 08 15 81 25 7F 81 06 85 17 06 > > > 0020 00 FF 0A 06 FF 15 00 25 01 35 01 45 04 95 01 75 > > > 0030 02 B1 02 35 00 45 00 B1 01 0A 04 FF 75 01 B1 02 > > > 0040 75 03 B1 01 85 18 0A 08 FF 75 01 B1 02 75 07 B1 > > > 0050 01 C0 C0 05 01 09 02 A1 01 05 01 09 02 A1 02 85 > > > 0060 11 09 01 A1 00 05 09 19 01 29 03 95 03 75 01 25 > > > 0070 01 81 02 95 01 81 01 09 05 81 02 95 03 81 01 05 > > > 0080 01 09 30 09 31 95 02 75 08 15 81 25 7F 81 06 A1 > > > 0090 02 85 12 09 48 95 01 75 02 15 00 25 01 35 01 45 > > > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > > > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > > > 00C0 06 C0 C0 C0 > > > ums0: > > class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > wheel=0 > > > sc->flags=0x0000 > > > ums0: 3 buttons and a TILT dir. > > > sc->sc_loc_z.size=0 > > > ---- end of krepdump ---- > > > > > > > > > ---- diff between my report and this from > > > lists.freebsd.org/.../004617.html ---- > > > --- 1.txt 2008-08-11 19:25:56.496820730 +0200 > > > +++ dump.txt 2008-08-11 19:25:59.156847633 +0200 > > > @@ -1,7 +1,7 @@ > > > -ums1: at uhub0 port 4 (addr 4) disconnected > > > -ums1: detached > > > - > > > -[report desc size=3D196] > > > +ums0: at uhub0 port 2 (addr 2) disconnected > > > +ums0: detached > > > + > > > +[report desc size=196] > > > USAGE PAGE Consumer(0xc) > > > USAGE Consumer Control(0x1)[Consumer(0xc)] > > > COLLECTION Application(1) > > > @@ -114,6 +114,9 @@ > > > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > > > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > > > 00C0 06 C0 C0 C0 > > > -ums1: > > class 0/0, rev 2.00/1.20, addr 4> on uhub0 > > > -ums1: 3 buttons and Z dir and a TILT dir. > > > +ums0: > > class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > +wheel=0 > > > +sc->flags=0x0000 > > > +ums0: 3 buttons and a TILT dir. > > > +sc->sc_loc_z.size=0 > > > ---- end of diff ---- > > > > > > and short info: > > > > > > When I use RELENG_7_0, driver reports that my mouse have Z dir, but > > > on RELENG_7 not. > > > > The report descriptor is the same. After some experiments, I think > > the actual problem is inside our hid parser. > > > > Could you please try the patch attached against /sys/dev/usb/hid.c > > along with the debug printf patch for ums.c, and see what the result > > will be? > > > > > > kernel with appiled this two patches reports that: > > ums0: class 0/0, rev 2.00/1.20, addr 2> on uhub0 ums0: mouse has no Y report > device_attach: ums0 attach returned 6 > Sorry I made a mistake in previous patch. How about this one? --Qxx1br4bt0+wmkIi Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="hid.diff" --- /sys/dev/usb/hid.c 2007-06-20 07:10:52.000000000 +0200 +++ ./hid.c 2008-08-12 15:29:03.000000000 +0200 @@ -193,8 +193,11 @@ case 0: /* Main */ switch (bTag) { case 8: /* Input */ - if (!(s->kindset & (1 << hid_input))) + if (!(s->kindset & (1 << hid_input))) { + if (s->nu > 0) + s->nu--; continue; + } c->kind = hid_input; c->flags = dval; ret: @@ -223,8 +226,11 @@ return (1); } case 9: /* Output */ - if (!(s->kindset & (1 << hid_output))) + if (!(s->kindset & (1 << hid_output))) { + if (s->nu > 0) + s->nu--; continue; + } c->kind = hid_output; c->flags = dval; goto ret; @@ -237,8 +243,11 @@ s->nu = 0; return (1); case 11: /* Feature */ - if (!(s->kindset & (1 << hid_feature))) + if (!(s->kindset & (1 << hid_feature))) { + if (s->nu > 0) + s->nu--; continue; + } c->kind = hid_feature; c->flags = dval; goto ret; --Qxx1br4bt0+wmkIi-- From magik at back-up.pl Tue Aug 12 14:53:39 2008 From: magik at back-up.pl (Grzegorz Blach) Date: Tue Aug 12 14:53:45 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 In-Reply-To: <20080812133029.GA9576@plan0> References: <200807242330.m6ONU70T091921@freefall.freebsd.org> <5d252c1d8f1ddaed55d2467adea536ca@chi.fastbighost.com> <20080811133434.GA4224@plan0> <0ed513c9800b730fff47034b86526e5d@chi.fastbighost.com> <20080811151941.GA4590@plan0> <310aef2cb8e5bbcc7cf345f962cb102b@chi.fastbighost.com> <20080812022710.GA7527@plan0> <20080812143016.2ac5a7a4@silver.doors> <20080812133029.GA9576@plan0> Message-ID: <20080812165329.47bc22d8@silver.doors> On Tue, 12 Aug 2008 15:30:29 +0200 Kai Wang wrote: > On Tue, Aug 12, 2008 at 02:30:16PM +0200, Grzegorz Blach wrote: > > On Tue, 12 Aug 2008 04:27:10 +0200 > > Kai Wang wrote: > > > > > On Mon, Aug 11, 2008 at 01:30:57PM -0400, Grzegorz Blach wrote: > > > > On Mon, 11 Aug 2008 17:19:41 +0200, Kai Wang > > > > wrote: > > > > > On Mon, Aug 11, 2008 at 10:19:35AM -0400, Grzegorz Blach > > > > > wrote: > > > > >> > > > > >> > > > > >> On Mon, 11 Aug 2008 15:34:34 +0200, Kai Wang > > > > >> > > > > > wrote: > > > > >> > On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl > > > > >> > wrote: > > > > >> >> > > > > >> >> > > > > >> >> On Thu, 24 Jul 2008 23:30:07 GMT, > > > > >> >> FreeBSD-gnats-submit@FreeBSD.org > > > > >> > wrote: > > > > >> >> > Thank you very much for your problem report. > > > > >> >> > It has the internal identification `usb/125941'. > > > > >> >> > The individual assigned to look at your > > > > >> >> > report is: freebsd-usb. > > > > >> >> > > > > > >> >> > You can access the state of your problem report at any > > > > >> >> > time via this link: > > > > >> >> > > > > > >> >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 > > > > >> >> > > > > > >> >> >>Category: usb > > > > >> >> >>Responsible: freebsd-usb > > > > >> >> >>Synopsis: not working wheel on my microsoft > > > > >> >> >>notebook optical > > > > >> > mouse > > > > >> >> > 3000 > > > > >> >> >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 > > > > >> >> > > > > >> >> I just fixed problem with wheel on my mouse > > > > >> >> and I'm sending in attachment patch > > > > >> >> for /usr/src/sys/dev/usb/ums.c > > > > > file. > > > > >> > > > > > >> >> --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 > > > > >> >> +++ ums.c 2008-08-05 17:24:51.885277111 +0200 > > > > >> >> @@ -402,6 +402,7 @@ > > > > >> >> sc->sc_loc_x.pos = 8; > > > > >> >> sc->sc_loc_y.pos = 16; > > > > >> >> sc->sc_loc_z.pos = 24; > > > > >> >> + sc->sc_loc_z.size = 8; > > > > >> >> sc->sc_loc_btn[0].pos = 0; > > > > >> >> sc->sc_loc_btn[1].pos = 1; > > > > >> >> sc->sc_loc_btn[2].pos = 2; > > > > >> > > > > > >> > > > > > >> > Hi, > > > > >> > > > > > >> > Thanks for submitting the patch. It'd be great if you could > > > > >> > also test the patch below for us and paste the result here, > > > > >> > just for better understanding the problem. > > > > >> > > > > > >> > The patch adds some debug printfs: > > > > >> > > > > > >> > --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 > > > > >> > +0200 +++ ums.c 2008-08-11 15:25:44.000000000 +0200 > > > > >> > @@ -284,6 +284,7 @@ > > > > >> > wheel = hid_locate(desc, size, > > > > >> > HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_WHEEL), > > > > >> > hid_input, &sc->sc_loc_z, > > > > >> > &flags); > > > > >> > + printf("wheel=%d\n", wheel); > > > > >> > > > > > >> > if (wheel) { > > > > >> > if ((flags & MOUSE_FLAGS_MASK) != > > > > >> > MOUSE_FLAGS) { @@ -323,6 +324,7 @@ > > > > >> > sc->flags |= UMS_Z; > > > > >> > } > > > > >> > } > > > > >> > + printf("sc->flags=0x%04x\n", sc->flags); > > > > >> > > > > > >> > /* > > > > >> > * The Microsoft Wireless Intellimouse 2.0 reports > > > > >> > it's wheel @@ -402,6 +404,7 @@ > > > > >> > sc->sc_loc_x.pos = 8; > > > > >> > sc->sc_loc_y.pos = 16; > > > > >> > sc->sc_loc_z.pos = 24; > > > > >> > + printf("sc->sc_loc_z.size=%u\n", > > > > >> > sc->sc_loc_z.size); sc->sc_loc_btn[0].pos = 0; > > > > >> > sc->sc_loc_btn[1].pos = 1; > > > > >> > sc->sc_loc_btn[2].pos = 2; > > > > >> > > > > >> this, what I see: > > > > >> > > > > >> ums0: > > > >> Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > > >> wheel=0 > > > > >> sc->flags=0x0000 > > > > >> ums0: 3 buttons and a TILT dir. > > > > >> sc->sc_loc_z.size=0 > > > > >> > > > > > > > > > > Interesting. Now I suspect that Optical Mouse 3000 model 1049 > > > > > got different > > > > > versions. > > > > > > > > > > Could you please get krepdump > > > > > (http://people.freebsd.org/~kaiw/tools/krepdump.tgz) > > > > > > > > > > # tar xzvf krepdump.tgz > > > > > # cd krepdump > > > > > # make > > > > > # kldload ./krepdump.ko > > > > > > > > > > Then plug in your mouse and paste the result here? > > > > > > > > > > There is one version of report desc of this mouse here: > > > > > http://lists.freebsd.org/pipermail/freebsd-usb/2008-February/004617.html > > > > > > > > > > and my guess is your mouse's report desc is different than > > > > > that... > > > > > > > > > > > > > > > Thanks, > > > > > Kai > > > > > > > > ---- my krepdump ---- > > > > ums0: at uhub0 port 2 (addr 2) disconnected > > > > ums0: detached > > > > > > > > [report desc size=196] > > > > USAGE PAGE Consumer(0xc) > > > > USAGE Consumer Control(0x1)[Consumer(0xc)] > > > > COLLECTION Application(1) > > > > USAGE PAGE Generic Desktop(0x1) > > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > > COLLECTION Logical(2) > > > > REPORT ID 19 > > > > USAGE PAGE Consumer(0xc) > > > > USAGE AC Pan(0x238)[Consumer(0xc)] > > > > REPORT COUNT 1 > > > > REPORT SIZE 8 > > > > LOGICAL MINIMUM -127 > > > > LOGICAL MAXIMUM 127 > > > > INPUT ( Data Variable Relative ) (6) > > > > REPORT ID 23 > > > > USAGE PAGE Microsoft(0xff00) > > > > USAGE Unknown Usage(0xff06)[Microsoft(0xff00)] > > > > LOGICAL MINIMUM 0 > > > > LOGICAL MAXIMUM 1 > > > > PHYSICAL MINIMUM 1 > > > > PHYSICAL MAXIMUM 4 > > > > REPORT COUNT 1 > > > > REPORT SIZE 2 > > > > FEATURE ( Data Variable Absolute ) (2) > > > > PHYSICAL MINIMUM 0 > > > > PHYSICAL MAXIMUM 0 > > > > FEATURE ( Const Array Absolute ) (1) > > > > USAGE Unknown Usage(0xff04)[Microsoft(0xff00)] > > > > REPORT SIZE 1 > > > > FEATURE ( Data Variable Absolute ) (2) > > > > REPORT SIZE 3 > > > > FEATURE ( Const Array Absolute ) (1) > > > > REPORT ID 24 > > > > USAGE Unknown Usage(0xff08)[Microsoft(0xff00)] > > > > REPORT SIZE 1 > > > > FEATURE ( Data Variable Absolute ) (2) > > > > REPORT SIZE 7 > > > > FEATURE ( Const Array Absolute ) (1) > > > > END COLLECTION > > > > END COLLECTION > > > > USAGE PAGE Generic Desktop(0x1) > > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > > COLLECTION Application(1) > > > > USAGE PAGE Generic Desktop(0x1) > > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > > COLLECTION Logical(2) > > > > REPORT ID 17 > > > > USAGE Pointer(0x1)[Generic Desktop(0x1)] > > > > COLLECTION Physical(0) > > > > USAGE PAGE Button(0x9) > > > > USAGE MINIMUM Button1(1) > > > > USAGE MAXIMUM Button3(3) > > > > REPORT COUNT 3 > > > > REPORT SIZE 1 > > > > LOGICAL MAXIMUM 1 > > > > INPUT ( Data Variable Absolute ) (2) > > > > REPORT COUNT 1 > > > > INPUT ( Const Array Absolute ) (1) > > > > USAGE Button5(0x5)[Button(0x9)] > > > > INPUT ( Data Variable Absolute ) (2) > > > > REPORT COUNT 3 > > > > INPUT ( Const Array Absolute ) (1) > > > > USAGE PAGE Generic Desktop(0x1) > > > > USAGE X(0x30)[Generic Desktop(0x1)] > > > > USAGE Y(0x31)[Generic Desktop(0x1)] > > > > REPORT COUNT 2 > > > > REPORT SIZE 8 > > > > LOGICAL MINIMUM -127 > > > > LOGICAL MAXIMUM 127 > > > > INPUT ( Data Variable Relative ) (6) > > > > COLLECTION Logical(2) > > > > REPORT ID 18 > > > > USAGE Resolution Multiplier(0x48)[Generic Desktop(0x1)] > > > > REPORT COUNT 1 > > > > REPORT SIZE 2 > > > > LOGICAL MINIMUM 0 > > > > LOGICAL MAXIMUM 1 > > > > PHYSICAL MINIMUM 1 > > > > PHYSICAL MAXIMUM 4 > > > > FEATURE ( Data Variable Absolute ) (2) > > > > PHYSICAL MINIMUM 0 > > > > PHYSICAL MAXIMUM 0 > > > > REPORT SIZE 6 > > > > FEATURE ( Const Array Absolute ) (1) > > > > REPORT ID 17 > > > > USAGE Wheel(0x38)[Generic Desktop(0x1)] > > > > LOGICAL MINIMUM -127 > > > > LOGICAL MAXIMUM 127 > > > > REPORT SIZE 8 > > > > INPUT ( Data Variable Relative ) (6) > > > > END COLLECTION > > > > USAGE PAGE Consumer(0xc) > > > > REPORT SIZE 8 > > > > USAGE AC Pan(0x238)[Consumer(0xc)] > > > > INPUT ( Data Variable Relative ) (6) > > > > END COLLECTION > > > > END COLLECTION > > > > END COLLECTION > > > > [hexdump] > > > > 0000 05 0C 09 01 A1 01 05 01 09 02 A1 02 85 13 05 0C > > > > 0010 0A 38 02 95 01 75 08 15 81 25 7F 81 06 85 17 06 > > > > 0020 00 FF 0A 06 FF 15 00 25 01 35 01 45 04 95 01 75 > > > > 0030 02 B1 02 35 00 45 00 B1 01 0A 04 FF 75 01 B1 02 > > > > 0040 75 03 B1 01 85 18 0A 08 FF 75 01 B1 02 75 07 B1 > > > > 0050 01 C0 C0 05 01 09 02 A1 01 05 01 09 02 A1 02 85 > > > > 0060 11 09 01 A1 00 05 09 19 01 29 03 95 03 75 01 25 > > > > 0070 01 81 02 95 01 81 01 09 05 81 02 95 03 81 01 05 > > > > 0080 01 09 30 09 31 95 02 75 08 15 81 25 7F 81 06 A1 > > > > 0090 02 85 12 09 48 95 01 75 02 15 00 25 01 35 01 45 > > > > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > > > > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > > > > 00C0 06 C0 C0 C0 > > > > ums0: > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > > wheel=0 > > > > sc->flags=0x0000 > > > > ums0: 3 buttons and a TILT dir. > > > > sc->sc_loc_z.size=0 > > > > ---- end of krepdump ---- > > > > > > > > > > > > ---- diff between my report and this from > > > > lists.freebsd.org/.../004617.html ---- > > > > --- 1.txt 2008-08-11 19:25:56.496820730 +0200 > > > > +++ dump.txt 2008-08-11 19:25:59.156847633 +0200 > > > > @@ -1,7 +1,7 @@ > > > > -ums1: at uhub0 port 4 (addr 4) disconnected > > > > -ums1: detached > > > > - > > > > -[report desc size=3D196] > > > > +ums0: at uhub0 port 2 (addr 2) disconnected > > > > +ums0: detached > > > > + > > > > +[report desc size=196] > > > > USAGE PAGE Consumer(0xc) > > > > USAGE Consumer Control(0x1)[Consumer(0xc)] > > > > COLLECTION Application(1) > > > > @@ -114,6 +114,9 @@ > > > > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > > > > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > > > > 00C0 06 C0 C0 C0 > > > > -ums1: > > > Wheel, class 0/0, rev 2.00/1.20, addr 4> on uhub0 > > > > -ums1: 3 buttons and Z dir and a TILT dir. > > > > +ums0: > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > > +wheel=0 > > > > +sc->flags=0x0000 > > > > +ums0: 3 buttons and a TILT dir. > > > > +sc->sc_loc_z.size=0 > > > > ---- end of diff ---- > > > > > > > > and short info: > > > > > > > > When I use RELENG_7_0, driver reports that my mouse have Z dir, > > > > but on RELENG_7 not. > > > > > > The report descriptor is the same. After some experiments, I think > > > the actual problem is inside our hid parser. > > > > > > Could you please try the patch attached against /sys/dev/usb/hid.c > > > along with the debug printf patch for ums.c, and see what the > > > result will be? > > > > > > > > > > kernel with appiled this two patches reports that: > > > > ums0: > class 0/0, rev 2.00/1.20, addr 2> on uhub0 ums0: mouse has no Y > > report device_attach: ums0 attach returned 6 > > > > Sorry I made a mistake in previous patch. > > How about this one? > Again, the same message as above: ums0: on uhub0 ums0: mouse has no Y report device_attach: ums0 attach returned 6 From magik at back-up.pl Tue Aug 12 15:00:13 2008 From: magik at back-up.pl (Grzegorz Blach) Date: Tue Aug 12 15:00:20 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Message-ID: <200808121500.m7CF0DIX032730@freefall.freebsd.org> The following reply was made to PR usb/125941; it has been noted by GNATS. From: Grzegorz Blach To: Kai Wang Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: Re: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Date: Tue, 12 Aug 2008 16:53:29 +0200 On Tue, 12 Aug 2008 15:30:29 +0200 Kai Wang wrote: > On Tue, Aug 12, 2008 at 02:30:16PM +0200, Grzegorz Blach wrote: > > On Tue, 12 Aug 2008 04:27:10 +0200 > > Kai Wang wrote: > > > > > On Mon, Aug 11, 2008 at 01:30:57PM -0400, Grzegorz Blach wrote: > > > > On Mon, 11 Aug 2008 17:19:41 +0200, Kai Wang > > > > wrote: > > > > > On Mon, Aug 11, 2008 at 10:19:35AM -0400, Grzegorz Blach > > > > > wrote: > > > > >> > > > > >> > > > > >> On Mon, 11 Aug 2008 15:34:34 +0200, Kai Wang > > > > >> > > > > > wrote: > > > > >> > On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl > > > > >> > wrote: > > > > >> >> > > > > >> >> > > > > >> >> On Thu, 24 Jul 2008 23:30:07 GMT, > > > > >> >> FreeBSD-gnats-submit@FreeBSD.org > > > > >> > wrote: > > > > >> >> > Thank you very much for your problem report. > > > > >> >> > It has the internal identification `usb/125941'. > > > > >> >> > The individual assigned to look at your > > > > >> >> > report is: freebsd-usb. > > > > >> >> > > > > > >> >> > You can access the state of your problem report at any > > > > >> >> > time via this link: > > > > >> >> > > > > > >> >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 > > > > >> >> > > > > > >> >> >>Category: usb > > > > >> >> >>Responsible: freebsd-usb > > > > >> >> >>Synopsis: not working wheel on my microsoft > > > > >> >> >>notebook optical > > > > >> > mouse > > > > >> >> > 3000 > > > > >> >> >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 > > > > >> >> > > > > >> >> I just fixed problem with wheel on my mouse > > > > >> >> and I'm sending in attachment patch > > > > >> >> for /usr/src/sys/dev/usb/ums.c > > > > > file. > > > > >> > > > > > >> >> --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 > > > > >> >> +++ ums.c 2008-08-05 17:24:51.885277111 +0200 > > > > >> >> @@ -402,6 +402,7 @@ > > > > >> >> sc->sc_loc_x.pos = 8; > > > > >> >> sc->sc_loc_y.pos = 16; > > > > >> >> sc->sc_loc_z.pos = 24; > > > > >> >> + sc->sc_loc_z.size = 8; > > > > >> >> sc->sc_loc_btn[0].pos = 0; > > > > >> >> sc->sc_loc_btn[1].pos = 1; > > > > >> >> sc->sc_loc_btn[2].pos = 2; > > > > >> > > > > > >> > > > > > >> > Hi, > > > > >> > > > > > >> > Thanks for submitting the patch. It'd be great if you could > > > > >> > also test the patch below for us and paste the result here, > > > > >> > just for better understanding the problem. > > > > >> > > > > > >> > The patch adds some debug printfs: > > > > >> > > > > > >> > --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 > > > > >> > +0200 +++ ums.c 2008-08-11 15:25:44.000000000 +0200 > > > > >> > @@ -284,6 +284,7 @@ > > > > >> > wheel = hid_locate(desc, size, > > > > >> > HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_WHEEL), > > > > >> > hid_input, &sc->sc_loc_z, > > > > >> > &flags); > > > > >> > + printf("wheel=%d\n", wheel); > > > > >> > > > > > >> > if (wheel) { > > > > >> > if ((flags & MOUSE_FLAGS_MASK) != > > > > >> > MOUSE_FLAGS) { @@ -323,6 +324,7 @@ > > > > >> > sc->flags |= UMS_Z; > > > > >> > } > > > > >> > } > > > > >> > + printf("sc->flags=0x%04x\n", sc->flags); > > > > >> > > > > > >> > /* > > > > >> > * The Microsoft Wireless Intellimouse 2.0 reports > > > > >> > it's wheel @@ -402,6 +404,7 @@ > > > > >> > sc->sc_loc_x.pos = 8; > > > > >> > sc->sc_loc_y.pos = 16; > > > > >> > sc->sc_loc_z.pos = 24; > > > > >> > + printf("sc->sc_loc_z.size=%u\n", > > > > >> > sc->sc_loc_z.size); sc->sc_loc_btn[0].pos = 0; > > > > >> > sc->sc_loc_btn[1].pos = 1; > > > > >> > sc->sc_loc_btn[2].pos = 2; > > > > >> > > > > >> this, what I see: > > > > >> > > > > >> ums0: > > > >> Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > > >> wheel=0 > > > > >> sc->flags=0x0000 > > > > >> ums0: 3 buttons and a TILT dir. > > > > >> sc->sc_loc_z.size=0 > > > > >> > > > > > > > > > > Interesting. Now I suspect that Optical Mouse 3000 model 1049 > > > > > got different > > > > > versions. > > > > > > > > > > Could you please get krepdump > > > > > (http://people.freebsd.org/~kaiw/tools/krepdump.tgz) > > > > > > > > > > # tar xzvf krepdump.tgz > > > > > # cd krepdump > > > > > # make > > > > > # kldload ./krepdump.ko > > > > > > > > > > Then plug in your mouse and paste the result here? > > > > > > > > > > There is one version of report desc of this mouse here: > > > > > http://lists.freebsd.org/pipermail/freebsd-usb/2008-February/004617.html > > > > > > > > > > and my guess is your mouse's report desc is different than > > > > > that... > > > > > > > > > > > > > > > Thanks, > > > > > Kai > > > > > > > > ---- my krepdump ---- > > > > ums0: at uhub0 port 2 (addr 2) disconnected > > > > ums0: detached > > > > > > > > [report desc size=196] > > > > USAGE PAGE Consumer(0xc) > > > > USAGE Consumer Control(0x1)[Consumer(0xc)] > > > > COLLECTION Application(1) > > > > USAGE PAGE Generic Desktop(0x1) > > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > > COLLECTION Logical(2) > > > > REPORT ID 19 > > > > USAGE PAGE Consumer(0xc) > > > > USAGE AC Pan(0x238)[Consumer(0xc)] > > > > REPORT COUNT 1 > > > > REPORT SIZE 8 > > > > LOGICAL MINIMUM -127 > > > > LOGICAL MAXIMUM 127 > > > > INPUT ( Data Variable Relative ) (6) > > > > REPORT ID 23 > > > > USAGE PAGE Microsoft(0xff00) > > > > USAGE Unknown Usage(0xff06)[Microsoft(0xff00)] > > > > LOGICAL MINIMUM 0 > > > > LOGICAL MAXIMUM 1 > > > > PHYSICAL MINIMUM 1 > > > > PHYSICAL MAXIMUM 4 > > > > REPORT COUNT 1 > > > > REPORT SIZE 2 > > > > FEATURE ( Data Variable Absolute ) (2) > > > > PHYSICAL MINIMUM 0 > > > > PHYSICAL MAXIMUM 0 > > > > FEATURE ( Const Array Absolute ) (1) > > > > USAGE Unknown Usage(0xff04)[Microsoft(0xff00)] > > > > REPORT SIZE 1 > > > > FEATURE ( Data Variable Absolute ) (2) > > > > REPORT SIZE 3 > > > > FEATURE ( Const Array Absolute ) (1) > > > > REPORT ID 24 > > > > USAGE Unknown Usage(0xff08)[Microsoft(0xff00)] > > > > REPORT SIZE 1 > > > > FEATURE ( Data Variable Absolute ) (2) > > > > REPORT SIZE 7 > > > > FEATURE ( Const Array Absolute ) (1) > > > > END COLLECTION > > > > END COLLECTION > > > > USAGE PAGE Generic Desktop(0x1) > > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > > COLLECTION Application(1) > > > > USAGE PAGE Generic Desktop(0x1) > > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > > COLLECTION Logical(2) > > > > REPORT ID 17 > > > > USAGE Pointer(0x1)[Generic Desktop(0x1)] > > > > COLLECTION Physical(0) > > > > USAGE PAGE Button(0x9) > > > > USAGE MINIMUM Button1(1) > > > > USAGE MAXIMUM Button3(3) > > > > REPORT COUNT 3 > > > > REPORT SIZE 1 > > > > LOGICAL MAXIMUM 1 > > > > INPUT ( Data Variable Absolute ) (2) > > > > REPORT COUNT 1 > > > > INPUT ( Const Array Absolute ) (1) > > > > USAGE Button5(0x5)[Button(0x9)] > > > > INPUT ( Data Variable Absolute ) (2) > > > > REPORT COUNT 3 > > > > INPUT ( Const Array Absolute ) (1) > > > > USAGE PAGE Generic Desktop(0x1) > > > > USAGE X(0x30)[Generic Desktop(0x1)] > > > > USAGE Y(0x31)[Generic Desktop(0x1)] > > > > REPORT COUNT 2 > > > > REPORT SIZE 8 > > > > LOGICAL MINIMUM -127 > > > > LOGICAL MAXIMUM 127 > > > > INPUT ( Data Variable Relative ) (6) > > > > COLLECTION Logical(2) > > > > REPORT ID 18 > > > > USAGE Resolution Multiplier(0x48)[Generic Desktop(0x1)] > > > > REPORT COUNT 1 > > > > REPORT SIZE 2 > > > > LOGICAL MINIMUM 0 > > > > LOGICAL MAXIMUM 1 > > > > PHYSICAL MINIMUM 1 > > > > PHYSICAL MAXIMUM 4 > > > > FEATURE ( Data Variable Absolute ) (2) > > > > PHYSICAL MINIMUM 0 > > > > PHYSICAL MAXIMUM 0 > > > > REPORT SIZE 6 > > > > FEATURE ( Const Array Absolute ) (1) > > > > REPORT ID 17 > > > > USAGE Wheel(0x38)[Generic Desktop(0x1)] > > > > LOGICAL MINIMUM -127 > > > > LOGICAL MAXIMUM 127 > > > > REPORT SIZE 8 > > > > INPUT ( Data Variable Relative ) (6) > > > > END COLLECTION > > > > USAGE PAGE Consumer(0xc) > > > > REPORT SIZE 8 > > > > USAGE AC Pan(0x238)[Consumer(0xc)] > > > > INPUT ( Data Variable Relative ) (6) > > > > END COLLECTION > > > > END COLLECTION > > > > END COLLECTION > > > > [hexdump] > > > > 0000 05 0C 09 01 A1 01 05 01 09 02 A1 02 85 13 05 0C > > > > 0010 0A 38 02 95 01 75 08 15 81 25 7F 81 06 85 17 06 > > > > 0020 00 FF 0A 06 FF 15 00 25 01 35 01 45 04 95 01 75 > > > > 0030 02 B1 02 35 00 45 00 B1 01 0A 04 FF 75 01 B1 02 > > > > 0040 75 03 B1 01 85 18 0A 08 FF 75 01 B1 02 75 07 B1 > > > > 0050 01 C0 C0 05 01 09 02 A1 01 05 01 09 02 A1 02 85 > > > > 0060 11 09 01 A1 00 05 09 19 01 29 03 95 03 75 01 25 > > > > 0070 01 81 02 95 01 81 01 09 05 81 02 95 03 81 01 05 > > > > 0080 01 09 30 09 31 95 02 75 08 15 81 25 7F 81 06 A1 > > > > 0090 02 85 12 09 48 95 01 75 02 15 00 25 01 35 01 45 > > > > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > > > > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > > > > 00C0 06 C0 C0 C0 > > > > ums0: > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > > wheel=0 > > > > sc->flags=0x0000 > > > > ums0: 3 buttons and a TILT dir. > > > > sc->sc_loc_z.size=0 > > > > ---- end of krepdump ---- > > > > > > > > > > > > ---- diff between my report and this from > > > > lists.freebsd.org/.../004617.html ---- > > > > --- 1.txt 2008-08-11 19:25:56.496820730 +0200 > > > > +++ dump.txt 2008-08-11 19:25:59.156847633 +0200 > > > > @@ -1,7 +1,7 @@ > > > > -ums1: at uhub0 port 4 (addr 4) disconnected > > > > -ums1: detached > > > > - > > > > -[report desc size=3D196] > > > > +ums0: at uhub0 port 2 (addr 2) disconnected > > > > +ums0: detached > > > > + > > > > +[report desc size=196] > > > > USAGE PAGE Consumer(0xc) > > > > USAGE Consumer Control(0x1)[Consumer(0xc)] > > > > COLLECTION Application(1) > > > > @@ -114,6 +114,9 @@ > > > > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > > > > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > > > > 00C0 06 C0 C0 C0 > > > > -ums1: > > > Wheel, class 0/0, rev 2.00/1.20, addr 4> on uhub0 > > > > -ums1: 3 buttons and Z dir and a TILT dir. > > > > +ums0: > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > > +wheel=0 > > > > +sc->flags=0x0000 > > > > +ums0: 3 buttons and a TILT dir. > > > > +sc->sc_loc_z.size=0 > > > > ---- end of diff ---- > > > > > > > > and short info: > > > > > > > > When I use RELENG_7_0, driver reports that my mouse have Z dir, > > > > but on RELENG_7 not. > > > > > > The report descriptor is the same. After some experiments, I think > > > the actual problem is inside our hid parser. > > > > > > Could you please try the patch attached against /sys/dev/usb/hid.c > > > along with the debug printf patch for ums.c, and see what the > > > result will be? > > > > > > > > > > kernel with appiled this two patches reports that: > > > > ums0: > class 0/0, rev 2.00/1.20, addr 2> on uhub0 ums0: mouse has no Y > > report device_attach: ums0 attach returned 6 > > > > Sorry I made a mistake in previous patch. > > How about this one? > Again, the same message as above: ums0: on uhub0 ums0: mouse has no Y report device_attach: ums0 attach returned 6 From kaiwang27 at gmail.com Tue Aug 12 15:01:49 2008 From: kaiwang27 at gmail.com (Kai Wang) Date: Tue Aug 12 15:01:56 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 In-Reply-To: <20080812165329.47bc22d8@silver.doors> References: <200807242330.m6ONU70T091921@freefall.freebsd.org> <5d252c1d8f1ddaed55d2467adea536ca@chi.fastbighost.com> <20080811133434.GA4224@plan0> <0ed513c9800b730fff47034b86526e5d@chi.fastbighost.com> <20080811151941.GA4590@plan0> <310aef2cb8e5bbcc7cf345f962cb102b@chi.fastbighost.com> <20080812022710.GA7527@plan0> <20080812143016.2ac5a7a4@silver.doors> <20080812133029.GA9576@plan0> <20080812165329.47bc22d8@silver.doors> Message-ID: <20080812150139.GA9769@plan0> On Tue, Aug 12, 2008 at 04:53:29PM +0200, Grzegorz Blach wrote: > On Tue, 12 Aug 2008 15:30:29 +0200 > Kai Wang wrote: > > > On Tue, Aug 12, 2008 at 02:30:16PM +0200, Grzegorz Blach wrote: > > > On Tue, 12 Aug 2008 04:27:10 +0200 > > > Kai Wang wrote: > > > > > > > On Mon, Aug 11, 2008 at 01:30:57PM -0400, Grzegorz Blach wrote: > > > > > On Mon, 11 Aug 2008 17:19:41 +0200, Kai Wang > > > > > wrote: > > > > > > On Mon, Aug 11, 2008 at 10:19:35AM -0400, Grzegorz Blach > > > > > > wrote: > > > > > >> > > > > > >> > > > > > >> On Mon, 11 Aug 2008 15:34:34 +0200, Kai Wang > > > > > >> > > > > > > wrote: > > > > > >> > On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl > > > > > >> > wrote: > > > > > >> >> > > > > > >> >> > > > > > >> >> On Thu, 24 Jul 2008 23:30:07 GMT, > > > > > >> >> FreeBSD-gnats-submit@FreeBSD.org > > > > > >> > wrote: > > > > > >> >> > Thank you very much for your problem report. > > > > > >> >> > It has the internal identification `usb/125941'. > > > > > >> >> > The individual assigned to look at your > > > > > >> >> > report is: freebsd-usb. > > > > > >> >> > > > > > > >> >> > You can access the state of your problem report at any > > > > > >> >> > time via this link: > > > > > >> >> > > > > > > >> >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 > > > > > >> >> > > > > > > >> >> >>Category: usb > > > > > >> >> >>Responsible: freebsd-usb > > > > > >> >> >>Synopsis: not working wheel on my microsoft > > > > > >> >> >>notebook optical > > > > > >> > mouse > > > > > >> >> > 3000 > > > > > >> >> >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 > > > > > >> >> > > > > > >> >> I just fixed problem with wheel on my mouse > > > > > >> >> and I'm sending in attachment patch > > > > > >> >> for /usr/src/sys/dev/usb/ums.c > > > > > > file. > > > > > >> > > > > > > >> >> --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 > > > > > >> >> +++ ums.c 2008-08-05 17:24:51.885277111 +0200 > > > > > >> >> @@ -402,6 +402,7 @@ > > > > > >> >> sc->sc_loc_x.pos = 8; > > > > > >> >> sc->sc_loc_y.pos = 16; > > > > > >> >> sc->sc_loc_z.pos = 24; > > > > > >> >> + sc->sc_loc_z.size = 8; > > > > > >> >> sc->sc_loc_btn[0].pos = 0; > > > > > >> >> sc->sc_loc_btn[1].pos = 1; > > > > > >> >> sc->sc_loc_btn[2].pos = 2; > > > > > >> > > > > > > >> > > > > > > >> > Hi, > > > > > >> > > > > > > >> > Thanks for submitting the patch. It'd be great if you could > > > > > >> > also test the patch below for us and paste the result here, > > > > > >> > just for better understanding the problem. > > > > > >> > > > > > > >> > The patch adds some debug printfs: > > > > > >> > > > > > > >> > --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 > > > > > >> > +0200 +++ ums.c 2008-08-11 15:25:44.000000000 +0200 > > > > > >> > @@ -284,6 +284,7 @@ > > > > > >> > wheel = hid_locate(desc, size, > > > > > >> > HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_WHEEL), > > > > > >> > hid_input, &sc->sc_loc_z, > > > > > >> > &flags); > > > > > >> > + printf("wheel=%d\n", wheel); > > > > > >> > > > > > > >> > if (wheel) { > > > > > >> > if ((flags & MOUSE_FLAGS_MASK) != > > > > > >> > MOUSE_FLAGS) { @@ -323,6 +324,7 @@ > > > > > >> > sc->flags |= UMS_Z; > > > > > >> > } > > > > > >> > } > > > > > >> > + printf("sc->flags=0x%04x\n", sc->flags); > > > > > >> > > > > > > >> > /* > > > > > >> > * The Microsoft Wireless Intellimouse 2.0 reports > > > > > >> > it's wheel @@ -402,6 +404,7 @@ > > > > > >> > sc->sc_loc_x.pos = 8; > > > > > >> > sc->sc_loc_y.pos = 16; > > > > > >> > sc->sc_loc_z.pos = 24; > > > > > >> > + printf("sc->sc_loc_z.size=%u\n", > > > > > >> > sc->sc_loc_z.size); sc->sc_loc_btn[0].pos = 0; > > > > > >> > sc->sc_loc_btn[1].pos = 1; > > > > > >> > sc->sc_loc_btn[2].pos = 2; > > > > > >> > > > > > >> this, what I see: > > > > > >> > > > > > >> ums0: > > > > >> Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > > > >> wheel=0 > > > > > >> sc->flags=0x0000 > > > > > >> ums0: 3 buttons and a TILT dir. > > > > > >> sc->sc_loc_z.size=0 > > > > > >> > > > > > > > > > > > > Interesting. Now I suspect that Optical Mouse 3000 model 1049 > > > > > > got different > > > > > > versions. > > > > > > > > > > > > Could you please get krepdump > > > > > > (http://people.freebsd.org/~kaiw/tools/krepdump.tgz) > > > > > > > > > > > > # tar xzvf krepdump.tgz > > > > > > # cd krepdump > > > > > > # make > > > > > > # kldload ./krepdump.ko > > > > > > > > > > > > Then plug in your mouse and paste the result here? > > > > > > > > > > > > There is one version of report desc of this mouse here: > > > > > > http://lists.freebsd.org/pipermail/freebsd-usb/2008-February/004617.html > > > > > > > > > > > > and my guess is your mouse's report desc is different than > > > > > > that... > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Kai > > > > > > > > > > ---- my krepdump ---- > > > > > ums0: at uhub0 port 2 (addr 2) disconnected > > > > > ums0: detached > > > > > > > > > > [report desc size=196] > > > > > USAGE PAGE Consumer(0xc) > > > > > USAGE Consumer Control(0x1)[Consumer(0xc)] > > > > > COLLECTION Application(1) > > > > > USAGE PAGE Generic Desktop(0x1) > > > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > > > COLLECTION Logical(2) > > > > > REPORT ID 19 > > > > > USAGE PAGE Consumer(0xc) > > > > > USAGE AC Pan(0x238)[Consumer(0xc)] > > > > > REPORT COUNT 1 > > > > > REPORT SIZE 8 > > > > > LOGICAL MINIMUM -127 > > > > > LOGICAL MAXIMUM 127 > > > > > INPUT ( Data Variable Relative ) (6) > > > > > REPORT ID 23 > > > > > USAGE PAGE Microsoft(0xff00) > > > > > USAGE Unknown Usage(0xff06)[Microsoft(0xff00)] > > > > > LOGICAL MINIMUM 0 > > > > > LOGICAL MAXIMUM 1 > > > > > PHYSICAL MINIMUM 1 > > > > > PHYSICAL MAXIMUM 4 > > > > > REPORT COUNT 1 > > > > > REPORT SIZE 2 > > > > > FEATURE ( Data Variable Absolute ) (2) > > > > > PHYSICAL MINIMUM 0 > > > > > PHYSICAL MAXIMUM 0 > > > > > FEATURE ( Const Array Absolute ) (1) > > > > > USAGE Unknown Usage(0xff04)[Microsoft(0xff00)] > > > > > REPORT SIZE 1 > > > > > FEATURE ( Data Variable Absolute ) (2) > > > > > REPORT SIZE 3 > > > > > FEATURE ( Const Array Absolute ) (1) > > > > > REPORT ID 24 > > > > > USAGE Unknown Usage(0xff08)[Microsoft(0xff00)] > > > > > REPORT SIZE 1 > > > > > FEATURE ( Data Variable Absolute ) (2) > > > > > REPORT SIZE 7 > > > > > FEATURE ( Const Array Absolute ) (1) > > > > > END COLLECTION > > > > > END COLLECTION > > > > > USAGE PAGE Generic Desktop(0x1) > > > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > > > COLLECTION Application(1) > > > > > USAGE PAGE Generic Desktop(0x1) > > > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > > > COLLECTION Logical(2) > > > > > REPORT ID 17 > > > > > USAGE Pointer(0x1)[Generic Desktop(0x1)] > > > > > COLLECTION Physical(0) > > > > > USAGE PAGE Button(0x9) > > > > > USAGE MINIMUM Button1(1) > > > > > USAGE MAXIMUM Button3(3) > > > > > REPORT COUNT 3 > > > > > REPORT SIZE 1 > > > > > LOGICAL MAXIMUM 1 > > > > > INPUT ( Data Variable Absolute ) (2) > > > > > REPORT COUNT 1 > > > > > INPUT ( Const Array Absolute ) (1) > > > > > USAGE Button5(0x5)[Button(0x9)] > > > > > INPUT ( Data Variable Absolute ) (2) > > > > > REPORT COUNT 3 > > > > > INPUT ( Const Array Absolute ) (1) > > > > > USAGE PAGE Generic Desktop(0x1) > > > > > USAGE X(0x30)[Generic Desktop(0x1)] > > > > > USAGE Y(0x31)[Generic Desktop(0x1)] > > > > > REPORT COUNT 2 > > > > > REPORT SIZE 8 > > > > > LOGICAL MINIMUM -127 > > > > > LOGICAL MAXIMUM 127 > > > > > INPUT ( Data Variable Relative ) (6) > > > > > COLLECTION Logical(2) > > > > > REPORT ID 18 > > > > > USAGE Resolution Multiplier(0x48)[Generic Desktop(0x1)] > > > > > REPORT COUNT 1 > > > > > REPORT SIZE 2 > > > > > LOGICAL MINIMUM 0 > > > > > LOGICAL MAXIMUM 1 > > > > > PHYSICAL MINIMUM 1 > > > > > PHYSICAL MAXIMUM 4 > > > > > FEATURE ( Data Variable Absolute ) (2) > > > > > PHYSICAL MINIMUM 0 > > > > > PHYSICAL MAXIMUM 0 > > > > > REPORT SIZE 6 > > > > > FEATURE ( Const Array Absolute ) (1) > > > > > REPORT ID 17 > > > > > USAGE Wheel(0x38)[Generic Desktop(0x1)] > > > > > LOGICAL MINIMUM -127 > > > > > LOGICAL MAXIMUM 127 > > > > > REPORT SIZE 8 > > > > > INPUT ( Data Variable Relative ) (6) > > > > > END COLLECTION > > > > > USAGE PAGE Consumer(0xc) > > > > > REPORT SIZE 8 > > > > > USAGE AC Pan(0x238)[Consumer(0xc)] > > > > > INPUT ( Data Variable Relative ) (6) > > > > > END COLLECTION > > > > > END COLLECTION > > > > > END COLLECTION > > > > > [hexdump] > > > > > 0000 05 0C 09 01 A1 01 05 01 09 02 A1 02 85 13 05 0C > > > > > 0010 0A 38 02 95 01 75 08 15 81 25 7F 81 06 85 17 06 > > > > > 0020 00 FF 0A 06 FF 15 00 25 01 35 01 45 04 95 01 75 > > > > > 0030 02 B1 02 35 00 45 00 B1 01 0A 04 FF 75 01 B1 02 > > > > > 0040 75 03 B1 01 85 18 0A 08 FF 75 01 B1 02 75 07 B1 > > > > > 0050 01 C0 C0 05 01 09 02 A1 01 05 01 09 02 A1 02 85 > > > > > 0060 11 09 01 A1 00 05 09 19 01 29 03 95 03 75 01 25 > > > > > 0070 01 81 02 95 01 81 01 09 05 81 02 95 03 81 01 05 > > > > > 0080 01 09 30 09 31 95 02 75 08 15 81 25 7F 81 06 A1 > > > > > 0090 02 85 12 09 48 95 01 75 02 15 00 25 01 35 01 45 > > > > > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > > > > > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > > > > > 00C0 06 C0 C0 C0 > > > > > ums0: > > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > > > wheel=0 > > > > > sc->flags=0x0000 > > > > > ums0: 3 buttons and a TILT dir. > > > > > sc->sc_loc_z.size=0 > > > > > ---- end of krepdump ---- > > > > > > > > > > > > > > > ---- diff between my report and this from > > > > > lists.freebsd.org/.../004617.html ---- > > > > > --- 1.txt 2008-08-11 19:25:56.496820730 +0200 > > > > > +++ dump.txt 2008-08-11 19:25:59.156847633 +0200 > > > > > @@ -1,7 +1,7 @@ > > > > > -ums1: at uhub0 port 4 (addr 4) disconnected > > > > > -ums1: detached > > > > > - > > > > > -[report desc size=3D196] > > > > > +ums0: at uhub0 port 2 (addr 2) disconnected > > > > > +ums0: detached > > > > > + > > > > > +[report desc size=196] > > > > > USAGE PAGE Consumer(0xc) > > > > > USAGE Consumer Control(0x1)[Consumer(0xc)] > > > > > COLLECTION Application(1) > > > > > @@ -114,6 +114,9 @@ > > > > > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > > > > > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > > > > > 00C0 06 C0 C0 C0 > > > > > -ums1: > > > > Wheel, class 0/0, rev 2.00/1.20, addr 4> on uhub0 > > > > > -ums1: 3 buttons and Z dir and a TILT dir. > > > > > +ums0: > > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > > > +wheel=0 > > > > > +sc->flags=0x0000 > > > > > +ums0: 3 buttons and a TILT dir. > > > > > +sc->sc_loc_z.size=0 > > > > > ---- end of diff ---- > > > > > > > > > > and short info: > > > > > > > > > > When I use RELENG_7_0, driver reports that my mouse have Z dir, > > > > > but on RELENG_7 not. > > > > > > > > The report descriptor is the same. After some experiments, I think > > > > the actual problem is inside our hid parser. > > > > > > > > Could you please try the patch attached against /sys/dev/usb/hid.c > > > > along with the debug printf patch for ums.c, and see what the > > > > result will be? > > > > > > > > > > > > > > kernel with appiled this two patches reports that: > > > > > > ums0: > > class 0/0, rev 2.00/1.20, addr 2> on uhub0 ums0: mouse has no Y > > > report device_attach: ums0 attach returned 6 > > > > > > > Sorry I made a mistake in previous patch. > > > > How about this one? > > > > Again, the same message as above: > > ums0: class 0/0, rev 2.00/1.20, addr 2> on uhub0 > ums0: mouse has no Y report > device_attach: ums0 attach returned 6 Strange.. This should not happen. Did you revert previous hid.c patch before applying this one? From kaiwang27 at gmail.com Tue Aug 12 15:10:07 2008 From: kaiwang27 at gmail.com (Kai Wang) Date: Tue Aug 12 15:10:14 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Message-ID: <200808121510.m7CFA76X033188@freefall.freebsd.org> The following reply was made to PR usb/125941; it has been noted by GNATS. From: Kai Wang To: Grzegorz Blach Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: Re: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Date: Tue, 12 Aug 2008 17:01:39 +0200 On Tue, Aug 12, 2008 at 04:53:29PM +0200, Grzegorz Blach wrote: > On Tue, 12 Aug 2008 15:30:29 +0200 > Kai Wang wrote: > > > On Tue, Aug 12, 2008 at 02:30:16PM +0200, Grzegorz Blach wrote: > > > On Tue, 12 Aug 2008 04:27:10 +0200 > > > Kai Wang wrote: > > > > > > > On Mon, Aug 11, 2008 at 01:30:57PM -0400, Grzegorz Blach wrote: > > > > > On Mon, 11 Aug 2008 17:19:41 +0200, Kai Wang > > > > > wrote: > > > > > > On Mon, Aug 11, 2008 at 10:19:35AM -0400, Grzegorz Blach > > > > > > wrote: > > > > > >> > > > > > >> > > > > > >> On Mon, 11 Aug 2008 15:34:34 +0200, Kai Wang > > > > > >> > > > > > > wrote: > > > > > >> > On Tue, Aug 05, 2008 at 10:03:15AM -0400, magik@back-up.pl > > > > > >> > wrote: > > > > > >> >> > > > > > >> >> > > > > > >> >> On Thu, 24 Jul 2008 23:30:07 GMT, > > > > > >> >> FreeBSD-gnats-submit@FreeBSD.org > > > > > >> > wrote: > > > > > >> >> > Thank you very much for your problem report. > > > > > >> >> > It has the internal identification `usb/125941'. > > > > > >> >> > The individual assigned to look at your > > > > > >> >> > report is: freebsd-usb. > > > > > >> >> > > > > > > >> >> > You can access the state of your problem report at any > > > > > >> >> > time via this link: > > > > > >> >> > > > > > > >> >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 > > > > > >> >> > > > > > > >> >> >>Category: usb > > > > > >> >> >>Responsible: freebsd-usb > > > > > >> >> >>Synopsis: not working wheel on my microsoft > > > > > >> >> >>notebook optical > > > > > >> > mouse > > > > > >> >> > 3000 > > > > > >> >> >>Arrival-Date: Thu Jul 24 23:30:07 UTC 2008 > > > > > >> >> > > > > > >> >> I just fixed problem with wheel on my mouse > > > > > >> >> and I'm sending in attachment patch > > > > > >> >> for /usr/src/sys/dev/usb/ums.c > > > > > > file. > > > > > >> > > > > > > >> >> --- ums.c.orig 2008-08-05 17:24:21.815936911 +0200 > > > > > >> >> +++ ums.c 2008-08-05 17:24:51.885277111 +0200 > > > > > >> >> @@ -402,6 +402,7 @@ > > > > > >> >> sc->sc_loc_x.pos = 8; > > > > > >> >> sc->sc_loc_y.pos = 16; > > > > > >> >> sc->sc_loc_z.pos = 24; > > > > > >> >> + sc->sc_loc_z.size = 8; > > > > > >> >> sc->sc_loc_btn[0].pos = 0; > > > > > >> >> sc->sc_loc_btn[1].pos = 1; > > > > > >> >> sc->sc_loc_btn[2].pos = 2; > > > > > >> > > > > > > >> > > > > > > >> > Hi, > > > > > >> > > > > > > >> > Thanks for submitting the patch. It'd be great if you could > > > > > >> > also test the patch below for us and paste the result here, > > > > > >> > just for better understanding the problem. > > > > > >> > > > > > > >> > The patch adds some debug printfs: > > > > > >> > > > > > > >> > --- /sys/dev/usb/ums.c 2008-05-05 20:25:42.000000000 > > > > > >> > +0200 +++ ums.c 2008-08-11 15:25:44.000000000 +0200 > > > > > >> > @@ -284,6 +284,7 @@ > > > > > >> > wheel = hid_locate(desc, size, > > > > > >> > HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_WHEEL), > > > > > >> > hid_input, &sc->sc_loc_z, > > > > > >> > &flags); > > > > > >> > + printf("wheel=%d\n", wheel); > > > > > >> > > > > > > >> > if (wheel) { > > > > > >> > if ((flags & MOUSE_FLAGS_MASK) != > > > > > >> > MOUSE_FLAGS) { @@ -323,6 +324,7 @@ > > > > > >> > sc->flags |= UMS_Z; > > > > > >> > } > > > > > >> > } > > > > > >> > + printf("sc->flags=0x%04x\n", sc->flags); > > > > > >> > > > > > > >> > /* > > > > > >> > * The Microsoft Wireless Intellimouse 2.0 reports > > > > > >> > it's wheel @@ -402,6 +404,7 @@ > > > > > >> > sc->sc_loc_x.pos = 8; > > > > > >> > sc->sc_loc_y.pos = 16; > > > > > >> > sc->sc_loc_z.pos = 24; > > > > > >> > + printf("sc->sc_loc_z.size=%u\n", > > > > > >> > sc->sc_loc_z.size); sc->sc_loc_btn[0].pos = 0; > > > > > >> > sc->sc_loc_btn[1].pos = 1; > > > > > >> > sc->sc_loc_btn[2].pos = 2; > > > > > >> > > > > > >> this, what I see: > > > > > >> > > > > > >> ums0: > > > > >> Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > > > >> wheel=0 > > > > > >> sc->flags=0x0000 > > > > > >> ums0: 3 buttons and a TILT dir. > > > > > >> sc->sc_loc_z.size=0 > > > > > >> > > > > > > > > > > > > Interesting. Now I suspect that Optical Mouse 3000 model 1049 > > > > > > got different > > > > > > versions. > > > > > > > > > > > > Could you please get krepdump > > > > > > (http://people.freebsd.org/~kaiw/tools/krepdump.tgz) > > > > > > > > > > > > # tar xzvf krepdump.tgz > > > > > > # cd krepdump > > > > > > # make > > > > > > # kldload ./krepdump.ko > > > > > > > > > > > > Then plug in your mouse and paste the result here? > > > > > > > > > > > > There is one version of report desc of this mouse here: > > > > > > http://lists.freebsd.org/pipermail/freebsd-usb/2008-February/004617.html > > > > > > > > > > > > and my guess is your mouse's report desc is different than > > > > > > that... > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Kai > > > > > > > > > > ---- my krepdump ---- > > > > > ums0: at uhub0 port 2 (addr 2) disconnected > > > > > ums0: detached > > > > > > > > > > [report desc size=196] > > > > > USAGE PAGE Consumer(0xc) > > > > > USAGE Consumer Control(0x1)[Consumer(0xc)] > > > > > COLLECTION Application(1) > > > > > USAGE PAGE Generic Desktop(0x1) > > > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > > > COLLECTION Logical(2) > > > > > REPORT ID 19 > > > > > USAGE PAGE Consumer(0xc) > > > > > USAGE AC Pan(0x238)[Consumer(0xc)] > > > > > REPORT COUNT 1 > > > > > REPORT SIZE 8 > > > > > LOGICAL MINIMUM -127 > > > > > LOGICAL MAXIMUM 127 > > > > > INPUT ( Data Variable Relative ) (6) > > > > > REPORT ID 23 > > > > > USAGE PAGE Microsoft(0xff00) > > > > > USAGE Unknown Usage(0xff06)[Microsoft(0xff00)] > > > > > LOGICAL MINIMUM 0 > > > > > LOGICAL MAXIMUM 1 > > > > > PHYSICAL MINIMUM 1 > > > > > PHYSICAL MAXIMUM 4 > > > > > REPORT COUNT 1 > > > > > REPORT SIZE 2 > > > > > FEATURE ( Data Variable Absolute ) (2) > > > > > PHYSICAL MINIMUM 0 > > > > > PHYSICAL MAXIMUM 0 > > > > > FEATURE ( Const Array Absolute ) (1) > > > > > USAGE Unknown Usage(0xff04)[Microsoft(0xff00)] > > > > > REPORT SIZE 1 > > > > > FEATURE ( Data Variable Absolute ) (2) > > > > > REPORT SIZE 3 > > > > > FEATURE ( Const Array Absolute ) (1) > > > > > REPORT ID 24 > > > > > USAGE Unknown Usage(0xff08)[Microsoft(0xff00)] > > > > > REPORT SIZE 1 > > > > > FEATURE ( Data Variable Absolute ) (2) > > > > > REPORT SIZE 7 > > > > > FEATURE ( Const Array Absolute ) (1) > > > > > END COLLECTION > > > > > END COLLECTION > > > > > USAGE PAGE Generic Desktop(0x1) > > > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > > > COLLECTION Application(1) > > > > > USAGE PAGE Generic Desktop(0x1) > > > > > USAGE Mouse(0x2)[Generic Desktop(0x1)] > > > > > COLLECTION Logical(2) > > > > > REPORT ID 17 > > > > > USAGE Pointer(0x1)[Generic Desktop(0x1)] > > > > > COLLECTION Physical(0) > > > > > USAGE PAGE Button(0x9) > > > > > USAGE MINIMUM Button1(1) > > > > > USAGE MAXIMUM Button3(3) > > > > > REPORT COUNT 3 > > > > > REPORT SIZE 1 > > > > > LOGICAL MAXIMUM 1 > > > > > INPUT ( Data Variable Absolute ) (2) > > > > > REPORT COUNT 1 > > > > > INPUT ( Const Array Absolute ) (1) > > > > > USAGE Button5(0x5)[Button(0x9)] > > > > > INPUT ( Data Variable Absolute ) (2) > > > > > REPORT COUNT 3 > > > > > INPUT ( Const Array Absolute ) (1) > > > > > USAGE PAGE Generic Desktop(0x1) > > > > > USAGE X(0x30)[Generic Desktop(0x1)] > > > > > USAGE Y(0x31)[Generic Desktop(0x1)] > > > > > REPORT COUNT 2 > > > > > REPORT SIZE 8 > > > > > LOGICAL MINIMUM -127 > > > > > LOGICAL MAXIMUM 127 > > > > > INPUT ( Data Variable Relative ) (6) > > > > > COLLECTION Logical(2) > > > > > REPORT ID 18 > > > > > USAGE Resolution Multiplier(0x48)[Generic Desktop(0x1)] > > > > > REPORT COUNT 1 > > > > > REPORT SIZE 2 > > > > > LOGICAL MINIMUM 0 > > > > > LOGICAL MAXIMUM 1 > > > > > PHYSICAL MINIMUM 1 > > > > > PHYSICAL MAXIMUM 4 > > > > > FEATURE ( Data Variable Absolute ) (2) > > > > > PHYSICAL MINIMUM 0 > > > > > PHYSICAL MAXIMUM 0 > > > > > REPORT SIZE 6 > > > > > FEATURE ( Const Array Absolute ) (1) > > > > > REPORT ID 17 > > > > > USAGE Wheel(0x38)[Generic Desktop(0x1)] > > > > > LOGICAL MINIMUM -127 > > > > > LOGICAL MAXIMUM 127 > > > > > REPORT SIZE 8 > > > > > INPUT ( Data Variable Relative ) (6) > > > > > END COLLECTION > > > > > USAGE PAGE Consumer(0xc) > > > > > REPORT SIZE 8 > > > > > USAGE AC Pan(0x238)[Consumer(0xc)] > > > > > INPUT ( Data Variable Relative ) (6) > > > > > END COLLECTION > > > > > END COLLECTION > > > > > END COLLECTION > > > > > [hexdump] > > > > > 0000 05 0C 09 01 A1 01 05 01 09 02 A1 02 85 13 05 0C > > > > > 0010 0A 38 02 95 01 75 08 15 81 25 7F 81 06 85 17 06 > > > > > 0020 00 FF 0A 06 FF 15 00 25 01 35 01 45 04 95 01 75 > > > > > 0030 02 B1 02 35 00 45 00 B1 01 0A 04 FF 75 01 B1 02 > > > > > 0040 75 03 B1 01 85 18 0A 08 FF 75 01 B1 02 75 07 B1 > > > > > 0050 01 C0 C0 05 01 09 02 A1 01 05 01 09 02 A1 02 85 > > > > > 0060 11 09 01 A1 00 05 09 19 01 29 03 95 03 75 01 25 > > > > > 0070 01 81 02 95 01 81 01 09 05 81 02 95 03 81 01 05 > > > > > 0080 01 09 30 09 31 95 02 75 08 15 81 25 7F 81 06 A1 > > > > > 0090 02 85 12 09 48 95 01 75 02 15 00 25 01 35 01 45 > > > > > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > > > > > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > > > > > 00C0 06 C0 C0 C0 > > > > > ums0: > > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > > > wheel=0 > > > > > sc->flags=0x0000 > > > > > ums0: 3 buttons and a TILT dir. > > > > > sc->sc_loc_z.size=0 > > > > > ---- end of krepdump ---- > > > > > > > > > > > > > > > ---- diff between my report and this from > > > > > lists.freebsd.org/.../004617.html ---- > > > > > --- 1.txt 2008-08-11 19:25:56.496820730 +0200 > > > > > +++ dump.txt 2008-08-11 19:25:59.156847633 +0200 > > > > > @@ -1,7 +1,7 @@ > > > > > -ums1: at uhub0 port 4 (addr 4) disconnected > > > > > -ums1: detached > > > > > - > > > > > -[report desc size=3D196] > > > > > +ums0: at uhub0 port 2 (addr 2) disconnected > > > > > +ums0: detached > > > > > + > > > > > +[report desc size=196] > > > > > USAGE PAGE Consumer(0xc) > > > > > USAGE Consumer Control(0x1)[Consumer(0xc)] > > > > > COLLECTION Application(1) > > > > > @@ -114,6 +114,9 @@ > > > > > 00A0 04 B1 02 35 00 45 00 75 06 B1 01 85 11 09 38 15 > > > > > 00B0 81 25 7F 75 08 81 06 C0 05 0C 75 08 0A 38 02 81 > > > > > 00C0 06 C0 C0 C0 > > > > > -ums1: > > > > Wheel, class 0/0, rev 2.00/1.20, addr 4> on uhub0 > > > > > -ums1: 3 buttons and Z dir and a TILT dir. > > > > > +ums0: > > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > > > +wheel=0 > > > > > +sc->flags=0x0000 > > > > > +ums0: 3 buttons and a TILT dir. > > > > > +sc->sc_loc_z.size=0 > > > > > ---- end of diff ---- > > > > > > > > > > and short info: > > > > > > > > > > When I use RELENG_7_0, driver reports that my mouse have Z dir, > > > > > but on RELENG_7 not. > > > > > > > > The report descriptor is the same. After some experiments, I think > > > > the actual problem is inside our hid parser. > > > > > > > > Could you please try the patch attached against /sys/dev/usb/hid.c > > > > along with the debug printf patch for ums.c, and see what the > > > > result will be? > > > > > > > > > > > > > > kernel with appiled this two patches reports that: > > > > > > ums0: > > class 0/0, rev 2.00/1.20, addr 2> on uhub0 ums0: mouse has no Y > > > report device_attach: ums0 attach returned 6 > > > > > > > Sorry I made a mistake in previous patch. > > > > How about this one? > > > > Again, the same message as above: > > ums0: class 0/0, rev 2.00/1.20, addr 2> on uhub0 > ums0: mouse has no Y report > device_attach: ums0 attach returned 6 Strange.. This should not happen. Did you revert previous hid.c patch before applying this one? From magik at back-up.pl Tue Aug 12 16:17:51 2008 From: magik at back-up.pl (Grzegorz Blach) Date: Tue Aug 12 16:17:57 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 In-Reply-To: <20080812150139.GA9769@plan0> References: <200807242330.m6ONU70T091921@freefall.freebsd.org> <5d252c1d8f1ddaed55d2467adea536ca@chi.fastbighost.com> <20080811133434.GA4224@plan0> <0ed513c9800b730fff47034b86526e5d@chi.fastbighost.com> <20080811151941.GA4590@plan0> <310aef2cb8e5bbcc7cf345f962cb102b@chi.fastbighost.com> <20080812022710.GA7527@plan0> <20080812143016.2ac5a7a4@silver.doors> <20080812133029.GA9576@plan0> <20080812165329.47bc22d8@silver.doors> <20080812150139.GA9769@plan0> Message-ID: <20080812181744.5b7be17c@silver.doors> On Tue, 12 Aug 2008 17:01:39 +0200 Kai Wang wrote: > > > > > Could you please try the patch attached > > > > > against /sys/dev/usb/hid.c along with the debug printf patch > > > > > for ums.c, and see what the result will be? > > > > > > > > > > > > > > > > > > kernel with appiled this two patches reports that: > > > > > > > > ums0: > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 ums0: mouse > > > > has no Y report device_attach: ums0 attach returned 6 > > > > > > > > > > Sorry I made a mistake in previous patch. > > > > > > How about this one? > > > > > > > Again, the same message as above: > > > > ums0: > class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > ums0: mouse has no Y report > > device_attach: ums0 attach returned 6 > > Strange.. This should not happen. Did you revert previous hid.c > patch before applying this one? OK, I have updated source from cvs, then appiled hid.diff and rebuild kernel, when kernel boot I see: ums0: on uhub0 wheel=1 sc->flags=0x0001 ums0: 3 buttons and Z dir. sc->sc_loc_z.size=8 Wheel is working correctly, but I don't have info about TILT dir (but I never used this direction). From magik at back-up.pl Tue Aug 12 16:20:03 2008 From: magik at back-up.pl (Grzegorz Blach) Date: Tue Aug 12 16:20:10 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Message-ID: <200808121620.m7CGK3Ar040323@freefall.freebsd.org> The following reply was made to PR usb/125941; it has been noted by GNATS. From: Grzegorz Blach To: Kai Wang Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: Re: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Date: Tue, 12 Aug 2008 18:17:44 +0200 On Tue, 12 Aug 2008 17:01:39 +0200 Kai Wang wrote: > > > > > Could you please try the patch attached > > > > > against /sys/dev/usb/hid.c along with the debug printf patch > > > > > for ums.c, and see what the result will be? > > > > > > > > > > > > > > > > > > kernel with appiled this two patches reports that: > > > > > > > > ums0: > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 ums0: mouse > > > > has no Y report device_attach: ums0 attach returned 6 > > > > > > > > > > Sorry I made a mistake in previous patch. > > > > > > How about this one? > > > > > > > Again, the same message as above: > > > > ums0: > class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > ums0: mouse has no Y report > > device_attach: ums0 attach returned 6 > > Strange.. This should not happen. Did you revert previous hid.c > patch before applying this one? OK, I have updated source from cvs, then appiled hid.diff and rebuild kernel, when kernel boot I see: ums0: on uhub0 wheel=1 sc->flags=0x0001 ums0: 3 buttons and Z dir. sc->sc_loc_z.size=8 Wheel is working correctly, but I don't have info about TILT dir (but I never used this direction). From kaiwang27 at gmail.com Tue Aug 12 16:42:32 2008 From: kaiwang27 at gmail.com (Kai Wang) Date: Tue Aug 12 16:42:39 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 In-Reply-To: <20080812181744.5b7be17c@silver.doors> References: <20080811133434.GA4224@plan0> <0ed513c9800b730fff47034b86526e5d@chi.fastbighost.com> <20080811151941.GA4590@plan0> <310aef2cb8e5bbcc7cf345f962cb102b@chi.fastbighost.com> <20080812022710.GA7527@plan0> <20080812143016.2ac5a7a4@silver.doors> <20080812133029.GA9576@plan0> <20080812165329.47bc22d8@silver.doors> <20080812150139.GA9769@plan0> <20080812181744.5b7be17c@silver.doors> Message-ID: <20080812164224.GA9967@plan0> On Tue, Aug 12, 2008 at 06:17:44PM +0200, Grzegorz Blach wrote: > On Tue, 12 Aug 2008 17:01:39 +0200 > Kai Wang wrote: > > > > > > > Could you please try the patch attached > > > > > > against /sys/dev/usb/hid.c along with the debug printf patch > > > > > > for ums.c, and see what the result will be? > > > > > > > > > > > > > > > > > > > > > > kernel with appiled this two patches reports that: > > > > > > > > > > ums0: > > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 ums0: mouse > > > > > has no Y report device_attach: ums0 attach returned 6 > > > > > > > > > > > > > Sorry I made a mistake in previous patch. > > > > > > > > How about this one? > > > > > > > > > > Again, the same message as above: > > > > > > ums0: > > class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > ums0: mouse has no Y report > > > device_attach: ums0 attach returned 6 > > > > Strange.. This should not happen. Did you revert previous hid.c > > patch before applying this one? > > OK, I have updated source from cvs, then appiled hid.diff and rebuild > kernel, when kernel boot I see: > > ums0: class 0/0, rev 2.00/1.20, addr 2> on uhub0 wheel=1 > sc->flags=0x0001 > ums0: 3 buttons and Z dir. > sc->sc_loc_z.size=8 Great! Thank you again for testing all these stuff. > Wheel is working correctly, but I don't have info about TILT dir (but > I never used this direction). It was wrong that ums(4) reported the mouse has "a TILT dir" before. The TWHEEL(0x48) usage inside the report desc of this mouse is a FEATURE item, while the Microsoft Wireless Intellimouse 2.0 quirk (the hid_locate call around line 334) tries to find a TWHEEL usage with a INPUT item, because of the hid parser bug, it will mistakenly find the next INPUT item, (which is the WHEEL input item) and report the "TILT dir". From kaiwang27 at gmail.com Tue Aug 12 16:50:05 2008 From: kaiwang27 at gmail.com (Kai Wang) Date: Tue Aug 12 16:50:14 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Message-ID: <200808121650.m7CGo5Vp043184@freefall.freebsd.org> The following reply was made to PR usb/125941; it has been noted by GNATS. From: Kai Wang To: Grzegorz Blach Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: Re: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Date: Tue, 12 Aug 2008 18:42:24 +0200 On Tue, Aug 12, 2008 at 06:17:44PM +0200, Grzegorz Blach wrote: > On Tue, 12 Aug 2008 17:01:39 +0200 > Kai Wang wrote: > > > > > > > Could you please try the patch attached > > > > > > against /sys/dev/usb/hid.c along with the debug printf patch > > > > > > for ums.c, and see what the result will be? > > > > > > > > > > > > > > > > > > > > > > kernel with appiled this two patches reports that: > > > > > > > > > > ums0: > > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 ums0: mouse > > > > > has no Y report device_attach: ums0 attach returned 6 > > > > > > > > > > > > > Sorry I made a mistake in previous patch. > > > > > > > > How about this one? > > > > > > > > > > Again, the same message as above: > > > > > > ums0: > > class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > ums0: mouse has no Y report > > > device_attach: ums0 attach returned 6 > > > > Strange.. This should not happen. Did you revert previous hid.c > > patch before applying this one? > > OK, I have updated source from cvs, then appiled hid.diff and rebuild > kernel, when kernel boot I see: > > ums0: class 0/0, rev 2.00/1.20, addr 2> on uhub0 wheel=1 > sc->flags=0x0001 > ums0: 3 buttons and Z dir. > sc->sc_loc_z.size=8 Great! Thank you again for testing all these stuff. > Wheel is working correctly, but I don't have info about TILT dir (but > I never used this direction). It was wrong that ums(4) reported the mouse has "a TILT dir" before. The TWHEEL(0x48) usage inside the report desc of this mouse is a FEATURE item, while the Microsoft Wireless Intellimouse 2.0 quirk (the hid_locate call around line 334) tries to find a TWHEEL usage with a INPUT item, because of the hid parser bug, it will mistakenly find the next INPUT item, (which is the WHEEL input item) and report the "TILT dir". From magik at back-up.pl Tue Aug 12 17:01:44 2008 From: magik at back-up.pl (Grzegorz Blach) Date: Tue Aug 12 17:01:51 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 In-Reply-To: <20080812164224.GA9967@plan0> References: <20080811133434.GA4224@plan0> <0ed513c9800b730fff47034b86526e5d@chi.fastbighost.com> <20080811151941.GA4590@plan0> <310aef2cb8e5bbcc7cf345f962cb102b@chi.fastbighost.com> <20080812022710.GA7527@plan0> <20080812143016.2ac5a7a4@silver.doors> <20080812133029.GA9576@plan0> <20080812165329.47bc22d8@silver.doors> <20080812150139.GA9769@plan0> <20080812181744.5b7be17c@silver.doors> <20080812164224.GA9967@plan0> Message-ID: <20080812190137.62dba989@silver.doors> On Tue, 12 Aug 2008 18:42:24 +0200 Kai Wang wrote: > On Tue, Aug 12, 2008 at 06:17:44PM +0200, Grzegorz Blach wrote: > > On Tue, 12 Aug 2008 17:01:39 +0200 > > Kai Wang wrote: > > > > > > > > > Could you please try the patch attached > > > > > > > against /sys/dev/usb/hid.c along with the debug printf > > > > > > > patch for ums.c, and see what the result will be? > > > > > > > > > > > > > > > > > > > > > > > > > > kernel with appiled this two patches reports that: > > > > > > > > > > > > ums0: > > > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 ums0: > > > > > > mouse has no Y report device_attach: ums0 attach returned 6 > > > > > > > > > > > > > > > > Sorry I made a mistake in previous patch. > > > > > > > > > > How about this one? > > > > > > > > > > > > > Again, the same message as above: > > > > > > > > ums0: > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > > ums0: mouse has no Y report > > > > device_attach: ums0 attach returned 6 > > > > > > Strange.. This should not happen. Did you revert previous hid.c > > > patch before applying this one? > > > > OK, I have updated source from cvs, then appiled hid.diff and > > rebuild kernel, when kernel boot I see: > > > > ums0: > class 0/0, rev 2.00/1.20, addr 2> on uhub0 wheel=1 > > sc->flags=0x0001 > > ums0: 3 buttons and Z dir. > > sc->sc_loc_z.size=8 > > Great! Thank you again for testing all these stuff. > > > Wheel is working correctly, but I don't have info about TILT dir > > (but I never used this direction). > > It was wrong that ums(4) reported the mouse has "a TILT dir" before. > The TWHEEL(0x48) usage inside the report desc of this mouse is a > FEATURE item, while the Microsoft Wireless Intellimouse 2.0 quirk > (the hid_locate call around line 334) tries to find a TWHEEL usage > with a INPUT item, because of the hid parser bug, it will mistakenly > find the next INPUT item, (which is the WHEEL input item) and report > the "TILT dir". > > I don't understand: Is TILT dir working when it isn't reported. Microsoft notebook optical 3000 and Microsoft wireless intellimouse 2.0, both support TITL dir. In documentation this is mentioned as "4-way scrolling with tilt wheel technology". From magik at back-up.pl Tue Aug 12 17:10:06 2008 From: magik at back-up.pl (Grzegorz Blach) Date: Tue Aug 12 17:10:13 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Message-ID: <200808121710.m7CHA51p043973@freefall.freebsd.org> The following reply was made to PR usb/125941; it has been noted by GNATS. From: Grzegorz Blach To: Kai Wang Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: Re: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Date: Tue, 12 Aug 2008 19:01:37 +0200 On Tue, 12 Aug 2008 18:42:24 +0200 Kai Wang wrote: > On Tue, Aug 12, 2008 at 06:17:44PM +0200, Grzegorz Blach wrote: > > On Tue, 12 Aug 2008 17:01:39 +0200 > > Kai Wang wrote: > > > > > > > > > Could you please try the patch attached > > > > > > > against /sys/dev/usb/hid.c along with the debug printf > > > > > > > patch for ums.c, and see what the result will be? > > > > > > > > > > > > > > > > > > > > > > > > > > kernel with appiled this two patches reports that: > > > > > > > > > > > > ums0: > > > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 ums0: > > > > > > mouse has no Y report device_attach: ums0 attach returned 6 > > > > > > > > > > > > > > > > Sorry I made a mistake in previous patch. > > > > > > > > > > How about this one? > > > > > > > > > > > > > Again, the same message as above: > > > > > > > > ums0: > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > > ums0: mouse has no Y report > > > > device_attach: ums0 attach returned 6 > > > > > > Strange.. This should not happen. Did you revert previous hid.c > > > patch before applying this one? > > > > OK, I have updated source from cvs, then appiled hid.diff and > > rebuild kernel, when kernel boot I see: > > > > ums0: > class 0/0, rev 2.00/1.20, addr 2> on uhub0 wheel=1 > > sc->flags=0x0001 > > ums0: 3 buttons and Z dir. > > sc->sc_loc_z.size=8 > > Great! Thank you again for testing all these stuff. > > > Wheel is working correctly, but I don't have info about TILT dir > > (but I never used this direction). > > It was wrong that ums(4) reported the mouse has "a TILT dir" before. > The TWHEEL(0x48) usage inside the report desc of this mouse is a > FEATURE item, while the Microsoft Wireless Intellimouse 2.0 quirk > (the hid_locate call around line 334) tries to find a TWHEEL usage > with a INPUT item, because of the hid parser bug, it will mistakenly > find the next INPUT item, (which is the WHEEL input item) and report > the "TILT dir". > > I don't understand: Is TILT dir working when it isn't reported. Microsoft notebook optical 3000 and Microsoft wireless intellimouse 2.0, both support TITL dir. In documentation this is mentioned as "4-way scrolling with tilt wheel technology". From kaiwang27 at gmail.com Tue Aug 12 17:18:53 2008 From: kaiwang27 at gmail.com (Kai Wang) Date: Tue Aug 12 17:19:00 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 In-Reply-To: <20080812190137.62dba989@silver.doors> References: <20080811151941.GA4590@plan0> <310aef2cb8e5bbcc7cf345f962cb102b@chi.fastbighost.com> <20080812022710.GA7527@plan0> <20080812143016.2ac5a7a4@silver.doors> <20080812133029.GA9576@plan0> <20080812165329.47bc22d8@silver.doors> <20080812150139.GA9769@plan0> <20080812181744.5b7be17c@silver.doors> <20080812164224.GA9967@plan0> <20080812190137.62dba989@silver.doors> Message-ID: <20080812171844.GA10473@plan0> On Tue, Aug 12, 2008 at 07:01:37PM +0200, Grzegorz Blach wrote: > On Tue, 12 Aug 2008 18:42:24 +0200 > Kai Wang wrote: > > > On Tue, Aug 12, 2008 at 06:17:44PM +0200, Grzegorz Blach wrote: > > > On Tue, 12 Aug 2008 17:01:39 +0200 > > > Kai Wang wrote: > > > > > > > > > > > Could you please try the patch attached > > > > > > > > against /sys/dev/usb/hid.c along with the debug printf > > > > > > > > patch for ums.c, and see what the result will be? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > kernel with appiled this two patches reports that: > > > > > > > > > > > > > > ums0: > > > > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 ums0: > > > > > > > mouse has no Y report device_attach: ums0 attach returned 6 > > > > > > > > > > > > > > > > > > > Sorry I made a mistake in previous patch. > > > > > > > > > > > > How about this one? > > > > > > > > > > > > > > > > Again, the same message as above: > > > > > > > > > > ums0: > > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > > > ums0: mouse has no Y report > > > > > device_attach: ums0 attach returned 6 > > > > > > > > Strange.. This should not happen. Did you revert previous hid.c > > > > patch before applying this one? > > > > > > OK, I have updated source from cvs, then appiled hid.diff and > > > rebuild kernel, when kernel boot I see: > > > > > > ums0: > > class 0/0, rev 2.00/1.20, addr 2> on uhub0 wheel=1 > > > sc->flags=0x0001 > > > ums0: 3 buttons and Z dir. > > > sc->sc_loc_z.size=8 > > > > Great! Thank you again for testing all these stuff. > > > > > Wheel is working correctly, but I don't have info about TILT dir > > > (but I never used this direction). > > > > It was wrong that ums(4) reported the mouse has "a TILT dir" before. > > The TWHEEL(0x48) usage inside the report desc of this mouse is a > > FEATURE item, while the Microsoft Wireless Intellimouse 2.0 quirk > > (the hid_locate call around line 334) tries to find a TWHEEL usage > > with a INPUT item, because of the hid parser bug, it will mistakenly > > find the next INPUT item, (which is the WHEEL input item) and report > > the "TILT dir". > > > > > > I don't understand: > > Is TILT dir working when it isn't reported. > > Microsoft notebook optical 3000 > and Microsoft wireless intellimouse > 2.0, both support TITL dir. > > In documentation this is mentioned as "4-way scrolling with tilt wheel > technology". I don't know if ums(4) support the TITL dir of this mouse, I guess not. It just falsely reports it before patching. You could try to use TITL wheel with and without patching, see if there is a difference. Thanks, Kai From kaiwang27 at gmail.com Tue Aug 12 17:20:06 2008 From: kaiwang27 at gmail.com (Kai Wang) Date: Tue Aug 12 17:20:13 2008 Subject: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Message-ID: <200808121720.m7CHK5ev046464@freefall.freebsd.org> The following reply was made to PR usb/125941; it has been noted by GNATS. From: Kai Wang To: Grzegorz Blach Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-usb@FreeBSD.org Subject: Re: usb/125941: not working wheel on my microsoft notebook optical mouse 3000 Date: Tue, 12 Aug 2008 19:18:44 +0200 On Tue, Aug 12, 2008 at 07:01:37PM +0200, Grzegorz Blach wrote: > On Tue, 12 Aug 2008 18:42:24 +0200 > Kai Wang wrote: > > > On Tue, Aug 12, 2008 at 06:17:44PM +0200, Grzegorz Blach wrote: > > > On Tue, 12 Aug 2008 17:01:39 +0200 > > > Kai Wang wrote: > > > > > > > > > > > Could you please try the patch attached > > > > > > > > against /sys/dev/usb/hid.c along with the debug printf > > > > > > > > patch for ums.c, and see what the result will be? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > kernel with appiled this two patches reports that: > > > > > > > > > > > > > > ums0: > > > > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 ums0: > > > > > > > mouse has no Y report device_attach: ums0 attach returned 6 > > > > > > > > > > > > > > > > > > > Sorry I made a mistake in previous patch. > > > > > > > > > > > > How about this one? > > > > > > > > > > > > > > > > Again, the same message as above: > > > > > > > > > > ums0: > > > > Wheel, class 0/0, rev 2.00/1.20, addr 2> on uhub0 > > > > > ums0: mouse has no Y report > > > > > device_attach: ums0 attach returned 6 > > > > > > > > Strange.. This should not happen. Did you revert previous hid.c > > > > patch before applying this one? > > > > > > OK, I have updated source from cvs, then appiled hid.diff and > > > rebuild kernel, when kernel boot I see: > > > > > > ums0: > > class 0/0, rev 2.00/1.20, addr 2> on uhub0 wheel=1 > > > sc->flags=0x0001 > > > ums0: 3 buttons and Z dir. > > > sc->sc_loc_z.size=8 > > > > Great! Thank you again for testing all these stuff. > > > > > Wheel is working correctly, but I don't have info about TILT dir > > > (but I never used this direction). > > > > It was wrong that ums(4) reported the mouse has "a TILT dir" before. > > The TWHEEL(0x48) usage inside the report desc of this mouse is a > > FEATURE item, while the Microsoft Wireless Intellimouse 2.0 quirk > > (the hid_locate call around line 334) tries to find a TWHEEL usage > > with a INPUT item, because of the hid parser bug, it will mistakenly > > find the next INPUT item, (which is the WHEEL input item) and report > > the "TILT dir". > > > > > > I don't understand: > > Is TILT dir working when it isn't reported. > > Microsoft notebook optical 3000 > and Microsoft wireless intellimouse > 2.0, both support TITL dir. > > In documentation this is mentioned as "4-way scrolling with tilt wheel > technology". I don't know if ums(4) support the TITL dir of this mouse, I guess not. It just falsely reports it before patching. You could try to use TITL wheel with and without patching, see if there is a difference. Thanks, Kai From dfilter at FreeBSD.ORG Wed Aug 13 12:50:03 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Wed Aug 13 12:50:09 2008 Subject: usb/96599: commit references a PR Message-ID: <200808131250.m7DCo3JD082948@freefall.freebsd.org> The following reply was made to PR usb/96599; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: usb/96599: commit references a PR Date: Wed, 13 Aug 2008 12:40:35 +0000 (UTC) maxim 2008-08-13 12:40:20 UTC FreeBSD src repository Modified files: sys/dev/usb umass.c Log: SVN rev 181685 on 2008-08-13 12:40:20Z by maxim o Add a quirk for Sony Handycam DCR-HC32E. PR: usb/96599 Submitted by: Eugene Grosbein MFC after: 1 week Revision Changes Path 1.164 +4 -0 src/sys/dev/usb/umass.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From tut at nhamon.com.ua Wed Aug 13 15:40:05 2008 From: tut at nhamon.com.ua (Artem Naluzhnyy) Date: Wed Aug 13 15:40:10 2008 Subject: usb/117205: [patch] uscanner support for HP ScanJet 4470c Message-ID: <200808131540.m7DFe410097966@freefall.freebsd.org> The following reply was made to PR usb/117205; it has been noted by GNATS. From: "Artem Naluzhnyy" To: bug-followup@FreeBSD.org Cc: Subject: Re: usb/117205: [patch] uscanner support for HP ScanJet 4470c Date: Wed, 13 Aug 2008 18:04:30 +0300 You may actually close the PR since there is no working backend for the scanner anyway. So it isn't supported by FreeBSD. -- Artem Naluzhnyy From avg at icyb.net.ua Wed Aug 13 16:05:18 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Aug 13 16:05:30 2008 Subject: tilt/horizontal scroll support Message-ID: <48A300B9.5090105@icyb.net.ua> I have the following mouse: http://www.logitech.com/index.cfm/partners/system_builders_integrators/products/mice/devices/3141&cl=gb,en# It has "Tilt Wheel Plus Zoom? technology", i.e. its scroll wheel can be tilted left and right. Currently it perfectly works as 3 buttons + wheel mouse, but tilting action does not cause any effect (in xev). This is some debug output from ums driver: ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/27.20, addr 2, iclass 3/1 ums0: 8 buttons and Z dir. ums_attach: sc=0xffffff004d747400 ums_attach: X 8/8 ums_attach: Y 16/8 ums_attach: Z 24/8 ums_attach: B1 0/1 ums_attach: B2 1/1 ums_attach: B3 2/1 ums_attach: B4 3/1 ums_attach: B5 4/1 ums_attach: B6 5/1 ums_attach: B7 6/1 ums_attach: B8 7/1 Here's how "normal"/vertical scrolling of the wheel is reported by ums (one scroll forward and one scroll backward): ums_intr: sc=0xffffff006b502400 status=0 ums_intr: data = 00 00 00 ff 00 ums_intr: x:0 y:0 z:1 t:0 buttons:0x0 ums_intr: sc=0xffffff006b502400 status=0 ums_intr: data = 00 00 00 01 00 ums_intr: x:0 y:0 z:-1 t:0 buttons:0x0 As expected value in the 4th byte (data[3]) is interpreted as z-axis movement (and seems to always be +1/-1). Here's how tilting of the wheel is reported (tilted the wheel, held it for some time and then released): ums_intr: sc=0xffffff004d747400 status=0 ums_intr: data = 00 00 00 00 01 ums_intr: x:0 y:0 z:0 t:0 buttons:0x0 ums_intr: sc=0xffffff004d747400 status=0 ums_intr: data = 00 00 00 00 01 ums_intr: x:0 y:0 z:0 t:0 buttons:0x0 ums_intr: sc=0xffffff004d747400 status=0 ums_intr: data = 00 00 00 00 01 ums_intr: x:0 y:0 z:0 t:0 buttons:0x0 ums_intr: sc=0xffffff004d747400 status=0 ums_intr: data = 00 00 00 00 00 ums_intr: x:0 y:0 z:0 t:0 buttons:0x0 It seems that tilting is reported by value in the 5th byte (data[4]), it has hardware "auto-repeat" and end of tilting is reported by all-zeroes data. Currently, it seems, data[4] is completely ignored. I would like to get tilting to work as horizontal scrolling in X, using SysMouse protocol. As I understand currently our sysmouse(4) protocol doesn't provide for tilting data (there is no field for it in the packet structure), and Xorg sysmouse driver does not have any support for tilting either. So now I have two questions. 1. What would be the best way to each ums about the tilt capability of this mouse? Is there some generic way to detect it or maybe logitech-specific way or some model-specific quirk is required? 2. What would be the best way to pass tilting data to consumers? I see two possibilities: A) map data[4] to some extended button value (do it in ums driver), e.g. to button 6 and button 7; B) it seems that dz value is always 1 or -1, amount of scrolling affects number of mouse events, but abs(dz) is always 1; if this is really always true, then tilting could be piggy-backed onto dz as +2/-2 value (or some such) and then Xorg sysmouse driver could be taught to interpret such values as special button presses (similarly to how vertical scrolling is handled in it). Thank you in advance for advices and opinions. -- Andriy Gapon From rpaulo at FreeBSD.org Wed Aug 13 16:55:16 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Wed Aug 13 16:55:22 2008 Subject: tilt/horizontal scroll support In-Reply-To: <48A300B9.5090105@icyb.net.ua> References: <48A300B9.5090105@icyb.net.ua> Message-ID: <20080813162931.GC718@epsilon.local> On Wed, Aug 13, 2008 at 06:41:45PM +0300, Andriy Gapon wrote: > > I have the following mouse: > http://www.logitech.com/index.cfm/partners/system_builders_integrators/products/mice/devices/3141&cl=gb,en# ... > So now I have two questions. > 1. What would be the best way to each ums about the tilt capability of > this mouse? Is there some generic way to detect it or maybe > logitech-specific way or some model-specific quirk is required? > > 2. What would be the best way to pass tilting data to consumers? > I see two possibilities: > A) map data[4] to some extended button value (do it in ums driver), e.g. > to button 6 and button 7; > B) it seems that dz value is always 1 or -1, amount of scrolling affects > number of mouse events, but abs(dz) is always 1; if this is really > always true, then tilting could be piggy-backed onto dz as +2/-2 value > (or some such) and then Xorg sysmouse driver could be taught to > interpret such values as special button presses (similarly to how > vertical scrolling is handled in it). Well, perhaps the best way is to teach sysmouse about horizontal scrolling and then add a quirk WRT your mouse ? sysmouse(4) really needs to grow horizontal scrolling since nowadays every mouse has it. Regards, -- Rui Paulo From okrg at ukr.net Thu Aug 14 07:00:06 2008 From: okrg at ukr.net (Oleksii Krykun) Date: Thu Aug 14 07:00:12 2008 Subject: usb/122992: MotoROKR Z6 Phone not recognised by umass as USB disk. Message-ID: <200808140700.m7E705Se009001@freefall.freebsd.org> The following reply was made to PR usb/122992; it has been noted by GNATS. From: "Oleksii Krykun" To: bug-followup@FreeBSD.org,gemellus@sdf.lonestar.org Cc: Subject: Re: usb/122992: MotoROKR Z6 Phone not recognised by umass as USB disk. Date: Thu, 14 Aug 2008 09:56:32 +0300 This bug also described in http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-03/msg04505.html I tried to apply quirks: --- usbdevs.orig 2008-01-08 01:12:45.000000000 +0200 +++ usbdevs 2008-07-30 13:55:59.000000000 +0300 @@ -1695,6 +1695,7 @@ product MOTOROLA2 E398 0x4810 E398 Mobile Phone product MOTOROLA2 USBLAN 0x600c USBLAN product MOTOROLA2 USBLAN2 0x6027 USBLAN +product MOTOROLA2 MS 0x6426 MS /* MultiTech products */ product MULTITECH ATLAS 0xf101 MT5634ZBA-USB modem --- umass.c.orig 2007-07-05 08:26:08.000000000 +0300 +++ umass.c 2008-08-06 15:00:00.000000000 +0300 @@ -544,6 +544,10 @@ UMASS_PROTO_SCSI | UMASS_PROTO_BBB, FORCE_SHORT_INQUIRY | NO_INQUIRY_EVPD | NO_GETMAXLUN }, + { USB_VENDOR_MOTOROLA2, USB_PRODUCT_MOTOROLA2_MS, RID_WILDCARD, + UMASS_PROTO_SCSI | UMASS_PROTO_BBB, + NO_INQUIRY | READ_CAPACITY_OFFBY1 + }, { USB_VENDOR_MSYSTEMS, USB_PRODUCT_MSYSTEMS_DISKONKEY, RID_WILDCARD, UMASS_PROTO_SCSI | UMASS_PROTO_BBB, IGNORE_RESIDUE | NO_GETMAXLUN | RS_NO_CLEAR_UA I get following messages: Aug 6 15:51:26 kws kernel: pass1 at umass-sim0 bus 0 target 0 lun 1 Aug 6 15:51:26 kws kernel: (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR Aug 6 15:51:26 kws kernel: (da0:umass-sim0:0:0:0): Retrying Command Aug 6 15:51:26 kws kernel: (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR Aug 6 15:51:26 kws kernel: (da0:umass-sim0:0:0:0): Retrying Command Aug 6 15:51:26 kws kernel: (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR Aug 6 15:51:26 kws kernel: (da0:umass-sim0:0:0:0): Retrying Command Aug 6 15:51:26 kws kernel: (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR Aug 6 15:51:26 kws kernel: (da0:umass-sim0:0:0:0): Retrying Command Aug 6 15:51:26 kws kernel: (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR Aug 6 15:51:26 kws kernel: (da0:umass-sim0:0:0:0): error 5 Aug 6 15:51:26 kws kernel: (da0:umass-sim0:0:0:0): Retries Exausted Aug 6 15:51:26 kws kernel: (da0:umass-sim0:0:0:0): removing device entry Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Request completed with CAM_REQ_CMP_ERR Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Retrying Command Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Request completed with CAM_REQ_CMP_ERR Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Retrying Command Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Request completed with CAM_REQ_CMP_ERR Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Retrying Command Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Request completed with CAM_REQ_CMP_ERR Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Retrying Command Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Request completed with CAM_REQ_CMP_ERR Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): error 5 Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Retries Exausted Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): got CAM status 0x4 Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): fatal error, failed to attach to device Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): lost device Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Request completed with CAM_REQ_CMP_ERR Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Retrying Command Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Request completed with CAM_REQ_CMP_ERR Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Retrying Command Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Request completed with CAM_REQ_CMP_ERR Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Retrying Command Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Request completed with CAM_REQ_CMP_ERR Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Retrying Command Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Request completed with CAM_REQ_CMP_ERR Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): error 5 Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): Retries Exausted Aug 6 15:51:26 kws kernel: (da1:umass-sim0:0:0:1): removing device entry After unplugging my phone seems connected to PC until reboot. Unfortunately I have not any idea about BULK_IGNORE_TAG porting From linimon at FreeBSD.org Thu Aug 14 10:22:33 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Aug 14 10:22:44 2008 Subject: usb/126519: [usb] [panic] panic when plugging in an iphone Message-ID: <200808141022.m7EAMXaI074396@freefall.freebsd.org> Old Synopsis: Panic when plugging in an iphone New Synopsis: [usb] [panic] panic when plugging in an iphone Responsible-Changed-From-To: freebsd-amd64->freebsd-usb Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 14 10:22:02 UTC 2008 Responsible-Changed-Why: Reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=126519 From kevlo at kevlo.org Fri Aug 15 10:08:38 2008 From: kevlo at kevlo.org (Kevin Lo) Date: Fri Aug 15 10:08:46 2008 Subject: High speed isochronous transfer patch Message-ID: <1218793142.1703.7.camel@wsl.kevlo.org> Hi, The attached patch that adds support for high speed isochronous transfer, which is taken from NetBSD. Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-ehci Type: text/x-patch Size: 30353 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20080815/f3d3480c/patch-ehci.bin From enterco at yahoo.com Sat Aug 16 21:00:15 2008 From: enterco at yahoo.com (Emil Cazamir) Date: Sat Aug 16 21:00:24 2008 Subject: usb/113432: [ucom] WARNING: attempt to net_add_domain(netgraph) after domainfinalize() Message-ID: <200808162100.m7GL0EVa016159@freefall.freebsd.org> The following reply was made to PR usb/113432; it has been noted by GNATS. From: Emil Cazamir To: freebsd-gnats-submit@FreeBSD.org, quetzal@zone3000.net Cc: Subject: Re: usb/113432: [ucom] WARNING: attempt to net_add_domain(netgraph) after domainfinalize() Date: Sat, 16 Aug 2008 13:30:05 -0700 (PDT) --0-1186498824-1218918605=:36762 Content-Type: text/plain; charset=us-ascii Hello! I received a similar message when I tried to use ethernet interface renaming, at the time when starting pppoed on a renamed interface. I believe that the problem is somewhere at the netgraph level, in conjunction with ng_pppoe. How to repeat: use lines similar to the following, into a system running FreeBSD 7.0: /etc/rc.conf: ifconfig_em1_name="lan0" pppoed_enable="YES" pppoed_interface="lan0" -- other /etc/rc.conf parameters -- and check the messages at the time when pppoed starts. Best regards, Emil Cazamir FreeBSD user since 4.3-RELEASE --0-1186498824-1218918605=:36762 Content-Type: text/html; charset=us-ascii
Hello!

I received a similar message when I tried to use ethernet interface renaming, at the time when starting pppoed on a renamed interface. I believe that the problem is somewhere at the netgraph level, in conjunction with ng_pppoe.

How to repeat:
use lines similar to the following, into a system running FreeBSD 7.0:
/etc/rc.conf:
ifco nfig_em1_name="lan0"
pppoed_enable="YES"
pppoed_interface="lan0"
-- other /etc/rc.conf parameters --

and check the messages at the time when pppoed starts.

Best regards,
Emil Cazamir
FreeBSD user since 4.3-RELEASE


--0-1186498824-1218918605=:36762-- From coxbrian at msu.edu Mon Aug 18 07:00:23 2008 From: coxbrian at msu.edu (Brian Cox) Date: Mon Aug 18 07:00:41 2008 Subject: kern/123224: [ums] Scroll wheel breakage w/ USB MS Wireless Intellimouse Explorer Message-ID: <200808180700.m7I70MKB087624@freefall.freebsd.org> The following reply was made to PR kern/123224; it has been noted by GNATS. From: Brian Cox To: Kai Wang Cc: bug-followup@freebsd.org Subject: Re: kern/123224: [ums] Scroll wheel breakage w/ USB MS Wireless Intellimouse Explorer Date: Mon, 18 Aug 2008 02:42:39 -0400 On Monday 11 August 2008 10:10:55 am Kai Wang wrote: > I think the regression you metioned is indeed there. > > Could you please try the following patch against -CURRENT or -STABLE > and see if it fixes the problem? I applied the patch against the latest RELENG_6 (as of approx. 18 Aug 2008 02:00 -0400). The kernel now detects the Z dir and scrolling with the wheel works. - Brian From bugmaster at FreeBSD.org Mon Aug 18 11:06:59 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 18 11:09:08 2008 Subject: Current problem reports assigned to freebsd-usb@FreeBSD.org Message-ID: <200808181106.m7IB6wXL079980@freefall.freebsd.org> Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f 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 i386/46371 usb USB controller cannot be initialized on IBM Netfinity o bin/57255 usb usbd(8) and multi-function devices o usb/63621 usb [umass] [panic] USB MemoryStick Reader stalls/crashes o usb/67301 usb [uftdi] [panic] RTS and system panic o usb/69006 usb [usbdevs] [patch] Apple Cinema Display hangs USB ports o usb/71155 usb [ulpt] misbehaving usb-printer hangs processes, causes o usb/73307 usb [panic] Kernel panics on USB disconnect o usb/74771 usb [umass] [hang] mounting write-protected umass device a o usb/75705 usb [umass] [panic] da0 attach / Optio S4 (with backtrace) o usb/75797 usb [sound] 5.3-STABLE(2005 1/4) detect USB headset, But c o usb/76395 usb [uhci] USB printer does not work, usbdevs says "addr 0 o usb/77184 usb [umass] [panic] kernel panic on USB device disconnect, o usb/77294 usb [ucom] [panic] ucom + ulpcom panic o usb/79269 usb [ohci] USB ohci da0 plug/unplug causes crashes and loc o usb/79287 usb [uhci] [hang] UHCI hang after interrupt transfer o usb/79524 usb [ulpt] printing to Minolta PagePro 1[23]xxW via USB fa a usb/79656 usb [ehci] RHSC interrupts lost o usb/79722 usb [ehci] wrong alignments in ehci.h o usb/80040 usb [hang] Use of sound mixer causes system freeze with ua o usb/80361 usb [umass] [patch] mounting of Dell usb-stick fails o usb/80829 usb [modules] [panic] possible panic when loading USB-modu o usb/80862 usb [patch] USB locking issues: missing some Giant calls o usb/82350 usb [ucom] [panic] null pointer dereference in USB stack o usb/82520 usb [udbp] [reboot] Reboot when USL101 connected s usb/82569 usb [umass] [panic] USB mass storage plug/unplug causes sy o usb/82660 usb [ehci] [panic] EHCI: I/O stuck in state 'physrd'/panic o usb/83504 usb [kernel] [patch] SpeedTouch USB stop working on recent o usb/83563 usb [umass] [panic] Page Fault while detaching Mpman Usb d f usb/83677 usb [usb] [request] usb controller often not detected (Sun o usb/83756 usb [ums] [patch] Microsoft Intellimouse Explorer 4.0A doe 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 s usb/84336 usb [usb] [reboot] instant system reboot when unmounting a o usb/86767 usb [umass] [patch] bogus "slice starts beyond end of the o usb/88743 usb [hang] [regression] USB makes kernel hang at boot (reg s usb/89003 usb [request] LaCie Firewire drive not properly supported o usb/89954 usb [umass] [panic] USB Disk driver race condition? o usb/90700 usb [umass] [panic] Kernel panic on connect/mount/use umas o usb/91238 usb [umass] USB tape unit fails to write a second tape fil o usb/91283 usb [boot] [regression] booting very slow with usb devices o usb/91538 usb [ulpt] [patch] Unable to print to EPSON CX3500 o usb/91906 usb [ehci] [hang] FreeBSD hangs while booting with USB leg o usb/92052 usb [ulpt] usbd causes defunct process with busy file-hand o usb/92083 usb [ural] [panic] panic using WPA on ural NIC in 6.0-RELE o usb/92142 usb [uhub] SET_ADDR_FAILED and SHORT_XFER errors from usb o usb/92171 usb [panic] panic unplugging Vodafone Mobile Connect (UMTS o usb/93155 usb [ulpt] /dev/ulpt0: device busy, USB printer does not w o usb/93408 usb [mouse] hw.acpi.cpu.cx_lowest=C3 on AMD Turion causes o usb/93828 usb [ohci] [panic] ohci causes panic on boot (HP Pavillion o usb/94384 usb [panic] kernel panic with usb2 hardware o usb/94717 usb [ulpt] Reading from /dev/ulpt can break work of a UHCI o usb/94897 usb [panic] Kernel Panic when cleanly unmounting USB disk s usb/95348 usb [keyboard] USB keyboard unplug causes noise on screen o usb/95562 usb [umass] Write Stress in USB Mass drive causes "vinvalb s usb/95636 usb [umass] [boot] 5 minute delay at boot when using VT620 s usb/96120 usb [ums] [request] USB mouse not always detected o usb/96224 usb [usb] [msdosfs] mount_msdosfs cause page fault in sync o usb/96457 usb [umass] [panic] fatback on umass = reboot s usb/97286 usb [mouse] [request] MS Wireless Intellimouse Explorer 2. o usb/99431 usb [keyboard] FreeBSD on MSI 6566E (Intel 845E motherboar o usb/101096 usb [ural] [panic] USB WLAN occasionally causes kernel-pan o usb/101448 usb [ohci] FBSD 6.1-STABLE/AMD64 crashes under heavy USB/O o usb/101752 usb [umass] [panic] 6.1-RELEASE kernel panic on usb device o usb/102066 usb [ukbd] usb keyboard and multimedia keys don't work f usb/102096 usb [patch] usbd(8) does not handle multiple devices in on o usb/103025 usb [uhub] [panic] wrong detection of USB device for FreeB o usb/104292 usb [umass] [hang] system lockup on forced umount of usb-s o usb/104830 usb [umass] system crashes when copying data to umass devi o usb/105186 usb [ehci] [panic] USB 2.0/ehci on FreeBSD 6.2-PRE/AMD64 c o usb/106615 usb [uftdi] uftdi module does not automatically load with o usb/106648 usb [umass] [hang] USB Floppy on D1950 10 min Hang on Inse s usb/106832 usb USB HP printer is not detected by kernel when ACPI ena o usb/107248 usb [umass] [patch] scsi_da.c quirk for Cowon iAUDIO X5 MP o usb/107446 usb [umass] umass problems (usb and fw disks) o usb/107827 usb [ohci] [panic] ohci_add_done addr not found o usb/107848 usb [umass] [request] cannot access Samsung flash disk o usb/107924 usb [patch] usbd(8) does not call detach o usb/108513 usb [umass] Creative MuVo TX FM fails in 6.2-RELEASE [regr 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/110856 usb [ugen] [patch] interrupt in msgs are truncated when bu o usb/110988 usb [umass] [patch] Handling of quirk IGNORE_RESIDUE is um o usb/111753 usb [uhid] [panic] Replicable system panic involving UHID s usb/112568 usb [umass] [request] USB mode may wrong when mounting Pla o usb/112631 usb [panic] Problem with SONY DSC-S80 camera on umount o usb/112640 usb [usb] [hang] Kernel freezes when writing a file to an s usb/113629 usb [ukbd] Dropped USB keyboard events on Dell Latitude D6 o usb/113672 usb [ehci] [panic] Kernel panic with AEWIN CB6971 s usb/113977 usb [request] Need a way to set mode of USB disk's write c o usb/114310 usb [libusb] [patch] [panic] USB hub attachment panics ker o usb/114682 usb [umass] generic USB media-card reader unusable o kern/114780 usb [uplcom] [panic] Panics while stress testing the uplco o usb/115298 usb [ulpt] [panic] Turning off USB printer panics kernel o usb/116561 usb [umodem] [panic] RELENG_6 umodem panic "trying to slee o usb/116699 usb [usbhid] USB HID devices do not initialize at system b o usb/116947 usb [ukbd] [patch] [regression] enable boot protocol on th o usb/117200 usb [ugen] ugen0 prints strange string on attach if detach o usb/117313 usb [umass] [panic] panic on usb camera insertion o usb/117613 usb [uhci] [irq] uhci interrupt storm & USB leaked memory o usb/117946 usb [panic] D-Link DUB-E100 rev. B1 crashes FreeBSD 7.0-BE o usb/117955 usb [umass] [panic] inserting minolta dimage a2 crashes OS o usb/118140 usb [ucom] [patch] quick hack for ucom to get it behave wi o usb/118141 usb [ucom] usb serial and nokia phones ucomreadcb ucomread o usb/118353 usb [panic] [ppp] repeatable kernel panic during ppp(4) se o usb/118480 usb [umass] Timeout in USB mass storage freezes vfs layer o usb/119201 usb [cam] [patch] Quirks for Olympus FE-210 camera, LG and o usb/119481 usb [hang] FreeBSD not responding after connecting USB-Mas o usb/119509 usb USB flaky on Dell Optiplex 755 o usb/119513 usb [irq] inserting dlink dwl-g630 wireless card results i o usb/119977 usb [ums] Mouse does not work in a Cherry-USB keyboard/mou o usb/120017 usb [ehci] [patch] CS5536 (AMD Geode) USB 2.0 quirk o usb/120034 usb [hang] 6.2 & 6.3 hangs on boot at usb0: OHCI with 1.5 o usb/120283 usb [panic] Automation reboot with wireless keyboard & mou o usb/120321 usb [hang] System hangs when transferring data to WD MyBoo o usb/120729 usb [panic] fault while in kernel mode with connecting USB o usb/120786 usb Kernel panic when forced umount of a dettached USB Har o usb/121232 usb remove PCCARD rebooted system o usb/121275 usb [boot] FreeBSD fails to boot with usb legacy support e o usb/121474 usb [cam] [patch] QUIRK: SAMSUNG HM250JI in LaCie usb hard o usb/121708 usb [keyboard] nforce 650i mobo w/ usb keyboard infinite k o usb/121734 usb [ugen] ugen HP1022 printer device not working since up o usb/121755 usb [ohci] [patch] Fix panic after ohci/uhub cardbus devic o usb/122483 usb [panic] [ulpt] Repeatable panic in 7.0-STABLE o usb/122539 usb [ohci] [panic] AnyDATA ADU-E1000D - kernel panic: ohci o usb/122905 usb [ubsa] [patch] add Huawei E220 to ubsa o kern/123510 usb [ums] Mouse Wheel Fails to Work [regression] o usb/123690 usb Panic on USB device insertion when usb loaded as a mod o usb/123714 usb Panic when hald-storage-probe runs with umass device i o usb/124708 usb [panic] Kernel panic on USB KVM reattach o usb/124758 usb rum panics SMP kernel o kern/124777 usb [ucom] USB cua devices don't revert to tty devices whe o usb/124980 usb [panic] kernel panic on detaching unmounted umass devi o usb/125088 usb Touchpad not detected on Adesso AKB-430UG USB kbd/pad o usb/125450 usb [panic] Removing USB flash card while being accessed c o usb/125631 usb [usb][ums] kernel panic during bootup while 'Logitech o kern/126396 usb [panic] kernel panic after unplug USB Bluetooth device o usb/126519 usb [usb] [panic] panic when plugging in an iphone 137 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/30929 usb [usb] [patch] use usbd to initialize USB ADSL modem o usb/40948 usb [umass] [request] USB HP CDW8200 does not work s usb/51958 usb [urio] [patch] update for urio driver s usb/52026 usb [usb] [request] umass driver support for InSystem ISD2 o usb/59698 usb [keyboard] [patch] Rework of ukbd HID to AT code trans s usb/62257 usb [umass] [request] card reader UCR-61S2B is only half-s o usb/66547 usb [ucom] Palm Tungsten T USB does not initialize correct o usb/68232 usb [ugen] [patch] ugen(4) isochronous handling correction o usb/70523 usb [umct] [patch] umct sending/receiving wrong characters o usb/71280 usb [aue] aue0 device (linksys usb100tx) doesn't work in 1 o usb/71416 usb [ugen] Cryptoflex e-gate USB token (ugen0) detach is n o usb/71417 usb [ugen] Cryptoflex e-gate USB token (ugen0) communicati o usb/71455 usb [umass] Slow USB umass performance of 5.3 s usb/72733 usb [ucom] [request] Kyocera 7135 Palm OS connection probl o usb/74211 usb [umass] USB flash drive causes CAM status 0x4 on 4.10R a usb/74453 usb [umass] [patch] Q-lity CD-RW USB ECW-043 (ScanLogic SL o usb/75764 usb [umass] [patch] "umass0: Phase Error" - no device for o usb/75800 usb [ucom] ucom1: init failed STALLED error in time of syn s usb/75928 usb [umass] [request] Cytronix SmartMedia card (SMC) reade o usb/76461 usb [umass] disklabel of umass(4)-CAM(4)-da(4) not used by o usb/76653 usb [umass] [patch] Problem with Asahi Optical usb device o usb/76732 usb Mouse problems with USB KVM Switch o usb/78984 usb [umass] [patch] Creative MUVO umass failure o usb/79723 usb [usb] [request] prepare for high speed isochronous tra o usb/80774 usb [patch] have "usbd_find_desc" in line with the other " s usb/80776 usb [udav] [request] UDAV device driver shouldn't use usb_ s usb/80777 usb [request] usb_rem_task() should wait for callback to c o usb/80854 usb [patch] [request] suggestion for new iface-no-probe me o usb/80935 usb [uvisor] [patch] uvisor.c is not work with CLIE TH55. o usb/81621 usb [ehci] [hang] external hd hangs under load on ehci o usb/83863 usb [ugen] Communication problem between opensc/openct via s usb/85067 usb [uscanner] Cannot attach ScanJet 4300C to usb device o usb/86298 usb [mouse] Known good USB mouse won't work with correct s o usb/87224 usb Cannot mount USB Zip750 o usb/87648 usb [mouse] Logitech USB-optical mouse problem. o usb/88408 usb [axe] axe0 read PHY failed o usb/91546 usb [umodem] [patch] Nokia 6630 mobile phone does not work o usb/91811 usb [umass] Compact Flash in HP Photosmart 2610 return " o usb/91896 usb camcontrol(8): Serial Number of USB Memory Sticks is n o usb/92852 usb [ums] [patch] Vertical scroll not working properly on o usb/93389 usb [umass] [patch] Digital Camera Pentax S60 don't work o usb/93872 usb [cam] [patch] SCSI quirk required for ELTA 8061 OL USB o usb/95037 usb [umass] USB disk not recognized on hot-plug. o usb/96381 usb [cam] [patch] add a quirk table entry for a flash ram o usb/96599 usb [usb] [patch] Sony Handycam DCR-HC32E memory stick slo o usb/97175 usb [umass] [hang] USB cardreader hangs system o usb/97472 usb [cam] [patch] add support for Olympus C150,D390 o usb/98343 usb [boot] BBB reset failed errors with Creative Muvo MP3 o usb/99538 usb [keyboard] while using USB keyboard default params of o usb/100746 usb [keyboard] system does not boot due to USB keyboard pr o usb/101761 usb [usb] [patch] [request] usb.h: increase maximal size o o usb/101775 usb [libusbhid] [patch] possible error in report descripto o usb/102678 usb [keyboard] Dell PowerEdge DRAC5 USB Keyboard does not o usb/102976 usb [panic] Casio Exilim Digital Camera causes panic on in o usb/103046 usb [ulpt] [patch] ulpt event driven I/O with select(2) an o usb/103289 usb [request] USB 2.0 problems on AMD LX-800 CPU and CS-55 o usb/103418 usb [usbhidctl] [patch] [request] usbhidctl: add ability t o usb/103917 usb [uhub] USB driver reports "Addr 0 should never happen" o usb/104290 usb [umass] [patch] quirk: TOSHIBA DVD-RAM drive (libretto o usb/104352 usb [ural] [patch] ural driver doesnt work o usb/104645 usb [umass] [request] Rave C-201 MP3 player does not commu o usb/105065 usb [ata] SATA - USB Bridge o usb/105361 usb [panic] Kernel panic during unmounting mass storage (C o usb/106041 usb [usb] [request] FreeBSD does not recognise Mustek Bear o usb/106621 usb [axe] [patch] DLINK DUB-E100 support broken o usb/106861 usb [usbdevs] [patch]: usbdevs update: Add product ACER Ze o usb/107243 usb [cam] [patch] Apacer USB Flash Drive quirk o usb/107388 usb [patch] [request] new driver: add utoppy device from N o usb/107496 usb [uhub] USB device problem on RELENG_6_2 (SHORT_XFER) [ o usb/107935 usb [uplcom] [panic] panic while accessing /dev/cuaU0 o usb/108056 usb [ohci] Mouse gets powered off during device probe when s usb/108344 usb [panic] kernel with atausb panics when unplugging USB o usb/110197 usb [umass] Sony PSP umass device does not detach from EHC s usb/110991 usb [usbdevs] [patch] QUIRK: Super Top IDE DEVICE (depends o usb/112461 usb [ehci] [request] ehci USB 2.0 doesn't work on nforce4 o usb/112463 usb [umass] problem with Samsung USB DVD writer, libscg an o usb/112944 usb [ulpt] [patch] Bi-directional access to HP LaserJet 10 o usb/113060 usb [usbdevs] [patch] Samsung printer not working in bidir o usb/113432 usb [ucom] WARNING: attempt to net_add_domain(netgraph) af o conf/114013 usb [patch] WITHOUT_USB allow to compil a lot of USB stuff o usb/114068 usb [umass] [patch] Problems with connection of the umass o usb/114916 usb [umass] [patch] USB Maxtor drive (L300RO) requires qui o usb/115400 usb [ehci] Problem with EHCI on ASUS M2N4-SLI o usb/115933 usb [uftdi] [patch] RATOC REX-USB60F (usb serial converter o usb/115935 usb [usbdevs] [patch] kernel counterproductively attaches o usb/116282 usb [ulpt] Cannot print on USB HP LJ1018 or LJ1300 o usb/117075 usb [scsi_da] [patch] quirk: USB Samsung YP-U3 MP3 o usb/117183 usb [panic] USB/fusefs -- panic while transferring large a o usb/117185 usb [umodem] [patch] Add support for UNION interface descr o usb/117205 usb [uscanner] [patch] uscanner support for HP ScanJet 447 o usb/117546 usb [uftdi] [patch] Add MaxStream ZigBee product ID to uft o usb/117598 usb [uaudio] [patch] Not possible to record with Plantroni o usb/117893 usb [umass] Lacie USB DVD writing failing o usb/117911 usb [ums] [request] Mouse Gembird MUSWC not work o usb/117938 usb [ums] [patch] Adding support for MS WL Natural and MS o usb/118098 usb [umass] 6th gen iPod causes problems when disconnectin o usb/118485 usb [usbdevs] [patch] Logitech Headset Workaround o usb/118686 usb [usbdevs] [patch] teach usbdevs / ubsa(4) about Huawei o usb/119150 usb [usbdevs] [patch] new usbdevs for CDMA 1xEVDO devices o usb/119227 usb [ubsa] [patch] ubsa buffer is too small; should be tun o usb/119389 usb [umass] Sony DSC-W1 CBI reset failed, STALLED [regress o usb/119633 usb [umass] umass0: BBB reset failed, IOERROR [regression] o usb/119653 usb [cam] [patch] iriver s7 player sync cache error patch o usb/119981 usb [axe] [patch] add support for LOGITEC LAN-GTJ/U2 gigab o usb/120572 usb [umass] [patch] quirk to support ASUS P535 as umass (a o usb/121045 usb [uftdi] [patch] Add support for PC-OP-RS1 and KURO-RS o usb/121169 usb [umass] Issues with usb mp3 player o usb/121184 usb [uipaq] [patch] add ids from linux ipaq driver (plus a o usb/121426 usb [patch] [uscanner] add HP ScanJet 3570C o usb/122025 usb [patch] uscanner does not attach to Epson RX620 printe o usb/122119 usb [umass] umass device causes creation of daX but not da o usb/122547 usb [ehci] USB Printer not being recognized after reboot p usb/122610 usb Add Verizon v740 support to ubsa(4) o usb/122621 usb [patch] [request] New driver for Sierra Wireless 3G US o usb/122712 usb [usbdevs] [patch] Sony Vaio RF keyboard/mouse receiver o usb/122813 usb [udbp] [request] udbp driver should be removed in favo o usb/122819 usb Patch to provide dynamic additions to the usb quirks t o usb/122936 usb [ucom][ubsa] Device does not receive interrupt o usb/122956 usb Support for Novatel Wireless XU870 3G Card o usb/122992 usb MotoROKR Z6 Phone not recognised by umass as USB disk. p usb/123148 usb [uscanner] [patch] Epson DX8400/50 needs uscanner to s p usb/123211 usb [udav] if_udav driver doesn't support Davicom 9601 USB o kern/123224 usb [ums] Scroll wheel breakage w/ USB MS Wireless Intelli o usb/123351 usb Add Reiner SCT cyberJack, Omnikey [26]020, Fujitsu Sie o usb/123352 usb Add Option GTMAX3.6/7.2 and Quallcomm MMC module devic o usb/123509 usb [umass] continuous reset Samsung SGH-G600 phone o usb/123611 usb [usb] BBB reset failed, STALLED from Imation/Mitsumi U o usb/123691 usb usbd(8): usbd hangs o usb/123969 usb Supermicro H8SMi-2 usb problem o usb/124604 usb Wireless Mouse doesn't work o usb/125072 usb [uplcom] [patch] add Mobile Action MA-620 Infrared Ada o usb/125238 usb Habu Mouse turns off in X o usb/125264 usb [patch] sysctl for set usb mouse rate (very useful for o usb/125510 usb repeated plug and unplug of USB mass storage devices l o usb/125736 usb [ukbd] [hang] system hangs after AT keyboard detect if o usb/125941 usb [ums] not working wheel on my microsoft notebook optic 136 problems total. From dfilter at FreeBSD.ORG Mon Aug 18 16:30:06 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Mon Aug 18 16:30:20 2008 Subject: kern/123224: commit references a PR Message-ID: <200808181630.m7IGU5l8012145@freefall.freebsd.org> The following reply was made to PR kern/123224; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/123224: commit references a PR Date: Mon, 18 Aug 2008 16:29:35 +0000 (UTC) kaiw 2008-08-18 16:29:13 UTC FreeBSD src repository Modified files: sys/dev/usb ums.c Log: SVN rev 181839 on 2008-08-18 16:29:13Z by kaiw Re-add Microsoft Intellimouse 2.0 TWHEEL quirk. Tested by: Merritt Draney, Brian Cox PR: kern/123224 PR: kern/123510 MFC after: 3 days Revision Changes Path 1.100 +3 -0 src/sys/dev/usb/ums.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From dfilter at FreeBSD.ORG Mon Aug 18 16:30:09 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Mon Aug 18 16:30:20 2008 Subject: kern/123510: commit references a PR Message-ID: <200808181630.m7IGU9Fq012388@freefall.freebsd.org> The following reply was made to PR kern/123510; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/123510: commit references a PR Date: Mon, 18 Aug 2008 16:29:36 +0000 (UTC) kaiw 2008-08-18 16:29:13 UTC FreeBSD src repository Modified files: sys/dev/usb ums.c Log: SVN rev 181839 on 2008-08-18 16:29:13Z by kaiw Re-add Microsoft Intellimouse 2.0 TWHEEL quirk. Tested by: Merritt Draney, Brian Cox PR: kern/123224 PR: kern/123510 MFC after: 3 days Revision Changes Path 1.100 +3 -0 src/sys/dev/usb/ums.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From dfilter at FreeBSD.ORG Mon Aug 18 16:50:08 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Mon Aug 18 16:50:13 2008 Subject: usb/125941: commit references a PR Message-ID: <200808181650.m7IGo7PT014750@freefall.freebsd.org> The following reply was made to PR usb/125941; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: usb/125941: commit references a PR Date: Mon, 18 Aug 2008 16:49:13 +0000 (UTC) kaiw 2008-08-18 16:48:53 UTC FreeBSD src repository Modified files: sys/dev/usb hid.c Log: SVN rev 181841 on 2008-08-18 16:48:53Z by kaiw In the hid parser, if a INPUT/OUTPUT/FEATURE item is skipped, its corresponding USAGE should be skipped as well. For example, below is a report desc fragment of some mouse: COLLECTION ... USAGE TWHEEL FEATURE ... ... USAGE WHEEL INPUT ... ... END COLLECTION "USAGE TWHEEL" should be consumed after the FEATURE item is skipped, otherwise, the INPUT item will be assigned to "USAGE TWHEEL" later, other than "USAGE WHEEL". Tested by: Grzegorz Blach PR: usb/125941 Revision Changes Path 1.30 +12 -3 src/sys/dev/usb/hid.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From spamtrap at tczyhatczsche.eu Mon Aug 18 17:02:50 2008 From: spamtrap at tczyhatczsche.eu (Jonathan Lee) Date: Mon Aug 18 17:02:58 2008 Subject: DWA-110 is supported by if_rum Message-ID: <20080818160552.GC1091@johnny.mnemoni.ca> I've tested D-LINK's DWA-110 on % uname -a FreeBSD johnny.mnemoni.ca 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun Aug 10 15:26:30 EEST 2008 root@johnny.mnemoni.ca:/usr/obj/usr/src/sys/JOHNNY i386 It works OK, except for some errors: Aug 12 11:00:36 johnny kernel: wpi0: timeout resetting Tx ring 1 Aug 12 11:00:36 johnny kernel: wpi0: timeout resetting Tx ring 3 Aug 12 11:00:36 johnny kernel: wpi0: timeout resetting Tx ring 4 Aug 14 22:49:26 johnny kernel: rum0: on uhub4 Aug 14 22:49:26 johnny kernel: rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 Aug 14 22:49:27 johnny kernel: rum0: WARNING: using obsoleted IFF_NEEDSGIANT flag You can see my original message to freebsd-drivers: http://lists.freebsd.org/pipermail/freebsd-drivers/2008-August/000753.html Anyway, the device is supported. Someone responsible could add the following to /usr/src/sys/dev/usb/: usbdevs: -------- product DLINK2 DWA110 0x3c07 DWA-110 -------- if_rum.c: -------- { USB_VENDOR_DLINK2, USB_PRODUCT_DLINK2_DWA110 }, -------- EOF. From bz at FreeBSD.org Mon Aug 18 22:41:19 2008 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Mon Aug 18 22:41:26 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <20080818205914.GJ16977@elvis.mu.org> References: <20080818205914.GJ16977@elvis.mu.org> Message-ID: <20080818214711.J88849@maildrop.int.zabbadoz.net> On Mon, 18 Aug 2008, Alfred Perlstein wrote: Hi Alfred, CC:ing freebsd-usb for additional review. A few initial comments on the patch > The delta is here: > http://mu.org/~bright/usb4bsd.diff.gz The patch only includes kernel parts, is there any impact on userland? There are various style bugs introduced. That could be fixed easily I guess? In kern/subr_bus.c you are taking steps to avoid zero size allocations, which haven't been there up to now. Why do we need that? There is a question about whether to avoid the conditional locking in dev/sound/pcm/channel.c in favour of recursive locking? The locking in dev/sound/pcm/mixer.c appears to be strange; the locking appears to have substantially changed without corresponding changes to the non-USB drivers. Some of the new sound drivers are Giant-locked? I am not sure we should be adding new drivers that are not mpsafe. There seems to be a README.TXT but no manpages for the new API or drivers. Are these pending? Some of the files have $FreeBSD$ strings already expanded, probably because they were copied from existing files. Why is the diff to compat/ndis/ntoskrnl_var.h necessary? Regards, Bjoern, Kris, Ed S., Ollivier (sitting together at king's, cam.ac.uk devsummit) -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From kevlo at kevlo.org Tue Aug 19 01:54:11 2008 From: kevlo at kevlo.org (Kevin Lo) Date: Tue Aug 19 01:54:18 2008 Subject: DWA-110 is supported by if_rum In-Reply-To: <20080818160552.GC1091@johnny.mnemoni.ca> References: <20080818160552.GC1091@johnny.mnemoni.ca> Message-ID: <1219110765.7981.0.camel@nsl> Jonathan Lee wrote: > I've tested D-LINK's DWA-110 on > > % uname -a > FreeBSD johnny.mnemoni.ca 7.0-STABLE > FreeBSD 7.0-STABLE #5: Sun Aug 10 15:26:30 EEST 2008 > root@johnny.mnemoni.ca:/usr/obj/usr/src/sys/JOHNNY i386 > > It works OK, except for some errors: > > Aug 12 11:00:36 johnny kernel: wpi0: timeout resetting Tx ring 1 > Aug 12 11:00:36 johnny kernel: wpi0: timeout resetting Tx ring 3 > Aug 12 11:00:36 johnny kernel: wpi0: timeout resetting Tx ring 4 > > Aug 14 22:49:26 johnny kernel: rum0: on uhub4 > Aug 14 22:49:26 johnny kernel: rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 > Aug 14 22:49:27 johnny kernel: rum0: WARNING: using obsoleted IFF_NEEDSGIANT flag > > You can see my original message to freebsd-drivers: > > http://lists.freebsd.org/pipermail/freebsd-drivers/2008-August/000753.html > > Anyway, the device is supported. Someone responsible > could add the following to /usr/src/sys/dev/usb/: > > usbdevs: > -------- > product DLINK2 DWA110 0x3c07 DWA-110 > -------- > > if_rum.c: > -------- > { USB_VENDOR_DLINK2, USB_PRODUCT_DLINK2_DWA110 }, > -------- Added, thanks. > > EOF. Kevin From alfred at freebsd.org Tue Aug 19 06:15:54 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue Aug 19 06:16:00 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <20080818214711.J88849@maildrop.int.zabbadoz.net> References: <20080818205914.GJ16977@elvis.mu.org> <20080818214711.J88849@maildrop.int.zabbadoz.net> Message-ID: <20080819055821.GO16977@elvis.mu.org> Hans, here's some final review questions, I've added responses where I can recall off the top of my head answers, but I need you to fill in the rest. Hans, can you please resend the answers to these that you've given me? Please include short examples why the changes are needed. I've noted the questions I've forgotten with "??Hans??", please fill those out. I'm quite certain we've already covered all of these points but I would like to be sure. They're not in the front of my brain and you can answer this much easier than I can. FYI, I plan on committing the code tomorrow night based on the following two issues: need to wait for smp tty code. need your reply to this email. -Alfred * Bjoern A. Zeeb [080818 15:24] wrote: > On Mon, 18 Aug 2008, Alfred Perlstein wrote: > > Hi Alfred, > > CC:ing freebsd-usb for additional review. > > A few initial comments on the patch > > >The delta is here: > > http://mu.org/~bright/usb4bsd.diff.gz > > The patch only includes kernel parts, is there any impact on userland? I think the userland tools need to be switched to the new headers, however what's more likely to happen is that after a soak period of a few weeks, we will move the new to replace the old and userland should be just fine. > There are various style bugs introduced. That could be fixed easily I > guess? Yes, this is a LOT of new code, let's leave a few whitespace nits for others to play with. :) > In kern/subr_bus.c you are taking steps to avoid zero size > allocations, which haven't been there up to now. Why do we need that? ??Hans?? > > There is a question about whether to avoid the conditional locking in > dev/sound/pcm/channel.c in favour of recursive locking? ??Hans?? > The locking in dev/sound/pcm/mixer.c appears to be strange; the > locking appears to have substantially changed without corresponding > changes to the non-USB drivers. ??Hans?? > Some of the new sound drivers are Giant-locked? I am not sure we > should be adding new drivers that are not mpsafe. I think this will be addressed shortly... but.. ??Hans?? (please comment) > > There seems to be a README.TXT but no manpages for the new API or > drivers. Are these pending? Hans has documented a LOT of headers and functions far past what is in the old code from what I can tell. If there are specific changes you have questions about I think we can attend to those relatively easily, Hans has been very forthcoming with information. > Some of the files have $FreeBSD$ strings already expanded, probably > because they were copied from existing files. Yes, committing them should fix that. If the tags aren't obliterated they'll serve as a guide as to what files they were based on, if they are obliterated it's not that important anyhow. I consider this a wash. > > Why is the diff to compat/ndis/ntoskrnl_var.h necessary? It's needed for compiling usb2_ndis, but... ??Hans?? -- - Alfred Perlstein From sk.paix at gmail.com Tue Aug 19 12:18:22 2008 From: sk.paix at gmail.com (Sergej Kandyla) Date: Tue Aug 19 12:18:29 2008 Subject: ugensa patch, CDMA ZTE AC8700 modem Message-ID: <48AAB5A2.5060801@gmail.com> Hi! I've tried to get working CDMA Evdo USB modem ZTE AC8700 (http://www.mobile-8.com/id/devices/zte_ac8700) under Releng_7 with ugensa kernel module http://people.FreeBSD.org/~lioux/ugensa.tar.gz The module was compiled without any problems and after reboot I've get next: #dmesg ugensa0: on uhub0 ugensa_attach: sc = 0xc2bb3e00 ugensa0: unexpected endpoint But there are no devices ugensa.... # ls -l /dev/u* crw-r--r-- 1 root operator 0, 82 Aug 19 14:21 /dev/ums0 lrwxr-xr-x 1 root wheel 6 Aug 19 14:21 /dev/urandom -> random crw-rw---- 1 root operator 0, 35 Aug 19 14:21 /dev/usb crw-rw---- 1 root operator 0, 34 Aug 19 14:21 /dev/usb0 crw-rw---- 1 root operator 0, 36 Aug 19 14:21 /dev/usb1 crw-rw---- 1 root operator 0, 37 Aug 19 14:21 /dev/usb2 crw-rw---- 1 root operator 0, 38 Aug 19 14:21 /dev/usb3 # uname -a FreeBSD adminbook.intranet 7.0-STABLE FreeBSD 7.0-STABLE #4: Fri Aug 15 22:27:32 EEST 2008 root@adminbook.intranet:/usr/obj/usr/src/sys/PAIX1 i386 #kldstat 5 1 0xc0a0f000 2858 ugensa.ko By default modem looks as: Jul 11 17:07:44 adminbook root: Unknown USB device: vendor 0x19d2 product 0xfffe bus uhub1 Jul 11 17:07:44 adminbook kernel: ugen0: on uhub1 Also, I've tried ugencom patch http://www.cs.cmu.edu/~dga/dot/fbsd_pc5220 but it's working only for releng_6 and fails on releng_7 Thanks for advice! -- Best Wishes, PAIX-UANIC | SK3929-RIPE From hselasky at c2i.net Tue Aug 19 15:56:42 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Aug 19 15:56:50 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <20080819055821.GO16977@elvis.mu.org> References: <20080818205914.GJ16977@elvis.mu.org> <20080818214711.J88849@maildrop.int.zabbadoz.net> <20080819055821.GO16977@elvis.mu.org> Message-ID: <200808191758.22981.hselasky@c2i.net> Hi, On Tuesday 19 August 2008, Alfred Perlstein wrote: > Hans, here's some final review questions, I've added responses > where I can recall off the top of my head answers, but I need > you to fill in the rest. > > need to wait for smp tty code. If this requires changes in the USB serial port drivers there will be trouble. > > > > The patch only includes kernel parts, is there any impact on userland? No. Userland will build like before. The current USB userland utilities and libusb from ports will only work with the old USB stack. I'm working on a replacement for "usbdevs" called "usbconfig" which has some more functionality and a FreeBSD specific libusb, which is compatible with libusb from sourceforge. I have most of it finished in my private SVN repository, and will add it to my P4 repository soon. > > I think the userland tools need to be switched to the new headers, > however what's more likely to happen is that after a soak period of > a few weeks, we will move the new to replace the old and userland should > be just fine. > > > There are various style bugs introduced. That could be fixed easily I > > guess? > > Yes, this is a LOT of new code, let's leave a few whitespace nits for > others to play with. :) All code has been and is continuously styled with a modified "indent" utility: (cat $F | indent -Toss_mixerinfo -TFILE -Tu_char -Tu_int -Tu_long \ -TTAILQ_HEAD -TLIST_HEAD -TTAILQ_ENTRY -TLIST_ENTRY \ -TSTAILQ_HEAD -TSTAILQ_ENTRY \ -Tu_short -Tfd_set -ta -st -bad -bap -nbbb -nbc -br -nbs \ -c41 -cd41 -cdb -ce -ci4 -cli0 -d0 -di8 -ndj -ei -nfc1 \ -nfcb -i8 -ip8 -l79 -lc77 -ldi0 -nlp -npcs -psl -sc \ -nsob -nv | sed -e "s/_HEAD [(]/_HEAD(/g" | sed -e "s/_ENTRY [(]/_ENTRY(/g" | sed -e "s/ __packed/ __packed/g" | sed -e "s/ __aligned/ __aligned/g" | sed -e "s/^#define /#define /g") > temp If there are any more options I can add, then please let me know. > > > In kern/subr_bus.c you are taking steps to avoid zero size > > allocations, which haven't been there up to now. Why do we need that? > It is a workaround. USB2 defines the following function, which can be called when there are no children on a device, which must be handled correctly cross-platform. If this function could be directly implemented in subr_bus.c we would not require the modifications to "device_get_children" at all or any memory allocation. int device_delete_all_children(device_t dev) { device_t *devlist; int devcount; int error; error = device_get_children(dev, &devlist, &devcount); if (error == 0) { while (devcount-- > 0) { error = device_delete_child(dev, devlist[devcount]); if (error) { break; } } free(devlist, M_TEMP); } return (error); } > ??Hans?? > > > There is a question about whether to avoid the conditional locking in > > dev/sound/pcm/channel.c in favour of recursive locking? > That is also possible. The type of the mutex in question can be changed. The feedback I've gotten so far has been against the use of recursive mutexes. Alternativly, expose two variants of the function in question: xxx_unlocked() xxx_locked() > > The locking in dev/sound/pcm/mixer.c appears to be strange; the > > locking appears to have substantially changed without corresponding > > changes to the non-USB drivers. > All the mixer changes are in the detach code for the mixer and should not require any changes to non-USB drivers. > > > Some of the new sound drivers are Giant-locked? I am not sure we > > should be adding new drivers that are not mpsafe. > I assume that you mean USB drivers? s/sound/USB/ Regarding Giant use: All USB drivers that can work without Giant has been converted to work without Giant. Some USB drivers like USB serial port drivers cannot work without Giant because they depend on a Giant locked TTY layer. Same with keyboard. Another example is UHUB which use Giant simply because the device_xxx() functions require Giant. The Giant lock is not used in any critical paths. > I think this will be addressed shortly... but.. > > > (please comment) > > > There seems to be a README.TXT but no manpages for the new API or > > drivers. Are these pending? The manpages are not ready. This is something I need to do. I would appreciate some help here like where I find manpage templates and where I should put these files. > > > Why is the diff to compat/ndis/ntoskrnl_var.h necessary? > > It's needed for compiling usb2_ndis, but... Without this patch the usb2_ndis module will not compile on certain architectures. If you remove this patch you will need to decouple the usb2_ndis module, which is not complete anyway, from the default build. --HPS From Alexander at Leidinger.net Tue Aug 19 16:10:45 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Tue Aug 19 16:10:52 2008 Subject: USB Video class In-Reply-To: <200808191305.m7JD5Tbl007123@brother.ludd.ltu.se> References: <200808191305.m7JD5Tbl007123@brother.ludd.ltu.se> Message-ID: <20080819175332.482767np3ciixag4@webmail.leidinger.net> Quoting "Peter B" (from Tue, 19 Aug 2008 15:05:29 +0200 (MEST)): > > Is there any ongoing project towards USB Video class support in FreeBSD ..? This is better asked on usb@ (CCed). I'm not aware of such an effort, feel free to start it (you better wait some days until the new USB stack hits CVS). Bye, Alexander. > (Looking at the Asus eee builtin webcam 0x04F2 (CHICONY) 0xB071) > > Some links: > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/ uvideo.c > http://developer.berlios.de/projects/linux-uvc > http://www.usb.org/developers/devclass_docs/USB_Video_Class_1_1.zip > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > -- While you don't greatly need the outside world, it's still very reassuring to know that it's still there. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From pb at ludd.ltu.se Tue Aug 19 18:04:44 2008 From: pb at ludd.ltu.se (Peter B) Date: Tue Aug 19 18:04:54 2008 Subject: USB Video Class, port/driver? Message-ID: <200808191749.m7JHnCdR016669@brother.ludd.ltu.se> Is there any ongoing project to create an USB Video Class driver project ..? Otherwise it seems porting the OpenBSD USB UVC driver is the least cumbersome path: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uvideo.h?rev=1.27&content-type=text/plain http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uvideo.c?rev=1.82&content-type=text/plain Maybe someone could at least convert the kernel interfaces such that there is something to work with. At least to get started. Improvements could be "later". (linux: http://developer.berlios.de/projects/linux-uvc) From kris at FreeBSD.org Tue Aug 19 19:47:12 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Aug 19 19:47:17 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <200808191758.22981.hselasky@c2i.net> References: <20080818205914.GJ16977@elvis.mu.org> <20080818214711.J88849@maildrop.int.zabbadoz.net> <20080819055821.GO16977@elvis.mu.org> <200808191758.22981.hselasky@c2i.net> Message-ID: <48AB233C.2010602@FreeBSD.org> Hans Petter Selasky wrote: > Hi, > > On Tuesday 19 August 2008, Alfred Perlstein wrote: >> Hans, here's some final review questions, I've added responses >> where I can recall off the top of my head answers, but I need >> you to fill in the rest. Just so we are clear, this is actually an "initial review" since it's the first time the commit candidate has been posted for public review, as far as I can tell. >> need to wait for smp tty code. > > If this requires changes in the USB serial port drivers there will be trouble. I am not sure what you mean by this statement, since it can be interpreted in several ways, some not so friendly. >>> The patch only includes kernel parts, is there any impact on userland? > > No. Userland will build like before. The current USB userland utilities and > libusb from ports will only work with the old USB stack. I'm working on a > replacement for "usbdevs" called "usbconfig" which has some more > functionality and a FreeBSD specific libusb, which is compatible with libusb > from sourceforge. I have most of it finished in my private SVN repository, > and will add it to my P4 repository soon. This raises the question of why the kernel changes need to be committed now, and what benefit they bring in the absence of a compatible userland. Shouldn't the commit happen after both kernel and userland are ready (and reviewed)? Another comment: the new code seems to bundle all new drivers into "subsystems" but not allow them to be loaded individually. This is quite contrary to how the rest of the kernel is structured, and seems to be of questionable benefit. For example, users will rarely have more than one USB ethernet driver in use on a given system but "device usb2_ethernet" will compile in all 7 drivers. >> I think the userland tools need to be switched to the new headers, >> however what's more likely to happen is that after a soak period of >> a few weeks, we will move the new to replace the old and userland should >> be just fine. >> >>> There are various style bugs introduced. That could be fixed easily I >>> guess? >> Yes, this is a LOT of new code, let's leave a few whitespace nits for >> others to play with. :) > > All code has been and is continuously styled with a modified "indent" utility: > > (cat $F | indent -Toss_mixerinfo -TFILE -Tu_char -Tu_int -Tu_long \ > -TTAILQ_HEAD -TLIST_HEAD -TTAILQ_ENTRY -TLIST_ENTRY \ > -TSTAILQ_HEAD -TSTAILQ_ENTRY \ > -Tu_short -Tfd_set -ta -st -bad -bap -nbbb -nbc -br -nbs \ > -c41 -cd41 -cdb -ce -ci4 -cli0 -d0 -di8 -ndj -ei -nfc1 \ > -nfcb -i8 -ip8 -l79 -lc77 -ldi0 -nlp -npcs -psl -sc \ > -nsob -nv | > sed -e "s/_HEAD [(]/_HEAD(/g" | > sed -e "s/_ENTRY [(]/_ENTRY(/g" | > sed -e "s/ __packed/ __packed/g" | > sed -e "s/ __aligned/ __aligned/g" | > sed -e "s/^#define /#define /g") > temp > > If there are any more options I can add, then please let me know. Mechanical indent tools can be a useful starting point for style(9) compliance but are not the end point of that process. Usually there will need to be manual tweaks. >>> In kern/subr_bus.c you are taking steps to avoid zero size >>> allocations, which haven't been there up to now. Why do we need that? > > It is a workaround. USB2 defines the following function, which can be called > when there are no children on a device, which must be handled correctly > cross-platform. If this function could be directly implemented in subr_bus.c > we would not require the modifications to "device_get_children" at all or any > memory allocation. What do the newbus guys say about this? Adding a workaround in underlying code for a problem caused by your own code is often a signal that you're not going about it the right way. At the very least the reason for the special case should be documented here. > int > device_delete_all_children(device_t dev) > { > device_t *devlist; > int devcount; > int error; > > error = device_get_children(dev, &devlist, &devcount); > if (error == 0) { > while (devcount-- > 0) { > error = device_delete_child(dev, devlist[devcount]); > if (error) { > break; > } > } > free(devlist, M_TEMP); > } > return (error); > } > >> ??Hans?? >> >>> There is a question about whether to avoid the conditional locking in >>> dev/sound/pcm/channel.c in favour of recursive locking? > > That is also possible. The type of the mutex in question can be changed. The > feedback I've gotten so far has been against the use of recursive mutexes. > Alternativly, expose two variants of the function in question: > > xxx_unlocked() > xxx_locked() It is correct that in general recursive locking is considered undesirable, but you should also not play games to work around the fact that your locking is in fact being called recursively, as in: - CHN_LOCK(c); + uint8_t do_unlock; + if (CHN_LOCK_OWNED(c)) { + /* + * Allow sound drivers to call this function with + * "CHN_LOCK()" locked: + */ + do_unlock = 0; + } else { + do_unlock = 1; + CHN_LOCK(c); + } >>> The locking in dev/sound/pcm/mixer.c appears to be strange; the >>> locking appears to have substantially changed without corresponding >>> changes to the non-USB drivers. > > All the mixer changes are in the detach code for the mixer and should not > require any changes to non-USB drivers. The change here: - snd_mtxlock(m->lock); + /* mixer uninit can sleep --hps */ MIXER_UNINIT(m); @@ -704,14 +704,24 @@ return EBUSY; } + /* destroy dev can sleep --hps */ + + snd_mtxunlock(m->lock); + pdev->si_drv1 = NULL; destroy_dev(pdev); + snd_mtxlock(m->lock); + for (i = 0; i < SOUND_MIXER_NRDEVICES; i++) mixer_set(m, i, 0); mixer_setrecsrc(m, SOUND_MASK_MIC); + snd_mtxunlock(m->lock); seems to change locking since you remove a mtx_lock and don't add it back anywhere. However it looks like it may have been a bug in the old code, I am not sure. Also is it safe to drop and reacquire the lock here? What do the sound maintainers think about these changes? >>> Some of the new sound drivers are Giant-locked? I am not sure we >>> should be adding new drivers that are not mpsafe. > > I assume that you mean USB drivers? s/sound/USB/ I am referring to this: +struct mtx * +mixer_get_lock(struct snd_mixer *m) +{ + if (m->lock == NULL) { + return (&Giant); + } + return (m->lock); +} This seems to say that m->lock now may be NULL in situations where it was not before (since there is no handling for m->lock == NULL in existing parts of the code), so the Giant locking is new. > Regarding Giant use: > > All USB drivers that can work without Giant has been converted to work without > Giant. Some USB drivers like USB serial port drivers cannot work without > Giant because they depend on a Giant locked TTY layer. Same with keyboard. > Another example is UHUB which use Giant simply because the device_xxx() > functions require Giant. > > The Giant lock is not used in any critical paths. > >> I think this will be addressed shortly... but.. >> > >> (please comment) >> >>> There seems to be a README.TXT but no manpages for the new API or >>> drivers. Are these pending? > > The manpages are not ready. This is something I need to do. I would appreciate > some help here like where I find manpage templates and where I should put > these files. The doc@ folks can probably answer this question if you ask them. It's also worth recalling that people asked for this 3 months ago as part of the process of getting this code commit-ready. >>> Why is the diff to compat/ndis/ntoskrnl_var.h necessary? >> It's needed for compiling usb2_ndis, but... > > Without this patch the usb2_ndis module will not compile on certain > architectures. If you remove this patch you will need to decouple the > usb2_ndis module, which is not complete anyway, from the default build. Why will it not compile? This looks like a workaround for some other issue that should be solved directly. Anyway, if the module is not complete then it should probably not be imported until it is. Kris From alfred at freebsd.org Tue Aug 19 20:00:18 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue Aug 19 20:00:24 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <48AB233C.2010602@FreeBSD.org> References: <20080818205914.GJ16977@elvis.mu.org> <20080818214711.J88849@maildrop.int.zabbadoz.net> <20080819055821.GO16977@elvis.mu.org> <200808191758.22981.hselasky@c2i.net> <48AB233C.2010602@FreeBSD.org> Message-ID: <20080819200017.GC16977@elvis.mu.org> * Kris Kennaway [080819 12:47] wrote: > Hans Petter Selasky wrote: > >Hi, > > > >On Tuesday 19 August 2008, Alfred Perlstein wrote: > >>Hans, here's some final review questions, I've added responses > >>where I can recall off the top of my head answers, but I need > >>you to fill in the rest. > > Just so we are clear, this is actually an "initial review" since it's > the first time the commit candidate has been posted for public review, > as far as I can tell. Kris, Hans usb code has been in a public repository with patches posted to the lists for a long time. > >>need to wait for smp tty code. > > > >If this requires changes in the USB serial port drivers there will be > >trouble. > > I am not sure what you mean by this statement, since it can be > interpreted in several ways, some not so friendly. I think hans means that there might be trouble in the usb2 system, but that doesn't spread out to anything else. If there's a problem in usb2, then don't use it, we'll fix it shortly. > >>>The patch only includes kernel parts, is there any impact on userland? > > > >No. Userland will build like before. The current USB userland utilities > >and libusb from ports will only work with the old USB stack. I'm working > >on a replacement for "usbdevs" called "usbconfig" which has some more > >functionality and a FreeBSD specific libusb, which is compatible with > >libusb from sourceforge. I have most of it finished in my private SVN > >repository, and will add it to my P4 repository soon. > > This raises the question of why the kernel changes need to be committed > now, and what benefit they bring in the absence of a compatible > userland. Shouldn't the commit happen after both kernel and userland > are ready (and reviewed)? This is a huge amount of code to haul around... again, we are not getting rid of "oldusb", if you don't want to be bleeding edge usb2, then you don't need it. > Another comment: the new code seems to bundle all new drivers into > "subsystems" but not allow them to be loaded individually. This is > quite contrary to how the rest of the kernel is structured, and seems to > be of questionable benefit. For example, users will rarely have more > than one USB ethernet driver in use on a given system but "device > usb2_ethernet" will compile in all 7 drivers. Interem issue, this is just to reduce the complexity for the time being, we will "remodularize it" before it replaces "oldusb" or as needed. > >>I think the userland tools need to be switched to the new headers, > >>however what's more likely to happen is that after a soak period of > >>a few weeks, we will move the new to replace the old and userland should > >>be just fine. > >> > >>>There are various style bugs introduced. That could be fixed easily I > >>>guess? > >>Yes, this is a LOT of new code, let's leave a few whitespace nits for > >>others to play with. :) > > > >All code has been and is continuously styled with a modified "indent" > >utility: > > > >(cat $F | indent -Toss_mixerinfo -TFILE -Tu_char -Tu_int -Tu_long \ > > -TTAILQ_HEAD -TLIST_HEAD -TTAILQ_ENTRY -TLIST_ENTRY \ > > -TSTAILQ_HEAD -TSTAILQ_ENTRY \ > > -Tu_short -Tfd_set -ta -st -bad -bap -nbbb -nbc -br -nbs \ > > -c41 -cd41 -cdb -ce -ci4 -cli0 -d0 -di8 -ndj -ei -nfc1 \ > > -nfcb -i8 -ip8 -l79 -lc77 -ldi0 -nlp -npcs -psl -sc \ > > -nsob -nv | > > sed -e "s/_HEAD [(]/_HEAD(/g" | > > sed -e "s/_ENTRY [(]/_ENTRY(/g" | > > sed -e "s/ __packed/ __packed/g" | > > sed -e "s/ __aligned/ __aligned/g" | > > sed -e "s/^#define /#define /g") > temp > > > >If there are any more options I can add, then please let me know. > > Mechanical indent tools can be a useful starting point for style(9) > compliance but are not the end point of that process. Usually there > will need to be manual tweaks. That is fine. > > >>>In kern/subr_bus.c you are taking steps to avoid zero size > >>>allocations, which haven't been there up to now. Why do we need that? > > > >It is a workaround. USB2 defines the following function, which can be > >called when there are no children on a device, which must be handled > >correctly cross-platform. If this function could be directly implemented > >in subr_bus.c we would not require the modifications to > >"device_get_children" at all or any memory allocation. > > What do the newbus guys say about this? Adding a workaround in > underlying code for a problem caused by your own code is often a signal > that you're not going about it the right way. At the very least the > reason for the special case should be documented here. I need to think about this, Hans gave me a better argument on AIM earlier for it, I need to reload this in my head. > >int > >device_delete_all_children(device_t dev) > >{ > > device_t *devlist; > > int devcount; > > int error; > > > > error = device_get_children(dev, &devlist, &devcount); > > if (error == 0) { > > while (devcount-- > 0) { > > error = device_delete_child(dev, > > devlist[devcount]); > > if (error) { > > break; > > } > > } > > free(devlist, M_TEMP); > > } > > return (error); > >} > > > >>??Hans?? > >> > >>>There is a question about whether to avoid the conditional locking in > >>>dev/sound/pcm/channel.c in favour of recursive locking? > > > >That is also possible. The type of the mutex in question can be changed. > >The feedback I've gotten so far has been against the use of recursive > >mutexes. Alternativly, expose two variants of the function in question: > > > >xxx_unlocked() > >xxx_locked() > > It is correct that in general recursive locking is considered > undesirable, but you should also not play games to work around the fact > that your locking is in fact being called recursively, as in: > > - CHN_LOCK(c); > + uint8_t do_unlock; > + if (CHN_LOCK_OWNED(c)) { > + /* > + * Allow sound drivers to call this function with > + * "CHN_LOCK()" locked: > + */ > + do_unlock = 0; > + } else { > + do_unlock = 1; > + CHN_LOCK(c); > + } Yes, but sometimes it's hard to do so. I think such things can be addressed. Do consider the amount of progress here, and realize it's a giant step forward with a few nits we can address with time. > >>>The locking in dev/sound/pcm/mixer.c appears to be strange; the > >>>locking appears to have substantially changed without corresponding > >>>changes to the non-USB drivers. > > > >All the mixer changes are in the detach code for the mixer and should not > >require any changes to non-USB drivers. > > The change here: > > - snd_mtxlock(m->lock); > + /* mixer uninit can sleep --hps */ > > MIXER_UNINIT(m); > > @@ -704,14 +704,24 @@ > return EBUSY; > } > > + /* destroy dev can sleep --hps */ > + > + snd_mtxunlock(m->lock); > + > pdev->si_drv1 = NULL; > destroy_dev(pdev); > > + snd_mtxlock(m->lock); > + > for (i = 0; i < SOUND_MIXER_NRDEVICES; i++) > mixer_set(m, i, 0); > > mixer_setrecsrc(m, SOUND_MASK_MIC); > > + snd_mtxunlock(m->lock); > > seems to change locking since you remove a mtx_lock and don't add it > back anywhere. However it looks like it may have been a bug in the old > code, I am not sure. Also is it safe to drop and reacquire the lock here? > > What do the sound maintainers think about these changes? > > >>>Some of the new sound drivers are Giant-locked? I am not sure we > >>>should be adding new drivers that are not mpsafe. > > > >I assume that you mean USB drivers? s/sound/USB/ > > I am referring to this: > > +struct mtx * > +mixer_get_lock(struct snd_mixer *m) > +{ > + if (m->lock == NULL) { > + return (&Giant); > + } > + return (m->lock); > +} > > This seems to say that m->lock now may be NULL in situations where it > was not before (since there is no handling for m->lock == NULL in > existing parts of the code), so the Giant locking is new. > > >Regarding Giant use: > > > >All USB drivers that can work without Giant has been converted to work > >without Giant. Some USB drivers like USB serial port drivers cannot work > >without Giant because they depend on a Giant locked TTY layer. Same with > >keyboard. Another example is UHUB which use Giant simply because the > >device_xxx() functions require Giant. > > > >The Giant lock is not used in any critical paths. > > > >>I think this will be addressed shortly... but.. > >> > > > >>(please comment) > >> > >>>There seems to be a README.TXT but no manpages for the new API or > >>>drivers. Are these pending? > > > >The manpages are not ready. This is something I need to do. I would > >appreciate some help here like where I find manpage templates and where I > >should put these files. > > The doc@ folks can probably answer this question if you ask them. It's > also worth recalling that people asked for this 3 months ago as part of > the process of getting this code commit-ready. Can we consider leveraging the doc people and doing the docs post commit? I think we can get something nice in short time. > > >>>Why is the diff to compat/ndis/ntoskrnl_var.h necessary? > >>It's needed for compiling usb2_ndis, but... > > > >Without this patch the usb2_ndis module will not compile on certain > >architectures. If you remove this patch you will need to decouple the > >usb2_ndis module, which is not complete anyway, from the default build. > > Why will it not compile? This looks like a workaround for some other > issue that should be solved directly. > > Anyway, if the module is not complete then it should probably not be > imported until it is. Yes, but it breaks the module without it, so it's a chicken and egg issue, having to haul around a patch that will eventually have to go in anyhow doesn't make much sense. At the end of this all, there are some small requests in here along with some large requests, if you take the time to add up the time needed to get all of this according to your request, it pushes back the delivery of the essential kernel functionality by several weeks if not months. -- - Alfred Perlstein From alfred at freebsd.org Tue Aug 19 20:00:54 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue Aug 19 20:01:00 2008 Subject: HEADSUP new usb code coming in. Message-ID: <20080819194413.GB16977@elvis.mu.org> After a long period of review and testing I am on the verge of committing Hans Peter's new usb stack to -current. The patchset requires a SMALL _493_ line diff to the main code, mostly bug fixes to arm. And then a large number of new files for the usb system. The new usb system will be committed as separate files with the intention of folding them over the old files before the 9.0 release. The diff to the main files is here: http://mu.org/~bright/usb2/usb2_release_001.diff The whole diff, including new files is here: http://mu.org/~bright/usb2/usb4bsd.diff.gz FAQ: Q. Has this been reviewed? A. Yes, pretty strongly by myself and we've consulted with various others, Warner, Scott and Andrew for review/testing. I wouldn't say that Warner or Scott have given full review but just about all questions have been answered. Q. Can we change the name from "usb2_" to my favorite name? A. No. This is for a short period, stop being so annoying. Q. What about the old usb code? A. What about it? :D Q. What about ttys? A. I don't know, we'll address the mpsafe aspects of ttys shortly, Hans is very responsive to SMP issues. Q. Shouldn't you wait? A. Wait for what? No. Q. I have some whitespace nits, can you do those? A. No. It's a 100k line diff and a 3meg delta, we tried really hard to get all whitespace right, but you're welcome to point things out after the commit. Thanks! -- - Alfred Perlstein From alfred at freebsd.org Tue Aug 19 20:01:52 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue Aug 19 20:02:00 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080819195738.GB45668@freebie.xs4all.nl> References: <20080819194413.GB16977@elvis.mu.org> <20080819195738.GB45668@freebie.xs4all.nl> Message-ID: <20080819200152.GD16977@elvis.mu.org> * Wilko Bulte [080819 12:59] wrote: > Quoting Alfred Perlstein, who wrote on Tue, Aug 19, 2008 at 12:44:13PM -0700 .. > > After a long period of review and testing I am on the verge of > > committing Hans Peter's new usb stack to -current. > > > > The patchset requires a SMALL _493_ line diff to the main code, > > mostly bug fixes to arm. And then a large number of new files > > for the usb system. > > > > The new usb system will be committed as separate files with > > the intention of folding them over the old files before the > > 9.0 release. > > > > The diff to the main files is here: > > http://mu.org/~bright/usb2/usb2_release_001.diff > > > > The whole diff, including new files is here: > > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > > > FAQ: > > Q. Has this been reviewed? > > A. Yes, pretty strongly by myself and we've consulted with > > various others, Warner, Scott and Andrew for review/testing. > > I wouldn't say that Warner or Scott have given full review > > but just about all questions have been answered. > > > > Q. Can we change the name from "usb2_" to my favorite name? > > A. No. This is for a short period, stop being so annoying. > > > > Q. What about the old usb code? > > A. What about it? :D > > > > Q. What about ttys? > > A. I don't know, we'll address the mpsafe aspects of ttys shortly, > > Hans is very responsive to SMP issues. > > > > Q. Shouldn't you wait? > > A. Wait for what? No. > > Well, Robert *explicitely* asked to wait for the tty stuff from Ed > to get into the tree. > > Apparantly you are planning on simply ignoring that request? I have acknowledged it, I don't find it necessary and am annoyed by it. I don't plan on side stepping it, but I do protest it, strongly as just unneeded process. I think I am entitled to an opinion and to gather support for my opinions, right? -- - Alfred Perlstein From wb at freebie.xs4all.nl Tue Aug 19 20:16:36 2008 From: wb at freebie.xs4all.nl (Wilko Bulte) Date: Tue Aug 19 20:16:54 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080819194413.GB16977@elvis.mu.org> References: <20080819194413.GB16977@elvis.mu.org> Message-ID: <20080819195738.GB45668@freebie.xs4all.nl> Quoting Alfred Perlstein, who wrote on Tue, Aug 19, 2008 at 12:44:13PM -0700 .. > After a long period of review and testing I am on the verge of > committing Hans Peter's new usb stack to -current. > > The patchset requires a SMALL _493_ line diff to the main code, > mostly bug fixes to arm. And then a large number of new files > for the usb system. > > The new usb system will be committed as separate files with > the intention of folding them over the old files before the > 9.0 release. > > The diff to the main files is here: > http://mu.org/~bright/usb2/usb2_release_001.diff > > The whole diff, including new files is here: > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > FAQ: > Q. Has this been reviewed? > A. Yes, pretty strongly by myself and we've consulted with > various others, Warner, Scott and Andrew for review/testing. > I wouldn't say that Warner or Scott have given full review > but just about all questions have been answered. > > Q. Can we change the name from "usb2_" to my favorite name? > A. No. This is for a short period, stop being so annoying. > > Q. What about the old usb code? > A. What about it? :D > > Q. What about ttys? > A. I don't know, we'll address the mpsafe aspects of ttys shortly, > Hans is very responsive to SMP issues. > > Q. Shouldn't you wait? > A. Wait for what? No. Well, Robert *explicitely* asked to wait for the tty stuff from Ed to get into the tree. Apparantly you are planning on simply ignoring that request? Wilko From hselasky at c2i.net Tue Aug 19 20:17:45 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Aug 19 20:17:53 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <48AB233C.2010602@FreeBSD.org> References: <20080818205914.GJ16977@elvis.mu.org> <200808191758.22981.hselasky@c2i.net> <48AB233C.2010602@FreeBSD.org> Message-ID: <200808192219.19246.hselasky@c2i.net> Hi, On Tuesday 19 August 2008, Kris Kennaway wrote: > Hans Petter Selasky wrote: > > Hi, > > > > On Tuesday 19 August 2008, Alfred Perlstein wrote: > >> Hans, here's some final review questions, I've added responses > >> where I can recall off the top of my head answers, but I need > >> you to fill in the rest. > > Just so we are clear, this is actually an "initial review" since it's > the first time the commit candidate has been posted for public review, > as far as I can tell. > > >> need to wait for smp tty code. > > > > If this requires changes in the USB serial port drivers there will be > > trouble. > > I am not sure what you mean by this statement, since it can be > interpreted in several ways, some not so friendly. I mean I need to make another patchset. And that the current patchset will break the kernel compilation if blindly committed after mpsafetty. > > >>> The patch only includes kernel parts, is there any impact on userland? > > > > No. Userland will build like before. The current USB userland utilities > > and libusb from ports will only work with the old USB stack. I'm working > > on a replacement for "usbdevs" called "usbconfig" which has some more > > functionality and a FreeBSD specific libusb, which is compatible with > > libusb from sourceforge. I have most of it finished in my private SVN > > repository, and will add it to my P4 repository soon. > > This raises the question of why the kernel changes need to be committed > now, and what benefit they bring in the absence of a compatible > userland. Shouldn't the commit happen after both kernel and userland > are ready (and reviewed)? I think that is correct. > > Another comment: the new code seems to bundle all new drivers into > "subsystems" but not allow them to be loaded individually. This is > quite contrary to how the rest of the kernel is structured, and seems to > be of questionable benefit. For example, users will rarely have more > than one USB ethernet driver in use on a given system but "device > usb2_ethernet" will compile in all 7 drivers. It is still possible to separate the USB drivers. In my experience grouping the drivers gives a more user-friendly experience. For example you have a USB serial port adapter and plug it in. Then all you need to do is to kldload usb2_serial regardless of adapter. It is like a container module. I don't opponent that for kernel compilation you can have a more fine-grained control what drivers are actually included. I will see about fixing that. > > >> I think the userland tools need to be switched to the new headers, > >> however what's more likely to happen is that after a soak period of > >> a few weeks, we will move the new to replace the old and userland should > >> be just fine. > >> > >>> There are various style bugs introduced. That could be fixed easily I > >>> guess? > >> > >> Yes, this is a LOT of new code, let's leave a few whitespace nits for > >> others to play with. :) > > > > All code has been and is continuously styled with a modified "indent" > > utility: > > > > (cat $F | indent -Toss_mixerinfo -TFILE -Tu_char -Tu_int -Tu_long \ > > -TTAILQ_HEAD -TLIST_HEAD -TTAILQ_ENTRY -TLIST_ENTRY \ > > -TSTAILQ_HEAD -TSTAILQ_ENTRY \ > > -Tu_short -Tfd_set -ta -st -bad -bap -nbbb -nbc -br -nbs \ > > -c41 -cd41 -cdb -ce -ci4 -cli0 -d0 -di8 -ndj -ei -nfc1 \ > > -nfcb -i8 -ip8 -l79 -lc77 -ldi0 -nlp -npcs -psl -sc \ > > -nsob -nv | > > sed -e "s/_HEAD [(]/_HEAD(/g" | > > sed -e "s/_ENTRY [(]/_ENTRY(/g" | > > sed -e "s/ __packed/ __packed/g" | > > sed -e "s/ __aligned/ __aligned/g" | > > sed -e "s/^#define /#define /g") > temp > > > > If there are any more options I can add, then please let me know. > > Mechanical indent tools can be a useful starting point for style(9) > compliance but are not the end point of that process. Usually there > will need to be manual tweaks. > > >>> In kern/subr_bus.c you are taking steps to avoid zero size > >>> allocations, which haven't been there up to now. Why do we need that? > > > > It is a workaround. USB2 defines the following function, which can be > > called when there are no children on a device, which must be handled > > correctly cross-platform. If this function could be directly implemented > > in subr_bus.c we would not require the modifications to > > "device_get_children" at all or any memory allocation. > > What do the newbus guys say about this? Adding a workaround in > underlying code for a problem caused by your own code is often a signal > that you're not going about it the right way. At the very least the > reason for the special case should be documented here. > > > int > > device_delete_all_children(device_t dev) > > { > > device_t *devlist; > > int devcount; > > int error; > > > > error = device_get_children(dev, &devlist, &devcount); > > if (error == 0) { > > while (devcount-- > 0) { > > error = device_delete_child(dev, > > devlist[devcount]); if (error) { > > break; > > } > > } > > free(devlist, M_TEMP); > > } > > return (error); > > } > > > >> ??Hans?? > >> > >>> There is a question about whether to avoid the conditional locking in > >>> dev/sound/pcm/channel.c in favour of recursive locking? > > > > That is also possible. The type of the mutex in question can be changed. > > The feedback I've gotten so far has been against the use of recursive > > mutexes. Alternativly, expose two variants of the function in question: > > > > xxx_unlocked() > > xxx_locked() > > It is correct that in general recursive locking is considered > undesirable, but you should also not play games to work around the fact > that your locking is in fact being called recursively, as in: > > - CHN_LOCK(c); > + uint8_t do_unlock; > + if (CHN_LOCK_OWNED(c)) { > + /* > + * Allow sound drivers to call this function with > + * "CHN_LOCK()" locked: > + */ > + do_unlock = 0; > + } else { > + do_unlock = 1; > + CHN_LOCK(c); > + } > > >>> The locking in dev/sound/pcm/mixer.c appears to be strange; the > >>> locking appears to have substantially changed without corresponding > >>> changes to the non-USB drivers. > > > > All the mixer changes are in the detach code for the mixer and should not > > require any changes to non-USB drivers. > > The change here: > > - snd_mtxlock(m->lock); > + /* mixer uninit can sleep --hps */ > > MIXER_UNINIT(m); > > @@ -704,14 +704,24 @@ > return EBUSY; > } > > + /* destroy dev can sleep --hps */ > + > + snd_mtxunlock(m->lock); > + > pdev->si_drv1 = NULL; > destroy_dev(pdev); > > + snd_mtxlock(m->lock); > + > for (i = 0; i < SOUND_MIXER_NRDEVICES; i++) > mixer_set(m, i, 0); > > mixer_setrecsrc(m, SOUND_MASK_MIC); > > + snd_mtxunlock(m->lock); > > seems to change locking since you remove a mtx_lock and don't add it > back anywhere. This is because the mtx_lock/unlock was unbalanced in the first place! The original code used to call mtx_destroy with the mutex locked. Now I added an unlock before the destroy. snd_mtxunlock(m->lock); /* mixer uninit can sleep --hps */ MIXER_UNINIT(m); snd_mtxfree(m->lock); > However it looks like it may have been a bug in the old > code, I am not sure. Right. > Also is it safe to drop and reacquire the lock here? You have to drop the lock, else I get witness warnings. > > What do the sound maintainers think about these changes? > > >>> Some of the new sound drivers are Giant-locked? I am not sure we > >>> should be adding new drivers that are not mpsafe. > > > > I assume that you mean USB drivers? s/sound/USB/ > > I am referring to this: > > +struct mtx * > +mixer_get_lock(struct snd_mixer *m) > +{ > + if (m->lock == NULL) { > + return (&Giant); > + } > + return (m->lock); > +} > > This seems to say that m->lock now may be NULL in situations where it > was not before (since there is no handling for m->lock == NULL in > existing parts of the code), so the Giant locking is new. That is just a safety measure, because the Sound code has some ifdef's to enable it to run without mutexes, and in that case Giant must be used. > > > Regarding Giant use: > > > > All USB drivers that can work without Giant has been converted to work > > without Giant. Some USB drivers like USB serial port drivers cannot work > > without Giant because they depend on a Giant locked TTY layer. Same with > > keyboard. Another example is UHUB which use Giant simply because the > > device_xxx() functions require Giant. > > > > The Giant lock is not used in any critical paths. > > > >> I think this will be addressed shortly... but.. > >> > >> > >> (please comment) > >> > >>> There seems to be a README.TXT but no manpages for the new API or > >>> drivers. Are these pending? > > > > The manpages are not ready. This is something I need to do. I would > > appreciate some help here like where I find manpage templates and where I > > should put these files. > > The doc@ folks can probably answer this question if you ask them. It's > also worth recalling that people asked for this 3 months ago as part of > the process of getting this code commit-ready. > > >>> Why is the diff to compat/ndis/ntoskrnl_var.h necessary? > >> > >> It's needed for compiling usb2_ndis, but... > > > > Without this patch the usb2_ndis module will not compile on certain > > architectures. If you remove this patch you will need to decouple the > > usb2_ndis module, which is not complete anyway, from the default build. > > Why will it not compile? This looks like a workaround for some other > issue that should be solved directly. There are multiple issues: 1) If PAGE_SIZE is 16384 bytes, then the code simply fails. 2) Sometimes PAGE_SHIFT is already defined. #if PAGE_SIZE == 4096 #define PAGE_SHIFT 12 #elif PAGE_SIZE == 8192 #define PAGE_SHIFT 13 #else #error PAGE_SHIFT undefined! #endif > > Anyway, if the module is not complete then it should probably not be > imported until it is. Yes, I agree about that. --HPS From oberman at es.net Tue Aug 19 20:20:06 2008 From: oberman at es.net (Kevin Oberman) Date: Tue Aug 19 20:20:13 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: Your message of "Tue, 19 Aug 2008 12:44:13 PDT." <20080819194413.GB16977@elvis.mu.org> Message-ID: <20080819200911.224754500F@ptavv.es.net> > Date: Tue, 19 Aug 2008 12:44:13 -0700 > From: Alfred Perlstein > Sender: owner-freebsd-current@freebsd.org > > After a long period of review and testing I am on the verge of > committing Hans Peter's new usb stack to -current. > > The patchset requires a SMALL _493_ line diff to the main code, > mostly bug fixes to arm. And then a large number of new files > for the usb system. > > The new usb system will be committed as separate files with > the intention of folding them over the old files before the > 9.0 release. > > The diff to the main files is here: > http://mu.org/~bright/usb2/usb2_release_001.diff > > The whole diff, including new files is here: > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > FAQ: > Q. Has this been reviewed? > A. Yes, pretty strongly by myself and we've consulted with > various others, Warner, Scott and Andrew for review/testing. > I wouldn't say that Warner or Scott have given full review > but just about all questions have been answered. > > Q. Can we change the name from "usb2_" to my favorite name? > A. No. This is for a short period, stop being so annoying. > > Q. What about the old usb code? > A. What about it? :D > > Q. What about ttys? > A. I don't know, we'll address the mpsafe aspects of ttys shortly, > Hans is very responsive to SMP issues. > > Q. Shouldn't you wait? > A. Wait for what? No. > > Q. I have some whitespace nits, can you do those? > A. No. It's a 100k line diff and a 3meg delta, we tried really hard > to get all whitespace right, but you're welcome to point things out after > the commit. Cool! I've been waiting for this for a loooooong time. Thanks to you, Hans Peter and all of the folks who have helped! Not on the FAQ: Q: Other then no longer requiring giant [MPSAFE], what does usb2 give us? Does it fix the battery-eating on laptops? Does it allow the system to reach C3 and lower sleep states? (These are at least closely linked issues.) I have not been running current for a while and this might be enough incentive to get me to kick the tires. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20080819/febf2591/attachment.pgp From hselasky at c2i.net Tue Aug 19 20:27:02 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Aug 19 20:27:09 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <20080819200017.GC16977@elvis.mu.org> References: <20080818205914.GJ16977@elvis.mu.org> <48AB233C.2010602@FreeBSD.org> <20080819200017.GC16977@elvis.mu.org> Message-ID: <200808192228.39015.hselasky@c2i.net> > > > > What do the newbus guys say about this? Adding a workaround in > > underlying code for a problem caused by your own code is often a signal > > that you're not going about it the right way. At the very least the > > reason for the special case should be documented here. > > I need to think about this, Hans gave me a better argument on > AIM earlier for it, I need to reload this in my head. > > > >int > > >device_delete_all_children(device_t dev) > > >{ > > > device_t *devlist; > > > int devcount; > > > int error; > > > > > > error = device_get_children(dev, &devlist, &devcount); > > > if (error == 0) { > > > while (devcount-- > 0) { > > > error = device_delete_child(dev, > > > devlist[devcount]); > > > if (error) { > > > break; > > > } > > > } > > > free(devlist, M_TEMP); > > > } > > > return (error); > > >} > > > In the existing kernel code, "device_get_children()" is used many places without checking the error code. I have patches, but they are not part of the patch-set. Also freeing a pointer to zero bytes is not logical. I'm not sure if this is allowed in kernel space? ptr = malloc(0, ... ) free(0); The device_get_children() could have returned an error if there are no children, but again, the existing code does not check this return value. --HPS From alfred at freebsd.org Tue Aug 19 20:27:59 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue Aug 19 20:28:10 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <48AB2A1C.4080808@moneybookers.com> References: <20080819194413.GB16977@elvis.mu.org> <48AB2A1C.4080808@moneybookers.com> Message-ID: <20080819202757.GG16977@elvis.mu.org> * Stefan Lambrev [080819 13:16] wrote: > Alfred Perlstein wrote: > >After a long period of review and testing I am on the verge of > >committing Hans Peter's new usb stack to -current. > > > >The patchset requires a SMALL _493_ line diff to the main code, > >mostly bug fixes to arm. And then a large number of new files > >for the usb system. > > > >The new usb system will be committed as separate files with > >the intention of folding them over the old files before the > >9.0 release. > > > >The diff to the main files is here: > >http://mu.org/~bright/usb2/usb2_release_001.diff > > > >The whole diff, including new files is here: > >http://mu.org/~bright/usb2/usb4bsd.diff.gz > > > >FAQ: > >Q. Has this been reviewed? > >A. Yes, pretty strongly by myself and we've consulted with > >various others, Warner, Scott and Andrew for review/testing. > >I wouldn't say that Warner or Scott have given full review > >but just about all questions have been answered. > > > >Q. Can we change the name from "usb2_" to my favorite name? > >A. No. This is for a short period, stop being so annoying. > > > >Q. What about the old usb code? > >A. What about it? :D > > > >Q. What about ttys? > >A. I don't know, we'll address the mpsafe aspects of ttys shortly, > >Hans is very responsive to SMP issues. > > > >Q. Shouldn't you wait? > >A. Wait for what? No. > > > >Q. I have some whitespace nits, can you do those? > >A. No. It's a 100k line diff and a 3meg delta, we tried really hard > >to get all whitespace right, but you're welcome to point things out after > >the commit. > > > >Thanks! > > > > > Is this the same as usb4bsd - http://turbocat.net/~hselasky/usb4bsd/ ? Yes. > > As user I think this is great news. Old usb is so buggy and there are > lot of PR that are not addressed > only because in the new usb stack they are fixed or just does not exist > and nobody care for the old usb anymore. Yup! :) -- - Alfred Perlstein From alfred at freebsd.org Tue Aug 19 20:28:35 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue Aug 19 20:28:42 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080819200911.224754500F@ptavv.es.net> References: <20080819194413.GB16977@elvis.mu.org> <20080819200911.224754500F@ptavv.es.net> Message-ID: <20080819202834.GH16977@elvis.mu.org> * Kevin Oberman [080819 13:20] wrote: > > Date: Tue, 19 Aug 2008 12:44:13 -0700 > > From: Alfred Perlstein > > Sender: owner-freebsd-current@freebsd.org > > > > After a long period of review and testing I am on the verge of > > committing Hans Peter's new usb stack to -current. > > > > The patchset requires a SMALL _493_ line diff to the main code, > > mostly bug fixes to arm. And then a large number of new files > > for the usb system. > > > > The new usb system will be committed as separate files with > > the intention of folding them over the old files before the > > 9.0 release. > > > > The diff to the main files is here: > > http://mu.org/~bright/usb2/usb2_release_001.diff > > > > The whole diff, including new files is here: > > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > > > FAQ: > > Q. Has this been reviewed? > > A. Yes, pretty strongly by myself and we've consulted with > > various others, Warner, Scott and Andrew for review/testing. > > I wouldn't say that Warner or Scott have given full review > > but just about all questions have been answered. > > > > Q. Can we change the name from "usb2_" to my favorite name? > > A. No. This is for a short period, stop being so annoying. > > > > Q. What about the old usb code? > > A. What about it? :D > > > > Q. What about ttys? > > A. I don't know, we'll address the mpsafe aspects of ttys shortly, > > Hans is very responsive to SMP issues. > > > > Q. Shouldn't you wait? > > A. Wait for what? No. > > > > Q. I have some whitespace nits, can you do those? > > A. No. It's a 100k line diff and a 3meg delta, we tried really hard > > to get all whitespace right, but you're welcome to point things out after > > the commit. > > Cool! I've been waiting for this for a loooooong time. Thanks to you, > Hans Peter and all of the folks who have helped! thanks! > > Not on the FAQ: > > Q: Other then no longer requiring giant [MPSAFE], what does usb2 give > us? Does it fix the battery-eating on laptops? Does it allow the > system to reach C3 and lower sleep states? (These are at least > closely linked issues.) > > I have not been running current for a while and this might be enough > incentive to get me to kick the tires. I don't know, I'm not aware as that being a feature, but Hans is pretty ambitious, he might jump on it. -Alfred From stefan.lambrev at moneybookers.com Tue Aug 19 20:34:05 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Tue Aug 19 20:34:17 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080819194413.GB16977@elvis.mu.org> References: <20080819194413.GB16977@elvis.mu.org> Message-ID: <48AB2A1C.4080808@moneybookers.com> Alfred Perlstein wrote: > After a long period of review and testing I am on the verge of > committing Hans Peter's new usb stack to -current. > > The patchset requires a SMALL _493_ line diff to the main code, > mostly bug fixes to arm. And then a large number of new files > for the usb system. > > The new usb system will be committed as separate files with > the intention of folding them over the old files before the > 9.0 release. > > The diff to the main files is here: > http://mu.org/~bright/usb2/usb2_release_001.diff > > The whole diff, including new files is here: > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > FAQ: > Q. Has this been reviewed? > A. Yes, pretty strongly by myself and we've consulted with > various others, Warner, Scott and Andrew for review/testing. > I wouldn't say that Warner or Scott have given full review > but just about all questions have been answered. > > Q. Can we change the name from "usb2_" to my favorite name? > A. No. This is for a short period, stop being so annoying. > > Q. What about the old usb code? > A. What about it? :D > > Q. What about ttys? > A. I don't know, we'll address the mpsafe aspects of ttys shortly, > Hans is very responsive to SMP issues. > > Q. Shouldn't you wait? > A. Wait for what? No. > > Q. I have some whitespace nits, can you do those? > A. No. It's a 100k line diff and a 3meg delta, we tried really hard > to get all whitespace right, but you're welcome to point things out after > the commit. > > Thanks! > > Is this the same as usb4bsd - http://turbocat.net/~hselasky/usb4bsd/ ? As user I think this is great news. Old usb is so buggy and there are lot of PR that are not addressed only because in the new usb stack they are fixed or just does not exist and nobody care for the old usb anymore. From stefan.lambrev at moneybookers.com Tue Aug 19 20:36:23 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Tue Aug 19 20:36:35 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080819200911.224754500F@ptavv.es.net> References: <20080819200911.224754500F@ptavv.es.net> Message-ID: <48AB2EC3.1030603@moneybookers.com> Kevin Oberman wrote: >> Date: Tue, 19 Aug 2008 12:44:13 -0700 >> From: Alfred Perlstein >> Sender: owner-freebsd-current@freebsd.org >> >> After a long period of review and testing I am on the verge of >> committing Hans Peter's new usb stack to -current. >> >> The patchset requires a SMALL _493_ line diff to the main code, >> mostly bug fixes to arm. And then a large number of new files >> for the usb system. >> >> The new usb system will be committed as separate files with >> the intention of folding them over the old files before the >> 9.0 release. >> >> The diff to the main files is here: >> http://mu.org/~bright/usb2/usb2_release_001.diff >> >> The whole diff, including new files is here: >> http://mu.org/~bright/usb2/usb4bsd.diff.gz >> >> FAQ: >> Q. Has this been reviewed? >> A. Yes, pretty strongly by myself and we've consulted with >> various others, Warner, Scott and Andrew for review/testing. >> I wouldn't say that Warner or Scott have given full review >> but just about all questions have been answered. >> >> Q. Can we change the name from "usb2_" to my favorite name? >> A. No. This is for a short period, stop being so annoying. >> >> Q. What about the old usb code? >> A. What about it? :D >> >> Q. What about ttys? >> A. I don't know, we'll address the mpsafe aspects of ttys shortly, >> Hans is very responsive to SMP issues. >> >> Q. Shouldn't you wait? >> A. Wait for what? No. >> >> Q. I have some whitespace nits, can you do those? >> A. No. It's a 100k line diff and a 3meg delta, we tried really hard >> to get all whitespace right, but you're welcome to point things out after >> the commit. >> > > Cool! I've been waiting for this for a loooooong time. Thanks to you, > Hans Peter and all of the folks who have helped! > > Not on the FAQ: > > Q: Other then no longer requiring giant [MPSAFE], what does usb2 give > us? I'm using usb4bsd on 7-stable even before 7R. It fixes few known kernel panics for me. I had a bad experience with base usb + GPRS card from vodafone which works on pcmci slot but is detected as usb device. I'm sure this is not the only improvement :) > Does it fix the battery-eating on laptops? Does it allow the > system to reach C3 and lower sleep states? (These are at least > closely linked issues.) > > I have not been running current for a while and this might be enough > incentive to get me to kick the tires. > From kris at FreeBSD.org Tue Aug 19 20:42:14 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Aug 19 20:42:20 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <20080819200017.GC16977@elvis.mu.org> References: <20080818205914.GJ16977@elvis.mu.org> <20080818214711.J88849@maildrop.int.zabbadoz.net> <20080819055821.GO16977@elvis.mu.org> <200808191758.22981.hselasky@c2i.net> <48AB233C.2010602@FreeBSD.org> <20080819200017.GC16977@elvis.mu.org> Message-ID: <48AB3023.2030307@FreeBSD.org> Alfred Perlstein wrote: > * Kris Kennaway [080819 12:47] wrote: >> Hans Petter Selasky wrote: >>> Hi, >>> >>> On Tuesday 19 August 2008, Alfred Perlstein wrote: >>>> Hans, here's some final review questions, I've added responses >>>> where I can recall off the top of my head answers, but I need >>>> you to fill in the rest. >> Just so we are clear, this is actually an "initial review" since it's >> the first time the commit candidate has been posted for public review, >> as far as I can tell. > > Kris, Hans usb code has been in a public repository with patches > posted to the lists for a long time. Having a public p4 branch is fine, but it's his active development branch including lots of stuff that may or may not be stable, finalized, intended for commit at all, etc. If you recall when you proposed the integration back in May, 3-4 people asked for the commit candidate patch then and didn't get one, and I haven't seen it posted on a mailing list since then either. If I missed a "commit candidate" email from you or Hans that was prior to last night's "post attempted commit", then I apologise, but as far as several of us can determine none was posted except possibly to some people in private email. The general intention of a USB integration in the future was well known for the past 3 months, but I think the fact that it you had intended to do it last night came as a complete surprise to many people who were expecting prior scheduling. >>>>> The patch only includes kernel parts, is there any impact on userland? >>> No. Userland will build like before. The current USB userland utilities >>> and libusb from ports will only work with the old USB stack. I'm working >>> on a replacement for "usbdevs" called "usbconfig" which has some more >>> functionality and a FreeBSD specific libusb, which is compatible with >>> libusb from sourceforge. I have most of it finished in my private SVN >>> repository, and will add it to my P4 repository soon. >> This raises the question of why the kernel changes need to be committed >> now, and what benefit they bring in the absence of a compatible >> userland. Shouldn't the commit happen after both kernel and userland >> are ready (and reviewed)? > > This is a huge amount of code to haul around... again, we are not > getting rid of "oldusb", if you don't want to be bleeding edge > usb2, then you don't need it. It just strikes me as odd that one half of the code needs to be committed urgently when the other is not finished. I was of the belief that you and Hans considered the USB code to be "complete" and hence ready for integration, but it sounds like there are large parts still incomplete or in flux. Some explanation of why this is not the case would help to clarify things. >>>>> There is a question about whether to avoid the conditional locking in >>>>> dev/sound/pcm/channel.c in favour of recursive locking? >>> That is also possible. The type of the mutex in question can be changed. >>> The feedback I've gotten so far has been against the use of recursive >>> mutexes. Alternativly, expose two variants of the function in question: >>> >>> xxx_unlocked() >>> xxx_locked() >> It is correct that in general recursive locking is considered >> undesirable, but you should also not play games to work around the fact >> that your locking is in fact being called recursively, as in: >> >> - CHN_LOCK(c); >> + uint8_t do_unlock; >> + if (CHN_LOCK_OWNED(c)) { >> + /* >> + * Allow sound drivers to call this function with >> + * "CHN_LOCK()" locked: >> + */ >> + do_unlock = 0; >> + } else { >> + do_unlock = 1; >> + CHN_LOCK(c); >> + } > > Yes, but sometimes it's hard to do so. > > I think such things can be addressed. Do consider the amount of > progress here, and realize it's a giant step forward with a few > nits we can address with time. I am taking no position on the bits of code I didn't review, but I hope we can agree that technical questions about subsets of the patch that were reviewed are worth resolving. Usually such concerns are resolved as part of the process of preparation for a commit. >>>>> There seems to be a README.TXT but no manpages for the new API or >>>>> drivers. Are these pending? >>> The manpages are not ready. This is something I need to do. I would >>> appreciate some help here like where I find manpage templates and where I >>> should put these files. >> The doc@ folks can probably answer this question if you ask them. It's >> also worth recalling that people asked for this 3 months ago as part of >> the process of getting this code commit-ready. > > Can we consider leveraging the doc people and doing the docs post > commit? I think we can get something nice in short time. It sounds reasonable to me if you and Hans are going to work together on that with the doc guys. Presumably this process would not just involve someone from doc@ writing all the manpages though. >>>>> Why is the diff to compat/ndis/ntoskrnl_var.h necessary? >>>> It's needed for compiling usb2_ndis, but... >>> Without this patch the usb2_ndis module will not compile on certain >>> architectures. If you remove this patch you will need to decouple the >>> usb2_ndis module, which is not complete anyway, from the default build. >> Why will it not compile? This looks like a workaround for some other >> issue that should be solved directly. >> >> Anyway, if the module is not complete then it should probably not be >> imported until it is. > > Yes, but it breaks the module without it, so it's a chicken and egg > issue, having to haul around a patch that will eventually have to go > in anyhow doesn't make much sense. It is the "have to go in anyhow" that I am querying. If there is a real solution that avoids the need for this patch then that is obviously preferable. > At the end of this all, there are some small requests in here along > with some large requests, if you take the time to add up the time > needed to get all of this according to your request, it pushes back > the delivery of the essential kernel functionality by several weeks > if not months. Keep in mind that any delay at this point to address review concerns could have been handled 3 months ago when the commit candidate diff was first requested, and are usually handled as part of the standard development practises we use in FreeBSD (posting diffs for public comment with a pre-announced timetable, dealing with technical review, etc). If following those steps after not previously having done so means you now have to push back the timetable, that is unfortunate, but necessary. Kris From hselasky at c2i.net Tue Aug 19 20:42:48 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Aug 19 20:42:55 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080819200911.224754500F@ptavv.es.net> References: <20080819200911.224754500F@ptavv.es.net> Message-ID: <200808192244.24034.hselasky@c2i.net> On Tuesday 19 August 2008, Kevin Oberman wrote: > > Date: Tue, 19 Aug 2008 12:44:13 -0700 > > From: Alfred Perlstein > > Sender: owner-freebsd-current@freebsd.org > > > > After a long period of review and testing I am on the verge of > > committing Hans Peter's new usb stack to -current. > > > > The patchset requires a SMALL _493_ line diff to the main code, > > mostly bug fixes to arm. And then a large number of new files > > for the usb system. > > > > The new usb system will be committed as separate files with > > the intention of folding them over the old files before the > > 9.0 release. > > > > The diff to the main files is here: > > http://mu.org/~bright/usb2/usb2_release_001.diff > > > > The whole diff, including new files is here: > > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > > > FAQ: > > Q. Has this been reviewed? > > A. Yes, pretty strongly by myself and we've consulted with > > various others, Warner, Scott and Andrew for review/testing. > > I wouldn't say that Warner or Scott have given full review > > but just about all questions have been answered. > > > > Q. Can we change the name from "usb2_" to my favorite name? > > A. No. This is for a short period, stop being so annoying. > > > > Q. What about the old usb code? > > A. What about it? :D > > > > Q. What about ttys? > > A. I don't know, we'll address the mpsafe aspects of ttys shortly, > > Hans is very responsive to SMP issues. > > > > Q. Shouldn't you wait? > > A. Wait for what? No. > > > > Q. I have some whitespace nits, can you do those? > > A. No. It's a 100k line diff and a 3meg delta, we tried really hard > > to get all whitespace right, but you're welcome to point things out after > > the commit. > > Cool! I've been waiting for this for a loooooong time. Thanks to you, > Hans Peter and all of the folks who have helped! > > Not on the FAQ: > > Q: Other then no longer requiring giant [MPSAFE], what does usb2 give > us? Does it fix the battery-eating on laptops? Does it allow the > system to reach C3 and lower sleep states? (These are at least > closely linked issues.) Hi, Regarding power save there is no news. But I have been thinking about it, and a simple patch like turning off the ASYNC and SYNC schedules when no devices are plugged is not impossible. Only that it hasn't been done yet, because there is already plenty of USB stuff to do. New stuff (all of which I can remember right now): - Full support for Split transactions, which means you can use your full speed USB audio on a high speed USB HUB. - Full support for HS ISOC transactions, which makes writing drivers for various HS webcams possible, for example - Full support for USB on embedded platforms, mostly cache flushing and buffer invalidating stuff. - Safer parsing of USB descriptors. - Autodetect of annoying USB install disks. - Support for USB device side (and a handful of USB device side chips) - Support for USB transfers like I/O vectors, means more throughput and less interrupts. - New UGEN backend and libusb library, finally solves the "driver unloading" problem. - A new USB API. - Many USB drivers are now running Giant free. - Linux USB kernel compat layer. - ... see the FreeBSD quarterly status reports --HPS From hselasky at c2i.net Tue Aug 19 20:55:33 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Aug 19 20:55:39 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <48AB32D4.5040904@FreeBSD.org> References: <20080819194413.GB16977@elvis.mu.org> <48AB32D4.5040904@FreeBSD.org> Message-ID: <200808192257.13576.hselasky@c2i.net> On Tuesday 19 August 2008, Maxim Sobolev wrote: > Alfred Perlstein wrote: > > Q. Can we change the name from "usb2_" to my favorite name? > > A. No. This is for a short period, stop being so annoying. > > Why not just "usb_"? You can then leave it as is then avoiding violating > POLA second time. Otherwise people would confuse it with USB 2.0. > Else you get symbol collisions with the old USB stack ... --HPS From kris at FreeBSD.org Tue Aug 19 20:57:48 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Aug 19 20:57:57 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <200808192253.26152.hselasky@c2i.net> References: <20080818205914.GJ16977@elvis.mu.org> <20080819200017.GC16977@elvis.mu.org> <48AB3023.2030307@FreeBSD.org> <200808192253.26152.hselasky@c2i.net> Message-ID: <48AB33C9.9010203@FreeBSD.org> Hans Petter Selasky wrote: > Hi, > > On Tuesday 19 August 2008, Kris Kennaway wrote: >> Keep in mind that any delay at this point to address review concerns >> could have been handled 3 months ago when the commit candidate diff was >> first requested, and are usually handled as part of the standard >> development practises we use in FreeBSD (posting diffs for public >> comment with a pre-announced timetable, dealing with technical review, >> etc). If following those steps after not previously having done so >> means you now have to push back the timetable, that is unfortunate, but >> necessary. > > To not draw away any attention from the old USB stack I have not made any > public postings to any FreeBSD lists about the new USB stack as an agreement > with some of the core FreeBSD developers during the last couple of months. OK, but this was surely not intended to block alfred from preparing to finalize and commit your work. Kris From sobomax at FreeBSD.org Tue Aug 19 21:04:23 2008 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Tue Aug 19 21:04:36 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080819194413.GB16977@elvis.mu.org> References: <20080819194413.GB16977@elvis.mu.org> Message-ID: <48AB32D4.5040904@FreeBSD.org> Alfred Perlstein wrote: > Q. Can we change the name from "usb2_" to my favorite name? > A. No. This is for a short period, stop being so annoying. Why not just "usb_"? You can then leave it as is then avoiding violating POLA second time. Otherwise people would confuse it with USB 2.0. -Maxim From sobomax at FreeBSD.org Tue Aug 19 21:04:24 2008 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Tue Aug 19 21:04:36 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <48AB32D4.5040904@FreeBSD.org> References: <20080819194413.GB16977@elvis.mu.org> <48AB32D4.5040904@FreeBSD.org> Message-ID: <48AB3408.4030703@FreeBSD.org> Maxim Sobolev wrote: > Alfred Perlstein wrote: >> Q. Can we change the name from "usb2_" to my favorite name? >> A. No. This is for a short period, stop being so annoying. > > Why not just "usb_"? You can then leave it as is then avoiding violating > POLA second time. Otherwise people would confuse it with USB 2.0. P.S. I am talking about entries for kernel config here, not about names of directories and source files. -Maxim From bakul at bitblocks.com Tue Aug 19 21:27:18 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Tue Aug 19 21:27:24 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: Your message of "Tue, 19 Aug 2008 22:44:20 +0200." <200808192244.24034.hselasky@c2i.net> Message-ID: <20080819211814.6CD685B4D@mail.bitblocks.com> On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky wrote: > > New stuff (all of which I can remember right now): ... Accidentally unplugging a mounted USB disk (without unmounting it) resulted in a hang or a crash. Is this fixed? Thx! From rwatson at FreeBSD.org Tue Aug 19 21:35:31 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Aug 19 21:35:37 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <48AB3408.4030703@FreeBSD.org> References: <20080819194413.GB16977@elvis.mu.org> <48AB32D4.5040904@FreeBSD.org> <48AB3408.4030703@FreeBSD.org> Message-ID: On Tue, 19 Aug 2008, Maxim Sobolev wrote: > Maxim Sobolev wrote: >> Alfred Perlstein wrote: >>> Q. Can we change the name from "usb2_" to my favorite name? A. No. This >>> is for a short period, stop being so annoying. >> >> Why not just "usb_"? You can then leave it as is then avoiding violating >> POLA second time. Otherwise people would confuse it with USB 2.0. > > P.S. I am talking about entries for kernel config here, not about names of > directories and source files. With the move to Subversion, there's a significantly lower technical barrier to renaming files in the tree, especially if they exist only in HEAD. Let's assume that, when the time comes to remove the old USB implementation, we will do whatever renaming of directories, files, and symbols that may make sense. That is to say, let's leave the names as-is and focus on the semantics. Robert N M Watson Computer Laboratory University of Cambridge From bakul at bitblocks.com Tue Aug 19 21:37:17 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Tue Aug 19 21:37:23 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: Your message of "Tue, 19 Aug 2008 22:44:20 +0200." <200808192244.24034.hselasky@c2i.net> Message-ID: <20080819211814.6CD685B4D@mail.bitblocks.com> On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky wrote: > > New stuff (all of which I can remember right now): ... Accidentally unplugging a mounted USB disk (without unmounting it) resulted in a hang or a crash. Is this fixed? Thx! From kris at FreeBSD.org Tue Aug 19 21:38:05 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Aug 19 21:38:11 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <200808192219.19246.hselasky@c2i.net> References: <20080818205914.GJ16977@elvis.mu.org> <200808191758.22981.hselasky@c2i.net> <48AB233C.2010602@FreeBSD.org> <200808192219.19246.hselasky@c2i.net> Message-ID: <48AB3D3A.4040303@FreeBSD.org> Hans Petter Selasky wrote: >> I am not sure what you mean by this statement, since it can be >> interpreted in several ways, some not so friendly. > > I mean I need to make another patchset. And that the current patchset will > break the kernel compilation if blindly committed after mpsafetty. OK, thanks for clarifying. >>>>> The patch only includes kernel parts, is there any impact on userland? >>> No. Userland will build like before. The current USB userland utilities >>> and libusb from ports will only work with the old USB stack. I'm working >>> on a replacement for "usbdevs" called "usbconfig" which has some more >>> functionality and a FreeBSD specific libusb, which is compatible with >>> libusb from sourceforge. I have most of it finished in my private SVN >>> repository, and will add it to my P4 repository soon. >> This raises the question of why the kernel changes need to be committed >> now, and what benefit they bring in the absence of a compatible >> userland. Shouldn't the commit happen after both kernel and userland >> are ready (and reviewed)? > > I think that is correct. OK, so does this mean we should expect to see a revised commit candidate patch from you and/or alfred later once that is finished? >> Another comment: the new code seems to bundle all new drivers into >> "subsystems" but not allow them to be loaded individually. This is >> quite contrary to how the rest of the kernel is structured, and seems to >> be of questionable benefit. For example, users will rarely have more >> than one USB ethernet driver in use on a given system but "device >> usb2_ethernet" will compile in all 7 drivers. > > It is still possible to separate the USB drivers. In my experience grouping > the drivers gives a more user-friendly experience. For example you have a USB > serial port adapter and plug it in. Then all you need to do is to kldload > usb2_serial regardless of adapter. It is like a container module. I don't > opponent that for kernel compilation you can have a more fine-grained control > what drivers are actually included. I will see about fixing that. You could look at what the sound code does, (I think it is specifically the snd_driver module). This implements auto-loading of the "right" drivers by loading them and then unloading the ones that don't attach. This still has overhead though, so users often will just compile in the ones they know they have. >> Also is it safe to drop and reacquire the lock here? > > You have to drop the lock, else I get witness warnings. Yes, and presumably rightly so. It doesn't mean that dropping the lock and later reacquiring it is safe though; it could introduce races. >> This seems to say that m->lock now may be NULL in situations where it >> was not before (since there is no handling for m->lock == NULL in >> existing parts of the code), so the Giant locking is new. > > That is just a safety measure, because the Sound code has some ifdef's to > enable it to run without mutexes, and in that case Giant must be used. OK, this seems unrelated to USB then and is something you should discuss with the sound maintainers. It sounds to me like the ability to "run without mutexes" is the real bug here, and "support" for that should be removed completely instead of patching it up downstream. >>>> It's needed for compiling usb2_ndis, but... >>> Without this patch the usb2_ndis module will not compile on certain >>> architectures. If you remove this patch you will need to decouple the >>> usb2_ndis module, which is not complete anyway, from the default build. >> Why will it not compile? This looks like a workaround for some other >> issue that should be solved directly. > > There are multiple issues: > > 1) If PAGE_SIZE is 16384 bytes, then the code simply fails. > 2) Sometimes PAGE_SHIFT is already defined. > > #if PAGE_SIZE == 4096 > #define PAGE_SHIFT 12 > #elif PAGE_SIZE == 8192 > #define PAGE_SHIFT 13 > #else > #error PAGE_SHIFT undefined! > #endif OK, but again, why? If some architecture is not defining the same symbols as the others then maybe that architecture should be fixed, instead of working around the effect downstream. Kris P.S. There were a number of questions you didn't answer, can I assume those will follow later? From hselasky at c2i.net Tue Aug 19 21:42:49 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Aug 19 21:42:56 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080819200911.224754500F@ptavv.es.net> References: <20080819200911.224754500F@ptavv.es.net> Message-ID: <200808192244.24034.hselasky@c2i.net> On Tuesday 19 August 2008, Kevin Oberman wrote: > > Date: Tue, 19 Aug 2008 12:44:13 -0700 > > From: Alfred Perlstein > > Sender: owner-freebsd-current@freebsd.org > > > > After a long period of review and testing I am on the verge of > > committing Hans Peter's new usb stack to -current. > > > > The patchset requires a SMALL _493_ line diff to the main code, > > mostly bug fixes to arm. And then a large number of new files > > for the usb system. > > > > The new usb system will be committed as separate files with > > the intention of folding them over the old files before the > > 9.0 release. > > > > The diff to the main files is here: > > http://mu.org/~bright/usb2/usb2_release_001.diff > > > > The whole diff, including new files is here: > > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > > > FAQ: > > Q. Has this been reviewed? > > A. Yes, pretty strongly by myself and we've consulted with > > various others, Warner, Scott and Andrew for review/testing. > > I wouldn't say that Warner or Scott have given full review > > but just about all questions have been answered. > > > > Q. Can we change the name from "usb2_" to my favorite name? > > A. No. This is for a short period, stop being so annoying. > > > > Q. What about the old usb code? > > A. What about it? :D > > > > Q. What about ttys? > > A. I don't know, we'll address the mpsafe aspects of ttys shortly, > > Hans is very responsive to SMP issues. > > > > Q. Shouldn't you wait? > > A. Wait for what? No. > > > > Q. I have some whitespace nits, can you do those? > > A. No. It's a 100k line diff and a 3meg delta, we tried really hard > > to get all whitespace right, but you're welcome to point things out after > > the commit. > > Cool! I've been waiting for this for a loooooong time. Thanks to you, > Hans Peter and all of the folks who have helped! > > Not on the FAQ: > > Q: Other then no longer requiring giant [MPSAFE], what does usb2 give > us? Does it fix the battery-eating on laptops? Does it allow the > system to reach C3 and lower sleep states? (These are at least > closely linked issues.) Hi, Regarding power save there is no news. But I have been thinking about it, and a simple patch like turning off the ASYNC and SYNC schedules when no devices are plugged is not impossible. Only that it hasn't been done yet, because there is already plenty of USB stuff to do. New stuff (all of which I can remember right now): - Full support for Split transactions, which means you can use your full speed USB audio on a high speed USB HUB. - Full support for HS ISOC transactions, which makes writing drivers for various HS webcams possible, for example - Full support for USB on embedded platforms, mostly cache flushing and buffer invalidating stuff. - Safer parsing of USB descriptors. - Autodetect of annoying USB install disks. - Support for USB device side (and a handful of USB device side chips) - Support for USB transfers like I/O vectors, means more throughput and less interrupts. - New UGEN backend and libusb library, finally solves the "driver unloading" problem. - A new USB API. - Many USB drivers are now running Giant free. - Linux USB kernel compat layer. - ... see the FreeBSD quarterly status reports --HPS From hselasky at c2i.net Tue Aug 19 21:51:47 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Aug 19 21:51:53 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <48AB3023.2030307@FreeBSD.org> References: <20080818205914.GJ16977@elvis.mu.org> <20080819200017.GC16977@elvis.mu.org> <48AB3023.2030307@FreeBSD.org> Message-ID: <200808192253.26152.hselasky@c2i.net> Hi, On Tuesday 19 August 2008, Kris Kennaway wrote: > > Keep in mind that any delay at this point to address review concerns > could have been handled 3 months ago when the commit candidate diff was > first requested, and are usually handled as part of the standard > development practises we use in FreeBSD (posting diffs for public > comment with a pre-announced timetable, dealing with technical review, > etc). If following those steps after not previously having done so > means you now have to push back the timetable, that is unfortunate, but > necessary. To not draw away any attention from the old USB stack I have not made any public postings to any FreeBSD lists about the new USB stack as an agreement with some of the core FreeBSD developers during the last couple of months. --HPS From sobomax at FreeBSD.org Tue Aug 19 21:59:19 2008 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Tue Aug 19 21:59:25 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: References: <20080819194413.GB16977@elvis.mu.org> <48AB32D4.5040904@FreeBSD.org> <48AB3408.4030703@FreeBSD.org> Message-ID: <48AB4234.80502@FreeBSD.org> Robert Watson wrote: > On Tue, 19 Aug 2008, Maxim Sobolev wrote: > >> Maxim Sobolev wrote: >>> Alfred Perlstein wrote: >>>> Q. Can we change the name from "usb2_" to my favorite name? A. No. >>>> This is for a short period, stop being so annoying. >>> >>> Why not just "usb_"? You can then leave it as is then avoiding >>> violating POLA second time. Otherwise people would confuse it with >>> USB 2.0. >> >> P.S. I am talking about entries for kernel config here, not about >> names of directories and source files. > > With the move to Subversion, there's a significantly lower technical > barrier to renaming files in the tree, especially if they exist only in > HEAD. Let's assume that, when the time comes to remove the old USB > implementation, we will do whatever renaming of directories, files, and > symbols that may make sense. That is to say, let's leave the names as-is > and focus on the semantics. See my other e-mail. I am talking about entries for kernel config here, not about names of directories and source files. -Maxim From imp at bsdimp.com Tue Aug 19 22:05:30 2008 From: imp at bsdimp.com (Warner Losh) Date: Tue Aug 19 22:05:46 2008 Subject: usb4bsd patch review In-Reply-To: <200808192228.39015.hselasky@c2i.net> References: <48AB233C.2010602@FreeBSD.org> <20080819200017.GC16977@elvis.mu.org> <200808192228.39015.hselasky@c2i.net> Message-ID: <20080819.160221.41717240.imp@bsdimp.com> From: Hans Petter Selasky Subject: Re: usb4bsd patch review [was Re: ...] Date: Tue, 19 Aug 2008 22:28:36 +0200 > > > > > > What do the newbus guys say about this? Adding a workaround in > > > underlying code for a problem caused by your own code is often a signal > > > that you're not going about it the right way. At the very least the > > > reason for the special case should be documented here. > > > > I need to think about this, Hans gave me a better argument on > > AIM earlier for it, I need to reload this in my head. > > > > > >int > > > >device_delete_all_children(device_t dev) > > > >{ > > > > device_t *devlist; > > > > int devcount; > > > > int error; > > > > > > > > error = device_get_children(dev, &devlist, &devcount); > > > > if (error == 0) { > > > > while (devcount-- > 0) { > > > > error = device_delete_child(dev, > > > > devlist[devcount]); > > > > if (error) { > > > > break; > > > > } > > > > } > > > > free(devlist, M_TEMP); > > > > } > > > > return (error); > > > >} > > > > > > In the existing kernel code, "device_get_children()" is used many places > without checking the error code. I have patches, but they are not part of the > patch-set. > > Also freeing a pointer to zero bytes is not logical. I'm not sure if this is > allowed in kernel space? > > ptr = malloc(0, ... ) > free(0); > > The device_get_children() could have returned an error if there are no > children, but again, the existing code does not check this return value. The existing code is fine when there's no children. The semantics of the kernel allocation routines are such that there's no problem. I don't think there's a bug here at all. The bug here is that the interface is impossible to lock, but that's another issue.... Having said that, I rather like the idea of having a device_delete_all_children. Warner From imp at bsdimp.com Tue Aug 19 22:09:05 2008 From: imp at bsdimp.com (Warner Losh) Date: Tue Aug 19 22:09:13 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <48AB3408.4030703@FreeBSD.org> References: <20080819194413.GB16977@elvis.mu.org> <48AB32D4.5040904@FreeBSD.org> <48AB3408.4030703@FreeBSD.org> Message-ID: <20080819.160439.71174078.imp@bsdimp.com> > Maxim Sobolev wrote: > > Alfred Perlstein wrote: > >> Q. Can we change the name from "usb2_" to my favorite name? > >> A. No. This is for a short period, stop being so annoying. > > > > Why not just "usb_"? You can then leave it as is then avoiding violating > > POLA second time. Otherwise people would confuse it with USB 2.0. > > P.S. I am talking about entries for kernel config here, not about names > of directories and source files. In the fullness of time, this is a great idea. Now, given the other reviews that have been offered of the code, I don't think it is a good use of time to deal with changes of this order. We should note it and move on. Warner From imp at bsdimp.com Tue Aug 19 22:09:10 2008 From: imp at bsdimp.com (Warner Losh) Date: Tue Aug 19 22:09:35 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080819211814.6CD685B4D@mail.bitblocks.com> References: <200808192244.24034.hselasky@c2i.net> <20080819211814.6CD685B4D@mail.bitblocks.com> Message-ID: <20080819.160510.104119134.imp@bsdimp.com> From: Bakul Shah Subject: Re: HEADSUP new usb code coming in. Date: Tue, 19 Aug 2008 14:18:13 -0700 > On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky wrote: > > > > New stuff (all of which I can remember right now): > ... > > Accidentally unplugging a mounted USB disk (without > unmounting it) resulted in a hang or a crash. Is this fixed? That's fixed in -current right now with the old stack. It isn't a usb issue at all, but a buffer cache issue. Warner From imp at bsdimp.com Tue Aug 19 22:09:10 2008 From: imp at bsdimp.com (Warner Losh) Date: Tue Aug 19 22:09:35 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080819211814.6CD685B4D@mail.bitblocks.com> References: <200808192244.24034.hselasky@c2i.net> <20080819211814.6CD685B4D@mail.bitblocks.com> Message-ID: <20080819.160510.104119134.imp@bsdimp.com> From: Bakul Shah Subject: Re: HEADSUP new usb code coming in. Date: Tue, 19 Aug 2008 14:18:13 -0700 > On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky wrote: > > > > New stuff (all of which I can remember right now): > ... > > Accidentally unplugging a mounted USB disk (without > unmounting it) resulted in a hang or a crash. Is this fixed? That's fixed in -current right now with the old stack. It isn't a usb issue at all, but a buffer cache issue. Warner From pschmehl_lists at tx.rr.com Tue Aug 19 22:37:59 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Tue Aug 19 22:38:06 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080819202757.GG16977@elvis.mu.org> References: <20080819194413.GB16977@elvis.mu.org> <48AB2A1C.4080808@moneybookers.com> <20080819202757.GG16977@elvis.mu.org> Message-ID: <20F9B757C07EEBCC1BB1B762@utd65257.utdallas.edu> So, if we're running 7.0 STABLE, will these changes show up with csup so we can rebuild kernel? Or are these diffs something you need to download and build separately? -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. ******************************************* Check the headers before clicking on Reply. From imp at bsdimp.com Tue Aug 19 22:46:44 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Aug 19 22:46:49 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20F9B757C07EEBCC1BB1B762@utd65257.utdallas.edu> References: <48AB2A1C.4080808@moneybookers.com> <20080819202757.GG16977@elvis.mu.org> <20F9B757C07EEBCC1BB1B762@utd65257.utdallas.edu> Message-ID: <20080819.164454.282837106.imp@bsdimp.com> In message: <20F9B757C07EEBCC1BB1B762@utd65257.utdallas.edu> Paul Schmehl writes: : So, if we're running 7.0 STABLE, will these changes show up with : csup so we can rebuild kernel? Or are these diffs something you : need to download and build separately? This code won't be committed to RELENG_7... However I think hps has patches for it... Warner From oberman at es.net Tue Aug 19 23:12:09 2008 From: oberman at es.net (Kevin Oberman) Date: Tue Aug 19 23:12:16 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: Your message of "Tue, 19 Aug 2008 22:44:20 +0200." <200808192244.24034.hselasky@c2i.net> Message-ID: <20080819230136.B5CAD4500F@ptavv.es.net> > From: Hans Petter Selasky > Date: Tue, 19 Aug 2008 22:44:20 +0200 > > On Tuesday 19 August 2008, Kevin Oberman wrote: > > > Date: Tue, 19 Aug 2008 12:44:13 -0700 > > > From: Alfred Perlstein > > > Sender: owner-freebsd-current@freebsd.org > > > > > > After a long period of review and testing I am on the verge of > > > committing Hans Peter's new usb stack to -current. > > > > > > The patchset requires a SMALL _493_ line diff to the main code, > > > mostly bug fixes to arm. And then a large number of new files > > > for the usb system. > > > > > > The new usb system will be committed as separate files with > > > the intention of folding them over the old files before the > > > 9.0 release. > > > > > > The diff to the main files is here: > > > http://mu.org/~bright/usb2/usb2_release_001.diff > > > > > > The whole diff, including new files is here: > > > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > > > > > FAQ: > > > Q. Has this been reviewed? > > > A. Yes, pretty strongly by myself and we've consulted with > > > various others, Warner, Scott and Andrew for review/testing. > > > I wouldn't say that Warner or Scott have given full review > > > but just about all questions have been answered. > > > > > > Q. Can we change the name from "usb2_" to my favorite name? > > > A. No. This is for a short period, stop being so annoying. > > > > > > Q. What about the old usb code? > > > A. What about it? :D > > > > > > Q. What about ttys? > > > A. I don't know, we'll address the mpsafe aspects of ttys shortly, > > > Hans is very responsive to SMP issues. > > > > > > Q. Shouldn't you wait? > > > A. Wait for what? No. > > > > > > Q. I have some whitespace nits, can you do those? > > > A. No. It's a 100k line diff and a 3meg delta, we tried really hard > > > to get all whitespace right, but you're welcome to point things out after > > > the commit. > > > > Cool! I've been waiting for this for a loooooong time. Thanks to you, > > Hans Peter and all of the folks who have helped! > > > > Not on the FAQ: > > > > Q: Other then no longer requiring giant [MPSAFE], what does usb2 give > > us? Does it fix the battery-eating on laptops? Does it allow the > > system to reach C3 and lower sleep states? (These are at least > > closely linked issues.) > > Hi, > > Regarding power save there is no news. But I have been thinking about it, and > a simple patch like turning off the ASYNC and SYNC schedules when no devices > are plugged is not impossible. Only that it hasn't been done yet, because > there is already plenty of USB stuff to do. > > New stuff (all of which I can remember right now): > > - Full support for Split transactions, which means you can use your full > speed USB audio on a high speed USB HUB. > - Full support for HS ISOC transactions, which makes writing drivers for > various HS webcams possible, for example > - Full support for USB on embedded platforms, mostly cache flushing and > buffer invalidating stuff. > - Safer parsing of USB descriptors. > - Autodetect of annoying USB install disks. > - Support for USB device side (and a handful of USB device side chips) > - Support for USB transfers like I/O vectors, means more throughput and less > interrupts. > - New UGEN backend and libusb library, finally solves the "driver unloading" > problem. > - A new USB API. > - Many USB drivers are now running Giant free. > - Linux USB kernel compat layer. > - ... see the FreeBSD quarterly status reports > > --HPS > Very impressive. Yes, turning off polling when there are no connected devices would help with the battery drain in that regard, but I don't see how this would solve the problem of getting to C3 or lower when a USB device is connected. I know that Windows once had this problem early in the XP days and they fixed it in some way. I am not at all expert on USB, so I don't know at what frequency USB polls, but I would hope it's not so high that a system can't even get to C3, but with the current stack, C2 is the best you can get and C2 does not save a lot of power on most systems. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20080819/2ff7111d/attachment.pgp From oberman at es.net Tue Aug 19 23:12:09 2008 From: oberman at es.net (Kevin Oberman) Date: Tue Aug 19 23:12:27 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: Your message of "Tue, 19 Aug 2008 22:44:20 +0200." <200808192244.24034.hselasky@c2i.net> Message-ID: <20080819230136.B5CAD4500F@ptavv.es.net> > From: Hans Petter Selasky > Date: Tue, 19 Aug 2008 22:44:20 +0200 > > On Tuesday 19 August 2008, Kevin Oberman wrote: > > > Date: Tue, 19 Aug 2008 12:44:13 -0700 > > > From: Alfred Perlstein > > > Sender: owner-freebsd-current@freebsd.org > > > > > > After a long period of review and testing I am on the verge of > > > committing Hans Peter's new usb stack to -current. > > > > > > The patchset requires a SMALL _493_ line diff to the main code, > > > mostly bug fixes to arm. And then a large number of new files > > > for the usb system. > > > > > > The new usb system will be committed as separate files with > > > the intention of folding them over the old files before the > > > 9.0 release. > > > > > > The diff to the main files is here: > > > http://mu.org/~bright/usb2/usb2_release_001.diff > > > > > > The whole diff, including new files is here: > > > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > > > > > FAQ: > > > Q. Has this been reviewed? > > > A. Yes, pretty strongly by myself and we've consulted with > > > various others, Warner, Scott and Andrew for review/testing. > > > I wouldn't say that Warner or Scott have given full review > > > but just about all questions have been answered. > > > > > > Q. Can we change the name from "usb2_" to my favorite name? > > > A. No. This is for a short period, stop being so annoying. > > > > > > Q. What about the old usb code? > > > A. What about it? :D > > > > > > Q. What about ttys? > > > A. I don't know, we'll address the mpsafe aspects of ttys shortly, > > > Hans is very responsive to SMP issues. > > > > > > Q. Shouldn't you wait? > > > A. Wait for what? No. > > > > > > Q. I have some whitespace nits, can you do those? > > > A. No. It's a 100k line diff and a 3meg delta, we tried really hard > > > to get all whitespace right, but you're welcome to point things out after > > > the commit. > > > > Cool! I've been waiting for this for a loooooong time. Thanks to you, > > Hans Peter and all of the folks who have helped! > > > > Not on the FAQ: > > > > Q: Other then no longer requiring giant [MPSAFE], what does usb2 give > > us? Does it fix the battery-eating on laptops? Does it allow the > > system to reach C3 and lower sleep states? (These are at least > > closely linked issues.) > > Hi, > > Regarding power save there is no news. But I have been thinking about it, and > a simple patch like turning off the ASYNC and SYNC schedules when no devices > are plugged is not impossible. Only that it hasn't been done yet, because > there is already plenty of USB stuff to do. > > New stuff (all of which I can remember right now): > > - Full support for Split transactions, which means you can use your full > speed USB audio on a high speed USB HUB. > - Full support for HS ISOC transactions, which makes writing drivers for > various HS webcams possible, for example > - Full support for USB on embedded platforms, mostly cache flushing and > buffer invalidating stuff. > - Safer parsing of USB descriptors. > - Autodetect of annoying USB install disks. > - Support for USB device side (and a handful of USB device side chips) > - Support for USB transfers like I/O vectors, means more throughput and less > interrupts. > - New UGEN backend and libusb library, finally solves the "driver unloading" > problem. > - A new USB API. > - Many USB drivers are now running Giant free. > - Linux USB kernel compat layer. > - ... see the FreeBSD quarterly status reports > > --HPS > Very impressive. Yes, turning off polling when there are no connected devices would help with the battery drain in that regard, but I don't see how this would solve the problem of getting to C3 or lower when a USB device is connected. I know that Windows once had this problem early in the XP days and they fixed it in some way. I am not at all expert on USB, so I don't know at what frequency USB polls, but I would hope it's not so high that a system can't even get to C3, but with the current stack, C2 is the best you can get and C2 does not save a lot of power on most systems. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20080819/2ff7111d/attachment-0001.pgp From fbsd-current at mawer.org Tue Aug 19 23:38:01 2008 From: fbsd-current at mawer.org (Antony Mawer) Date: Tue Aug 19 23:38:18 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080819.160510.104119134.imp@bsdimp.com> References: <200808192244.24034.hselasky@c2i.net> <20080819211814.6CD685B4D@mail.bitblocks.com> <20080819.160510.104119134.imp@bsdimp.com> Message-ID: <48AB566B.5010507@mawer.org> Warner Losh wrote: > From: Bakul Shah > Subject: Re: HEADSUP new usb code coming in. > Date: Tue, 19 Aug 2008 14:18:13 -0700 > >> On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky wrote: >>> New stuff (all of which I can remember right now): >> ... >> >> Accidentally unplugging a mounted USB disk (without >> unmounting it) resulted in a hang or a crash. Is this fixed? > > That's fixed in -current right now with the old stack. It isn't a usb > issue at all, but a buffer cache issue. Is this change that is likely to be MFC'd in time for 7.1? And/or is there a specific patch that can manually be applied to -STABLE to fix this? --Antony From fbsd-current at mawer.org Tue Aug 19 23:38:01 2008 From: fbsd-current at mawer.org (Antony Mawer) Date: Tue Aug 19 23:38:19 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080819.160510.104119134.imp@bsdimp.com> References: <200808192244.24034.hselasky@c2i.net> <20080819211814.6CD685B4D@mail.bitblocks.com> <20080819.160510.104119134.imp@bsdimp.com> Message-ID: <48AB566B.5010507@mawer.org> Warner Losh wrote: > From: Bakul Shah > Subject: Re: HEADSUP new usb code coming in. > Date: Tue, 19 Aug 2008 14:18:13 -0700 > >> On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky wrote: >>> New stuff (all of which I can remember right now): >> ... >> >> Accidentally unplugging a mounted USB disk (without >> unmounting it) resulted in a hang or a crash. Is this fixed? > > That's fixed in -current right now with the old stack. It isn't a usb > issue at all, but a buffer cache issue. Is this change that is likely to be MFC'd in time for 7.1? And/or is there a specific patch that can manually be applied to -STABLE to fix this? --Antony From imp at bsdimp.com Wed Aug 20 00:04:38 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Aug 20 00:04:54 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <48AB566B.5010507@mawer.org> References: <20080819211814.6CD685B4D@mail.bitblocks.com> <20080819.160510.104119134.imp@bsdimp.com> <48AB566B.5010507@mawer.org> Message-ID: <20080819.180450.-867152686.imp@bsdimp.com> In message: <48AB566B.5010507@mawer.org> Antony Mawer writes: : Warner Losh wrote: : > From: Bakul Shah : > Subject: Re: HEADSUP new usb code coming in. : > Date: Tue, 19 Aug 2008 14:18:13 -0700 : > : >> On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky wrote: : >>> New stuff (all of which I can remember right now): : >> ... : >> : >> Accidentally unplugging a mounted USB disk (without : >> unmounting it) resulted in a hang or a crash. Is this fixed? : > : > That's fixed in -current right now with the old stack. It isn't a usb : > issue at all, but a buffer cache issue. : : Is this change that is likely to be MFC'd in time for 7.1? And/or is : there a specific patch that can manually be applied to -STABLE to fix this? I should spend the time to dig into the changes in current. There turned out to be several little changes... And I need to verify all the edge cases were covered... Warner From imp at bsdimp.com Wed Aug 20 00:04:38 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Aug 20 00:04:55 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <48AB566B.5010507@mawer.org> References: <20080819211814.6CD685B4D@mail.bitblocks.com> <20080819.160510.104119134.imp@bsdimp.com> <48AB566B.5010507@mawer.org> Message-ID: <20080819.180450.-867152686.imp@bsdimp.com> In message: <48AB566B.5010507@mawer.org> Antony Mawer writes: : Warner Losh wrote: : > From: Bakul Shah : > Subject: Re: HEADSUP new usb code coming in. : > Date: Tue, 19 Aug 2008 14:18:13 -0700 : > : >> On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky wrote: : >>> New stuff (all of which I can remember right now): : >> ... : >> : >> Accidentally unplugging a mounted USB disk (without : >> unmounting it) resulted in a hang or a crash. Is this fixed? : > : > That's fixed in -current right now with the old stack. It isn't a usb : > issue at all, but a buffer cache issue. : : Is this change that is likely to be MFC'd in time for 7.1? And/or is : there a specific patch that can manually be applied to -STABLE to fix this? I should spend the time to dig into the changes in current. There turned out to be several little changes... And I need to verify all the edge cases were covered... Warner From fbsd-current at mawer.org Wed Aug 20 06:08:42 2008 From: fbsd-current at mawer.org (Antony Mawer) Date: Wed Aug 20 06:08:55 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080819.180450.-867152686.imp@bsdimp.com> References: <20080819211814.6CD685B4D@mail.bitblocks.com> <20080819.160510.104119134.imp@bsdimp.com> <48AB566B.5010507@mawer.org> <20080819.180450.-867152686.imp@bsdimp.com> Message-ID: <48ABB1FA.5070609@mawer.org> M. Warner Losh wrote: > In message: <48AB566B.5010507@mawer.org> > Antony Mawer writes: > : Warner Losh wrote: > : > From: Bakul Shah > : > Subject: Re: HEADSUP new usb code coming in. > : > Date: Tue, 19 Aug 2008 14:18:13 -0700 > : > > : >> On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky wrote: > : >>> New stuff (all of which I can remember right now): > : >> ... > : >> > : >> Accidentally unplugging a mounted USB disk (without > : >> unmounting it) resulted in a hang or a crash. Is this fixed? > : > > : > That's fixed in -current right now with the old stack. It isn't a usb > : > issue at all, but a buffer cache issue. > : > : Is this change that is likely to be MFC'd in time for 7.1? And/or is > : there a specific patch that can manually be applied to -STABLE to fix this? > > I should spend the time to dig into the changes in current. There > turned out to be several little changes... And I need to verify all > the edge cases were covered... I'd be happy to test patches if you do end up doing this.. it would be really nice to have in 7.1, or at least available as a patchset if it isn't suitable for MFC (eg. ABI changes)... --Antony From fbsd-current at mawer.org Wed Aug 20 06:08:42 2008 From: fbsd-current at mawer.org (Antony Mawer) Date: Wed Aug 20 06:08:55 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080819.180450.-867152686.imp@bsdimp.com> References: <20080819211814.6CD685B4D@mail.bitblocks.com> <20080819.160510.104119134.imp@bsdimp.com> <48AB566B.5010507@mawer.org> <20080819.180450.-867152686.imp@bsdimp.com> Message-ID: <48ABB1FA.5070609@mawer.org> M. Warner Losh wrote: > In message: <48AB566B.5010507@mawer.org> > Antony Mawer writes: > : Warner Losh wrote: > : > From: Bakul Shah > : > Subject: Re: HEADSUP new usb code coming in. > : > Date: Tue, 19 Aug 2008 14:18:13 -0700 > : > > : >> On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky wrote: > : >>> New stuff (all of which I can remember right now): > : >> ... > : >> > : >> Accidentally unplugging a mounted USB disk (without > : >> unmounting it) resulted in a hang or a crash. Is this fixed? > : > > : > That's fixed in -current right now with the old stack. It isn't a usb > : > issue at all, but a buffer cache issue. > : > : Is this change that is likely to be MFC'd in time for 7.1? And/or is > : there a specific patch that can manually be applied to -STABLE to fix this? > > I should spend the time to dig into the changes in current. There > turned out to be several little changes... And I need to verify all > the edge cases were covered... I'd be happy to test patches if you do end up doing this.. it would be really nice to have in 7.1, or at least available as a patchset if it isn't suitable for MFC (eg. ABI changes)... --Antony From pb at ludd.ltu.se Wed Aug 20 12:11:27 2008 From: pb at ludd.ltu.se (Peter B) Date: Wed Aug 20 12:11:33 2008 Subject: USB Video Class, port/driver. Message-ID: <200808201211.m7KCBLhK010712@brother.ludd.ltu.se> NetBSD is getting USB Video Class support with help of Google Summer of Code. http://netbsd-soc.sourceforge.net/projects/uvc/ http://netbsd-soc.cvs.sourceforge.net/netbsd-soc/uvc/ Should be even less complicated than an OpenBSD port. Especially considering that several NetBSD drivers has already been imported before (like uscanner). Last update as of 2008-08-18, Nearly Complete Status Update: UVC driver (uvideo) * Supports isoc cameras with frame-based formats (MJPEG and uncompressed) * Supports immediate (non-interrupt) controls * Uses mi video driver for external API Video driver (video) * Implements Video4Linux2 API. Only supports capture interface (video input), format settings, and camera controls (brightness, etc.). * Supports capture via read() or mmap() modes. * Successfully compiled and use MPlayer with the video driver (webpage includes patch). * Initial documentation of userland API in video(4) and kernel interface in video(9). * Has been used with a second webcam driver, Jared's pseye. TODO before end of GSoC * Test another V4L2 app such as VLC or xawtv. * Add more controls to uvideo (currently only has a few as proof-of-concept; adding the other controls is trivial). * Add uvideo(4) manpage. Maybe TODO depending on time * Implement bulk xfers in uvideo. I can't test this directly due to lack of hardware with bulk endpoints. UVC spec: http://www.usb.org/developers/devclass_docs/USB_Video_Class_1_1.zip From naylor.b.david at gmail.com Wed Aug 20 14:49:14 2008 From: naylor.b.david at gmail.com (David Naylor) Date: Wed Aug 20 14:49:20 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080819194413.GB16977@elvis.mu.org> References: <20080819194413.GB16977@elvis.mu.org> Message-ID: <200808201619.22720.naylor.b.david@gmail.com> On Tuesday 19 August 2008 21:44:13 Alfred Perlstein wrote: > After a long period of review and testing I am on the verge of > committing Hans Peter's new usb stack to -current. > > The patchset requires a SMALL _493_ line diff to the main code, > mostly bug fixes to arm. And then a large number of new files > for the usb system. > > The new usb system will be committed as separate files with > the intention of folding them over the old files before the > 9.0 release. > > The diff to the main files is here: > http://mu.org/~bright/usb2/usb2_release_001.diff > > The whole diff, including new files is here: > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > FAQ: > Q. Has this been reviewed? > A. Yes, pretty strongly by myself and we've consulted with > various others, Warner, Scott and Andrew for review/testing. > I wouldn't say that Warner or Scott have given full review > but just about all questions have been answered. > > Q. Can we change the name from "usb2_" to my favorite name? > A. No. This is for a short period, stop being so annoying. > > Q. What about the old usb code? > A. What about it? :D > > Q. What about ttys? > A. I don't know, we'll address the mpsafe aspects of ttys shortly, > Hans is very responsive to SMP issues. > > Q. Shouldn't you wait? > A. Wait for what? No. > > Q. I have some whitespace nits, can you do those? > A. No. It's a 100k line diff and a 3meg delta, we tried really hard > to get all whitespace right, but you're welcome to point things out after > the commit. > > Thanks! This sounds great :-) I see that in the patch usb2 is not enabled in the kernel by default. Is there a timeline for it to be enabled and/or could you provide an alternate kernel config with usb2 enabled (temporarily)? Lastly, is there a web-page where one can check up on the progress of the integration of the new code (and the removal of the old code) [preferably an up-to-date web-page]. Thanks for the great work Regards David -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20080820/6c0622b1/attachment.pgp From janusz.dziedzic at gmail.com Wed Aug 20 15:33:17 2008 From: janusz.dziedzic at gmail.com (Janusz Dziedzic) Date: Wed Aug 20 15:33:23 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <200808192244.24034.hselasky@c2i.net> References: <20080819200911.224754500F@ptavv.es.net> <200808192244.24034.hselasky@c2i.net> Message-ID: <2266b73c0808200805j3a77dbcbgbabb2ac9e56df7d@mail.gmail.com> Nice job. Thanks Hans Peter :) -- Janusz Dziedzic From janusz.dziedzic at gmail.com Wed Aug 20 15:34:13 2008 From: janusz.dziedzic at gmail.com (Janusz Dziedzic) Date: Wed Aug 20 15:34:19 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <200808192244.24034.hselasky@c2i.net> References: <20080819200911.224754500F@ptavv.es.net> <200808192244.24034.hselasky@c2i.net> Message-ID: <2266b73c0808200805j3a77dbcbgbabb2ac9e56df7d@mail.gmail.com> Nice job. Thanks Hans Peter :) -- Janusz Dziedzic From hselasky at c2i.net Wed Aug 20 15:48:11 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Aug 20 15:48:26 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <200808201619.22720.naylor.b.david@gmail.com> References: <20080819194413.GB16977@elvis.mu.org> <200808201619.22720.naylor.b.david@gmail.com> Message-ID: <200808201749.51953.hselasky@c2i.net> On Wednesday 20 August 2008, David Naylor wrote: > On Tuesday 19 August 2008 21:44:13 Alfred Perlstein wrote: > > After a long period of review and testing I am on the verge of > > committing Hans Peter's new usb stack to -current. > > > > The patchset requires a SMALL _493_ line diff to the main code, > > mostly bug fixes to arm. And then a large number of new files > > for the usb system. > > > > The new usb system will be committed as separate files with > > the intention of folding them over the old files before the > > 9.0 release. > > > > The diff to the main files is here: > > http://mu.org/~bright/usb2/usb2_release_001.diff > > > > The whole diff, including new files is here: > > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > > > FAQ: > > Q. Has this been reviewed? > > A. Yes, pretty strongly by myself and we've consulted with > > various others, Warner, Scott and Andrew for review/testing. > > I wouldn't say that Warner or Scott have given full review > > but just about all questions have been answered. > > > > Q. Can we change the name from "usb2_" to my favorite name? > > A. No. This is for a short period, stop being so annoying. > > > > Q. What about the old usb code? > > A. What about it? :D > > > > Q. What about ttys? > > A. I don't know, we'll address the mpsafe aspects of ttys shortly, > > Hans is very responsive to SMP issues. > > > > Q. Shouldn't you wait? > > A. Wait for what? No. > > > > Q. I have some whitespace nits, can you do those? > > A. No. It's a 100k line diff and a 3meg delta, we tried really hard > > to get all whitespace right, but you're welcome to point things out after > > the commit. > > > > Thanks! > > This sounds great :-) > > I see that in the patch usb2 is not enabled in the kernel by default. Is > there a timeline for it to be enabled and/or could you provide an alternate > kernel config with usb2 enabled (temporarily)? For KB920X boards the USB2 is enabled by default. It is not much you need: +device usb2_core +device usb2_controller # EHCI/OHCI/UHCI/AT91DCI +device usb2_storage # USB mass storage support +device usb2_ethernet # USB ethernet support +device usb2_wlan # USB wireless LAN support +device usb2_serial # USB serial support +device usb2_quirk # USB quirks +device usb2_template # Device Side Mode USB templates +device usb2_image # USB Scanner support > > Lastly, is there a web-page where one can check up on the progress of the > integration of the new code (and the removal of the old code) [preferably > an up-to-date web-page]. No, there is no such webpage. --HPS From hselasky at c2i.net Wed Aug 20 15:48:11 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Aug 20 15:48:26 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <200808201619.22720.naylor.b.david@gmail.com> References: <20080819194413.GB16977@elvis.mu.org> <200808201619.22720.naylor.b.david@gmail.com> Message-ID: <200808201749.51953.hselasky@c2i.net> On Wednesday 20 August 2008, David Naylor wrote: > On Tuesday 19 August 2008 21:44:13 Alfred Perlstein wrote: > > After a long period of review and testing I am on the verge of > > committing Hans Peter's new usb stack to -current. > > > > The patchset requires a SMALL _493_ line diff to the main code, > > mostly bug fixes to arm. And then a large number of new files > > for the usb system. > > > > The new usb system will be committed as separate files with > > the intention of folding them over the old files before the > > 9.0 release. > > > > The diff to the main files is here: > > http://mu.org/~bright/usb2/usb2_release_001.diff > > > > The whole diff, including new files is here: > > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > > > FAQ: > > Q. Has this been reviewed? > > A. Yes, pretty strongly by myself and we've consulted with > > various others, Warner, Scott and Andrew for review/testing. > > I wouldn't say that Warner or Scott have given full review > > but just about all questions have been answered. > > > > Q. Can we change the name from "usb2_" to my favorite name? > > A. No. This is for a short period, stop being so annoying. > > > > Q. What about the old usb code? > > A. What about it? :D > > > > Q. What about ttys? > > A. I don't know, we'll address the mpsafe aspects of ttys shortly, > > Hans is very responsive to SMP issues. > > > > Q. Shouldn't you wait? > > A. Wait for what? No. > > > > Q. I have some whitespace nits, can you do those? > > A. No. It's a 100k line diff and a 3meg delta, we tried really hard > > to get all whitespace right, but you're welcome to point things out after > > the commit. > > > > Thanks! > > This sounds great :-) > > I see that in the patch usb2 is not enabled in the kernel by default. Is > there a timeline for it to be enabled and/or could you provide an alternate > kernel config with usb2 enabled (temporarily)? For KB920X boards the USB2 is enabled by default. It is not much you need: +device usb2_core +device usb2_controller # EHCI/OHCI/UHCI/AT91DCI +device usb2_storage # USB mass storage support +device usb2_ethernet # USB ethernet support +device usb2_wlan # USB wireless LAN support +device usb2_serial # USB serial support +device usb2_quirk # USB quirks +device usb2_template # Device Side Mode USB templates +device usb2_image # USB Scanner support > > Lastly, is there a web-page where one can check up on the progress of the > integration of the new code (and the removal of the old code) [preferably > an up-to-date web-page]. No, there is no such webpage. --HPS From hselasky at c2i.net Wed Aug 20 16:07:42 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Aug 20 16:10:45 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <48AB3D3A.4040303@FreeBSD.org> References: <20080818205914.GJ16977@elvis.mu.org> <200808192219.19246.hselasky@c2i.net> <48AB3D3A.4040303@FreeBSD.org> Message-ID: <200808201809.24620.hselasky@c2i.net> On Tuesday 19 August 2008, Kris Kennaway wrote: > Hans Petter Selasky wrote: > >> This raises the question of why the kernel changes need to be committed > >> now, and what benefit they bring in the absence of a compatible > >> userland. Shouldn't the commit happen after both kernel and userland > >> are ready (and reviewed)? > > > > I think that is correct. > > OK, so does this mean we should expect to see a revised commit candidate > patch from you and/or alfred later once that is finished? Alfred, I leave this up to you. > > You could look at what the sound code does, (I think it is specifically > the snd_driver module). This implements auto-loading of the "right" > drivers by loading them and then unloading the ones that don't attach. > This still has overhead though, so users often will just compile in the > ones they know they have. > > >> Also is it safe to drop and reacquire the lock here? > > > > You have to drop the lock, else I get witness warnings. > > Yes, and presumably rightly so. It doesn't mean that dropping the lock > and later reacquiring it is safe though; it could introduce races. Yes, I know. > > OK, this seems unrelated to USB then and is something you should discuss > with the sound maintainers. It sounds to me like the ability to "run > without mutexes" is the real bug here, and "support" for that should be > removed completely instead of patching it up downstream. Yes, and it would be nice if the sound maintainers would try out the new USB stack, and propose how they want to solve the problems that exist in the sound system. > > > > There are multiple issues: > > > > 1) If PAGE_SIZE is 16384 bytes, then the code simply fails. > > 2) Sometimes PAGE_SHIFT is already defined. > > > > #if PAGE_SIZE == 4096 > > #define PAGE_SHIFT 12 > > #elif PAGE_SIZE == 8192 > > #define PAGE_SHIFT 13 > > #else > > #error PAGE_SHIFT undefined! > > #endif > > OK, but again, why? If some architecture is not defining the same > symbols as the others then maybe that architecture should be fixed, > instead of working around the effect downstream. Yes, but then there will be even more patches, and I've been told to reduce the number of patches outside USB. > P.S. There were a number of questions you didn't answer, can I assume > those will follow later? Could you please repeat the questions you did not get an answer to? --HPS From hselasky at c2i.net Wed Aug 20 16:08:39 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Aug 20 16:11:32 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080820155936.GE1803@deviant.kiev.zoral.com.ua> References: <20080819194413.GB16977@elvis.mu.org> <200808201749.51953.hselasky@c2i.net> <20080820155936.GE1803@deviant.kiev.zoral.com.ua> Message-ID: <200808201810.22498.hselasky@c2i.net> On Wednesday 20 August 2008, Kostik Belousov wrote: > On Wed, Aug 20, 2008 at 05:49:50PM +0200, Hans Petter Selasky wrote: > > On Wednesday 20 August 2008, David Naylor wrote: > > > I see that in the patch usb2 is not enabled in the kernel by default. > > > Is there a timeline for it to be enabled and/or could you provide an > > > alternate kernel config with usb2 enabled (temporarily)? > > > > For KB920X boards the USB2 is enabled by default. It is not much you > > need: > > > > +device usb2_core > > +device usb2_controller # EHCI/OHCI/UHCI/AT91DCI > > +device usb2_storage # USB mass storage support > > +device usb2_ethernet # USB ethernet support > > +device usb2_wlan # USB wireless LAN support > > +device usb2_serial # USB serial support > > +device usb2_quirk # USB quirks > > +device usb2_template # Device Side Mode USB templates > > +device usb2_image # USB Scanner support > > Are new usb components built as modules ? Yes, there are corresponding modules. kldload usb2_core kldload usb2_controller ... --HPS From hselasky at c2i.net Wed Aug 20 16:08:39 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Aug 20 16:11:32 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080820155936.GE1803@deviant.kiev.zoral.com.ua> References: <20080819194413.GB16977@elvis.mu.org> <200808201749.51953.hselasky@c2i.net> <20080820155936.GE1803@deviant.kiev.zoral.com.ua> Message-ID: <200808201810.22498.hselasky@c2i.net> On Wednesday 20 August 2008, Kostik Belousov wrote: > On Wed, Aug 20, 2008 at 05:49:50PM +0200, Hans Petter Selasky wrote: > > On Wednesday 20 August 2008, David Naylor wrote: > > > I see that in the patch usb2 is not enabled in the kernel by default. > > > Is there a timeline for it to be enabled and/or could you provide an > > > alternate kernel config with usb2 enabled (temporarily)? > > > > For KB920X boards the USB2 is enabled by default. It is not much you > > need: > > > > +device usb2_core > > +device usb2_controller # EHCI/OHCI/UHCI/AT91DCI > > +device usb2_storage # USB mass storage support > > +device usb2_ethernet # USB ethernet support > > +device usb2_wlan # USB wireless LAN support > > +device usb2_serial # USB serial support > > +device usb2_quirk # USB quirks > > +device usb2_template # Device Side Mode USB templates > > +device usb2_image # USB Scanner support > > Are new usb components built as modules ? Yes, there are corresponding modules. kldload usb2_core kldload usb2_controller ... --HPS From mezz7 at cox.net Wed Aug 20 16:17:48 2008 From: mezz7 at cox.net (Jeremy Messenger) Date: Wed Aug 20 16:17:54 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <200808192257.13576.hselasky@c2i.net> References: <20080819194413.GB16977@elvis.mu.org> <48AB32D4.5040904@FreeBSD.org> <200808192257.13576.hselasky@c2i.net> Message-ID: On Tue, 19 Aug 2008 15:57:11 -0500, Hans Petter Selasky wrote: > On Tuesday 19 August 2008, Maxim Sobolev wrote: >> Alfred Perlstein wrote: >> > Q. Can we change the name from "usb2_" to my favorite name? >> > A. No. This is for a short period, stop being so annoying. >> >> Why not just "usb_"? You can then leave it as is then avoiding violating >> POLA second time. Otherwise people would confuse it with USB 2.0. >> > > Else you get symbol collisions with the old USB stack ... At least, can you document it? Like add an explain about that usb2 is just a name, not USB 2.0, that way no users can mistake it for USB 2.0. Even smarter people can mistake it for USB 2.0, btw. Cheers, Mezz > --HPS -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From kostikbel at gmail.com Wed Aug 20 16:21:57 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Aug 20 16:22:15 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <200808201749.51953.hselasky@c2i.net> References: <20080819194413.GB16977@elvis.mu.org> <200808201619.22720.naylor.b.david@gmail.com> <200808201749.51953.hselasky@c2i.net> Message-ID: <20080820155936.GE1803@deviant.kiev.zoral.com.ua> On Wed, Aug 20, 2008 at 05:49:50PM +0200, Hans Petter Selasky wrote: > On Wednesday 20 August 2008, David Naylor wrote: > > I see that in the patch usb2 is not enabled in the kernel by default. Is > > there a timeline for it to be enabled and/or could you provide an alternate > > kernel config with usb2 enabled (temporarily)? > > For KB920X boards the USB2 is enabled by default. It is not much you need: > > +device usb2_core > +device usb2_controller # EHCI/OHCI/UHCI/AT91DCI > +device usb2_storage # USB mass storage support > +device usb2_ethernet # USB ethernet support > +device usb2_wlan # USB wireless LAN support > +device usb2_serial # USB serial support > +device usb2_quirk # USB quirks > +device usb2_template # Device Side Mode USB templates > +device usb2_image # USB Scanner support Are new usb components built as modules ? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20080820/1b54c9e3/attachment.pgp From kostikbel at gmail.com Wed Aug 20 16:21:57 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Aug 20 16:22:15 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <200808201749.51953.hselasky@c2i.net> References: <20080819194413.GB16977@elvis.mu.org> <200808201619.22720.naylor.b.david@gmail.com> <200808201749.51953.hselasky@c2i.net> Message-ID: <20080820155936.GE1803@deviant.kiev.zoral.com.ua> On Wed, Aug 20, 2008 at 05:49:50PM +0200, Hans Petter Selasky wrote: > On Wednesday 20 August 2008, David Naylor wrote: > > I see that in the patch usb2 is not enabled in the kernel by default. Is > > there a timeline for it to be enabled and/or could you provide an alternate > > kernel config with usb2 enabled (temporarily)? > > For KB920X boards the USB2 is enabled by default. It is not much you need: > > +device usb2_core > +device usb2_controller # EHCI/OHCI/UHCI/AT91DCI > +device usb2_storage # USB mass storage support > +device usb2_ethernet # USB ethernet support > +device usb2_wlan # USB wireless LAN support > +device usb2_serial # USB serial support > +device usb2_quirk # USB quirks > +device usb2_template # Device Side Mode USB templates > +device usb2_image # USB Scanner support Are new usb components built as modules ? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20080820/1b54c9e3/attachment-0001.pgp From peterjeremy at optushome.com.au Wed Aug 20 16:32:23 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Wed Aug 20 16:32:29 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <200808192219.19246.hselasky@c2i.net> References: <20080818205914.GJ16977@elvis.mu.org> <200808191758.22981.hselasky@c2i.net> <48AB233C.2010602@FreeBSD.org> <200808192219.19246.hselasky@c2i.net> Message-ID: <20080820074205.GC32539@server.vk2pj.dyndns.org> On 2008-Aug-19 22:19:14 +0200, Hans Petter Selasky wrote: >On Tuesday 19 August 2008, Kris Kennaway wrote: >> Hans Petter Selasky wrote: >> > On Tuesday 19 August 2008, Alfred Perlstein wrote: >> >> need to wait for smp tty code. >> > >> > If this requires changes in the USB serial port drivers there will be >> > trouble. >> >> I am not sure what you mean by this statement, since it can be >> interpreted in several ways, some not so friendly. > >I mean I need to make another patchset. And that the current patchset will >break the kernel compilation if blindly committed after mpsafetty. I am concerned that the current plans appear to have both mpsafetty and usb4bsd committed at virtually the same time. With the best will in the world, it's still likely that one or both imports will have some rough edges. IMHO, there should be a reasonable period between major kernel subsystem upheavals to allow things to stabilise. Having both a new USB stack and a new TTY subsystem would appear to make it unnecessarily difficult to identify the cause of USB serial port issues. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20080820/e3fca8cf/attachment.pgp From imp at bsdimp.com Wed Aug 20 16:43:41 2008 From: imp at bsdimp.com (Warner Losh) Date: Wed Aug 20 16:43:47 2008 Subject: usb4bsd patch review In-Reply-To: <20080820074205.GC32539@server.vk2pj.dyndns.org> References: <48AB233C.2010602@FreeBSD.org> <200808192219.19246.hselasky@c2i.net> <20080820074205.GC32539@server.vk2pj.dyndns.org> Message-ID: <20080820.104122.41652728.imp@bsdimp.com> > On 2008-Aug-19 22:19:14 +0200, Hans Petter Selasky wrote: > >On Tuesday 19 August 2008, Kris Kennaway wrote: > >> Hans Petter Selasky wrote: > >> > On Tuesday 19 August 2008, Alfred Perlstein wrote: > >> >> need to wait for smp tty code. > >> > > >> > If this requires changes in the USB serial port drivers there will be > >> > trouble. > >> > >> I am not sure what you mean by this statement, since it can be > >> interpreted in several ways, some not so friendly. > > > >I mean I need to make another patchset. And that the current patchset will > >break the kernel compilation if blindly committed after mpsafetty. > > I am concerned that the current plans appear to have both mpsafetty > and usb4bsd committed at virtually the same time. With the best will > in the world, it's still likely that one or both imports will have > some rough edges. IMHO, there should be a reasonable period between > major kernel subsystem upheavals to allow things to stabilise. Having > both a new USB stack and a new TTY subsystem would appear to make it > unnecessarily difficult to identify the cause of USB serial port > issues. The new tty layer is in place now. The new usb code likely is going to have lots of issues, and the new tty code isn't likely going to be any worse at obscuring them than other changes to the system that have happened during the new usb code's development. Warner From kris at FreeBSD.org Wed Aug 20 17:30:34 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Aug 20 17:30:41 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <200808201809.24620.hselasky@c2i.net> References: <20080818205914.GJ16977@elvis.mu.org> <200808192219.19246.hselasky@c2i.net> <48AB3D3A.4040303@FreeBSD.org> <200808201809.24620.hselasky@c2i.net> Message-ID: <48AC54B8.4040406@FreeBSD.org> Hans Petter Selasky wrote: > On Tuesday 19 August 2008, Kris Kennaway wrote: >> Hans Petter Selasky wrote: > >>>> This raises the question of why the kernel changes need to be committed >>>> now, and what benefit they bring in the absence of a compatible >>>> userland. Shouldn't the commit happen after both kernel and userland >>>> are ready (and reviewed)? >>> I think that is correct. >> OK, so does this mean we should expect to see a revised commit candidate >> patch from you and/or alfred later once that is finished? > > Alfred, I leave this up to you. > >> You could look at what the sound code does, (I think it is specifically >> the snd_driver module). This implements auto-loading of the "right" >> drivers by loading them and then unloading the ones that don't attach. >> This still has overhead though, so users often will just compile in the >> ones they know they have. >> >>>> Also is it safe to drop and reacquire the lock here? >>> You have to drop the lock, else I get witness warnings. >> Yes, and presumably rightly so. It doesn't mean that dropping the lock >> and later reacquiring it is safe though; it could introduce races. > > Yes, I know. ...so what is the answer? >> OK, this seems unrelated to USB then and is something you should discuss >> with the sound maintainers. It sounds to me like the ability to "run >> without mutexes" is the real bug here, and "support" for that should be >> removed completely instead of patching it up downstream. > > Yes, and it would be nice if the sound maintainers would try out the new USB > stack, and propose how they want to solve the problems that exist in the > sound system. This is backwards. If you perceive problems in other subsystems you should take the lead on engaging with the relevant developers and resolving those problems to your mutual satisfaction, instead of inviting them to come to you. >>> There are multiple issues: >>> >>> 1) If PAGE_SIZE is 16384 bytes, then the code simply fails. >>> 2) Sometimes PAGE_SHIFT is already defined. >>> >>> #if PAGE_SIZE == 4096 >>> #define PAGE_SHIFT 12 >>> #elif PAGE_SIZE == 8192 >>> #define PAGE_SHIFT 13 >>> #else >>> #error PAGE_SHIFT undefined! >>> #endif >> OK, but again, why? If some architecture is not defining the same >> symbols as the others then maybe that architecture should be fixed, >> instead of working around the effect downstream. > > Yes, but then there will be even more patches, and I've been told to reduce > the number of patches outside USB. The way you minimize patches outside of USB is by submitting separate patches that fix upstream issues at their source, instead of adding workarounds like several of those that appeared in this diff. >> P.S. There were a number of questions you didn't answer, can I assume >> those will follow later? > > Could you please repeat the questions you did not get an answer to? I've repeated some of them already. e.g. in this mail you still didn't answer the "is it safe to drop the locks" question which was asked twice. Rather than me repeating them yet again, I'd suggest you go back and take another close read over my emails and your responses, and reply to the questions that are still not resolved. Thanks, Kris From rink at FreeBSD.org Wed Aug 20 20:06:38 2008 From: rink at FreeBSD.org (Rink Springer) Date: Wed Aug 20 20:06:45 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080819194413.GB16977@elvis.mu.org> References: <20080819194413.GB16977@elvis.mu.org> Message-ID: <20080820194807.GE33396@rink.nu> Hi Alfred, On Tue, Aug 19, 2008 at 12:44:13PM -0700, Alfred Perlstein wrote: > http://mu.org/~bright/usb2/usb4bsd.diff.gz Whenever I try this patch, my build dies with: cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I../../.. -I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror ../../../dev/usb2/core/usb2_generic.c cc1: warnings being treated as errors ../../../dev/usb2/core/usb2_generic.c: In function 'ugen_ioctl': ../../../dev/usb2/core/usb2_generic.c:1409: warning: 'ep_index' may be used uninitialized in this function ../../../dev/usb2/core/usb2_generic.c:1409: note: 'ep_index' was declared here *** Error code 1 I'm using a small patch to get it to compile: - uint8_t ep_index; + uint8_t ep_index = 0; However, I am unsure if this is correct. Futhermore, 'device usb2_bluetooth' gives a lot of compile errors. Am I using the right patch here? Regards, -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From hselasky at c2i.net Wed Aug 20 20:14:42 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Aug 20 20:14:54 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080820194807.GE33396@rink.nu> References: <20080819194413.GB16977@elvis.mu.org> <20080820194807.GE33396@rink.nu> Message-ID: <200808202216.21060.hselasky@c2i.net> Hi, On Wednesday 20 August 2008, Rink Springer wrote: > Hi Alfred, > > On Tue, Aug 19, 2008 at 12:44:13PM -0700, Alfred Perlstein wrote: > > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > Whenever I try this patch, my build dies with: > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > -fformat-extensions -nostdinc -I. -I../../.. -I../../../contrib/altq > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -Werror > ../../../dev/usb2/core/usb2_generic.c > cc1: warnings being treated as errors > ../../../dev/usb2/core/usb2_generic.c: In function 'ugen_ioctl': > ../../../dev/usb2/core/usb2_generic.c:1409: warning: 'ep_index' may be > used uninitialized in this function > ../../../dev/usb2/core/usb2_generic.c:1409: note: 'ep_index' was > declared here > *** Error code 1 > > I'm using a small patch to get it to compile: > > - uint8_t ep_index; > + uint8_t ep_index = 0; > > However, I am unsure if this is correct. Your patch is Ok. "ep_index" is not used uninitialized. Try adding the patch in "ugen_fs_get_complete()" instead: 1002 static uint8_t 1003 ugen_fs_get_complete(struct usb2_fifo *f, uint8_t *pindex) 1004 { 1005 struct usb2_mbuf *m; 1006 1007 USB_IF_DEQUEUE(&f->used_q, m); 1008 1009 if (m) { 1010 *pindex = *((uint8_t *)(m->cur_data_ptr)); 1011 1012 USB_IF_ENQUEUE(&f->free_q, m); 1013 1014 return (0); /* success */ 1015 } else { 1016 f->flag_iscomplete = 0; --here-- >> *pindex = 0; /* fix compiler warning */ 1017 } 1018 return (1); /* failure */ 1019 } > > Futhermore, 'device usb2_bluetooth' gives a lot of compile errors. Am I > using the right patch here? usb2_bluetooth depends on Netgraph which needs some extra options in the kernel config. You maybe want to build the module instead. --HPS From hselasky at c2i.net Wed Aug 20 20:14:42 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Aug 20 20:14:54 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080820194807.GE33396@rink.nu> References: <20080819194413.GB16977@elvis.mu.org> <20080820194807.GE33396@rink.nu> Message-ID: <200808202216.21060.hselasky@c2i.net> Hi, On Wednesday 20 August 2008, Rink Springer wrote: > Hi Alfred, > > On Tue, Aug 19, 2008 at 12:44:13PM -0700, Alfred Perlstein wrote: > > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > Whenever I try this patch, my build dies with: > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > -fformat-extensions -nostdinc -I. -I../../.. -I../../../contrib/altq > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -Werror > ../../../dev/usb2/core/usb2_generic.c > cc1: warnings being treated as errors > ../../../dev/usb2/core/usb2_generic.c: In function 'ugen_ioctl': > ../../../dev/usb2/core/usb2_generic.c:1409: warning: 'ep_index' may be > used uninitialized in this function > ../../../dev/usb2/core/usb2_generic.c:1409: note: 'ep_index' was > declared here > *** Error code 1 > > I'm using a small patch to get it to compile: > > - uint8_t ep_index; > + uint8_t ep_index = 0; > > However, I am unsure if this is correct. Your patch is Ok. "ep_index" is not used uninitialized. Try adding the patch in "ugen_fs_get_complete()" instead: 1002 static uint8_t 1003 ugen_fs_get_complete(struct usb2_fifo *f, uint8_t *pindex) 1004 { 1005 struct usb2_mbuf *m; 1006 1007 USB_IF_DEQUEUE(&f->used_q, m); 1008 1009 if (m) { 1010 *pindex = *((uint8_t *)(m->cur_data_ptr)); 1011 1012 USB_IF_ENQUEUE(&f->free_q, m); 1013 1014 return (0); /* success */ 1015 } else { 1016 f->flag_iscomplete = 0; --here-- >> *pindex = 0; /* fix compiler warning */ 1017 } 1018 return (1); /* failure */ 1019 } > > Futhermore, 'device usb2_bluetooth' gives a lot of compile errors. Am I > using the right patch here? usb2_bluetooth depends on Netgraph which needs some extra options in the kernel config. You maybe want to build the module instead. --HPS From alfred at freebsd.org Wed Aug 20 21:01:36 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Wed Aug 20 21:01:42 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <200808201809.24620.hselasky@c2i.net> References: <20080818205914.GJ16977@elvis.mu.org> <200808192219.19246.hselasky@c2i.net> <48AB3D3A.4040303@FreeBSD.org> <200808201809.24620.hselasky@c2i.net> Message-ID: <20080820210136.GY16977@elvis.mu.org> * Hans Petter Selasky [080820 09:07] wrote: > On Tuesday 19 August 2008, Kris Kennaway wrote: > > Hans Petter Selasky wrote: > > > >> This raises the question of why the kernel changes need to be committed > > >> now, and what benefit they bring in the absence of a compatible > > >> userland. Shouldn't the commit happen after both kernel and userland > > >> are ready (and reviewed)? > > > > > > I think that is correct. > > > > OK, so does this mean we should expect to see a revised commit candidate > > patch from you and/or alfred later once that is finished? > > Alfred, I leave this up to you. I think we'll be committing the kernel portion first. There are several reasons that justify this: 1) The old usb code remains and is on by default so no one is really affected by it. 2) This is a rather large delta and it has been getting quite difficult to get in, the larger the delta, the more problems we will have bringing it in. > > P.S. There were a number of questions you didn't answer, can I assume > > those will follow later? > > Could you please repeat the questions you did not get an answer to? I agree, there has been so many reviews/opinions posted that it would be easier to repeat the missed questions than to expect the person that unintentionally missed them to pick them up again. -- - Alfred Perlstein From alfred at freebsd.org Wed Aug 20 21:07:24 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Wed Aug 20 21:07:35 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <20080820074205.GC32539@server.vk2pj.dyndns.org> References: <20080818205914.GJ16977@elvis.mu.org> <200808191758.22981.hselasky@c2i.net> <48AB233C.2010602@FreeBSD.org> <200808192219.19246.hselasky@c2i.net> <20080820074205.GC32539@server.vk2pj.dyndns.org> Message-ID: <20080820210724.GZ16977@elvis.mu.org> * Peter Jeremy [080820 09:32] wrote: > On 2008-Aug-19 22:19:14 +0200, Hans Petter Selasky wrote: > >On Tuesday 19 August 2008, Kris Kennaway wrote: > >> Hans Petter Selasky wrote: > >> > On Tuesday 19 August 2008, Alfred Perlstein wrote: > >> >> need to wait for smp tty code. > >> > > >> > If this requires changes in the USB serial port drivers there will be > >> > trouble. > >> > >> I am not sure what you mean by this statement, since it can be > >> interpreted in several ways, some not so friendly. > > > >I mean I need to make another patchset. And that the current patchset will > >break the kernel compilation if blindly committed after mpsafetty. > > I am concerned that the current plans appear to have both mpsafetty > and usb4bsd committed at virtually the same time. With the best will > in the world, it's still likely that one or both imports will have > some rough edges. IMHO, there should be a reasonable period between > major kernel subsystem upheavals to allow things to stabilise. Having > both a new USB stack and a new TTY subsystem would appear to make it > unnecessarily difficult to identify the cause of USB serial port > issues. Again, the usb2 code is completely optional, you won't see any changes unless you change your kernel config file to use the "usb2" stack. This is sort of like oldcard/newcard, you pick and choose. -- - Alfred Perlstein From alfred at freebsd.org Wed Aug 20 21:08:27 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Wed Aug 20 21:08:38 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: References: <20080819194413.GB16977@elvis.mu.org> <48AB32D4.5040904@FreeBSD.org> <200808192257.13576.hselasky@c2i.net> Message-ID: <20080820210826.GA16977@elvis.mu.org> * Jeremy Messenger [080820 09:03] wrote: > On Tue, 19 Aug 2008 15:57:11 -0500, Hans Petter Selasky > wrote: > > >On Tuesday 19 August 2008, Maxim Sobolev wrote: > >>Alfred Perlstein wrote: > >>> Q. Can we change the name from "usb2_" to my favorite name? > >>> A. No. This is for a short period, stop being so annoying. > >> > >>Why not just "usb_"? You can then leave it as is then avoiding violating > >>POLA second time. Otherwise people would confuse it with USB 2.0. > >> > > > >Else you get symbol collisions with the old USB stack ... > > At least, can you document it? Like add an explain about that usb2 is just > a name, not USB 2.0, that way no users can mistake it for USB 2.0. Even > smarter people can mistake it for USB 2.0, btw. This is not necessary, usb2 will replace usb in short order if things go well. "usb2" is not expected to live past 8.0-release so "users" shouldn't be confused. -Alfred From alfred at freebsd.org Wed Aug 20 21:10:21 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Wed Aug 20 21:10:32 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <200808201749.51953.hselasky@c2i.net> References: <20080819194413.GB16977@elvis.mu.org> <200808201619.22720.naylor.b.david@gmail.com> <200808201749.51953.hselasky@c2i.net> Message-ID: <20080820211021.GB16977@elvis.mu.org> FYI Hans, I'm not planning on taking that part of your patch, no kernels will by default run usb2 for a few weeks. That's the only part I'm rejecting for the time being. I don't want anyone to be "surprised". -Alfred * Hans Petter Selasky [080820 08:48] wrote: > On Wednesday 20 August 2008, David Naylor wrote: > > On Tuesday 19 August 2008 21:44:13 Alfred Perlstein wrote: > > > After a long period of review and testing I am on the verge of > > > committing Hans Peter's new usb stack to -current. > > > > > > The patchset requires a SMALL _493_ line diff to the main code, > > > mostly bug fixes to arm. And then a large number of new files > > > for the usb system. > > > > > > The new usb system will be committed as separate files with > > > the intention of folding them over the old files before the > > > 9.0 release. > > > > > > The diff to the main files is here: > > > http://mu.org/~bright/usb2/usb2_release_001.diff > > > > > > The whole diff, including new files is here: > > > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > > > > > FAQ: > > > Q. Has this been reviewed? > > > A. Yes, pretty strongly by myself and we've consulted with > > > various others, Warner, Scott and Andrew for review/testing. > > > I wouldn't say that Warner or Scott have given full review > > > but just about all questions have been answered. > > > > > > Q. Can we change the name from "usb2_" to my favorite name? > > > A. No. This is for a short period, stop being so annoying. > > > > > > Q. What about the old usb code? > > > A. What about it? :D > > > > > > Q. What about ttys? > > > A. I don't know, we'll address the mpsafe aspects of ttys shortly, > > > Hans is very responsive to SMP issues. > > > > > > Q. Shouldn't you wait? > > > A. Wait for what? No. > > > > > > Q. I have some whitespace nits, can you do those? > > > A. No. It's a 100k line diff and a 3meg delta, we tried really hard > > > to get all whitespace right, but you're welcome to point things out after > > > the commit. > > > > > > Thanks! > > > > This sounds great :-) > > > > I see that in the patch usb2 is not enabled in the kernel by default. Is > > there a timeline for it to be enabled and/or could you provide an alternate > > kernel config with usb2 enabled (temporarily)? > > For KB920X boards the USB2 is enabled by default. It is not much you need: > > +device usb2_core > +device usb2_controller # EHCI/OHCI/UHCI/AT91DCI > +device usb2_storage # USB mass storage support > +device usb2_ethernet # USB ethernet support > +device usb2_wlan # USB wireless LAN support > +device usb2_serial # USB serial support > +device usb2_quirk # USB quirks > +device usb2_template # Device Side Mode USB templates > +device usb2_image # USB Scanner support > > > > > Lastly, is there a web-page where one can check up on the progress of the > > integration of the new code (and the removal of the old code) [preferably > > an up-to-date web-page]. > > No, there is no such webpage. > > --HPS -- - Alfred Perlstein From alfred at freebsd.org Wed Aug 20 21:10:21 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Wed Aug 20 21:10:33 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <200808201749.51953.hselasky@c2i.net> References: <20080819194413.GB16977@elvis.mu.org> <200808201619.22720.naylor.b.david@gmail.com> <200808201749.51953.hselasky@c2i.net> Message-ID: <20080820211021.GB16977@elvis.mu.org> FYI Hans, I'm not planning on taking that part of your patch, no kernels will by default run usb2 for a few weeks. That's the only part I'm rejecting for the time being. I don't want anyone to be "surprised". -Alfred * Hans Petter Selasky [080820 08:48] wrote: > On Wednesday 20 August 2008, David Naylor wrote: > > On Tuesday 19 August 2008 21:44:13 Alfred Perlstein wrote: > > > After a long period of review and testing I am on the verge of > > > committing Hans Peter's new usb stack to -current. > > > > > > The patchset requires a SMALL _493_ line diff to the main code, > > > mostly bug fixes to arm. And then a large number of new files > > > for the usb system. > > > > > > The new usb system will be committed as separate files with > > > the intention of folding them over the old files before the > > > 9.0 release. > > > > > > The diff to the main files is here: > > > http://mu.org/~bright/usb2/usb2_release_001.diff > > > > > > The whole diff, including new files is here: > > > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > > > > > FAQ: > > > Q. Has this been reviewed? > > > A. Yes, pretty strongly by myself and we've consulted with > > > various others, Warner, Scott and Andrew for review/testing. > > > I wouldn't say that Warner or Scott have given full review > > > but just about all questions have been answered. > > > > > > Q. Can we change the name from "usb2_" to my favorite name? > > > A. No. This is for a short period, stop being so annoying. > > > > > > Q. What about the old usb code? > > > A. What about it? :D > > > > > > Q. What about ttys? > > > A. I don't know, we'll address the mpsafe aspects of ttys shortly, > > > Hans is very responsive to SMP issues. > > > > > > Q. Shouldn't you wait? > > > A. Wait for what? No. > > > > > > Q. I have some whitespace nits, can you do those? > > > A. No. It's a 100k line diff and a 3meg delta, we tried really hard > > > to get all whitespace right, but you're welcome to point things out after > > > the commit. > > > > > > Thanks! > > > > This sounds great :-) > > > > I see that in the patch usb2 is not enabled in the kernel by default. Is > > there a timeline for it to be enabled and/or could you provide an alternate > > kernel config with usb2 enabled (temporarily)? > > For KB920X boards the USB2 is enabled by default. It is not much you need: > > +device usb2_core > +device usb2_controller # EHCI/OHCI/UHCI/AT91DCI > +device usb2_storage # USB mass storage support > +device usb2_ethernet # USB ethernet support > +device usb2_wlan # USB wireless LAN support > +device usb2_serial # USB serial support > +device usb2_quirk # USB quirks > +device usb2_template # Device Side Mode USB templates > +device usb2_image # USB Scanner support > > > > > Lastly, is there a web-page where one can check up on the progress of the > > integration of the new code (and the removal of the old code) [preferably > > an up-to-date web-page]. > > No, there is no such webpage. > > --HPS -- - Alfred Perlstein From alfred at freebsd.org Wed Aug 20 21:16:45 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Wed Aug 20 21:16:51 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <48AC54B8.4040406@FreeBSD.org> References: <20080818205914.GJ16977@elvis.mu.org> <200808192219.19246.hselasky@c2i.net> <48AB3D3A.4040303@FreeBSD.org> <200808201809.24620.hselasky@c2i.net> <48AC54B8.4040406@FreeBSD.org> Message-ID: <20080820211644.GD16977@elvis.mu.org> [[ Reply to Hans at end of this ]] [[ Reply to Kris inline ]] * Kris Kennaway [080820 10:30] wrote: > Hans Petter Selasky wrote: > >On Tuesday 19 August 2008, Kris Kennaway wrote: > >> > >>>>Also is it safe to drop and reacquire the lock here? > >>>You have to drop the lock, else I get witness warnings. > >>Yes, and presumably rightly so. It doesn't mean that dropping the lock > >>and later reacquiring it is safe though; it could introduce races. > > > >Yes, I know. > > ...so what is the answer? > > >>OK, this seems unrelated to USB then and is something you should discuss > >>with the sound maintainers. It sounds to me like the ability to "run > >>without mutexes" is the real bug here, and "support" for that should be > >>removed completely instead of patching it up downstream. > > > >Yes, and it would be nice if the sound maintainers would try out the new > >USB stack, and propose how they want to solve the problems that exist in > >the sound system. > > This is backwards. If you perceive problems in other subsystems you > should take the lead on engaging with the relevant developers and > resolving those problems to your mutual satisfaction, instead of > inviting them to come to you. I think there has been a huge amount of effort just on the usb side, I think expecting Hans to come up with a patch that is "fix all freebsd issues" is a bit too much. I think we can proceed in an organic matter and clean up these small nits as time goes on, just like we do with almost every other problem... except for when we don't do require a completionist solution and never produce anything. (ie, the SMP lag). > >>>There are multiple issues: > >>> > >>>1) If PAGE_SIZE is 16384 bytes, then the code simply fails. > >>>2) Sometimes PAGE_SHIFT is already defined. > >>> > >>>#if PAGE_SIZE == 4096 > >>>#define PAGE_SHIFT 12 > >>>#elif PAGE_SIZE == 8192 > >>>#define PAGE_SHIFT 13 > >>>#else > >>>#error PAGE_SHIFT undefined! > >>>#endif > >>OK, but again, why? If some architecture is not defining the same > >>symbols as the others then maybe that architecture should be fixed, > >>instead of working around the effect downstream. > > > >Yes, but then there will be even more patches, and I've been told to > >reduce the number of patches outside USB. > > The way you minimize patches outside of USB is by submitting separate > patches that fix upstream issues at their source, instead of adding > workarounds like several of those that appeared in this diff. It's a two line ifdef, I dare say we're being a bit pedantic here. How much of a showstopper is this in reality? How _wrong_ is it compared to how _wrong_ the old usb code is? Are you taking into account that these nits can be fixed easily compared to the extra effort we will have to go through to submit all these stuff just for a two line delta? > >>P.S. There were a number of questions you didn't answer, can I assume > >>those will follow later? > > > >Could you please repeat the questions you did not get an answer to? > > I've repeated some of them already. e.g. in this mail you still didn't > answer the "is it safe to drop the locks" question which was asked > twice. Rather than me repeating them yet again, I'd suggest you go back > and take another close read over my emails and your responses, and reply > to the questions that are still not resolved. Hans, let's just leave sound the way it is. I will remove that part of the patch. It might be better to leave a bad locking in that generates a warning rather than obscure the locking issue by removing the warning without fully understanding the issues. -- - Alfred Perlstein From imp at bsdimp.com Wed Aug 20 21:55:35 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Aug 20 21:55:41 2008 Subject: usb4bsd patch review In-Reply-To: <20080820211644.GD16977@elvis.mu.org> References: <200808201809.24620.hselasky@c2i.net> <48AC54B8.4040406@FreeBSD.org> <20080820211644.GD16977@elvis.mu.org> Message-ID: <20080820.155307.1102526075.imp@bsdimp.com> In message: <20080820211644.GD16977@elvis.mu.org> Alfred Perlstein writes: : [[ Reply to Hans at end of this ]] : [[ Reply to Kris inline ]] : : * Kris Kennaway [080820 10:30] wrote: : > Hans Petter Selasky wrote: : > >On Tuesday 19 August 2008, Kris Kennaway wrote: : > >> : > >>>>Also is it safe to drop and reacquire the lock here? : > >>>You have to drop the lock, else I get witness warnings. : > >>Yes, and presumably rightly so. It doesn't mean that dropping the lock : > >>and later reacquiring it is safe though; it could introduce races. : > > : > >Yes, I know. : > : > ...so what is the answer? : > : > >>OK, this seems unrelated to USB then and is something you should discuss : > >>with the sound maintainers. It sounds to me like the ability to "run : > >>without mutexes" is the real bug here, and "support" for that should be : > >>removed completely instead of patching it up downstream. : > > : > >Yes, and it would be nice if the sound maintainers would try out the new : > >USB stack, and propose how they want to solve the problems that exist in : > >the sound system. : > : > This is backwards. If you perceive problems in other subsystems you : > should take the lead on engaging with the relevant developers and : > resolving those problems to your mutual satisfaction, instead of : > inviting them to come to you. : : I think there has been a huge amount of effort just on the usb : side, I think expecting Hans to come up with a patch that : is "fix all freebsd issues" is a bit too much. I think we can : proceed in an organic matter and clean up these small nits as : time goes on, just like we do with almost every other problem... We should at least tag these, understand them and make sure they don't drop on the floor rather than just dismissing things out of hand... I have a few action items here because things have dropped on the floor in the past... : > >>>There are multiple issues: : > >>> : > >>>1) If PAGE_SIZE is 16384 bytes, then the code simply fails. : > >>>2) Sometimes PAGE_SHIFT is already defined. : > >>> : > >>>#if PAGE_SIZE == 4096 : > >>>#define PAGE_SHIFT 12 : > >>>#elif PAGE_SIZE == 8192 : > >>>#define PAGE_SHIFT 13 : > >>>#else : > >>>#error PAGE_SHIFT undefined! : > >>>#endif : > >>OK, but again, why? If some architecture is not defining the same : > >>symbols as the others then maybe that architecture should be fixed, : > >>instead of working around the effect downstream. : > > : > >Yes, but then there will be even more patches, and I've been told to : > >reduce the number of patches outside USB. : > : > The way you minimize patches outside of USB is by submitting separate : > patches that fix upstream issues at their source, instead of adding : > workarounds like several of those that appeared in this diff. : : It's a two line ifdef, I dare say we're being a bit pedantic here. : : How much of a showstopper is this in reality? How _wrong_ is it : compared to how _wrong_ the old usb code is? Are you taking into : account that these nits can be fixed easily compared to the extra : effort we will have to go through to submit all these stuff just for : a two line delta? Why not just use PAGE_SHIFT w/o defining it again? It looks like it is defined everywhere these days... It is part of the defined interface that the MD code is supposed to provide for everybody... Warner From kris at FreeBSD.org Wed Aug 20 22:18:38 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Aug 20 22:18:45 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <20080820211644.GD16977@elvis.mu.org> References: <20080818205914.GJ16977@elvis.mu.org> <200808192219.19246.hselasky@c2i.net> <48AB3D3A.4040303@FreeBSD.org> <200808201809.24620.hselasky@c2i.net> <48AC54B8.4040406@FreeBSD.org> <20080820211644.GD16977@elvis.mu.org> Message-ID: <48AC983B.4020409@FreeBSD.org> Alfred Perlstein wrote: >>> Yes, and it would be nice if the sound maintainers would try out the new >>> USB stack, and propose how they want to solve the problems that exist in >>> the sound system. >> This is backwards. If you perceive problems in other subsystems you >> should take the lead on engaging with the relevant developers and >> resolving those problems to your mutual satisfaction, instead of >> inviting them to come to you. > > I think there has been a huge amount of effort just on the usb > side, I think expecting Hans to come up with a patch that > is "fix all freebsd issues" is a bit too much. This is a straw man argument, since no-one except you has mentioned "fixing all freebsd issues" in this thread about importing a new USB stack. The issue under discussion is a particular part of the patch that you and Hans are proposing to commit, which introduces changes to non-USB parts of the system that it turns out are completely unrelated to USB. Anyway, we now agree that this should not be part of the USB import, and I urge you or Hans to follow the normal FreeBSD process, which involves sending mail to the relevant developers. >>>>> There are multiple issues: >>>>> >>>>> 1) If PAGE_SIZE is 16384 bytes, then the code simply fails. >>>>> 2) Sometimes PAGE_SHIFT is already defined. >>>>> >>>>> #if PAGE_SIZE == 4096 >>>>> #define PAGE_SHIFT 12 >>>>> #elif PAGE_SIZE == 8192 >>>>> #define PAGE_SHIFT 13 >>>>> #else >>>>> #error PAGE_SHIFT undefined! >>>>> #endif >>>> OK, but again, why? If some architecture is not defining the same >>>> symbols as the others then maybe that architecture should be fixed, >>>> instead of working around the effect downstream. >>> Yes, but then there will be even more patches, and I've been told to >>> reduce the number of patches outside USB. >> The way you minimize patches outside of USB is by submitting separate >> patches that fix upstream issues at their source, instead of adding >> workarounds like several of those that appeared in this diff. > > It's a two line ifdef, I dare say we're being a bit pedantic here. > > How much of a showstopper is this in reality? How _wrong_ is it > compared to how _wrong_ the old usb code is? Are you taking into > account that these nits can be fixed easily compared to the extra > effort we will have to go through to submit all these stuff just for > a two line delta? Calling me pedantic is not an argument, nor is saying "but the old code is worse". If neither you nor Hans can explain why this part of the diff is the best solution to some incompletely specified problem, then it's likely not to be. What architecture is this change even relevant for? >>>> P.S. There were a number of questions you didn't answer, can I assume >>>> those will follow later? >>> Could you please repeat the questions you did not get an answer to? >> I've repeated some of them already. e.g. in this mail you still didn't >> answer the "is it safe to drop the locks" question which was asked >> twice. Rather than me repeating them yet again, I'd suggest you go back >> and take another close read over my emails and your responses, and reply >> to the questions that are still not resolved. > > Hans, let's just leave sound the way it is. I will remove that > part of the patch. It might be better to leave a bad locking > in that generates a warning rather than obscure the locking issue > by removing the warning without fully understanding the issues. OK. Based on this review thread I think we have agreed that: * The ARM changes were already imported separately by warner * the sound changes will not go in since they're unrelated to USB and there are some unresolved questions there. It sounds like there are real bugs identified and possibly also fixed there, so I continue to encourage you or Hans to follow up with the sound developers so the problems can be resolved separately. * the newbus change is not needed (but warner liked Hans's helper function so maybe that should be committed separately) * the ndis module is not complete and will not go in yet, and the question about the above #ifdef will be resolved in the meantime * hans is going to work on adding back the individual drivers instead of bundling them * you and hans will work on the manpages post-commit with help from the doc guys Questions remaining: * Why is the PAGE_SHIFT change necessary? * The $FreeBSD$ expansion in files that were copied - will this confuse SVN or the CVS exporter? In CVS we had to make sure not to import expanded tags. Easiest solution is to just unexpand them. * How much of the userland support is incomplete or in flux, and what functionality is missing for users of the usb2 code until it is finished? Kris From hselasky at c2i.net Thu Aug 21 07:04:17 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Thu Aug 21 07:04:24 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <20080820211644.GD16977@elvis.mu.org> References: <20080818205914.GJ16977@elvis.mu.org> <48AC54B8.4040406@FreeBSD.org> <20080820211644.GD16977@elvis.mu.org> Message-ID: <200808210905.59150.hselasky@c2i.net> On Wednesday 20 August 2008, Alfred Perlstein wrote: > [[ Reply to Hans at end of this ]] > [[ Reply to Kris inline ]] > Hi, I've CC'ed multimedia. We have the following diff to mixer.c. Can anyone tell if it will have any negative consequences: --- sys/dev/sound/pcm/mixer.c August 2008 +++ sys.new/dev/sound/pcm/mixer.c August 2008 @@ -589,7 +589,7 @@ KASSERT(m->type == MIXER_TYPE_SECONDARY, ("%s(): illegal mixer type=%d", __func__, m->type)); - snd_mtxlock(m->lock); + /* mixer uninit can sleep --hps */ MIXER_UNINIT(m); @@ -704,14 +704,24 @@ return EBUSY; } + /* destroy dev can sleep --hps */ + + snd_mtxunlock(m->lock); + pdev->si_drv1 = NULL; destroy_dev(pdev); + snd_mtxlock(m->lock); + for (i = 0; i < SOUND_MIXER_NRDEVICES; i++) mixer_set(m, i, 0); mixer_setrecsrc(m, SOUND_MASK_MIC); + snd_mtxunlock(m->lock); + + /* mixer uninit can sleep --hps */ + MIXER_UNINIT(m); snd_mtxfree(m->lock); @@ -1280,3 +1290,16 @@ return (EINVAL); } > > >>P.S. There were a number of questions you didn't answer, can I assume > > >>those will follow later? > > > > > >Could you please repeat the questions you did not get an answer to? > > > > I've repeated some of them already. e.g. in this mail you still didn't > > answer the "is it safe to drop the locks" question which was asked > > twice. Rather than me repeating them yet again, I'd suggest you go back > > and take another close read over my emails and your responses, and reply > > to the questions that are still not resolved. > > Hans, let's just leave sound the way it is. I will remove that > part of the patch. It might be better to leave a bad locking > in that generates a warning rather than obscure the locking issue > by removing the warning without fully understanding the issues. USB audio is the only sound device I know about that is regularly plugged in and out, which is causing this code path to be executed, unless you load unload a sound module, which I think is very rarely done. The lock in question has never before been exposed to the underlying layers, so the funtions that are called should not have any knowledge about it and consequently not depend on it either. Alfred: Just make sure that everything builds. We can fix up these issues afterwards. If USB sound support is broken it is not that critical. ---HPS From imp at bsdimp.com Thu Aug 21 07:22:40 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Aug 21 07:22:55 2008 Subject: usb4bsd patch review In-Reply-To: <200808210905.59150.hselasky@c2i.net> References: <48AC54B8.4040406@FreeBSD.org> <20080820211644.GD16977@elvis.mu.org> <200808210905.59150.hselasky@c2i.net> Message-ID: <20080821.012146.1791046933.imp@bsdimp.com> In message: <200808210905.59150.hselasky@c2i.net> Hans Petter Selasky writes: : USB audio is the only sound device I know about that is regularly plugged in : and out, which is causing this code path to be executed, unless you load : unload a sound module, which I think is very rarely done. There's a number of CardBus sound cards that I've helped people debug over the years. Also, I know many people will load and unload the sound driver as a way to keep power usage down since doing so puts the device into D3 state. I've fielded many bugs over the years where people have issues with sound because they suddenly removed it while things were playing. Warner From aminoff at nber.org Thu Aug 21 15:27:36 2008 From: aminoff at nber.org (Alex Aminoff) Date: Thu Aug 21 15:27:43 2008 Subject: USB thumb drive does not newfs under FreeBSD 7.0 (but does under 6.2) Message-ID: <20080821144826.GD13934@perlw2.nber.org> We seem to have a USB thumb drive that works under FreeBSD 6.2 but does not newfs under 7.0. We hope that there is some package or library we have failed to upgrade. Any advice on how to proceed to resolve this would be greatly appreciated. If this is the wrong place to ask, please point us to the correct place. The versions of FreeBSD in question are 6.2-RELEASE-p9 vs 7.0-RELEASE-p2 both are generic kernels. It is the same hardware booted to one or the other OS. dmesg says: da1 at umass-sim0 bus 0 target 0 lun 0 da1: Removable Direct Access SCSI-0 device da1: 1.000MB/s transfers da1: 15424MB (31588352 512 byte sectors: 255H 63S/T 1966C) # fdisk -I /dev/da1 succeeds on both OSs # newfs /dev/da1s1 On 6.2, this succeeds, and we can mount and use the filesystem. On 7.0, newfs dies with cg 0: bad magic number Some searching on that error string turns up stuff about needing to reserve space at the beginning of a disk for the partition table. We have tried adjusting the parameters of the slice with fdisk with no success. In any case it seems strange that this would happen under 7 but not 6.2. Thanks, - Alex Aminoff BaseSpace.net National Bureau of Economic Research (nber.org) From imp at bsdimp.com Thu Aug 21 15:43:55 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Aug 21 15:44:02 2008 Subject: USB thumb drive does not newfs under FreeBSD 7.0 (but does under 6.2) In-Reply-To: <20080821144826.GD13934@perlw2.nber.org> References: <20080821144826.GD13934@perlw2.nber.org> Message-ID: <20080821.094348.1257475537.imp@bsdimp.com> In message: <20080821144826.GD13934@perlw2.nber.org> Alex Aminoff writes: : : : We seem to have a USB thumb drive that works under FreeBSD 6.2 but : does not newfs under 7.0. We hope that there is some package or : library we have failed to upgrade. Any advice on how to proceed to : resolve this would be greatly appreciated. If this is the wrong place : to ask, please point us to the correct place. : : The versions of FreeBSD in question are : : 6.2-RELEASE-p9 : vs : 7.0-RELEASE-p2 : : both are generic kernels. It is the same hardware booted to one or the : other OS. : : dmesg says: : : da1 at umass-sim0 bus 0 target 0 lun 0 : da1: Removable Direct Access SCSI-0 device : da1: 1.000MB/s transfers : da1: 15424MB (31588352 512 byte sectors: 255H 63S/T 1966C) : : # fdisk -I /dev/da1 : : succeeds on both OSs : : # newfs /dev/da1s1 : : On 6.2, this succeeds, and we can mount : and use the filesystem. On 7.0, newfs dies with : : cg 0: bad magic number : : Some searching on that error string turns up stuff about needing to : reserve space at the beginning of a disk for the partition table. We : have tried adjusting the parameters of the slice with fdisk with no : success. In any case it seems strange that this would happen under 7 : but not 6.2. Does something like "dd if=/dev/zero of=/dev/da1s1 bs=1m" work? Warner From hselasky at c2i.net Thu Aug 21 15:50:09 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Thu Aug 21 15:50:17 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <48AC983B.4020409@FreeBSD.org> References: <20080818205914.GJ16977@elvis.mu.org> <20080820211644.GD16977@elvis.mu.org> <48AC983B.4020409@FreeBSD.org> Message-ID: <200808211751.51465.hselasky@c2i.net> Hi, > OK. Based on this review thread I think we have agreed that: > > * The ARM changes were already imported separately by warner Great. > * the sound changes will not go in since they're unrelated to USB and > there are some unresolved questions there. It sounds like there are > real bugs identified and possibly also fixed there, so I continue to > encourage you or Hans to follow up with the sound developers so the > problems can be resolved separately. Fine. > > * the newbus change is not needed (but warner liked Hans's helper > function so maybe that should be committed separately) Fine. > > * the ndis module is not complete and will not go in yet, and the > question about the above #ifdef will be resolved in the meantime > Fine. > * hans is going to work on adding back the individual drivers instead of > bundling them Fine. > > * you and hans will work on the manpages post-commit with help from the > doc guys Fine. > > Questions remaining: > > * Why is the PAGE_SHIFT change necessary? According to what Warner stated in a recent e-mail, the page PAGE_SHIFT re-definition by the NDIS is redundant and can be removed. > * The $FreeBSD$ expansion in files that were copied - will this confuse > SVN or the CVS exporter? In CVS we had to make sure not to import > expanded tags. Easiest solution is to just unexpand them. Alfred, you have to answer this. > * How much of the userland support is incomplete or in flux, and what > functionality is missing for users of the usb2 code until it is finished? The USB userland library is nearly complete. All it lacks is proper documentation: svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/libusb20 The USB config utility is also starting to become finished. It will be renamed to usbconfig. Currently it is called usbview : svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/usbview --HPS From kris at FreeBSD.org Thu Aug 21 16:25:47 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu Aug 21 16:25:53 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <200808211751.51465.hselasky@c2i.net> References: <20080818205914.GJ16977@elvis.mu.org> <20080820211644.GD16977@elvis.mu.org> <48AC983B.4020409@FreeBSD.org> <200808211751.51465.hselasky@c2i.net> Message-ID: <48AD9708.5000106@FreeBSD.org> Hans Petter Selasky wrote: >> * How much of the userland support is incomplete or in flux, and what >> functionality is missing for users of the usb2 code until it is finished? > > The USB userland library is nearly complete. All it lacks is proper > documentation: > > svn --username anonsvn --password anonsvn \ > checkout svn://svn.turbocat.net/i4b/trunk/libusb20 > > The USB config utility is also starting to become finished. It will be renamed > to usbconfig. Currently it is called usbview : > > svn --username anonsvn --password anonsvn \ > checkout svn://svn.turbocat.net/i4b/trunk/usbview So...what functionality is missing for users of the usb2 code until it is finished? Stated even more clearly, what things will users of the USB2 code not be able to do until the above userland code is imported? Seriously, I'm trying to understand this! Kris From hselasky at c2i.net Thu Aug 21 16:38:32 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Thu Aug 21 16:38:39 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <48AD9708.5000106@FreeBSD.org> References: <20080818205914.GJ16977@elvis.mu.org> <200808211751.51465.hselasky@c2i.net> <48AD9708.5000106@FreeBSD.org> Message-ID: <200808211840.13109.hselasky@c2i.net> On Thursday 21 August 2008, Kris Kennaway wrote: > Hans Petter Selasky wrote: > >> * How much of the userland support is incomplete or in flux, and what > >> functionality is missing for users of the usb2 code until it is > >> finished? > > > > The USB userland library is nearly complete. All it lacks is proper > > documentation: > > > > svn --username anonsvn --password anonsvn \ > > checkout svn://svn.turbocat.net/i4b/trunk/libusb20 > > > > The USB config utility is also starting to become finished. It will be > > renamed to usbconfig. Currently it is called usbview : > > > > svn --username anonsvn --password anonsvn \ > > checkout svn://svn.turbocat.net/i4b/trunk/usbview > > So...what functionality is missing for users of the usb2 code until it > is finished? > > Stated even more clearly, what things will users of the USB2 code not be > able to do until the above userland code is imported? > > Seriously, I'm trying to understand this! > Hi, There are some USB drivers which run in userland that will not work until this library is complete. These are currently not part of the FreeBSD distribution. You find them in /usr/ports : grep libusb /usr/ports/INDEX The kernel USB drivers provided under /sys/dev/usb2 do not directly depend on any userland utilities, but rather indirectly through the TTY, KBD, NET ... One exception is the USB mouse driver which depends on "moused", and currently have some warnings because moused tries to load the old ums module, which fails. --HPS From kris at FreeBSD.org Thu Aug 21 16:45:17 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu Aug 21 16:45:24 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <200808211840.13109.hselasky@c2i.net> References: <20080818205914.GJ16977@elvis.mu.org> <200808211751.51465.hselasky@c2i.net> <48AD9708.5000106@FreeBSD.org> <200808211840.13109.hselasky@c2i.net> Message-ID: <48AD9B9A.8070403@FreeBSD.org> Hans Petter Selasky wrote: > On Thursday 21 August 2008, Kris Kennaway wrote: >> Hans Petter Selasky wrote: >>>> * How much of the userland support is incomplete or in flux, and what >>>> functionality is missing for users of the usb2 code until it is >>>> finished? >>> The USB userland library is nearly complete. All it lacks is proper >>> documentation: >>> >>> svn --username anonsvn --password anonsvn \ >>> checkout svn://svn.turbocat.net/i4b/trunk/libusb20 >>> >>> The USB config utility is also starting to become finished. It will be >>> renamed to usbconfig. Currently it is called usbview : >>> >>> svn --username anonsvn --password anonsvn \ >>> checkout svn://svn.turbocat.net/i4b/trunk/usbview >> So...what functionality is missing for users of the usb2 code until it >> is finished? >> >> Stated even more clearly, what things will users of the USB2 code not be >> able to do until the above userland code is imported? >> >> Seriously, I'm trying to understand this! >> > > Hi, > > There are some USB drivers which run in userland that will not work until this > library is complete. These are currently not part of the FreeBSD > distribution. You find them in /usr/ports : > > grep libusb /usr/ports/INDEX > > The kernel USB drivers provided under /sys/dev/usb2 do not directly depend on > any userland utilities, but rather indirectly through the TTY, KBD, NET ... > > One exception is the USB mouse driver which depends on "moused", and currently > have some warnings because moused tries to load the old ums module, which > fails. OK, now we're approaching half way. The moused thing should be documented somewhere with a workaround (or fix). If the new ums2 module is present before moused is started will it still try to load the old one? Is there another workaround? What about the second thing: usbconfig? Kris From hselasky at c2i.net Thu Aug 21 16:55:08 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Thu Aug 21 16:55:15 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <48AD9B9A.8070403@FreeBSD.org> References: <20080818205914.GJ16977@elvis.mu.org> <200808211840.13109.hselasky@c2i.net> <48AD9B9A.8070403@FreeBSD.org> Message-ID: <200808211856.47568.hselasky@c2i.net> On Thursday 21 August 2008, Kris Kennaway wrote: > Hans Petter Selasky wrote: > > On Thursday 21 August 2008, Kris Kennaway wrote: > >> Hans Petter Selasky wrote: > >>>> * How much of the userland support is incomplete or in flux, and what > >>>> functionality is missing for users of the usb2 code until it is > >>>> finished? > >>> > >>> The USB userland library is nearly complete. All it lacks is proper > >>> documentation: > >>> > >>> svn --username anonsvn --password anonsvn \ > >>> checkout svn://svn.turbocat.net/i4b/trunk/libusb20 > >>> > >>> The USB config utility is also starting to become finished. It will be > >>> renamed to usbconfig. Currently it is called usbview : > >>> > >>> svn --username anonsvn --password anonsvn \ > >>> checkout svn://svn.turbocat.net/i4b/trunk/usbview > >> > >> So...what functionality is missing for users of the usb2 code until it > >> is finished? > >> > >> Stated even more clearly, what things will users of the USB2 code not be > >> able to do until the above userland code is imported? > >> > >> Seriously, I'm trying to understand this! > > > > Hi, > > > > There are some USB drivers which run in userland that will not work until > > this library is complete. These are currently not part of the FreeBSD > > distribution. You find them in /usr/ports : > > > > grep libusb /usr/ports/INDEX > > > > The kernel USB drivers provided under /sys/dev/usb2 do not directly > > depend on any userland utilities, but rather indirectly through the TTY, > > KBD, NET ... > > > > One exception is the USB mouse driver which depends on "moused", and > > currently have some warnings because moused tries to load the old ums > > module, which fails. > > OK, now we're approaching half way. The moused thing should be > documented somewhere with a workaround (or fix). If the new ums2 module > is present before moused is started will it still try to load the old > one? Is there another workaround? Hi, What happens is this: 1. devd reports "ums0" like before. 2. moused is started 3. moused tries to kldload ums 4. The ums module depens on the usb module which is also tried loaded. 5. Loading the usb module fails. 6. moused finally tries to open /dev/ums0 and the mouse works like before. ums0: on usbus3 ums0: 3 buttons and [XYZ] coordinates Symlink: ums0 -> usb3.3.0.16 module_register: module pci/uhci already exists! Module pci/uhci failed to register: 17 module_register: module cardbus/uhci already exists! Module cardbus/uhci failed to register: 17 module_register: module pci/ohci already exists! Module pci/ohci failed to register: 17 module_register: module cardbus/ohci already exists! Module cardbus/ohci failed to register: 17 module_register: module pci/ehci already exists! Module pci/ehci failed to register: 17 module_register: module cardbus/ehci already exists! Module cardbus/ehci failed to register: 17 KLD ums.ko: depends on usb - not available > > What about the second thing: usbconfig? The USB stack will work fine without "usbconfig". Its purpose is mostly to view the currently attached USB devices, where the USB devices are located and to select a non-default USB configuration. One thing which might be missed is to change owner and permission of a USB device, which means you must be either UID=root or GID=OPERATOR to be able to use USB devices that create devices under /dev/ . --HPS From pfgshield-freebsd at yahoo.com Thu Aug 21 17:03:05 2008 From: pfgshield-freebsd at yahoo.com (Pedro Giffuni) Date: Thu Aug 21 17:03:11 2008 Subject: USB Video class Message-ID: <548051.80257.qm@web32701.mail.mud.yahoo.com> BTW; There was/is also a NetBSD GSoC project: http://netbsd-soc.sourceforge.net/projects/uvc/ cheers, Pedro. __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it From chuckr at telenix.org Thu Aug 21 17:26:54 2008 From: chuckr at telenix.org (Chuck Robey) Date: Thu Aug 21 17:27:01 2008 Subject: trying out the new usb stuff ... Message-ID: <48ADA51C.5020107@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm not sure how to change my config to try out the new usb2 code. I saw where you mentioned the new config lines, but I'm not sure what to do with the devices I have in my kernel now (I don't use the modules for usb). I mean, things like usb, ohci, ehci, etc., do you keep them in or change them (and what's the complete list of required changes, not only the additions?) Lastly, are there any changes contemplated in the usb hid code? I'm not sure if it's my own ineptness, or bugs in the usbhid code, but there are parts of that libhibhid code that I've never been able to get to work (I needed to write my own), so I'm really interested if the usbhid stuff is going to change or not. Thanks. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkitpRwACgkQz62J6PPcoOkCFwCfYMkUkqgCnH26ScSe8p6q4VJF MOkAoJr9BFzpxhx17ZMaK1B1cHknUgBe =gEqx -----END PGP SIGNATURE----- From kris at FreeBSD.org Thu Aug 21 17:31:24 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu Aug 21 17:31:33 2008 Subject: usb4bsd patch review [was Re: ...] In-Reply-To: <200808211856.47568.hselasky@c2i.net> References: <20080818205914.GJ16977@elvis.mu.org> <200808211840.13109.hselasky@c2i.net> <48AD9B9A.8070403@FreeBSD.org> <200808211856.47568.hselasky@c2i.net> Message-ID: <48ADA66A.3040906@FreeBSD.org> Hans Petter Selasky wrote: > On Thursday 21 August 2008, Kris Kennaway wrote: >> Hans Petter Selasky wrote: >>> On Thursday 21 August 2008, Kris Kennaway wrote: >>>> Hans Petter Selasky wrote: >>>>>> * How much of the userland support is incomplete or in flux, and what >>>>>> functionality is missing for users of the usb2 code until it is >>>>>> finished? >>>>> The USB userland library is nearly complete. All it lacks is proper >>>>> documentation: >>>>> >>>>> svn --username anonsvn --password anonsvn \ >>>>> checkout svn://svn.turbocat.net/i4b/trunk/libusb20 >>>>> >>>>> The USB config utility is also starting to become finished. It will be >>>>> renamed to usbconfig. Currently it is called usbview : >>>>> >>>>> svn --username anonsvn --password anonsvn \ >>>>> checkout svn://svn.turbocat.net/i4b/trunk/usbview >>>> So...what functionality is missing for users of the usb2 code until it >>>> is finished? >>>> >>>> Stated even more clearly, what things will users of the USB2 code not be >>>> able to do until the above userland code is imported? >>>> >>>> Seriously, I'm trying to understand this! >>> Hi, >>> >>> There are some USB drivers which run in userland that will not work until >>> this library is complete. These are currently not part of the FreeBSD >>> distribution. You find them in /usr/ports : >>> >>> grep libusb /usr/ports/INDEX >>> >>> The kernel USB drivers provided under /sys/dev/usb2 do not directly >>> depend on any userland utilities, but rather indirectly through the TTY, >>> KBD, NET ... >>> >>> One exception is the USB mouse driver which depends on "moused", and >>> currently have some warnings because moused tries to load the old ums >>> module, which fails. >> OK, now we're approaching half way. The moused thing should be >> documented somewhere with a workaround (or fix). If the new ums2 module >> is present before moused is started will it still try to load the old >> one? Is there another workaround? > > Hi, > > What happens is this: > > 1. devd reports "ums0" like before. > 2. moused is started > 3. moused tries to kldload ums > 4. The ums module depens on the usb module which is also tried loaded. > 5. Loading the usb module fails. > 6. moused finally tries to open /dev/ums0 and the mouse works like before. > > ums0: 1.10/3.00, addr 3> on usbus3 > ums0: 3 buttons and [XYZ] coordinates > Symlink: ums0 -> usb3.3.0.16 > > module_register: module pci/uhci already exists! > Module pci/uhci failed to register: 17 > module_register: module cardbus/uhci already exists! > Module cardbus/uhci failed to register: 17 > module_register: module pci/ohci already exists! > Module pci/ohci failed to register: 17 > module_register: module cardbus/ohci already exists! > Module cardbus/ohci failed to register: 17 > module_register: module pci/ehci already exists! > Module pci/ehci failed to register: 17 > module_register: module cardbus/ehci already exists! > Module cardbus/ehci failed to register: 17 > KLD ums.ko: depends on usb - not available OK, so just cosmetic. It kind of sounds like moused is doing the wrong thing, but this can hopefully be fixed later. >> What about the second thing: usbconfig? > > The USB stack will work fine without "usbconfig". Its purpose is mostly to > view the currently attached USB devices, where the USB devices are located > and to select a non-default USB configuration. One thing which might be > missed is to change owner and permission of a USB device, which means you > must be either UID=root or GID=OPERATOR to be able to use USB devices that > create devices under /dev/ . OK great, this isn't critical either. I think all of the issues I raised are agreed upon now! Unfortunately since Alfred is going away for 3 weeks it looks like that is now going to put this on hold for a bit. It's probably a good thing that the initial import was delayed actually, since he is going to need to be available for the inevitable followup work after it gets imported, and leaving 3 days after the planned import would have really hurt that process. Unless someone else comes forward to take over from Alfred, here's what I recommend as a plan: * post the revised diff with the minor changes/bits left out that we have agreed upon. Users can continue to test this commit candidate while Alfred is away. * When Alfred gets back and has a block of free time, he will proceed with the import and handle followup commits to fix issues that are identified. * If the "commit candidate diff" changes in the meantime due to bug fixes etc, then you should keep the mailing list updated regularly with a pointer to the latest version of the commit candidate diff. Other new stuff like the forthcoming userland changes should stay out of this first diff for now so we don't invalidate things that have already been reviewed. * In the meantime you can continue to work on the missing stuff like manpages, userland, unbundling drivers, etc. With luck, some or all of this will also be ready by the time Alfred gets back, and you can post a second diff for review and subsequent commit around the same time. How does this plan sound to you? Kris From imp at bsdimp.com Thu Aug 21 17:53:40 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Aug 21 17:53:52 2008 Subject: usb4bsd patch review In-Reply-To: <48ADA66A.3040906@FreeBSD.org> References: <48AD9B9A.8070403@FreeBSD.org> <200808211856.47568.hselasky@c2i.net> <48ADA66A.3040906@FreeBSD.org> Message-ID: <20080821.115210.-524876976.imp@bsdimp.com> In message: <48ADA66A.3040906@FreeBSD.org> Kris Kennaway writes: : Hans Petter Selasky wrote: : > On Thursday 21 August 2008, Kris Kennaway wrote: : >> Hans Petter Selasky wrote: : >>> On Thursday 21 August 2008, Kris Kennaway wrote: : >>>> Hans Petter Selasky wrote: : >>>>>> * How much of the userland support is incomplete or in flux, and what : >>>>>> functionality is missing for users of the usb2 code until it is : >>>>>> finished? : >>>>> The USB userland library is nearly complete. All it lacks is proper : >>>>> documentation: : >>>>> : >>>>> svn --username anonsvn --password anonsvn \ : >>>>> checkout svn://svn.turbocat.net/i4b/trunk/libusb20 : >>>>> : >>>>> The USB config utility is also starting to become finished. It will be : >>>>> renamed to usbconfig. Currently it is called usbview : : >>>>> : >>>>> svn --username anonsvn --password anonsvn \ : >>>>> checkout svn://svn.turbocat.net/i4b/trunk/usbview : >>>> So...what functionality is missing for users of the usb2 code until it : >>>> is finished? : >>>> : >>>> Stated even more clearly, what things will users of the USB2 code not be : >>>> able to do until the above userland code is imported? : >>>> : >>>> Seriously, I'm trying to understand this! : >>> Hi, : >>> : >>> There are some USB drivers which run in userland that will not work until : >>> this library is complete. These are currently not part of the FreeBSD : >>> distribution. You find them in /usr/ports : : >>> : >>> grep libusb /usr/ports/INDEX : >>> : >>> The kernel USB drivers provided under /sys/dev/usb2 do not directly : >>> depend on any userland utilities, but rather indirectly through the TTY, : >>> KBD, NET ... : >>> : >>> One exception is the USB mouse driver which depends on "moused", and : >>> currently have some warnings because moused tries to load the old ums : >>> module, which fails. : >> OK, now we're approaching half way. The moused thing should be : >> documented somewhere with a workaround (or fix). If the new ums2 module : >> is present before moused is started will it still try to load the old : >> one? Is there another workaround? : > : > Hi, : > : > What happens is this: : > : > 1. devd reports "ums0" like before. : > 2. moused is started : > 3. moused tries to kldload ums : > 4. The ums module depens on the usb module which is also tried loaded. : > 5. Loading the usb module fails. : > 6. moused finally tries to open /dev/ums0 and the mouse works like before. : > : > ums0: 1.10/3.00, addr 3> on usbus3 : > ums0: 3 buttons and [XYZ] coordinates : > Symlink: ums0 -> usb3.3.0.16 : > : > module_register: module pci/uhci already exists! : > Module pci/uhci failed to register: 17 : > module_register: module cardbus/uhci already exists! : > Module cardbus/uhci failed to register: 17 : > module_register: module pci/ohci already exists! : > Module pci/ohci failed to register: 17 : > module_register: module cardbus/ohci already exists! : > Module cardbus/ohci failed to register: 17 : > module_register: module pci/ehci already exists! : > Module pci/ehci failed to register: 17 : > module_register: module cardbus/ehci already exists! : > Module cardbus/ehci failed to register: 17 : > KLD ums.ko: depends on usb - not available : : OK, so just cosmetic. It kind of sounds like moused is doing the wrong : thing, but this can hopefully be fixed later. : : >> What about the second thing: usbconfig? : > : > The USB stack will work fine without "usbconfig". Its purpose is mostly to : > view the currently attached USB devices, where the USB devices are located : > and to select a non-default USB configuration. One thing which might be : > missed is to change owner and permission of a USB device, which means you : > must be either UID=root or GID=OPERATOR to be able to use USB devices that : > create devices under /dev/ . : : OK great, this isn't critical either. I think all of the issues I : raised are agreed upon now! : : Unfortunately since Alfred is going away for 3 weeks it looks like that : is now going to put this on hold for a bit. It's probably a good thing : that the initial import was delayed actually, since he is going to need : to be available for the inevitable followup work after it gets imported, : and leaving 3 days after the planned import would have really hurt that : process. : : Unless someone else comes forward to take over from Alfred, here's what : I recommend as a plan: : : * post the revised diff with the minor changes/bits left out that we : have agreed upon. Users can continue to test this commit candidate : while Alfred is away. : : * When Alfred gets back and has a block of free time, he will proceed : with the import and handle followup commits to fix issues that are : identified. : : * If the "commit candidate diff" changes in the meantime due to bug : fixes etc, then you should keep the mailing list updated regularly with : a pointer to the latest version of the commit candidate diff. Other new : stuff like the forthcoming userland changes should stay out of this : first diff for now so we don't invalidate things that have already been : reviewed. : : * In the meantime you can continue to work on the missing stuff like : manpages, userland, unbundling drivers, etc. With luck, some or all of : this will also be ready by the time Alfred gets back, and you can post a : second diff for review and subsequent commit around the same time. : : How does this plan sound to you? I'd be willing to pick up the ball a little bit here: There's some base system (not driver) issues that can be resolved so that we can improve the quality of the commit candidates and underlying FreeBSD. Warner From hselasky at c2i.net Thu Aug 21 18:07:09 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Thu Aug 21 18:07:27 2008 Subject: trying out the new usb stuff ... In-Reply-To: <48ADA51C.5020107@telenix.org> References: <48ADA51C.5020107@telenix.org> Message-ID: <200808212008.50544.hselasky@c2i.net> On Thursday 21 August 2008, Chuck Robey wrote: > I'm not sure how to change my config to try out the new usb2 code. I saw > where you mentioned the new config lines, but I'm not sure what to do with > the devices I have in my kernel now (I don't use the modules for usb). I > mean, things like usb, ohci, ehci, etc., do you keep them in or change them > (and what's the complete list of required changes, not only the additions?) Hi Chuck, 1. Remove all the USB modules from the kernel config. 2. Add this to your /boot/loader.conf after installing the patches and building a new kernel. usb2_core_load=YES usb2_controller_load=YES usb2_input_load=YES > Lastly, are there any changes contemplated in the usb hid code? I'm not > sure if it's my own ineptness, or bugs in the usbhid code, but there are > parts of that libhibhid code that I've never been able to get to work (I > needed to write my own), so I'm really interested if the usbhid stuff is > going to change or not. Yes, there are some new IOCTLs which might solve some of your problems. /* Generic HID device */ #define USB_GET_REPORT_DESC _IOR ('U', 21, struct usb2_gen_descriptor) #define USB_SET_IMMED _IOW ('U', 22, int) #define USB_GET_REPORT _IOWR('U', 23, struct usb2_gen_descriptor) #define USB_SET_REPORT _IOW ('U', 24, struct usb2_gen_descriptor) #define USB_GET_REPORT_ID _IOR ('U', 25, int) struct usb2_gen_descriptor { void *ugd_data; uint16_t ugd_lang_id; uint16_t ugd_maxlen; uint16_t ugd_actlen; uint16_t ugd_offset; uint8_t ugd_config_index; uint8_t ugd_string_index; uint8_t ugd_iface_index; uint8_t ugd_altif_index; uint8_t ugd_endpt_index; uint8_t ugd_report_type; uint8_t reserved[8]; }; For UHID you only need to initialise ugd_data, ugd_maxlen and ugd_report_type . --HPS From Alexander at Leidinger.net Fri Aug 22 08:45:47 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Fri Aug 22 08:45:55 2008 Subject: usb4bsd patch review In-Reply-To: <20080821.115210.-524876976.imp@bsdimp.com> References: <48AD9B9A.8070403@FreeBSD.org> <200808211856.47568.hselasky@c2i.net> <48ADA66A.3040906@FreeBSD.org> <20080821.115210.-524876976.imp@bsdimp.com> Message-ID: <20080822102925.12906gou50yqgpvw@webmail.leidinger.net> Quoting "M. Warner Losh" (from Thu, 21 Aug 2008 11:52:10 -0600 (MDT)): > In message: <48ADA66A.3040906@FreeBSD.org> > Kris Kennaway writes: > : Hans Petter Selasky wrote: > : > The USB stack will work fine without "usbconfig". Its purpose is > : > mostly to > : > view the currently attached USB devices, where the USB devices : > > are located > : > and to select a non-default USB configuration. One thing which might be > : > missed is to change owner and permission of a USB device, which means you > : > must be either UID=root or GID=OPERATOR to be able to use USB : > > devices that > : > create devices under /dev/ . > : > : OK great, this isn't critical either. I think all of the issues I > : raised are agreed upon now! Wait a moment. Does this mean the devfs stuff to handle the access rights (devfs.rules or manual chown/chmod by root) does not work with the new usb stuff? If the answer is yes, I would see this as some kind of nasty bug (I don't think this shall be a showstopper, as long as this is fixed later). Bye, Alexander. -- The scratch on the record is always through the song you like most. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From kris at FreeBSD.org Fri Aug 22 08:59:43 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Fri Aug 22 08:59:49 2008 Subject: usb4bsd patch review In-Reply-To: <20080822102925.12906gou50yqgpvw@webmail.leidinger.net> References: <48AD9B9A.8070403@FreeBSD.org> <200808211856.47568.hselasky@c2i.net> <48ADA66A.3040906@FreeBSD.org> <20080821.115210.-524876976.imp@bsdimp.com> <20080822102925.12906gou50yqgpvw@webmail.leidinger.net> Message-ID: <48AE7FFA.7070502@FreeBSD.org> Alexander Leidinger wrote: > Quoting "M. Warner Losh" (from Thu, 21 Aug 2008 > 11:52:10 -0600 (MDT)): > >> In message: <48ADA66A.3040906@FreeBSD.org> >> Kris Kennaway writes: >> : Hans Petter Selasky wrote: > >> : > The USB stack will work fine without "usbconfig". Its purpose is : >> > mostly to >> : > view the currently attached USB devices, where the USB devices : > >> are located >> : > and to select a non-default USB configuration. One thing which >> might be >> : > missed is to change owner and permission of a USB device, which >> means you >> : > must be either UID=root or GID=OPERATOR to be able to use USB : > >> devices that >> : > create devices under /dev/ . >> : >> : OK great, this isn't critical either. I think all of the issues I >> : raised are agreed upon now! > > Wait a moment. Does this mean the devfs stuff to handle the access > rights (devfs.rules or manual chown/chmod by root) does not work with > the new usb stuff? If the answer is yes, I would see this as some kind > of nasty bug (I don't think this shall be a showstopper, as long as this > is fixed later). Yes, he said it will be fixed later. Kris From Alexander at Leidinger.net Fri Aug 22 09:37:47 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Fri Aug 22 09:37:57 2008 Subject: usb4bsd patch review In-Reply-To: <48AE7FFA.7070502@FreeBSD.org> References: <48AD9B9A.8070403@FreeBSD.org> <200808211856.47568.hselasky@c2i.net> <48ADA66A.3040906@FreeBSD.org> <20080821.115210.-524876976.imp@bsdimp.com> <20080822102925.12906gou50yqgpvw@webmail.leidinger.net> <48AE7FFA.7070502@FreeBSD.org> Message-ID: <20080822113738.75855zbz0hkckp8o@webmail.leidinger.net> Quoting "Kris Kennaway" (from Fri, 22 Aug 2008 10:59:38 +0200): > Alexander Leidinger wrote: >> Quoting "M. Warner Losh" (from Thu, 21 Aug 2008 >> 11:52:10 -0600 (MDT)): >> >>> In message: <48ADA66A.3040906@FreeBSD.org> >>> Kris Kennaway writes: >>> : Hans Petter Selasky wrote: >> >>> : > The USB stack will work fine without "usbconfig". Its purpose >>> is : > mostly to >>> : > view the currently attached USB devices, where the USB devices >>> : > are located >>> : > and to select a non-default USB configuration. One thing which might be >>> : > missed is to change owner and permission of a USB device, >>> which means you >>> : > must be either UID=root or GID=OPERATOR to be able to use USB >>> : > devices that >>> : > create devices under /dev/ . >>> : >>> : OK great, this isn't critical either. I think all of the issues I >>> : raised are agreed upon now! >> >> Wait a moment. Does this mean the devfs stuff to handle the access >> rights (devfs.rules or manual chown/chmod by root) does not work >> with the new usb stuff? If the answer is yes, I would see this as >> some kind of nasty bug (I don't think this shall be a showstopper, >> as long as this is fixed later). > > Yes, he said it will be fixed later. You are aware that I point out that this may or may not suggest that HPS is circumventing the normal devfs infrastructure and that this may or may not be a problem and should be reviewed by someone with knowledge about the devfs infrastructure? And as he mentioned that in the context of the userland utilities, it may be interesting if this means if an USB specific userland utility will be responsible to change the ownership and file access or not. If yes, what are the consequences from a security point of view and what about POLA (devfs.rules, chown/chmod)? I want to see this new USB subsystem, but if the answer to the above paragraph is yes, then this would be a showstopper for me (IMO the replacement should work in this regard as before, I don't say it can not be changed after enough people agree that the replacement was successful). Bye, Alexander. -- Such a fine first dream! But they laughed at me; they said I had made it up. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From aledm at qix.co.uk Fri Aug 22 15:30:04 2008 From: aledm at qix.co.uk (Aled Morris) Date: Fri Aug 22 15:30:19 2008 Subject: usb/126740: ulpt doesn't work on 7.0-RELEASE Message-ID: <200808221529.m7MFTsOT065282@www.freebsd.org> >Number: 126740 >Category: usb >Synopsis: ulpt doesn't work on 7.0-RELEASE >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Aug 22 15:30:03 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Aled Morris >Release: 7.0-RELEASE >Organization: >Environment: FreeBSD kryten.carneddi.net 7.0-RELEASE FreeBSD 7.0-RELEASE #1: Fri Aug 22 15:21:55 BST 2008 aledm@kryten.carneddi.net:/usr/src/sys/i386/compile/DELL i386 >Description: Trying to print to a Dymo label printer 400 connected via USB to my Dell 6000 laptop running 7.0-RELEASE. This used to work on this hardware under an older release of FreeBSD 5. The printer works on the same hardware if I boot Windows XP. The symptom is that writing to the USB port times out and returns an error EIO. I am trying to use CUPS however the problem also appears if you just do: # echo hello >/dev/ulpt0 su: echo: write error: Input/output error There is a delay of exactly 10 seconds before the error message is printed. Here is the output of dmesg with USB_DEBUG set to 999: ulptopen: flags=0x0 ulpt_reset usbd_alloc_xfer() = 0xc58ea600 usbd_transfer: xfer=0xc58ea600, flags=2, pipe=0xc5414800, running=0 usbd_dump_queue: pipe=0xc5414800 usb_insert_transfer: pipe=0xc5414800 running=0 timeout=5000 usb_event_thread: woke up usb_discover usb_add_task: task=0xc58ea790 usb_task_thread: woke up task=0xc58ea790 usb_schedsoftintr: polling=0 usb_transfer_complete: pipe=0xc5414800 xfer=0xc58ea600 status=15 actlen=0 usb_transfer_complete: repeat=0 new head=0 usbd_start_next: pipe=0xc5414800, xfer=0 usbd_free_xfer: 0xc58ea600 usbd_alloc_xfer() = 0xc58ea600 usbd_transfer: xfer=0xc58ea600, flags=2, pipe=0xc5414800, running=0 usbd_dump_queue: pipe=0xc5414800 usb_insert_transfer: pipe=0xc5414800 running=0 timeout=5000 usb_add_task: task=0xc58ea790 usb_task_thread: woke up task=0xc58ea790 usb_schedsoftintr: polling=0 usb_transfer_complete: pipe=0xc5414800 xfer=0xc58ea600 status=15 actlen=0 usb_transfer_complete: repeat=0 new head=0 usbd_start_next: pipe=0xc5414800, xfer=0 usbd_free_xfer: 0xc58ea600 usbd_open_pipe: iface=0xc655cd60 address=0x2 flags=0x0 usbd_setup_pipe: dev=0xc6796780 iface=0xc655cd60 ep=0xc655c8cc pipe=0xe7b4f9a8 usbd_alloc_xfer() = 0xc58ea600 ulpt_open: open input pipe usbd_open_pipe: iface=0xc655cd60 address=0x82 flags=0x0 usbd_setup_pipe: dev=0xc6796780 iface=0xc655cd60 ep=0xc655c8c0 pipe=0xe7b4f9a8 usbd_alloc_xfer() = 0xc527d200 ulpt_open: start read callout ulptopen: done, error=0 ulptwrite usbd_alloc_xfer() = 0xc58ea400 usbd_transfer: xfer=0xc58ea400, flags=2, pipe=0xc5414800, running=0 usbd_dump_queue: pipe=0xc5414800 usb_insert_transfer: pipe=0xc5414800 running=0 timeout=5000 usb_schedsoftintr: polling=0 usb_transfer_complete: pipe=0xc5414800 xfer=0xc58ea400 status=0 actlen=1 usb_transfer_complete: repeat=0 new head=0 usbd_start_next: pipe=0xc5414800, xfer=0 usbd_free_xfer: 0xc58ea400 ulpt_status: status=0x18 err=0 ulptwrite: transfer 6 bytes usbd_bulk_transfer: start transfer 6 bytes usbd_transfer: xfer=0xc58ea600, flags=1, pipe=0xc6796400, running=0 usbd_dump_queue: pipe=0xc6796400 usb_insert_transfer: pipe=0xc6796400 running=0 timeout=0 usb_schedsoftintr: polling=0 usb_transfer_complete: pipe=0xc6796400 xfer=0xc58ea600 status=17 actlen=6 usb_transfer_complete: repeat=0 new head=0 usbd_start_next: pipe=0xc6796400, xfer=0 usbd_bulk_transfer: transferred 6 usbd_bulk_transfer: error=17 usbd_clear_endpoint_stall usbd_alloc_xfer() = 0xc58ea400 usbd_transfer: xfer=0xc58ea400, flags=2, pipe=0xc5414800, running=0 usbd_dump_queue: pipe=0xc5414800 usb_insert_transfer: pipe=0xc5414800 running=0 timeout=5000 usb_schedsoftintr: polling=0 usb_schedsoftintr: polling=0 usb_transfer_complete: pipe=0xc5414800 xfer=0xc58ea400 status=0 actlen=0 usb_transfer_complete: repeat=0 new head=0 usbd_start_next: pipe=0xc5414800, xfer=0 usbd_free_xfer: 0xc58ea400 ulptwrite: error=17 usbd_ar_pipe: pipe=0xc6796400 usbd_dump_queue: pipe=0xc6796400 usbd_free_xfer: 0xc58ea600 usbd_ar_pipe: pipe=0xc61d1800 usbd_dump_queue: pipe=0xc61d1800 usbd_free_xfer: 0xc527d200 ulptclose: closed >How-To-Repeat: echo hello >/dev/ulpt0 >Fix: >Release-Note: >Audit-Trail: >Unformatted: From danfe at nsu.ru Fri Aug 22 16:07:45 2008 From: danfe at nsu.ru (Alexey Dokuchaev) Date: Fri Aug 22 16:07:54 2008 Subject: PR usb/117185 anyone? Message-ID: <20080822151201.GA23538@regency.nsu.ru> Hi there, I'm wondering if anyone can take a look at PR usb/117185 and possibly commit it? It looks those patches were well-tested for quite a few months already. I'm eager to provide any needed assistance with this patch (further review, testing, etc.). Patches for RELENG_6|7 and -CURRENT available. Thanks. ./danfe From pb at ludd.ltu.se Fri Aug 22 19:48:47 2008 From: pb at ludd.ltu.se (Peter B) Date: Fri Aug 22 19:48:54 2008 Subject: usb match() function Message-ID: <200808221948.m7MJmglt004097@brother.ludd.ltu.se> Within the usb drivers (/usr/src/sys/dev/usb/u*.c) there's an matching routine where the 'uaa->iface' is supposed to be assigned before the routine is called. However for a new device or class this doesn't seem to work. Instead 'uaa' is set like for an generic device (two interfaces, no "default" in my case). So how is one supposed to make the kernel fill in 'uaa->iface' ..? Code excerpt: static int *_match(device_t self) { struct usb_attach_arg *uaa = device_get_ivars(self); usb_interface_descriptor_t *id; DPRINTFN(10,("*_match\n")); if (uaa->iface == NULL) return (UMATCH_NONE); From hselasky at c2i.net Sat Aug 23 06:02:25 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Aug 23 06:02:33 2008 Subject: usb4bsd patch review In-Reply-To: <20080822113738.75855zbz0hkckp8o@webmail.leidinger.net> References: <48AD9B9A.8070403@FreeBSD.org> <48AE7FFA.7070502@FreeBSD.org> <20080822113738.75855zbz0hkckp8o@webmail.leidinger.net> Message-ID: <200808230804.03275.hselasky@c2i.net> On Friday 22 August 2008, Alexander Leidinger wrote: > Quoting "Kris Kennaway" (from Fri, 22 Aug 2008 > > 10:59:38 +0200): > > Alexander Leidinger wrote: > >> Quoting "M. Warner Losh" (from Thu, 21 Aug 2008 > >> > >> 11:52:10 -0600 (MDT)): > >>> In message: <48ADA66A.3040906@FreeBSD.org> > >>> > >>> Kris Kennaway writes: > >>> : Hans Petter Selasky wrote: > >>> : > The USB stack will work fine without "usbconfig". Its purpose > >>> > >>> is : > mostly to > >>> > >>> : > view the currently attached USB devices, where the USB devices > >>> : > are located > >>> : > and to select a non-default USB configuration. One thing which > >>> : > might be missed is to change owner and permission of a USB device, > >>> > >>> which means you > >>> > >>> : > must be either UID=root or GID=OPERATOR to be able to use USB > >>> : > devices that > >>> : > create devices under /dev/ . > >>> : > >>> : OK great, this isn't critical either. I think all of the issues I > >>> : raised are agreed upon now! > >> > >> Wait a moment. Does this mean the devfs stuff to handle the access > >> rights (devfs.rules or manual chown/chmod by root) does not work > >> with the new usb stuff? If the answer is yes, I would see this as > >> some kind of nasty bug (I don't think this shall be a showstopper, > >> as long as this is fixed later). > > > > Yes, he said it will be fixed later. > > You are aware that I point out that this may or may not suggest that > HPS is circumventing the normal devfs infrastructure and that this may > or may not be a problem and should be reviewed by someone with > knowledge about the devfs infrastructure? > > And as he mentioned that in the context of the userland utilities, it > may be interesting if this means if an USB specific userland utility > will be responsible to change the ownership and file access or not. If > yes, what are the consequences from a security point of view and what > about POLA (devfs.rules, chown/chmod)? > > I want to see this new USB subsystem, but if the answer to the above > paragraph is yes, then this would be a showstopper for me (IMO the > replacement should work in this regard as before, I don't say it can > not be changed after enough people agree that the replacement was > successful). > > Bye, > Alexander. Hi Alexander, You have to ask Paul Henning Kamp about that. He does not like the idea about /dev/ being the inventory list. Besides, there are no more visible /dev/ devices. All devices are so-called cloneable and invisible, so you need a separate utility. The good news is that you can set the permissions on a USB subtree (a HUB and all subdevices) before devices are eventually plugged ! --HPS From hselasky at c2i.net Sat Aug 23 06:11:22 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Aug 23 06:11:28 2008 Subject: usb match() function In-Reply-To: <200808221948.m7MJmglt004097@brother.ludd.ltu.se> References: <200808221948.m7MJmglt004097@brother.ludd.ltu.se> Message-ID: <200808230813.05981.hselasky@c2i.net> On Friday 22 August 2008, Peter B wrote: > Within the usb drivers (/usr/src/sys/dev/usb/u*.c) there's an matching > routine where the 'uaa->iface' is supposed to be assigned before the > routine is called. > > However for a new device or class this doesn't seem to work. Instead 'uaa' > is set like for an generic device (two interfaces, no "default" in my > case). > > So how is one supposed to make the kernel fill in 'uaa->iface' ..? > > Code excerpt: > static int > *_match(device_t self) > { > struct usb_attach_arg *uaa = device_get_ivars(self); > usb_interface_descriptor_t *id; > > DPRINTFN(10,("*_match\n")); > if (uaa->iface == NULL) > return (UMATCH_NONE); It is usually like this the the probe function is called once with iface == NULL, to give the driver a chance to claim the whole device. The you have to set the config yourself. If this fails, the iface is set to the various interfaces to hook on interface specific drivers. BTW: This feature is going away. All probes will be interface specific and the config can only be set from userland in the future. --HPS From Alexander at Leidinger.net Sat Aug 23 07:39:57 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat Aug 23 07:40:04 2008 Subject: usb4bsd patch review In-Reply-To: <200808230804.03275.hselasky@c2i.net> References: <48AD9B9A.8070403@FreeBSD.org> <48AE7FFA.7070502@FreeBSD.org> <20080822113738.75855zbz0hkckp8o@webmail.leidinger.net> <200808230804.03275.hselasky@c2i.net> Message-ID: <20080823093940.179e54ec@deskjail> Quoting Hans Petter Selasky (Sat, 23 Aug 2008 08:03:55 +0200): > On Friday 22 August 2008, Alexander Leidinger wrote: > > Quoting "Kris Kennaway" (from Fri, 22 Aug 2008 > > > > 10:59:38 +0200): > > > Alexander Leidinger wrote: > > >> Quoting "M. Warner Losh" (from Thu, 21 Aug 2008 > > >> > > >> 11:52:10 -0600 (MDT)): > > >>> In message: <48ADA66A.3040906@FreeBSD.org> > > >>> > > >>> Kris Kennaway writes: > > >>> : Hans Petter Selasky wrote: > > >>> : > The USB stack will work fine without "usbconfig". Its purpose > > >>> > > >>> is : > mostly to > > >>> > > >>> : > view the currently attached USB devices, where the USB devices > > >>> : > are located > > >>> : > and to select a non-default USB configuration. One thing which > > >>> : > might be missed is to change owner and permission of a USB device, > > >>> > > >>> which means you > > >>> > > >>> : > must be either UID=root or GID=OPERATOR to be able to use USB > > >>> : > devices that > > >>> : > create devices under /dev/ . > > >>> : > > >>> : OK great, this isn't critical either. I think all of the issues I > > >>> : raised are agreed upon now! > > >> > > >> Wait a moment. Does this mean the devfs stuff to handle the access > > >> rights (devfs.rules or manual chown/chmod by root) does not work > > >> with the new usb stuff? If the answer is yes, I would see this as > > >> some kind of nasty bug (I don't think this shall be a showstopper, > > >> as long as this is fixed later). > > > > > > Yes, he said it will be fixed later. > > > > You are aware that I point out that this may or may not suggest that > > HPS is circumventing the normal devfs infrastructure and that this may > > or may not be a problem and should be reviewed by someone with > > knowledge about the devfs infrastructure? > > > > And as he mentioned that in the context of the userland utilities, it > > may be interesting if this means if an USB specific userland utility > > will be responsible to change the ownership and file access or not. If > > yes, what are the consequences from a security point of view and what > > about POLA (devfs.rules, chown/chmod)? > > > > I want to see this new USB subsystem, but if the answer to the above > > paragraph is yes, then this would be a showstopper for me (IMO the > > replacement should work in this regard as before, I don't say it can > > not be changed after enough people agree that the replacement was > > successful). > > > > Bye, > > Alexander. > > Hi Alexander, > > You have to ask Paul Henning Kamp about that. He does not like the idea > about /dev/ being the inventory list. We already have a lot of cloning devices, so it's not about showing a device node in /dev or not, I'm talking about chmod/chflags/devfs.rules. > Besides, there are no more visible /dev/ devices. All devices are so-called > cloneable and invisible, so you need a separate utility. The good news is No, devfs.rules is handling this case already, no need for another utility: ---snip--- NAME devfs.rules -- devfs configuration information DESCRIPTION The devfs.rules file provides an easy way to create and apply devfs(8) rules, even for devices that are not available at boot. For devices available at boot, see devfs.conf(5). ---snip--- With your new utility you are changing the security policy, and this without discussing this in public (who is able to change the permissions, are changes permanent and survive a reboot, ...). With devfs.rules we already have a tested and reviewed feature where root can configure access. > that you can set the permissions on a USB subtree (a HUB and all subdevices) > before devices are eventually plugged ! I don't know of a scenario where this is useful, but I'm not surprised if someone has an use for this. And I think this feature can be available while respecting the current semantics of devfs and devfs.rules (e.g. if your feature is used, give priority to it, else respect devfs.rules). Bye, Alexander. -- Ferengi Rule of Acquisition #7: Keep your ears open. -- ST:DS9, "In the Hands of the Prophets" http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From hselasky at c2i.net Sat Aug 23 08:33:12 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Aug 23 08:33:19 2008 Subject: usb4bsd patch review In-Reply-To: <20080823093940.179e54ec@deskjail> References: <48AD9B9A.8070403@FreeBSD.org> <200808230804.03275.hselasky@c2i.net> <20080823093940.179e54ec@deskjail> Message-ID: <200808231034.54484.hselasky@c2i.net> Hi, I've CC'ed PHK in case he has any comments on this issue. I think the solution is that you use "devd.conf" instead of "devfs.conf" to do this in the future. The problem about "devfs.rules" with regard to USB is that you don't know what you are giving permissions to. A rule that gives permission to "/dev/ulpt0" will give permissions to the first printer you plug into the USB system. That is not neccessarily what the user wants. --HPS On Saturday 23 August 2008, Alexander Leidinger wrote: > Quoting Hans Petter Selasky (Sat, 23 Aug 2008 08:03:55 +0200): > > On Friday 22 August 2008, Alexander Leidinger wrote: > > > Quoting "Kris Kennaway" (from Fri, 22 Aug 2008 > > > > > > 10:59:38 +0200): > > > > Alexander Leidinger wrote: > > > >> Quoting "M. Warner Losh" (from Thu, 21 Aug 2008 > > > >> > > > >> 11:52:10 -0600 (MDT)): > > > >>> In message: <48ADA66A.3040906@FreeBSD.org> > > > >>> > > > >>> Kris Kennaway writes: > > > >>> : Hans Petter Selasky wrote: > > > >>> : > The USB stack will work fine without "usbconfig". Its purpose > > > >>> > > > >>> is : > mostly to > > > >>> > > > >>> : > view the currently attached USB devices, where the USB devices > > > >>> : > are located > > > >>> : > and to select a non-default USB configuration. One thing which > > > >>> : > might be missed is to change owner and permission of a USB > > > >>> : > device, > > > >>> > > > >>> which means you > > > >>> > > > >>> : > must be either UID=root or GID=OPERATOR to be able to use USB > > > >>> : > devices that > > > >>> : > create devices under /dev/ . > > > >>> : > > > >>> : OK great, this isn't critical either. I think all of the issues > > > >>> : I raised are agreed upon now! > > > >> > > > >> Wait a moment. Does this mean the devfs stuff to handle the access > > > >> rights (devfs.rules or manual chown/chmod by root) does not work > > > >> with the new usb stuff? If the answer is yes, I would see this as > > > >> some kind of nasty bug (I don't think this shall be a showstopper, > > > >> as long as this is fixed later). > > > > > > > > Yes, he said it will be fixed later. > > > > > > You are aware that I point out that this may or may not suggest that > > > HPS is circumventing the normal devfs infrastructure and that this may > > > or may not be a problem and should be reviewed by someone with > > > knowledge about the devfs infrastructure? > > > > > > And as he mentioned that in the context of the userland utilities, it > > > may be interesting if this means if an USB specific userland utility > > > will be responsible to change the ownership and file access or not. If > > > yes, what are the consequences from a security point of view and what > > > about POLA (devfs.rules, chown/chmod)? > > > > > > I want to see this new USB subsystem, but if the answer to the above > > > paragraph is yes, then this would be a showstopper for me (IMO the > > > replacement should work in this regard as before, I don't say it can > > > not be changed after enough people agree that the replacement was > > > successful). > > > > > > Bye, > > > Alexander. > > > > Hi Alexander, > > > > You have to ask Paul Henning Kamp about that. He does not like the idea > > about /dev/ being the inventory list. > > We already have a lot of cloning devices, so it's not about showing a > device node in /dev or not, I'm talking about chmod/chflags/devfs.rules. > > > Besides, there are no more visible /dev/ devices. All devices are > > so-called cloneable and invisible, so you need a separate utility. The > > good news is > > No, devfs.rules is handling this case already, no need for another > utility: > ---snip--- > NAME > devfs.rules -- devfs configuration information > > DESCRIPTION > The devfs.rules file provides an easy way to create and apply devfs(8) > rules, even for devices that are not available at boot. > > For devices available at boot, see devfs.conf(5). > ---snip--- > > With your new utility you are changing the security policy, and this > without discussing this in public (who is able to change the > permissions, are changes permanent and survive a reboot, ...). With > devfs.rules we already have a tested and reviewed feature where root > can configure access. > > > that you can set the permissions on a USB subtree (a HUB and all > > subdevices) before devices are eventually plugged ! > > I don't know of a scenario where this is useful, but I'm not surprised > if someone has an use for this. And I think this feature can be > available while respecting the current semantics of devfs and > devfs.rules (e.g. if your feature is used, give priority to it, else > respect devfs.rules). From volker at vwsoft.com Sat Aug 23 10:25:42 2008 From: volker at vwsoft.com (Volker) Date: Sat Aug 23 10:26:02 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <48ABB1FA.5070609@mawer.org> References: <20080819211814.6CD685B4D@mail.bitblocks.com> <20080819.160510.104119134.imp@bsdimp.com> <48AB566B.5010507@mawer.org> <20080819.180450.-867152686.imp@bsdimp.com> <48ABB1FA.5070609@mawer.org> Message-ID: <48AFE196.7050100@vwsoft.com> On 12/23/-58 20:59, Antony Mawer wrote: > M. Warner Losh wrote: >> In message: <48AB566B.5010507@mawer.org> >> Antony Mawer writes: >> : Warner Losh wrote: >> : > From: Bakul Shah >> : > Subject: Re: HEADSUP new usb code coming in. : > Date: Tue, 19 Aug >> 2008 14:18:13 -0700 >> : > : >> On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky >> wrote: >> : >>> New stuff (all of which I can remember right now): >> : >> ... >> : >> >> : >> Accidentally unplugging a mounted USB disk (without >> : >> unmounting it) resulted in a hang or a crash. Is this fixed? >> : > : > That's fixed in -current right now with the old stack. It >> isn't a usb >> : > issue at all, but a buffer cache issue. >> : : Is this change that is likely to be MFC'd in time for 7.1? And/or >> is : there a specific patch that can manually be applied to -STABLE to >> fix this? >> >> I should spend the time to dig into the changes in current. There >> turned out to be several little changes... And I need to verify all >> the edge cases were covered... > > I'd be happy to test patches if you do end up doing this.. it would be > really nice to have in 7.1, or at least available as a patchset if it > isn't suitable for MFC (eg. ABI changes)... > > --Antony Antony, I'm a bit behind with reading emails. Please forgive me if this has already been answered. Don't expect the new USB stack for 7.1-R. It's too short and the new USB stack will introduce an ABI breakage. For that, all drivers written for the old USB stack need to be rewritten and I guess, we need to take care about 3rd party developers and inform them in advance about that massive change. I would not wonder if this will never get MFC'd but I don't know actually. HTH Volker From volker at vwsoft.com Sat Aug 23 10:25:42 2008 From: volker at vwsoft.com (Volker) Date: Sat Aug 23 10:26:03 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <48ABB1FA.5070609@mawer.org> References: <20080819211814.6CD685B4D@mail.bitblocks.com> <20080819.160510.104119134.imp@bsdimp.com> <48AB566B.5010507@mawer.org> <20080819.180450.-867152686.imp@bsdimp.com> <48ABB1FA.5070609@mawer.org> Message-ID: <48AFE196.7050100@vwsoft.com> On 12/23/-58 20:59, Antony Mawer wrote: > M. Warner Losh wrote: >> In message: <48AB566B.5010507@mawer.org> >> Antony Mawer writes: >> : Warner Losh wrote: >> : > From: Bakul Shah >> : > Subject: Re: HEADSUP new usb code coming in. : > Date: Tue, 19 Aug >> 2008 14:18:13 -0700 >> : > : >> On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky >> wrote: >> : >>> New stuff (all of which I can remember right now): >> : >> ... >> : >> >> : >> Accidentally unplugging a mounted USB disk (without >> : >> unmounting it) resulted in a hang or a crash. Is this fixed? >> : > : > That's fixed in -current right now with the old stack. It >> isn't a usb >> : > issue at all, but a buffer cache issue. >> : : Is this change that is likely to be MFC'd in time for 7.1? And/or >> is : there a specific patch that can manually be applied to -STABLE to >> fix this? >> >> I should spend the time to dig into the changes in current. There >> turned out to be several little changes... And I need to verify all >> the edge cases were covered... > > I'd be happy to test patches if you do end up doing this.. it would be > really nice to have in 7.1, or at least available as a patchset if it > isn't suitable for MFC (eg. ABI changes)... > > --Antony Antony, I'm a bit behind with reading emails. Please forgive me if this has already been answered. Don't expect the new USB stack for 7.1-R. It's too short and the new USB stack will introduce an ABI breakage. For that, all drivers written for the old USB stack need to be rewritten and I guess, we need to take care about 3rd party developers and inform them in advance about that massive change. I would not wonder if this will never get MFC'd but I don't know actually. HTH Volker From imp at bsdimp.com Sat Aug 23 15:05:18 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Aug 23 15:05:25 2008 Subject: usb4bsd patch review In-Reply-To: <200808231034.54484.hselasky@c2i.net> References: <200808230804.03275.hselasky@c2i.net> <20080823093940.179e54ec@deskjail> <200808231034.54484.hselasky@c2i.net> Message-ID: <20080823.090205.-696512487.imp@bsdimp.com> In message: <200808231034.54484.hselasky@c2i.net> Hans Petter Selasky writes: : I think the solution is that you use "devd.conf" instead of "devfs.conf" to do : this in the future. No, I think it should be devfs.conf to control permissions, etc. : The problem about "devfs.rules" with regard to USB is that you don't know what : you are giving permissions to. A rule that gives permission to "/dev/ulpt0" : will give permissions to the first printer you plug into the USB system. That : is not neccessarily what the user wants. It is. Until we have better wiring of devices to drivers, it will have to do. Better to solve that problem more generically.. Warner : --HPS : : On Saturday 23 August 2008, Alexander Leidinger wrote: : > Quoting Hans Petter Selasky (Sat, 23 Aug 2008 08:03:55 : +0200): : > > On Friday 22 August 2008, Alexander Leidinger wrote: : > > > Quoting "Kris Kennaway" (from Fri, 22 Aug 2008 : > > > : > > > 10:59:38 +0200): : > > > > Alexander Leidinger wrote: : > > > >> Quoting "M. Warner Losh" (from Thu, 21 Aug 2008 : > > > >> : > > > >> 11:52:10 -0600 (MDT)): : > > > >>> In message: <48ADA66A.3040906@FreeBSD.org> : > > > >>> : > > > >>> Kris Kennaway writes: : > > > >>> : Hans Petter Selasky wrote: : > > > >>> : > The USB stack will work fine without "usbconfig". Its purpose : > > > >>> : > > > >>> is : > mostly to : > > > >>> : > > > >>> : > view the currently attached USB devices, where the USB devices : > > > >>> : > are located : > > > >>> : > and to select a non-default USB configuration. One thing which : > > > >>> : > might be missed is to change owner and permission of a USB : > > > >>> : > device, : > > > >>> : > > > >>> which means you : > > > >>> : > > > >>> : > must be either UID=root or GID=OPERATOR to be able to use USB : > > > >>> : > devices that : > > > >>> : > create devices under /dev/ . : > > > >>> : : > > > >>> : OK great, this isn't critical either. I think all of the issues : > > > >>> : I raised are agreed upon now! : > > > >> : > > > >> Wait a moment. Does this mean the devfs stuff to handle the access : > > > >> rights (devfs.rules or manual chown/chmod by root) does not work : > > > >> with the new usb stuff? If the answer is yes, I would see this as : > > > >> some kind of nasty bug (I don't think this shall be a showstopper, : > > > >> as long as this is fixed later). : > > > > : > > > > Yes, he said it will be fixed later. : > > > : > > > You are aware that I point out that this may or may not suggest that : > > > HPS is circumventing the normal devfs infrastructure and that this may : > > > or may not be a problem and should be reviewed by someone with : > > > knowledge about the devfs infrastructure? : > > > : > > > And as he mentioned that in the context of the userland utilities, it : > > > may be interesting if this means if an USB specific userland utility : > > > will be responsible to change the ownership and file access or not. If : > > > yes, what are the consequences from a security point of view and what : > > > about POLA (devfs.rules, chown/chmod)? : > > > : > > > I want to see this new USB subsystem, but if the answer to the above : > > > paragraph is yes, then this would be a showstopper for me (IMO the : > > > replacement should work in this regard as before, I don't say it can : > > > not be changed after enough people agree that the replacement was : > > > successful). : > > > : > > > Bye, : > > > Alexander. : > > : > > Hi Alexander, : > > : > > You have to ask Paul Henning Kamp about that. He does not like the idea : > > about /dev/ being the inventory list. : > : > We already have a lot of cloning devices, so it's not about showing a : > device node in /dev or not, I'm talking about chmod/chflags/devfs.rules. : > : > > Besides, there are no more visible /dev/ devices. All devices are : > > so-called cloneable and invisible, so you need a separate utility. The : > > good news is : > : > No, devfs.rules is handling this case already, no need for another : > utility: : > ---snip--- : > NAME : > devfs.rules -- devfs configuration information : > : > DESCRIPTION : > The devfs.rules file provides an easy way to create and apply devfs(8) : > rules, even for devices that are not available at boot. : > : > For devices available at boot, see devfs.conf(5). : > ---snip--- : > : > With your new utility you are changing the security policy, and this : > without discussing this in public (who is able to change the : > permissions, are changes permanent and survive a reboot, ...). With : > devfs.rules we already have a tested and reviewed feature where root : > can configure access. : > : > > that you can set the permissions on a USB subtree (a HUB and all : > > subdevices) before devices are eventually plugged ! : > : > I don't know of a scenario where this is useful, but I'm not surprised : > if someone has an use for this. And I think this feature can be : > available while respecting the current semantics of devfs and : > devfs.rules (e.g. if your feature is used, give priority to it, else : > respect devfs.rules). : _______________________________________________ : 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" : : From phk at phk.freebsd.dk Sat Aug 23 15:54:39 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat Aug 23 15:54:45 2008 Subject: usb4bsd patch review In-Reply-To: Your message of "Sat, 23 Aug 2008 10:34:53 +0200." <200808231034.54484.hselasky@c2i.net> Message-ID: <10490.1219505244@critter.freebsd.dk> In message <200808231034.54484.hselasky@c2i.net>, Hans Petter Selasky writes: >The problem about "devfs.rules" with regard to USB is that you don't know what >you are giving permissions to. A rule that gives permission to "/dev/ulpt0" >will give permissions to the first printer you plug into the USB system. That >is not neccessarily what the user wants. I think this might be a good time to consider the devd/devfs distribution of work. The reason devfs(8) works like "firewall rules" is that we did not want some mandatory daemon to set the modes, in particular on embedded systems. The alternative solution is to always create device nodes "root:wheel r--" and let the daemon set the mode as desired. This model has the advantage of not needing the uid, gid and mode arguments to make_dev, something that has always been acknowleded as a kludge. The down side is that devd(8) becomes a mandatory daemon on most systems. Given that devfs(8) has not exactly been a stellar success and that it often and repeatedly bites people with it slightly pedantic semantics, transitioning in that direction might be a good thing. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From imp at bsdimp.com Sat Aug 23 16:01:53 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Aug 23 16:02:00 2008 Subject: usb4bsd patch review In-Reply-To: <10490.1219505244@critter.freebsd.dk> References: <200808231034.54484.hselasky@c2i.net> <10490.1219505244@critter.freebsd.dk> Message-ID: <20080823.100155.1310242209.imp@bsdimp.com> In message: <10490.1219505244@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <200808231034.54484.hselasky@c2i.net>, Hans Petter Selasky writes: : : : >The problem about "devfs.rules" with regard to USB is that you don't know what : >you are giving permissions to. A rule that gives permission to "/dev/ulpt0" : >will give permissions to the first printer you plug into the USB system. That : >is not neccessarily what the user wants. : : I think this might be a good time to consider the devd/devfs : distribution of work. : : The reason devfs(8) works like "firewall rules" is that we did not want : some mandatory daemon to set the modes, in particular on embedded : systems. : : The alternative solution is to always create device nodes "root:wheel r--" : and let the daemon set the mode as desired. : : This model has the advantage of not needing the uid, gid and mode arguments : to make_dev, something that has always been acknowleded as a kludge. : : The down side is that devd(8) becomes a mandatory daemon on most systems. : : Given that devfs(8) has not exactly been a stellar success and that it : often and repeatedly bites people with it slightly pedantic semantics, : transitioning in that direction might be a good thing. While this may be a good idea, I'm hesitant about races that it may introduce. This is the classic point of attack: do something between steps of a formerly atomic operation that was made non-atomic. I can't think of anything off the top of my head, but I'm still concerned. Warner From Alexander at Leidinger.net Sat Aug 23 16:45:46 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat Aug 23 16:45:54 2008 Subject: usb4bsd patch review In-Reply-To: <10490.1219505244@critter.freebsd.dk> References: <200808231034.54484.hselasky@c2i.net> <10490.1219505244@critter.freebsd.dk> Message-ID: <20080823184534.575803d0@deskjail> Quoting "Poul-Henning Kamp" (Sat, 23 Aug 2008 15:27:24 +0000): > In message <200808231034.54484.hselasky@c2i.net>, Hans Petter Selasky writes: > > > >The problem about "devfs.rules" with regard to USB is that you don't know what > >you are giving permissions to. A rule that gives permission to "/dev/ulpt0" > >will give permissions to the first printer you plug into the USB system. That > >is not neccessarily what the user wants. > > I think this might be a good time to consider the devd/devfs > distribution of work. > > The reason devfs(8) works like "firewall rules" is that we did not want > some mandatory daemon to set the modes, in particular on embedded > systems. > > The alternative solution is to always create device nodes "root:wheel r--" > and let the daemon set the mode as desired. > > This model has the advantage of not needing the uid, gid and mode arguments > to make_dev, something that has always been acknowleded as a kludge. > > The down side is that devd(8) becomes a mandatory daemon on most systems. A downside which belongs into its own discussion, an not into the already huge back and forth for the new USB subsystem. > Given that devfs(8) has not exactly been a stellar success and that it > often and repeatedly bites people with it slightly pedantic semantics, > transitioning in that direction might be a good thing. Unpredictable behavior (except you know by heard which entry is behaving how... something someone should not need to know) instead of doing it right by doing all at once? I don't think this is a good idea, and it seems Warner thinks the same (see his answer to the mail you answered to). Bye, Alexander. -- Ferengi Rule of Acquisition #177: Know your enemies... but do business with them always. -- ST: Legends of the Ferengi http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From phk at phk.freebsd.dk Sat Aug 23 17:15:43 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat Aug 23 17:15:49 2008 Subject: usb4bsd patch review In-Reply-To: Your message of "Sat, 23 Aug 2008 10:01:55 CST." <20080823.100155.1310242209.imp@bsdimp.com> Message-ID: <10826.1219511738@critter.freebsd.dk> In message <20080823.100155.1310242209.imp@bsdimp.com>, "M. Warner Losh" writes : >While this may be a good idea, I'm hesitant about races that it may >introduce. This is the classic point of attack: do something between >steps of a formerly atomic operation that was made non-atomic. I >can't think of anything off the top of my head, but I'm still >concerned. We have ways of closing the race if need be, but they're all slightly kludgy, but I am not overly concerned about those races as long as the default is to not give access. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From dfilter at FreeBSD.ORG Sat Aug 23 17:40:03 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Sat Aug 23 17:40:20 2008 Subject: kern/123224: commit references a PR Message-ID: <200808231740.m7NHe3Fm038641@freefall.freebsd.org> The following reply was made to PR kern/123224; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/123224: commit references a PR Date: Sat, 23 Aug 2008 17:33:13 +0000 (UTC) kaiw 2008-08-23 17:32:43 UTC FreeBSD src repository Modified files: (Branch: RELENG_7) sys/dev/usb ums.c Log: SVN rev 182072 on 2008-08-23 17:32:43Z by kaiw MFC r181839: Re-add Microsoft Intellimouse 2.0 TWHEEL quirk. Tested by: Merritt Draney, Brian Cox PR: kern/123224 PR: kern/123510 Revision Changes Path 1.96.2.4 +3 -0 src/sys/dev/usb/ums.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From dfilter at FreeBSD.ORG Sat Aug 23 17:40:06 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Sat Aug 23 17:40:20 2008 Subject: kern/123510: commit references a PR Message-ID: <200808231740.m7NHe5gZ038672@freefall.freebsd.org> The following reply was made to PR kern/123510; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/123510: commit references a PR Date: Sat, 23 Aug 2008 17:33:13 +0000 (UTC) kaiw 2008-08-23 17:32:43 UTC FreeBSD src repository Modified files: (Branch: RELENG_7) sys/dev/usb ums.c Log: SVN rev 182072 on 2008-08-23 17:32:43Z by kaiw MFC r181839: Re-add Microsoft Intellimouse 2.0 TWHEEL quirk. Tested by: Merritt Draney, Brian Cox PR: kern/123224 PR: kern/123510 Revision Changes Path 1.96.2.4 +3 -0 src/sys/dev/usb/ums.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From dfilter at FreeBSD.ORG Sat Aug 23 17:40:08 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Sat Aug 23 17:40:20 2008 Subject: usb/125941: commit references a PR Message-ID: <200808231740.m7NHe8hU038722@freefall.freebsd.org> The following reply was made to PR usb/125941; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: usb/125941: commit references a PR Date: Sat, 23 Aug 2008 17:38:46 +0000 (UTC) kaiw 2008-08-23 17:38:24 UTC FreeBSD src repository Modified files: (Branch: RELENG_7) sys/dev/usb hid.c Log: SVN rev 182074 on 2008-08-23 17:38:24Z by kaiw MFC r181841: In the hid parser, if a INPUT/OUTPUT/FEATURE item is skipped, its corresponding USAGE should be skipped as well. Tested by: Grzegorz Blach PR: usb/125941 Revision Changes Path 1.29.2.1 +12 -3 src/sys/dev/usb/hid.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From kaiw at FreeBSD.org Sat Aug 23 18:18:35 2008 From: kaiw at FreeBSD.org (kaiw@FreeBSD.org) Date: Sat Aug 23 18:18:42 2008 Subject: usb/125941: [ums] not working wheel on my microsoft notebook optical mouse 3000 Message-ID: <200808231818.m7NIIYFl041480@freefall.freebsd.org> Synopsis: [ums] not working wheel on my microsoft notebook optical mouse 3000 State-Changed-From-To: open->closed State-Changed-By: kaiw State-Changed-When: Sat Aug 23 18:17:27 UTC 2008 State-Changed-Why: Patch committed. http://www.freebsd.org/cgi/query-pr.cgi?pr=125941 From kaiw at FreeBSD.org Sat Aug 23 18:51:22 2008 From: kaiw at FreeBSD.org (kaiw@FreeBSD.org) Date: Sat Aug 23 18:51:43 2008 Subject: kern/123224: [ums] Scroll wheel breakage w/ USB MS Wireless Intellimouse Explorer 2.0 Message-ID: <200808231851.m7NIpLD7044476@freefall.freebsd.org> Synopsis: [ums] Scroll wheel breakage w/ USB MS Wireless Intellimouse Explorer 2.0 State-Changed-From-To: open->closed State-Changed-By: kaiw State-Changed-When: Sat Aug 23 18:50:55 UTC 2008 State-Changed-Why: Patched. http://www.freebsd.org/cgi/query-pr.cgi?pr=123224 From kaiw at FreeBSD.org Sat Aug 23 18:51:51 2008 From: kaiw at FreeBSD.org (kaiw@FreeBSD.org) Date: Sat Aug 23 18:51:59 2008 Subject: kern/123510: [ums] Mouse Wheel Fails to Work [regression] Message-ID: <200808231851.m7NIpoNR044523@freefall.freebsd.org> Synopsis: [ums] Mouse Wheel Fails to Work [regression] State-Changed-From-To: open->closed State-Changed-By: kaiw State-Changed-When: Sat Aug 23 18:51:35 UTC 2008 State-Changed-Why: Patched. http://www.freebsd.org/cgi/query-pr.cgi?pr=123510 From asim at nm.ru Sat Aug 23 21:26:29 2008 From: asim at nm.ru (=?koi8-r?B?7cHLwdLFzsvP1yDhzMXL08HOxNIg88XNz9fJ3iA=?=) Date: Sat Aug 23 21:26:38 2008 Subject: Microsoft Wireless Optical Desktop 3000 doesn't work correctly Message-ID: <1219526002.17589.denwebmail-344@makarenkov> Hi, Andrew! Recently. I had a similar problem with Microsoft Wireless MultiMedia Keyboard 1.1 and FreeBSD 7.0 i386 Below the letter my ums.c that working correctly with this hardware. My modifications of ums.c was inspired by http://accima.com/members/dhesser/fbsd_mouse_stuff/ The most significant modification in this source file is: else if ( id->bInterfaceClass == UICLASS_HID && uaa->product == 0x009d && uaa->vendor == 0x045e && uaa->ifaceno == 1 // iface0 for keyboard, iface1 for mice ){ id->bInterfaceSubClass = UISUBCLASS_BOOT; id->bInterfaceProtocol = UIPROTO_MOUSE; printf("\nMicosoft Wireles Desktop Mouse\n"); ret = UMATCH_IFACECLASS; } Please, keep in mind, that I wrote product and vendor code especially for my hardware. You may have to use another values. Have a good time, Alexander Makarenkov /*- * Copyright (c) 1998 The NetBSD Foundation, Inc. * All rights reserved. * * This code is derived from software contributed to The NetBSD Foundation * by Lennart Augustsson (lennart@augustsson.net) at * Carlstedt Research & Technology. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the NetBSD * Foundation, Inc. and its contributors. * 4. Neither the name of The NetBSD Foundation nor the names of its * contributors may be used to endorse or promote products derived * from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGE. */ #include __FBSDID("$FreeBSD: src/sys/dev/usb/ums.c,v 1.96.2.3 2008/06/12 16:45:46 kaiw Exp $"); /* * HID spec: http://www.usb.org/developers/devclass_docs/HID1_11.pdf */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include "usbdevs.h" #include #include #include #ifdef USB_DEBUG #define DPRINTF(x) if (umsdebug) printf x #define DPRINTFN(n,x) if (umsdebug>(n)) printf x int umsdebug = 0; SYSCTL_NODE(_hw_usb, OID_AUTO, ums, CTLFLAG_RW, 0, "USB ums"); SYSCTL_INT(_hw_usb_ums, OID_AUTO, debug, CTLFLAG_RW, &umsdebug, 0, "ums debug level"); #else #define DPRINTF(x) #define DPRINTFN(n,x) #endif #define UMSUNIT(s) (minor(s)&0x1f) #define MS_TO_TICKS(ms) ((ms) * hz / 1000) #define QUEUE_BUFSIZE 400 /* MUST be divisible by 5 _and_ 8 */ struct ums_softc { device_t sc_dev; /* base device */ usbd_interface_handle sc_iface; /* interface */ usbd_pipe_handle sc_intrpipe; /* interrupt pipe */ int sc_ep_addr; u_char *sc_ibuf; u_int8_t sc_iid; int sc_isize; struct hid_location sc_loc_x, sc_loc_y, sc_loc_z, sc_loc_t, sc_loc_w; struct hid_location *sc_loc_btn; struct callout callout_handle; /* for spurious button ups */ int sc_enabled; int sc_disconnected; /* device is gone */ int flags; /* device configuration */ #define UMS_Z 0x01 /* z direction available */ #define UMS_SPUR_BUT_UP 0x02 /* spurious button up events */ #define UMS_T 0x04 /* aa direction available (tilt) */ #define UMS_REVZ 0x08 /* Z-axis is reversed */ int nbuttons; #define MAX_BUTTONS 31 /* chosen because sc_buttons is int */ u_char qbuf[QUEUE_BUFSIZE]; /* must be divisable by 3&4 */ u_char dummy[100]; /* XXX just for safety and for now */ int qcount, qhead, qtail; mousehw_t hw; mousemode_t mode; mousestatus_t status; int state; # define UMS_ASLEEP 0x01 /* readFromDevice is waiting */ # define UMS_SELECT 0x02 /* select is waiting */ struct selinfo rsel; /* process waiting in select */ struct cdev *dev; /* specfs */ }; #define MOUSE_FLAGS_MASK (HIO_CONST|HIO_RELATIVE) #define MOUSE_FLAGS (HIO_RELATIVE) static void ums_intr(usbd_xfer_handle xfer, usbd_private_handle priv, usbd_status status); static void ums_add_to_queue(struct ums_softc *sc, int dx, int dy, int dz, int dt, int buttons); static void ums_add_to_queue_timeout(void *priv); static int ums_enable(void *); static void ums_disable(void *); static d_open_t ums_open; static d_close_t ums_close; static d_read_t ums_read; static d_ioctl_t ums_ioctl; static d_poll_t ums_poll; static struct cdevsw ums_cdevsw = { .d_version = D_VERSION, .d_flags = D_NEEDGIANT, .d_open = ums_open, .d_close = ums_close, .d_read = ums_read, .d_ioctl = ums_ioctl, .d_poll = ums_poll, .d_name = "ums", }; static device_probe_t ums_match; static device_attach_t ums_attach; static device_detach_t ums_detach; static device_method_t ums_methods[] = { /* Device interface */ DEVMETHOD(device_probe, ums_match), DEVMETHOD(device_attach, ums_attach), DEVMETHOD(device_detach, ums_detach), { 0, 0 } }; static driver_t ums_driver = { "ums", ums_methods, sizeof(struct ums_softc) }; static devclass_t ums_devclass; static int ums_match(device_t self) { struct usb_attach_arg *uaa = device_get_ivars(self); usb_interface_descriptor_t *id; int size, ret; void *desc; usbd_status err; if (!uaa->iface) return (UMATCH_NONE); id = usbd_get_interface_descriptor(uaa->iface); if (!id || id->bInterfaceClass != UICLASS_HID) { //printf("\nNot a HID\n"); return (UMATCH_NONE); } err = usbd_read_report_desc(uaa->iface, &desc, &size, M_TEMP); if (err){ //printf("\nERR\n"); return (UMATCH_NONE); } //printf("\nOK1\n"); if (hid_is_collection(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_MOUSE))){ //printf("\nOK2\n"); ret = UMATCH_IFACECLASS; } else if ( id->bInterfaceClass == UICLASS_HID && id->bInterfaceSubClass == UISUBCLASS_BOOT && id->bInterfaceProtocol == UIPROTO_MOUSE ){ //printf("\nOK3\n"); ret = UMATCH_IFACECLASS; } else if ( id->bInterfaceClass == UICLASS_HID && uaa->product == 0x009d && uaa->vendor == 0x045e && uaa->ifaceno == 1 ){ id->bInterfaceSubClass = UISUBCLASS_BOOT; id->bInterfaceProtocol = UIPROTO_MOUSE; printf("\nMicosoft Wireles Desktop Mouse\n"); ret = UMATCH_IFACECLASS; } else { // printf("\nOK4\n"); ret = UMATCH_NONE; } free(desc, M_TEMP); return (ret); } static int ums_attach(device_t self) { struct ums_softc *sc = device_get_softc(self); struct usb_attach_arg *uaa = device_get_ivars(self); usbd_interface_handle iface = uaa->iface; usb_interface_descriptor_t *id; usb_endpoint_descriptor_t *ed; int size; void *desc; usbd_status err; u_int32_t flags; int i, wheel; struct hid_location loc_btn; sc->sc_disconnected = 1; sc->sc_iface = iface; id = usbd_get_interface_descriptor(iface); sc->sc_dev = self; ed = usbd_interface2endpoint_descriptor(iface, 0); if (!ed) { printf("%s: could not read endpoint descriptor\n", device_get_nameunit(sc->sc_dev)); return ENXIO; } DPRINTFN(10,("ums_attach: bLength=%d bDescriptorType=%d " "bEndpointAddress=%d-%s bmAttributes=%d wMaxPacketSize=%d" " bInterval=%d\n", ed->bLength, ed->bDescriptorType, UE_GET_ADDR(ed->bEndpointAddress), UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_IN ? "in":"out", UE_GET_XFERTYPE(ed->bmAttributes), UGETW(ed->wMaxPacketSize), ed->bInterval)); if (UE_GET_DIR(ed->bEndpointAddress) != UE_DIR_IN || UE_GET_XFERTYPE(ed->bmAttributes) != UE_INTERRUPT) { printf("%s: unexpected endpoint\n", device_get_nameunit(sc->sc_dev)); return ENXIO; } err = usbd_read_report_desc(uaa->iface, &desc, &size, M_TEMP); if (err) return ENXIO; if (!hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_X), hid_input, &sc->sc_loc_x, &flags)) { printf("%s: mouse has no X report\n", device_get_nameunit(sc->sc_dev)); return ENXIO; } if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { printf("%s: X report 0x%04x not supported\n", device_get_nameunit(sc->sc_dev), flags); return ENXIO; } if (!hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_Y), hid_input, &sc->sc_loc_y, &flags)) { printf("%s: mouse has no Y report\n", device_get_nameunit(sc->sc_dev)); return ENXIO; } if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { printf("%s: Y report 0x%04x not supported\n", device_get_nameunit(sc->sc_dev), flags); return ENXIO; } /* Try the wheel first as the Z activator since it's tradition. */ wheel = hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_WHEEL), hid_input, &sc->sc_loc_z, &flags); if (wheel) { if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { printf("\n%s: Wheel report 0x%04x not supported\n", device_get_nameunit(sc->sc_dev), flags); sc->sc_loc_z.size = 0; /* Bad Z coord, ignore it */ } else { sc->flags |= UMS_Z; if (usbd_get_quirks(uaa->device)->uq_flags & UQ_MS_REVZ) { /* Some wheels need the Z axis reversed. */ sc->flags |= UMS_REVZ; } } /* * We might have both a wheel and Z direction, if so put * put the Z on the W coordinate. */ if (hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_Z), hid_input, &sc->sc_loc_w, &flags)) { if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { printf("\n%s: Z report 0x%04x not supported\n", device_get_nameunit(sc->sc_dev), flags); sc->sc_loc_w.size = 0; /* Bad Z, ignore */ } } } else if (hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_Z), hid_input, &sc->sc_loc_z, &flags)) { if ((flags & MOUSE_FLAGS_MASK) != MOUSE_FLAGS) { printf("\n%s: Z report 0x%04x not supported\n", device_get_nameunit(sc->sc_dev), flags); sc->sc_loc_z.size = 0; /* Bad Z coord, ignore it */ } else { sc->flags |= UMS_Z; } } /* * The Microsoft Wireless Intellimouse 2.0 reports it's wheel * using 0x0048 (i've called it HUG_TWHEEL) and seems to expect * you to know that the byte after the wheel is the tilt axis. * There are no other HID axis descriptors other than X,Y and * TWHEEL */ if (hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_TWHEEL), hid_input, &sc->sc_loc_t, &flags)) { sc->sc_loc_t.pos = sc->sc_loc_t.pos + 8; sc->flags |= UMS_T; } /* figure out the number of buttons */ for (i = 1; i <= MAX_BUTTONS; i++) if (!hid_locate(desc, size, HID_USAGE2(HUP_BUTTON, i), hid_input, &loc_btn, 0)) break; sc->nbuttons = i - 1; sc->sc_loc_btn = malloc(sizeof(struct hid_location)*sc->nbuttons, M_USBDEV, M_NOWAIT); if (!sc->sc_loc_btn) { printf("%s: no memory\n", device_get_nameunit(sc->sc_dev)); return ENXIO; } printf("%s: %d buttons%s%s.\n", device_get_nameunit(sc->sc_dev), sc->nbuttons, sc->flags & UMS_Z? " and Z dir" : "", sc->flags & UMS_T?" and a TILT dir": ""); for (i = 1; i <= sc->nbuttons; i++) hid_locate(desc, size, HID_USAGE2(HUP_BUTTON, i), hid_input, &sc->sc_loc_btn[i-1], 0); sc->sc_isize = hid_report_size(desc, size, hid_input, &sc->sc_iid); sc->sc_ibuf = malloc(sc->sc_isize, M_USB, M_NOWAIT); if (!sc->sc_ibuf) { printf("%s: no memory\n", device_get_nameunit(sc->sc_dev)); free(sc->sc_loc_btn, M_USB); return ENXIO; } /* * The Microsoft Wireless Notebook Optical Mouse seems to be in worse * shape than the Wireless Intellimouse 2.0, as its X, Y, wheel, and * all of its other button positions are all off. It also reports that * it has two addional buttons and a tilt wheel. */ if (usbd_get_quirks(uaa->device)->uq_flags & UQ_MS_BAD_CLASS) { sc->flags = UMS_Z; sc->flags |= UMS_SPUR_BUT_UP; sc->nbuttons = 3; sc->sc_isize = 5; sc->sc_iid = 0; /* 1st byte of descriptor report contains garbage */ sc->sc_loc_x.pos = 16; sc->sc_loc_y.pos = 24; sc->sc_loc_z.pos = 32; sc->sc_loc_btn[0].pos = 8; sc->sc_loc_btn[1].pos = 9; sc->sc_loc_btn[2].pos = 10; } /* * The Microsoft Wireless Notebook Optical Mouse 3000 Model 1049 has * five Report IDs: 19 23 24 17 18 (in the order they appear in report * descriptor), it seems that report id 17 contains the necessary * mouse information(3-buttons,X,Y,wheel) so we specify it manually. */ if ((uaa->vendor == USB_VENDOR_MICROSOFT && uaa->product == USB_PRODUCT_MICROSOFT_WLNOTEBOOK3) ||( uaa->product == 0x009d && uaa->vendor == 0x045e && uaa->ifaceno == 1 ) ){ sc->flags = UMS_Z; sc->nbuttons = 3; sc->sc_isize = 5; sc->sc_iid = 17; sc->sc_loc_x.pos = 8; sc->sc_loc_y.pos = 16; sc->sc_loc_z.pos = 24; sc->sc_loc_btn[0].pos = 0; sc->sc_loc_btn[1].pos = 1; sc->sc_loc_btn[2].pos = 2; } sc->sc_ep_addr = ed->bEndpointAddress; sc->sc_disconnected = 0; free(desc, M_TEMP); #ifdef USB_DEBUG DPRINTF(("ums_attach: sc=%p\n", sc)); DPRINTF(("ums_attach: X\t%d/%d\n", sc->sc_loc_x.pos, sc->sc_loc_x.size)); DPRINTF(("ums_attach: Y\t%d/%d\n", sc->sc_loc_y.pos, sc->sc_loc_y.size)); if (sc->flags & UMS_Z) DPRINTF(("ums_attach: Z\t%d/%d\n", sc->sc_loc_z.pos, sc->sc_loc_z.size)); for (i = 1; i <= sc->nbuttons; i++) { DPRINTF(("ums_attach: B%d\t%d/%d\n", i, sc->sc_loc_btn[i-1].pos,sc->sc_loc_btn[i-1].size)); } DPRINTF(("ums_attach: size=%d, id=%d\n", sc->sc_isize, sc->sc_iid)); #endif if (sc->nbuttons > MOUSE_MSC_MAXBUTTON) sc->hw.buttons = MOUSE_MSC_MAXBUTTON; else sc->hw.buttons = sc->nbuttons; sc->hw.iftype = MOUSE_IF_USB; sc->hw.type = MOUSE_MOUSE; sc->hw.model = MOUSE_MODEL_GENERIC; sc->hw.hwid = 0; sc->mode.protocol = MOUSE_PROTO_MSC; sc->mode.rate = -1; sc->mode.resolution = MOUSE_RES_UNKNOWN; sc->mode.accelfactor = 0; sc->mode.level = 0; sc->mode.packetsize = MOUSE_MSC_PACKETSIZE; sc->mode.syncmask[0] = MOUSE_MSC_SYNCMASK; sc->mode.syncmask[1] = MOUSE_MSC_SYNC; sc->status.flags = 0; sc->status.button = sc->status.obutton = 0; sc->status.dx = sc->status.dy = sc->status.dz = 0; sc->dev = make_dev(&ums_cdevsw, device_get_unit(self), UID_ROOT, GID_OPERATOR, 0644, "ums%d", device_get_unit(self)); callout_init(&sc->callout_handle, 0); if (usbd_get_quirks(uaa->device)->uq_flags & UQ_SPUR_BUT_UP) { DPRINTF(("%s: Spurious button up events\n", device_get_nameunit(sc->sc_dev))); sc->flags |= UMS_SPUR_BUT_UP; } return 0; } static int ums_detach(device_t self) { struct ums_softc *sc = device_get_softc(self); if (sc->sc_enabled) ums_disable(sc); DPRINTF(("%s: disconnected\n", device_get_nameunit(self))); free(sc->sc_loc_btn, M_USB); free(sc->sc_ibuf, M_USB); /* someone waiting for data */ /* * XXX If we wakeup the process here, the device will be gone by * the time the process gets a chance to notice. *_close and friends * should be fixed to handle this case. * Or we should do a delayed detach for this. * Does this delay now force tsleep to exit with an error? */ if (sc->state & UMS_ASLEEP) { sc->state &= ~UMS_ASLEEP; wakeup(sc); } if (sc->state & UMS_SELECT) { sc->state &= ~UMS_SELECT; selwakeuppri(&sc->rsel, PZERO); } destroy_dev(sc->dev); return 0; } void ums_intr(usbd_xfer_handle xfer, usbd_private_handle addr, usbd_status status) { struct ums_softc *sc = addr; u_char *ibuf; int dx, dy, dz, dw, dt; int buttons = 0; int i; #define UMS_BUT(i) ((i) < 3 ? (((i) + 2) % 3) : (i)) DPRINTFN(5, ("ums_intr: sc=%p status=%d\n", sc, status)); DPRINTFN(5, ("ums_intr: data =")); for (i = 0; i < sc->sc_isize; i++) DPRINTFN(5, (" %02x", sc->sc_ibuf[i])); DPRINTFN(5, ("\n")); if (status == USBD_CANCELLED) return; if (status != USBD_NORMAL_COMPLETION) { DPRINTF(("ums_intr: status=%d\n", status)); if (status == USBD_STALLED) usbd_clear_endpoint_stall_async(sc->sc_intrpipe); if(status != USBD_IOERROR) return; } ibuf = sc->sc_ibuf; /* * The M$ Wireless Intellimouse 2.0 sends 1 extra leading byte of * data compared to most USB mice. This byte frequently switches * from 0x01 (usual state) to 0x02. I assume it is to allow * extra, non-standard, reporting (say battery-life). However * at the same time it generates a left-click message on the button * byte which causes spurious left-click's where there shouldn't be. * This should sort that. * Currently it's the only user of UMS_T so use it as an identifier. * We probably should switch to some more official quirk. * * UPDATE: This problem affects the M$ Wireless Notebook Optical Mouse, * too. However, the leading byte for this mouse is normally 0x11, * and the phantom mouse click occurs when its 0x14. */ if (sc->flags & UMS_T) { if (sc->sc_iid) { if (*ibuf++ == 0x02) return; } } else if (sc->flags & UMS_SPUR_BUT_UP) { DPRINTFN(5, ("ums_intr: #### ibuf[0] =3D %d ####\n", *ibuf)); if (*ibuf == 0x14 || *ibuf == 0x15) return; } else { if (sc->sc_iid) { if (*ibuf++ != sc->sc_iid) return; } } dx = hid_get_data(ibuf, &sc->sc_loc_x); dy = -hid_get_data(ibuf, &sc->sc_loc_y); dz = -hid_get_data(ibuf, &sc->sc_loc_z); dw = hid_get_data(ibuf, &sc->sc_loc_w); if (sc->flags & UMS_REVZ) dz = -dz; if (sc->flags & UMS_T) dt = -hid_get_data(ibuf, &sc->sc_loc_t); else dt = 0; for (i = 0; i < sc->nbuttons; i++) if (hid_get_data(ibuf, &sc->sc_loc_btn[i])) buttons |= (1 << UMS_BUT(i)); if (dx || dy || dz || dt || dw || (sc->flags & UMS_Z) || buttons != sc->status.button) { DPRINTFN(5, ("ums_intr: x:%d y:%d z:%d w:%d t:%d buttons:0x%x\n", dx, dy, dz, dw, dt, buttons)); sc->status.button = buttons; sc->status.dx += dx; sc->status.dy += dy; sc->status.dz += dz; /* sc->status.dt += dt; */ /* no way to export this yet */ /* sc->status.dw += dw; */ /* idem */ /* Discard data in case of full buffer */ if (sc->qcount == sizeof(sc->qbuf)) { DPRINTF(("Buffer full, discarded packet")); return; } From imp at bsdimp.com Sun Aug 24 04:40:51 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Aug 24 04:40:58 2008 Subject: usb4bsd patch review In-Reply-To: <10826.1219511738@critter.freebsd.dk> References: <20080823.100155.1310242209.imp@bsdimp.com> <10826.1219511738@critter.freebsd.dk> Message-ID: <20080823.223951.-962047221.imp@bsdimp.com> In message: <10826.1219511738@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20080823.100155.1310242209.imp@bsdimp.com>, "M. Warner Losh" writes : : : : >While this may be a good idea, I'm hesitant about races that it may : >introduce. This is the classic point of attack: do something between : >steps of a formerly atomic operation that was made non-atomic. I : >can't think of anything off the top of my head, but I'm still : >concerned. : : We have ways of closing the race if need be, but they're all slightly : kludgy, but I am not overly concerned about those races as long as : the default is to not give access. I guess I'm worried about a device that comes and goes and comes back and there being some difference between the two that causes us to bogusly do something to the new device that was appropriate for the old one, but not the new one... Wraner From fbsd-current at mawer.org Sun Aug 24 04:57:16 2008 From: fbsd-current at mawer.org (Antony Mawer) Date: Sun Aug 24 04:57:23 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <48AFE196.7050100@vwsoft.com> References: <20080819211814.6CD685B4D@mail.bitblocks.com> <20080819.160510.104119134.imp@bsdimp.com> <48AB566B.5010507@mawer.org> <20080819.180450.-867152686.imp@bsdimp.com> <48ABB1FA.5070609@mawer.org> <48AFE196.7050100@vwsoft.com> Message-ID: <48B0EA50.2090105@mawer.org> On 23/08/2008 8:08 PM, Volker wrote: > On 12/23/-58 20:59, Antony Mawer wrote: >> M. Warner Losh wrote: >>> In message: <48AB566B.5010507@mawer.org> >>> Antony Mawer writes: >>> : Warner Losh wrote: >>> : > From: Bakul Shah >>> : > Subject: Re: HEADSUP new usb code coming in. : > Date: Tue, 19 Aug >>> 2008 14:18:13 -0700 >>> : > : >> On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky >>> wrote: >>> : >>> New stuff (all of which I can remember right now): >>> : >> ... >>> : >> >>> : >> Accidentally unplugging a mounted USB disk (without >>> : >> unmounting it) resulted in a hang or a crash. Is this fixed? >>> : > : > That's fixed in -current right now with the old stack. It >>> isn't a usb >>> : > issue at all, but a buffer cache issue. >>> : : Is this change that is likely to be MFC'd in time for 7.1? And/or >>> is : there a specific patch that can manually be applied to -STABLE to >>> fix this? >>> >>> I should spend the time to dig into the changes in current. There >>> turned out to be several little changes... And I need to verify all >>> the edge cases were covered... >> I'd be happy to test patches if you do end up doing this.. it would be >> really nice to have in 7.1, or at least available as a patchset if it >> isn't suitable for MFC (eg. ABI changes)... > > I'm a bit behind with reading emails. Please forgive me if this has > already been answered. > > Don't expect the new USB stack for 7.1-R. It's too short and the new USB > stack will introduce an ABI breakage. For that, all drivers written for > the old USB stack need to be rewritten and I guess, we need to take care > about 3rd party developers and inform them in advance about that massive > change. I would not wonder if this will never get MFC'd but I don't know > actually. This wasn't about the new USB stack -- we were discussing the buffer cache and CAM-related fixes that prevents the system from panic'ing when a USB device is unplugged without first unmounting the filesystem. These patches are in HEAD with the existing USB stack. :-) --Antony From fbsd-current at mawer.org Sun Aug 24 04:57:16 2008 From: fbsd-current at mawer.org (Antony Mawer) Date: Sun Aug 24 04:57:33 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <48AFE196.7050100@vwsoft.com> References: <20080819211814.6CD685B4D@mail.bitblocks.com> <20080819.160510.104119134.imp@bsdimp.com> <48AB566B.5010507@mawer.org> <20080819.180450.-867152686.imp@bsdimp.com> <48ABB1FA.5070609@mawer.org> <48AFE196.7050100@vwsoft.com> Message-ID: <48B0EA50.2090105@mawer.org> On 23/08/2008 8:08 PM, Volker wrote: > On 12/23/-58 20:59, Antony Mawer wrote: >> M. Warner Losh wrote: >>> In message: <48AB566B.5010507@mawer.org> >>> Antony Mawer writes: >>> : Warner Losh wrote: >>> : > From: Bakul Shah >>> : > Subject: Re: HEADSUP new usb code coming in. : > Date: Tue, 19 Aug >>> 2008 14:18:13 -0700 >>> : > : >> On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky >>> wrote: >>> : >>> New stuff (all of which I can remember right now): >>> : >> ... >>> : >> >>> : >> Accidentally unplugging a mounted USB disk (without >>> : >> unmounting it) resulted in a hang or a crash. Is this fixed? >>> : > : > That's fixed in -current right now with the old stack. It >>> isn't a usb >>> : > issue at all, but a buffer cache issue. >>> : : Is this change that is likely to be MFC'd in time for 7.1? And/or >>> is : there a specific patch that can manually be applied to -STABLE to >>> fix this? >>> >>> I should spend the time to dig into the changes in current. There >>> turned out to be several little changes... And I need to verify all >>> the edge cases were covered... >> I'd be happy to test patches if you do end up doing this.. it would be >> really nice to have in 7.1, or at least available as a patchset if it >> isn't suitable for MFC (eg. ABI changes)... > > I'm a bit behind with reading emails. Please forgive me if this has > already been answered. > > Don't expect the new USB stack for 7.1-R. It's too short and the new USB > stack will introduce an ABI breakage. For that, all drivers written for > the old USB stack need to be rewritten and I guess, we need to take care > about 3rd party developers and inform them in advance about that massive > change. I would not wonder if this will never get MFC'd but I don't know > actually. This wasn't about the new USB stack -- we were discussing the buffer cache and CAM-related fixes that prevents the system from panic'ing when a USB device is unplugged without first unmounting the filesystem. These patches are in HEAD with the existing USB stack. :-) --Antony From imp at bsdimp.com Sun Aug 24 05:10:43 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Aug 24 05:10:55 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <48B0EA50.2090105@mawer.org> References: <48ABB1FA.5070609@mawer.org> <48AFE196.7050100@vwsoft.com> <48B0EA50.2090105@mawer.org> Message-ID: <20080823.231058.-1605553760.imp@bsdimp.com> In message: <48B0EA50.2090105@mawer.org> Antony Mawer writes: : On 23/08/2008 8:08 PM, Volker wrote: : > On 12/23/-58 20:59, Antony Mawer wrote: : >> M. Warner Losh wrote: : >>> In message: <48AB566B.5010507@mawer.org> : >>> Antony Mawer writes: : >>> : Warner Losh wrote: : >>> : > From: Bakul Shah : >>> : > Subject: Re: HEADSUP new usb code coming in. : > Date: Tue, 19 Aug : >>> 2008 14:18:13 -0700 : >>> : > : >> On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky : >>> wrote: : >>> : >>> New stuff (all of which I can remember right now): : >>> : >> ... : >>> : >> : >>> : >> Accidentally unplugging a mounted USB disk (without : >>> : >> unmounting it) resulted in a hang or a crash. Is this fixed? : >>> : > : > That's fixed in -current right now with the old stack. It : >>> isn't a usb : >>> : > issue at all, but a buffer cache issue. : >>> : : Is this change that is likely to be MFC'd in time for 7.1? And/or : >>> is : there a specific patch that can manually be applied to -STABLE to : >>> fix this? : >>> : >>> I should spend the time to dig into the changes in current. There : >>> turned out to be several little changes... And I need to verify all : >>> the edge cases were covered... : >> I'd be happy to test patches if you do end up doing this.. it would be : >> really nice to have in 7.1, or at least available as a patchset if it : >> isn't suitable for MFC (eg. ABI changes)... : > : > I'm a bit behind with reading emails. Please forgive me if this has : > already been answered. : > : > Don't expect the new USB stack for 7.1-R. It's too short and the new USB : > stack will introduce an ABI breakage. For that, all drivers written for : > the old USB stack need to be rewritten and I guess, we need to take care : > about 3rd party developers and inform them in advance about that massive : > change. I would not wonder if this will never get MFC'd but I don't know : > actually. : : This wasn't about the new USB stack -- we were discussing the buffer : cache and CAM-related fixes that prevents the system from panic'ing when : a USB device is unplugged without first unmounting the filesystem. These : patches are in HEAD with the existing USB stack. :-) The best I can do is say "Maybe" and the answer is closer to yes if somebody data-mines the changes I've made in this area in -current. That's the hard part of back porting them.. Warner From imp at bsdimp.com Sun Aug 24 05:10:43 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Aug 24 05:10:55 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <48B0EA50.2090105@mawer.org> References: <48ABB1FA.5070609@mawer.org> <48AFE196.7050100@vwsoft.com> <48B0EA50.2090105@mawer.org> Message-ID: <20080823.231058.-1605553760.imp@bsdimp.com> In message: <48B0EA50.2090105@mawer.org> Antony Mawer writes: : On 23/08/2008 8:08 PM, Volker wrote: : > On 12/23/-58 20:59, Antony Mawer wrote: : >> M. Warner Losh wrote: : >>> In message: <48AB566B.5010507@mawer.org> : >>> Antony Mawer writes: : >>> : Warner Losh wrote: : >>> : > From: Bakul Shah : >>> : > Subject: Re: HEADSUP new usb code coming in. : > Date: Tue, 19 Aug : >>> 2008 14:18:13 -0700 : >>> : > : >> On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky : >>> wrote: : >>> : >>> New stuff (all of which I can remember right now): : >>> : >> ... : >>> : >> : >>> : >> Accidentally unplugging a mounted USB disk (without : >>> : >> unmounting it) resulted in a hang or a crash. Is this fixed? : >>> : > : > That's fixed in -current right now with the old stack. It : >>> isn't a usb : >>> : > issue at all, but a buffer cache issue. : >>> : : Is this change that is likely to be MFC'd in time for 7.1? And/or : >>> is : there a specific patch that can manually be applied to -STABLE to : >>> fix this? : >>> : >>> I should spend the time to dig into the changes in current. There : >>> turned out to be several little changes... And I need to verify all : >>> the edge cases were covered... : >> I'd be happy to test patches if you do end up doing this.. it would be : >> really nice to have in 7.1, or at least available as a patchset if it : >> isn't suitable for MFC (eg. ABI changes)... : > : > I'm a bit behind with reading emails. Please forgive me if this has : > already been answered. : > : > Don't expect the new USB stack for 7.1-R. It's too short and the new USB : > stack will introduce an ABI breakage. For that, all drivers written for : > the old USB stack need to be rewritten and I guess, we need to take care : > about 3rd party developers and inform them in advance about that massive : > change. I would not wonder if this will never get MFC'd but I don't know : > actually. : : This wasn't about the new USB stack -- we were discussing the buffer : cache and CAM-related fixes that prevents the system from panic'ing when : a USB device is unplugged without first unmounting the filesystem. These : patches are in HEAD with the existing USB stack. :-) The best I can do is say "Maybe" and the answer is closer to yes if somebody data-mines the changes I've made in this area in -current. That's the hard part of back porting them.. Warner From phk at phk.freebsd.dk Sun Aug 24 06:00:13 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun Aug 24 06:00:20 2008 Subject: usb4bsd patch review In-Reply-To: Your message of "Sat, 23 Aug 2008 22:39:51 CST." <20080823.223951.-962047221.imp@bsdimp.com> Message-ID: <13745.1219557610@critter.freebsd.dk> In message <20080823.223951.-962047221.imp@bsdimp.com>, "M. Warner Losh" writes : >In message: <10826.1219511738@critter.freebsd.dk> > "Poul-Henning Kamp" writes: >: In message <20080823.100155.1310242209.imp@bsdimp.com>, "M. Warner Losh" writes >: : >: >: >While this may be a good idea, I'm hesitant about races that it may >: >introduce. This is the classic point of attack: do something between >: >steps of a formerly atomic operation that was made non-atomic. I >: >can't think of anything off the top of my head, but I'm still >: >concerned. >: >: We have ways of closing the race if need be, but they're all slightly >: kludgy, but I am not overly concerned about those races as long as >: the default is to not give access. > >I guess I'm worried about a device that comes and goes and comes back >and there being some difference between the two that causes us to >bogusly do something to the new device that was appropriate for the >old one, but not the new one... That scenario is always present as far as I can tell... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From myswlde at yahoo.de Sun Aug 24 10:00:13 2008 From: myswlde at yahoo.de (Daniel) Date: Sun Aug 24 10:00:19 2008 Subject: usb/126776: [umass/geom] confusing mixed output (but no panic!) after removing unmounted usb device Message-ID: <200808240951.m7O9pX3m029387@www.freebsd.org> >Number: 126776 >Category: usb >Synopsis: [umass/geom] confusing mixed output (but no panic!) after removing unmounted usb device >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Aug 24 10:00:11 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Daniel >Release: FreeBSD 7.0-RELEASE >Organization: >Environment: FreeBSD xyz 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >Description: Removing the usb flash drive produces a confusing output. There is NO kernel panic! To see it better I label the usb device "XXXXXXXXXXX". It does not matter if the device was mounted+unmount before removing. Problem occurs in FreeBSD 7.0 i386+amd64 with two different usb flash drives (128MB Twinmos and 1GB Sandisk). No problem with FreeBSD 6.3 on the same machine. plug in usb device: ------------------- root: Unknown USB device: vendor 0x126f product 0x1325 bus uhub1 kernel: umass0: on uhub1 kernel: da0 at umass-sim0 bus 0 target 0 lun 0 kernel: da0: Removable Direct Access SCSI-2 device kernel: da0: 40.000MB/s transfers kernel: da0: 122MB (249856 512 byte sectors: 64H 32S/T 122C) kernel: GEOM_LABEL: Label for provider da0s1 is msdosfs/XXXXXXXXXXX. mount -t msdosfs /dev/da0s1 /mnt/usb ------------------------------------ kernel: GEOM_LABEL: Label msdosfs/XXXXXXXXXXX removed. umount /mnt/usb --------------- kernel: GEOM_LABEL: Label for provider da0s1 is msdosfs/XXXXXXXXXXX. remove the usb device - output on FreeBSD 7.0 ------------------------------------------------- kernel: umass0: at uhub1 port 4 (addr 2) disconnected kernel: (da0:uGmEaOsMs_-LsAiBmE0L::0 :La0b:e0l) : mlsodsots fdse/vXiXcXeXX kernel: XX(XdXaX0X: urmeamsosv-esdim.0:0:0:0): removing device entry kernel: kernel: umass0: detached It looks like the GEOM output ("GEOM_LABEL: Label msdosfs/XXXXXXXXXXX removed.") is written over the UMASS output. remove the usb device - output on FreeBSD 6.3 ------------------------------------------------- kernel: umass0: at uhub1 port 4 (addr 2) disconnected kernel: (da0:umass-sim0:0:0:0): lost device kernel: (da0:umass-sim0:0:0:0): removing device entry kernel: umass0: detached >How-To-Repeat: plug in and remove the usb flash drive >Fix: >Release-Note: >Audit-Trail: >Unformatted: From rink at FreeBSD.org Sun Aug 24 10:50:05 2008 From: rink at FreeBSD.org (Rink Springer) Date: Sun Aug 24 10:50:12 2008 Subject: usb/126776: [umass/geom] confusing mixed output (but no panic!) after removing unmounted usb device Message-ID: <200808241050.m7OAo5V5062472@freefall.freebsd.org> The following reply was made to PR usb/126776; it has been noted by GNATS. From: Rink Springer To: Daniel Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: usb/126776: [umass/geom] confusing mixed output (but no panic!) after removing unmounted usb device Date: Sun, 24 Aug 2008 12:33:47 +0200 Hi Daniel, On Sun, Aug 24, 2008 at 09:51:33AM +0000, Daniel wrote: > It looks like the GEOM output ("GEOM_LABEL: Label msdosfs/XXXXXXXXXXX removed.") is written over the UMASS output. Yes, this is a FAQ - look at http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues, "Kernel". Regards, -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From fbsd-current at mawer.org Sun Aug 24 12:19:19 2008 From: fbsd-current at mawer.org (Antony Mawer) Date: Sun Aug 24 12:19:30 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080823.231058.-1605553760.imp@bsdimp.com> References: <48ABB1FA.5070609@mawer.org> <48AFE196.7050100@vwsoft.com> <48B0EA50.2090105@mawer.org> <20080823.231058.-1605553760.imp@bsdimp.com> Message-ID: <48B14AEC.2020609@mawer.org> On 24/08/2008 3:10 PM, M. Warner Losh wrote: > In message: <48B0EA50.2090105@mawer.org> > Antony Mawer writes: ... > : This wasn't about the new USB stack -- we were discussing the buffer > : cache and CAM-related fixes that prevents the system from panic'ing when > : a USB device is unplugged without first unmounting the filesystem. These > : patches are in HEAD with the existing USB stack. :-) > > The best I can do is say "Maybe" and the answer is closer to yes if > somebody data-mines the changes I've made in this area in -current. > That's the hard part of back porting them.. I'm going to try and do just that - is there a particular date that this must be done by in order to make sure these would make it in for the 7.1 release cycle? --Antony From fbsd-current at mawer.org Sun Aug 24 12:19:19 2008 From: fbsd-current at mawer.org (Antony Mawer) Date: Sun Aug 24 12:19:31 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <20080823.231058.-1605553760.imp@bsdimp.com> References: <48ABB1FA.5070609@mawer.org> <48AFE196.7050100@vwsoft.com> <48B0EA50.2090105@mawer.org> <20080823.231058.-1605553760.imp@bsdimp.com> Message-ID: <48B14AEC.2020609@mawer.org> On 24/08/2008 3:10 PM, M. Warner Losh wrote: > In message: <48B0EA50.2090105@mawer.org> > Antony Mawer writes: ... > : This wasn't about the new USB stack -- we were discussing the buffer > : cache and CAM-related fixes that prevents the system from panic'ing when > : a USB device is unplugged without first unmounting the filesystem. These > : patches are in HEAD with the existing USB stack. :-) > > The best I can do is say "Maybe" and the answer is closer to yes if > somebody data-mines the changes I've made in this area in -current. > That's the hard part of back porting them.. I'm going to try and do just that - is there a particular date that this must be done by in order to make sure these would make it in for the 7.1 release cycle? --Antony From kes-kes at yandex.ru Sun Aug 24 14:50:02 2008 From: kes-kes at yandex.ru (Eugen Konkov) Date: Sun Aug 24 14:50:08 2008 Subject: usb/126788: Can not boot FreeBSDv7.0.iso from USB formated as FAT? Message-ID: <200808241441.m7OEfahO096967@www.freebsd.org> >Number: 126788 >Category: usb >Synopsis: Can not boot FreeBSDv7.0.iso from USB formated as FAT? >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sun Aug 24 14:50:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Eugen Konkov >Release: 7.0release >Organization: >Environment: do not know yet >Description: I am trying to use SYSLINUX to load *.iso Actually I format and install to USB key syslinux I copy memdisk to root of USB key I unpack content to root of USB key When I boot from USB I get SYSLINUX loaded then I do: memdisk initrd/boot/boot I get invalid label so I da(0,a) and I get registry dump in loop How to boot iso installed to USB disk formatted as FAT! not BSD native >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From imp at bsdimp.com Sun Aug 24 16:26:12 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Aug 24 16:26:31 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <48B14AEC.2020609@mawer.org> References: <48B0EA50.2090105@mawer.org> <20080823.231058.-1605553760.imp@bsdimp.com> <48B14AEC.2020609@mawer.org> Message-ID: <20080824.102307.439579517.imp@bsdimp.com> In message: <48B14AEC.2020609@mawer.org> Antony Mawer writes: : On 24/08/2008 3:10 PM, M. Warner Losh wrote: : > In message: <48B0EA50.2090105@mawer.org> : > Antony Mawer writes: : ... : > : This wasn't about the new USB stack -- we were discussing the buffer : > : cache and CAM-related fixes that prevents the system from panic'ing when : > : a USB device is unplugged without first unmounting the filesystem. These : > : patches are in HEAD with the existing USB stack. :-) : > : > The best I can do is say "Maybe" and the answer is closer to yes if : > somebody data-mines the changes I've made in this area in -current. : > That's the hard part of back porting them.. : : I'm going to try and do just that - is there a particular date that this : must be done by in order to make sure these would make it in for the 7.1 : release cycle? End of this month would be ideal. By the middle of next would be acceptable, I think. Warner From imp at bsdimp.com Sun Aug 24 16:26:12 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Aug 24 16:26:31 2008 Subject: HEADSUP new usb code coming in. In-Reply-To: <48B14AEC.2020609@mawer.org> References: <48B0EA50.2090105@mawer.org> <20080823.231058.-1605553760.imp@bsdimp.com> <48B14AEC.2020609@mawer.org> Message-ID: <20080824.102307.439579517.imp@bsdimp.com> In message: <48B14AEC.2020609@mawer.org> Antony Mawer writes: : On 24/08/2008 3:10 PM, M. Warner Losh wrote: : > In message: <48B0EA50.2090105@mawer.org> : > Antony Mawer writes: : ... : > : This wasn't about the new USB stack -- we were discussing the buffer : > : cache and CAM-related fixes that prevents the system from panic'ing when : > : a USB device is unplugged without first unmounting the filesystem. These : > : patches are in HEAD with the existing USB stack. :-) : > : > The best I can do is say "Maybe" and the answer is closer to yes if : > somebody data-mines the changes I've made in this area in -current. : > That's the hard part of back porting them.. : : I'm going to try and do just that - is there a particular date that this : must be done by in order to make sure these would make it in for the 7.1 : release cycle? End of this month would be ideal. By the middle of next would be acceptable, I think. Warner From dfilter at FreeBSD.ORG Mon Aug 25 02:40:05 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Mon Aug 25 02:40:11 2008 Subject: usb/121184: commit references a PR Message-ID: <200808250240.m7P2e4kb047376@freefall.freebsd.org> The following reply was made to PR usb/121184; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: usb/121184: commit references a PR Date: Mon, 25 Aug 2008 02:36:44 +0000 (UTC) imp 2008-08-25 02:36:27 UTC FreeBSD src repository Modified files: sys/dev/usb uipaq.c Log: SVN rev 182138 on 2008-08-25 02:36:27Z by imp Greatly expand the devices listed as being supported. This list was taken from PR/121184 which was mechanically generated from similar lists in the Linux ipaq driver. I then took the numbers we had in usbdevs and filled in the right symbols and eliminated duplicates. PR: 121184 Revision Changes Path 1.14 +449 -0 src/sys/dev/usb/uipaq.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From dfilter at FreeBSD.ORG Mon Aug 25 02:50:08 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Mon Aug 25 02:50:14 2008 Subject: usb/121184: commit references a PR Message-ID: <200808250250.m7P2o7dm047812@freefall.freebsd.org> The following reply was made to PR usb/121184; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: usb/121184: commit references a PR Date: Mon, 25 Aug 2008 02:42:35 +0000 (UTC) imp 2008-08-25 02:42:13 UTC FreeBSD src repository Modified files: sys/dev/usb uipaq.c Log: SVN rev 182140 on 2008-08-25 02:42:13Z by imp Send the magic unlock packet the linux driver claims to have sniffed to enable line control. PR: 121184 Submitted by: Andriy Gapon Revision Changes Path 1.15 +16 -1 src/sys/dev/usb/uipaq.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From bugmaster at FreeBSD.org Mon Aug 25 11:07:01 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 25 11:09:13 2008 Subject: Current problem reports assigned to freebsd-usb@FreeBSD.org Message-ID: <200808251106.m7PB6xfS027927@freefall.freebsd.org> Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f 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 i386/46371 usb USB controller cannot be initialized on IBM Netfinity o bin/57255 usb usbd(8) and multi-function devices o usb/63621 usb [umass] [panic] USB MemoryStick Reader stalls/crashes o usb/67301 usb [uftdi] [panic] RTS and system panic o usb/69006 usb [usbdevs] [patch] Apple Cinema Display hangs USB ports o usb/71155 usb [ulpt] misbehaving usb-printer hangs processes, causes o usb/73307 usb [panic] Kernel panics on USB disconnect o usb/74771 usb [umass] [hang] mounting write-protected umass device a o usb/75705 usb [umass] [panic] da0 attach / Optio S4 (with backtrace) o usb/75797 usb [sound] 5.3-STABLE(2005 1/4) detect USB headset, But c o usb/76395 usb [uhci] USB printer does not work, usbdevs says "addr 0 o usb/77184 usb [umass] [panic] kernel panic on USB device disconnect, o usb/77294 usb [ucom] [panic] ucom + ulpcom panic o usb/79269 usb [ohci] USB ohci da0 plug/unplug causes crashes and loc o usb/79287 usb [uhci] [hang] UHCI hang after interrupt transfer o usb/79524 usb [ulpt] printing to Minolta PagePro 1[23]xxW via USB fa a usb/79656 usb [ehci] RHSC interrupts lost o usb/79722 usb [ehci] wrong alignments in ehci.h o usb/80040 usb [hang] Use of sound mixer causes system freeze with ua o usb/80361 usb [umass] [patch] mounting of Dell usb-stick fails o usb/80829 usb [modules] [panic] possible panic when loading USB-modu o usb/80862 usb [patch] USB locking issues: missing some Giant calls o usb/82350 usb [ucom] [panic] null pointer dereference in USB stack o usb/82520 usb [udbp] [reboot] Reboot when USL101 connected s usb/82569 usb [umass] [panic] USB mass storage plug/unplug causes sy o usb/82660 usb [ehci] [panic] EHCI: I/O stuck in state 'physrd'/panic o usb/83504 usb [kernel] [patch] SpeedTouch USB stop working on recent o usb/83563 usb [umass] [panic] Page Fault while detaching Mpman Usb d f usb/83677 usb [usb] [request] usb controller often not detected (Sun o usb/83756 usb [ums] [patch] Microsoft Intellimouse Explorer 4.0A doe 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 s usb/84336 usb [usb] [reboot] instant system reboot when unmounting a o usb/86767 usb [umass] [patch] bogus "slice starts beyond end of the o usb/88743 usb [hang] [regression] USB makes kernel hang at boot (reg s usb/89003 usb [request] LaCie Firewire drive not properly supported o usb/89954 usb [umass] [panic] USB Disk driver race condition? o usb/90700 usb [umass] [panic] Kernel panic on connect/mount/use umas o usb/91238 usb [umass] USB tape unit fails to write a second tape fil o usb/91283 usb [boot] [regression] booting very slow with usb devices o usb/91538 usb [ulpt] [patch] Unable to print to EPSON CX3500 o usb/91906 usb [ehci] [hang] FreeBSD hangs while booting with USB leg o usb/92052 usb [ulpt] usbd causes defunct process with busy file-hand o usb/92083 usb [ural] [panic] panic using WPA on ural NIC in 6.0-RELE o usb/92142 usb [uhub] SET_ADDR_FAILED and SHORT_XFER errors from usb o usb/92171 usb [panic] panic unplugging Vodafone Mobile Connect (UMTS o usb/93155 usb [ulpt] /dev/ulpt0: device busy, USB printer does not w o usb/93408 usb [mouse] hw.acpi.cpu.cx_lowest=C3 on AMD Turion causes o usb/93828 usb [ohci] [panic] ohci causes panic on boot (HP Pavillion o usb/94384 usb [panic] kernel panic with usb2 hardware o usb/94717 usb [ulpt] Reading from /dev/ulpt can break work of a UHCI o usb/94897 usb [panic] Kernel Panic when cleanly unmounting USB disk s usb/95348 usb [keyboard] USB keyboard unplug causes noise on screen o usb/95562 usb [umass] Write Stress in USB Mass drive causes "vinvalb s usb/95636 usb [umass] [boot] 5 minute delay at boot when using VT620 s usb/96120 usb [ums] [request] USB mouse not always detected o usb/96224 usb [usb] [msdosfs] mount_msdosfs cause page fault in sync o usb/96457 usb [umass] [panic] fatback on umass = reboot s usb/97286 usb [mouse] [request] MS Wireless Intellimouse Explorer 2. o usb/99431 usb [keyboard] FreeBSD on MSI 6566E (Intel 845E motherboar o usb/101096 usb [ural] [panic] USB WLAN occasionally causes kernel-pan o usb/101448 usb [ohci] FBSD 6.1-STABLE/AMD64 crashes under heavy USB/O o usb/101752 usb [umass] [panic] 6.1-RELEASE kernel panic on usb device o usb/102066 usb [ukbd] usb keyboard and multimedia keys don't work f usb/102096 usb [patch] usbd(8) does not handle multiple devices in on o usb/103025 usb [uhub] [panic] wrong detection of USB device for FreeB o usb/104292 usb [umass] [hang] system lockup on forced umount of usb-s o usb/104830 usb [umass] system crashes when copying data to umass devi o usb/105186 usb [ehci] [panic] USB 2.0/ehci on FreeBSD 6.2-PRE/AMD64 c o usb/106615 usb [uftdi] uftdi module does not automatically load with o usb/106648 usb [umass] [hang] USB Floppy on D1950 10 min Hang on Inse s usb/106832 usb USB HP printer is not detected by kernel when ACPI ena o usb/107248 usb [umass] [patch] scsi_da.c quirk for Cowon iAUDIO X5 MP o usb/107446 usb [umass] umass problems (usb and fw disks) o usb/107827 usb [ohci] [panic] ohci_add_done addr not found o usb/107848 usb [umass] [request] cannot access Samsung flash disk o usb/107924 usb [patch] usbd(8) does not call detach o usb/108513 usb [umass] Creative MuVo TX FM fails in 6.2-RELEASE [regr 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/110856 usb [ugen] [patch] interrupt in msgs are truncated when bu o usb/110988 usb [umass] [patch] Handling of quirk IGNORE_RESIDUE is um o usb/111753 usb [uhid] [panic] Replicable system panic involving UHID s usb/112568 usb [umass] [request] USB mode may wrong when mounting Pla o usb/112631 usb [panic] Problem with SONY DSC-S80 camera on umount o usb/112640 usb [usb] [hang] Kernel freezes when writing a file to an s usb/113629 usb [ukbd] Dropped USB keyboard events on Dell Latitude D6 o usb/113672 usb [ehci] [panic] Kernel panic with AEWIN CB6971 s usb/113977 usb [request] Need a way to set mode of USB disk's write c o usb/114310 usb [libusb] [patch] [panic] USB hub attachment panics ker o usb/114682 usb [umass] generic USB media-card reader unusable o kern/114780 usb [uplcom] [panic] Panics while stress testing the uplco o usb/115298 usb [ulpt] [panic] Turning off USB printer panics kernel o usb/116561 usb [umodem] [panic] RELENG_6 umodem panic "trying to slee o usb/116699 usb [usbhid] USB HID devices do not initialize at system b o usb/116947 usb [ukbd] [patch] [regression] enable boot protocol on th o usb/117200 usb [ugen] ugen0 prints strange string on attach if detach o usb/117313 usb [umass] [panic] panic on usb camera insertion o usb/117613 usb [uhci] [irq] uhci interrupt storm & USB leaked memory o usb/117946 usb [panic] D-Link DUB-E100 rev. B1 crashes FreeBSD 7.0-BE o usb/117955 usb [umass] [panic] inserting minolta dimage a2 crashes OS o usb/118140 usb [ucom] [patch] quick hack for ucom to get it behave wi o usb/118141 usb [ucom] usb serial and nokia phones ucomreadcb ucomread o usb/118353 usb [panic] [ppp] repeatable kernel panic during ppp(4) se o usb/118480 usb [umass] Timeout in USB mass storage freezes vfs layer o usb/119201 usb [cam] [patch] Quirks for Olympus FE-210 camera, LG and o usb/119481 usb [hang] FreeBSD not responding after connecting USB-Mas o usb/119509 usb USB flaky on Dell Optiplex 755 o usb/119513 usb [irq] inserting dlink dwl-g630 wireless card results i o usb/119977 usb [ums] Mouse does not work in a Cherry-USB keyboard/mou o usb/120017 usb [ehci] [patch] CS5536 (AMD Geode) USB 2.0 quirk o usb/120034 usb [hang] 6.2 & 6.3 hangs on boot at usb0: OHCI with 1.5 o usb/120283 usb [panic] Automation reboot with wireless keyboard & mou o usb/120321 usb [hang] System hangs when transferring data to WD MyBoo o usb/120729 usb [panic] fault while in kernel mode with connecting USB o usb/120786 usb Kernel panic when forced umount of a dettached USB Har o usb/121232 usb remove PCCARD rebooted system o usb/121275 usb [boot] FreeBSD fails to boot with usb legacy support e o usb/121474 usb [cam] [patch] QUIRK: SAMSUNG HM250JI in LaCie usb hard o usb/121708 usb [keyboard] nforce 650i mobo w/ usb keyboard infinite k o usb/121734 usb [ugen] ugen HP1022 printer device not working since up o usb/121755 usb [ohci] [patch] Fix panic after ohci/uhub cardbus devic o usb/122483 usb [panic] [ulpt] Repeatable panic in 7.0-STABLE o usb/122539 usb [ohci] [panic] AnyDATA ADU-E1000D - kernel panic: ohci o usb/122905 usb [ubsa] [patch] add Huawei E220 to ubsa o usb/123690 usb Panic on USB device insertion when usb loaded as a mod o usb/123714 usb Panic when hald-storage-probe runs with umass device i o usb/124708 usb [panic] Kernel panic on USB KVM reattach o usb/124758 usb rum panics SMP kernel o kern/124777 usb [ucom] USB cua devices don't revert to tty devices whe o usb/124980 usb [panic] kernel panic on detaching unmounted umass devi o usb/125088 usb Touchpad not detected on Adesso AKB-430UG USB kbd/pad o usb/125450 usb [panic] Removing USB flash card while being accessed c o usb/125631 usb [usb][ums] kernel panic during bootup while 'Logitech o kern/126396 usb [panic] kernel panic after unplug USB Bluetooth device o usb/126519 usb [usb] [panic] panic when plugging in an iphone o usb/126740 usb [ulpt] doesn't work on 7.0-RELEASE, 10 second stall be 137 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/30929 usb [usb] [patch] use usbd to initialize USB ADSL modem o usb/40948 usb [umass] [request] USB HP CDW8200 does not work s usb/51958 usb [urio] [patch] update for urio driver s usb/52026 usb [usb] [request] umass driver support for InSystem ISD2 o usb/59698 usb [keyboard] [patch] Rework of ukbd HID to AT code trans s usb/62257 usb [umass] [request] card reader UCR-61S2B is only half-s o usb/66547 usb [ucom] Palm Tungsten T USB does not initialize correct o usb/68232 usb [ugen] [patch] ugen(4) isochronous handling correction o usb/70523 usb [umct] [patch] umct sending/receiving wrong characters o usb/71280 usb [aue] aue0 device (linksys usb100tx) doesn't work in 1 o usb/71416 usb [ugen] Cryptoflex e-gate USB token (ugen0) detach is n o usb/71417 usb [ugen] Cryptoflex e-gate USB token (ugen0) communicati o usb/71455 usb [umass] Slow USB umass performance of 5.3 s usb/72733 usb [ucom] [request] Kyocera 7135 Palm OS connection probl o usb/74211 usb [umass] USB flash drive causes CAM status 0x4 on 4.10R a usb/74453 usb [umass] [patch] Q-lity CD-RW USB ECW-043 (ScanLogic SL o usb/75764 usb [umass] [patch] "umass0: Phase Error" - no device for o usb/75800 usb [ucom] ucom1: init failed STALLED error in time of syn s usb/75928 usb [umass] [request] Cytronix SmartMedia card (SMC) reade o usb/76461 usb [umass] disklabel of umass(4)-CAM(4)-da(4) not used by o usb/76653 usb [umass] [patch] Problem with Asahi Optical usb device o usb/76732 usb Mouse problems with USB KVM Switch o usb/78984 usb [umass] [patch] Creative MUVO umass failure o usb/79723 usb [usb] [request] prepare for high speed isochronous tra o usb/80774 usb [patch] have "usbd_find_desc" in line with the other " s usb/80776 usb [udav] [request] UDAV device driver shouldn't use usb_ s usb/80777 usb [request] usb_rem_task() should wait for callback to c o usb/80854 usb [patch] [request] suggestion for new iface-no-probe me o usb/80935 usb [uvisor] [patch] uvisor.c is not work with CLIE TH55. o usb/81621 usb [ehci] [hang] external hd hangs under load on ehci o usb/83863 usb [ugen] Communication problem between opensc/openct via s usb/85067 usb [uscanner] Cannot attach ScanJet 4300C to usb device o usb/86298 usb [mouse] Known good USB mouse won't work with correct s o usb/87224 usb Cannot mount USB Zip750 o usb/87648 usb [mouse] Logitech USB-optical mouse problem. o usb/88408 usb [axe] axe0 read PHY failed o usb/91546 usb [umodem] [patch] Nokia 6630 mobile phone does not work o usb/91811 usb [umass] Compact Flash in HP Photosmart 2610 return " o usb/91896 usb camcontrol(8): Serial Number of USB Memory Sticks is n o usb/92852 usb [ums] [patch] Vertical scroll not working properly on o usb/93389 usb [umass] [patch] Digital Camera Pentax S60 don't work o usb/93872 usb [cam] [patch] SCSI quirk required for ELTA 8061 OL USB o usb/95037 usb [umass] USB disk not recognized on hot-plug. o usb/96381 usb [cam] [patch] add a quirk table entry for a flash ram o usb/96599 usb [usb] [patch] Sony Handycam DCR-HC32E memory stick slo o usb/97175 usb [umass] [hang] USB cardreader hangs system o usb/97472 usb [cam] [patch] add support for Olympus C150,D390 o usb/98343 usb [boot] BBB reset failed errors with Creative Muvo MP3 o usb/99538 usb [keyboard] while using USB keyboard default params of o usb/100746 usb [keyboard] system does not boot due to USB keyboard pr o usb/101761 usb [usb] [patch] [request] usb.h: increase maximal size o o usb/101775 usb [libusbhid] [patch] possible error in report descripto o usb/102678 usb [keyboard] Dell PowerEdge DRAC5 USB Keyboard does not o usb/102976 usb [panic] Casio Exilim Digital Camera causes panic on in o usb/103046 usb [ulpt] [patch] ulpt event driven I/O with select(2) an o usb/103289 usb [request] USB 2.0 problems on AMD LX-800 CPU and CS-55 o usb/103418 usb [usbhidctl] [patch] [request] usbhidctl: add ability t o usb/103917 usb [uhub] USB driver reports "Addr 0 should never happen" o usb/104290 usb [umass] [patch] quirk: TOSHIBA DVD-RAM drive (libretto o usb/104352 usb [ural] [patch] ural driver doesnt work o usb/104645 usb [umass] [request] Rave C-201 MP3 player does not commu o usb/105065 usb [ata] SATA - USB Bridge o usb/105361 usb [panic] Kernel panic during unmounting mass storage (C o usb/106041 usb [usb] [request] FreeBSD does not recognise Mustek Bear o usb/106621 usb [axe] [patch] DLINK DUB-E100 support broken o usb/106861 usb [usbdevs] [patch]: usbdevs update: Add product ACER Ze o usb/107243 usb [cam] [patch] Apacer USB Flash Drive quirk o usb/107388 usb [patch] [request] new driver: add utoppy device from N o usb/107496 usb [uhub] USB device problem on RELENG_6_2 (SHORT_XFER) [ o usb/107935 usb [uplcom] [panic] panic while accessing /dev/cuaU0 o usb/108056 usb [ohci] Mouse gets powered off during device probe when s usb/108344 usb [panic] kernel with atausb panics when unplugging USB o usb/110197 usb [umass] Sony PSP umass device does not detach from EHC s usb/110991 usb [usbdevs] [patch] QUIRK: Super Top IDE DEVICE (depends o usb/112461 usb [ehci] [request] ehci USB 2.0 doesn't work on nforce4 o usb/112463 usb [umass] problem with Samsung USB DVD writer, libscg an o usb/112944 usb [ulpt] [patch] Bi-directional access to HP LaserJet 10 o usb/113060 usb [usbdevs] [patch] Samsung printer not working in bidir o usb/113432 usb [ucom] WARNING: attempt to net_add_domain(netgraph) af o conf/114013 usb [patch] WITHOUT_USB allow to compil a lot of USB stuff o usb/114068 usb [umass] [patch] Problems with connection of the umass o usb/114916 usb [umass] [patch] USB Maxtor drive (L300RO) requires qui o usb/115400 usb [ehci] Problem with EHCI on ASUS M2N4-SLI o usb/115933 usb [uftdi] [patch] RATOC REX-USB60F (usb serial converter o usb/115935 usb [usbdevs] [patch] kernel counterproductively attaches o usb/116282 usb [ulpt] Cannot print on USB HP LJ1018 or LJ1300 o usb/117075 usb [scsi_da] [patch] quirk: USB Samsung YP-U3 MP3 o usb/117183 usb [panic] USB/fusefs -- panic while transferring large a o usb/117185 usb [umodem] [patch] Add support for UNION interface descr o usb/117205 usb [uscanner] [patch] uscanner support for HP ScanJet 447 o usb/117546 usb [uftdi] [patch] Add MaxStream ZigBee product ID to uft o usb/117598 usb [uaudio] [patch] Not possible to record with Plantroni o usb/117893 usb [umass] Lacie USB DVD writing failing o usb/117911 usb [ums] [request] Mouse Gembird MUSWC not work o usb/117938 usb [ums] [patch] Adding support for MS WL Natural and MS o usb/118098 usb [umass] 6th gen iPod causes problems when disconnectin o usb/118485 usb [usbdevs] [patch] Logitech Headset Workaround o usb/118686 usb [usbdevs] [patch] teach usbdevs / ubsa(4) about Huawei o usb/119150 usb [usbdevs] [patch] new usbdevs for CDMA 1xEVDO devices o usb/119227 usb [ubsa] [patch] ubsa buffer is too small; should be tun o usb/119389 usb [umass] Sony DSC-W1 CBI reset failed, STALLED [regress o usb/119633 usb [umass] umass0: BBB reset failed, IOERROR [regression] o usb/119653 usb [cam] [patch] iriver s7 player sync cache error patch o usb/119981 usb [axe] [patch] add support for LOGITEC LAN-GTJ/U2 gigab o usb/120572 usb [umass] [patch] quirk to support ASUS P535 as umass (a o usb/121045 usb [uftdi] [patch] Add support for PC-OP-RS1 and KURO-RS o usb/121169 usb [umass] Issues with usb mp3 player o usb/121184 usb [uipaq] [patch] add ids from linux ipaq driver (plus a o usb/121426 usb [patch] [uscanner] add HP ScanJet 3570C o usb/122025 usb [patch] uscanner does not attach to Epson RX620 printe o usb/122119 usb [umass] umass device causes creation of daX but not da o usb/122547 usb [ehci] USB Printer not being recognized after reboot p usb/122610 usb Add Verizon v740 support to ubsa(4) o usb/122621 usb [patch] [request] New driver for Sierra Wireless 3G US o usb/122712 usb [usbdevs] [patch] Sony Vaio RF keyboard/mouse receiver o usb/122813 usb [udbp] [request] udbp driver should be removed in favo o usb/122819 usb Patch to provide dynamic additions to the usb quirks t o usb/122936 usb [ucom][ubsa] Device does not receive interrupt o usb/122956 usb Support for Novatel Wireless XU870 3G Card o usb/122992 usb MotoROKR Z6 Phone not recognised by umass as USB disk. p usb/123148 usb [uscanner] [patch] Epson DX8400/50 needs uscanner to s p usb/123211 usb [udav] if_udav driver doesn't support Davicom 9601 USB o usb/123351 usb Add Reiner SCT cyberJack, Omnikey [26]020, Fujitsu Sie o usb/123352 usb Add Option GTMAX3.6/7.2 and Quallcomm MMC module devic o usb/123509 usb [umass] continuous reset Samsung SGH-G600 phone o usb/123611 usb [usb] BBB reset failed, STALLED from Imation/Mitsumi U o usb/123691 usb usbd(8): usbd hangs o usb/123969 usb Supermicro H8SMi-2 usb problem o usb/124604 usb Wireless Mouse doesn't work o usb/125072 usb [uplcom] [patch] add Mobile Action MA-620 Infrared Ada o usb/125238 usb Habu Mouse turns off in X o usb/125264 usb [patch] sysctl for set usb mouse rate (very useful for o usb/125510 usb repeated plug and unplug of USB mass storage devices l o usb/125736 usb [ukbd] [hang] system hangs after AT keyboard detect if o usb/126776 usb [umass/geom] confusing mixed output (but no panic!) af o usb/126788 usb Can not boot FreeBSDv7.0.iso from USB formated as FAT? 136 problems total. From gavin at FreeBSD.org Mon Aug 25 14:21:58 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Mon Aug 25 14:22:05 2008 Subject: kern/126788: [boot] Can not boot FreeBSDv7.0.iso from USB formated as FAT? Message-ID: <200808251421.m7PELvTr049624@freefall.freebsd.org> Old Synopsis: Can not boot FreeBSDv7.0.iso from USB formated as FAT? New Synopsis: [boot] Can not boot FreeBSDv7.0.iso from USB formated as FAT? State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Mon Aug 25 14:18:53 UTC 2008 State-Changed-Why: To submitter: Can you try with one of the ISO images from ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200808/ and see if that works? Responsible-Changed-From-To: freebsd-usb->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Mon Aug 25 14:18:53 UTC 2008 Responsible-Changed-Why: TracK http://www.freebsd.org/cgi/query-pr.cgi?pr=126788 From r.c.ladan at gmail.com Mon Aug 25 14:26:14 2008 From: r.c.ladan at gmail.com (Rene Ladan) Date: Mon Aug 25 14:26:22 2008 Subject: Fwd: Patch for libusb In-Reply-To: <48B1AEB5.7050903@gmx.de> References: <48B11C77.3060708@gmx.de> <48B1A73F.7070301@gmail.com> <48B1AEB5.7050903@gmx.de> Message-ID: Hi, this is about a one-line patch for libusb-0.1.12 which is available in the ports tree as devel/libusb. Is it ok to send a problem report for this? Regards, Rene ---------- Forwarded message ---------- From: Volker Theile Date: 2008/8/24 Subject: Re: Patch for libusb To: Rene Ladan -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rene Ladan wrote: | Volker Theile schreef: |> Hello, |> |> i had to modify the bsd.c patch to get NUT (Network UPS tools) working correctly when i attach an UPS via USB to my FreeBSD machine. Without the patch the communication breaks every few seconds because of an full read buffer. NUT checks the input buffer too fast, so the kernel or something else blocks which will cause an communication break to the UPS. Don't know if i have explained it correctly, but it works. |> | The only difference between this patch and the one in devel/libusb/files is | that the fd is opened in non-blocking mode, right? | | Regards, | Rene Yes, that's correct. I've found the origin article where i've read about that patch for NetBSD. http://wiki.botka.homeunix.org/bin/view/Main/NetworkUpsToolsUsb - ------ cut -------------------------------- ~ todo: ~ 1. upsmon section ~ 2. Install libusb 0.1.12 ,0.1.11 includes a bug fix for *BSD to allow short reads. Without thisvarious status is not returned from UPS. ~ 3. Problem with libusb on netBSD in that the Function usb_interrupt_read() calls read() which blocks on read from usb until buffer is full. Change bsd.c in libusb Fd = ensure_ep_open(dev, ep, 0, O_RDONLY) To Fd = ensure_ep_open(dev, ep, 0, O_RDONLY | O_NONBLOCK) - ------ cut -------------------------------- I don't know whether this fix has any consequences for other applications, but for NUT it helps and now i can use my UPS via USB. Regards Volker -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkixrrQACgkQzsRXLGDcg0pMugCeKg2BtXAx+PjneOUKRhp+j5Bk +kAAn3DabDmqu9OSLrG1zoO0tupgeqqZ =ksxG -----END PGP SIGNATURE----- -- http://www.rene-ladan.nl/ GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) From pb at ludd.ltu.se Mon Aug 25 15:15:26 2008 From: pb at ludd.ltu.se (Peter B) Date: Mon Aug 25 15:15:33 2008 Subject: usbd_add_drv_event() ? Message-ID: <200808251515.m7PFFL1j017900@brother.ludd.ltu.se> What does 'usbd_add_drv_event()' kernel function do? Trying to understand the code ;) no man page.. From hselasky at c2i.net Mon Aug 25 20:31:22 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Aug 25 20:31:28 2008 Subject: usbd_add_drv_event() ? In-Reply-To: <200808251515.m7PFFL1j017900@brother.ludd.ltu.se> References: <200808251515.m7PFFL1j017900@brother.ludd.ltu.se> Message-ID: <200808252233.00933.hselasky@c2i.net> On Monday 25 August 2008, Peter B wrote: > What does 'usbd_add_drv_event()' kernel function do? > Trying to understand the code ;) > > no man page.. Hi, This function sends events to usbd, but is going to be removed. Replaced by devd. --HPS From volker at vwsoft.com Mon Aug 25 21:53:04 2008 From: volker at vwsoft.com (Volker) Date: Mon Aug 25 21:53:11 2008 Subject: "legacy" usb stack fixes (was: Re: HEADSUP new usb code coming in.) In-Reply-To: <48B0EA50.2090105@mawer.org> References: <20080819211814.6CD685B4D@mail.bitblocks.com> <20080819.160510.104119134.imp@bsdimp.com> <48AB566B.5010507@mawer.org> <20080819.180450.-867152686.imp@bsdimp.com> <48ABB1FA.5070609@mawer.org> <48AFE196.7050100@vwsoft.com> <48B0EA50.2090105@mawer.org> Message-ID: <48B3299F.5080101@vwsoft.com> On 08/24/08 06:57, Antony Mawer wrote: > On 23/08/2008 8:08 PM, Volker wrote: >> On 12/23/-58 20:59, Antony Mawer wrote: >>> M. Warner Losh wrote: >>>> In message: <48AB566B.5010507@mawer.org> >>>> Antony Mawer writes: >>>> : Warner Losh wrote: >>>> : > From: Bakul Shah >>>> : > Subject: Re: HEADSUP new usb code coming in. : > Date: Tue, 19 Aug >>>> 2008 14:18:13 -0700 >>>> : > : >> On Tue, 19 Aug 2008 22:44:20 +0200 Hans Petter Selasky >>>> wrote: >>>> : >>> New stuff (all of which I can remember right now): >>>> : >> ... >>>> : >> >>>> : >> Accidentally unplugging a mounted USB disk (without >>>> : >> unmounting it) resulted in a hang or a crash. Is this fixed? >>>> : > : > That's fixed in -current right now with the old stack. It >>>> isn't a usb >>>> : > issue at all, but a buffer cache issue. >>>> : : Is this change that is likely to be MFC'd in time for 7.1? And/or >>>> is : there a specific patch that can manually be applied to -STABLE to >>>> fix this? >>>> >>>> I should spend the time to dig into the changes in current. There >>>> turned out to be several little changes... And I need to verify all >>>> the edge cases were covered... >>> I'd be happy to test patches if you do end up doing this.. it would be >>> really nice to have in 7.1, or at least available as a patchset if it >>> isn't suitable for MFC (eg. ABI changes)... >> >> I'm a bit behind with reading emails. Please forgive me if this has >> already been answered. >> >> Don't expect the new USB stack for 7.1-R. It's too short and the new USB >> stack will introduce an ABI breakage. For that, all drivers written for >> the old USB stack need to be rewritten and I guess, we need to take care >> about 3rd party developers and inform them in advance about that massive >> change. I would not wonder if this will never get MFC'd but I don't know >> actually. > > This wasn't about the new USB stack -- we were discussing the buffer > cache and CAM-related fixes that prevents the system from panic'ing when > a USB device is unplugged without first unmounting the filesystem. These > patches are in HEAD with the existing USB stack. :-) > > --Antony > Antony, please forgive me. While re-reading the thread partially, I've also seen your question was about the old usb stack. That does happen if $SUBJECT does not match $CONTENT (you could have changed $SUBJECT when driving the discussion into another direction). Anyway, I've already had those crashes even with the "new" usb stack (but it doesn't happen everytime - YMMV). Volker From omar at heedme.com Tue Aug 26 05:39:10 2008 From: omar at heedme.com (Omar Siddique) Date: Tue Aug 26 05:39:17 2008 Subject: USB audio CDs? Message-ID: Is AUDIO from USB optical drives supported? See below for what I've tried under 6.3-RELEASE (unsuccessfully). (I tried freebsd-questions without any reply and only saw a couple of unanswered posts on the topic when searching the archives for this list.) Thanks for any advice! -omar ---------- Forwarded message ---------- Subject: USB audio CDs? I have a USB DVD-RW drive that I'd like to use to rip music under 6.3-RELEASE, but I don't seem to have a /dev/acd0 (and can't get "grip" (from ports) to work from /dev/cd0). /dev/cd0 shows up fine, but audio CDs log errors and "grip" can't do much with /dev/cd0. Using /dev/cd0, grip is able to see the TOC for the CD, but attempting to rip only generates errors: 006: Could not read any data from drive (repeats per track) Repeatable for different CDs. I was able to mount a cd9660 disc from this drive without a problem. I've previously done this (using grip) with ATA/SATA optical drives of various sorts, as well as used various (non-audio) USB mass-storage devices without any problems, but this is my first shot under *BSD at getting audio off a USB optical drive. I read through the USB related man pages, FB handbook, and googled without finding any answers... Would appreciate any advice! I have all of these in my running kernel: device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device ugen # Generic device umass # Disks/Mass storage - Requires scbus and da device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device pass # Passthrough device (direct SCSI access) device cd # scsi cd for cd-r/burner on USB device atapicam I tried it both w/ and w/o atapicam. Attaching device with audio CD loaded logs the following: Jul 20 01:28:20 mine kernel: umass0: Sony DRX-500UL, rev 2.00/1.04, addr 2 Jul 20 01:28:30 mine kernel: cd0 at umass-sim0 bus 0 target 0 lun 0 Jul 20 01:28:30 mine kernel: cd0: Removable CD-ROM SCSI-0 device Jul 20 01:28:30 mine kernel: cd0: 40.000MB/s transfers Jul 20 01:28:30 mine kernel: cd0: cd present [198012 x 2048 byte records] Jul 20 01:28:30 mine kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 2 0 Jul 20 01:28:30 mine kernel: (cd0:umass-sim0:0:0:0): CAM Status: SCSI Status Error Jul 20 01:28:30 mine kernel: (cd0:umass-sim0:0:0:0): SCSI Status: Check Condition Jul 20 01:28:30 mine kernel: (cd0:umass-sim0:0:0:0): ILLEGAL REQUEST asc:64,0 Jul 20 01:28:30 mine kernel: (cd0:umass-sim0:0:0:0): Illegal mode for this track Jul 20 01:28:30 mine kernel: (cd0:umass-sim0:0:0:0): Unretryable error Jul 20 01:28:30 mine kernel: (cd0:umass-sim0:0:0:0): cddone: got error 0x6 back Jul 20 01:28:30 mine kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 3 5 7b 0 0 1 0 Jul 20 01:28:30 mine kernel: (cd0:umass-sim0:0:0:0): CAM Status: SCSI Status Error Jul 20 01:28:30 mine kernel: (cd0:umass-sim0:0:0:0): SCSI Status: Check Condition (etc...) Thanks! -omar From gavin at FreeBSD.org Tue Aug 26 10:06:33 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Tue Aug 26 10:06:45 2008 Subject: usb/126845: Cyberpower UPS is attached as uhid instead of ugen Message-ID: <200808261006.m7QA6W7Q090361@freefall.freebsd.org> Synopsis: Cyberpower UPS is attached as uhid instead of ugen Responsible-Changed-From-To: freebsd-bugs->freebsd-usb Responsible-Changed-By: gavin Responsible-Changed-When: Tue Aug 26 10:06:13 UTC 2008 Responsible-Changed-Why: Over to maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=126845 From gavin at FreeBSD.org Tue Aug 26 10:10:04 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Aug 26 10:10:10 2008 Subject: usb/126845: Cyberpower UPS is attached as uhid instead of ugen Message-ID: <200808261010.m7QAA4hF090478@freefall.freebsd.org> The following reply was made to PR usb/126845; it has been noted by GNATS. From: Gavin Atkinson To: bug-followup@FreeBSD.org Cc: Mattias Lindgren Subject: Re: usb/126845: Cyberpower UPS is attached as uhid instead of ugen Date: Tue, 26 Aug 2008 11:08:43 +0100 (BST) Can you try this patch please? Index: src/sys/dev/usb/usb_quirks.c =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/usb_quirks.c,v retrieving revision 1.63.2.2 diff -u -r1.63.2.2 usb_quirks.c --- src/sys/dev/usb/usb_quirks.c 12 Aug 2008 19:40:18 -0000 1.63.2.2 +++ src/sys/dev/usb/usb_quirks.c 26 Aug 2008 10:05:03 -0000 @@ -96,6 +96,8 @@ ANY, { UQ_HID_IGNORE }}, { USB_VENDOR_BELKIN, USB_PRODUCT_BELKIN_F6C550AVR, ANY, { UQ_HID_IGNORE }}, + { USB_VENDOR_CYBERPOWER, USB_PRODUCT_CYBERPOWER_1500CAVRLCD, + ANY, { UQ_HID_IGNORE }}, { USB_VENDOR_DELORME, USB_PRODUCT_DELORME_EARTHMATE, ANY, { UQ_HID_IGNORE }}, { USB_VENDOR_ITUNERNET, USB_PRODUCT_ITUNERNET_USBLCD2X20, Index: src/sys/dev/usb/usbdevs =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.328.2.16 diff -u -r1.328.2.16 usbdevs --- src/sys/dev/usb/usbdevs 19 Aug 2008 01:51:37 -0000 1.328.2.16 +++ src/sys/dev/usb/usbdevs 26 Aug 2008 10:04:01 -0000 @@ -364,6 +364,7 @@ vendor DIGITALSTREAM 0x074e Digital Stream vendor AUREAL 0x0755 Aureal Semiconductor vendor MIDIMAN 0x0763 Midiman +vendor CYBERPOWER 0x0764 CyberPower vendor SURECOM 0x0769 Surecom Technology vendor LINKSYS2 0x077b Linksys vendor GRIFFIN 0x077d Griffin Technology @@ -1063,6 +1064,9 @@ product CURITEL HX57XB 0x2101 CDMA 2000 1xRTT USB modem (HX-570/575B/PR-600) product CURITEL PC5740 0x3701 Broadband Wireless modem +/* CyberPower products */ +product CYBERPOWER 1500CAVRLCD 0x0501 1500CAVRLCD + /* CyberTAN Technology products */ product CYBERTAN TG54USB 0x1666 TG54USB From imp at bsdimp.com Tue Aug 26 15:55:47 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Aug 26 15:55:54 2008 Subject: usb/126845: Cyberpower UPS is attached as uhid instead of ugen In-Reply-To: <200808261010.m7QAA4hF090478@freefall.freebsd.org> References: <200808261010.m7QAA4hF090478@freefall.freebsd.org> Message-ID: <20080826.095600.-1297659289.imp@bsdimp.com> In message: <200808261010.m7QAA4hF090478@freefall.freebsd.org> Gavin Atkinson writes: : +vendor CYBERPOWER 0x0764 CyberPower 0x764 is 1892 decimal and listed in the usb database as: 1892|Cyber Power Systems, Inc. So maybe that's what should be where "CyberPower" is now? Other than that, it looks good. Warner From gavin at FreeBSD.org Tue Aug 26 16:49:10 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Aug 26 16:49:15 2008 Subject: usb/126845: Cyberpower UPS is attached as uhid instead of ugen In-Reply-To: <20080826.095600.-1297659289.imp@bsdimp.com> References: <200808261010.m7QAA4hF090478@freefall.freebsd.org> <20080826.095600.-1297659289.imp@bsdimp.com> Message-ID: <1219767586.34348.66.camel@buffy.york.ac.uk> On Tue, 2008-08-26 at 09:56 -0600, M. Warner Losh wrote: > In message: <200808261010.m7QAA4hF090478@freefall.freebsd.org> > Gavin Atkinson writes: > : +vendor CYBERPOWER 0x0764 CyberPower > > 0x764 is 1892 decimal and listed in the usb database as: > > 1892|Cyber Power Systems, Inc. > > So maybe that's what should be where "CyberPower" is now? Thanks for noticing! I always forget that list is in decimal whenever I grep it. The submitter wanted extra info on how to apply it, so I've given them an updated patch, and I'll check through the other patches I've made to make sure I didn't make the same mistake with any of them. Gavin From remko at FreeBSD.org Wed Aug 27 06:34:15 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Wed Aug 27 06:34:27 2008 Subject: kern/126848: [usb]: USB Keyboard hangs during Installation Message-ID: <200808270634.m7R6YFiR067928@freefall.freebsd.org> Old Synopsis: USB Keyboard hangs during Installation New Synopsis: [usb]: USB Keyboard hangs during Installation State-Changed-From-To: open->feedback State-Changed-By: remko State-Changed-When: Wed Aug 27 06:33:46 UTC 2008 State-Changed-Why: I asked for feedback Responsible-Changed-From-To: freebsd-i386->freebsd-usb Responsible-Changed-By: remko Responsible-Changed-When: Wed Aug 27 06:33:46 UTC 2008 Responsible-Changed-Why: Move to the USB team http://www.freebsd.org/cgi/query-pr.cgi?pr=126848 From gavin at FreeBSD.org Wed Aug 27 11:10:03 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Wed Aug 27 11:10:10 2008 Subject: usb/126845: Cyberpower UPS is attached as uhid instead of ugen Message-ID: <200808271110.m7RBA2KP018933@freefall.freebsd.org> The following reply was made to PR usb/126845; it has been noted by GNATS. From: Gavin Atkinson To: bug-followup@FreeBSD.org Cc: Subject: Re: usb/126845: Cyberpower UPS is attached as uhid instead of ugen Date: Wed, 27 Aug 2008 12:02:41 +0100 --=-NPzv00iMx66t2hTUfOpS Content-Type: text/plain Content-Transfer-Encoding: 7bit Submitter confirms that the attached patch fixes things for him. (Patch slightly updated to match the official company name as registered in usb.if) --=-NPzv00iMx66t2hTUfOpS Content-Disposition: attachment; filename=126845.diff Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name=126845.diff; charset=ASCII SW5kZXg6IHNyYy9zeXMvZGV2L3VzYi91c2JfcXVpcmtzLmMNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxl OiAvaG9tZS9uY3ZzL3NyYy9zeXMvZGV2L3VzYi91c2JfcXVpcmtzLmMsdg0KcmV0cmlldmluZyBy ZXZpc2lvbiAxLjYzLjQuMQ0KZGlmZiAtdSAtcjEuNjMuNC4xIHVzYl9xdWlya3MuYw0KLS0tIHNy Yy9zeXMvZGV2L3VzYi91c2JfcXVpcmtzLmMJNyBKYW4gMjAwOCAyMzoxMjo0NSAtMDAwMAkxLjYz LjQuMQ0KKysrIHNyYy9zeXMvZGV2L3VzYi91c2JfcXVpcmtzLmMJMjYgQXVnIDIwMDggMTc6NDQ6 MDkgLTAwMDANCkBAIC05Niw2ICs5Niw4IEBADQogCUFOWSwgeyBVUV9ISURfSUdOT1JFIH19LA0K ICB7IFVTQl9WRU5ET1JfQkVMS0lOLCBVU0JfUFJPRFVDVF9CRUxLSU5fRjZDNTUwQVZSLA0KIAlB TlksIHsgVVFfSElEX0lHTk9SRSB9fSwNCisgeyBVU0JfVkVORE9SX0NZQkVSUE9XRVIsIFVTQl9Q Uk9EVUNUX0NZQkVSUE9XRVJfMTUwMENBVlJMQ0QsDQorCUFOWSwgeyBVUV9ISURfSUdOT1JFIH19 LA0KICB7IFVTQl9WRU5ET1JfREVMT1JNRSwgVVNCX1BST0RVQ1RfREVMT1JNRV9FQVJUSE1BVEUs DQogCUFOWSwgeyBVUV9ISURfSUdOT1JFIH19LA0KICB7IFVTQl9WRU5ET1JfSVRVTkVSTkVULCBV U0JfUFJPRFVDVF9JVFVORVJORVRfVVNCTENEMlgyMCwNCkluZGV4OiBzcmMvc3lzL2Rldi91c2Iv dXNiZGV2cw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9kZXYvdXNi L3VzYmRldnMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjMyOC4yLjEuMi4xDQpkaWZmIC11IC1y MS4zMjguMi4xLjIuMSB1c2JkZXZzDQotLS0gc3JjL3N5cy9kZXYvdXNiL3VzYmRldnMJNyBKYW4g MjAwOCAyMzoxMjo0NSAtMDAwMAkxLjMyOC4yLjEuMi4xDQorKysgc3JjL3N5cy9kZXYvdXNiL3Vz YmRldnMJMjYgQXVnIDIwMDggMTc6NDQ6MDkgLTAwMDANCkBAIC0zNjQsNiArMzY0LDcgQEANCiB2 ZW5kb3IgRElHSVRBTFNUUkVBTQkweDA3NGUJRGlnaXRhbCBTdHJlYW0NCiB2ZW5kb3IgQVVSRUFM CQkweDA3NTUJQXVyZWFsIFNlbWljb25kdWN0b3INCiB2ZW5kb3IgTUlESU1BTgkJMHgwNzYzCU1p ZGltYW4NCit2ZW5kb3IgQ1lCRVJQT1dFUgkweDA3NjQJQ3liZXIgUG93ZXIgU3lzdGVtcywgSW5j Lg0KIHZlbmRvciBTVVJFQ09NCQkweDA3NjkJU3VyZWNvbSBUZWNobm9sb2d5DQogdmVuZG9yIExJ TktTWVMyCQkweDA3N2IJTGlua3N5cw0KIHZlbmRvciBHUklGRklOCQkweDA3N2QJR3JpZmZpbiBU ZWNobm9sb2d5DQpAQCAtMTA1Niw2ICsxMDU3LDkgQEANCiBwcm9kdWN0IENVUklURUwgSFg1N1hC CQkweDIxMDEJQ0RNQSAyMDAwIDF4UlRUIFVTQiBtb2RlbSAoSFgtNTcwLzU3NUIvUFItNjAwKQ0K IHByb2R1Y3QgQ1VSSVRFTCBQQzU3NDAJCTB4MzcwMQlCcm9hZGJhbmQgV2lyZWxlc3MgbW9kZW0N CiANCisvKiBDeWJlclBvd2VyIHByb2R1Y3RzICovDQorcHJvZHVjdCBDWUJFUlBPV0VSIDE1MDBD QVZSTENECTB4MDUwMQkxNTAwQ0FWUkxDRA0KKw0KIC8qIEN5YmVyVEFOIFRlY2hub2xvZ3kgcHJv ZHVjdHMgKi8NCiBwcm9kdWN0IENZQkVSVEFOIFRHNTRVU0IJMHgxNjY2CVRHNTRVU0INCiANCg== --=-NPzv00iMx66t2hTUfOpS-- From Daan at VEHosting.nl Wed Aug 27 11:40:04 2008 From: Daan at VEHosting.nl (Daan Vreeken [PA4DAN]) Date: Wed Aug 27 11:40:15 2008 Subject: usb/126884: [patch] Bug in buffer handling in ugen.c Message-ID: <200808271058.m7RAwd0P043130@TVlottePert.VEHosting.nl> >Number: 126884 >Category: usb >Synopsis: [patch] Bug in buffer handling in ugen.c >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: Wed Aug 27 11:40:02 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Daan Vreeken [PA4DAN] >Release: FreeBSD 7.0-STABLE amd64 >Organization: VEHosting.nl >Environment: System: FreeBSD TVlottePert.VEHosting.nl 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Jun 13 18:02:09 CEST 2008 root@TVlottePert.VEHosting.nl:/usr/obj/usr/src/sys/GENERIC amd64 >Description: In ugen_isoc_rintr() old data is thrown away when the fifo is full. This code contains multiple errors : o Only in the case of sce->fill < sce->cur data is thrown away. (No data is discarded when sce->fill is near the end of the buffer and sce->cur is near the beginning of the buffer.) o Too much data is discarded. If 10 bytes need to be written with only space left for 8 bytes, 10 bytes of input are discarded instead of just 2. o When sce->cur reaches/passes the end of the buffer, the pointer is set to sce->ibuf + (sce->limit - sce->cur) instead of to sce->ibuf + (sce->cur - sce->limit). This could leave the sce->cur pointer ahead of the buffer pointing to unknown memory. >How-To-Repeat: Try to use the ugen interface to read data from a device with an isochronous endpoint that delivers isochronous packets of varying length and see that data gets corrupted. >Fix: The attached patch is to -CURRENT, but the bug is found in other branches too. The patch moves the deletion of data into the while loop that copies data from the incoming packet. This way data is also discarded in the case where sce->fill >= sce->cur initially (because the while loop already breaks filling the end & beginning of the buffer into two itterations). --- ugen.c.patch begins here --- --- ugen.c-1.112 2008-08-27 11:48:37.000000000 +0200 +++ ugen.c 2008-08-27 12:08:10.000000000 +0200 @@ -1054,15 +1054,6 @@ DPRINTFN(5,("ugen_isoc_rintr: xfer %td, count=%d\n", req - sce->isoreqs, count)); - /* throw away oldest input if the buffer is full */ - if(sce->fill < sce->cur && sce->cur <= sce->fill + count) { - sce->cur += count; - if(sce->cur >= sce->limit) - sce->cur = sce->ibuf + (sce->limit - sce->cur); - DPRINTFN(5, ("ugen_isoc_rintr: throwing away %d bytes\n", - count)); - } - isize = UGETW(sce->edesc->wMaxPacketSize); for (i = 0; i < UGEN_NISORFRMS; i++) { u_int32_t actlen = req->sizes[i]; @@ -1071,6 +1062,22 @@ /* copy data to buffer */ while (actlen > 0) { n = min(actlen, sce->limit - sce->fill); + + /* throw away oldest input if the buffer is full */ + if(sce->fill < sce->cur && + sce->cur <= sce->fill + n) { + u_int32_t drop; + + /* calculate fow many bytes we have to drop */ + drop = scr->cur - sce->fill; + + sce->cur += drop; + if(sce->cur >= sce->limit) + sce->cur = sce->ibuf; + DPRINTFN(5, ("ugen_isoc_rintr: throwing " + "away %d bytes\n", drop)); + } + memcpy(sce->fill, buf, n); buf += n; --- ugen.c.patch ends here --- >Release-Note: >Audit-Trail: >Unformatted: From tarn at xnets.co.za Wed Aug 27 18:10:03 2008 From: tarn at xnets.co.za (Tarn Alcock) Date: Wed Aug 27 18:10:16 2008 Subject: kern/126848: [usb]: USB Keyboard hangs during Installation Message-ID: <200808271810.m7RIA2qG056069@freefall.freebsd.org> The following reply was made to PR kern/126848; it has been noted by GNATS. From: "Tarn Alcock" To: , Cc: Subject: Re: kern/126848: [usb]: USB Keyboard hangs during Installation Date: Wed, 27 Aug 2008 19:09:08 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C90878.61CFDD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI. Thanks for the prompt response. I have tried both USB ports. Problem = still occures with both of them. I have noticed that htey keyboard = lights flash as the keyboard is detected and then i think that is when = it dies. ------=_NextPart_000_0002_01C90878.61CFDD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
HI. Thanks for the prompt response. I = have tried=20 both USB ports. Problem still occures with both of them. I have noticed = that=20 htey keyboard lights flash as the keyboard is detected and then i think = that is=20 when it dies.
------=_NextPart_000_0002_01C90878.61CFDD00-- From stone.creek.114 at gmail.com Wed Aug 27 21:44:55 2008 From: stone.creek.114 at gmail.com (C Hwang) Date: Wed Aug 27 21:45:02 2008 Subject: make error after add 'device zyd' into MYKERNEL Message-ID: <42877e8a0808271419v5e68c79alae4c9dc080dbec02@mail.gmail.com> Hi There, My first post! I install a fresh 7.0 release a week ago. I get two wireless USB adapter from Frys'. One is Linksys WUSB54GC which is working beautifully( I love Linksys). The 2nd USB adapter is Trendnet TEW-424UB. I want to add this device into the kernel so I add a line in MYKERNEL(derive from /usr/src/sys/i386/conf/GENERIC, make work with GENERIC) device zyd #for Trendnet TEW-424U. I also add a line in /usr/src/sys/conf/files (make can find the device without complain) dev/usb/if_zyd optional zyd then do #make buildkernel KERNCONF=MYKERNEL The make process good all the way to if_rum.c but fail at if_zyd.c there is a long error list but it seems all related to the same thing so I will just list it what I think is enough. printout of the make: ====================================================== ....before this all good cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissin g-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions - nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -i nclude opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-f unction-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mn o-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /usr/src/sys/dev/usb/if_rum.c cc -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-p rototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nos tdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -incl ude opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-func tion-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-s se -mno-sse2 -mno-sse3 -ffreestanding /usr/src/sys/dev/usb/if_zyd.c -o /usr/src/sys/dev/usb/if_z yd /usr/lib/crt1.o(.text+0x85): In function `_start': : undefined reference to `main' /var/tmp//ccwgxp7Y.o(.text+0xf7): In function `zyd_free_rx_list': /usr/src/sys/dev/usb/if_zyd.c:652: undefined reference to `usbd_free_xfer' /var/tmp//ccwgxp7Y.o(.text+0x129): In function `zyd_cmd': /usr/src/sys/dev/usb/if_zyd.c:760: undefined reference to `usbd_alloc_xfer' /var/tmp//ccwgxp7Y.o(.text+0x1e0):/usr/src/sys/dev/usb/if_zyd.c:776: undefined reference to `usbd_ setup_xfer' /var/tmp//ccwgxp7Y.o(.text+0x1eb):/usr/src/sys/dev/usb/if_zyd.c:778: undefined reference to `usbd_ transfer' ================================================== I notice that there is an -o /usr/src/sys/dev/usb/if_zyd for compiler option. I don't know why it will use different compiler option for this module. I can do make at /usr/src/sys/modules/zyd and generate if_zyd.ko. I can maually load it with kldload ./if_zyd.ko and see it with kldstat. It can not be seen by ifconfig zyd0. I have been spend about two day to mess around the if_zyd.c, /usr/src/sys/NOTES,GENERIC.hint, /usr/src/sys/modules/Makefile, /usr/src/sys/dev/usb/usbdevs None change the result of make error. Someone has experience on adding zyd into kernel with this make problem? I read some other post it seems that there are more work need to be done but I don't think it will make compile error like this. Thanks, Ching From ws at au.dyndns.ws Thu Aug 28 04:40:14 2008 From: ws at au.dyndns.ws (Wayne Sierke) Date: Thu Aug 28 04:40:21 2008 Subject: kern/126848: [usb]: USB Keyboard hangs during Installation In-Reply-To: <200808271810.m7RIA2qG056069@freefall.freebsd.org> References: <200808271810.m7RIA2qG056069@freefall.freebsd.org> Message-ID: <1219897491.49053.256.camel@predator-ii.buffyverse> On Wed, 2008-08-27 at 18:10 +0000, Tarn Alcock wrote: > The following reply was made to PR kern/126848; it has been noted by GNATS. > > From: "Tarn Alcock" > To: , > > Cc: > Subject: Re: kern/126848: [usb]: USB Keyboard hangs during Installation > Date: Wed, 27 Aug 2008 19:09:08 +0200 > > This is a multi-part message in MIME format. > > ------=_NextPart_000_0002_01C90878.61CFDD00 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > HI. Thanks for the prompt response. I have tried both USB ports. Problem = > still occures with both of them. I have noticed that htey keyboard = > lights flash as the keyboard is detected and then i think that is when = > it dies. Probably a long-shot. My Gigabyte 8SQ800 has a problem with my Logitech MX500 mice and more recently with a Logitech USB keyboard. I've had to connect both of these via a hub to avoid frequent disconnects that occur when they are connected directly to the motherboard's USB ports. Not as severe as your issue but might be worth a shot. From on at cs.ait.ac.th Thu Aug 28 08:17:40 2008 From: on at cs.ait.ac.th (Olivier Nicole) Date: Thu Aug 28 08:17:49 2008 Subject: How to eject an USB disk on FreeBSD Message-ID: <200808280746.m7S7kuJV018511@banyan.cs.ait.ac.th> Hello, Is there a command in FreeBSD that ejects a USB disk like in Windows? I mount the USB disk with automount daemone (amd). I have a script that access this disk and force an umount at the end of the script. But anyone accessing the disk will have amd re'mount the disk and at the time I unplu the disk, problem may occur because the disk is still mounted and in use. I would like to have a command that makes the disk/USB port physically inaccessible, so at the end of the script a user cannot access the disk again. Like in Windows after stopping a USB mass storage device, one has to unplg and replug the disk if he wants to access it again. TIA, Olivier From maxim at FreeBSD.org Thu Aug 28 13:40:01 2008 From: maxim at FreeBSD.org (maxim@FreeBSD.org) Date: Thu Aug 28 13:40:15 2008 Subject: usb/96599: [usb] [patch] Sony Handycam DCR-HC32E memory stick slot Message-ID: <200808281340.m7SDe0P0093409@freefall.freebsd.org> Synopsis: [usb] [patch] Sony Handycam DCR-HC32E memory stick slot State-Changed-From-To: open->closed State-Changed-By: maxim State-Changed-When: Thu Aug 28 13:39:30 UTC 2008 State-Changed-Why: Committed to HEAD and RELENG_7. http://www.freebsd.org/cgi/query-pr.cgi?pr=96599 From hselasky at c2i.net Thu Aug 28 16:10:02 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Thu Aug 28 16:10:13 2008 Subject: How to eject an USB disk on FreeBSD In-Reply-To: <200808280746.m7S7kuJV018511@banyan.cs.ait.ac.th> References: <200808280746.m7S7kuJV018511@banyan.cs.ait.ac.th> Message-ID: <200808281811.46885.hselasky@c2i.net> On Thursday 28 August 2008, Olivier Nicole wrote: > Hello, > > Is there a command in FreeBSD that ejects a USB disk like in Windows? > > I mount the USB disk with automount daemone (amd). > > I have a script that access this disk and force an umount at the end > of the script. > > But anyone accessing the disk will have amd re'mount the disk and at > the time I unplu the disk, problem may occur because the disk is still > mounted and in use. > > I would like to have a command that makes the disk/USB port physically > inaccessible, so at the end of the script a user cannot access the > disk again. > > Like in Windows after stopping a USB mass storage device, one has to > unplg and replug the disk if he wants to access it again. > Hi, Maybe the following will help: man camcontrol --HPS From hselasky at c2i.net Thu Aug 28 17:05:03 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Thu Aug 28 17:05:09 2008 Subject: How to eject an USB disk on FreeBSD In-Reply-To: <48B6D108.8010405@vicor.com> References: <200808280746.m7S7kuJV018511@banyan.cs.ait.ac.th> <200808281811.46885.hselasky@c2i.net> <48B6D108.8010405@vicor.com> Message-ID: <200808281906.41700.hselasky@c2i.net> On Thursday 28 August 2008, Halit Canbazoglu wrote: > we, at vicor, use freebsd and redhat, it will be good for us > to be able to use the linux compatible interface for USB devices. > we still use FreeBSD 4.11, i wonder anybody is planning to > back port this new USB interface. since it's separated from the > earlier USB layer, i believe it might not be that hard, at the same > time not easy to say. > > thanks .. halit .. Hi, It might be some work to do the backport, but it is not impossible. Personally I have no plans to backport the code to FreeBSD 4.11. --HPS From halit at vicor.com Thu Aug 28 17:17:20 2008 From: halit at vicor.com (Halit Canbazoglu) Date: Thu Aug 28 17:17:26 2008 Subject: How to eject an USB disk on FreeBSD In-Reply-To: <200808281811.46885.hselasky@c2i.net> References: <200808280746.m7S7kuJV018511@banyan.cs.ait.ac.th> <200808281811.46885.hselasky@c2i.net> Message-ID: <48B6D108.8010405@vicor.com> we, at vicor, use freebsd and redhat, it will be good for us to be able to use the linux compatible interface for USB devices. we still use FreeBSD 4.11, i wonder anybody is planning to back port this new USB interface. since it's separated from the earlier USB layer, i believe it might not be that hard, at the same time not easy to say. thanks .. halit .. -- Halit Canbazoglu | Senior Engineer 510-621-2196(work) | 510-621-2020(fax) halit@vicor.com | VICOR, a Metavante Company This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. From gavin at FreeBSD.org Thu Aug 28 21:20:02 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Thu Aug 28 21:20:08 2008 Subject: usb/126927: [zyd] [patch] Support ZyDAS G202 Message-ID: <200808282116.m7SLGS4C050741@buffy.york.ac.uk> >Number: 126927 >Category: usb >Synopsis: [zyd] [patch] Support ZyDAS G202 >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 Aug 28 21:20:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Gavin Atkinson >Release: FreeBSD 7.0-STABLE amd64 >Organization: >Environment: System: FreeBSD buffy.york.ac.uk 7.0-STABLE FreeBSD 7.0-STABLE #3: Fri Jun 20 09:21:51 UTC 2008 root@buffy.york.ac.uk:/usr/obj/usr/src/sys/GENERIC amd64 >Description: Add support for the USB dongle I've got in my hand >How-To-Repeat: Take adapter out of my hand. Plug adapter into my laptop. >Fix: --- zyd_g202.diff begins here --- Index: src/sys/dev/usb/if_zyd.c =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/if_zyd.c,v retrieving revision 1.18 diff -u -r1.18 if_zyd.c --- src/sys/dev/usb/if_zyd.c 7 Jun 2008 18:38:02 -0000 1.18 +++ src/sys/dev/usb/if_zyd.c 13 Aug 2008 17:29:35 -0000 @@ -140,6 +140,7 @@ ZYD_ZD1211B_DEV(VTECH, ZD1211B), ZYD_ZD1211B_DEV(ZCOM, ZD1211B), ZYD_ZD1211B_DEV(ZYDAS, ZD1211B), + ZYD_ZD1211B_DEV(ZYXEL, G202), ZYD_ZD1211B_DEV(ZYXEL, M202), ZYD_ZD1211B_DEV(ZYXEL, G220V2), }; Index: src/sys/dev/usb/usbdevs =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.367 diff -u -r1.367 usbdevs --- src/sys/dev/usb/usbdevs 21 Aug 2008 20:37:38 -0000 1.367 +++ src/sys/dev/usb/usbdevs 28 Aug 2008 20:12:09 -0000 @@ -2440,3 +2440,4 @@ product ZYXEL AG225H 0x3409 AG-225H product ZYXEL M202 0x340a M-202 product ZYXEL G220V2 0x340f G-220 v2 +product ZYXEL G202 0x3410 G-202 --- zyd_g202.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: From artis.caune at gmail.com Fri Aug 29 09:30:04 2008 From: artis.caune at gmail.com (Artis Caune) Date: Fri Aug 29 09:30:11 2008 Subject: kern/126848: [usb]: USB Keyboard hangs during Installation Message-ID: <200808290930.m7T9U340029671@freefall.freebsd.org> The following reply was made to PR kern/126848; it has been noted by GNATS. From: "Artis Caune" To: bug-followup@FreeBSD.org Cc: f0ng@hotmail.com Subject: Re: kern/126848: [usb]: USB Keyboard hangs during Installation Date: Fri, 29 Aug 2008 12:28:58 +0300 could you try with: set hint.kbdmux.0.disabled="1" -- regards, Artis Caune <----. CCNA <----|==================== <----' didii FreeBSD