Re: devd automatic conversion of umass[0-9] to da[0-9]
On Wed, 2009-05-06 at 17:27 +0200, Julian Stacey wrote: Config below works for a number of memory sticks simultaneously; But if one already has a dvd burner plugged in, then it fails as devd sees (in case of a first memory stick) a new umass1. Although /dev/da0* get created, devd tries to access non existant da1*. Any ideas how to improve this ? ( Using 7.1-RELEASE ) You may want to have a look at the umass script from this old email, which did the umassX to daY mapping using camcontrol output: http://lists.freebsd.org/pipermail/freebsd-usb/2007-December/004286.html but please note the following bug pointed out by Peter Trifonov: http://lists.freebsd.org/pipermail/freebsd-usb/2008-January/004511.html I haven't actually been using this script lately, so I don't know if it will still work, but it seemed pretty stable at the time... /Henrik P.S. You might also want to consider removing skanova.net from your list of spam domains, to avoid blocking half of Sweden from mailing you. ___ 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 panic when unmount removed usbdrive
I think I've already made my point regarding this bug, but since I stay on this mailing list primarily to see the fix through to completion, it would be silly not to comment when everyone else seems to do that :-) On Thu, 2008-02-28 at 09:27 -0600, Octavian Covalschi wrote: this problem is known at least for 1 year.. this is bad. The problem was known over five years ago (usb/46176). I offered a first working patch set for private review in September 2004, but never took the time to follow up. With hindsight, that was a mistake. You see, the thing is that the panic-at-usb-drive-removal bug has been with us for so long that most long-term FreeBSD users have gotten used to it. They know that the drive must be unmounted before the USB stick can be pulled out, and they have probably forgotten the horror experienced when they first made the pull-out-first mistake themselves. That is why you get advice like don't do that, although a bug fix is a very reasonable request. anybody knows any work-around ? Right now, your best bet is to take Warner's advice and try 8.0-CURRENT, since none of the known patches have been merged to the 7.0 track yet. However, I honestly don't know how he can get anything stable without the final scsi_da.c patch, since I had something like 100% reproducible crashes when I updated my system from late 7.0 to early 8.0. You might want to apply patches from http://www.gulbra.net/freebsd-usb/ yourself, but keep in mind that CURRENT is a moving target, so I can't guarantee that the patches are still working perfectly. Also, please remember to use -o sync when mounting the drive. The other case is less tested... thank u in advance You're welcome! And if you're uncomfortable with applying weird patches and recompiling bleeding-edge kernels, please don't give up hope! It's hopefully just a matter of months before we have an acceptable solution in one of the official releases. On Thu, 2008-02-28 at 17:08 +0100, Torfinn Ingolfsen wrote: This problem has been known for a lot longer time. However, most people only complain about it - and they also think it is easy to fix this problem. Well, it is not easy - in fact it is very hard to fix this problem. For data on this, please search the mailing list archives of FreeBSD. You know, the good thing about thinking something is easy is that you get the nerve to actually start working on the problem. I agree that it is not a trivial fix. I pride myself on being able to fix almost any bug within a day. At least, that's what it says on my business cards, but in this case there were several underlying issues, so say one week of deep analysis and patching to reach the state where I couldn't reproduce any version of the problem. I'd call that hard, not very hard :-) Yes - the work around is this: don't do that! Do _not_ remove any mass storage device before unmounting it. If you can't learn to live with this workaround, please do not use removable mass storage devices with FreeBSD. There is a piece of potential wisdom that I've been toying with lately: You get the life you accept. Read that again and give it some thought! What you accept. Not the life you want, not even the life you deserve, but the life you accept, because that is where you will stop striving for something even better. In this case, I have no doubt that the very moment we decide that it is truly unacceptable for a FreeBSD kernel to panic in a common scenario like this, that is when we will start to see some really quick progress in this area. /Henrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Mounting USB flash drive
On Tue, 2008-01-29 at 11:22 +0300, Peter Trifonov wrote:
Just a small suggestion for your patch set. The /etc/devd/umass script
contains the following:
# Verify that there is a slice to mount
if [ ! -e /dev/${drv}s1 ]; then
exit 1;
fi
I have seen some flash drives which do not contain any partitions, i.e. they
look like a big floppy.
In this case one should not look for /dev/daXsY, but mount /dev/daX.
Thanks for the reminder! I know I've seen this mentioned somewhere else,
but I guess I was hoping that someone with access to one of those drives
would submit a tested patch, so I wouldn't have the risk of leaving some
stupid mistake in the code. I'll try to keep it in mind for new updates!
/Henrik
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/84336: [usb] [reboot] instant system reboot when unmounting a powered off/unplugged+replugged USB device
On Sun, 2008-01-27 at 14:29 +1100, Peter Jeremy wrote: This approach doesn't work because GEOM doesn't know the drive has gone away until it's no longer present. At that point it's too late to write unflushed buffers. And a devfs-triggered forced unmount does not address the issue of in-flight I/O's between when the media goes away and the filesystem is unmounted. Well, unflushed buffers will obviously be discarded, but this scenario is focused on small umass devices, which should be mounted with -o sync. In this case, everything will typically already be written to disk. The in-flight I/O part used to be a cause of crashes, but this should work now, with the patches that Warner has already committed to 8.0-CURRENT. This problem is one of a number of problems within FreeBSD where there is a disconnect between the people who want the problem solved and those with the skills to actually solve the problem. This is a side-effect of FreeBSD being a volunteer project and it's not clear how to fix this. The volunteer project mantra is not an excuse to leave the difficult problems unsolved. It just means that sometimes I have to be the one who volunteers a solution. Ideally, that solution would then be reviewed and either committed to the tree or rejected for a valid technical reason. Unfortunately, there are few volunteers for this part of the process :-( On Sat, 2008-01-26 at 20:40 -0700, M. Warner Losh wrote: One of the things that I've been working on with someone (whose name escapes me) and Bruce Evans is trying to address these issues. One problem we have today is that when the device return ENXIO, the buffer cache retries the operation rather than failing it upstream. There are a number of issues with doing this, including fixing all the filesystems to cope with errors. I've committed a number of 'keep the system from panicing' type fixes, but much works remains to be done. I'd like to think that I'm someone :-) While I agree with you that there is still work to do, I think most of it would actually be side issues not directly related to usb/46176 or usb/84336. Things should be working for USB memory sticks and cameras, but perhaps flash cards still trigger it, or file systems other than msdosfs have problems, or the fix happens to introduce a memory leak. All of these problems would be better handled with more specific PRs. Writing as the guy who actually spent two and a half hours in a futile attempt to reproduce this problem with all patches applied, I'd say that the usb/46176 problem has passed on. It is no more. It has ceased to be. This is an ex-bug! At least until someone tells me why I'm a fool! :-) /Henrik P.S. I had some extra background information here, but it turned out to be longer than expected, so I will send it as a separate email. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
usb/46176: Background information
As promised, here is some extra background information to help people understand my latest patch attempt for usb/46176, just to make you a little less nervous when you look at it. I will post a link to this message at the usual place ( http://www.gulbra.net/freebsd-usb/ ), so you can find it when it's needed. Now, back to our regular program: On Sat, 2008-01-26 at 20:40 -0700, M. Warner Losh wrote: And my time this month is very limited, as will next month's because work is being insane. I appreciate the fact that you still take the time to comment, since I would normally get a long email backlog under similar circumstances. Anyway, whenever you or someone else gets the time to think about this again, it might be a good idea to have a look at the scsi_da.c patch. This email will give some extra motivation for it. My memory is already starting to fade, but according to my handwritten notes, the chain of events is as follows: The umass detach correctly triggers the following sequence: umass_cam_detach_sim(umass_softc *sc) xpt_bus_deregister(cam_sim_path(sc-umass_sim)) cam_sim_free(ss-umass_sim, TRUE) ...and the only serious bug remaining is that a later unmount will try to close the da device via daclose, which will access the SIM that has already been released. Actually, it calls cam_periph_lock(), which will try to lock a mutex located in the SIM struct. Now, as you may recall, the SCSI subsystem has actually been designed to handle disappearing devices, presumably for things like hot swapping, so the xpt_bus_deregister() call has already invoked this call chain: xpt_bus_deregister(cam_sim_path(sc-umass_sim)) xpt_async(AC_LOST_DEVICE, bus_path, NULL) daasync(...) cam_periph_async(...) cam_periph_invalidate(...) daoninvalidate(...) disk_gone(softc-disk) [in geom_disk.c] xpt_print(periph-path, lost device\n) The xpt_print(...) gives us some feedback to the /var/log/messages file, so we know where we are in the process. Under normal circumstances, when there is no mounted file system to interfere with things, the call stack would return to cam_periph_invalidate() and do the following: cam_periph_invalidate(...) camperiphfree(periph) dacleanup(periph) [called as periph-periph_dtor(periph) ] xpt_print(periph-path, removing device entry\n); disk_destroy(softc-disk) [in geom_disk.c] ...shimmering GEOM magic... At this point, the disk is gone, and the periph struct will be released. Unfortunately, in our case the file system still holds a reference to the periph, which keeps it from being freed in cam_periph_invalidate(). Instead, we end up with an existing device that holds an invalid pointer to the already released SIM struct, ultimately leading to system panic. My patch for this problem simply adds an extra explicit daclose() call, immediately after the lost device printing listed above, and sets the periph pointer in our disk struct to NULL. Some of you may be worried about that disk_destroy() call. At least, it suddenly made me worried, so I just double-checked it. It's true that having a destroyed disk is potentially dangerous, since the file system will normally access this during the unmount. However, it turns out that GEOM is already prepared for this case and has a special check in g_disk_access(), so the second call to daclose() will never actually be made. The alternative option would have been for GEOM to recognize the extra disk reference and keep the struct alive until daclose(). In that case, the first statement in that function would already be checking our periph and return ENXIO when it's NULL, so we would still be safe. From a system design perspective, it would be cleaner if the daclose() call originated from the same layer as the original daopen(), but under the circumstances I don't think this is too bad. It's hard to avoid... Finally, take the above description with a grain of salt, since I had to reconstruct some parts of it that were not found in my notes. Also, when I tested the disk_destroy() stuff a few minutes ago, I realized that the msdosfs_vfsops.c patch is as vital as the scsi_da.c one, which probably means that the -o sync option is equally vital, since the msdosfs fix is intended to be restricted to that. It looks like GEOM has another ENXIO problem in this area, but I'm not planning to investigate that today... /Henrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/84336: [usb] [reboot] instant system reboot when unmounting a powered off/unplugged+replugged USB device
On Sat, 2008-01-26 at 00:34 +, [EMAIL PROTECTED] wrote: This is a well-known error: there are underlying structures in the kernel that haven't been made to understand that drives can go away. This assumption has been false for years. However, the work required is going to be quite detailed; no quick workarounds are available (they've been discussed and rejected). So, mark this one as suspended for now. Just out of curiosity: when was this problem last discussed in earnest, what were the suggested workarounds, and why were they rejected? This seems to be a variety of my pet peeve, usb/46176. From what I see, the workaround has been about four patches away most of the time, but I get the feeling that nobody has bothered looking for it, because it has been a well-known fact that the solution must involve a full redesign of the underlying subsystems. At least four subsystems are involved here: USB, SCSI, GEOM, and the file system, which would most commonly be the msdosfs in this scenario. The first three of these SHOULD already be handling disappearing drives, but SCSI gets a bit confused when the file system is still around. That was the main problem worked around in the new patch mentioned here: http://lists.freebsd.org/pipermail/freebsd-usb/2007-December/004286.html At this point, only the file systems need to be updated. The cleanest way to handle things may be to have GEOM automatically unmount them at orphaning. Until that's done, however, unmounting from user space via devd seems to be a reasonable approach. Now, I know that this is something of a moving target. There will almost certainly be other problems in this area, for instance when some devices suddenly disappear under high load. That doesn't change the fact that we are slowly getting there. Remember: this bug won't go away until we have the courage to stop running, turn around, and say boo! :-) /Henrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
usb/46176: Let's save the horse!
I have uploaded an updated version of the patch set: http://www.gulbra.net/freebsd-usb/umass2.tar.gz Apparently, the original patches didn't help much for the latest version of FreeBSD-CURRENT, but this version seems to do the trick. I have tried it with 1001 attach/detach iterations and didn't get a single error. 1001 iterations correspond to about two and a half hours of manual testing, so that's about as far as I'm prepared to go for today! :-) As before, here is a quick overview of the contents of umass2.tar.gz: etc/devd.conf.patch: Hurray! I've updated it to use devd.conf instead of the obsoleted usbd.conf file. This also means that the usb_subr.c patch is no longer needed for things to work in this version. etc/devd/umass: Other things in devd.conf seem to have their scripts in the rc.d directory, but I didn't want to think about that now, so the umass script has simply been moved from etc/usbd to etc/devd. Also, the original script had a bug: I had forgotten to initialize the user data before attempting to execute the user's .umass script after detaching. In the current version, user info is fetched from the device directory. src/msdosfs_vfsops.c.patch: The msdosfs_vfsops.c file had changed in a radical way, so this is a new patch that should do about the same thing as the corresponding patch in the original patch set. src/scsi_da.c.patch: I couldn't help noticing that detaching failed miserably in the latest CURRENT. Basically, the unmount call attempted to close the da device, but crashed because the SCSI Interface Module was already gone. This patch tries to solve it by explicitly calling daclose as soon as the AC_LOST_DEVICE event is received. I'm hoping to get away with it, since everything happens within the da device driver, but some extra code review would probably not hurt... /Henrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
READ_CAPACITY_OFFBY1 [was: Re: usb/umass, devfs: this sucks]
I'm dropping the stable list and continuing discussion on the USB list. On Wed, 2007-12-26 at 11:48 -0700, M. Warner Losh wrote: The patch in [usb/78984] is wrong. There are devices that are an odd number of sectors. This is one of the places where the obvious patch isn't necessarily right. On Wed, 2007-12-26 at 17:45 -0700, M. Warner Losh wrote: There's already a quirk for this problem that has been applied to the few devices that it affects. That would be the new READ_CAPACITY_OFFBY1, which you checked in about five months after my patch submission :-) Maybe we need to add one more to the list? There was also talk of forcing a read to the last sector if the sector count was odd, but it never got past talk. Well, there are at least three ways of handling this, but none of them seems particularly good to me. It all boils down to a trade-off: a) Using the quirk flag. This is the obvious solution, now when it has been added to the umass.c file. The problem with quirks in general is highlighted by your check-in comment: ...there are a host of other devices with this issue, including iPods and some popular cameras. Each of these will be separately debugged and added to the list, and since the link between cause and effect can be less than obvious in this case, that can take hours of work per device. b) Reading from the last sector. This is an interesting solution, but worries me, because that sector will technically be out-of-range in the devices that we're interested in. If they can't get the sector count right, how will they handle a read from an invalid sector? I'm not a bit surprised if there are devices out there that would block indefinitely, convert the read to a write in the first sector and corrupt the file system, or generally burn the barn... c) Using heuristics. This is what I did when I assumed that there should typically be an even number of sectors. While that is obviously a bit too optimistic, perhaps there are other sufficiently good algorithms for detecting the incorrect cases with a negligible number of false positives. It may be due to a lack of imagination, but I find it hard to think of any reason why somebody would put exactly 256001 512-byte sectors on a umass device, unless that's an off-by-one error in itself. For my own personal use, solution (a) is good enough, but I'd prefer a more general solution, so we can use scarce developer time in a more useful way than for identifying this quirk over and over again. /Henrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/umass, devfs: this sucks
On Wed, 2007-12-26 at 00:35 -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Mikhail Teterin [EMAIL PROTECTED] writes: : If we want people to give FreeBSD a try in good faith, it is both profoundly : stupid and dishonest on our part to claim, we have a working USB-system... It : does not matter, how great our buffer-sharing VM is, if a home user can't : process their photos with a FreeBSD-powered computer. In an ideal world, it would be perfect. However, all the USB hardware I've recently purchased actually does work without a hitch on my FreeBSD system. Older card readers are more problematic. Rather than complain about the system, how about merging RELENG_7's usb stack to RELENG_6? Or fixing a few bugs from the PRs that are filed? I did my time in a big push for 7.0, maybe some other people can help out a little too? Fixing and merging are good, but it seems to me (as an occasional patch contributor without commit privileges) that the bottleneck for USB is still in the handling of incoming patches. At the moment, there are 162 USB PRs to close. Out of these, 103 are marked with [patch], but only 42 of those are actually in patched state. Almost all of the latter were apparently handled as part of Warner's summer push. The USB stack has to deal with many third-party devices, most of which will not be immediately available for testing by FreeBSD developers. This means that we are more or less forced to rely on external patch contributors (such as myself) to provide workarounds for the problems caused by various hardware peculiarities. Usually, it shouldn't take more than a basic code review to accept these patches, so this would be a good place to start if you want to improve USB handling in FreeBSD. Look at it from my perspective: I would be happy to complete my fix for the infamous five-year-old usb/46176, so people can finally detach umass devices without having to manually unmount them first. However, it will undoubtedly take a non-trivial amount of time to reproduce and eliminate the remaining issues. I'm more likely to put in that effort if I believe that my patches may actually end up in CURRENT, but if a one-line fix such as that in usb/78984 has not been applied after more than a year, how long will it take for patches that involve multiple subsystems? /Henrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/umass, devfs: this sucks
On Wed, 2007-12-26 at 11:48 -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Henrik Gulbrandsen [EMAIL PROTECTED] writes: : Look at it from my perspective: I would be happy to complete my fix for : the infamous five-year-old usb/46176, so people can finally detach umass : devices without having to manually unmount them first. However, it will : undoubtedly take a non-trivial amount of time to reproduce and eliminate : the remaining issues. There's no patches in this bug. Correct. I was hoping to have a complete fix before making any official announcements, especially since the approach may be a bit controversial. Fixing underlying issues one by one is not necessarily as clean as doing a complete redesign, but it's pretty efficient and good for merging too. The patches to CURRENT were described in this post to the USB list: http://lists.freebsd.org/pipermail/freebsd-usb/2007-November/004127.html : I'm more likely to put in that effort if I believe : that my patches may actually end up in CURRENT, but if a one-line fix : such as that in usb/78984 has not been applied after more than a year, : how long will it take for patches that involve multiple subsystems? The patch in this bug is wrong. There are devices that are an odd number of sectors. This is one of the places where the obvious patch isn't necessarily right. You're right. I realized that myself right after I sent the first email. The patch was already two years old when I submitted it, and I guess I must have focused a little too much on solid-state devices with large megabytes, where the sector count is very likely to be a power of two. The patch can be written as a quirk fix for this specific umass device, but (as I've mentioned elsewhere) I'd prefer something that handles the entire category of problems at once. Perhaps an extra line containing if (is_power_of_two(maxsector)) could be a working compromise, but this can be discussed in a smaller setting than the current one. /Henrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Patches for usb/46176 (problems with umass removal before unmount)
Well, apparently the list is stripping even small binary attachments, so I guess I'll just have to point you to a suitable location on the web: http://www.gulbra.net/freebsd-usb/umass.tar.gz /Henrik On Thu, 2007-11-01 at 12:48 +0100, Henrik Gulbrandsen wrote: This is not a complete fix, but this bug has been, eh... bugging me ever since I first crashed my system back in 2004. I had a set of patches for 5.3-BETA3, but it was too late to have it included on the 5.3 track, and since I was expecting some heavy redesign in the involved kernel parts, I dropped the patch delivery. Unfortunately, not that much has changed in this area in the past three years, and the current behavior is still far from the ideal I'd prefer: when you plug in a USB memory stick, a new directory is automatically mounted, and when it is unplugged, the directory silently disappears. The attached umass.tar.gz file contains patches and scripts that will give you this functionality in about 99% of the cases. The exact point of failure had moved a little since 5.3-BETA3, but the panic is still not difficult to avoid. However, the code is still highly experimental. In about 1% of USB detaches, the kernel will freeze. More specifically, in my four test runs, it happened after 63, 107, 6, and 321 cycles of attach followed by detach. Your mileage will most likely vary. I understand that the disk and file systems were not really designed for disappearing devices, so it's not that surprising if some lock is left locked under some circumstances. Or something completely different :-) Normally, I would continue looking for it, but I have other plans for the next month or two, so I don't know if I'll get the time. Perhaps someone else is interested enough to give it a shot... Anyway, here is a quick overview of the contents of umass.tar.gz: etc/usbd.conf.patch: an added entry in the usbd.conf file, to handle the umass devices. Yeah, I know... this should probably have used devd.conf instead, but this part is three years old and I didn't want to rerun the 321 attach/detach tests to verify that there is no important difference. etc/usbd/umass: the script that handles mounting and unmounting of the device directory under /media. I tried to make it work as expected, but I only have a single environment and a single USB memory stick to test with, so there may be some issues left. You'll get the gist, though... home/.umass: the main umass script will mount a directory if there is a single X11 user, or if there is no X11 user but a single user logged in at a local text terminal. The new directory will be owned by that user. If a .umass file exists in the user's home directory, it will be run to do more advanced things with the data. The included .umass is an example script that opens the GNOME file manager when the directory is mounted. src/msdosfs_vfsops.c.patch: the msdosfs will normally try to write the clean bit back to disk at unmount. When the drive is unplugged without warning, this would not only leave the file system marked as dirty, but will also cause a write failure. This patch modifies the implementation to keep the bit clean all the time if the file system is mounted with the -o sync option. This should be the case for USB memory sticks. src/usb_subr.c.patch: the usbd fails to match a usbd.conf entry during detach, since the detach event is filled in after the device is gone. This is easily fixed by moving a line to fill in the information before we clear all the relevant data. src/vfs_bio.c.patch: when the device is gone, remaining write attempts will correctly fail with ENXIO, but the failed buffer will get stuck in the sync queue. In 5.3-BETA3, this wasn't obvious until it blocked the unmounting of file systems at shutdown. Nowadays, it's detected earlier but this patch still seems to help. src/vfs_mount.c.patch: the only null-pointer problem left in the way of detaching is when the unmounting code discovers that it couldn't access the device and attempts to backtrack the correct handling already done. This patch makes it ignore the ENXIO error and finish the unmounting. That's it. I would hate to see another major release of FreeBSD where a system must be rebooted just because you forgot to do the umount before unplugging a umass device. It may again be too late to fix the remaining problems in time for the release, but I am at least hoping to see things work in 8-CURRENT Real Soon Now... /Henrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
usb/117598: [patch] Not possible to record with Plantronics DSP-400 USB headset
Number: 117598
Category: usb
Synopsis: [patch] Not possible to record with Plantronics DSP-400 USB
headset
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: Sun Oct 28 11:10:01 UTC 2007
Closed-Date:
Last-Modified:
Originator: Henrik Gulbrandsen
Release:FreeBSD 7.0-BETA1.5 i386
Organization:
Environment:
FreeBSD Test 7.0-BETA1.5 FreeBSD 7.0-BETA1.5 #2 Sat Oct 27 12:53:33 CEST 2007
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENERIC i386
(uname -a after patching)
Description:
The Plantronics DSP-400 USB headset works fine for playback, but recording
fails. A look at /dev/sndstat indicated that there were no recording channels
available, and the relevant lines from /var/log/messages are as follows:
Oct 25 17:37:43 root: Unknown USB device: vendor 0x047f product 0x0ca1 bus
uhub2
Oct 25 17:37:43 kernel: uaudio0: Plantronics Plantronics Headset, class 0/0,
rev 1.10/0.04, addr 2 on uhub2
Oct 25 17:37:43 kernel: uaudio0: ignored input endpoint of type adaptive
Oct 25 17:37:43 last message repeated 2 times
Oct 25 17:37:43 kernel: uaudio0: audio rev 1.00
Oct 25 17:37:43 kernel: pcm0: USB Audio on uaudio0
Apparently, the headset reports using an adaptive audio source endpoint for
data from the microphone. According to the USB specs, such endpoints need an
explicit synch pipe to specify the wanted sample rate [See USB Spec rev 2.0,
sec. 5.12.4.2 Feedback and the USB Device Class Definition for Audio Devices,
sec. 3.7.2.2 Isochronous Synch Endpoint]. Unfortunately, FreeBSD currently
doesn't support these synch endpoints. Fortunately, neither does the DSP-400 :-)
The rest of the story follows in the fix description...
How-To-Repeat:
Plug in your Plantronics DSP-400 headset and make sure that the snd_uaudio
kernel module is loaded. Verify that playback works and recording fails.
Fix:
Recompiling sys/dev/sound/usb/uaudio.c with defined UAUDIO_MULTIPLE_ENDPOINTS
revealed that that the required synch endpoint didn't exist. There is already a
USB quirk flag UQ_AU_INP_ASYNC, which specifies that a claimed adaptive input is
in fact not adaptive at all, but better handled as asynchronous. After setting
the flag for the DSP-400 headset, recording seems to work without obvious flaws.
I'm attaching a patch that adds this to the set of known quirks. Since this has
happened at least twice, I'm also adding some optional code that assumes that
all cases with a mysteriously missing sync endpoint should be handled similarly.
This may help to save some debugging time for other problem devices out there...
Patch attached with submission follows:
--- dev/sound/usb/uaudio.c.orig 2007-06-20 07:11:37.0 +0200
+++ dev/sound/usb/uaudio.c 2007-10-27 21:50:10.0 +0200
@@ -116,7 +116,11 @@
#else
/* #define USB_DEBUG */
#endif
+
+/* A few knobs to enable/disable features... */
/* #define UAUDIO_MULTIPLE_ENDPOINTS */
+#define UAUDIO_ASSUME_ASYNC
+
#ifdef USB_DEBUG
#define DPRINTF(x) do { if (uaudiodebug) printf x; } while (0)
#define DPRINTFN(n,x) do { if (uaudiodebug(n)) printf x; } while (0)
@@ -2018,6 +2022,12 @@
dir == UE_DIR_IN type == UE_ISO_ADAPT)
type = UE_ISO_ASYNC;
+#ifdef UAUDIO_ASSUME_ASYNC
+ /* Dammit! The spec doesn't allow this, so why not assume a quirk? */
+ if (dir == UE_DIR_IN type == UE_ISO_ADAPT id-bNumEndpoints == 1)
+ type = UE_ISO_ASYNC;
+#endif
+
/* We can't handle endpoints that need a sync pipe yet. */
sync = FALSE;
if (dir == UE_DIR_IN type == UE_ISO_ADAPT) {
@@ -2050,9 +2060,18 @@
if (sync id-bNumEndpoints = 1) {
printf(%s: a sync-pipe endpoint but no other endpoint\n,
device_get_nameunit(sc-sc_dev));
+#ifndef UAUDIO_ASSUME_ASYNC
+ if (dir != UE_DIR_IN)
+ return USBD_INVAL;
+ printf(This device may need a UQ_AU_INP_ASYNC quirk flag.\n);
+ printf(Consider adding it in sys/dev/usb/usb_quirks.c !!!\n);
+ printf(vendor: 0x%04x; product: 0x%04x; release: 0x%04x\n,
+ sc-sc_vendor, sc-sc_product, sc-sc_release);
+#endif /* UAUDIO_ASSUME_ASYNC */
return USBD_INVAL;
}
-#endif
+#endif /* UAUDIO_MULTIPLE_ENDPOINTS */
+
if (!sync id-bNumEndpoints 1) {
printf(%s: non sync-pipe endpoint but multiple endpoints\n,
device_get_nameunit(sc-sc_dev));
--- dev/usb/usb_quirks.c.orig 2007-07-22 17:59:45.0 +0200
+++ dev/usb/usb_quirks.c2007-10-27 12:53:02.0 +0200
@@ -74,6 +74,8 @@
{ USB_VENDOR_TELEX, USB_PRODUCT_TELEX_MIC1, 0x009, { UQ_AU_NO_FRAC }},
{ USB_VENDOR_SILICONPORTALS, USB_PRODUCT_SILICONPORTALS_YAPPHONE
Re: usb/117598: [patch] Not possible to record with Plantronics DSP-400 USB headset
The following reply was made to PR usb/117598; it has been noted by GNATS. From: Henrik Gulbrandsen [EMAIL PROTECTED] To: Hans Petter Selasky [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: usb/117598: [patch] Not possible to record with Plantronics DSP-400 USB headset Date: Sun, 28 Oct 2007 14:43:07 +0100 On Sun, 2007-10-28 at 14:27 +0200, Hans Petter Selasky wrote: What you experience is very common and I think that a quirk would be useless. How about assuming ASYNC by default ? Well, I couldn't think of a good reason not to, so that's why you'll find a #define UAUDIO_ASSUME_ASYNC at the beginning of the patch. I just wanted to make it easy to turn it off, just in case someone else could think of a good reason why that would be better - and the quirk fix is there to ensure that my own headset keeps working in that case. I wouldn't have added the quirk flag if it wasn't for the fact that it was already there. In a case like this, I'd prefer to work around the problem once and for all. See the usb/78984 patch for example. That was never applied, by the way. I probably missed some administrative detail. /Henrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/117598: [patch] Not possible to record with Plantronics DSP-400 USB headset
The following reply was made to PR usb/117598; it has been noted by GNATS.
From: Henrik Gulbrandsen [EMAIL PROTECTED]
To: M. Warner Losh [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: usb/117598: [patch] Not possible to record with Plantronics
DSP-400 USB headset
Date: Sun, 28 Oct 2007 16:45:46 +0100
--=-58217vnrXX1U7ux/YEJl
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
On Sun, 2007-10-28 at 07:50 -0600, M. Warner Losh wrote:
If the patch is reliable (eg, we get no false positives from the
printf), then we should eliminate the quirk.
True, but this would require at least a small leap of faith, since I
haven't analyzed the consequences in detail. All I know is that we are
currently handling this as an error situation and return USBD_INVAL.
Assuming an asynchronous endpoint and continuing will work around the
problem if this is indeed what the device expects, but it may lead to
other bugs if the core problem is something else.
My qualified guess is that this will probably help more often than it
hurts, so I enabled UAUDIO_ASSUME_ASYNC by default. If we check this in
and nobody complains in the near future, then it's probably safe to do
as you say and eliminate the quirk (and the printf) in a later version.
/Henrik
P.S. The patch is virtually unreadable in the web version, so I'm
attaching it again, hoping to get better formatting this time.
--=-58217vnrXX1U7ux/YEJl
Content-Disposition: attachment; filename=dsp-400.diff
Content-Type: text/x-patch; name=dsp-400.diff; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
--- dev/sound/usb/uaudio.c.orig2007-06-20 07:11:37.0 +0200
+++ dev/sound/usb/uaudio.c 2007-10-27 21:50:10.0 +0200
@@ -116,7 +116,11 @@
#else
/* #define USB_DEBUG */
#endif
+
+/* A few knobs to enable/disable features... */
/* #define UAUDIO_MULTIPLE_ENDPOINTS */
+#define UAUDIO_ASSUME_ASYNC
+
#ifdef USB_DEBUG
#define DPRINTF(x)do { if (uaudiodebug) printf x; } while (0)
#define DPRINTFN(n,x) do { if (uaudiodebug(n)) printf x; } while (0)
@@ -2018,6 +2022,12 @@
dir == UE_DIR_IN type == UE_ISO_ADAPT)
type = UE_ISO_ASYNC;
+#ifdef UAUDIO_ASSUME_ASYNC
+ /* Dammit! The spec doesn't allow this, so why not assume a quirk? */
+ if (dir == UE_DIR_IN type == UE_ISO_ADAPT id-bNumEndpoints == 1)
+ type = UE_ISO_ASYNC;
+#endif
+
/* We can't handle endpoints that need a sync pipe yet. */
sync = FALSE;
if (dir == UE_DIR_IN type == UE_ISO_ADAPT) {
@@ -2050,9 +2060,18 @@
if (sync id-bNumEndpoints = 1) {
printf(%s: a sync-pipe endpoint but no other endpoint\n,
device_get_nameunit(sc-sc_dev));
+#ifndef UAUDIO_ASSUME_ASYNC
+ if (dir != UE_DIR_IN)
+ return USBD_INVAL;
+ printf(This device may need a UQ_AU_INP_ASYNC quirk flag.\n);
+ printf(Consider adding it in sys/dev/usb/usb_quirks.c !!!\n);
+ printf(vendor: 0x%04x; product: 0x%04x; release: 0x%04x\n,
+ sc-sc_vendor, sc-sc_product, sc-sc_release);
+#endif /* UAUDIO_ASSUME_ASYNC */
return USBD_INVAL;
}
-#endif
+#endif /* UAUDIO_MULTIPLE_ENDPOINTS */
+
if (!sync id-bNumEndpoints 1) {
printf(%s: non sync-pipe endpoint but multiple endpoints\n,
device_get_nameunit(sc-sc_dev));
--- dev/usb/usb_quirks.c.orig 2007-07-22 17:59:45.0 +0200
+++ dev/usb/usb_quirks.c 2007-10-27 12:53:02.0 +0200
@@ -74,6 +74,8 @@
{ USB_VENDOR_TELEX, USB_PRODUCT_TELEX_MIC1, 0x009, { UQ_AU_NO_FRAC }},
{ USB_VENDOR_SILICONPORTALS, USB_PRODUCT_SILICONPORTALS_YAPPHONE,
0x100, { UQ_AU_INP_ASYNC }},
+ { USB_VENDOR_PLANTRONICS, USB_PRODUCT_PLANTRONICS_DSP400,
+ 0x004, { UQ_AU_INP_ASYNC }},
{ USB_VENDOR_LOGITECH, USB_PRODUCT_LOGITECH_UN53B, ANY, { UQ_NO_STRINGS }},
/* XXX These should have a revision number, but I don't know what they are.
*/
{ USB_VENDOR_HP, USB_PRODUCT_HP_895C,ANY, {
UQ_BROKEN_BIDIR }},
--- dev/usb/usbdevs.orig 2007-10-05 09:26:39.0 +0200
+++ dev/usb/usbdevs2007-10-27 12:53:06.0 +0200
@@ -1851,6 +1851,9 @@
product PLANEX3 GU1000T 0xab11 GU-1000T
product PLANEX3 GWUS54MINI0xab13 GW-US54Mini
+/* Plantronics products */
+product PLANTRONICS DSP4000x0ca1 DSP-400 Foldable PC Headset
+
/* Plextor Corp. */
product PLEXTOR 40_12_40U 0x0011 PlexWriter 40/12/40U
--=-58217vnrXX1U7ux/YEJl--
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/108513: [umass] Creative MuVo TX FM fails in 6.2-RELEASE (regression)
The following reply was made to PR usb/108513; it has been noted by GNATS. From: Henrik Gulbrandsen [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: usb/108513: [umass] Creative MuVo TX FM fails in 6.2-RELEASE (regression) Date: Thu, 25 Oct 2007 15:13:11 +0200 I just happened to see this report; anyone wanting to get rid of this bug might want to start by testing the patch given for PR usb/78984. There is no way to confirm it without access to the same hardware, but the Creative MuVo brand and the BBB errors look suspiciously similar. /Henrik ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
