Re: How to obtain the "ugen" that corresponds to an "ums", "uep" or "uhid"?
On 2014-09-15 15:07, Hans Petter Selasky wrote: Hi, folks. Is there a way to obtain the name of an ugen device that corresponds to a particular ums/uep/uhid device? Have you tried: usbconfig show_ifdrv I haven't. It does look like a good solution though. Thank you. It seems that we have the correct number in the "devaddr" variable, but the correct number is nowhere to be found. That might be a bug. We can easily add a unit=%d argument to the devd events, if not already there. That would be great as well (although I won't be able to use this until the EoL of all FreeBSD versions without this feature, but it will simplify things afterwards). ___ 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"
How to obtain the "ugen" that corresponds to an "ums", "uep" or "uhid"?
Hi, folks. Is there a way to obtain the name of an ugen device that corresponds to a particular ums/uep/uhid device? The situation I'm working with is this: there's a (custom) DEVD rule that executes a script when any new "ums" or "uhid" device is created. This script has access to the device name (and any other info DEVD provides), and needs to figure out manufacturer name, product name and ID numbers of this device. To do that, it parses the output of this command: usbconfig -d ugen. dump_device_desc The question is how should the script obtain these and numbers? Now, when a new device is attached DEVD receives a message like this: +uhid0 at bus=1 hubaddr=1 port=3 devaddr=2 interface=0 vendor=0x0079 product=0x0011 devclass=0x00 devsubclass=0x00 sernum="" release=0x0106 mode=host intclass=0x03 intsubclass=0x00 intprotocol=0x00 on uhub0 (The correct ugen for this device happens to be ugen3.2). ... or a message like this: +ums0 at bus=0 hubaddr=2 port=2 devaddr=3 interface=1 vendor=0x046d product=0xc52b devclass=0x00 devsubclass=0x00 sernum="" release=0x1201 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x02 on uhub3 (In this case the correct ugen is ugen0.3). It seems that we have the correct number in the "devaddr" variable, but the correct number is nowhere to be found. So, again, given an ums/uep/uhid device name (and, possibly number), how should one fine what to pass into usbconfig's "ugen." parameter? (This question is triggered by the discussion in PR 183478 [1]). [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183478 ___ 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: need help with eGalax USB touch screen, will pay
> We have some eGalax based touchscreens that we are trying to get > working with FreeBSD 9.2, eventually in Xorg. They are PioneerPOS > TOM-M7 screens. > > They appear to be the newer eGalax models that are at least somewhat > HID compliant. Hi. While the proper way would be to port xf86-input-evdev and use it with webcamd, you may have some luck with my USB HID driver [1]. It's very lightly tested (I don't have a lot of HID-compliant hardware), but it should work at least to some extent. Report back any results. [1] http://tx97.net/xf86-input-usbhid/ ___ 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: Tablets with webcamd (was: wacom and x11 and webcamd)
Hans Petter Selasky wrote: > The drivers mentioned does not compile as-is, That is my conclusion as well. > but you are free to send a > patch to make them compile. Should not be too hard! In that case I will look into it as time permits. No promises though. Thank you for your help. ___ 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: Tablets with webcamd (was: wacom and x11 and webcamd)
Hans Petter Selasky wrote:
>> Any plans for CONFIG_HID_KYE, CONFIG_HID_UCLOGIC and CONFIG_HID_WALTOP?
>
> It is just to edit the "config" in the root directory of webcamd, add those
>
> options and see if it compiles.
It compiles, but webcamd wouldn't attach to the hardware those
drivers are supposed to support. It seems that webcamd doesn't
contain the needed sources at the moment. In particular
drivers/hid/hid-{kye,uclogic,waltop}.c are definitely needed,
as well as a bunch of other files (I don't really know which
though).
Should I try just copying over those files? Is editing 'config'
file enough for the rest of the system to pick them up?
(I don't think it's that easy, but no harm in asking, right?)
___
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: Tablets with webcamd (was: wacom and x11 and webcamd)
Hans Petter Selasky wrote: > The following tables are supported in the latest version of webcamd: > > CONFIG_TABLET_USB_ACECAD=y > CONFIG_TABLET_USB_AIPTEK=y > CONFIG_TABLET_USB_GTCO=y > CONFIG_TABLET_USB_HANWANG=y > CONFIG_TABLET_USB_KBTAB=y > CONFIG_TABLET_USB_WACOM=y I see. Any plans for CONFIG_HID_KYE, CONFIG_HID_UCLOGIC and CONFIG_HID_WALTOP? ___ 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"
Tablets with webcamd (was: wacom and x11 and webcamd)
Hans Petter Selasky wrote: > I've created a Wiki Page for Wacom Tablets: > > https://wiki.freebsd.org/WacomTablet I have a more general question: does webcamd contain Linux code for non-Wacom tablets (there's quite a few in drivers/hid), i.e. will it create /dev/input/* devices for them too? If so, is my understanding correct that we'll need xf86-input-evdev to make use of that? If not so, is there a plan to add those drivers too, and is it at all possible? > Feel free to suggest more information which might be added there. Do add a note that UQ_UMS_IGNORE is only available on 9-STABLE and 10-CURRENT. ___ 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/171721: [patch] usb_quirk(4), ums(4): add UQ_UMS_IGNORE quirk
Hans Petter Selasky wrote: >> Will it be possible to also MFC this change so it would >> get into the upcoming 9.1-RELEASE? > > Yes, if you remind me in a week or so. I see that you committed the change to both head and stable/9 (thanks for that); will it be possible to get it into releng/9.1 too? ___ 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/172458: Make uhid(4) attach to mice and keyboards with UQ_{UMS, KBD}_IGNORE quirks
>Number: 172458
>Category: usb
>Synopsis: Make uhid(4) attach to mice and keyboards with
>UQ_{UMS,KBD}_IGNORE quirks
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-usb
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Sun Oct 07 18:10:15 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Vitaly Magerya
>Release:FreeBSD 9.1-RC1 amd64
>Organization:
>Environment:
>Description:
The uhid(4) driver that can attach to the same devices that
ums(4) and ukbd(4) can. Since uhid should generally be used as
a fallback, it performs this check:
/*
* Don't attach to mouse and keyboard devices, hence then no
* "nomatch" event is generated and then ums and ukbd won't
* attach properly when loaded.
*/
if ((uaa->info.bInterfaceClass == UICLASS_HID) &&
(uaa->info.bInterfaceSubClass == UISUBCLASS_BOOT) &&
((uaa->info.bInterfaceProtocol == UIPROTO_BOOT_KEYBOARD) ||
(uaa->info.bInterfaceProtocol == UIPROTO_MOUSE))) {
return (ENXIO);
}
The problem here is that we have UQ_KBD_IGNORE and UQ_UMS_IGNORE
quirks that prevent ukbd and ums from attaching -- if such a
quirk is set, it may be the case that because of this check no
driver will attach to the device, while uhid should take over
in such a case.
>How-To-Repeat:
>Fix:
The proper fix would be to remove the above check altogether and
somehow ensure that uhid is given lower priority than ukbd and
ums. Since I don't really know how to do that, I propose just
testing for UQ_KBD_IGNORE and UQ_UMS_IGNORE quirks in uhid too.
Patch attached with submission follows:
Index: sys/dev/usb/input/uhid.c
===
--- sys/dev/usb/input/uhid.c(revision 241311)
+++ sys/dev/usb/input/uhid.c(working copy)
@@ -691,8 +691,10 @@
*/
if ((uaa->info.bInterfaceClass == UICLASS_HID) &&
(uaa->info.bInterfaceSubClass == UISUBCLASS_BOOT) &&
- ((uaa->info.bInterfaceProtocol == UIPROTO_BOOT_KEYBOARD) ||
-(uaa->info.bInterfaceProtocol == UIPROTO_MOUSE))) {
+ (((uaa->info.bInterfaceProtocol == UIPROTO_BOOT_KEYBOARD) &&
+ !usb_test_quirk(uaa, UQ_KBD_IGNORE)) ||
+((uaa->info.bInterfaceProtocol == UIPROTO_MOUSE) &&
+ !usb_test_quirk(uaa, UQ_UMS_IGNORE {
return (ENXIO);
}
>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"
usb/171810: [patch] make hid_start_parse(3) respect report ID argument
>Number: 171810
>Category: usb
>Synopsis: [patch] make hid_start_parse(3) respect report ID argument
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-usb
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Thu Sep 20 11:50:11 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Vitaly Magerya
>Release:
>Organization:
>Environment:
>Description:
Currently hid_start_parse(3) ignores it's 3-rd parameter -- the
report ID, so subsequent calls to hid_get_item(3) return items
of all report IDs, not just the one requested. This also affects
hid_locate(3), which effectively ignores requested report ID too.
This is different from how it works on NetBSD and OpenBSD: their
libusbhid(3) implementations only return items of the requested
report ID, unless it is -1, in which case items of all report
IDs are returned. In fact our own usbhidctl(1) always uses -1
as the report ID argument, and usbhidaction(1) has an undocumented
option '-r' to use report ID other than -1 -- which doesn't seem
to work at the moment (I did not test it, but it appears that
way from the code).
In short, I propose to follow NetBSD and OpenBSD and respect id
argument of hid_start_parse(3).
Note: we had the same API before revision 205728, which says
"This merge does not change any API", so it seems this was just
overlooked.
>How-To-Repeat:
>Fix:
Patch attached with submission follows:
Index: usbhid.3
===
--- usbhid.3(revision 240744)
+++ usbhid.3(working copy)
@@ -144,16 +144,15 @@
.Ss Descriptor Parsing Functions
To parse the report descriptor the
.Fn hid_start_parse
-function should be called with a report descriptor and a set that
-describes which items that are interesting.
+function should be called with a report descriptor, a set that
+describes which items that are interesting, and the desired report
+ID (or -1 to obtain items of all report IDs).
The set is obtained by OR-ing together values
.Fa "(1 << k)"
where
.Fa k
is an item of type
.Vt hid_kind_t .
-The report ID (if present) is given by
-.Fa id .
The function returns
.Dv NULL
if the initialization fails, otherwise an opaque value to be used
Index: descr.c
===
--- descr.c (revision 240744)
+++ descr.c (working copy)
@@ -68,7 +68,7 @@
if ((rep = hid_get_report_desc(fd)) == NULL)
goto use_ioctl;
kindset = 1 << hid_input | 1 << hid_output | 1 << hid_feature;
- for (d = hid_start_parse(rep, kindset, 0); hid_get_item(d, &h); ) {
+ for (d = hid_start_parse(rep, kindset, -1); hid_get_item(d, &h); ) {
/* Return the first report ID we met. */
if (h.report_ID != 0) {
temp = h.report_ID;
Index: parse.c
===
--- parse.c (revision 240744)
+++ parse.c (working copy)
@@ -70,6 +70,7 @@
uint8_t iusage; /* current "usages_min/max" index */
uint8_t ousage; /* current "usages_min/max" offset */
uint8_t susage; /* usage set flags */
+ uint32_t reportid; /* requested report ID */
};
/**
@@ -149,7 +150,7 @@
* hid_start_parse
**/
hid_data_t
-hid_start_parse(report_desc_t d, int kindset, int id __unused)
+hid_start_parse(report_desc_t d, int kindset, int id)
{
struct hid_data *s;
@@ -158,6 +159,7 @@
s->start = s->p = d->data;
s->end = d->data + d->size;
s->kindset = kindset;
+ s->reportid = id;
return (s);
}
@@ -207,8 +209,8 @@
/**
* hid_get_item
**/
-int
-hid_get_item(hid_data_t s, hid_item_t *h)
+static int
+hid_get_item_raw(hid_data_t s, hid_item_t *h)
{
hid_item_t *c;
unsigned int bTag, bType, bSize;
@@ -509,6 +511,19 @@
}
int
+hid_get_item(hid_data_t s, hid_item_t *h)
+{
+ int r;
+
+ for (;;) {
+ r = hid_get_item_raw(s, h);
+ if (r <= 0 || s->reportid == -1 || h->report_ID == s->reportid)
+ break;
+ }
+ return (r);
+}
+
+int
hid_report_size(report_desc_t r, enum hid_kind k, int id)
{
struct hid_data *d;
@@ -523,7 +538,7 @@
memset(&h, 0, sizeof h);
for (d = h
Re: usb/171721: [patch] usb_quirk(4), ums(4): add UQ_UMS_IGNORE quirk
The following reply was made to PR usb/171721; it has been noted by GNATS. From: Vitaly Magerya To: bug-follo...@freebsd.org Cc: Subject: Re: usb/171721: [patch] usb_quirk(4), ums(4): add UQ_UMS_IGNORE quirk Date: Tue, 18 Sep 2012 13:41:20 +0300 Will it be possible to also MFC this change so it would get into the upcoming 9.1-RELEASE? ___ 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/171721: [patch] usb_quirk(4), ums(4): add UQ_UMS_IGNORE quirk
>Number: 171721
>Category: usb
>Synopsis: [patch] usb_quirk(4), ums(4): add UQ_UMS_IGNORE quirk
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-usb
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Mon Sep 17 18:10:04 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Vitaly Magerya
>Release:
>Organization:
>Environment:
>Description:
It appears that we have USB quirks UQ_HID_IGNORE and UQ_KBD_IGNORE
that make uhid(4) and ukbd(4) to ignore a perticular device. I
propose adding UQ_UMS_IGNORE that instruct ums(4) to ignore a
device.
The motivation for this is hardware that lists a bogus
Generic_Desktop:Mouse usage in it's record descriptor thus fooling
ums(4) into thinking that it is a mouse, while in reality it is
something other and should be handled by uhid(4) instead (I have
a graphics tablet that does this).
>How-To-Repeat:
>Fix:
I'm attaching a patch against head.
Patch attached with submission follows:
Index: share/man/man4/usb_quirk.4
===
--- share/man/man4/usb_quirk.4 (revision 240607)
+++ share/man/man4/usb_quirk.4 (working copy)
@@ -66,6 +66,8 @@
device should be ignored by kbd class
.It UQ_KBD_BOOTPROTO
device should set the boot protocol
+.It UQ_UMS_IGNORE
+device should be ignored by ums class
.It UQ_MS_BAD_CLASS
doesn't identify properly
.It UQ_MS_LEADING_BYTE
Index: sys/dev/usb/quirk/usb_quirk.c
===
--- sys/dev/usb/quirk/usb_quirk.c (revision 240607)
+++ sys/dev/usb/quirk/usb_quirk.c (working copy)
@@ -494,6 +494,7 @@
[UQ_HID_IGNORE] = "UQ_HID_IGNORE",
[UQ_KBD_IGNORE] = "UQ_KBD_IGNORE",
[UQ_KBD_BOOTPROTO] = "UQ_KBD_BOOTPROTO",
+ [UQ_UMS_IGNORE] = "UQ_UMS_IGNORE",
[UQ_MS_BAD_CLASS] = "UQ_MS_BAD_CLASS",
[UQ_MS_LEADING_BYTE]= "UQ_MS_LEADING_BYTE",
[UQ_MS_REVZ]= "UQ_MS_REVZ",
Index: sys/dev/usb/quirk/usb_quirk.h
===
--- sys/dev/usb/quirk/usb_quirk.h (revision 240607)
+++ sys/dev/usb/quirk/usb_quirk.h (working copy)
@@ -29,7 +29,7 @@
enum {
/*
-* Keep in sync with theusb_quirk_str usb_quirk.c, and with the
+* Keep in sync with usb_quirk_str in usb_quirk.c, and with
* share/man/man4/usb_quirk.4
*/
UQ_NONE,/* not a valid quirk */
@@ -49,6 +49,7 @@
UQ_HID_IGNORE, /* device should be ignored by hid class */
UQ_KBD_IGNORE, /* device should be ignored by kbd class */
UQ_KBD_BOOTPROTO, /* device should set the boot protocol */
+ UQ_UMS_IGNORE, /* device should be ignored by ums class */
UQ_MS_BAD_CLASS,/* doesn't identify properly */
UQ_MS_LEADING_BYTE, /* mouse sends an unknown leading byte */
UQ_MS_REVZ, /* mouse has Z-axis reversed */
Index: sys/dev/usb/input/ums.c
===
--- sys/dev/usb/input/ums.c (revision 240607)
+++ sys/dev/usb/input/ums.c (working copy)
@@ -381,6 +381,9 @@
if (uaa->info.bInterfaceClass != UICLASS_HID)
return (ENXIO);
+ if (usb_test_quirk(uaa, UQ_UMS_IGNORE))
+ return (ENXIO);
+
if ((uaa->info.bInterfaceSubClass == UISUBCLASS_BOOT) &&
(uaa->info.bInterfaceProtocol == UIPROTO_MOUSE))
return (BUS_PROBE_DEFAULT);
>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: Support for graphics tablets
Alexander Yerenkow wrote: > I don't remember exact details, if I'm not mistaken, pressure was supported > (it's basically sent by tablet as one byte). > You should have three section of device in xorg, and xorg will take > automatically one as mouse, one as tablet (weird, but working magic). > Could you write later to this list about results :) Yeah, so after updating [1] to the latest xf86-input-mouse (1.8.1), the tablet seems to work. The caveat is that I haven't found a way to detach ums(4) from the device without recompiling the kernel with ums excluded. A workaround is to use sysutils/uhidd which will emulate an uhid(4) device from a given ugen(4) device, so pointing the patched mouse driver to that emulation seems to work. The few minor problems (compared to Linux) are: no proximity events, no relative mode support, and too many events (i.e. the driver produces input events even if pointer's coordinates did not change). Finally, mav@ replied pointing to his original post at [2]. [1] http://people.freebsd.org/~mav/patch-zz-input-mouse9.1.7.1 [2] http://lists.freebsd.org/pipermail/freebsd-hardware/2011-July/006749.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: Support for graphics tablets
Alexander Yerenkow wrote: > mav@ did patch for x, and my cheap tablet from `genius` became working :) > You probably should write to him, ask details on how make your device > working. That is good news then; do you have pressure sensitivity working in programs like gimp? I did mail mav@ (avg@ suggested this too), but got no response so far. There are however his patches at people.freebsd.org that look useful. Is [1] the one you're using? I shall look into it. >From the first glance the patch seems to assume a uhid(4) device though; does ums(4) not grab your tablet before uhid(4)? [1] http://people.freebsd.org/~mav/patch-zz-input-mouse9.1.7.1 ___ 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: Support for graphics tablets
Hans Petter Selasky wrote: > On Wednesday 12 September 2012 23:13:10 Vitaly Magerya wrote: >> Hi, folks. I have a graphics tablet (a Waltop-based one, see [1] >> for it's USB ids and descriptors) and I want to make it work on >> FreeBSD. >> >> Currently (8.3-RC1) this is what happens when I attach it: I have no idea why I wrote 8.3-RC1 here. It should be 9.1-RC1 instead. >> [...] > > Maybe webcamd in ports supports it. > > --HPS I didn't know webcamd supports that kind of devices; I thought it only supports video/audio stuff. Anyway, here's what I get with webcamd-3.7.0.1: # usbconf | grep WALTOP ugen3.2: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON # webcamd -d 3.2 webcamd: Cannot find USB device The same thing happens if I use libusb_detach_kernel_driver(3) to detach ums(4) from the tablet prior to trying webcamd. ___ 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"
Support for graphics tablets
Hi, folks. I have a graphics tablet (a Waltop-based one, see [1] for it's USB ids and descriptors) and I want to make it work on FreeBSD. Currently (8.3-RC1) this is what happens when I attach it: ugen0.2: at usbus0 ums0: on usbus0 ums0: 5 buttons and [XYZ] coordinates ID=1 So, ums(4) tries to grab it -- but that doesn't really work: # cat -v /dev/ums0 In any case, the native mode for this tablet are events with absolute coordinates, so if my understanding is correct ums(4) is of no use here, as it is bound by mouse(4) protocol. So the first question I have is: do we have any kind of support for tablets (other than Wacom's)? Did we ever? Is/was there someone working on this? The second question: is there a way to disconnect ums(4) and make uhid(4) handle the device (while staying with GENERIC kernel)? [1] http://sourceforge.net/apps/mediawiki/digimend/index.php?title=Waltop_Slim_Tablet_12.1%22 ___ 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 problems after sleep/resume on FreeBSD 8.1-RELEASE
Hi, folks. When I try to sleep and then resume on my ThinkPad T40, I sometimes (but not always) get this error message: usbus3: port reset timeout uhub_reattach_port: port 1 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 1 This happens even when there's no USB device actually attached. If I do have a USB flash drive inserted (but not mounted), mounting it after resume fails with this error message: mount_msdosfs: /dev/da0: Input/output error ... and this kernel message: (da0:umass-sim0:0:0:0): AutoSense failed If I however now remove the drive and insert it back, mount works without problems. If the flash drive was mounted before the sleep and I try to unmount it, umount fails with "Input/output error", and this error starts to appear periodically: (da0:umass-sim0:0:0:0): AutoSense failed g_vfs_done():da0[WRITE(offset=19456, length=4096)]error = 5 Trying to read or write to the drive results in similar errors. When I try to shutdown afterward, the error is printed a few more times, then there's a message about giving up on 1 buffer, and finally, the laptop won't actually shut down; it just shows the last messages and doesn't react to key presses. You can find my laptop's dmesg at [1]. If anyone wants to look into this issue, I can provide any further information -- just name it. Note that this isn't the only problem I'm having with sleep/resume; my report here was prompted by the discussion starting at [2]. [1] http://tx97.net/~magv/dmesg-t40.81-p1.txt [2] http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/thread.html#59057 ___ 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"
