APC's Back-UPS devices not recognized as uhid -- only as ugen
The sysutiles/apcupsd/files/pkg-message.in advises one to enable uhid(4) in kernel for the UPS-units to be recognized by the software: NOTE that for USB cable you must comment out the line device uhid# Human Interface Devices in your kernel configuration file and recompile the kernel. Your keyboard and mouse will still work. Unfortunately, the uhid(4) driver does not attach to either of the two Back-UPS devices I have -- both are seen only as ugen and apctest does not want to work with that. For example, when the current unit is connected as: ugen4.9: Back-UPS RS 1000G FW869.L3 .D USB FWL3 American Power Conversion at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON the software reports: root@narawntapu:/home/mi (118) apctest -d 1000 2012-11-02 13:39:50 apctest 3.14.10 (13 September 2011) freebsd Checking configuration ... 0.000 apcupsd: apcconfig.c:799 After config scriptdir: /opt/etc/apcupsd 0.000 apcupsd: apcconfig.c:800 After config pwrfailpath: /var/run 0.000 apcupsd: apcconfig.c:801 After config nologinpath: /var/run 0.000 apcupsd: newups.c:102 write_lock at drivers.c:208 0.000 apcupsd: drivers.c:210 Looking for driver: usb 0.000 apcupsd: drivers.c:214 Driver dumb is configured. 0.000 apcupsd: drivers.c:214 Driver apcsmart is configured. 0.000 apcupsd: drivers.c:214 Driver net is configured. 0.000 apcupsd: drivers.c:214 Driver usb is configured. 0.000 apcupsd: drivers.c:217 Driver usb found and attached. 0.000 apcupsd: newups.c:108 write_unlock at drivers.c:234 0.000 apcupsd: drivers.c:236 Driver ptr=0x4231c0 Attached to driver: usb sharenet.type = Network ShareUPS Disabled cable.type = USB Cable mode.type = USB UPS Driver Setting up the port ... 0.000 apcupsd: newups.c:102 write_lock at generic-usb.c:655 0.000 apcupsd: generic-usb.c:425 Initializing libusb 0.000 apcupsd: generic-usb.c:430 Found 1 USB busses 0.001 apcupsd: generic-usb.c:432 Found 13 USB devices *0.001 apcupsd: generic-usb.c:443 /dev/usb:/dev/ugen4.9 - 051d:0002 0.001 apcupsd: generic-usb.c:446 Trying device /dev/usb:/dev/ugen4.9 0.002 apcupsd: hidutils.c:255 Got string of length=14: 3B1217X28266 0.002 apcupsd: generic-usb.c:358 device='3B1217X28266', user='auto'* 0.002 apcupsd: generic-usb.c:443 /dev/usb:/dev/ugen4.8 - 04b4:6560 0.002 apcupsd: generic-usb.c:443 /dev/usb:/dev/ugen4.7 - 0409:005a 0.002 apcupsd: generic-usb.c:443 /dev/usb:/dev/ugen4.6 - 0409:005a 0.002 apcupsd: generic-usb.c:443 /dev/usb:/dev/ugen4.5 - 0461:4d03 0.002 apcupsd: generic-usb.c:443 /dev/usb:/dev/ugen4.4 - 0409:005a 0.002 apcupsd: generic-usb.c:443 /dev/usb:/dev/ugen4.3 - 413c:2003 0.002 apcupsd: generic-usb.c:443 /dev/usb:/dev/ugen4.2 - 0409:005a 0.002 apcupsd: generic-usb.c:443 /dev/usb:/dev/ugen4.1 - : 0.005 apcupsd: generic-usb.c:443 /dev/usb:/dev/ugen3.1 - : 0.005 apcupsd: generic-usb.c:443 /dev/usb:/dev/ugen2.1 - : 0.005 apcupsd: generic-usb.c:443 /dev/usb:/dev/ugen1.1 - : 0.005 apcupsd: generic-usb.c:443 /dev/usb:/dev/ugen0.1 - : 0.005 apcupsd: newups.c:108 write_unlock at generic-usb.c:671 *apctest FATAL ERROR in generic-usb.c at line 674 Cannot find UPS device --* For a link to detailed USB trouble shooting information, please see http://www.apcupsd.com/support.html. 0.005 apcupsd: newups.c:102 write_lock at generic-usb.c:694 0.005 apcupsd: newups.c:108 write_unlock at generic-usb.c:701 apctest error termination completed Working off of the neighbor's generator after Sandy, I've developed a whole new appreciation for UPS devices and would like for my system to be able to interact with one directly and automatically... Please, advise. Thanks! -mi ___ 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: [uaudio] Sound-recording too fast
On 11.09.2011 15:57, Hans Petter Selasky wrote: Have you tried the Logitec quirk mentioned at the FreeBSD WIKI page? http://wiki.freebsd.org/WebcamCompat No, I have not seen that page before. My webcam is the C310, and, I guess, the magic command in [1] would've helped me too. I wonder, what that string does, though... If it forces the sampling rate to the actual 48K, I may not even want it -- the sound was just fine at 16K and it, likely, takes up a lot less bandwidth... Thanks for the pointer! -mi ___ 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
[uaudio] Sound-recording too fast
Hello! I have a Logitech's webcam with built-in microphone. The audio device is recognized by FreeBSD-8-stable as: uaudio0: vendor 0x046d product 0x081b, class 239/2, rev 2.00/0.10, addr 2 on usbus2 uaudio0: No playback! uaudio0: Record: 48000 Hz, 1 ch, 16-bit S-LE PCM format uaudio0: No midi sequencer pcm1: USB audio on uaudio0 mixer(8) reports it a little strangely, depending on which /dev-entry I use: % mixer -f /dev/mixer1 Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 % mixer -f /dev/dsp1 Mixer rec is currently set to 45:45 But recording works. For example, using the rec-utility from the SoX package: % env AUDIODEV=/dev/dsp1 rec /tmp/test.aiff Input File : '/dev/dsp1' (ossdsp) Channels : 2 Sample Rate: 48000 Precision : 16-bit Sample Encoding: 16-bit Signed Integer PCM Well, it almost works, because the recording ends up highly distorted -- much faster, than what I'm really saying into microphone. About three times faster. For example, if I let the above command run for 18 seconds (according to time(1)), the created test.aiff will contain a 6-seconds recording. How do I fix this? Thanks! Yours, -mi ___ 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: 8.x grudges
07.07.2010 16:50, Marcel Moolenaar написав(ла): Not to mention that if you change uart(4) to create dev entries like sio(4) after uart(4) has been in the tree for more than 6 years creating ttyu* entries, you actually introduce a gratuitous change. If sio and uart could co-exist, then you'd be right. But sio no longer builds under 8.x, so some kind of aliasing (either by uart itself or by devfs) would be useful. -mi ___ 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
8.x grudges
I'm upgrading several systems these days to the 8.1 (pre-release) and have hit the following troubles... I could file a formal PR for each, I suppose, but, maybe, this way will get the right people's attention sooner. In no particular order: 1. A picture, that one of the systems was displaying at boot (and then used as a screen-saver), stopped showing properly. The colors are right, but the picture is distorted beyond recognition. The relevant part of loader.conf is: splash_pcx_load=YES vesa_load=YES bitmap_load=YES bitmap_name=/boot/187426-9-quokka-dreaming.pcx the picture file is identified as: PCX 772x551 772x551+0+0 8-bit PseudoClass 256c 454KB 0.039u 0:00.093 2. FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and thus not an option) -- the kernel-config files, that worked with 7.x, break without this option in them (in addition to all the nuisance, that's documented in UPDATING -- which, somehow, makes the breakage acceptable). config(8) would not warn about this, but kernel build fails. 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. 4. The sio(4) is described in UPDATING as removed, but rouses no complaint from config(8) either. It just breaks the kernel build... It should be an alias for uart, IMHO -- all I want is for my serial ports to be usable, whether their driver is called Serial Input/Output or Universal Asynchronous Receiver and Transmitter. (BTW, about the /dev-entries -- do we /really/ have to change the names of the serial port-devices every couple of years? It is rather painful to reconfigure the fax- and ppp-software, etc.) How does the Microsoft world manage to stay with the COM1, COM2 for decades?) 5. One of the upgraded systems would repeatedly hang at boot, until I disabled the on-board firewire-device through the BIOS... It was not a problem under 7.x, although I don't know, whether the device actually worked. 6. Despite the reported improvements in the USB area, my USB keyboard /still/ does not work during boot. It during POST and then after the booting is complete. But in single-user mode -- no... Had to fish-out the PS2 keyboard... 7. All my dangerously dedicated disks lost the s1 in the subdevice-names after the upgrade: /dev/da1s1d became /dev/da1d, etc. I like the shorter names (and there are, indeed, no slices there), but having to fix them manually upon reboot was unpleasant and uncalled for. As with uart/sio, backward-compatibility aliases are a fine idea and really improves user's experience... 8. I tried to do an install on one of the systems via netbooting (pxeload) the disk1-image. It booted, but the sysinstall had to be started manually and, once started, did not act the same as when booted off of CD-ROM. Seems like a simple bit to correct so that setting init to /usr/sbin/sysinstall/manually on every boot/ is not necessary... 9. The k8temp utility (installed by sysutils/k8temp http://www.freshports.org/sysutils/k8temp), which worked fine on both of my AMD-machines, no longer works on the Athlon one (still works on the Opteron-based server). I reinstalled the port, but that did not help -- the utility runs, but does not say anything. Requeting debug-info is of little help: *ro...@quokka:~ (101) k8temp *ro...@quokka:~ (102) k8temp -d CPUID: Vendor: AuthenticAMD, 0x6a0: Model=0a Family=6+0 Stepping=0 Advanced Power Management=0x1 Temperature sensor: Yes Frequency ID control: No Voltage ID control: No THERMTRIP support: No HW Thermal control: No SW Thermal control: No 100MHz multipliers: No HW P-State control: No TSC Invariant: No If any of the above can be corrected or, at least, documented, before release, we stand a little bit better chance of getting the praise otherwise well-deserved by FreeBSD... Thanks. Yours, -mi ___ 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: 8.x grudges
07.07.2010 14:59, Jeremy Chadwick ???(??): FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and thus not an option) -- the kernel-config files, that worked with 7.x, break without this option in them (in addition to all the nuisance, that's documented in UPDATING -- which, somehow, makes the breakage acceptable). config(8) would not warn about this, but kernel build fails. We don't use this option (meaning it's removed from our kernels). It's definitely not required. All it does is ensure your kernel can comprehend executables/binaries built on 7.x. Attached is the kernel config-file (i386), that worked fine under 7.x. The kernel-compile will break (some *freebsd7* structs undefined), without the COMPAT_FREEBSD7 option. Try it for yourself... 3. Likewise, having device ugen breaks config(8) -- another undocumented incompatibility. This sounds like you not including all of the necessary USB/device framework in your kernel configuration. You're not providing enough output for us to help diagnose the problem, though. Put device ugen back into the attached kernel-config file and see config's error yourself. 4. The sio(4) is described in UPDATING as removed, but rouses no complaint from config(8) either. It just breaks the kernel build... It should be an alias for uart, IMHO -- all I want is for my serial ports to be usable, whether their driver is called Serial Input/Output or Universal Asynchronous Receiver and Transmitter. I disagree (re: it should be an alias). sio(4) is deprecated (meaning it's not used by default any more), and it's left in the driver tree solely as a fall-back method if someone runs into uart(4) problems. If it were merely deprecated it would've still worked. It does not -- put device sio into the attached kernel-config and try building -- you'll get the compile-error. Whether deliberately or through bit-rot, uart /replaced/ sio... I'll take a moment to point out that your complaints about the kernel configuration file, so far, seem to stem from you not migrating your kernel configuration from 7.x to 8.x. Things change -- that's the reality of the situation. The way I do this is, when upgrading major releases (7.x-8.x), to start fresh using GENERIC as my base template and then adding/adjusting while comparing against the older kernels' config. Others do it differently, this is just how I do it. Yes, your way is fine. But so is mine. It is perfectly reasonable to expect my method to work just as well -- the 7-8 is not revolutionary, but simply the next step. I read the UPDATING file and, though annoyed a little, took care of things mentioned in there... The remaining things are enumerated here... (BTW, about the /dev-entries -- do we /really/ have to change the names of the serial port-devices every couple of years? It is rather painful to reconfigure the fax- and ppp-software, etc.) How does the Microsoft world manage to stay with the COM1, COM2 for decades?) Like I said: things change. Well, pardon the political pun, but I don't believe in change for the sake of change. These particular changes are gratuitous. If sio is no longer available -- and replaced by uart, why change the /dev-entries?.. 5. One of the upgraded systems would repeatedly hang at boot, until I disabled the on-board firewire-device through the BIOS... It was not a problem under 7.x, although I don't know, whether the device actually worked. This is a commonly-reported problem, assuming at boot you mean while the kernel is starting. Or unless you're using a certain model of Shuttle box, but that turned out to be literally a BIOS bug: http://koitsu.wordpress.com/2009/05/22/shuttle-sg45h7-firewire-bug-in-bios-sg45u10o/ No, this is not it /at all/. The link above describes a crash in the BIOS (and no POST), if firewire circuitry is disabled in BIOS. My problem is with FreeBSD kernel hanging on boot, if the firewire circuitry is enabled in BIOS. The boot was fine under 7.x, so this can not be due to a BIOS-bug -- the only thing, that changed, is the OS... This is also a commonly-reported problem (and one I've harped on as well). When you say during boot: does it work during loader (the screen with the FreeBSD logo on it)? Yes. If the keyboard works during loader but not once the kernel + kernel USB stack loads (e.g. when booting into single-user), then look at the very bottom of this page for a couple things to try: http://wiki.freebsd.org/BugBusting/Commonly_reported_issues Will do, thanks! Still, I was hoping, things will just work with 8.1... Regardless, this is one of the reasons I still have not made the move to USB keyboards and stick with PS/2 keyboards on FreeBSD. While renovating the house, I ran USB-, audio-, and video-cables through the walls from server room to
Re: 8.x grudges
07.07.2010 16:34, Randi Harper ???(??): Attached is the kernel config-file (i386), that worked fine under 7.x. The kernel-compile will break (some *freebsd7* structs undefined), without the COMPAT_FREEBSD7 option. Try it for yourself... Don't use a kernel config from 7. We've already told you this. Your telling me this is just as valid as warning me against using computer-cases of a particular color. It is a silly requirement. My expecting things, that worked for 7, to work in 8 is reasonable. There may be (documented!) exceptions, but it ought to just work. Yes, your way is fine. But so is mine. It is perfectly reasonable to expect my method to work just as well -- the 7-8 is not revolutionary, but simply the next step. I read the UPDATING file and, though annoyed a little, took care of things mentioned in there... The remaining things are enumerated here... Your way clearly isn't fine, as it doesn't work. That's an obviously flawed argument -- this line of thinking can be used against ANY ONE reporting ANY BUG -- if one has a problem, then one's way of doing things clearly isn't fine. These changes aren't gratuitous. Did you read the commit messages behind each of the changes? I'm guessing that you haven't. No, and I'm not going to. A commercial OS would've been the laughing stock, if one hand to change C: to 1: between releases, for example... Again: this particular change seems gratuitous. It's not. You didn't bother researching before complaining. I bothered to type up my list. Presumably, problem-reports are welcome. I've been a Unix-user since 1990, a FreeBSD user since 1993 (or 94?), and a project-member for a decade. If *I* have a problem, then newer users certainly will too. And, guess what, they'll simply go with something, that does not give as much grief... To put it in simple terms, there were changes made to geom, and the way that sysinstall writes out dedicated disks wasn't compatible. Search the mailing list archives. If this is a known problem, it is even more of an outrage, that some shim was not introduced to keep the users from hitting this particular bump. The modification should be necessary. Why? Why should a netboot act differently from a local boot from CD? Just because you don't want to make the modification doesn't mean it was made that way by accident. No, I never claimed this to have been an accident... That variable can be set to any number of things. We don't advertise the iso image just working out of the box for pxe booting. You don't. But there is very little, that needs to be added there for it to just work over both netboot and local CD, and you should do it, instead of arguing with me here... No, I don't know, what it is exactly, but I'm quite certain, it can't be very much. In fact, the article about PXE booting on the official freebsd website says nothing about using the ISO. You just found some article that said it was possible (and it is) and complained because you didn't like the process? Yes, exactly. I didn't like process -- it is needlessly complicated. The same CD-image, /should/ also be usable out of the box for netbooting. Funny. It works just fine in 8.0 on my Athlon. Have you tried updating the port? Yes, I have -- and I said so in my very first e-mail on this subject. For someone, who expects people to research mailing lists, you do a terrible job of following a one-day-old thread... Also, even if it didn't work, this is an issue you should take up with the author of the port. Tom -- the maintainer -- is still in CC... From the man page: The amdtemp driver provides support for the on-die digital thermal sensor present in AMD K8, K10 and K11 processors. I know nothing about the driver. But a utility I regularly used stopped working after upgrade, so I added that to my list of upgrade-related grudges. -mi ___ 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
Ioctl 0x7601 on /dev/video0 - `linux' in kernel
Hello!
I've successfully installed webcamd on this 8.1-prerelease system and
even saw myself in pwecview.
However, when I try to run skype, I get the same IOCTL-errors logged,
that are mentioned in:
http://www.mail-archive.com/freebsd-usb@freebsd.org/msg06354.html
linux: pid foo (skype): ioctl fd=10, cmd=0x7601 ('v',1) is not
implemented
I have linuxulator in the kernel (option COMPAT_LINUX), however, so, I
thought, it is supposed to just work... But it does not. Is anyone
successful getting skype with video on FreeBSD?
Any ideas? Thanks a lot!
-mi
___
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
7.3: instant panic upon connecting a umass
Hello! I'm suffering from a fully reproducible panic, that strikes, when I connect a umass storage device (Blackberry Pearl with a mini-SD card inserted) to the EHCI USB port. The system runs a freshly rebuilt 7.3-stable/amd64. The crash is somewhere inside USB-stack. The stack, as produced by kgdb, can be found at: http://aldan.algebra.com/~mi/tmp/usb-crash.txt The usb4-process -- the current process at the panic-time -- is associated with: usb4: EHCI version 1.0 usb4: companion controllers, 3 ports each: usb2 usb3 usb4: NEC uPD 720100 USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: NEC EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb4 The system is running has 6Gb of RAM and 2 dual-core Opterons. The connection was just fine with 7.2-stable from March 5th, although that kernel was not an SMP one (by mistake). Please, advise. Thank you, -mi P.S. Is the USB supposed to work in 7.x, or do I have to go to 8.x for it to work reliably? ___ 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: 7.3: instant panic upon connecting a umass
Jeremy Chadwick написав(ла): Regarding your problem: it likely has nothing to do with SMP, so don't worry about that aspect of it. Thanks for the reassuring response, Jeremy. If this is not about SMP, then there is a (bad) regression -- the 7.2-kernel from March 5 never crashed this way... I connected the same phone numerous times, as well as the camera... I shall await response from USB-maintainers... -mi ___ 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: BlackBerry (Re: using libusb)
понеділок 14 січень 2008, Kirk Davis, Ви написали: = I have ported the uberry driver from OpenBSD over to FreeBSD. I have = done a lot of changed and support for the new devices and am just = working on some final changed before submitting it. I abandoned the = linux uberry driver as I didn't like the inteaction with libusb and = running it from userspace. Thanks, Kirk. Without knowing the details of your work, I can only emphasise once again, the API-compatibility with (the Linuxish) libusb is an absolute requirement. I'm sure, the API can be argued to be lacking in some respect or another. I'd also accept the validity of arguments for making kernel-drivers for various devices (such as uberry) instead of exposing them as ugen and letting the user-space software deal with them. However, without the libusb API-compatibility AND the sysctl-compatibility for Linuxulator we will not be able to compile/run the applications written for Linux (Solaris?). Some time ago BSD decided to go its own way with video instead of adopting the video4linux framework. I don't know the arguments leading that decision, but I'm quite certain, they were and remain sound... Unfortunately, it also meant incompatibility with Linux-targeted apps, and we should not repeat the same mistake with USB. uberry(4) is nice, but libusb is a must... -mi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
usb/114682: USB media-card reader unusable
Number: 114682 Category: usb Synopsis: USB media-card reader unusable Confidential: no Severity: serious Priority: high Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed Jul 18 03:30:01 GMT 2007 Closed-Date: Last-Modified: Originator: Mikhail T. Release:FreeBSD 6.2-STABLE amd64 Organization: Virtual Estates, Inc. Environment: System: FreeBSD aldan.algebra.com 6.2-STABLE FreeBSD 6.2-STABLE #2: Tue Jul 17 23:00:12 EDT 2007 [EMAIL PROTECTED]:/meow/obj/var/src/sys/SILVER-SMP amd64 Description: I'm using a generic multi-standard media-card reader. Its several slots are identified at boot-time as: da2 at umass-sim0 bus 0 target 0 lun 0 da2: Generic USB SD Reader 1.00 Removable Direct Access SCSI-0 device da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da3 at umass-sim0 bus 0 target 0 lun 1 da3: Generic USB CF Reader 1.01 Removable Direct Access SCSI-0 device da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present da4 at umass-sim0 bus 0 target 0 lun 2 da4: Generic USB SM Reader 1.02 Removable Direct Access SCSI-0 device da4: 40.000MB/s transfers da4: Attempt to query device size failed: NOT READY, Medium not present da5 at umass-sim0 bus 0 target 0 lun 3 da5: Generic USB MS Reader 1.03 Removable Direct Access SCSI-0 device da5: 40.000MB/s transfers da5: Attempt to query device size failed: NOT READY, Medium not present Fair enough -- at boot time the slots are all empty. However, when I then insert a card (SD) into the proper slot and try to mount /dev/da2s1 -- or even to `fdisk da2', the command hangs for A LONG time... Pressing Ctrl-T reveals, that the hang is inside `cbwait'. During this time, a number of errors are logged on the console: umass0: BBB reset failed, TIMEOUT umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR And the command fails eventually with can't open device /dev/da2: Input/output error. The only way to get to the data, apparently, is to boot with the card inserted -- unacceptable in most cases :( I first observed this with the kernel from June 7, 2007. But I was using an EXTERNAL reader before then... The problem is still here with 6.2-stable from July 17th. How-To-Repeat: Fix: Use an EXTERNAL card-reader, and connect it with the card already inserted. This _may_ work... 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 [EMAIL PROTECTED]
Re: All-in-one printer/scanner dilemma
Hans Petter Selasky wrote: You mean, sane may be able to access the scanner part, even if ulpt is attached? Yes, but that may [or can be] change[d]. I'm confused, are you saying, it may be possible to share the functionality /now/? So, which device should I give to sane? The /dev/ulpt0? We're talking some time this year. Great -- the sooner the better, thank you! (Frankly, it is embarrassing, that we did not have it 3 years ago :-( Not to point any fingers at anyone in particular.) -mi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
