Re: scsi_da quirk for a device with no name
[sorry for top-quoting, but I think that this should be more convenient
since I am following up on my own posts]
Warner, list, please consider the attached patch.
umass.c part of it is intended to put some meaningful data into inquiry
response if a device return completely empty identification. This is
useful when cam/scsi layer needs to have a quirk for such a device.
scsi_da.c part of it utilizes this new feature to handle ASUS P535
smartphone (phone+pda) configured to act as a mass storage device for
USB connection.
Another possible alternative to the umass.c patch is to have a new quirk
to force some inquiry data instead of dynamic inquiry response checking,
but I am not sure if that would be any better.
Would it be more convenient for everybody if I file a PR on this ?
Thank you for your attention.
on 24/01/2008 15:58 Andriy Gapon said the following:
This is me again on the issue of a weird umass device that reports empty
strings to SCSI inquiry command. Currently the only way to specify some
SCSI-level quirk for such a device is to create a quirk entry with all
fields set to wildcard *, but apparently such a quirk would be applied
to many more devices.
A suggestion: what about umass intercepting a response of inquiry
command and generating some names in such a case. E.g. vendor and
product identification could be generated from the USB ids like
Vendor_abcd, Product_1234.
In this case we would get some sufficient identification for such devices.
P.S. it also seems that if NO_INQUIRY umass quirk is specified for a
device, then its identification will be empty as well. I think that this
is not good because, for example, scsi_da quirks are troublesome then.
P.P.S. it is currently impossible to have scsi_da quirk entries with
empty fields (), they get ignored.
on 16/08/2007 15:22 Andriy Gapon said the following:
I have ASUS P535 PPC+phone with Windows Mobile 5 on it.
It has an option to act as a USB mass storage (instead of attempting
acivesync).
When I tried it, it first got recognized by umass and then it
immediately panicked my system.
From messages:
kernel: umass0: ASUS Generic Mass Storage, rev 2.00/0.00, addr 3
kernel: da0 at umass-sim0 bus 0 target 0 lun 0
kernel: da0:Removable Direct Access SCSI-0 device
kernel: da0: 1.000MB/s transfers
kernel: da0: 1952MB (3998720 512 byte sectors: 255H 63S/T 248C)
From panic (typed from memory):
umass0: Invalid CSW: tag 7 should be 8
(da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x0, scsi
status == 0x4
I googled up several reports of similar and not so similar panics.
Here's a small overview that is not directly related to a question that
I really want to ask:
1. Invalid CSW problems where a signature is wrong, I see that
WRONG_CSWSIG umass quirk is recommended for that;
2. Invalid CSW problems where a tag is wrong and the values are very
different, I see that one person attempted to cure that with a new
hand-rolled quirk to simply ignore the mismatch;
3. Invalid CSW problems where a tag is wrong and the difference is
exactly one. I don't know if there is anything special about that, but
it looks the most interesting of all the cases.
In some cases but not all Invalid CSW comes together with Synchronize
cache failed and DA_Q_NO_SYNC_CACHE scsi_da quirk is recommended for that.
So I attempted the latter quirk and it helped me! But there is one not
good thing about the way I did that - I used wild cards (*) for all
three of vendor, product and revision. This is because they all appear
to be empty/unset. This is shown in both kernel messages and by
camcontrol devlist and by camcontrol inquiry.
I am not sure if there are any risks of applying the quirk to all
possible da devices, there will be only umass ones in my case, but I
still would like to do something more specific to the device in question.
Will empty patterns work ? I mean if I put , , entry into the
quirk array. Actually, I can test this myself soon, but not today.
Thank you.
P.S. some links to the problems that others have reported:
http://www.freebsd.org/cgi/query-pr.cgi?pr=114916cat=
http://osdir.com/ml/os.freebsd.devel.usb/2005-12/msg00039.html
http://lists.freebsd.org/pipermail/freebsd-bugs/2004-November/010483.html
http://lists.freebsd.org/pipermail/freebsd-bugs/2004-January/005170.html
http://lists.freebsd.org/mailman/htdig/freebsd-usb/2004-December/000318.html
http://lists.freebsd.org/mailman/htdig/freebsd-usb/2005-February/000660.html
--
Andriy Gapon
--- sys/dev/usb/umass.c 2008-02-10 15:30:23.0 +0200
+++ sys/dev/usb/umass.c 2008-02-10 15:02:43.0 +0200
@@ -3063,6 +3059,12 @@
maxsector = scsi_4btoul(rcap-addr) - 1;
scsi_ulto4b(maxsector, rcap-addr);
}
+ else if (csio-cdb_io.cdb_bytes[0] == INQUIRY
+ csio-data_ptr[8] == '\0' csio-data_ptr[16] == '\0') {
+ usb_device_descriptor_t *dd = usbd_get_device_descriptor(sc-sc_udev);
+
Re: getting my new graphic tablet cooperating with gimp
On Sat, Feb 09, 2008 at 05:27:55PM -0500, Chuck Robey wrote: I have a nice new UC-Logic WP8060-TAB08, sometimes called the Superpen, and I want to get it working so's I can make fine art with it (yeah, I'm a dreamer, so what else is new, hey?) The return off of dmesg is: ums0: UC-LOGIC Tablet WP8060U, class 0/0, rev 1.10/0.00, addr 2 on uhub0 ums0: X report 0x0002 not supported device_attach: ums0 attach returned 6 This is because your tablet use absolute coordinates (most tablets do) while ums(4) currently only support relative ones. Could you please try to dump your pen's report descriptor and paste it here, thus we can have more infomation? You can do it by: Download the tool: http://people.freebsd.org/~kaiw/tools/krepdump.tgz # tar xzvf krepdump.tgz # cd krepdump # make # kldload ./krepdump.ko Then connect your superpen to the usb port, (if it is already connected you will have to disconnect it first) the report descriptor will be printed on the console. (or you can type 'dmesg' to see it) -- Kai ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getting my new graphic tablet cooperating with gimp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kai Wang wrote: On Sat, Feb 09, 2008 at 05:27:55PM -0500, Chuck Robey wrote: I have a nice new UC-Logic WP8060-TAB08, sometimes called the Superpen, and I want to get it working so's I can make fine art with it (yeah, I'm a dreamer, so what else is new, hey?) The return off of dmesg is: ums0: UC-LOGIC Tablet WP8060U, class 0/0, rev 1.10/0.00, addr 2 on uhub0 ums0: X report 0x0002 not supported device_attach: ums0 attach returned 6 This is because your tablet use absolute coordinates (most tablets do) while ums(4) currently only support relative ones. Could you please try to dump your pen's report descriptor and paste it here, thus we can have more infomation? You can do it by: Download the tool: http://people.freebsd.org/~kaiw/tools/krepdump.tgz # tar xzvf krepdump.tgz # cd krepdump # make # kldload ./krepdump.ko Then connect your superpen to the usb port, (if it is already connected you will have to disconnect it first) the report descriptor will be printed on the console. (or you can type 'dmesg' to see it) -- Kai Kai, another thing just occurred to me, you mgith need a physical description of the system. It comes with a stylus that has a replaceable plastic tip, and 3 extra tips are packaged with it. The stylus itself has a 1.5 volt AAA cell in it, and the barrel of the stylus has a rocker switch on it, one that seems to have 3 positions: a center position, which I would probably define as rest, to which it remains when no force is applied, and the switch may be rocked either forward (nearer to the tip) or backward (away from the tip). There might possibly be a third position that might be defined, because the light on the top of the tablet itself comes on solid when the tip of the pen touches it, and that might possibly be defined as a third button, sort of mimicing a 3 button mouse. I understand from company literature that the tablet allows 1024 levels of force gradient, to select differing widths of brushes in applications such as gimp. Like I siad, the tablet has a green LED which is mounted at the top center of the tablet. The writing area is 8 inches wide by 6 inches tall, and is covered by a translucent piece of fairly heavy (maybe 10 mil?) plastic. I noted no spares for this in the package. They will probably sell replacements for this covering, as it would be a very natural place for a particular application to emblazon a series of hot areas for special input.. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHr0Nwz62J6PPcoOkRAq9pAJ92xZdlAisXsYt/WfxofaEegoij4QCghOXF 3I8TvLXiefVJKK4X+ztRvms= =Ezlg -END PGP SIGNATURE- ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/56095: [usb] [patch] QUIRK: Apacer Pen Drive fails to work
The following reply was made to PR usb/56095; it has been noted by GNATS. From: Volker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: usb/56095: [usb] [patch] QUIRK: Apacer Pen Drive fails to work Date: Sun, 10 Feb 2008 23:57:48 +0100 submitters mail address bounces: (host exgw2.lumeta.com[65.198.68.66] said: 550 5.1.1 [EMAIL PROTECTED]: Recipient address rejected: User unknown in local recipient table (in reply to RCPT TO command)) ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
