issue with usb hdd
hi there, i recently bought a western digital 1 terrabyte usb2/usb3 hdd: [83611.209514] umass0: MSC Bulk-Only Transport on usbus3 [83613.618514] da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 [83613.618514] da0: WD My Passport 0740 1003 Fixed Direct Access SCSI-6 device [83613.618514] da0: 40.000MB/s transfers [83613.618514] da0: 953837MB (1953458176 512 byte sectors: 255H 63S/T 121597C) i partitioned it via the gpt scheme and one big ufs2 partition with SU+J enabled: Geom name: da0 modified: false state: OK fwheads: 255 fwsectors: 63 last: 1953458142 first: 34 entries: 128 scheme: GPT Providers: 1. Name: da0p1 Mediasize: 1000170551808 (931G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 17408 Mode: r0w0e0 rawuuid: 39d3bf09-fb47-11e0-ade1-000fb58207c8 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: (null) length: 1000170551808 offset: 17408 type: freebsd-ufs index: 1 end: 1953458142 start: 34 Consumers: 1. Name: da0 Mediasize: 1000170586112 (931G) Sectorsize: 512 Mode: r0w0e0 =34 1953458109 da0 GPT (931G) 34 19534581091 freebsd-ufs (931G) tunefs: POSIX.1e ACLs: (-a)disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f)16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) wd mounting and everything works great. however if i don't access the monted hdd for a couple of hours, and then do `ls /mnt/wd`, nothing is there. `mount -p` reports that the hdd is still mounted: /dev/ufs/rootfs / ufs ro 1 1 devfs /devdevfs rw 0 0 /dev/ufs/varfs /varufs rw 1 2 /dev/ufs/usrfs /usrufs rw 1 2 linprocfs /usr/compat/linux/proc linprocfs rw 0 0 linsysfs/usr/compat/linux/sys linsysfsrw 0 0 devfs /usr/compat/linux/dev devfs rw 0 0 linprocfs /usr/local/gentoo-stage3/proc linprocfs rw 0 0 linsysfs/usr/local/gentoo-stage3/sys linsysfs rw 0 0 devfs /usr/local/gentoo-stage3/dev devfs rw 0 0 tmpfs /tmptmpfs rw 0 0 tmpfs /var/tmptmpfs rw 0 0 /dev/ufs/wd /mnt/wd ufs rw,noexec,nosuid 0 0 `pwd` executed will return ENXIO. i can then do `umount /mnt/wd`, but re-mounting the hdd fails with the following dmesg warnings: [96836.840512] (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 0 0 0 0 0 [96836.840512] (probe0:umass-sim0:0:0:1): CAM status: SCSI Status Error [96836.840512] (probe0:umass-sim0:0:0:1): SCSI status: Check Condition [96836.840512] (probe0:umass-sim0:0:0:1): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) [97109.824517] WARNING: R/W mount of /mnt/wd denied. Filesystem is not clean - run fsck [97109.824517] WARNING: Forced mount will invalidate journal contents [97126.200518] WARNING: R/W mount of /mnt/wd denied. Filesystem is not clean - run fsck [97126.200518] WARNING: Forced mount will invalidate journal contents [97129.283518] WARNING: R/W mount of /mnt/wd denied. Filesystem is not clean - run fsck [97129.283518] WARNING: Forced mount will invalidate journal contents [97133.904518] WARNING: R/W mount of /mnt/wd denied. Filesystem is not clean - run fsck [97133.904518] WARNING: Forced mount will invalidate journal contents (i believe the probe0 stuff is from the umount) `mount` fails with EPERM btw. what i have to do is: `fsck /dev/ufs/wd`. this complains about the following: ** /dev/ufs/wd USE JOURNAL? [yn] y ** SU+J Recovering /dev/ufs/wd ** Reading 33554432 byte journal from inode 4. RECOVER? [yn] y ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. * FILE SYSTEM MARKED CLEAN * ...now everything is back to normal and i can mount the hdd again. any suggestions? i'm running a very recent HEAD on amd64. cheers. alex ___ freebsd-usb@freebsd.org mailing list
Re: usb/161793: poor EHCI usb2 i/o performance
On Wed Oct 19 11, Hans Petter Selasky wrote: The following reply was made to PR usb/161793; it has been noted by GNATS. From: Hans Petter Selasky hsela...@c2i.net To: freebsd-usb@freebsd.org Cc: Chargen char...@gmail.com, freebsd-gnats-sub...@freebsd.org Subject: Re: usb/161793: poor EHCI usb2 i/o performance Date: Wed, 19 Oct 2011 07:55:50 +0200 Hello, When testing and formatting, it is important to set the block size to 65536 bytes to get the maximum performance. The default blocksize of dd is 512 bytes, and there is no read-ahead! Try again using: dd if=/dev/daX of=/dev/null bs=65536. results here are: otaku% dd if=/dev/da0 of=/dev/null bs=65536 30495+1 records in 30495+1 records out 1998585344 bytes transferred in 159.388494 secs (12539082 bytes/sec) otaku% dd if=/dev/da0 of=/dev/null bs=65536 238033+1 records in 238033+1 records out 15599771136 bytes transferred in 655.616437 secs (23794051 bytes/sec) testing an old usb stick and a fairly recent one. that's with usb2 and running HEAD. the results are incredible imo. my usb controller is Intel 82801I (ICH9) USB 2.0 controller cheers. alex Thank you, --HPS On Wednesday 19 October 2011 05:41:16 Chargen wrote: Number: 161793 Category: usb Synopsis: poor EHCI usb2 i/o performance 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 Oct 19 03:50:03 UTC 2011 Closed-Date: Last-Modified: Originator: Chargen Release:10.0-CURRENT Organization: Environment: FreeBSD schwarzesonne 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Tue Oct 18 21:40:49 CEST 2011 chargen@schwarzesonne:/usr/src/sys/i386/compile/SCHWARZESONNE i386 Description: I did some OHCI/EHCI usb1/2 subsystem performance checks on CURRENT with 1 older generation 1gb USB memory stick and a newer 2GB USB memory stick. EHCI, usb2 UFS or MSDOSFS formatted gives about the same performance in FreeBSD, ~3MB/s and about 8~10 MB/s under Windows operating systems using the same hardware. schwarzesonne# usbconfig dump_info | grep 480 ugen2.1: EHCI root HUB NEC at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE schwarzesonne# dmesg | grep usbus2 usbus2: EHCI version 1.0 usbus2: NEC uPD 720100 USB 2.0 controller on ehci0 usbus2: 480Mbps High Speed USB v2.0 ugen2.1: NEC at usbus2 uhub2: NEC EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus2 ugen2.2: Generic at usbus2 umass0: Generic Mass Storage, class 0/0, rev 2.00/1.41, addr 2 on usbus2 schwarzesonne# mount /dev/da0p2 on / (ufs, local, noatime, journaled soft-updates) devfs on /dev (devfs, local) schwarzesonne# dmesg | grep da1 da1 at umass-sim0 bus 0 scbus4 target 0 lun 0 da1: A60C0705 Flash Disk 8.07 Removable Direct Access SCSI-2 device da1: 40.000MB/s transfers da1: 999MB (2047998 512 byte sectors: 64H 32S/T 999C) schwarzesonne# time dd if=/dev/zero of=/dev/da1 count=2 2+0 records in 2+0 records out 1024 bytes transferred in 0.003543 secs (289029 bytes/sec) 0.000u 0.002s 0:00.02 0.0% 0+0k 0+2io 0pf+0w schwarzesonne# ls -alrt /dev/da1* crw-r- 1 root operator 0x55 Oct 19 03:01 /dev/da1 crw-r- 1 root operator 0x62 Oct 19 03:01 /dev/da1s1 crw-r- 1 root operator 0x72 Oct 19 03:02 /dev/da1s1a schwarzesonne# fdisk -vBI /dev/da1 *** Working on device /dev/da1 *** fdisk: invalid fdisk partition table found parameters extracted from in-core disklabel are: cylinders=999 heads=64 sectors/track=32 (2048 blks/cyl) parameters to be used for BIOS calculations are: cylinders=999 heads=64 sectors/track=32 (2048 blks/cyl) Information from DOS bootblock is: 1: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 32, size 2045920 (998 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 998/ head 63/ sector 32 2: UNUSED 3: UNUSED 4: UNUSED fdisk: Class not found schwarzesonne# bsdlabel -w da1s1 schwarzesonne# time newfs -O 1 /dev/da1s1a /dev/da1s1a: 999.0MB (2045904 sectors) block size 32768, fragment size 4096 using 4 cylinder groups of 249.75MB, 7992 blks, 16128 inodes. super-block backups (for fsck -b #) at: 64, 511552, 1023040, 1534528 0.005u 0.015s 0:06.25 0.1% 128+15616k 6+260io 0pf+0w schwarzesonne# mkdir /mnt/usb schwarzesonne# mount -v /dev/da1s1a /mnt/usb/ /dev/da1s1a on /mnt (ufs, local, fsid 66279e4eff2fa382) schwarzesonne# time dd if=/dev/zero bs=1m count=500 /mnt/usb/500mb 500+0 records in 500+0 records out 524288000 bytes transferred in 106.844333 secs (4907027 bytes/sec) 0.007u 1.813s 1:46.85 1.6% 28+5603k 5+4006io 0pf+0w : rebooted to flush
Re: Problem with mouse during high CPU load
On Fri Mar 18 11, Anonymous wrote: Alexander Best arun...@freebsd.org writes: i've reported this issue quite a while ago [1], but back then nobody was able to help me. i have an issue with my usb mouse. when there's a high CPU load it produces random mouse clicks. this doesn't happen on other OSes. i've attached a different usb mouse to my freebsd box and i could't observe the same behavior. so it seems this problem is only related to specific mice. I'm curious, can you reproduce it without moused(8), i.e. specifying /dev/umsN in xorg.conf rather than /dev/sysmouse. after restarting hald and removing all input sections from my xorg.conf i'm now able to use both mouse and keyboard via hald in X. so it seems moused(8) is clearly to blame for the random clicks during high CPU load and/or fast mouse movements. thanks again for the pointer. :) cheers. alex This may be unrelated but my mx518 mouse produces random clicks when I move it very quickly and using moused(8), no clicks when not. back then hps@ guessed that my mouse requires a certain polling rate from the host. during high cpu load the host couldn't keep up the polling rate and thus the mouse starts producing wrong output. -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: restore(8) to USB key: terrible slow
On Wed Nov 17 10, Hans Petter Selasky wrote: On Wednesday 17 November 2010 14:39:14 Matthias Apitz wrote: El día Wednesday, November 17, 2010 a las 01:14:19PM +0100, Hans Petter Selasky escribió: after around 90 minutes of restore the taget file system says 19 MByte used (i.e restored): $ df -kh /mnt Filesystem SizeUsed Avail Capacity Mounted on /dev/da0s1a3.6G 19M3.3G 1%/mnt What is wrong with this? If this does matter: 8-CURRENT. Thanks matthias Hi, Maybe you get some answers from: sysctl hw.usb.umass.debug=-1 Kernel needs to be compiled with: options USB_DEBUG Thanks; I have to build a kernel for this ... When I write the key just with dd(1) it performs normal with big blocks: # dd if=/home/guru/usb9root.dmp of=/dev/da0 bs=1m count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 16.650550 secs (6297546 bytes/sec) and slow with 512 byte blocks: # dd if=/home/guru/usb9root.dmp of=/dev/da0 count=100 100+0 records in 100+0 records out 51200 bytes transferred in 1.997130 secs (25637 bytes/sec) any idea or do we need the debug output? matthias What block size does the dump utility use? dump(8) says 10k. --HPS -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/138548: [usb67] [usb8] usb devices periodically have unknown activity
On Mon Nov 15 10, Andriy Gapon wrote: The following reply was made to PR usb/138548; it has been noted by GNATS. From: Andriy Gapon a...@freebsd.org To: bug-follo...@freebsd.org, yeren...@gmail.com Cc: Subject: Re: usb/138548: [usb67] [usb8] usb devices periodically have unknown activity Date: Mon, 15 Nov 2010 10:50:19 +0200 BTW, just a guess, the source of activity could be hald. good point! :) Alexander, could you please try the following before plugging in the usb device: /usr/local/etc/rc.d/hald stop does that solve the 'blinking' issue? cheers. alex -- Andriy Gapon -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
usb/130230: [patch] [quirk] [usb67] [usb] [cam] [umass] Samsung Electronics YP-U3 does not attach in 7.1-RELEASE
The following reply was made to PR usb/130230; it has been noted by GNATS.
From: Alexander Best arun...@freebsd.org
To: bug-follo...@freebsd.org
Cc:
Subject: usb/130230: [patch] [quirk] [usb67] [usb] [cam] [umass] Samsung
Electronics YP-U3 does not attach in 7.1-RELEASE
Date: Sat, 13 Nov 2010 14:03:15 +
--Nq2Wo0NMKNjxTN9z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
could you please try the first patch and see if that lets you use your device
without any manual quirks?
if that works it would be nice if you could also try the second patch. maybe
the existing scsi quirks aren't necessary anymore. this is just a guess
however. if your device stops working after you've applied the second patch,
please revert it and only use the first patch.
cheers.
alex
--
a13x
--Nq2Wo0NMKNjxTN9z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=yp-u3.diff1
diff --git a/sys/dev/usb/quirk/usb_quirk.c b/sys/dev/usb/quirk/usb_quirk.c
index 6691538..15611c3 100644
--- a/sys/dev/usb/quirk/usb_quirk.c
+++ b/sys/dev/usb/quirk/usb_quirk.c
@@ -332,6 +332,8 @@ static struct usb_quirk_entry
usb_quirks[USB_DEV_QUIRKS_MAX] = {
USB_QUIRK_VP(USB_VENDOR_SAMSUNG_TECHWIN,
USB_PRODUCT_SAMSUNG_TECHWIN_DIGIMAX_410, UQ_MSC_FORCE_WIRE_BBB,
UQ_MSC_FORCE_PROTO_SCSI, UQ_MSC_NO_INQUIRY),
+ USB_QUIRK(SAMSUNG, YP_U3, 0x, 0x, UQ_MSC_NO_INQUIRY,
+ UQ_MSC_NO_SYNC_CACHE),
USB_QUIRK(SAMSUNG, YP_U4, 0x, 0x, UQ_MSC_NO_SYNC_CACHE),
USB_QUIRK(SANDISK, SDDR05A, 0x, 0x, UQ_MSC_FORCE_WIRE_CBI,
UQ_MSC_FORCE_PROTO_SCSI, UQ_MSC_READ_CAP_OFFBY1,
diff --git a/sys/dev/usb/usbdevs b/sys/dev/usb/usbdevs
index 404ec18..dc92093 100644
--- a/sys/dev/usb/usbdevs
+++ b/sys/dev/usb/usbdevs
@@ -2773,6 +2773,7 @@ product SAGEM XG76NA 0x0062 XG-76NA
/* Samsung products */
product SAMSUNG ML60600x3008 ML-6060 laser printer
product SAMSUNG YP_U2 0x5050 YP-U2 MP3 Player
+product SAMSUNG YP_U3 0x507c YP-U3 MP3 Player
product SAMSUNG YP_U4 0x5092 YP-U4 MP3 Player
product SAMSUNG I500 0x6601 I500 Palm USB Phone
product SAMSUNG I330 0x8001 I330 phone cradle
--Nq2Wo0NMKNjxTN9z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=yp-u3.diff2
diff --git a/sys/cam/scsi/scsi_da.c b/sys/cam/scsi/scsi_da.c
index b3b968c..29e1641 100644
--- a/sys/cam/scsi/scsi_da.c
+++ b/sys/cam/scsi/scsi_da.c
@@ -545,14 +545,6 @@ static struct da_quirk_entry da_quirk_table[] =
*}, /*quirks*/ DA_Q_NO_SYNC_CACHE
},
{
- /*
- * Samsung YP-U3 mp3-player
- * PR: 125398
- */
- {T_DIRECT, SIP_MEDIA_REMOVABLE, Samsung, YP-U3,
- *}, /*quirks*/ DA_Q_NO_SYNC_CACHE
- },
- {
{T_DIRECT, SIP_MEDIA_REMOVABLE, Netac, OnlyDisk*,
2000}, /*quirks*/ DA_Q_NO_SYNC_CACHE
},
--Nq2Wo0NMKNjxTN9z--
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/142276: [umass] [usb8] Cache Synchronization Error with Olympus FE210 Camera
The following reply was made to PR usb/142276; it has been noted by GNATS. From: Alexander Best arun...@freebsd.org To: bug-follo...@freebsd.org Cc: Subject: Re: usb/142276: [umass] [usb8] Cache Synchronization Error with Olympus FE210 Camera Date: Sat, 13 Nov 2010 15:02:30 + could you try the following quirk with usbconfig: UQ_MSC_NO_SYNC_CACHE cheers. alex -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/138570: [usb67] [panic] USB mass device panics current 7.2-STABLE
On Sat Nov 13 10, Jens Rehsack wrote: 2010/11/13 arun...@freebsd.org: Old Synopsis: [usb] [panic] USB mass device panics current 7.2-STABLE New Synopsis: [usb67] [panic] USB mass device panics current 7.2-STABLE State-Changed-From-To: open-feedback State-Changed-By: arundel State-Changed-When: Sat Nov 13 14:33:29 UTC 2010 State-Changed-Why: Does this panic also occur with a more recent stable snapshot? I'm on the road for jobs and can't test again (to busy and no time to restore the machine in case of a panic destroys something). I moved most tasks away from the FSBD machine meanwhile, from my point of view this PR can be closed (no feedback from reporter), because I can confirm that I don't have time to take care the next 6 month. thanks for your help. i've suspended the PR. i'll close it once 7.x goes EoL, since i don't think this issue occurs under the new USb stack (FreeBSD 8.x). cheers. alex Have you tried the device under FreBSD 8.x? No - but on NetBSD 5-CURRENT and Ubuntu 10.04, and it works fine there. Best regards, Jens http://www.freebsd.org/cgi/query-pr.cgi?pr=138570 -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/108344: [usb67] [atausb] [panic] kernel with atausb panics when unplugging USB Flash
The following reply was made to PR usb/108344; it has been noted by GNATS. From: Alexander Best arun...@freebsd.org To: bug-follo...@freebsd.org Cc: Subject: Re: usb/108344: [usb67] [atausb] [panic] kernel with atausb panics when unplugging USB Flash Date: Wed, 3 Nov 2010 11:12:04 + this pr can be closed once the 7.x branch goes EoL, since ata-usb support was removed in 8.x. cheers. alex -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usbconfig reset ugen4.2 hanging since an hour
On Tue Nov 2 10, Alexander Leidinger wrote: Quoting Alexander Motin m...@freebsd.org (from Tue, 02 Nov 2010 14:02:17 +0200): Alexander Leidinger wrote: Quoting Hans Petter Selasky hsela...@freebsd.org (from Tue, 2 Nov 2010 10:36:41 +0100): If you dump all threads in this state I think you will see that USB is waiting # procstat -kk 29213 PIDTID COMM TDNAME KSTACK 29213 100291 usbconfig-mi_switch+0x188 sleepq_switch+0x13c sleepq_timedwait+0x40 _sleep+0x320 pause+0x30 usb_pause_mtx+0x94 usb_ioctl+0x171 devfs_ioctl_f+0x73 kern_ioctl+0x9d ioctl+0xc5 syscallenter+0x1af syscall+0x34 Xint0x80_syscall+0x21 somewhere in umass_detach(), which is preventing the usbconfig reset from No umass_detach in there... umass_detach() (if there) should be in some other thread. Not here: ---snip--- # procstat -kka | grep umass_detach ---snip--- grabbing the SX-lock associated with serialisation. Because umass_detach() is not returning we are stuck. And there is no way to use some kind of timeout for cases which cause problem reports (like umass_detach() and maybe this one)? I could imagine several possibilities: usbconfig tries a trylock first (maybe several times) and if it does not succeed in a specified timeperiode, it returns an error. Adidtionally there is maybe the possibility to determine if a command did not finish in a given timeperiode and print out a warning message (syslog) to have an indication, that somthing is not in a good condition. Not sure what should it give. We should track the real problem, not the consequences. Possible reason could be that due to some error umass/CAM leaked some references, which made impossible to destroy CAM bus on stick disconnection. But to diagnose it we need much more info. Something I could provide? Some kdb magic I could copypaste? i believe you're experiencing the same i issue i have [1]. cheers. alex [1] http://www.mail-archive.com/freebsd-usb@freebsd.org/msg07599.html Bye, Alexander. -- Phosflink, v.: To flick a bulb on and off when it burns out (as if, somehow, that will bring it back to life). -- Rich Hall Friends, Sniglets http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: serious issue caused by usb device, stalling almost all operations
On Mon Oct 25 10, Alexander Motin wrote: Hans Petter Selasky wrote: On Wednesday 20 October 2010 17:30:40 Alexander Best wrote: hi there, i'm running HEAD (r213495; amd64). i stumbled upon this severe problem: after attaching my mobile phone, it simply resets without doing mount or anything. however after letting the device come up again it won't show up in the console. after detaching it the usb subsystem seemed to have completely crashed. but that's not all. the following programs now simply hang without producing any output C-C won't do anything: - dmesg - top - ps - killall - camcontrol devlist - usbconfig That's most likely because USB's umass driver is waiting for cam to drain. Possibly some refcounting is not correct. I suspect this is not a USB problem. Try to enter into the debugger, and look for backtrace for function stuck in umass_detach. i set debug.kdb.panic=1, but didn't work, because writing the core dump stalled and watchdog came up. any advice? cheers. alex It is a bit suspicious that problem happens only when device dies during request. Are you sure that running command was properly aborted when device got detached? Every running command has own set of references, denying detach. -- Alexander Motin -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
serious issue caused by usb device, stalling almost all operations
hi there, i'm running HEAD (r213495; amd64). i stumbled upon this severe problem: after attaching my mobile phone, it simply resets without doing mount or anything. however after letting the device come up again it won't show up in the console. after detaching it the usb subsystem seemed to have completely crashed. but that's not all. the following programs now simply hang without producing any output C-C won't do anything: - dmesg - top - ps - killall - camcontrol devlist - usbconfig i cannot even kill the apps, since top and ps aren't working so there's no way to find out the PIDs. using 'killall dmesg' e.g. won't work either, since killall will also stall. this is the console output which i could grab with 'vidcontrol -H -P /dev/ttyv0' (since dmesg doesn't work anymore): ugen3.3: Samsung at usbus3 umass0: USB Mass Storage Interface on usbus3 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to rea dy change, medium may have changed) da0 at umass-sim0 bus 0 scbus9 target 0 lun 0 da0: Samsung SGH-i550 1.0 Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3777MB (7736320 512 byte sectors: 255H 63S/T 481C) (da0:umass-sim0:0:0:0): AutoSense failed ugen3.3: Samsung at usbus3 (disconnected) umass0: at uhub8, port 3, addr 3 (disconnected) (da0:umass-sim0:0:0:0): AutoSense failed (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): Invalidating pack (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0xa, scsi status == 0x0 (da0:umass-sim0:0:0:0): removing device entry lock order reversal: 1st 0x80a37d50 GEOM topology (GEOM topology) @ /usr/src/sys/geom/label/ g_label.c:320 2nd 0x808387a0 sysctl lock (sysctl lock) @ /usr/src/sys/kern/kern_sysct l.c:257 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x35 kdb_backtrace() at kdb_backtrace+0x4e _witness_debugger() at _witness_debugger+0x29 witness_checkorder() at witness_checkorder+0xad2 _sx_xlock() at _sx_xlock+0xae sysctl_ctx_free() at sysctl_ctx_free+0x2e dacleanup() at dacleanup+0x65 camperiphfree() at camperiphfree+0x152 cam_periph_release_locked() at cam_periph_release_locked+0x84 cam_periph_release() at cam_periph_release+0x6d daclose() at daclose+0x223 g_disk_access() at g_disk_access+0x21c g_access() at g_access+0x3b7 g_label_taste() at g_label_taste+0x3be g_new_provider_event() at g_new_provider_event+0x145 one_event() at one_event+0x2d5 g_run_events() at g_run_events+0xe g_event_procbody() at g_event_procbody+0x8b fork_exit() at fork_exit+0xfd fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff83ecf0, rbp = 0 --- cheers. alex -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
fixing PR 130230
hi there,
this patch should fix PR 130230.
cheers.
alex
--
a13x
diff --git a/sys/cam/scsi/scsi_da.c b/sys/cam/scsi/scsi_da.c
index 7729ecc..7125c2a 100644
--- a/sys/cam/scsi/scsi_da.c
+++ b/sys/cam/scsi/scsi_da.c
@@ -547,9 +547,9 @@ static struct da_quirk_entry da_quirk_table[] =
{
/*
* Samsung YP-U3 mp3-player
-* PR: 125398
+* PR: 125398, 130230
*/
- {T_DIRECT, SIP_MEDIA_REMOVABLE, Samsung, YP-U3,
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, Samsung*, YP-U3*,
*}, /*quirks*/ DA_Q_NO_SYNC_CACHE
},
{
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB_VERBOSE and vendor-/productnames
On Tue Sep 14 10, Hans Petter Selasky wrote: On Tuesday 14 September 2010 02:20:17 Alexander Best wrote: hi there, a lot of people report issues where usbconfig doesn't show a vendor or device name, although an usbdevs entry exists. i found a few replies to those reports by hps@ stating that USB_VERBOSE needs to be enabled. could anybody explain why? if that option needs to be enabled in order to see vendor and device names in usbconfig how come that even without it i see most of the vendor and device names with usbconfig: Hi, The reason the option is not default, is that the verbose database consume a couple of hundred kilobytes. does usbdevs actually get compiled into the kernel if USB_VERBOSE has been defined? that would explain the extra size. why not do it like the pci database? simply add usbdevs to /usr/share/misc and look for entries in that file for each request. cheers. alex ugen0.1: UHCI root HUB Intel at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen1.1: UHCI root HUB Intel at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen2.1: UHCI root HUB Intel at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen3.1: EHCI root HUB Intel at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen4.1: UHCI root HUB Intel at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen5.1: UHCI root HUB Intel at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen6.1: UHCI root HUB Intel at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen7.1: EHCI root HUB Intel at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen3.2: product 0x2514 vendor 0x0424 at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen1.2: Dell USB Keyboard Dell at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen1.3: Razer 1600dpi Mouse Razer at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON my guess would be that these devices are missing the iManufacturer and/or iProduct string, but that's just a wild guess. if that is the case wouldn't it be possible to check for a usbdevs entry in case one of those strings don't exist and if there's an entry in usbdevs use it? i think the option USB_VERBOSE is not really accurate in this particular case. people who want usbconfig to output the vendor and product name actually want less verbosity (i.e. no product/vendor hex ids). I'm not sure if compiling this information into usbdevs will be any better. --HPS -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB_VERBOSE and vendor-/productnames
On Thu Sep 16 10, Nick Hibma wrote: From: http://www.linux-usb.org/usb-ids.html The contents of the database and the generated files can be distributed under the terms of either the GNU General Public License (version 2 or later) or of the 3-clause BSD License. Do you want me make this list available in our source tree? any progress on this task? ;) cheers. alex Steps: 1) Write a script to download it and convert it to our usbdevs*.h files. 2) Match the entries with our own and add usbdevs*_legacy.h for FBSD8 systems, so recompilation of existing drivers is straightforward. 3) Test. Review. Bikeshed. Rinse. Repeat. 4) Commit. Nick On 14 Sep 2010, at 22:31, Hans Petter Selasky wrote: On Tuesday 14 September 2010 22:25:46 Alexander Best wrote: also i've been wondering why freebsd keeps its own set of a usb device db? the databse at http://www.linux-usb.org/usb-ids.html seems very active. can't we just use a script to create usbdevs from that db? that's how pci ids are mapped to vendors/products on freebsd (see http://www.mail-archive.com/freebsd-curr...@freebsd.org/msg124948.html). If we don't have to GPL the resulting .h and .c files. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [USB] Keyboard, mouse and ergonomy
On Mon Sep 27 10, Hans Petter Selasky wrote: Hi, I was thinking about adding a sysctl to ukbd and ums that shows how many keypresses have been done and how many pixels you have moved the mouse during a day. These number will mostly be useful for making ergonomic arguments that a certain way of working is better than another one. Anyone have any comments or input on this? Are there any security concerns about this? i like the idea. :) would be nice if this could be turned on/off for ums and ukbd seperately. how about the kernel options: USB_STATS_UMS USB_STATS_UKBD cheers. alex --HPS -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB_VERBOSE and vendor-/productnames
On Tue Sep 14 10, Hans Petter Selasky wrote: On Tuesday 14 September 2010 22:25:46 Alexander Best wrote: also i've been wondering why freebsd keeps its own set of a usb device db? the databse at http://www.linux-usb.org/usb-ids.html seems very active. can't we just use a script to create usbdevs from that db? that's how pci ids are mapped to vendors/products on freebsd (see http://www.mail-archive.com/freebsd-curr...@freebsd.org/msg124948.html). If we don't have to GPL the resulting .h and .c files. The contents of the database and the generated files can be distributed under the terms of either the GNU General Public License (version 2 or later) or of the 3-clause BSD License. :) --HPS -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
USB_VERBOSE and vendor-/productnames
hi there, a lot of people report issues where usbconfig doesn't show a vendor or device name, although an usbdevs entry exists. i found a few replies to those reports by hps@ stating that USB_VERBOSE needs to be enabled. could anybody explain why? if that option needs to be enabled in order to see vendor and device names in usbconfig how come that even without it i see most of the vendor and device names with usbconfig: ugen0.1: UHCI root HUB Intel at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen1.1: UHCI root HUB Intel at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen2.1: UHCI root HUB Intel at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen3.1: EHCI root HUB Intel at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen4.1: UHCI root HUB Intel at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen5.1: UHCI root HUB Intel at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen6.1: UHCI root HUB Intel at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen7.1: EHCI root HUB Intel at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen3.2: product 0x2514 vendor 0x0424 at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen1.2: Dell USB Keyboard Dell at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen1.3: Razer 1600dpi Mouse Razer at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON my guess would be that these devices are missing the iManufacturer and/or iProduct string, but that's just a wild guess. if that is the case wouldn't it be possible to check for a usbdevs entry in case one of those strings don't exist and if there's an entry in usbdevs use it? i think the option USB_VERBOSE is not really accurate in this particular case. people who want usbconfig to output the vendor and product name actually want less verbosity (i.e. no product/vendor hex ids). cheers. alex -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: problem with mobile phone
On Fri Aug 27 10, Hans Petter Selasky wrote: On Thursday 26 August 2010 23:50:28 Alexander Best wrote: hi there, when i connect my mobile phone to a recent HEAD (amd64; r211393) i get the following: ugen3.3: Samsung at usbus3 umass0: USB Mass Storage Interface on usbus3 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have changed) da0 at umass-sim0 bus 0 scbus9 target 0 lun 0 da0: Samsung SGH-i550 1.0 Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3777MB (7736320 512 byte sectors: 255H 63S/T 481C) when i try to read stuff from the phone, it resets and i get this: ugen3.3: Samsung at usbus3 (disconnected) umass0: at uhub8, port 3, addr 3 (disconnected) (da0:umass-sim0:0:0:0): AutoSense failed (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0xa, scsi status == 0x0 (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry it both happens if i mount it and read files or if i directly read something from the /dev/da0 device using `dd`. interestingly it always crashes after the same ammount of data read: dd: /dev/da0: Input/output error 4+0 records in 4+0 records out 4194304 bytes transferred in 3.333149 secs (1258361 bytes/sec) after a few retries the usb port i was using becomes unusable and nothing is being detected any longer. i'm pretty sure this didn't happen a few weeks ago, but now it does. Hi, Have you loaded the usb_quirk.ko ? Try adding a mass storage quirk for this mass storage device, for test unit ready and synchronize cache. i've used the following commanda to add the quirks: usbconfig add_dev_quirk_vplh 0x04e8 0x6720 0x0100 0x0100 UQ_MSC_NO_TEST_UNIT_READY usbconfig add_dev_quirk_vplh 0x04e8 0x6720 0x0100 0x0100 UQ_MSC_NO_SYNC_CACHE `usbconfig dump_device_quirks|grep 0x04e8` says: VID=0x04e8 PID=0x5092 REVLO=0x REVHI=0x QUIRK=UQ_MSC_NO_SYNC_CACHE VID=0x04e8 PID=0x6720 REVLO=0x0100 REVHI=0x0100 QUIRK=UQ_MSC_NO_SYNC_CACHE VID=0x04e8 PID=0x6720 REVLO=0x0100 REVHI=0x0100 QUIRK=UQ_MSC_NO_TEST_UNIT_READY still no difference. as soon as i attach the device it crashes and reboots itsself (the mobile). sometimes it doesn't, however when i read data from it it then crashes instantly. here are the device details: ugen3.3: SGH-i550 Samsung at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0020 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x0004 Bulk transfer method configuration bmAttributes = 0x00e0 bMaxPower = 0x0032 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x0008 bInterfaceSubClass = 0x0006 bInterfaceProtocol = 0x0050 iInterface = 0x0006 USB Mass Storage Interface Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 IN bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 OUT bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x the output of `otaku% kldstat -v|grep usb` is: 72 usbus/uhub 71 uhub/usb_linux 69 uss820/usbus 68 at91_udp/usbus 67 ehci/usbus 66 uhci/usbus 65 ohci/usbus however `kldload usb_quirk` fails with EEXIST. cheers. alex Else look for changes in SCSI area. --HPS -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: tiny ukbd num lock issue
On Thu Aug 26 10, Jim Bryant wrote: oh freaking wow!!! this just got weirder!!! i haven't had the two-press thing again, but since you listed the status of the keys themselves, i decided to check just now... numlock off = numbers numlock on = cursor pad nope. not the case here neither on the console nor under Xorg: numlock off = cursor pad numlock on = numbers i'm not sure however if the issue where i need to press num lock multiple times occurs only under Xorg or also when i'm just on the console and haven't started Xorg at all. i'll get back to you on that one. cheers. alex we have two different behaviors here. please double check yours just in case. i just double-checked, my keypad is operating opposite the way it should be. motherboard: intel dq45ek, most recent bios (mid august), numlock defaults to on in bios cmos setting. just in case, i double-checked, my external keypad is hooked up to the laptop, not this - no conflicts there. xorg is configured or default behavior, as is kde4. this might be a xorg or kde issue. i just checked syscons. normal behavior there. nums only when numlock is on. in kde system settings: leave unchanged is the enabled option. if you have kde4 installed (or any other wm) please check under x for reverse behavior. Alexander Best wrote: On Thu Aug 26 10, Jim Bryant wrote: when you had to press it twice, was that only for the first attempt, and did pressing it once after that turn it off? and once after that, on? exactly. it might be a bit easier to understand if i explain it this way: instance | num lock led| number keys working --- | - | - no key press | on | no 1st key press| on | no 2nd key press| off | no 3rd key press| on | yes 4th key press| off | no 5th key press| on | yes ... (key press refering to the num lock key) cheers. alex i just read your note here, and the following one about the long delays (kern/99538), and was able to duplicate the two-press thing. amd64 here, under kde, and the keyboard is a compaq pos ps/2 via a generic mouse/kb dongle/adapter for usb i got on ebay from hong kong: ukbd1: vendor 0x13ba Generic USB K/B, class 0/0, rev 1.10/0.01, addr 2 on usbus2 ums1: vendor 0x13ba Generic USB K/B, class 0/0, rev 1.10/0.01, addr 2 on usbus2 it seems that the press-twice scenario was only needed the first attempt. normal behaviour after that. 8.1-stable last cvsup/build: FreeBSD orb.electron-tube.net 8.1-STABLE FreeBSD 8.1-STABLE #0: Wed Aug 25 03:44:55 CDT 2010 jbry...@orb.electron-tube.net:/usr/obj/usr/src/sys/ORB amd64 Alexander Best wrote: hi there, i have a very tiny num lock issue with ukbd on HEAD (amd64; r211393). in my bios i have enabled the boot with num lock enabled feature. when i fire up freebsd the num lock light on my keyboard is on. however the num lock keys don't work. if i press the num lock button once nothing happens. if i hit it twice the num lock led goes off. to make the num lock feature work i have to actually hit the num lock key thrice. is this a known issue? cheers. alex -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: tiny ukbd num lock issue
On Thu Aug 26 10, Jim Bryant wrote: oh freaking wow!!! this just got weirder!!! just found PR 139144. maybe that's the cause for the problem? are you loading a a specific keymap? i'm using german.iso cheers. alex i haven't had the two-press thing again, but since you listed the status of the keys themselves, i decided to check just now... numlock off = numbers numlock on = cursor pad we have two different behaviors here. please double check yours just in case. i just double-checked, my keypad is operating opposite the way it should be. motherboard: intel dq45ek, most recent bios (mid august), numlock defaults to on in bios cmos setting. just in case, i double-checked, my external keypad is hooked up to the laptop, not this - no conflicts there. xorg is configured or default behavior, as is kde4. this might be a xorg or kde issue. i just checked syscons. normal behavior there. nums only when numlock is on. in kde system settings: leave unchanged is the enabled option. if you have kde4 installed (or any other wm) please check under x for reverse behavior. Alexander Best wrote: On Thu Aug 26 10, Jim Bryant wrote: when you had to press it twice, was that only for the first attempt, and did pressing it once after that turn it off? and once after that, on? exactly. it might be a bit easier to understand if i explain it this way: instance | num lock led| number keys working --- | - | - no key press | on | no 1st key press| on | no 2nd key press| off | no 3rd key press| on | yes 4th key press| off | no 5th key press| on | yes ... (key press refering to the num lock key) cheers. alex i just read your note here, and the following one about the long delays (kern/99538), and was able to duplicate the two-press thing. amd64 here, under kde, and the keyboard is a compaq pos ps/2 via a generic mouse/kb dongle/adapter for usb i got on ebay from hong kong: ukbd1: vendor 0x13ba Generic USB K/B, class 0/0, rev 1.10/0.01, addr 2 on usbus2 ums1: vendor 0x13ba Generic USB K/B, class 0/0, rev 1.10/0.01, addr 2 on usbus2 it seems that the press-twice scenario was only needed the first attempt. normal behaviour after that. 8.1-stable last cvsup/build: FreeBSD orb.electron-tube.net 8.1-STABLE FreeBSD 8.1-STABLE #0: Wed Aug 25 03:44:55 CDT 2010 jbry...@orb.electron-tube.net:/usr/obj/usr/src/sys/ORB amd64 Alexander Best wrote: hi there, i have a very tiny num lock issue with ukbd on HEAD (amd64; r211393). in my bios i have enabled the boot with num lock enabled feature. when i fire up freebsd the num lock light on my keyboard is on. however the num lock keys don't work. if i press the num lock button once nothing happens. if i hit it twice the num lock led goes off. to make the num lock feature work i have to actually hit the num lock key thrice. is this a known issue? cheers. alex -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: tiny ukbd num lock issue
On Fri Aug 27 10, Alexander Best wrote: On Thu Aug 26 10, Jim Bryant wrote: oh freaking wow!!! this just got weirder!!! just found PR 139144. maybe that's the cause for the problem? are you loading a a specific keymap? i'm using german.iso cheers. alex i haven't had the two-press thing again, but since you listed the status of the keys themselves, i decided to check just now... numlock off = numbers numlock on = cursor pad we have two different behaviors here. please double check yours just in case. i just double-checked, my keypad is operating opposite the way it should be. motherboard: intel dq45ek, most recent bios (mid august), numlock defaults to on in bios cmos setting. just in case, i double-checked, my external keypad is hooked up to the laptop, not this - no conflicts there. xorg is configured or default behavior, as is kde4. this might be a xorg or kde issue. i just checked syscons. normal behavior there. nums only when numlock is on. ok. i did some tests and it seems this is indeed an xorg problen. i couldn't reproduce this on the console. i think this is an issue with hal. because i also noticed that if i unplug my keyboard or mouse and plug it in again it won't work properly under xorg (some keys don't work anymore). what i need to do is switch to the console using ctrl+alt+[1-9] and then switch back to xorg again. after that everything's back to normal. so this not an usb issue it seems but related to xorg (most likely hal). cheers. alex in kde system settings: leave unchanged is the enabled option. if you have kde4 installed (or any other wm) please check under x for reverse behavior. Alexander Best wrote: On Thu Aug 26 10, Jim Bryant wrote: when you had to press it twice, was that only for the first attempt, and did pressing it once after that turn it off? and once after that, on? exactly. it might be a bit easier to understand if i explain it this way: instance | num lock led| number keys working ---| - | - no key press | on | no 1st key press | on | no 2nd key press | off | no 3rd key press | on | yes 4th key press | off | no 5th key press | on | yes ... (key press refering to the num lock key) cheers. alex i just read your note here, and the following one about the long delays (kern/99538), and was able to duplicate the two-press thing. amd64 here, under kde, and the keyboard is a compaq pos ps/2 via a generic mouse/kb dongle/adapter for usb i got on ebay from hong kong: ukbd1: vendor 0x13ba Generic USB K/B, class 0/0, rev 1.10/0.01, addr 2 on usbus2 ums1: vendor 0x13ba Generic USB K/B, class 0/0, rev 1.10/0.01, addr 2 on usbus2 it seems that the press-twice scenario was only needed the first attempt. normal behaviour after that. 8.1-stable last cvsup/build: FreeBSD orb.electron-tube.net 8.1-STABLE FreeBSD 8.1-STABLE #0: Wed Aug 25 03:44:55 CDT 2010 jbry...@orb.electron-tube.net:/usr/obj/usr/src/sys/ORB amd64 Alexander Best wrote: hi there, i have a very tiny num lock issue with ukbd on HEAD (amd64; r211393). in my bios i have enabled the boot with num lock enabled feature. when i fire up freebsd the num lock light on my keyboard is on. however the num lock keys don't work. if i press the num lock button once nothing happens. if i hit it twice the num lock led goes off. to make the num lock feature work i have to actually hit the num lock key thrice. is this a known issue? cheers. alex -- a13x -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
problem with mobile phone
hi there, when i connect my mobile phone to a recent HEAD (amd64; r211393) i get the following: ugen3.3: Samsung at usbus3 umass0: USB Mass Storage Interface on usbus3 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have changed) da0 at umass-sim0 bus 0 scbus9 target 0 lun 0 da0: Samsung SGH-i550 1.0 Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3777MB (7736320 512 byte sectors: 255H 63S/T 481C) when i try to read stuff from the phone, it resets and i get this: ugen3.3: Samsung at usbus3 (disconnected) umass0: at uhub8, port 3, addr 3 (disconnected) (da0:umass-sim0:0:0:0): AutoSense failed (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0xa, scsi status == 0x0 (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry it both happens if i mount it and read files or if i directly read something from the /dev/da0 device using `dd`. interestingly it always crashes after the same ammount of data read: dd: /dev/da0: Input/output error 4+0 records in 4+0 records out 4194304 bytes transferred in 3.333149 secs (1258361 bytes/sec) after a few retries the usb port i was using becomes unusable and nothing is being detected any longer. i'm pretty sure this didn't happen a few weeks ago, but now it does. cheers. alex -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: tiny ukbd num lock issue
On Thu Aug 26 10, Jim Bryant wrote: when you had to press it twice, was that only for the first attempt, and did pressing it once after that turn it off? and once after that, on? exactly. it might be a bit easier to understand if i explain it this way: instance| num lock led| number keys working --- | - | - no key press| on | no 1st key press | on | no 2nd key press | off | no 3rd key press | on | yes 4th key press | off | no 5th key press | on | yes ... (key press refering to the num lock key) cheers. alex i just read your note here, and the following one about the long delays (kern/99538), and was able to duplicate the two-press thing. amd64 here, under kde, and the keyboard is a compaq pos ps/2 via a generic mouse/kb dongle/adapter for usb i got on ebay from hong kong: ukbd1: vendor 0x13ba Generic USB K/B, class 0/0, rev 1.10/0.01, addr 2 on usbus2 ums1: vendor 0x13ba Generic USB K/B, class 0/0, rev 1.10/0.01, addr 2 on usbus2 it seems that the press-twice scenario was only needed the first attempt. normal behaviour after that. 8.1-stable last cvsup/build: FreeBSD orb.electron-tube.net 8.1-STABLE FreeBSD 8.1-STABLE #0: Wed Aug 25 03:44:55 CDT 2010 jbry...@orb.electron-tube.net:/usr/obj/usr/src/sys/ORB amd64 Alexander Best wrote: hi there, i have a very tiny num lock issue with ukbd on HEAD (amd64; r211393). in my bios i have enabled the boot with num lock enabled feature. when i fire up freebsd the num lock light on my keyboard is on. however the num lock keys don't work. if i press the num lock button once nothing happens. if i hit it twice the num lock led goes off. to make the num lock feature work i have to actually hit the num lock key thrice. is this a known issue? cheers. alex -- a13x ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: vendor and device name not appearing
On Tue, Jun 29, 2010 at 9:46 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Tuesday 29 June 2010 20:15:46 Alexander Best wrote: hi there, i have a little question. i'm running HEAD (amd64; r209548) and when i run `usbconfig` this is the description for my usb hub: ugen3.2: product 0x2514 vendor 0x0424 at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE i'm a bit surprised by that, because both the vendor and the product have been defined in sys/dev/usb/usbdevs. `cat /usr/src/sys/dev/usb/usbdevs|egrep '(0x2514|0x0424)'` reports: vendor SMC2 0x0424 Standard Microsystems product SMC2 2514HUB 0x2514 USB Hub Did you compile the kernel with options USB_VERBOSE ? nope. :) --HPS -- Alexander Best ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
vendor and device name not appearing
hi there, i have a little question. i'm running HEAD (amd64; r209548) and when i run `usbconfig` this is the description for my usb hub: ugen3.2: product 0x2514 vendor 0x0424 at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE i'm a bit surprised by that, because both the vendor and the product have been defined in sys/dev/usb/usbdevs. `cat /usr/src/sys/dev/usb/usbdevs|egrep '(0x2514|0x0424)'` reports: vendor SMC2 0x0424 Standard Microsystems product SMC2 2514HUB0x2514 USB Hub cheers. alex -- Alexander Best ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: PS3's Joystick on FreeBSD (can be possible?)
Paul B Mahol schrieb am 2010-03-13: On Sat, Mar 13, 2010 at 1:56 PM, Alexander Best alexbes...@wwu.de wrote: Hans Petter Selasky schrieb am 2010-03-13: On Saturday 13 March 2010 13:21:10 Paul B Mahol wrote: On 3/13/10, Alexander Best alexbes...@wwu.de wrote: Paul B Mahol schrieb am 2010-03-13: On 3/13/10, Alexander Best alexbes...@wwu.de wrote: i'm sorry to hijack this thread, but i've been having similar issues as Vinicius with his PS3 controller with my logitech cordless gamepad. this is the attach message: ugen3.3: Logitech at usbus3 uhid0: Logitech Logitech Cordless RumblePad 2, class 0/0, rev 1.10/2.00, addr 3 on usbus3 the output of `usbhidctl -f /dev/uhid0 -r` is: Report descriptor: Collection page=Generic_Desktop usage=Game_Pad Total input size 0 bytes Total output size 0 bytes Total feature size 0 bytes if i do `hd /dev/uhid0` is see output like this when pressing buttons on the gamepad: 01 78 72 88 69 08 00 01 01 80 7f 7f 80 18 00 00 |.xr.i...| 0010 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 00 00 || 0020 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 28 00 00 |.(..| 0030 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 48 00 00 |.H..| 0040 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 88 00 00 || 0050 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 01 00 || 0060 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 02 00 || 0070 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 04 00 || 0080 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 08 00 || 0090 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 10 00 || 00a0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 20 00 |.. .| 00b0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 04 00 00 || 00c0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 06 00 00 || 00d0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 00 00 00 || 00e0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 02 00 00 || the pad has 10 buttons, 1 analog stick, 2 digital sticks, a mode button and a vibration button. There was/is ujoy in development but that is all. thanks for the hint. i mailed the developer a year or so ago due to his post on the freebsd-drivers@ mailinglist [1], but he told development of the ujoy driver had ceased. i checked the site mentioned in his post and the ujoy driver from back then is also no longer available. so there is no way of xorg or hal working directly with uhid devices then? There is xf86-input-joystick, but I dunno about its usability. Also look here: http://wiki.freebsd.org/uhidd thanks for the hint. i'm about to try it out. however i'm having difficulties recompiling my kernel without ukbd (which is required for using uhidd): You can build all usb stuff as module. It only eats little more disk space ... thanks for the hint, but since uhidd won't help me with my problem i'm no longer trying to compile my kernel without ums, uhid and ukbd. however i filed a pr under usb/144751, because building a kernel without ukbd seems broken on CURRENT. cheers. alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
usb/144751: [ukbd] [usb8] kernel without keyboard support won't compile
Number: 144751 Category: usb Synopsis: [ukbd] [usb8] kernel without keyboard support won't compile Confidential: no Severity: serious Priority: medium Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Mon Mar 15 00:00:19 UTC 2010 Closed-Date: Last-Modified: Originator: Alexander Best Release:9.0-CURRENT Organization: Environment: FreeBSD otaku 9.0-CURRENT FreeBSD 9.0-CURRENT #8 r205019M: Thu Mar 11 21:03:33 CET 2010 r...@otaku:/usr/obj/usr/src/sys/ARUNDEL amd64 Description: trying to compile a kernel with no usb keyboard support results in the following error during kernel compilation: cc -c -O0 -pipe -fno-builtin -march=native -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/usr/src/sys -I/usr/src/sys/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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector vnode_if.c : hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=make sh /usr/src/sys/conf/newvers.sh ARUNDEL cc -c -O0 -pipe -fno-builtin -march=native -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/usr/src/sys -I/usr/src/sys/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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector vers.c linking kernel kbd.o(.text+0x59b): In function `kbd_register': : undefined reference to `__start_set_kbddriver_set' kbd.o(.text+0x686): In function `kbd_register': : undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x842): In function `kbd_get_switch': : undefined reference to `__start_set_kbddriver_set' kbd.o(.text+0x87f): In function `kbd_get_switch': : undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0xdf8): In function `kbd_configure': : undefined reference to `__start_set_kbddriver_set' kbd.o(.text+0xe2c): In function `kbd_configure': : undefined reference to `__stop_set_kbddriver_set' *** Error code 1 Stop in /usr/obj/usr/src/sys/ARUNDEL. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. cheers. alex How-To-Repeat: use the attached kernel conf to compile a new kernel. Fix: since the atkbd driver cannot be compiled as a kernel module it's obvious that having no keyboard defined in the kernel conf should make the kernel rely on the ukbd module. if however the use of the ukb driver as module is unsupported this problem report should be considered a change request to the ukbd(4) manual to reflect the mandatory definition of ukbd in the kernel conf. Patch attached with submission follows: # debugger/ktrace/kernel.debug options KDB # Compile with kernel debugger related code. options DDB # Enable the ddb debugger backend. options KTRACE # ktrace(1) support makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols # various debugging options #optionsKDB_TRACE # Print a stack trace of the current thread on the console for a panic. #optionsPREEMPTION # Allows the threads that are in the kernel to be preempted by higher priority [interrupt] threads. #optionsIPI_PREEMPTION # Instructs the kernel to preempt threads running on other CPUS if needed. Relies on the PREEMPTION option. #optionsBREAK_TO_DEBUGGER # A BREAK on a serial console goes to ddb, if available. #optionsINVARIANTS #optionsINVARIANT_SUPPORT #optionsWITNESS #optionsDEBUG_LOCKS #optionsDEBUG_VFS_LOCKS #optionsDIAGNOSTIC #optionsSW_WATCHDOG #optionsSOCKBUF_DEBUG #optionsDEBUG_MEMGUARD #optionsDEBUG_REDZONE #optionsSTACK options DEADLKRES # Add the software deadlock resolver thread. cpu HAMMER ident ARUNDEL #optionsSCHED_ULE # ULE scheduler options
Re: PS3's Joystick on FreeBSD (can be possible?)
i'm sorry to hijack this thread, but i've been having similar issues as Vinicius with his PS3 controller with my logitech cordless gamepad. this is the attach message: ugen3.3: Logitech at usbus3 uhid0: Logitech Logitech Cordless RumblePad 2, class 0/0, rev 1.10/2.00, addr 3 on usbus3 the output of `usbhidctl -f /dev/uhid0 -r` is: Report descriptor: Collection page=Generic_Desktop usage=Game_Pad Total input size 0 bytes Total output size 0 bytes Total feature size 0 bytes if i do `hd /dev/uhid0` is see output like this when pressing buttons on the gamepad: 01 78 72 88 69 08 00 01 01 80 7f 7f 80 18 00 00 |.xr.i...| 0010 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 00 00 || 0020 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 28 00 00 |.(..| 0030 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 48 00 00 |.H..| 0040 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 88 00 00 || 0050 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 01 00 || 0060 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 02 00 || 0070 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 04 00 || 0080 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 08 00 || 0090 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 10 00 || 00a0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 20 00 |.. .| 00b0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 04 00 00 || 00c0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 06 00 00 || 00d0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 00 00 00 || 00e0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 02 00 00 || the pad has 10 buttons, 1 analog stick, 2 digital sticks, a mode button and a vibration button. cheers. alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: PS3's Joystick on FreeBSD (can be possible?)
Paul B Mahol schrieb am 2010-03-13:
On 3/13/10, Alexander Best alexbes...@wwu.de wrote:
i'm sorry to hijack this thread, but i've been having similar
issues as
Vinicius with his PS3 controller with my logitech cordless gamepad.
this is
the attach message:
ugen3.3: Logitech at usbus3
uhid0: Logitech Logitech Cordless RumblePad 2, class 0/0, rev
1.10/2.00,
addr
3 on usbus3
the output of `usbhidctl -f /dev/uhid0 -r` is:
Report descriptor:
Collection page=Generic_Desktop usage=Game_Pad
Total input size 0 bytes
Total output size 0 bytes
Total feature size 0 bytes
if i do `hd /dev/uhid0` is see output like this when pressing
buttons on the
gamepad:
01 78 72 88 69 08 00 01 01 80 7f 7f 80 18 00 00
|.xr.i...|
0010 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 00 00
||
0020 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 28 00 00
|.(..|
0030 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 48 00 00
|.H..|
0040 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 88 00 00
||
0050 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 01 00
||
0060 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 02 00
||
0070 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 04 00
||
0080 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 08 00
||
0090 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 10 00
||
00a0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 20 00
|..
.|
00b0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 04 00 00
||
00c0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 06 00 00
||
00d0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 00 00 00
||
00e0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 02 00 00
||
the pad has 10 buttons, 1 analog stick, 2 digital sticks, a mode
button
and
a vibration button.
There was/is ujoy in development but that is all.
thanks for the hint. i mailed the developer a year or so ago due to his post
on the freebsd-drivers@ mailinglist [1], but he told development of the ujoy
driver had ceased. i checked the site mentioned in his post and the ujoy
driver from back then is also no longer available.
so there is no way of xorg or hal working directly with uhid devices then?
cheers.
alex
[1]
http://lists.freebsd.org/pipermail/freebsd-drivers/2008-December/000858.html
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: PS3's Joystick on FreeBSD (can be possible?)
Paul B Mahol schrieb am 2010-03-13:
On 3/13/10, Alexander Best alexbes...@wwu.de wrote:
Paul B Mahol schrieb am 2010-03-13:
On 3/13/10, Alexander Best alexbes...@wwu.de wrote:
i'm sorry to hijack this thread, but i've been having similar
issues as
Vinicius with his PS3 controller with my logitech cordless
gamepad.
this is
the attach message:
ugen3.3: Logitech at usbus3
uhid0: Logitech Logitech Cordless RumblePad 2, class 0/0, rev
1.10/2.00,
addr
3 on usbus3
the output of `usbhidctl -f /dev/uhid0 -r` is:
Report descriptor:
Collection page=Generic_Desktop usage=Game_Pad
Total input size 0 bytes
Total output size 0 bytes
Total feature size 0 bytes
if i do `hd /dev/uhid0` is see output like this when pressing
buttons on the
gamepad:
01 78 72 88 69 08 00 01 01 80 7f 7f 80 18 00 00
|.xr.i...|
0010 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 00 00
||
0020 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 28 00 00
|.(..|
0030 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 48 00 00
|.H..|
0040 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 88 00 00
||
0050 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 01 00
||
0060 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 02 00
||
0070 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 04 00
||
0080 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 08 00
||
0090 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 10 00
||
00a0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 20 00
|..
.|
00b0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 04 00 00
||
00c0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 06 00 00
||
00d0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 00 00 00
||
00e0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 02 00 00
||
the pad has 10 buttons, 1 analog stick, 2 digital sticks, a
mode
button
and
a vibration button.
There was/is ujoy in development but that is all.
thanks for the hint. i mailed the developer a year or so ago due to
his post
on the freebsd-drivers@ mailinglist [1], but he told development of
the ujoy
driver had ceased. i checked the site mentioned in his post and the
ujoy
driver from back then is also no longer available.
so there is no way of xorg or hal working directly with uhid
devices then?
There is xf86-input-joystick, but I dunno about its usability.
thanks. i'll go check that out. i also found an old post from 1999 saying
something about a usb joystick driver being committed to freebsd soon [1].
;)
[1]
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=782800+0+archive/1999/cvs-all/19990704.cvs-all
[1]
http://lists.freebsd.org/pipermail/freebsd-drivers/2008-December/000858.html
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: PS3's Joystick on FreeBSD (can be possible?)
Paul B Mahol schrieb am 2010-03-13:
On 3/13/10, Alexander Best alexbes...@wwu.de wrote:
Paul B Mahol schrieb am 2010-03-13:
On 3/13/10, Alexander Best alexbes...@wwu.de wrote:
i'm sorry to hijack this thread, but i've been having similar
issues as
Vinicius with his PS3 controller with my logitech cordless
gamepad.
this is
the attach message:
ugen3.3: Logitech at usbus3
uhid0: Logitech Logitech Cordless RumblePad 2, class 0/0, rev
1.10/2.00,
addr
3 on usbus3
the output of `usbhidctl -f /dev/uhid0 -r` is:
Report descriptor:
Collection page=Generic_Desktop usage=Game_Pad
Total input size 0 bytes
Total output size 0 bytes
Total feature size 0 bytes
if i do `hd /dev/uhid0` is see output like this when pressing
buttons on the
gamepad:
01 78 72 88 69 08 00 01 01 80 7f 7f 80 18 00 00
|.xr.i...|
0010 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 00 00
||
0020 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 28 00 00
|.(..|
0030 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 48 00 00
|.H..|
0040 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 88 00 00
||
0050 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 01 00
||
0060 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 02 00
||
0070 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 04 00
||
0080 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 08 00
||
0090 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 10 00
||
00a0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 20 00
|..
.|
00b0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 04 00 00
||
00c0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 06 00 00
||
00d0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 00 00 00
||
00e0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 02 00 00
||
the pad has 10 buttons, 1 analog stick, 2 digital sticks, a
mode
button
and
a vibration button.
There was/is ujoy in development but that is all.
thanks for the hint. i mailed the developer a year or so ago due to
his post
on the freebsd-drivers@ mailinglist [1], but he told development of
the ujoy
driver had ceased. i checked the site mentioned in his post and the
ujoy
driver from back then is also no longer available.
so there is no way of xorg or hal working directly with uhid
devices then?
There is xf86-input-joystick, but I dunno about its usability.
no luck unfortunately:
(**) Option Device /dev/uhid0
(**) Option SendCoreEvents
(**) Logitech Cordless RumblePad 2: always reports core events
(**) Option DebugLevel 9
(**) Logitech Cordless RumblePad 2: debug level set to 9
(**) Button 1 mapped to 5
(**) Button 2 mapped to 5
(**) Button 3 mapped to 5
(**) Button 4 mapped to 0
(**) Button 5 mapped to 0
(**) Button 6 mapped to 0
(**) Button 7 mapped to 0
(**) Button 8 mapped to 0
(**) Button 9 mapped to 0
(**) Button 10 mapped to 0
(**) Button 11 mapped to 0
(**) Button 12 mapped to 0
(**) Button 13 mapped to 0
(**) Button 14 mapped to 0
(**) Button 15 mapped to 0
(**) Button 16 mapped to 0
(**) Button 17 mapped to 0
(**) Button 18 mapped to 0
(**) Button 19 mapped to 0
(**) Button 20 mapped to 0
(**) Button 21 mapped to 0
(**) Button 22 mapped to 0
(**) Button 23 mapped to 0
(**) Button 24 mapped to 0
(**) Button 25 mapped to 0
(**) Button 26 mapped to 0
(**) Button 27 mapped to 0
(**) Button 28 mapped to 0
(**) Button 29 mapped to 0
(**) Button 30 mapped to 0
(**) Button 31 mapped to 0
(**) Button 32 mapped to 0
(**) Axis 1 type is 1, mapped to 1, amplify=1.000
(**) Axis 2 type is 1, mapped to 2, amplify=1.000
(**) Axis 3 type is 1, mapped to 3, amplify=1.000
(**) Axis 4 type is 1, mapped to 4, amplify=1.000
(**) Axis 5 type is 2, mapped to 1, amplify=1.000
(**) Axis 6 type is 2, mapped to 2, amplify=1.000
(**) Axis 7 type is 0, mapped to 0, amplify=1.000
(**) Axis 8 type is 0, mapped to 0, amplify=1.000
(**) Axis 9 type is 0, mapped to 0, amplify=1.000
(**) Axis 10 type is 0, mapped to 0, amplify=1.000
(**) Axis 11 type is 0, mapped to 0, amplify=1.000
(**) Axis 12 type is 0, mapped to 0, amplify=1.000
(**) Axis 13 type is 0, mapped to 0, amplify=1.000
(**) Axis 14 type is 0, mapped to 0, amplify=1.000
(**) Axis 15 type is 0, mapped to 0, amplify=1.000
(**) Axis 16 type is 0, mapped to 0, amplify=1.000
(**) Axis 17 type is 0, mapped to 0, amplify=1.000
(**) Axis 18 type is 0, mapped to 0, amplify=1.000
(**) Axis 19 type is 0, mapped to 0, amplify=1.000
(**) Axis 20 type is 0, mapped to 0, amplify=1.000
(**) Axis 21 type is 0, mapped to 0, amplify=1.000
(**) Axis 22 type is 0, mapped to 0, amplify=1.000
(**) Axis 23 type is 0, mapped to 0, amplify=1.000
(**) Axis 24 type is 0, mapped to 0, amplify=1.000
(**) Axis 25 type is 0
Re: PS3's Joystick on FreeBSD (can be possible?)
Hans Petter Selasky schrieb am 2010-03-13: On Saturday 13 March 2010 13:21:10 Paul B Mahol wrote: On 3/13/10, Alexander Best alexbes...@wwu.de wrote: Paul B Mahol schrieb am 2010-03-13: On 3/13/10, Alexander Best alexbes...@wwu.de wrote: i'm sorry to hijack this thread, but i've been having similar issues as Vinicius with his PS3 controller with my logitech cordless gamepad. this is the attach message: ugen3.3: Logitech at usbus3 uhid0: Logitech Logitech Cordless RumblePad 2, class 0/0, rev 1.10/2.00, addr 3 on usbus3 the output of `usbhidctl -f /dev/uhid0 -r` is: Report descriptor: Collection page=Generic_Desktop usage=Game_Pad Total input size 0 bytes Total output size 0 bytes Total feature size 0 bytes if i do `hd /dev/uhid0` is see output like this when pressing buttons on the gamepad: 01 78 72 88 69 08 00 01 01 80 7f 7f 80 18 00 00 |.xr.i...| 0010 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 00 00 || 0020 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 28 00 00 |.(..| 0030 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 48 00 00 |.H..| 0040 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 88 00 00 || 0050 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 01 00 || 0060 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 02 00 || 0070 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 04 00 || 0080 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 08 00 || 0090 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 10 00 || 00a0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 08 20 00 |.. .| 00b0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 04 00 00 || 00c0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 06 00 00 || 00d0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 00 00 00 || 00e0 01 80 7f 7f 80 08 00 00 01 80 7f 7f 80 02 00 00 || the pad has 10 buttons, 1 analog stick, 2 digital sticks, a mode button and a vibration button. There was/is ujoy in development but that is all. thanks for the hint. i mailed the developer a year or so ago due to his post on the freebsd-drivers@ mailinglist [1], but he told development of the ujoy driver had ceased. i checked the site mentioned in his post and the ujoy driver from back then is also no longer available. so there is no way of xorg or hal working directly with uhid devices then? There is xf86-input-joystick, but I dunno about its usability. Also look here: http://wiki.freebsd.org/uhidd thanks. i've tried very hard to compile a kernel without ukbd statically linked in to it and didn't succeed. maybe you could have a look at this? to me it seems building a kernel with ukbd as module and without it statically linked into the kernel is broken. again the error message during buildkernel is: cc -c -O0 -pipe -fno-builtin -march=native -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/usr/src/sys -I/usr/src/sys/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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector vnode_if.c : hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=make sh /usr/src/sys/conf/newvers.sh ARUNDEL cc -c -O0 -pipe -fno-builtin -march=native -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/usr/src/sys -I/usr/src/sys/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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector vers.c linking kernel kbd.o(.text+0x59b): In function `kbd_register': : undefined reference to `__start_set_kbddriver_set' kbd.o(.text+0x686): In function `kbd_register': : undefined reference to `__stop_set_kbddriver_set' kbd.o(.text+0x842): In function `kbd_get_switch': : undefined reference to `__start_set_kbddriver_set' kbd.o(.text+0x87f): In function `kbd_get_switch': : undefined reference
[patch] add usb hub (0x2514 / 0x0424) to usbdevs
just a product addition to usbdevs. cheers. alex oh...and one question: why does `usbconfig dump_device_desc` say ugen3.2: product 0x2514 vendor 0x0424 at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x0009 bDeviceSubClass = 0x bDeviceProtocol = 0x0002 bMaxPacketSize0 = 0x0040 idVendor = 0x0424 idProduct = 0x2514 bcdDevice = 0x iManufacturer = 0x no string iProduct = 0x no string iSerialNumber = 0x no string bNumConfigurations = 0x0001 although the vendor id is already in usbdevs? Index: sys/dev/usb/usbdevs === --- sys/dev/usb/usbdevs (revision 204988) +++ sys/dev/usb/usbdevs (working copy) @@ -2768,6 +2768,7 @@ product SMC 2206USB0x0201 EZ Connect USB Ethernet product SMC 2862WG 0xee13 EZ Connect Wireless Adapter product SMC2 2020HUB 0x2020 USB Hub +product SMC2 2514HUB 0x2514 USB Hub product SMC3 2662WUSB 0xa002 2662W-AR Wireless /* SOHOware products */ ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [patch] add usb hub (0x2514 / 0x0424) to usbdevs
Hans Petter Selasky schrieb am 2010-03-11: On Thursday 11 March 2010 12:25:46 Alexander Best wrote: just a product addition to usbdevs. cheers. alex oh...and one question: Hi, See USB P4 ID 175574. thanks. :) why does `usbconfig dump_device_desc` say I think you need to compile the kernel with: option USB_VERBOSE Before it works like you expect. options USB_VERBOSE seems broken on r204988: cc -c -O0 -pipe -fno-builtin -march=native -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-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 -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector /usr/src/sys/dev/usb/usb_dev.c cc -c -O0 -pipe -fno-builtin -march=native -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-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 -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector /usr/src/sys/dev/usb/usb_device.c In file included from /usr/src/sys/dev/usb/usb_device.c:2181: ./usbdevs_data.h:5671: error: 'USB_VENDOR_MICRODIA' undeclared here (not in a function) *** Error code 1 Stop in /usr/obj/usr/src/sys/ARUNDEL. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. although the vendor id is already in usbdevs? --HPS i'd also like to ask what the purpose of this code in storage/umass.c is: #define UMASS_EXT_BUFFER #ifdef UMASS_EXT_BUFFER /* this enables loading of virtual buffers into DMA */ #define UMASS_USB_FLAGS .ext_buffer=1, #else #define UMASS_USB_FLAGS #endif isn't that just doing the same as: #define UMASS_EXT_BUFFER /* this enables loading of virtual buffers into DMA */ #define UMASS_USB_FLAGS .ext_buffer=1, cheers. alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [patch] add usb hub (0x2514 / 0x0424) to usbdevs
Hans Petter Selasky schrieb am 2010-03-11: On Thursday 11 March 2010 12:25:46 Alexander Best wrote: just a product addition to usbdevs. cheers. alex oh...and one question: Hi, See USB P4 ID 175574. hmm...with the patch applied and the kernel rebuilt the device's vendor and product id still get displayed instead of the usbdev-names: otaku% sudo usbconfig -d ugen3.2 dump_device_desc ugen3.2: product 0x2514 vendor 0x0424 at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x0009 bDeviceSubClass = 0x bDeviceProtocol = 0x0002 bMaxPacketSize0 = 0x0040 idVendor = 0x0424 idProduct = 0x2514 bcdDevice = 0x iManufacturer = 0x no string iProduct = 0x no string iSerialNumber = 0x no string bNumConfigurations = 0x0001 otaku% egrep '0x2514|0x0424' /usr/src/sys/dev/usb/usbdevs vendor SMC2 0x0424 Standard Microsystems product SMC2 2514HUB0x2514 USB Hub alex why does `usbconfig dump_device_desc` say I think you need to compile the kernel with: option USB_VERBOSE Before it works like you expect. although the vendor id is already in usbdevs? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [patch] add usb hub (0x2514 / 0x0424) to usbdevs
Hans Petter Selasky schrieb am 2010-03-11: On Thursday 11 March 2010 13:15:13 Alexander Best wrote: Hans Petter Selasky schrieb am 2010-03-11: On Thursday 11 March 2010 12:25:46 Alexander Best wrote: just a product addition to usbdevs. cheers. alex oh...and one question: Hi, See USB P4 ID 175574. thanks. :) why does `usbconfig dump_device_desc` say I think you need to compile the kernel with: option USB_VERBOSE Before it works like you expect. options USB_VERBOSE seems broken on r204988: Try this patch: http://www.mail-archive.com/svn-src-...@freebsd.org/msg02230.html thanks. now i can build a kernel with USB_VERBOSE. it seems the changes made by r185998 were lost/reverted during a later commit. my usbdevs is r204632 and still had the /* Microdia products */ section in it. Stop in /usr/src. although the vendor id is already in usbdevs? --HPS i'd also like to ask what the purpose of this code in storage/umass.c is: #define UMASS_EXT_BUFFER #ifdef UMASS_EXT_BUFFER /* this enables loading of virtual buffers into DMA */ #define UMASS_USB_FLAGS .ext_buffer=1, #else #define UMASS_USB_FLAGS #endif When ext_buffer is set, no data is copied. Else data is copied into an intermediate buffer. isn't that just doing the same as: Probably we should expand those macros. Send me a patch! hehe...ok. i'll see what i can do. ;) #define UMASS_EXT_BUFFER /* this enables loading of virtual buffers into DMA */ #define UMASS_USB_FLAGS .ext_buffer=1, --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
system freeze with hub
hi there. sometimes my complete system freezes when attaching a certain umass device over the hub integrated in my tft. the only option left is to do a hard reset. no core dump is being produced. this is what gets printed out before the reset: Feb 3 18:12:13 otaku root: Unknown USB device: vendor 0x0492 product 0x0140 bus uhub8 Feb 3 18:12:13 otaku kernel: ugen3.3: Meizu Electronics at usbus3 Feb 3 18:12:13 otaku kernel: umass0: Meizu Electronics MiniPlayer, class 0/0, rev 2.00/1.00, addr 3 on usbus3 Feb 3 18:12:13 otaku kernel: umass0: SCSI over Bulk-Only; quirks = 0x4400 Feb 3 18:12:19 otaku kernel: umass0: Get Max Lun not supported (USB_ERR_TIMEOUT) Feb 3 18:12:20 otaku kernel: umass0:9:0:-1: Attached to scbus9 Feb 3 18:12:20 otaku kernel: ugen3.3: Meizu Electronics at usbus3 (disconnected) Feb 3 18:12:20 otaku kernel: umass0: at uhub8, port 3, addr 3 (disconnected) Feb 3 18:12:20 otaku kernel: (probe0:umass-sim0:0:0:0): AutoSense failed Feb 3 18:12:20 otaku kernel: (da0:umass-sim0:0:0:0): lost device Feb 3 18:12:20 otaku kernel: (da0:umass-sim0:0:0:0): got CAM status 0xa Feb 3 18:12:20 otaku kernel: (da0:umass-sim0:0:0:0): fatal error, failed to attach to device Feb 3 18:12:20 otaku kernel: (da0:umass-sim0:0:0:0): removing device entry Feb 3 18:12:22 otaku kernel: uhub_reattach_port: giving up port reset - device vanished Feb 3 18:12:24 otaku last message repeated 2 times Feb 3 18:12:25 otaku root: Unknown USB device: vendor 0x0492 product 0x0140 bus uhub8 Feb 3 18:12:25 otaku kernel: ugen3.3: Meizu Electronics at usbus3 Feb 3 18:12:25 otaku kernel: umass0: Meizu Electronics MiniPlayer, class 0/0, rev 2.00/1.00, addr 3 on usbus3 Feb 3 18:12:25 otaku kernel: umass0: SCSI over Bulk-Only; quirks = 0x4400 Feb 3 18:12:30 otaku kernel: umass0: Get Max Lun not supported (USB_ERR_TIMEOUT) funny thing is that the device should be known since the vendor and device id are in sys/dev/usb/usbdevs. i'm running CURRENT/amd64 (r203410). after a hard reset i tried reattaching the device to the hub and got no system freeze, but the device didn't attach properly. this is what gets printed: uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished ugen3.3: Meizu Electronics at usbus3 umass0: Meizu Electronics MiniPlayer, class 0/0, rev 2.00/1.00, addr 3 on usbus3 umass0: SCSI over Bulk-Only; quirks = 0x4400 umass0: Get Max Lun not supported (USB_ERR_TIMEOUT) umass0:9:0:-1: Attached to scbus9 ugen3.3: Meizu Electronics at usbus3 (disconnected) umass0: at uhub8, port 3, addr 3 (disconnected) (probe0:umass-sim0:0:0:0): AutoSense failed (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): got CAM status 0xa (da0:umass-sim0:0:0:0): fatal error, failed to attach to device (da0:umass-sim0:0:0:0): removing device entry uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished ugen3.3: Meizu Electronics at usbus3 umass0: Meizu Electronics MiniPlayer, class 0/0, rev 2.00/1.00, addr 3 on usbus3 umass0: SCSI over Bulk-Only; quirks = 0x4400 umass0: Get Max Lun not supported (USB_ERR_TIMEOUT) umass0:9:0:-1: Attached to scbus9 ugen3.3: Meizu Electronics at usbus3 (disconnected) umass0: at uhub8, port 3, addr 3 (disconnected) (probe0:umass-sim0:0:0:0): AutoSense failed (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): got CAM status 0xa (da0:umass-sim0:0:0:0): fatal error, failed to attach to device (da0:umass-sim0:0:0:0): removing device entry uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished uhub_reattach_port: giving up port reset - device vanished
usb/140590: [bluetooth] [usb] ng_ubt(4) ng_l2cap_process_cmd_rej warnings
Number: 140590
Category: usb
Synopsis: [bluetooth] [usb] ng_ubt(4) ng_l2cap_process_cmd_rej warnings
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: Mon Nov 16 02:10:01 UTC 2009
Closed-Date:
Last-Modified:
Originator: Alexander Best
Release:9.0-CURRENT
Organization:
Environment:
FreeBSD otaku 9.0-CURRENT FreeBSD 9.0-CURRENT #7 r199258M: Sat Nov 14 00:05:10
CET 2009 r...@otaku:/usr/obj/usr/src/sys/ARUNDEL i386
Description:
when receiving data with my usb bluetooth dongle device i'm getting these
warnings:
ng_l2cap_process_cmd_rej: ubt0l2cap - unexpected L2CAP_CommandRej command.
Requested ident does not exist, ident=2
ng_l2cap_process_cmd_rej: ubt0l2cap - unexpected L2CAP_CommandRej command.
Requested ident does not exist, ident=2
when sending data these are the warnings appear:
ng_l2cap_process_cmd_rej: ubt0l2cap - unexpected L2CAP_CommandRej command.
Requested ident does not exist, ident=1
ng_l2cap_process_cmd_rej: ubt0l2cap - unexpected L2CAP_CommandRej command.
Requested ident does not exist, ident=1
ng_btsocket_rfcomm_receive_dm: Got DM for non-existing dlci=18
this is my device:
ugen3.3: product 0x0001 vendor 0x0a12 at usbus3, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON
bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x00e0
bDeviceSubClass = 0x0001
bDeviceProtocol = 0x0001
bMaxPacketSize0 = 0x0040
idVendor = 0x0a12
idProduct = 0x0001
bcdDevice = 0x1593
iManufacturer = 0x no string
iProduct = 0x no string
iSerialNumber = 0x no string
bNumConfigurations = 0x0001
i have the following devd.conf entries installed to start bluetooth services
upon attach:
attach 100 {
device-name ubt[0-9]+;
action /etc/rc.d/hcsecd onestart;
action /etc/rc.d/sdpd onestart;
action /etc/rc.d/bluetooth quietstart $device-name;
action /usr/local/bin/obexapp -u arundel -r /var/spool/obex -s -C1;
};
this is the detach entry:
detach 100 {
device-name ubt[0-9]+;
action /usr/bin/killall obexapp;
action /etc/rc.d/bluetooth quietstop $device-name;
action /etc/rc.d/sdpd onestop;
action /etc/rc.d/hcsecd onestop;
};
cheers.
alex
How-To-Repeat:
Fix:
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/127549: [umass] [patch] Meizu MiniPlayer M6 (SL) requires some quirks
The following reply was made to PR usb/127549; it has been noted by GNATS. From: Alexander Best alexbes...@math.uni-muenster.de To: bug-follo...@freebsd.org Cc: Subject: Re: usb/127549: [umass] [patch] Meizu MiniPlayer M6 (SL) requires some quirks Date: Sun, 08 Nov 2009 15:58:25 +0100 (CET) i'm the originator of the pr. using this device under HEAD works without any problems. commit r187163 fixed the issues described in this problem report. apparently the changes to sys/cam/scsi/scsi_da.c in the initial patch weren't necessary and thus weren't committed by thom...@. the changes are also in 8-stable (which was HEAD at the time the fixes got committed). also with r190311/r190310 umass.c and usbdevs in 7-stable got synced with the HEAD versions of those files meaning the fixes are in this branch too. 6-stable is still missing these changes. please mark this pr as patched. thanks. alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/125264: [patch] sysctl for set usb mouse rate (very useful for gamers - FPS games)
The following reply was made to PR usb/125264; it has been noted by GNATS. From: Alexander Best alexbes...@math.uni-muenster.de To: bug-follo...@freebsd.org Cc: Subject: Re: usb/125264: [patch] sysctl for set usb mouse rate (very useful for gamers - FPS games) Date: Sat, 07 Nov 2009 21:08:18 +0100 (CET) since 8 has now become a stable branch the pr can be closed. this feature is dependant upon the usb2 stack an will not be backported to branches 7 and 6 which use the old usb1 stack. alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: device nodes in usb2 stack
Hans Petter Selasky schrieb am 2009-10-19: On Sunday 18 October 2009 23:08:14 Alexander Best wrote: posted this to freebsd-questions@ a while ago and got no answer. alex Hi, For every USB device there is /dev/usb/XXX . Currently the USB Bluetooth driver does not have any file nodes. Entries appearing in devd.conf might not always be matched due to /dev/XXX creation. In that regard the USB stack fakes ugenX.Y device messages for devd.conf. --HPS i see. will this stay the way it is or are there any plans to also add file nodes for usb dongle devices? alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
device nodes in usb2 stack (fwd)
posted this to freebsd-questions@ a while ago and got no answer.
alex
---BeginMessage---
i was wondering why some device nodes appear as regular files under /dev (like
ulpt or da e.g.) and some don't?
if i attach my usb dongle device i get this dmesg output:
ugen1.2: vendor 0x0a12 at usbus1
ubt0: vendor 0x0a12 product 0x0001, class 224/1, rev 2.00/15.93, addr 2 on
usbus1
but no device node gets created under /dev. however the following lines i have
in my /etc/devd.conf work just as expected:
# When a USB Bluetooth dongle appears activate it
attach 100 {
device-name ubt[0-9]+;
action /etc/rc.d/bluetooth quietstart $device-name;
action /usr/local/bin/obexapp -r /var/spool/obex -s -C1;
};
detach 100 {
device-name ubt[0-9]+;
action /etc/rc.d/bluetooth quietstop $device-name;
action /usr/bin/killall obexapp;
};
the device works perfectly, but i'm still wondering why no device node gets
created in /dev. i always thought one of the main unix philosophies was:
everything is a file!.
cheers.
alex
---End Message---
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
mouse behaving strange on high cpu load and rapid movements
hi there, i'm running -CURRENT (i386, r197623). on heavy cpu load i get random copypastes when moving my mouse rapidly. this happens under X as well as on the console. these are the moused options i have in my rc.conf: moused_enable=NO moused_ums0_enable=YES moused_flags=-z4 -a 0.2,0.2 moused_port=/dev/ums0 moused_type=auto this also happens with if i add -F 1000 or -F 500 to the moused_flags. cheers. alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: mouse behaving strange on high cpu load and rapid movements
here's some debug output: ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 f6 1a 00 f6 ff 1a 00 ums_intr_callback:291: x:-10 y:-26 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 fd 19 00 fd ff 19 00 ums_intr_callback:291: x:-3 y:-25 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 04 18 00 04 00 18 00 ums_intr_callback:291: x:4 y:-24 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 0b 17 00 0b 00 17 00 ums_intr_callback:291: x:11 y:-23 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 13 15 00 13 00 15 00 ums_intr_callback:291: x:19 y:-21 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 16 12 00 16 00 12 00 ums_intr_callback:291: x:22 y:-18 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 1c 0e 00 1c 00 0e 00 ums_intr_callback:291: x:28 y:-14 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 54 c5 00 54 00 c5 ff ums_intr_callback:291: x:84 y:59 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 fb f8 00 fb ff f8 ff ums_intr_callback:291: x:-5 y:8 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 fd fa 00 fd ff fa ff ums_intr_callback:291: x:-3 y:6 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 fe fc 00 fe ff fc ff ums_intr_callback:291: x:-2 y:4 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 ff fd 00 ff ff fd ff ums_intr_callback:291: x:-1 y:3 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 00 ff 00 00 00 ff ff ums_intr_callback:291: x:0 y:1 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 00 ff 00 00 00 ff ff ums_intr_callback:291: x:0 y:1 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 00 01 00 00 00 01 00 ums_intr_callback:291: x:0 y:-1 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 00 01 00 00 00 01 00 ums_intr_callback:291: x:0 y:-1 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 ff 01 00 ff ff 01 00 ums_intr_callback:291: x:-1 y:-1 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 00 03 00 00 00 03 00 ums_intr_callback:291: x:0 y:-3 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 ff 03 00 ff ff 03 00 ums_intr_callback:291: x:-1 y:-3 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 ff 03 00 ff ff 03 00 ums_intr_callback:291: x:-1 y:-3 z:0 t:0 w:0 buttons:0x ums_intr_callback:207: sc=0xc95f1800 actlen=8 ums_intr_callback:225: data = 00 ff 00 00 ff ff 00 00 ums_intr_callback:291: x:-1 y:0 z:0 t:0 w:0 buttons:0x cheers. alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/130325: [usb] [patch] fix tools/tools/usb/print-usb-if-vids.sh
The following reply was made to PR usb/130325; it has been noted by GNATS. From: Alexander Best alexbes...@math.uni-muenster.de To: bug-follo...@freebsd.org Cc: Subject: Re: usb/130325: [usb] [patch] fix tools/tools/usb/print-usb-if-vids.sh Date: Wed, 09 Sep 2009 22:13:55 +0200 (CEST) since this is a script the file should have it's executable bit set (755). alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: problem writing to umass device
to end this thread: the problem wasn't caused by the device, but by a problem with certain usb ports. whether this is a bug in the usb stack or faulty hardware remains unclear. alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: problem writing to umass device
hi there. have you had the time to look at this issue? i tested the device under windows xp and it works without any problems. with a recent head copying files to the device still fails at some point with `cp` reporting an input/output error and a lot of failed writes being reported on the console. alex Hans Petter Selasky schrieb am 2009-07-29: On Wednesday 29 July 2009 22:25:05 Alexander Best wrote: i have a problem with the following device: ugen7.2: Meizu Electronics at usbus7 umass0: Meizu Electronics MiniPlayer, class 0/0, rev 2.00/1.00, addr 2 on usbus7 umass0: SCSI over Bulk-Only; quirks = 0x4400 umass0:7:0:-1: Attached to scbus7 da0 at umass-sim0 bus 0 target 0 lun 0 da0:Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 3864MB (7913472 512 byte sectors: 255H 63S/T 492C) i haven't used it for quite a while, but it used to work just fine (yes with usb2). but since then i've updated my kernel a couple of times and now i'm getting these errors. i can mount the device just fine, but if i try to copy files onto it i get the following error messages: Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54083584, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54149120, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54214656, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54280192, length=32768)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54312960, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54329344, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54394880, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54460416, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54525952, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54591488, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54657024, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=512, length=512)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=24576, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=28672, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=1024000, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=1028096, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=38502400, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=39370752, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: fsync: giving up on dirty Jul 28 11:22:07 otaku kernel: 0xcc0aa6b8: tag msdosfs, type VREG Jul 28 11:22:07 otaku kernel: usecount 1, writecount 0, refcount 55 mountedhere 0 Jul 28 11:22:07 otaku kernel: flags () Jul 28 11:22:07 otaku kernel: v_object 0xc8a81770 ref 0 pages 212 Jul 28 11:22:07 otaku kernel: lock type msdosfs: EXCL by thread 0xcc60a240 (pid 19448) Jul 28 11:22:07 otaku kernel: #0 0xc05b5ee0 at __lockmgr_args+0xb90 Jul 28 11:22:07 otaku kernel: #1 0xc0647898 at vop_stdlock+0x68 Jul 28 11:22:07 otaku kernel: #2 0xc0781fb5 at VOP_LOCK1_APV+0xb5 Jul 28 11:22:07 otaku kernel: #3 0xc0664008 at _vn_lock+0x78 Jul 28 11:22:07 otaku kernel: #4 0xc0658adb at vget+0xbb Jul 28 11:22:07 otaku kernel: #5 0xc055d4ca at msdosfs_sync+0x17a Jul 28 11:22:07 otaku kernel: #6 0xc06520be at dounmount+0x44e Jul 28 11:22:07 otaku kernel: #7 0xc065262f at unmount+0x2bf Jul 28 11:22:07 otaku kernel: #8 0xc076eb26 at syscall+0x2a6 Jul 28 11:22:07 otaku kernel: #9 0xc0752ad0 at Xint0x80_syscall+0x20 Jul 28 11:22:07 otaku kernel: startcluster 2230, dircluster 2229, diroffset 96, on dev da0 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=53805056, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=53870592, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=53936128, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54001664, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54067200, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54132736, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54198272, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54263808, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54329344, length=65536)]error = 5 Jul 28 11:22
Re: kernel debugger and usb keyboard
hmm...is it necessary to add any extra options to the kernelconf? because when i hit the panic key-combo under r196037 i'm still not able to use my usb keyboard. i have the following debug related options in my kernelconf: options KDB options BREAK_TO_DEBUGGER options DDB makeoptions DEBUG=-g options INVARIANTS options INVARIANT_SUPPORT options WITNESS options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC options SW_WATCHDOG options KTRACE # ktrace(1) support options SOCKBUF_DEBUG options DEBUG_MEMGUARD legacy usb keyboard support is enabled in the bios so i can use my keyboard at the bootmanager prompt. i did makeworld 4 days ago. is it necessary to make it again in order to have usb/umass support in the kernel debugger? alex Hans Petter Selasky schrieb am 2009-08-03: On Sunday 02 August 2009 23:46:29 Alexander Best wrote: i've seen that there have been some recent changed which deal with this issue. is usb support in the debugger possible with these changes? Yes, UMASS and UKBD should work from the debugger. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: kernel debugger and usb keyboard
to be sure i just updated my sources and rebuild/reinstalled the kernel. i'm now running FreeBSD otaku 8.0-BETA2 FreeBSD 8.0-BETA2 #2 r196050: Mon Aug 3 18:54:46 CEST 2009 r...@otaku:/usr/obj/usr/src/sys/ARUNDEL i386 still when i hit the panic key combo i'm unable to use my usb keyboard in the kernel debugger. alex Hans Petter Selasky schrieb am 2009-08-03: On Monday 03 August 2009 10:08:56 Alexander Best wrote: hmm...is it necessary to add any extra options to the kernelconf? because when i hit the panic key-combo under r196037 i'm still not able to use my usb keyboard. i have the following debug related options in my kernelconf: options KDB options BREAK_TO_DEBUGGER options DDB makeoptions DEBUG=-g options INVARIANTS options INVARIANT_SUPPORT options WITNESS options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC options SW_WATCHDOG options KTRACE # ktrace(1) support options SOCKBUF_DEBUG options DEBUG_MEMGUARD legacy usb keyboard support is enabled in the bios so i can use my keyboard at the bootmanager prompt. i did makeworld 4 days ago. You need to build a kernel newer than friday. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: kernel debugger and usb keyboard
just tried settings `sysctl debug.kdb.panic = 1`. if i use this way to enter the kernel debugger my usb keyboard works. if i type continue however the kernel panics and the kernel debugger gets yet entered again, but without the keyboard working. i don't know how to produce backtraces since the keyboard doesn't work. the other way of entering the debugger without my keyboard working was to simple press ctrl+ast+esc. alex Hans Petter Selasky schrieb am 2009-08-03: On Monday 03 August 2009 20:28:56 Alexander Best wrote: to be sure i just updated my sources and rebuild/reinstalled the kernel. i'm now running FreeBSD otaku 8.0-BETA2 FreeBSD 8.0-BETA2 #2 r196050: Mon Aug 3 18:54:46 CEST 2009 r...@otaku:/usr/obj/usr/src/sys/ARUNDEL i386 still when i hit the panic key combo i'm unable to use my usb keyboard in the kernel debugger. alex This is maybe because the CPU is in the USB stack already. What is the backtrace? If you use the panic sysctl, does the keyboard work then? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: kernel debugger and usb keyboard
thanks a bunch for the info. although usb keyboard support isn't as mature as at keyboard support in the kernel debugger it's good to have some basic support now. cheers. alex Hans Petter Selasky schrieb am 2009-08-03: On Monday 03 August 2009 20:55:16 Alexander Best wrote: just tried settings `sysctl debug.kdb.panic = 1`. if i use this way to enter the kernel debugger my usb keyboard works. if i type continue however the kernel panics and the kernel debugger gets yet entered again, but without the keyboard working. The USB controller which the keyboard is hooked onto will not work after panic has been entered, due to some state not being cleaned up. To increase the chance of the keyboard working on a panic, connect the keyboard to a separate USB controller. i don't know how to produce backtraces since the keyboard doesn't work. Ok. the other way of entering the debugger without my keyboard working was to simple press ctrl+ast+esc. Yes, because most likely the DDB is entered directly from the USB keyboard code, and the USB stack does not allow function recursion in that case! --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: kernel debugger and usb keyboard
i've seen that there have been some recent changed which deal with this issue. is usb support in the debugger possible with these changes? alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: problem writing to umass device
Hans Petter Selasky schrieb am 2009-07-29: On Wednesday 29 July 2009 22:25:05 Alexander Best wrote: i have a problem with the following device: ugen7.2: Meizu Electronics at usbus7 umass0: Meizu Electronics MiniPlayer, class 0/0, rev 2.00/1.00, addr 2 on usbus7 umass0: SCSI over Bulk-Only; quirks = 0x4400 umass0:7:0:-1: Attached to scbus7 da0 at umass-sim0 bus 0 target 0 lun 0 da0:Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 3864MB (7913472 512 byte sectors: 255H 63S/T 492C) i haven't used it for quite a while, but it used to work just fine (yes with usb2). but since then i've updated my kernel a couple of times and now i'm getting these errors. i can mount the device just fine, but if i try to copy files onto it i get the following error messages: Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54083584, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54149120, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54214656, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54280192, length=32768)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54312960, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54329344, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54394880, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54460416, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54525952, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54591488, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54657024, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=512, length=512)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=24576, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=28672, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=1024000, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=1028096, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=38502400, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=39370752, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: fsync: giving up on dirty Jul 28 11:22:07 otaku kernel: 0xcc0aa6b8: tag msdosfs, type VREG Jul 28 11:22:07 otaku kernel: usecount 1, writecount 0, refcount 55 mountedhere 0 Jul 28 11:22:07 otaku kernel: flags () Jul 28 11:22:07 otaku kernel: v_object 0xc8a81770 ref 0 pages 212 Jul 28 11:22:07 otaku kernel: lock type msdosfs: EXCL by thread 0xcc60a240 (pid 19448) Jul 28 11:22:07 otaku kernel: #0 0xc05b5ee0 at __lockmgr_args+0xb90 Jul 28 11:22:07 otaku kernel: #1 0xc0647898 at vop_stdlock+0x68 Jul 28 11:22:07 otaku kernel: #2 0xc0781fb5 at VOP_LOCK1_APV+0xb5 Jul 28 11:22:07 otaku kernel: #3 0xc0664008 at _vn_lock+0x78 Jul 28 11:22:07 otaku kernel: #4 0xc0658adb at vget+0xbb Jul 28 11:22:07 otaku kernel: #5 0xc055d4ca at msdosfs_sync+0x17a Jul 28 11:22:07 otaku kernel: #6 0xc06520be at dounmount+0x44e Jul 28 11:22:07 otaku kernel: #7 0xc065262f at unmount+0x2bf Jul 28 11:22:07 otaku kernel: #8 0xc076eb26 at syscall+0x2a6 Jul 28 11:22:07 otaku kernel: #9 0xc0752ad0 at Xint0x80_syscall+0x20 Jul 28 11:22:07 otaku kernel: startcluster 2230, dircluster 2229, diroffset 96, on dev da0 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=53805056, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=53870592, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=53936128, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54001664, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54067200, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54132736, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54198272, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54263808, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54329344, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54394880, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54460416, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54525952, length=65536)]error = 5 might the device's
Re: problem writing to umass device
seems i need to reboot. since i wasn't able to unmount the device i unplugged it and tried plugging it in again. but it doesn't get recognised at all. no attach message or anything like that even after attaching it to a different usb port. i'm sure at the end the only option is to trigger the reset button. doing `reboot` hangs after the message all disks synched. although the message is being displayed the synched disks don't get marked as clean, because after a reboot all my harddrives are being being fsck'ed because they weren't dismounted properly. oh...and btw: if i try `umount /mnt/umass` after detaching the device umount prints this: Jul 29 23:08:42 otaku kernel: g_vfs_done():da0[WRITE(offset=16384, length=4096)]error = 6 then it hangs forever. killing the umount process isn't possible. alex Hans Petter Selasky schrieb am 2009-07-29: On Wednesday 29 July 2009 22:25:05 Alexander Best wrote: i have a problem with the following device: ugen7.2: Meizu Electronics at usbus7 umass0: Meizu Electronics MiniPlayer, class 0/0, rev 2.00/1.00, addr 2 on usbus7 umass0: SCSI over Bulk-Only; quirks = 0x4400 umass0:7:0:-1: Attached to scbus7 da0 at umass-sim0 bus 0 target 0 lun 0 da0:Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 3864MB (7913472 512 byte sectors: 255H 63S/T 492C) i haven't used it for quite a while, but it used to work just fine (yes with usb2). but since then i've updated my kernel a couple of times and now i'm getting these errors. i can mount the device just fine, but if i try to copy files onto it i get the following error messages: Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54083584, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54149120, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54214656, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54280192, length=32768)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54312960, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54329344, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54394880, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54460416, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54525952, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54591488, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54657024, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=512, length=512)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=24576, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=28672, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=1024000, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=1028096, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=38502400, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=39370752, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: fsync: giving up on dirty Jul 28 11:22:07 otaku kernel: 0xcc0aa6b8: tag msdosfs, type VREG Jul 28 11:22:07 otaku kernel: usecount 1, writecount 0, refcount 55 mountedhere 0 Jul 28 11:22:07 otaku kernel: flags () Jul 28 11:22:07 otaku kernel: v_object 0xc8a81770 ref 0 pages 212 Jul 28 11:22:07 otaku kernel: lock type msdosfs: EXCL by thread 0xcc60a240 (pid 19448) Jul 28 11:22:07 otaku kernel: #0 0xc05b5ee0 at __lockmgr_args+0xb90 Jul 28 11:22:07 otaku kernel: #1 0xc0647898 at vop_stdlock+0x68 Jul 28 11:22:07 otaku kernel: #2 0xc0781fb5 at VOP_LOCK1_APV+0xb5 Jul 28 11:22:07 otaku kernel: #3 0xc0664008 at _vn_lock+0x78 Jul 28 11:22:07 otaku kernel: #4 0xc0658adb at vget+0xbb Jul 28 11:22:07 otaku kernel: #5 0xc055d4ca at msdosfs_sync+0x17a Jul 28 11:22:07 otaku kernel: #6 0xc06520be at dounmount+0x44e Jul 28 11:22:07 otaku kernel: #7 0xc065262f at unmount+0x2bf Jul 28 11:22:07 otaku kernel: #8 0xc076eb26 at syscall+0x2a6 Jul 28 11:22:07 otaku kernel: #9 0xc0752ad0 at Xint0x80_syscall+0x20 Jul 28 11:22:07 otaku kernel: startcluster 2230, dircluster 2229, diroffset 96, on dev da0 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=53805056, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=53870592, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=53936128, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54001664, length=65536)]error = 5 Jul 28
Re: problem writing to umass device
damn. just say that i overlooked the minus. so instead of setting sysctl hw.usb.umass.debug=-1 i did in fact do sysctl hw.usb.umass.debug=1. sorry for that. i'll send you a new output after i'm done blanking and reformatting the umass device. alex Hans Petter Selasky schrieb am 2009-07-29: On Wednesday 29 July 2009 22:25:05 Alexander Best wrote: i have a problem with the following device: ugen7.2: Meizu Electronics at usbus7 umass0: Meizu Electronics MiniPlayer, class 0/0, rev 2.00/1.00, addr 2 on usbus7 umass0: SCSI over Bulk-Only; quirks = 0x4400 umass0:7:0:-1: Attached to scbus7 da0 at umass-sim0 bus 0 target 0 lun 0 da0:Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 3864MB (7913472 512 byte sectors: 255H 63S/T 492C) i haven't used it for quite a while, but it used to work just fine (yes with usb2). but since then i've updated my kernel a couple of times and now i'm getting these errors. i can mount the device just fine, but if i try to copy files onto it i get the following error messages: Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54083584, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54149120, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54214656, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54280192, length=32768)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54312960, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54329344, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54394880, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54460416, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54525952, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54591488, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54657024, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=512, length=512)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=24576, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=28672, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=1024000, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=1028096, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=38502400, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=39370752, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: fsync: giving up on dirty Jul 28 11:22:07 otaku kernel: 0xcc0aa6b8: tag msdosfs, type VREG Jul 28 11:22:07 otaku kernel: usecount 1, writecount 0, refcount 55 mountedhere 0 Jul 28 11:22:07 otaku kernel: flags () Jul 28 11:22:07 otaku kernel: v_object 0xc8a81770 ref 0 pages 212 Jul 28 11:22:07 otaku kernel: lock type msdosfs: EXCL by thread 0xcc60a240 (pid 19448) Jul 28 11:22:07 otaku kernel: #0 0xc05b5ee0 at __lockmgr_args+0xb90 Jul 28 11:22:07 otaku kernel: #1 0xc0647898 at vop_stdlock+0x68 Jul 28 11:22:07 otaku kernel: #2 0xc0781fb5 at VOP_LOCK1_APV+0xb5 Jul 28 11:22:07 otaku kernel: #3 0xc0664008 at _vn_lock+0x78 Jul 28 11:22:07 otaku kernel: #4 0xc0658adb at vget+0xbb Jul 28 11:22:07 otaku kernel: #5 0xc055d4ca at msdosfs_sync+0x17a Jul 28 11:22:07 otaku kernel: #6 0xc06520be at dounmount+0x44e Jul 28 11:22:07 otaku kernel: #7 0xc065262f at unmount+0x2bf Jul 28 11:22:07 otaku kernel: #8 0xc076eb26 at syscall+0x2a6 Jul 28 11:22:07 otaku kernel: #9 0xc0752ad0 at Xint0x80_syscall+0x20 Jul 28 11:22:07 otaku kernel: startcluster 2230, dircluster 2229, diroffset 96, on dev da0 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=53805056, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=53870592, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=53936128, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54001664, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54067200, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54132736, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54198272, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54263808, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54329344, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54394880
Re: problem writing to umass device
kern.cam.da.da_send_ordered: 1 kern.cam.da.default_timeout: 60 kern.cam.da.retry_count: 4 kern.cam.da.0.minimum_cmd_size: 10 i guess the next line would have been usb related. cheers. alex Hans Petter Selasky schrieb am 2009-07-29: On Wednesday 29 July 2009 22:25:05 Alexander Best wrote: i have a problem with the following device: ugen7.2: Meizu Electronics at usbus7 umass0: Meizu Electronics MiniPlayer, class 0/0, rev 2.00/1.00, addr 2 on usbus7 umass0: SCSI over Bulk-Only; quirks = 0x4400 umass0:7:0:-1: Attached to scbus7 da0 at umass-sim0 bus 0 target 0 lun 0 da0:Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 3864MB (7913472 512 byte sectors: 255H 63S/T 492C) i haven't used it for quite a while, but it used to work just fine (yes with usb2). but since then i've updated my kernel a couple of times and now i'm getting these errors. i can mount the device just fine, but if i try to copy files onto it i get the following error messages: Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54083584, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54149120, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54214656, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54280192, length=32768)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54312960, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54329344, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54394880, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54460416, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54525952, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54591488, length=65536)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=54657024, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=512, length=512)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=24576, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=28672, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=1024000, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=1028096, length=4096)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=38502400, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: g_vfs_done():da0[WRITE(offset=39370752, length=16384)]error = 5 Jul 28 11:22:07 otaku kernel: fsync: giving up on dirty Jul 28 11:22:07 otaku kernel: 0xcc0aa6b8: tag msdosfs, type VREG Jul 28 11:22:07 otaku kernel: usecount 1, writecount 0, refcount 55 mountedhere 0 Jul 28 11:22:07 otaku kernel: flags () Jul 28 11:22:07 otaku kernel: v_object 0xc8a81770 ref 0 pages 212 Jul 28 11:22:07 otaku kernel: lock type msdosfs: EXCL by thread 0xcc60a240 (pid 19448) Jul 28 11:22:07 otaku kernel: #0 0xc05b5ee0 at __lockmgr_args+0xb90 Jul 28 11:22:07 otaku kernel: #1 0xc0647898 at vop_stdlock+0x68 Jul 28 11:22:07 otaku kernel: #2 0xc0781fb5 at VOP_LOCK1_APV+0xb5 Jul 28 11:22:07 otaku kernel: #3 0xc0664008 at _vn_lock+0x78 Jul 28 11:22:07 otaku kernel: #4 0xc0658adb at vget+0xbb Jul 28 11:22:07 otaku kernel: #5 0xc055d4ca at msdosfs_sync+0x17a Jul 28 11:22:07 otaku kernel: #6 0xc06520be at dounmount+0x44e Jul 28 11:22:07 otaku kernel: #7 0xc065262f at unmount+0x2bf Jul 28 11:22:07 otaku kernel: #8 0xc076eb26 at syscall+0x2a6 Jul 28 11:22:07 otaku kernel: #9 0xc0752ad0 at Xint0x80_syscall+0x20 Jul 28 11:22:07 otaku kernel: startcluster 2230, dircluster 2229, diroffset 96, on dev da0 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=53805056, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=53870592, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=53936128, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54001664, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54067200, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54132736, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54198272, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54263808, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54329344, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0[WRITE(offset=54394880, length=65536)]error = 5 Jul 28 11:22:40 otaku kernel: g_vfs_done():da0
kernel debugger and usb keyboard
if i understood it correctly the reason a usb keyboard cannot be used in the kernel debugger after a panic is that we can't be sure the panic didn't happen inside the usb stack so the whole usb stack is discarded at a panic. maybe this would be a solution: modern bioses support an option called legcy usb keyboard support. the way i understood it is that the bios grabs usb keyboard events and uses them to emulate an AT keyboard. that way e.g. a bootloader can the used with a usb keyboard although there's no usb stack or whatever in the bootloader. when the kernel boots the usb stack takes control over the usb keyboard and the bios keyboard legacy support gets disabled. couldn't we revert to this stage after a panic occurs? letting the bios take control over the usb keyboard again and emulate an AT keyboard? alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: kernel debugger and usb keyboard
just found this wiki: http://wiki.freebsd.org/USBTODO so making ukbd giant free has a high priority? very nice. :) alex Hans Petter Selasky schrieb am 2009-07-16: On Thursday 16 July 2009 10:43:26 Alexander Best wrote: if i understood it correctly the reason a usb keyboard cannot be used in the kernel debugger after a panic is that we can't be sure the panic didn't happen inside the usb stack so the whole usb stack is discarded at a panic. The USB keyboard can be used in the debugger, if the ukbd is made free from Giant. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: settings usb mouse rate
here's your reminder. *riiing* ;) alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
power_off/power_on with usb mouse/keyboard and hald
when i do `usbconfig power_off` and usbconfig power_on` with my usb keayboard/mouse it won't come up again in X. i suspect this is due to hald managing both devices. to get the devices running again under X without restarting it i have to unplug them then plug them in again. after that i need to switch to the console once and then back again to X. otherwise no keyboard input is being processed. also on a side note i noticed the following: when doing `usbconfig -u X -a Y suspend; usbconfig -u X -a Y resume` on a keyboard the very first keystroke doesn't get processed. so issuing the command sequence and typing hello results in ello being displayed on the console. alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: settings usb mouse rate
thx for the patch. i'm recompiling my kernel right now and will test the changes right away. any reason you limited the rate to = 1000? i had a quick look at the specs of my mouse: - 6400 frames per second (5.8 megapixels per second) - 1800dpi Razer Precision 3G infrared sensor what about the mouse resolution? moused comes has the -r switch to change it. would usb mice benefit from that option? cheers. alex Hans Petter Selasky schrieb am 2009-07-14: Hi, The patch is in. http://perforce.freebsd.org/chv.cgi?CH=166075 Please try rates from moused -F 1 XXX to moused -F 1000 XXX. Check that the rate is actually set by enabling ums debugging: sysctl hw.usb.ums.debug=15 --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: settings usb mouse rate
you were right. i attached a different usb mouse and setting the rate to 10 or 100 didn't cause the random copypaste issue. what's the reason the usb polling rate is limited to 1000? performance? because gaming devices feature a very high rate. would be great to have full support for them. i've seen laser mice with a rate of 10.000. i've attached the output of hw.usb.ums.debug=15 and included a note where the copypaste occured. however when the debug output is enabled the random copypaste issue doesn't appear that often. if a disable the debug output ~ 2 lines per second get pasted to the console when moving the mouse. alex Hans Petter Selasky schrieb am 2009-07-14: On Tuesday 14 July 2009 15:25:59 Alexander Best wrote: i tested the patch with rates of 1, 100 and 1000: 1: random copypastes when moving the mouse 100: also random copypastes when moving the mouse 1000: OK Could you try another USB mouse. Also I would like to see some ums debug prints when you see random mouse clicks. I'm not sure, but probably your mouse expects a certain minimum polling rate, which is passed through the endpoint descriptor, else it goes mad :-) setting hw.usb.ums.debug=15 indicates that the polling rate is set exactly to moused's -F value. Good. at some point i experienced a crash including a reboot. no core dump was produced however. i've tried to reproduce the crash but wasn't able to. i think the crash occured when i booted with a low -F value, then set -F to a higher value in /etc/rc.conf and after that unplugged the mouse and plugged it in again. as i said i'm not able to produce the panic any longer. might have been caused by old code fragments in my /usr/src. --HPS rates.log Description: Binary data ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: settings usb mouse rate
thanks for the info. so right now i'm running the patched kernel with no problems whatsoever. mouse is running smoothly with a rate of 1000. only values 100 cause the issue i mentioned beforehand with this mouse. unfortnunately i lost the manual, but i think two of the buttons on this mouse are meant to control the rate. i don't know if their're output is just being caught by some windows driver-app or if the buttons control the mouse rate internaly. here's the output when pressing both buttons: Jul 14 19:39:54 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:54 otaku kernel: ums_intr_callback:224: data = 00 00 00 00 00 00 00 00 Jul 14 19:39:55 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:55 otaku kernel: ums_intr_callback:224: data = 00 00 00 01 00 00 00 00 Jul 14 19:39:55 otaku kernel: ums_intr_callback:282: x:0 y:0 z:-1 t:0 w:0 buttons:0x Jul 14 19:39:55 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:55 otaku kernel: ums_intr_callback:224: data = 00 00 00 00 00 00 00 00 Jul 14 19:39:55 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:55 otaku kernel: ums_intr_callback:224: data = 00 00 00 ff 00 00 00 00 Jul 14 19:39:55 otaku kernel: ums_intr_callback:282: x:0 y:0 z:1 t:0 w:0 buttons:0x Jul 14 19:39:55 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:55 otaku kernel: ums_intr_callback:224: data = 00 00 00 00 00 00 00 00 Jul 14 19:39:56 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:56 otaku kernel: ums_intr_callback:224: data = 00 00 00 ff 00 00 00 00 Jul 14 19:39:56 otaku kernel: ums_intr_callback:282: x:0 y:0 z:1 t:0 w:0 buttons:0x Jul 14 19:39:56 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:56 otaku kernel: ums_intr_callback:224: data = 00 00 00 00 00 00 00 00 Jul 14 19:39:56 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:56 otaku kernel: ums_intr_callback:224: data = 00 00 00 ff 00 00 00 00 Jul 14 19:39:56 otaku kernel: ums_intr_callback:282: x:0 y:0 z:1 t:0 w:0 buttons:0x Jul 14 19:39:56 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:56 otaku kernel: ums_intr_callback:224: data = 00 00 00 00 00 00 00 00 Jul 14 19:39:56 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:56 otaku kernel: ums_intr_callback:224: data = 00 00 00 ff 00 00 00 00 Jul 14 19:39:56 otaku kernel: ums_intr_callback:282: x:0 y:0 z:1 t:0 w:0 buttons:0x Jul 14 19:39:56 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:56 otaku kernel: ums_intr_callback:224: data = 00 00 00 00 00 00 00 00 alex Hans Petter Selasky schrieb am 2009-07-14: On Tuesday 14 July 2009 18:29:33 Alexander Best wrote: you were right. i attached a different usb mouse and setting the rate to 10 or 100 didn't cause the random copypaste issue. what's the reason the usb polling rate is limited to 1000? performance? because gaming devices feature a very high rate. would be great to have full support for them. i've seen laser mice with a rate of 10.000. The USB hardware cannot poll more than 1000 times per second on INTERRUPT endpoints typically. Using a BULK endpoint you can at maximum poll 8000 times per second. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
settings usb mouse rate
i found this very cool PR http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/125264 and wanted to ask if there's a way of changing the rate of usb mice with the new usb2 stack? what about the `moused` switches -r and -F? do they work with usb mice? alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
detaching usb device without unmounting it
since the usb2 stack allows one to detach a mounted usb device without the kernel panic'ing i'd like to know which steps are necessary to be taken after detaching a device? because i tried the following: 1. attach device 2. mount device 3. detach device when i tried to unmount the device i got the follwing error message: g_vfs_done():label/usb[WRITE(offset=19456, length=4096)]error = 6 and the console got locked up (ctr+c didn't work). so i tried to reboot using ctrl+alt+del. however after the message: All buffers synced there was no reboot. so i had to do a hard reset. however after the reset freebsd fsck'ed my harddrives. so they didn't unmount properly. should i have used `umount -f`? or just plug the device back in again? or isn't it possible to unmount a device that has already been detached? i'm running r195476 btw. alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: detaching usb device without unmounting it
actually i'm running current: FreeBSD otaku 8.0-BETA1 FreeBSD 8.0-BETA1 #0 r195534: Fri Jul 10 11:52:48 CEST 2009 r...@otaku:/usr/obj/usr/src/sys/ARUNDEL i386 updated my kernel sources a few hours ago. should i report this to the freebsd-current@ list then? alex Hans Petter Selasky schrieb am 2009-07-10: This is not an USB issue. Try -current. --HPS On Friday 10 July 2009 11:05:48 Alexander Best wrote: since the usb2 stack allows one to detach a mounted usb device without the kernel panic'ing i'd like to know which steps are necessary to be taken after detaching a device? because i tried the following: 1. attach device 2. mount device 3. detach device when i tried to unmount the device i got the follwing error message: g_vfs_done():label/usb[WRITE(offset=19456, length=4096)]error = 6 and the console got locked up (ctr+c didn't work). so i tried to reboot using ctrl+alt+del. however after the message: All buffers synced there was no reboot. so i had to do a hard reset. however after the reset freebsd fsck'ed my harddrives. so they didn't unmount properly. should i have used `umount -f`? or just plug the device back in again? or isn't it possible to unmount a device that has already been detached? i'm running r195476 btw. alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: detaching usb device without unmounting it
oh. i just did. ;-) didn't see you put freebsd-current@ in the To: field. alex Hans Petter Selasky schrieb am 2009-07-10: This is not an USB issue. Try -current. --HPS On Friday 10 July 2009 11:05:48 Alexander Best wrote: since the usb2 stack allows one to detach a mounted usb device without the kernel panic'ing i'd like to know which steps are necessary to be taken after detaching a device? because i tried the following: 1. attach device 2. mount device 3. detach device when i tried to unmount the device i got the follwing error message: g_vfs_done():label/usb[WRITE(offset=19456, length=4096)]error = 6 and the console got locked up (ctr+c didn't work). so i tried to reboot using ctrl+alt+del. however after the message: All buffers synced there was no reboot. so i had to do a hard reset. however after the reset freebsd fsck'ed my harddrives. so they didn't unmount properly. should i have used `umount -f`? or just plug the device back in again? or isn't it possible to unmount a device that has already been detached? i'm running r195476 btw. alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: settings usb mouse rate
ok. thanks. alex Hans Petter Selasky schrieb am 2009-07-10: On Friday 10 July 2009 09:26:00 Alexander Best wrote: i found this very cool PR http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/125264 and wanted to ask if there's a way of changing the rate of usb mice with the new usb2 stack? what about the `moused` switches -r and -F? do they work with usb mice? I think this patch is not included in 8-current. I might put a modified patch in. Remind me about it next week and I'll see about getting it done! --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: detaching usb device without unmounting it
hmmm...i just tried that: 1. attach the device 2. mount the device @ mnt/umass 3. detach the device 4. do `umount -f /mnt/umass` i got the same error message i got when not using the f switch. also i forget to mention this lor: Jul 10 16:26:24 otaku kernel: lock order reversal: Jul 10 16:26:24 otaku kernel: 1st 0xc81569c0 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1199 Jul 10 16:26:24 otaku kernel: 2nd 0xc8dec9c0 devfs (devfs) @ /usr/src/sys/fs/msdosfs/msdosfs_vfsops.c:944 Jul 10 16:26:24 otaku kernel: KDB: stack backtrace: Jul 10 16:26:24 otaku kernel: db_trace_self_wrapper(c07d787b,ea61ca3c,c0609a25,c05fa4db,c07da81e,...) at db_trace_self_wrapper+0x26 Jul 10 16:26:24 otaku kernel: kdb_backtrace(c05fa4db,c07da81e,c78f0bc0,c78f0af0,ea61ca98,...) at kdb_backtrace+0x29 Jul 10 16:26:24 otaku kernel: _witness_debugger(c07da81e,c8dec9c0,c07c9650,c78f0af0,c07c9f08,...) at _witness_debugger+0x25 Jul 10 16:26:24 otaku kernel: witness_checkorder(c8dec9c0,9,c07c9f08,3b0,c8deca28,...) at witness_checkorder+0x839 Jul 10 16:26:24 otaku kernel: __lockmgr_args(c8dec9c0,80400,c8deca28,0,0,...) at __lockmgr_args+0x7b7 Jul 10 16:26:24 otaku kernel: vop_stdlock(ea61cba0,c09abbc8,c8a8ee24,80400,c8dec968,...) at vop_stdlock+0x68 Jul 10 16:26:24 otaku kernel: VOP_LOCK1_APV(c0820980,ea61cba0,ea61cbc0,c0853f80,c8dec968,...) at VOP_LOCK1_APV+0xb5 Jul 10 16:26:24 otaku kernel: _vn_lock(c8dec968,80400,c07c9f08,3b0,c7ea35a0,...) at _vn_lock+0x78 Jul 10 16:26:24 otaku kernel: msdosfs_sync(c7ea35a0,1,ea61cc38,4f4,80,...) at msdosfs_sync+0x29c Jul 10 16:26:24 otaku kernel: dounmount(c7ea35a0,808,c8a8ed80,479,1,...) at dounmount+0x44e Jul 10 16:26:24 otaku kernel: unmount(c8a8ed80,ea61ccf8,8,65,c,...) at unmount+0x2bf Jul 10 16:26:24 otaku kernel: syscall(ea61cd38) at syscall+0x2a6 Jul 10 16:26:24 otaku kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 10 16:26:24 otaku kernel: --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d730f, esp = 0xbfbfe4bc, ebp = 0xbfbfe588 --- again i can't get back to the shell using ctrl+c. switching to another console and issuing a reboot stalls at the very same point. alex M. Warner Losh schrieb am 2009-07-10: In message: permail-20090710090548f7e55a9d3ae0-a_bes...@message-id.uni-muenster.de Alexander Best alexbes...@math.uni-muenster.de writes: : since the usb2 stack allows one to detach a mounted usb device without the : kernel panic'ing usb1 allowed that too. the problem rarely was inside the usb stack (although there were some problems). The problem was at the higher levels of cam, the buffer cache and the file system. There were changes scattered throughout the rest of the system to allow devices to suddenly disappear. All usb2 did was fix a few edge cases in usb. : i'd like to know which steps are necessary to be taken after : detaching a device? because i tried the following: : : 1. attach device : 2. mount device : 3. detach device : : when i tried to unmount the device i got the follwing error message: : : g_vfs_done():label/usb[WRITE(offset=19456, length=4096)]error = 6 The proper action is limited to 'umount -f'. You can't reattach it, you can't really touch any files in the system (some cached files might be ok), you certainly can't write to it. : and the console got locked up (ctr+c didn't work). so i tried to reboot using : ctrl+alt+del. however after the message: All buffers synced there was no : reboot. so i had to do a hard reset. however after the reset freebsd fsck'ed : my harddrives. so they didn't unmount properly. : : should i have used `umount -f`? or just plug the device back in again? or : isn't it possible to unmount a device that has already been detached? You should have done an umount -f. You can't plug it back in again because we don't have support at the right levels (CAM(?), GEOM, buffer cache, fs) to allow previously orphaned resources to be reconnected to a new device. The device was destroyed, and data was destroyed with it... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/127549: [umass] [patch] Meizu MiniPlayer M6 (SL) requires some quirks
The following reply was made to PR usb/127549; it has been noted by GNATS. From: Alexander Best alexbes...@math.uni-muenster.de To: bug-follo...@freebsd.org Cc: Subject: Re: usb/127549: [umass] [patch] Meizu MiniPlayer M6 (SL) requires some quirks Date: Sat, 13 Jun 2009 19:32:00 +0200 (CEST) the patch is in -CURRENT and probably -STABLE. the PR can be closed. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Suspend failed
hi there, i'm using the following commands to deactivate and activate my mouse: usbconfig -u 1 -a 3 power_off usbconfig -u 1 -a 3 power_on which works great. if i issue the commands shortly after another this is what happens: ums0: at uhub1, port 2, addr 3 (disconnected) ums0: Razer Razer 1600dpi Mouse, class 0/0, rev 2.00/21.00, addr 3 on usbus1 ums0: 7 buttons and [XYZ] coordinates ID=0 however. if i wait for some time before re-activating the mouse it flashes twice and this is what dmesg says: ums0: at uhub1, port 2, addr 3 (disconnected) ums0: Razer Razer 1600dpi Mouse, class 0/0, rev 2.00/21.00, addr 3 on usbus1 ums0: 7 buttons and [XYZ] coordinates ID=0 ums0: Suspend failed the Suspend failed warning however isn't causing any problems. the mouse attaches just fine. i'm running r191076 (-CURRENT/usb2). cheers. alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Suspend failed
thx a bunch. i'll check out the patches and see if that makes the warning go away. cheers. alex Hans Petter Selasky schrieb am 2009-04-16: On Thursday 16 April 2009, Alexander Best wrote: hi there, i'm using the following commands to deactivate and activate my mouse: usbconfig -u 1 -a 3 power_off usbconfig -u 1 -a 3 power_on which works great. if i issue the commands shortly after another this is what happens: ums0: at uhub1, port 2, addr 3 (disconnected) ums0: Razer Razer 1600dpi Mouse, class 0/0, rev 2.00/21.00, addr 3 on usbus1 ums0: 7 buttons and [XYZ] coordinates ID=0 however. if i wait for some time before re-activating the mouse it flashes twice and this is what dmesg says: ums0: at uhub1, port 2, addr 3 (disconnected) ums0: Razer Razer 1600dpi Mouse, class 0/0, rev 2.00/21.00, addr 3 on usbus1 ums0: 7 buttons and [XYZ] coordinates ID=0 ums0: Suspend failed the Suspend failed warning however isn't causing any problems. the mouse attaches just fine. i'm running r191076 (-CURRENT/usb2). Try these patches: http://perforce.freebsd.org/chv.cgi?CH=160485 http://perforce.freebsd.org/chv.cgi?CH=160413 --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Suspend failed
thanks. i'm compiling the kernel right now with all the patches in place. i had to get the following files from p4, because they don't seem to exist in -CURRENT: //depot/projects/usb/src/sys/dev/usb/usb_sw_transfer.c //depot/projects/usb/src/sys/dev/usb/usb_sw_transfer.h alex Hans Petter Selasky schrieb am 2009-04-16: On Thursday 16 April 2009, Alexander Best wrote: thx a bunch. i'll check out the patches and see if that makes the warning go away. And this one. http://perforce.freebsd.org/chv.cgi?CH=160614 Try these patches: http://perforce.freebsd.org/chv.cgi?CH=160485 http://perforce.freebsd.org/chv.cgi?CH=160413 --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Suspend failed
after recompiling the kernel the warning disappeared. :-) however there still seems to be a difference between turning the power off and on again shortly after another and waiting some time before turning the power on again. my mouse comes with a blue LED. when i do power_off the light goes out. when i do power_on directly afterwards the LED goes on. if i wait for an hour or so before doing power_on the LED goes on, then off again and then on again. cheers. alex Hans Petter Selasky schrieb am 2009-04-16: On Thursday 16 April 2009, Alexander Best wrote: thx a bunch. i'll check out the patches and see if that makes the warning go away. And this one. http://perforce.freebsd.org/chv.cgi?CH=160614 Try these patches: http://perforce.freebsd.org/chv.cgi?CH=160485 http://perforce.freebsd.org/chv.cgi?CH=160413 --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Low perfomance when read from usb flash drive
i'm getting 1+0 records in 1+0 records out 65536 bytes transferred in 54.169996 secs (12098210 bytes/sec) running r191076. alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: problem with usb printer
to be sure i updated my sources using `svn up /usr/src` then reverted back to the repository files in order to get rid of any previously patched files using `svn -R revert /usr/src` and the applied the patch you send me. the result is the same: only the top of the page get's printed. that's it. the printer signals an error. at this point i need to turn off the printer and turn it on again in order to use it again. if i try to print another page without restarting the printer usb becomes unusable. i've attached my kernel config and my make.conf. maybe there's a problem there. cheers. Hans Petter Selasky schrieb am 2009-03-16: Hi Alexander, There are now multiple outstanding patches. Are you sure you applied all of them? I've attached a diff between -current and USB P4. Some patches might fail regarding the RCS-ID changes. --HPS arundel Description: Binary data make.conf Description: Binary data ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: problem with usb printer
i applied the patches. now every time i try to print something the printer indicates an error (red light blinking). i can however turn off the printer and then turn it on again with the printer getting detached and attached properly. if i try to print something after the first attempt to print the issue i described beforehand occurs. cupsd cannot be killed and usb devices cannot be attached/detached. running lp* and usbconfig doesn't work anymore. i need to reboot. cheers. Hans Petter Selasky schrieb am 2009-03-15: Hi, I have been able to reproduce the issue over here on an USB printer. Try this patch in addition to the previous ones: http://perforce.freebsd.org/chv.cgi?CH=159241 --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: problem with usb printer
i recompiled my kernel using the usb1 stack and was able to print a perfect testpage. i was able to print using the gdi driver (ulpt and unlpt) and printing with the splix2 driver also works. the splix version from the ports dir doesn't work for some reason. i now installed 4 printers in cups: splix2 (ulpt and unlpt) and gdi (ulpt and unlpt). i'll try to recompile my kernel (usb2) with and without the patches and see if one of those combinations works. cheers. Hans Petter Selasky schrieb am 2009-03-15: On Sunday 15 March 2009, Alexander Best wrote: i recompiled my kernel with the p4-files, but still nothing get's printed. this is what i get when attaching the device: ugen0.3: Samsung Electronics Co., Ltd. at usbus0 ulpt_probe:472: ulpt_attach:498: sc=0xc5a4c900 ulpt0: Samsung Electronics Co., Ltd. Samsung ML-1510_700, class 0/0, rev 1.10/1.00, addr 3 on usbus0 ulpt_attach:538: setting alternate config number: 0 ulpt0: using bi-directional mode and this when i try to print something: ulpt_reset:164: ulpt_write_callback:203: state=0x0 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x1 Looks good. Try also: sysctl hw.usb2.dev.debug=15 While printing and see if there is a drain in the end! i also enabled debugging output in the cups config file, but that didn't reveal any errors. right now i'm trying to build a kernel with the old usb stack to see if the problem get's solved. if the problem then still exists cups must be causing the problems. unfortunately building the kernel with the old usb stack fails: Did it work before? The only thing I can imagine is that the flushing/drain mechanism is not working, after that the last byte has been written. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: problem with usb printer
alright. i've tried various patches and cups drivers. the only combination that slightly works is a kernel with both patchsets in combination with the splix2 driver. alls other combinations of patches and drivers fail without a page being printed and causing the printer to signal an error. with the two patchsets and the splix2 driver i'm able to print about 5% of the testpage. the paper is almost completely empty. only a a little bit of the testpage is being printed onto the top of the page. after ejecting the page the printer signals an error. with the usb1-stack the whole testpage get's printed and the printer stays operational afterwards. also the gdi driver works just like the splix2 driver without any problems. using the usb2-stack the gdi driver causes the printer to signal an error without anything being printed. alex Hans Petter Selasky schrieb am 2009-03-15: Hi, I have been able to reproduce the issue over here on an USB printer. Try this patch in addition to the previous ones: http://perforce.freebsd.org/chv.cgi?CH=159241 --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
problem with usb printer
hi there. i'm having a problem with my usb printer. it's being recognised as ulpt0, but i cannot print. i'm using the cups port for printing. i've set hw.usb2.ulpt.debug=15 and this is the output: uhub_reattach_port:348: port 2 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port:434: device problem (USB_ERR_TIMEOUT), disabling port 2 ugen0.3: Samsung Electronics Co., Ltd. at usbus0 ulpt_probe:472: ulpt_attach:498: sc=0xc6f6be80 ulpt0: Samsung Electronics Co., Ltd. Samsung ML-1510_700, class 0/0, rev 1.10/1.00, addr 3 on usbus0 ulpt_attach:538: setting alternate config number: 0 ulpt0: using bi-directional mode ulpt_reset:164: ulpt_write_callback:203: state=0x0 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x2 after turning off the device i constantly get this output: ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED the cups daemon cannot be stopped (even with kill -9) and none of the lp* apps work anymore. also i'm not able to attach any new usb devices. so a reboot is the only solution that worked in order to get my computer fully operational again. i'm running: FreeBSD moshnroll 8.0-CURRENT FreeBSD 8.0-CURRENT #6 r189789M: Sat Mar 14 13:37:49 UTC 2009 r...@moshnroll:/usr/obj/usr/src/sys/ARUNDEL i386 cheers. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: problem with usb printer
what do you mean by reset the device? turning it off and on again? nothing! there's no detach notice or attach notice being printed to the console. what actually happens is this: when i try to print a testpage from the cups web interface it says Processing page 1 however the print job doesn't get printed. what happens is that a red light on my printer starts flashing telling me that there's an error. if i try to print the testpage another time the whole web interface stops responding. if i run commands like lp or lpq the apps just hang. also running usbconfig lust let's the application hang. if i turn off the printer the console get's flooded with the ulpt_status_callback:328: error=USB_ERR_STALLED message. before flooding the console with those warnings this one get's printed out: ulpt_write_callback:203: state=0x2 if i reboot the system using reboot the flooding stops and the detach info that wasn't output when i unplugged the device get's printed then. i'm not sure at which pint exactly the following warnings are being produced: ulpt_write_callback:203: state=0x0 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x2 i'll reboot my machine and check it out. i tried hitting ctrl+alt+esc. unfortunately i'm not able to use my keyboard anymore after entering the debugger. :( cheers. Hans Petter Selasky schrieb am 2009-03-14: On Saturday 14 March 2009, Alexander Best wrote: hi there. i'm having a problem with my usb printer. it's being recognised as ulpt0, but i cannot print. i'm using the cups port for printing. i've set hw.usb2.ulpt.debug=15 and this is the output: uhub_reattach_port:348: port 2 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port:434: device problem (USB_ERR_TIMEOUT), disabling port 2 ugen0.3: Samsung Electronics Co., Ltd. at usbus0 ulpt_probe:472: ulpt_attach:498: sc=0xc6f6be80 ulpt0: Samsung Electronics Co., Ltd. Samsung ML-1510_700, class 0/0, rev 1.10/1.00, addr 3 on usbus0 ulpt_attach:538: setting alternate config number: 0 ulpt0: using bi-directional mode ulpt_reset:164: ulpt_write_callback:203: state=0x0 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x2 after turning off the device i constantly get this output: ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED the cups daemon cannot be stopped (even with kill -9) and none of the lp* apps work anymore. also i'm not able to attach any new usb devices. so a reboot is the only solution that worked in order to get my computer fully operational again. What happens if you try to reset the usb device? Maybe you could press CTRL + ALT + ESC and dump all the threads or at least threads having the word ulpt in the function names in the backtrace? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: problem with usb printer
alright. here's some more information. when i attach the printer i get the following output: uhub_reattach_port:348: port 2 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port:434: device problem (USB_ERR_TIMEOUT), disabling port 2 ugen0.3: Samsung Electronics Co., Ltd. at usbus0 ulpt_probe:472: ulpt_attach:498: sc=0xc5f81200 ulpt0: Samsung Electronics Co., Ltd. Samsung ML-1510_700, class 0/0, rev 1.10/1.00, addr 3 on usbus0 ulpt_attach:538: setting alternate config number: 0 ulpt0: using bi-directional mode when i simply issue a print command using `lp file` i get the following output: ulpt_reset:164: ulpt_write_callback:203: state=0x0 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x1 at this point the printers light flashes a few times indicating that it's about to print. but nothing get's printed. `lpq` tells me that the job has been finished succesfully. the problem where the console get's flooded with warnings and the printer's led reports an error appears randomly. i'm trying to figure out how to exactly to reproduce it. alex Hans Petter Selasky schrieb am 2009-03-14: On Saturday 14 March 2009, Alexander Best wrote: hi there. i'm having a problem with my usb printer. it's being recognised as ulpt0, but i cannot print. i'm using the cups port for printing. i've set hw.usb2.ulpt.debug=15 and this is the output: uhub_reattach_port:348: port 2 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port:434: device problem (USB_ERR_TIMEOUT), disabling port 2 ugen0.3: Samsung Electronics Co., Ltd. at usbus0 ulpt_probe:472: ulpt_attach:498: sc=0xc6f6be80 ulpt0: Samsung Electronics Co., Ltd. Samsung ML-1510_700, class 0/0, rev 1.10/1.00, addr 3 on usbus0 ulpt_attach:538: setting alternate config number: 0 ulpt0: using bi-directional mode ulpt_reset:164: ulpt_write_callback:203: state=0x0 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x2 after turning off the device i constantly get this output: ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED the cups daemon cannot be stopped (even with kill -9) and none of the lp* apps work anymore. also i'm not able to attach any new usb devices. so a reboot is the only solution that worked in order to get my computer fully operational again. What happens if you try to reset the usb device? Maybe you could press CTRL + ALT + ESC and dump all the threads or at least threads having the word ulpt in the function names in the backtrace? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: problem with usb printer
i've been able to reproduce the error. it only occurs when i print a testpage from the cups web interface. if i simply print a page using `lp` the problem doesn't occur. also the printer needs to have the following device line configured: DeviceURI file:/dev/ulpt0 if DeviceURI is set to usb:/dev/ulpt0 the error doesn't occur when i print a testpage. i'm not sure which exact command is being issued when a testpage is being printed. obviously the error i described only appears in rare situations. so it might not be worth fixing it. however apart from this error i'm not able to print at all. even though there's no crash, nothing get's printed. cheers. Hans Petter Selasky schrieb am 2009-03-14: On Saturday 14 March 2009, Alexander Best wrote: hi there. i'm having a problem with my usb printer. it's being recognised as ulpt0, but i cannot print. i'm using the cups port for printing. i've set hw.usb2.ulpt.debug=15 and this is the output: uhub_reattach_port:348: port 2 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port:434: device problem (USB_ERR_TIMEOUT), disabling port 2 ugen0.3: Samsung Electronics Co., Ltd. at usbus0 ulpt_probe:472: ulpt_attach:498: sc=0xc6f6be80 ulpt0: Samsung Electronics Co., Ltd. Samsung ML-1510_700, class 0/0, rev 1.10/1.00, addr 3 on usbus0 ulpt_attach:538: setting alternate config number: 0 ulpt0: using bi-directional mode ulpt_reset:164: ulpt_write_callback:203: state=0x0 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x1 ulpt_write_callback:203: state=0x2 after turning off the device i constantly get this output: ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED ulpt_status_callback:328: error=USB_ERR_STALLED the cups daemon cannot be stopped (even with kill -9) and none of the lp* apps work anymore. also i'm not able to attach any new usb devices. so a reboot is the only solution that worked in order to get my computer fully operational again. What happens if you try to reset the usb device? Maybe you could press CTRL + ALT + ESC and dump all the threads or at least threads having the word ulpt in the function names in the backtrace? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
usb/130325: [usb] [patch] fix tools/tools/usb/print-usb-if-vids.sh
Number: 130325
Category: usb
Synopsis: [usb] [patch] fix tools/tools/usb/print-usb-if-vids.sh
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: Fri Jan 09 14:30:01 UTC 2009
Closed-Date:
Last-Modified:
Originator: Alexander Best
Release:8-CURRENT
Organization:
Environment:
reeBSD moshnroll 8.0-CURRENT FreeBSD 8.0-CURRENT #11 r186887M: Thu Jan 8
11:38:05 UTC 2009 r...@moshnroll:/usr/obj/usr/src/sys/ARUNDEL i386
Description:
here's a fix to make tools/tools/usb/print-usb-if-vids.sh work again. the file
hasn't been touched in over 4 years. ;)
alex
How-To-Repeat:
Fix:
Patch attached with submission follows:
--- tools/tools/usb/print-usb-if-vids.sh2008-11-27 00:25:34.0
+
+++ tools/tools/usb/print-usb-if-vids.sh2009-01-09 00:49:50.0
+
@@ -27,5 +27,5 @@
# $FreeBSD$
-fetch -o /tmp/usb.if http://www.usb.org/app/pub/dump/comp_dump/
+fetch -o /tmp/usb.if http://www.usb.org/developers/tools/comp_dump/
awk -F '|' '{ printf %#06x\t%s\n, $1, $2 }' /tmp/usb.if | sort
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/130230: Samsung Electronics YP-U3 does not attach in 7.1-RELEASE
The following reply was made to PR usb/130230; it has been noted by GNATS. From: Alexander Best alexbes...@math.uni-muenster.de To: bug-follo...@freebsd.org Cc: uspoerl...@gmail.com Subject: Re: usb/130230: Samsung Electronics YP-U3 does not attach in 7.1-RELEASE Date: Wed, 07 Jan 2009 01:25:30 +0100 (CET) This is a MIME encoded multipart message. --+permail-200901070025306981cf3e65b8-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit please try the following patch. cheers. alex --+permail-200901070025306981cf3e65b8-a_best01+ Content-Type: application/octet-stream Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename=ypu3.patch LS0tIHN5cy9kZXYvdXNiL3VtYXNzLmMub3JpZwkyMDA5LTAxLTA3IDAxOjA3OjM1LjAwMDAwMDAw MCArMDAwMAorKysgc3lzL2Rldi91c2IvdW1hc3MuYwkyMDA5LTAxLTA3IDAxOjA5OjEzLjAwMDAw MDAwMCArMDAwMApAQCAtNjU0LDYgKzY1NCwxMCBAQAogCSAgVU1BU1NfUFJPVE9fU0NTSSB8IFVN QVNTX1BST1RPX0JCQiwKIAkgIFNIVVRUTEVfSU5JVCB8IE5PX0dFVE1BWExVTgogCX0sCisJeyBV U0JfVkVORE9SX1NBTVNVTkcsICBVU0JfUFJPRFVDVF9TQU1TVU5HX1lQX1UzLCBSSURfV0lMRENB UkQsCisJICBVTUFTU19QUk9UT19TQ1NJIHwgVU1BU1NfUFJPVE9fQkJCLAorCSAgU0hVVFRMRV9J TklUIHwgTk9fR0VUTUFYTFVOCisJfQogCXsgVVNCX1ZFTkRPUl9TQU1TVU5HX1RFQ0hXSU4sIFVT Ql9QUk9EVUNUX1NBTVNVTkdfVEVDSFdJTl9ESUdJTUFYXzQxMCwgUklEX1dJTERDQVJELAogCSAg VU1BU1NfUFJPVE9fU0NTSSB8IFVNQVNTX1BST1RPX0JCQiwKIAkgIE5PX0lOUVVJUlkKLS0tIHN5 cy9kZXYvdXNiL3VzYmRldnMub3JpZwkyMDA5LTAxLTA3IDAxOjA2OjM3LjAwMDAwMDAwMCArMDAw MAorKysgc3lzL2Rldi91c2IvdXNiZGV2cwkyMDA5LTAxLTA3IDAxOjA3OjI2LjAwMDAwMDAwMCAr MDAwMApAQCAtMTk5MCw2ICsxOTkwLDcgQEAKIC8qIFNhbXN1bmcgcHJvZHVjdHMgKi8KIHByb2R1 Y3QgU0FNU1VORyBNTDYwNjAJCTB4MzAwOAlNTC02MDYwIGxhc2VyIHByaW50ZXIKIHByb2R1Y3Qg U0FNU1VORyBZUF9VMgkJMHg1MDUwCVlQLVUyIE1QMyBQbGF5ZXIKK3Byb2R1Y3QgU0FNU1VORyBZ UF9VMwkJMHg1MDdjCVlQLVUzIE1QMyBQbGF5ZXIKIHByb2R1Y3QgU0FNU1VORyBJNTAwCQkweDY2 MDEJSTUwMCBQYWxtIFVTQiBQaG9uZSAKIAogLyogU2Ftc3VuZyBUZWNod2luIHByb2R1Y3RzICov Cg== --+permail-200901070025306981cf3e65b8-a_best01+-- ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb2 quirks
instead of using usbconfig to add the quirks for my device i added them to umass2.c and usb2_devid.h. with the changes the device works without any problems. here's the dmesg output: ugen3.2: Meizu Electronics at usbus3 umass0: Meizu Electronics MiniPlayer, class 0/0, rev 2.00/1.00, addr 2 on usbus3 umass0: SCSI over Bulk-Only; quirks = 0x4400 umass0:7:0:-1: Attached to scbus7 da0 at umass-sim0 bus 0 target 0 lun 0 da0:Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 3864MB (7913472 512 byte sectors: 255H 63S/T 492C) it would be nice to see the changes make it into HEAD. cheers. alex Hans Petter Selasky schrieb am 2008-12-23: On Tuesday 23 December 2008, Alexander Best wrote: hi there, could somebody tell me where i can find info about the quirk settings used in usbconfig (usb2) please? i had a look at usbconfig(8), but the manual doesn't contain any information concerning usb quirks. Hi, If you type: usbconfig -h You see that you have the following quirk commands available: add_dev_quirk_vplh vid pid lo_rev hi_rev quirk remove_dev_quirk_vplh vid pid lo_rev hi_rev quirk dump_quirk_names dump_device_quirks Before you can use quirks you need to: kldload usb2_quirk --HPS usb2meizu.patch Description: Binary data ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/130230: Samsung Electronics YP-U3 does not attach in 7.1-RELEASE
The following reply was made to PR usb/130230; it has been noted by GNATS. From: Alexander Best alexbes...@math.uni-muenster.de To: bug-follo...@freebsd.org Cc: uspoerl...@gmail.com Subject: Re: usb/130230: Samsung Electronics YP-U3 does not attach in 7.1-RELEASE Date: Wed, 07 Jan 2009 01:52:45 +0100 (CET) if the device still fails to attach please see this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/127980 you might have to undo the changes that were introduced with the following patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=125398 cheers. alex ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/129129: panic with device Meizu MiniPlayer M6 (SL) under usb2
The following reply was made to PR usb/129129; it has been noted by GNATS. From: Alexander Best alexbes...@math.uni-muenster.de To: bug-follo...@freebsd.org Cc: Subject: Re: usb/129129: panic with device Meizu MiniPlayer M6 (SL) under usb2 Date: Tue, 23 Dec 2008 21:07:07 +0100 (CET) --+permail-20081223200707f7e55a9d7dba-a_best01+signed+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit this issue got fixed. i'm currently running FreeBSD moshnroll 8.0-CURRENT FreeBSD 8.0-CURRENT #3 r186374M: Sun Dec 21 20:10:18 CET 2008 the panic no longer occurs. cheers. --+permail-20081223200707f7e55a9d7dba-a_best01+signed+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) iQDVAwUASVFE6yo8gGMXfm+ZAQLAAAX/fbfDxKOUT+RyJbbNw/1fEaiU0X/Z/46i Aj0lGJSC3qXEden1g7h9k3/iYJDMAh/M7MVkKsDNd7RNYD8Go8HbyrAmncIkpaO1 Ogg4oXkHJtUnrvayHQSZA/Z5VyIIm+OETvL8k81jzFKwuQj1jRi5B82Fdo/LFCwz mtFogbcLS8sgPFgcijiNG5ZmMPViXe5zUU+KCIaAgUYDZ/y+1xUHFrzo8mJZ5HkA MmcUn9mr7mxdoMGJ/4iaUJRk5XdAJwVJ =71sl -END PGP SIGNATURE- --+permail-20081223200707f7e55a9d7dba-a_best01+signed+-- ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
usb2 quirks
hi there, could somebody tell me where i can find info about the quirk settings used in usbconfig (usb2) please? i had a look at usbconfig(8), but the manual doesn't contain any information concerning usb quirks. cheers. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
