Re: Byte-banging a USB device attached on ugen
On 27/04/2016 4:06 AM, Karl Denninger wrote: So I've got one of these ugen0.5: at usbus0 Which is a CM15. It does not appear to attach as an HID or expose a serial-like interface (on a tty or cua device node.) I have documentation of two end-points that this device uses, one for transmitting data to the host and one for receiving commands from the host, along with the byte-format protocol that is expected on each. As such if I can determine how to programmatically access those two end-points I should be good. What I'm having trouble finding documentation on is how to open the device and attach a byte stream to those endpoints on FreeBSD (e.g. how to get it open and specify which endpoint to associate with the handle) and once I do, can I expect to use the usual select() paradigm to see if they're ready for read (e.g. something is on the bus inbound to me) and ready for write (can be written to.) Is there a pointer available somewhere to a code fragment that shows how to do this? I also want to get the device specification as part of the setup, obviously, to make sure I'm talking to the right device and not some other random thing that was plugged in -- my intent is to handle the situation where my code can detect a hot-plug (or unplug) of the device and initialize and/or shut down the channel accordingly and thus I want to iterate over the ugen devices I find and check them for the correct device specification. what you are looking for is libusb I think. https://www.freebsd.org/cgi/man.cgi?apropos=0&sektion=3&query=libusb20&manpath=FreeBSD+5.0-current&format=html you should also look at the webcamd which I think uses it. Thanks in advance! ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Test Results
On 5/26/14, 2:16 PM, Hans Petter Selasky wrote:
On 05/26/14 05:16, Ronald F. Guilmette wrote:
2) As can be seen in the "desktop2-varlogmessages.txt' log file,
on that
one system there were also a number of additional errors logged
after the
Hitachi Touro Mobile drive was plugged in:
(probe0:umass-sim2:2:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:umass-sim2:2:0:0): CAM status: CCB request completed
with an error
(probe0:umass-sim2:2:0:0): Retrying command
(probe0:umass-sim2:2:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:umass-sim2:2:0:0): CAM status: CCB request completed
with an error
(probe0:umass-sim2:2:0:0): Retrying command
(probe0:umass-sim2:2:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:umass-sim2:2:0:0): CAM status: CCB request completed
with an error
(probe0:umass-sim2:2:0:0): Retrying command
Hi,
This error is typical for no-synchronize-cache.
1)
Lookup the device above using "usbconfig".
2)
Add the quirk, where X.Y are the numbers after "ugen".
usbconfig -d X.Y add_quirk UQ_MSC_NO_SYNC_CACHE
3)
Replug this device.
I've seen this pattern a bit too much.
user: I see error X
dev: turn on quirk Y, disabling {lock device, queuing, syncing,
block erase, etc.}
Would it be possible for part of the attach code for drives, to silently
run through a bunch of these commands and just turn off those that
return errors? In the Old (old) SCSI code we did this in some devices,
and in some cases there were capability descriptions in some of the
sense pages.
(though I think that was on some proprietary subdrivers).
--HPS
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
___
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: hot usb sticks
On 10/5/13 11:46 PM, Miroslav Lachman wrote: Julian H. Stacey wrote: Has anyone else noticed how hot USB sticks can get when used for backup ? & also that IO errors occur after a while, which go away after a cold reboot. Not the whole stick, but the metal connector gets hot, so chip is hotter still. Obviously one won't notice this on large plastic encassed sticks, but 2 main sicks I use are: sandisk 2Gig metal case "vendor" "0x0781"; "product" "0x5151"; delock 8G miniature (~ 3mm of platic beyond plug) "vendor" "0x05e3" "product" "0x0727" I usually notice this when I am updating (writing) a crypted (gbde) UFS file systems using port/net/rdist6 (which only rewrites updated files). Source data is 1,446,438 K bytes in 42,611 files so average size of 34 K. But a lot of the files are really small, (~/.* config & mail files etc, so as rdist will be updating each one sequentially, & each will take a read + write cycle on a stick block,& as many small files will probably map to the same stick block, thats some concentrated cycles. More stick detail at http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/jhs/etc/devd/jhs.conf Quite often I have to reboot my target host that has a stick inserted, I believe regardless of OS version on USB target host Possibly there might be less heating when only reading (as read cycles are also quicker), but mainly I'm backing up, writing. I was thinking of making a heatsink to clamp to a USB socket on an extension cable, but before that I'll try hanging a USB extension cable adjacent to a case fan. I have a few USB sticks, some of them are really old (and fast!), for example 512MB A-Data with 200x speed, or 8GB 133x. These fast sticks are almost cool. Some cheap modern sticks are hot even if used as read-only for booting ZFS backup server, where whole base system is on UFS USB stick monted read-only and all writes are on ZFS partitions of 4 HDDs. Even in this RO scenario, the hot stick died after about 2 years. Writes on it was made about 3 times a year because of system or ports updates. So in my case: newer -> cheaper -> slower -> hotter = shorter life. actually, hotter is not always worse in Flash. Warner can say more in detail but hot is good in some case while cold is best when you put the device on the shelf. Miroslav Lachman ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/181425: USB keyboard with full N-key rollover not working
On 8/20/13 8:02 PM, Mark Felder wrote: I have an opposite problem on my Dell workstation: my keyboard with N-key rollover doesn't work in BIOS or FreeBSD boot menu, but does work after the kernel is loaded... I didn't know keyboards could be problematic. ___ 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" tried a different usb port? (some bios are set up to only look for stuff on one port) ___ 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 driver locking
On 5/25/11 12:54 AM, Daniel O'Connor wrote: On 25/05/2011, at 9:51, Hans Petter Selasky wrote: current. There is also a new utility called usbdump, which can be used to figure out what is going on. I am running 9-current (in production for my sins..) usbdump is useful but consumes too much CPU at my data rate :( You probably need an USB analyzer to figure out the real problem. Have you tried to start usbdump only once the problem happens? I'll try and cook something up to run it when the problem happens. hans and Daniel, I suggest you put some KTR points into the driver and trace some crucial information using that. it is capable of keeping up with very fast stuff with small disturbance. Just the basic info.. you get 5 x 64 bit arguments. (or is it 6?) which is enough space for quite a bit of stuff to be logged. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: mount and umount large capacity external USB HDD (fstab)
I believe there are 2 limits you may be encountering. The disk is larger than 2TiB and is low-level formatted with 4096 bytes sectors. The 2TiB limit results from clculations with 32 bit integers and 512 byte sectors. The large sector size is almost certainly the problem with "dd"...you can read less than a sector, but an attempt to write less than a sector will fail. Try bs=4k. I'm running 8 Stable as of a few days ago. The "fdisk" sources on this system were updated 11/22/2010, but appear to handle sector sizes only up to 2048 bytes. I haven't checked to see if it handles disk or partition sizes above 2TiB, but it doesn't matter, it won't handle your disk properly, and I doubt that the FBSD 7.3 fdisk would either. There is no option for sector size, it's a hard-coded limit which is too small. Bsdlabel may have similar limits. The version on this system was last modified 09/26/2010. It reads the sectorsize from the disk and therefore should have no trouble with a 3tb disk. I don't know whether the 7.3 fdisk has these modifications, but with fdisk failing, it doesn't matter. If you are using the disk only under freebsd you might try using 'bsdlabel' on the entire disk (da0), but check I suspect your bsdlabel may not be upgraded yet (check sbin/bsdlabel). The manual page for 'gpart' claims that it was introduced in 7.0, and I would think it would be working reasonably by 7.3. It should be able to handle large disks and partitions with no trouble, and is much easier to use than the old stuff. You said in your last email that 'gpart show' showed nothing, but that may be because it had nothing intelligible to show. If you haven't tried it yet, and the disk contains no data which you might lose, then try the recipe from the link I gave you. Create a couple of partitions, then try 'gpart show'. Alternately, you may try getting recent versions of fdisk and bsdlabel from cvs or svn, increase the sector size limit in fdisk, and try that route again. -- Duane H. Hesser Thank you all for your input. We must admit, we have a bit more reading to do to fully understand what "Nagilum" was providing. On the other hand, we do understand more of what Mr. Hesser was saying, however, we aren't prepared to upgrade to to 8.x or start playing around by replacing/updating individual utilities on this 'live 7.3 system'. Perhaps on a test machine 'first'. Until then we will have to take the whimp way out and format the 3TB USB device with NTFS and mount it until we are better versed on exactly where Freebsds' support is for these HDD's that are greater than @-TB in size. We really would like at least one (1) FreeBSD machine that is all, dedicated so to speak, BSD. We will read that recipe. Should anyone make additions to this thread we are all eyes_&_ears. As was mentioned before, the limitationcomes from the defintion of the partition structures. Firstly the fdisk structure introduced with the IBM PC (I think) has onlt room for 32 bits on its sector tables. secondly the bsd 'label' structure introduced in the 80s has a similar limitiation. The new structure to get around this is the GPT structure. you need to partition the drive with a gpt capable partitioning tool.. gpart claims to do this (though I have never done it as I don't have a need (yet)). This limitiation will affect any system which you wil use to write those partition types and is indepenent of file system. In addition Once you have made a partition big enough, you will need to populate it wirth a filesystem capable of representing data to that scale. UFS2 and ZFS are two candidates for this. If you take a modern Windows, it will probably partitionthe drive using a GPT table or some similar modern structure.(I don't have any modern windows system so I can't tell you exactly what they do, but they MUST have done the same thingif they didn't use GPT itself.) This is a separate step from puting the file system on, though the windows tools may present it as a single step. I hope y'all will find this useful. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Intermittent pauses copying from one usb drive to another
On 2/5/11 8:28 AM, Donald Allen wrote: On Sat, Feb 5, 2011 at 10:28 AM, Hans Petter Selaskywrote: On Saturday 05 February 2011 16:18:56 Donald Allen wrote: Does whoever is responsible for CAM/SCSI know about this and do you know if there are plans to fix it? What is the point of "supporting" USB devices (and we aren't talking about an odd-ball device here; these are USB disks), when the "support" is partially broken? As far as I know there are no ongoing plans to fix this issue. Yes, we need to support the oddballs too, of course. Actually, I'm arguing that you (FreeBSD, not necessarily the USB layer) need to better support the *main-stream* devices better (I care much less about the outliers, because by definition, the quality of their support affects far fewer people). These Toshiba drives are vanilla stuff, used by many for backups Currently a lot of quirks have been pushed into the umass driver, but I guess that we need to add more quirks, and probably switch around from black-listing into white-listing, so that the quirks are turned on by default. Thanks for your understanding! I do understand, but in some ways I don't. FreeBSD is a great system, superior to Linux in many ways that have been discussed ad nauseum, but USB devices, particularly disks and flash-based devices, are ubiquitous these days, and FreeBSD's support for these devices is weak, weaker than Linux and even OpenBSD (in my experience). This seems like a very odd place for a gaping hole in the system, particularly after all the work you did to re-implement the USB layer. Hans Petter, Could the USB mass storage layer not refuse to pass down some commands and just return the proscribed error? /Don --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org" ___ 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: FYI: USB 3.0 support and the XHCI driver is now fully committed to FreeBSD-current
On 10/5/10 2:58 PM, Mark Atkinson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/05/2010 11:39, Mark Atkinson wrote: On 10/05/2010 10:09, Mark Atkinson wrote: Root mount waiting for: usbus3 usbus0 [hang, waits forever...] Well reverting to r213377 exhibits similar behavior, so I guess this is not suspect. I'll keep reverting until I find the breakage. Wish I had kept his machine on a closer track with current: r212532: working r212553: fail I'm currently suspecting the one-shot timers are causing this box to hang. -current hangs around there on boot under Xen. setting kern.eventtimers.periodic=1 from the boot prompt allows it to continue. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyrn3cACgkQrDN5kXnx8yba5wCdGOkoUzm7nnJQQfj2Tc3v5Ptg +xYAnRgcOL3HqjGbm9hAVrpotjg0lLOa =PA/u -END PGP SIGNATURE- ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Network TX/RX fairness is not honored by USB stack
On 10/3/10 4:54 PM, Pyun YongHyeon wrote: On Sat, Oct 02, 2010 at 08:41:57AM +0200, Hans Petter Selasky wrote: On Saturday 02 October 2010 02:11:00 Pyun YongHyeon wrote: Hi, I don't know how long it had been there but it seems current USB stack does not honor fairness of TX/RX on USB ethernet controller. Unidirectional performance test(UDP) or most-unidirectional performance(TCP) test works well without problems. However if heavy TX/RX traffic hits controller at the same time either TX or RX is not served at all. I'm under the impression that whenever TX work is done it seems USB reschedules next pending TX again instead of processing RX such that RX is starved to death. This can be easily reproduced on two hosts with the netperf performance test. Whenever both hosts send tiny UDP datagrams to the other host either TX or RX packet counters are not increasing until the end of the UDP torture test. The number of EHCI interrupt is about 8K/s while test is in progress so I think it reached its maximum processing limit. After netperf testing, it can still process TX/RX packets even though it dropped too many RX packets. But these dropped packets are not counted so netstat(1) shows 0 dropped frames even though it lost millions of packets. Hans, do you have any idea what's going on here? You can use the following netperf command on both hosts after running netserver. %netperf -c -H ip_addr_of_other_host -tUDP_STREAM -l 300 -- -m 1 Another odd thing I noticed is number of interrupts does not go down to 0 after the testing. It constantly generates 1k/s interrupts after that. Maybe we are triggering a bug. Can you enable USB debugging to figure out what data lengths are transmitted or received. In the middle of testing? If yes, that would be meaningless as it would generate bunch of messages. The test case generates payload size 1 UDP datagrams with full speed so enabling debug messages will change timing. Note, I'm exercising number of packets per second, not number of bytes per second. USB EHCI uses round robin, so this is either USB device problem or a test- program software failure. I'm pretty sure the benchmark program is not broken, so either axe(4) or USB stack could be wrong here. I see three issues from the UDP torture test. - Either TX or RX could be starved to death. If you start TX test first, RX would be stuck. If you start RX test first, TX would be stuck. - The number of packets sent or received are much lower than expected. For TX case, the number of packets sent per second is exactly 8k which is much less than that of non-USB controllers. For gigabit that is a big clue. the USB hardware uses an 8 thousand time per second clock for it's internal polling. controllers number of TX packets could be several hundred thousands per second. For RX packets it shows 14K/s packets with 8K/s interrupts. I thought USB ethernet controllers can send more than 8k packets per second. Because the number of interrupts per second and 8k packets per second is the same, this also make me wonder there could be some relations there. - Number of interrupts does not go back to 0 after the testing. I'll let you know if I find some clue but it may take long time as I'm not familiar with USB stack. :-( Check the CPU usage of the host computer during the test. Do you see anything? I didn't notice odd thing except 8k/s interrupts. The only way I stop that interrupts was to down the ue0 interface with "ifconfig ue0 down" command. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org" ___ 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: ...but this USB device is more than a printer!
On 10/3/10 3:34 AM, dan wrote: On 03.10.2010 10:19, Hans Petter Selasky wrote: On Sunday 03 October 2010 01:19:18 dan wrote: Hi all, I'll go straight to the point. Here's the output from "usbconfig dump_device_desc" #* ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0008 idVendor = 0x04e8 idProduct = 0x3413 bcdDevice = 0x0100 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0003<8J21BAKYB28091W.> bNumConfigurations = 0x0001 #* and here's the output from "usbconfig dump_curr_config_desc" #* ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0020 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x bmAttributes = 0x00c0 bMaxPower = 0x Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x0007 bInterfaceSubClass = 0x0001 bInterfaceProtocol = 0x0002 iInterface = 0x Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0003 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x bRefresh = 0x bSynchAddress = 0x #* Userland software, such as sane-find-scanner, is currently sure this is is just a printer. I would like this device to introduce itself for what it is ... a printer + a color scanner. Is it feasible? Are there any well-established techniques to (try to) reach the goal? Thanks for any link/suggestion Hi, Maybe you have to switch some button on the printer. Only one driver can use a set of IN and OUT endpoints at a time in an interface. Maybe the original driver has a multiplexer on top? --HPS Thanks Hans Petter, the device has no physical switch anywhere. Probably multiplexing is involved. It's worth to note then, if I understand it correctly, that this device does not follow this recommendation I read somewhere: "Important: Do not implement multiplexing over a single USB channel. Software multiplexing is fragile, and the native capabilities of USB should be used for communicating with multiple functions." Well they are not multiplexing on a single endpoint, and are using separate endpoints to do this but they are doing it at the wrong level in order to keep the entire device under the control of a single (their) driver rather than have to risk having a separate driver usurp part of it. d ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: ...but this USB device is more than a printer!
On 10/3/10 1:19 AM, Hans Petter Selasky wrote: On Sunday 03 October 2010 01:19:18 dan wrote: Hi all, I'll go straight to the point. Here's the output from "usbconfig dump_device_desc" #* ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0008 idVendor = 0x04e8 idProduct = 0x3413 bcdDevice = 0x0100 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0003<8J21BAKYB28091W.> bNumConfigurations = 0x0001 #* and here's the output from "usbconfig dump_curr_config_desc" #* ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0020 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x bmAttributes = 0x00c0 bMaxPower = 0x Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x0007 bInterfaceSubClass = 0x0001 bInterfaceProtocol = 0x0002 iInterface = 0x Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0003 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x bRefresh = 0x bSynchAddress = 0x #* Userland software, such as sane-find-scanner, is currently sure this is is just a printer. I would like this device to introduce itself for what it is ... a printer + a color scanner. Is it feasible? Are there any well-established techniques to (try to) reach the goal? Thanks for any link/suggestion Hi, Maybe you have to switch some button on the printer. Only one driver can use a set of IN and OUT endpoints at a time in an interface. Maybe the original driver has a multiplexer on top? I've seen quite a bit of this sort of thing. usually there are separate interface descriptors (can we handle that?) but I've also seen examples of this where there appear to be setups that would normally require a separate driver. maybe there should be a way to split out an endpoint and provide it with a virtual separate interface. (speaking in USB terms) --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: kernel debugger and usb keyboard
Hans Petter Selasky wrote: On Monday 03 August 2009 20:55:16 Alexander Best wrote: just tried settings `sysctl debug.kdb.panic = 1`. if i use this way to enter the kernel debugger my usb keyboard works. if i type "continue" however the kernel panics and the kernel debugger gets yet entered again, but without the keyboard working. The USB controller which the keyboard is hooked onto will not work after panic has been entered, due to some state not being cleaned up. To increase the chance of the keyboard working on a panic, connect the keyboard to a separate USB controller. i don't know how to produce backtraces since the keyboard doesn't work. Ok. the other way of entering the debugger without my keyboard working was to simple press "ctrl+ast+esc". try entering it from the sysctl debug.kdb.enter (set it to 1) Yes, because most likely the DDB is entered directly from the USB keyboard code, and the USB stack does not allow function recursion in that case! --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org" ___ 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: Panic in netgraph with VIMAGE
Marko Zec wrote: On Monday 25 May 2009 15:06:27 Milan Obuch wrote: Hi, there is some bug in (most probably) netgraph code. I did fresh csup and rebuild today. Whenever I try to turn bluetooth on (equivalent to plugging in the dongle), panic occurs: ubt0: on usbus3 panic: in /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:634 ng_make_node_common() vnet=0 curvnet=0 cpuid = 0 This does not occur with kernel from sources three days old. This is a known problem related to curvnet context not being set by the USB device attach code - I have to lurk / shop around for some cheap USB ethernet or bt devices to be able to reproduce & fix this locally, the alternative would be wild guessing and planting context setting macros at random places in the USB code, i.e. without testing, which I'm reluctant to do. it probably requires someone who knows the bluetooth and usb-ethernet code to decide how this is done. It seems to me that the bluetooth stuff should probably just always set itself to the base (default) vimage, as it has many kinds of devices that are not really 'interfaces' so to speak and probably deserve to be in the base virtual machine. It does have SOME interface type devices in theory but I don't know if they are supported. Maksim, in vimage, before yo call teh netgraph code, the mbuf should have an interface pointer and that in turn should have a pointer to the vimage.. Alternatively, the thread coming into netgraph should run code from vimage.h that sets the current image for that thread. can you suggest places that this may occur? Marko Part from core.txt file: #0 doadump () at pcpu.h:246 246<--->pcpu.h: No such file or directory. <-->in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc0554e0e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xc05550e2 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc0b947c1 in ng_make_node_common (type=0xc0b8f9a0, nodepp=0xc416b3a8) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:634 #4 0xc0b8bcc4 in ubt_attach (dev=0xc4294280) at /usr/src/sys/modules/netgraph/bluetooth/ubt/../../../../dev/usb/bluetooth/n g_ubt.c:443 #5 0xc057dcbf in device_attach (dev=0xc4294280) at device_if.h:178 #6 0xc057e88e in device_probe_and_attach (dev=0xc4294280) at /usr/src/sys/kern/subr_bus.c:2473 #7 0xc0b38240 in usb2_probe_and_attach_sub (udev=0xc41fd800, uaa=0xe4116c1c) at /usr/src/sys/modules/usb/usb/../../../dev/usb/usb_device.c:1131 #8 0xc0b3871a in usb2_probe_and_attach (udev=0xc41fd800, iface_index=255 'ÿ') at /usr/src/sys/modules/usb/usb/../../../dev/usb/usb_device.c:1288 #9 0xc0b40ff0 in uhub_explore (udev=0xc3f07000) at /usr/src/sys/modules/usb/usb/../../../dev/usb/usb_hub.c:218 #10 0xc0b31f29 in usb2_bus_explore (pm=0xc3ed0dd4) at /usr/src/sys/modules/usb/usb/../../../dev/usb/controller/usb_controller.c:2 15 #11 0xc0b4343a in usb2_process (arg=0xc3ed0d74) at /usr/src/sys/modules/usb/usb/../../../dev/usb/usb_process.c:139 #12 0xc0530008 in fork_exit (callout=0xc0b43360 ,. arg=0xc3ed0d74, frame=0xe4116d38) at /usr/src/sys/kern/kern_fork.c:830 #13 0xc070b550 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 At line 634 in ng_base.c, there is INIT_VNET_NETGRAPH(curvnet); I have options VIMAGE in my kernel config (actually this is first one succesfully compiled with mentioned option, but I did not try it too often, it just failed to compile before). Now I recompiled kernel again, this time without options VIMAGE in config, and panic does not occur. So the original problem is INIT_VNET_NETGRAPH implementation in presence of options VIMAGE in kernel config. If anyone has anything to test, please let me know. Regards, Milan ___ freebsd-virtualizat...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org" ___ freebsd-virtualizat...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: recently happend kernel panics regarding usb
Oliver Lehmann wrote: Markus Hitter wrote: If you throw the EHCI driver out of the kernel your drive will use either OHCI or UHCI (both are slow). This seems to help, at least for the limited things I use this pen drive now. I'm not sure, that this g_vfs_done is related to the panic. I've attached the drive to an uhci drived port on the same machine, started an fsck and I've got an immediate panic: trying to sleep while sleeping is prohibited when you hold a mutex in the kernel you are not allowed to go to sleep as other kernel actors may need that mutex.. OR a interrupt thread is trying to sleep. I doubt it has anything to do with a usb device hibernating. If I remember it correctly. The driver has some power saving feature which shuts the drive down if it is not used for some time and spins it up when a request arrives. But yesterday I powered the drive up... waited some secunds and started then a fsck. So I guess it was not in a "shutdown" state - So I wonder who requested a sleep ;) ___ 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: bin/129963: [newusb] usbconfig(8) fails with misleading error when run as a normal user
Hans Petter Selasky wrote:
On Tuesday 06 January 2009, M. Warner Losh wrote:
In message: <200901062024.31100.hsela...@c2i.net>
Hans Petter Selasky writes:
: On Tuesday 06 January 2009, M. Warner Losh wrote:
: > In message:
: > <7d6fde3d0901061110r79333a07jf4eb134224a94...@mail.gmail.com>
: >
: > "Garrett Cooper" writes:
: > : On Tue, Jan 6, 2009 at 10:32 AM, Hans Petter Selasky
: > :
:
: wrote:
: > : > On Saturday 03 January 2009, Volker wrote:
: > : >> On 01/03/09 01:35, Hans Petter Selasky wrote:
: > : >> > On Wednesday 31 December 2008, v...@freebsd.org wrote:
: > : >> >> Synopsis: [newusb] usbconfig(8) fails with misleading error
: > : >> >> when run as a normal user
: > : >> >>
: > : >> >> Responsible-Changed-From-To: freebsd-bugs->freebsd-usb
: > : >> >> Responsible-Changed-By: vwe
: > : >> >> Responsible-Changed-When: Wed Dec 31 12:55:52 UTC 2008
: > : >> >> Responsible-Changed-Why:
: > : >> >> reassign
: > : >> >>
: > : >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=129963
: > : >> >
: > : >> > Hi,
: > : >> >
: > : >> > "usbconfig" will only show USB devices which the user has access
: > : >> > to.
: > : >> >
: > : >> > What should be the correct display message when no devices are
: > : >> > accessible due to innsufficient permissions?
: > : >> >
: > : >> > --HPS
: > : >>
: > : >> Hans,
: > : >>
: > : >> what about "access denied" or "insufficient privileges"?
: > : >>
: > : >> Someone might have a better idea but everything should be better
: > : >> than silently refusing to do anything.
: > : >>
: > : >> Volker
: > : >
: > : > Is this Ok:
: > : >
: > : > http://perforce.freebsd.org/chv.cgi?CH=155731
: > : >
: > : > --HPS
: > :
: > : Eh? I still think that strerror or something along those lines would
: > : be more helpful.
: > :
: > : You could also do
: > :
: > : if (getuid() != 0) {
: > : errx(1, "Cluebat -- you might not be able to read the usb devices
: > : if you're not root");
: > : }
: > :
: > : or...
: > :
: > : struct stat usb_s;
: > :
: > : int fd = open(..., O_RDONLY /* blah, blah... */);
: > :
: > : if (fd == -1) {
: > : errx(1, "Does the file -- %s -- exist?", file);
: > : }
: > :
: > : if (fstat(fd, &usb_s) == -1) {
: > : errx(1, "Couldn't stat the file: %s", file);
: > : }
: > :
: > : if (!S_IRUSR(usb_s.st_mode) && !S_IRGRP(usb_s.st_mode) &&
: > : !S_IROTH(usb_s.st_mode)) {
: > : errx(1, "File not readable (do you have read permissions?)");
: > : }
: > :
: > : /* Continue on merry way reading devices; maybe use strerror(3) for
: > : more intuitive error messages? */
: > :
: > : Thoughts?
: >
: > Do you really have to be root to find the devices, if so, that's bad.
: > Very bad. xsane refuses to run as root. I have:
:
: No, no. That's wrong.
:
: Do it like this for example:
:
: usbconfig -u xxx -a xxx set_owner xxx set_perm 660
:
: This won't have no effect at all with USB2:
: > [localrules=10]
: > add path 'uscanner*' mode 0660
: >
: > to make it work. /dev/usb* in old usb allow listing w/o privs...
That's bad. I'm sorry, but having to do something weird to get the
scanner to work every time isn't good design.
I don't understand. If you are lazy you do:
usbconfig -u xxx set_perm 777
how about using the standard devd stuff?
why invent a completely new way of doing things for USB?
That will give everyone access to all USB devices on the given controller "-u
xxx". Note: No "-a" argument.
Or:
usbconfig set_owner warner:wheel set_perm 660
All USB devices ever plugged on your machine will be accessible by you.
I think Rink Springer is working on something in this area.
--HPS
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
___
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: HEADSUP: NDIS USB code has been committed
Weongyo Jeong wrote: Hello, Just for information. The code for supporting NDIS USB drivers has been committed into HEAD. Please tell me if you encounter problems. regards, Weongyo Jeong ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" using the original USB code, 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: "legacy" usb stack fixes
Scott Long wrote: On Fri, 12 Sep 2008, M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Scott Long <[EMAIL PROTECTED]> writes: : Scott Long wrote: : > This is close to How Things Should Be. Each umass target having its own : > SIM and bus is indeed wrong, but I'm not sure if it's correct for all : > USB controllers and buses to be under a single SIM. What would be the : > most correct is for each physical USB controller/bus instance to have : > its own SIM instance. I don't know if it's better to do the attachment : > in ehci/ohci/uhci controller drivers or in usb bus driver; up in the : > controller drivers is probably more correct. I don't like this hack of : > attaching stuff in a SYSINIT. : > : > Scott : > : > : : Now that I've thought some on it, I'll go one step further and say that : registering a single SIM for multiple controller+bus instances in a : SYSINIT will be highly undesirable thing to do. Since you have to : register a lock with the CAM when you register the SIM, you'll wind up : serializing all of the USB controllers under a single lock. Or you'll : probably try something dangerous and tricky with dropping the new global : lock and picking up an individual lock, then swizzling locks in the : completion and event paths, with the result being rather unsatisfying : and unpleasant. So I know that you'll do what you believe is correct, : but please take my advice on the matter anyways. Yes. A SIM will serialize all operations, and the most logical place for that is the computer <-> usb interface, which is the host controller. So having one SIM per host controller would be the optimal placement. Having one SIM per usb device doesn't result in any more real parallelism because the host controller necessarily serializes things because of how USB is defined... Correct. Another argument for having a SIM per controller/bus and not per target is that the SIM is responsible for managing all resources on a controller. USB is still a bus topology, and thus certain resources are finite and shared, be they bandwidth, arbitration, or concurrency. Granted, USB is simple enough that it doesn't give you much control over these resources, but having the SIM be at the target level gives the system even less control and visibility. If a future enhancement to USB grows the ability to do useful things like more concurrency, it'll be essential for the SIM to have a controller-wide view of this. cam/umass used to have a SIM per USB bus but it got changed sometime around 1999-2001 from memory. It was haled at the time as a great step forward when each device got its own SIM but I could never work out why. it did solve some problems though I forget what they where. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "legacy" usb stack fixes
Volker wrote: On 09/11/08 10:13, Hans Petter Selasky wrote: On Monday 25 August 2008, Volker wrote: Anyway, I've already had those crashes even with the "new" usb stack (but it doesn't happen everytime - YMMV). Hi, I also see crashes with my new stuff and the umass driver when the USB device is un-plugged too early. The backtraces I've got so far does not indicate a USB problem, though --HPS // dropped current@ from CC Hans Petter, the device unplug problem is not just with usb, but these devices are the most frequent unplugged devices so far. Early this week, I discovered a new problem. I've fetched fresh RELENG_7 sources, patched your usb stack in and recompiled kernel (using usb, not usb2). I've seen situations with a process holding open file descriptors for a ugen device being killed but a thread was still hanging in "usbdrain" state (sleeping on a mutex for draining). The process is still holding open file descriptors (I see output from ``fstat | grep ugen'' listing the already killed process), even while the process itself is already killed and not in the process list as a whole. Only a thread of that former process can be seen by ``ps -alxcH'', but it can't be killed. what is the thread waiting on? I'm pretty sure I'm able to patch kern_exit.c to have that process being freed completely but I'm also pretty sure, this will just kill a symptom but not the source. While in that situation, the usb port does not react to plug/unplug events anymore. I haven't been able to debug that situation as I do have too much stress at other places as well. Probably I'll find the time tomorrow for debugging. BTW, can you give a quick explanation about usb2? What's different, better? What needs to be done at the driver side to port something over to usb2? Thanks, Volker ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "legacy" usb stack fixes
Rink Springer wrote: On Thu, Sep 11, 2008 at 10:13:22AM +0200, Hans Petter Selasky wrote: I also see crashes with my new stuff and the umass driver when the USB device is un-plugged too early. The backtraces I've got so far does not indicate a USB problem, though That is correct, this is a bug in CAM. More specifically, CAM does not handle the removal of busses well. There are two possible options: 1) Obviously, fix CAM to handle this scenarion DragonflyBSD seems to have a lot of fixes in this area, which I intend to take a look at 'some day' (no thanks to $reallife...) 2) Create a CAM bus per USB bus I think this is reasonable, and it makes a lot more sense than the one-bus-per-device approach that we have now. The idea is that every USB controller hub creates a CAM bus, and umass(4) attaches to this bus instead of creating its own. Of course, until CAM is fixed, detaching PCMCIA or equivalent USB cards will still cause panics, but it would be a lot better than it is now... This is how it was originally. There was a reason that it was changed, so make sure you look into the history to figure out what the tradeoff was. Personally, I'd like to see option 2 implemented in the USB2 stack, as it avoids the issue and makes a lot more sense from user perspective (I'm probably onot the only one who gets scared by 'camcontrol devlist' if you have a single MP3 player which advertises 2 disks :-)) Regards, ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BlackBerry (Re: using libusb)
Mikhail T. wrote: понеділок 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. we did not decide to not go with it...we just never did it.. there have been serveral attempts to get a v4l2 in FreeBSD but they all stalled for ENOTIME. there is even one that basically worked but never got integrated. It's in perforce somewhere. 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]" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OpenUSB for FreeBSD?
Hans Petter Selasky wrote: Hi, On Thursday 15 November 2007, Xiaofan Chen wrote: On 11/12/07, Henrik Brix Andersen <[EMAIL PROTECTED]> wrote: Is it possible for some people here to implement a backend (based on ugen?) for FreeBSD? Interesting - definitely something I will take a look at. Thank you for the pointer. Or maybe at least improve the current libusb-0.1.x implemenation for FreeBSD. Yeah, I was looking at backporting some of the features from libusb CVS HEAD to libusb-0.1 on FreeBSD a while back and improving FreeBSD compatability as well for an application, I work on - but we ended up making FreeBSD specific work-arounds in the application instead. Could you be a bit more specific? I know there are some missing calls in FreeBSD. And I have problems with libusb interrupt write with the default kernel (hangs). It is documented here. http://lists.freebsd.org/pipermail/freebsd-usb/2007-November/004128.html But I am not so sure if it is a libusb problem or the kernel USB driver problem. The problem about clear stall on the interrupt endpoint is a pure device problem. Your USB device must re-queue any lost interrupt packets after clear stall! The HPS stack seems to be better in this aspect and I got some libusb application ported from Linux/Windows to FreeBSD thanks to the help from Hans. The current stable version of libusb certainly makes a lot to wish for on FreeBSD. I haven't got time yet to look at the latest version of libusb. I have some plans to make a replacement for /dev/ugen, that can interact on USB interfaces that already have drivers on them. Currently I'm very busy with other USB stuff. like, err documentation maybe? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How do I use my USB headset?
Hans Petter Selasky wrote: On Wednesday 10 October 2007, Andreas Davour wrote: Hi! I've bought a Logitech USB headset, and realized that since it's a USB device it shows up as new audio unit with it's own mixer and other devices. Now TeamSpeak and Skype, which are the programs I bought the headset for, don't seem to like the idea of sending the audio output anywhere except the first unit i.e. pcm0 which unfortunately is my built in laptop audio device. Anyone know if I can somehow route all output/input to pcm1 or somehow get the headset to work with Skype? I can use some programs, like 'mplayer' which take a lot of options like to what device it shall render audio/video. But since not all programs are that forgiving I had hoped there would be some kind of system wide way to direct the audio system to use my USB device instead. Any suggestions? I am using KDE if that's important (and I have checked the volume on all devices and it's not zero). /andreas Hi, If you are not using FreeBSD-7 current, something like the following might do the trick: rm /dev/dsp0 ln -s /dev/dsp1 /dev/dsp0 Although that means you will loose access to /dev/dsp0 . back when I used skype on BSD it was a linux binary, which means it was looking in /compat/linux/dev you need to have the correct symlinks in there.. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New USB stack - some updates
Hans Petter Selasky wrote: Hi, There hasn't been some many changes during the last month to my SVN repository nor P4 tree. Actually that is because my cable provider in Norway has been terribly slow providing me decent internet access. So there will be a big commit soon with lots of improvements. Anyways, there are several changes coming soon, some of which might interest you: 1) Optimisations for embedded platforms 1.a) Reduced stack usage 1.b) Faster USB control transfers 1.c) Loading of DMA buffers with automatic cache synch operations. 2) End of data bouncing in USB drivers. Using DMA buffers are now mandatory. 3) Some non-critical bug fixes. 4) Planned "USB device side" support. Currently only the "USB host side" is well supported. --HPS PS: I will be at EuroBSDcon in Denmark next week, available for comments. Being htere is a good start. having someone there who can question you on it woudl be good too. I don't know who is going. Having just flown back from Europe last nignt I'm not volunteering. Having some documentation they can read in order to knwo what to ask you about is more important. How is the documentation going? The code will not be accepted "EVER" without documentation, so that is BY FAR your highest priority if you want it to be accepted. You have not mentioned it at all though you have been told many times it is the single biggest drawback. (Along with locking issues that can be adddresses better when there is documentation) to recap: 1/ in-code commenting.. have some. in fact, have lots. 2/ some whitepaper giving an overview on how you approach problems and how your approach is different from that of the exisiting code. pictures are good. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB2 device won't attach to ehci
Peter Jeremy wrote: On 2007-Jul-23 00:01:47 +0200, Raaf <[EMAIL PROTECTED]> wrote: Looking at the specifications page of the Olympus FE-210 i see USB 2.0 compatible Yes. http://www.olympus.co.uk/consumer/29_FE-210_Specifications.htm That usually means that it's really a USB1.x device, but marketing department decided that selling it as a USB 2.0 compatible device would probably be better for sales :-) I've done some experimenting and it appears to be true in this case as well. I've checked on a different system running Winbloze and it agrees that it's USB1 :-(. Looking further, it seems that the 'USB2' claim only exists in some countries - presumably where that sort of claim doesn't raise the ire of the relevant consumer protection body. Thanks for that pointer. Sorry for disturbing this list. Do not confuse high-speed with USB2. A slow device can still be USB2 compliant as USB2 still defines the slower speeds. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Wireless USB
M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Hans Petter Selasky <[EMAIL PROTECTED]> writes: : I'm looking at adding support for Wireless USB to FreeBSD. : : Anyone which wants to say anything? Given all the wireless devices for USB, I'm not sure what you are talking about here. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]" support for "wireless USB" as opposed to "USB Wireless".. i.e. USB with no wires.. It's a new spec some are pushing.. al lthe things on your desktop chatting, without wires.. kinda what bluetooth was supposed to be. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
reminder
The ball is in your court with respect to code cleanup before review.. Just a reminder in case you are waiting for us to review. Warner is doing a lot of cleaning in the existing code I notice... ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 31st address line sometimes not used on EHCI/UHCI/OHCI
Hans Petter Selasky wrote: On Monday 28 May 2007 09:59, Julian Elischer wrote: I'd rather it were a screwed up MB than a screwed up chip :-) Ok. Here are the PCI ID's: [EMAIL PROTECTED]:11:0:class=0x0c0310 card=0x818a1043 chip=0x003b10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP04 USB Controller' class = serial bus subclass = USB [EMAIL PROTECTED]:11:1:class=0x0c0310 card=0x818a1043 chip=0x003b10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP04 USB Controller' class = serial bus subclass = USB [EMAIL PROTECTED]:11:2:class=0x0c0320 card=0x818a1043 chip=0x003c10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP04 USB Controller' class = serial bus subclass = USB [EMAIL PROTECTED]:7:0: class=0x0c0310 card=0x00351033 chip=0x00351033 rev=0x41 hdr=0x00 vendor = 'NEC Electronics Hong Kong' device = 'uPD9210FGC-7EA / PD720101 USB 1.0 Host Controller (OHCI compliant)' class = serial bus subclass = USB [EMAIL PROTECTED]:7:1: class=0x0c0310 card=0x00351033 chip=0x00351033 rev=0x41 hdr=0x00 vendor = 'NEC Electronics Hong Kong' device = 'uPD9210FGC-7EA / PD720101 USB 1.0 Host Controller (OHCI compliant)' class = serial bus subclass = USB [EMAIL PROTECTED]:7:2: class=0x0c0320 card=0x29280e55 chip=0x00e01033 rev=0x02 hdr=0x00 vendor = 'NEC Electronics Hong Kong' device = 'uPD720100A/101 USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB Can anyone find out if the USB hardware or the mainboard is not supporting 32 address lines from the text above? is the problem with the nvidia or the NEC? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ucom0: could not set data multiplex mode
Nikolay Pavlov wrote: On Wednesday, 6 June 2007 at 17:51:34 +0300, Alexander Motin wrote: Ok. The last one person i know how can throw the light upon this is Julian. If he doesn't know anything regarding this i will submit a PR for future investigations. I haven't been following.. can someone summarise? also: My ISP wouldn't let me send to the names in cyrilic.. please forward.. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ETA on HPS USB stack into CURRENT?
Anish Mistry wrote: What requirements still need to be met before the HPS USB stack is committed to CURRENT? I understand that introducing a major sub-system change so close the start of a release cycle can be very disruptive. My main concern is that the RELENG_7 branch will be arriving in the next couple months and imp@ mentioned in the (Re: UMASS pbm at startup) thread that RELENG_7 might not see the new stack. This means that we'll have to wait until an 8.x release (2009?) until we see the new stack in a stock install. Also the current stack will then need to be supported during the entire life of RELENG_7 which will probably into at least late 2010. From here on out the limitations of the current USB stack not being MPSAFE will only become more apparent with more systems shipping with multiple processors. Such as not allow CPUs to drop to C3 when USB is loaded, performance issues, and various HID parsing problems. With all that said what would be needed so that we could see the new stack in 7.1 eventhough 7.0 would have the old stack? Though this does seem to be asking for a lot of trouble since it would be a STABLE branch. This is a question we've been discussing a lot. Your public question probably deserves a public answer. There are some requirements that all subsystems require. HPS's USB code is no different from others. I will borrow from a talk at BSDCan that talked about project dynamics.. 1/ "Bus factor" of the project must not increase. i.e. "number of developers that may be hit by a bus before the project is really screwed". (bigger is better) Currently the "bus factor of the existing USB code is about 5 (busy) people Bus factor of new code is 1 2/ The nuclear powerplant problem. The direct opposite from a "bikeshed". Everyone understands a bikeshed and they can all comment on it. Very few people understand a nuclear powerplant so sometimes they can get installed with almost no review and comment. When they go wrong however they go wrong in a big way and influence a lot. They tend to decrease the "bus factor" of a project. (not good). What this means: A large module needs comprehensive review by other developers. The module needs to be split up into chunks that can be reviewed by humans. Ether by implementing it as a sequence of patches to get from "Here" to "there" in understandable steps, or by heavily documenting it. Preferably with lots of diagrams etc. (see the papers in the "docs" section for some of the examples of what people have done in the past) The code needs to reviewed, which means that it needs to be well laid out and commented. I beieve HPS is currently going through his code commenting it. It's curently "under commented". He has also been asked to provide some sort of design document to assist the reviewers. To some extent this means that HPS must be willing to let the control of his code slip from his hads somewhat. None of this of course means that it will get in if the reviewers don't like what they see, but if they do it comes in when all issues are addressed. Unless a really superior competitor exists, which seems doubtful at this time. The biggest competitor th HPS's USB code is "fix the old USB code". he needs to demonstrate that his co de is superior to this option. BTW after "first cut reviews" (done with great pain on the undocumented code), current issues of concern (also somewhat present in the existing code) include Locking issues and interaction with the newbus/device framework. When the commented and documented version of the code become available then it wil be reviewed more thoroughly and more issues will be raised undoubtedly. Currently the lack of documentation has hindered review. Implementation details: New code modules such as this should be installed with a transition period. In other words, for a short while both new and old code should exist side-by-side in some way. This allows people who need teh functionality and cannot spare the time to debug the new code, to keep working while others can work on the new code. This has happenned severaltimes in the past, with #ifdefs etc. being used to compile a kernle with new or old versions of various modules (e.g. pcmcia code vs pccard/newcard, or fastforward vs. regular forwarding) HPS is hoping to be able to present his code to developers attending EuroBSDcon in some way, and has agreed to assist us in reviewing it by adding comments and other documentation. (in some cases adding back commenting that already existed but he removed from his versions of the files). Until now all the work on HPS's code has been on the technical side, and none of it has been on the project integration side of things. This often tends to be overlooked but if Hans-Peter can get that side of his act together He has a chance that it could be accepted well. (assuming that reviewing results in a well integrated result.) Anyhow this is the basic thrust of a long di
Re: RE : UMASS pbm at startup
Alexandre DELAY wrote: But why does it work with an other motherboard and not with an other one? It is the same usb mass storage and the same system. Is it possible that it is due to IRQ interruptions? Maybe that the first motherboard doesn't have IRQ on USB port!? try a different USB port.. some motherboards do wierd things with some ports. Alex -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de M. Warner Losh Envoyé : lundi 28 mai 2007 20:02 À : [EMAIL PROTECTED] Cc : freebsd-usb@FreeBSD.ORG Objet : Re: UMASS pbm at startup In message: <[EMAIL PROTECTED]> Hans Petter Selasky <[EMAIL PROTECTED]> writes: : On Monday 28 May 2007 18:52, Aymeric MUNTZ (Cerbere3) wrote: : > Hi, : > : > I have a pbm with my usb disk-key under freebsd. : > When i start the system (FreeBSD 5.2) with the key already plugged, it is : > not recognised. If I unplug and replug it, it is recognised. : > With an other motherboard, I do not have this problem. : > : > Is there a way to rescan for usb devices? I already tried "camcontrol : > rescan all" with no success. : > : : Have you tried the SVN version of the new USB stack with FreeBSD 6.2 : installed? Let's just change one thing at a time... Try going to 6.2 first. changing both the usb stack and the freebsd version at one time might not be wise. We also need to track down problems in the current USB stack, since we are never going to put hps' stack into RELENG_6. Since it hasn't yet been committed to current and there's a freeze coming up shortly, it is doubtful that it will be in RELENG_7 either. We need to not view hps' stack as this magical thing that solves all problems because we have at least RELENG_6 to support for a while, and may have to support the current stack in RELENG_7 too. To be honest, I really wish Hans would be more pro-active in merging changes to the old stack so that the delta between it and his would be more manageable. I've said this plenty of times privately, but no fixes to the old stack have been forthcoming, not even new vendor IDs for existing drivers... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 31st address line sometimes not used on EHCI/UHCI/OHCI
John-Mark Gurney wrote: Hans Petter Selasky wrote this message on Mon, May 28, 2007 at 08:53 +0200: On Sunday 27 May 2007 23:53, John-Mark Gurney wrote: Hans Petter Selasky wrote this message on Sun, May 27, 2007 at 22:35 +0200: I've got some reports back that some USB host controllers do not support transferring memory from a location higher than 2GB. What should we do about this? Should we limit all USB DMA allocations to the lower 2GB of the memory? No, a quirk table should be setup and pass the restriction to bus_dma at tag initalization time when a broken controller is detected.. Yes, I can do that. But I am also thinking about a static quirk, like a sysctl you can set at boot time. The only issue w/ this is that it would also effect add in USB PCI cards that aren't effected by the bug... Which means a sysctl would limit the hardware to the lowest common denominator... I hope that this is not a wide-spread problem. And I am not surprised that hardware manufacturers are not specification compliant, which really makes me wonder if they support a true 64-bit address bus on the EHCI controller at all. I would maybe cost too much money? And therefore we should just stick with 32-bit addressing on 32-bit platforms aswell. Don't forget we have PAE for i386... so restricting to 32bit addressing for i386 would have an impact... As for it being an intermediate bus being the issue, I'd be surprised as that would mean that pci bridge to the USB controller is seriously broken... At least dealing w/ a intermediate bus is easier now that was have bus_get_dma_tag... I'd rather it were a screwed up MB than a screwed up chip :-) ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 31st address line sometimes not used on EHCI/UHCI/OHCI
Hans Petter Selasky wrote: On Sunday 27 May 2007 23:53, John-Mark Gurney wrote: Hans Petter Selasky wrote this message on Sun, May 27, 2007 at 22:35 +0200: I've got some reports back that some USB host controllers do not support transferring memory from a location higher than 2GB. What should we do about this? Should we limit all USB DMA allocations to the lower 2GB of the memory? No, a quirk table should be setup and pass the restriction to bus_dma at tag initalization time when a broken controller is detected.. Yes, I can do that. But I am also thinking about a static quirk, like a sysctl you can set at boot time. I hope that this is not a wide-spread problem. What manufacturers are we talking about here? and is there any possibility that it's not the USB chipset, but rather, some feature of an intermediary bus? And I am not surprised that hardware manufacturers are not specification compliant, which really makes me wonder if they support a true 64-bit address bus on the EHCI controller at all. I would maybe cost too much money? And therefore we should just stick with 32-bit addressing on 32-bit platforms aswell. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Call for Testers: FreeBSD webcam driver (and more)
Luigi Rizzo wrote: I think I reached a first interesting milestone in my project to build an emulation layer to compile linux device drivers on FreeBSD. I managed to build a FreeBSD port of the linux 'gspca' driver (which claims to support 228 different webcams) with basically no modifications to the original source. So it would be good if someone could give a try to this code, either on -current or -stable, keeping in mind that this is NOT PRODUCTION READY yet. More details on how the thing works are at http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html together of course with source code, and even binary modules for FreeBSD 6.2. Basically I would like to know how it builds/works on -current, have reports on cameras that work with it and those which don't and so on. The driver supports the Video4Linux API so it should be useful for a variety of applications. project "not_quite_as_evil" ? cheers luigi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB_ATTACH_SETUP macros question
John-Mark Gurney wrote:
Tofig Suleymanov wrote this message on Thu, Aug 17, 2006 at 17:10 +0500:
is there anybody to explain why do we have infinite loop inside of
USB_ATTACH_SETUP macros inside of usb_port.h ? How does his loop gets
escaped when we use it in some usb driver ?
#define USB_ATTACH_SETUP \
do { \
sc->sc_dev = self; \
device_set_desc_copy(self, devinfo); \
device_printf(self, "%s\n", devinfo); \
} while (0);
The real bug here is the extra ; after the while(0) part... because
if you use it as such:
if (case)
USB_ATTACH_SETUP;
else
somethingelse;
you will get a compile error due to the double semicolon...
yes style(9) specifies this form of macro should NOT have the semicolon.
In cases like this, it is also common to have parens after the macro
name so that it looks like a function, and not a simple expresion.
yes
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] FreeBSD USB redirector for qemu completed
Lonnie Mendez wrote: Hello list. This is heads up on the status of the backend. I have tested it with a mass storage device, a keypad, and a hid gps unit successfully on FreeBSD 6.1 beta 2. Please find the patch linked. http://gnome.dnsalias.net/patches/patch-bsdusb.patch AWEsome! (though why my mail reader classified it as Junk is another question.. just as well I occasionally look in my junk folder) -Lonnie ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New USB driver & API, now on NetBSD 3.0
Hans Petter Selasky wrote: Hi, I just want to let you know that my new USB driver is now compiling and working on NetBSD 3.0. The first goal of my driver is to get the USB drivers out of Giant/spl. Another goal is that NetBSD and FreeBSD should share some device drivers line by line, without any #ifdefs nor macros. That would help bring down the amount of maintainance, not having to port patches forth and back. And to avoid separate branches for drivers. Theoretically, any USB device driver that creates a device in /dev/, like ulpt, can now easily be ported from FreeBSD to NetBSD. if NetBSD has accepted Hans's rewritten drivers, then that takes away one of the few remaining obstacles for having them in FreeBSD, which is the fact that we were trying ot maintain compatibiolity with NetBSD. Currently ported to NetBSD + my new USB API: - New ugen USB device driver (http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb2/_ugen.c) - ISDN4BSD USB device drivers (http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/i4b/layer1/ihfc2/*usb*) Sources: http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb2/ There has been a major cleanup in "usb_port.h". The new USB driver supports _all_ transfer types on EHCI, OHCI, and UHCI. NOTE: the code compiles and loads on Sparc64, but it does not work properly yet. This is being worked on. Maybe someone wants to help? Host processors currently supported i386, amd64 and alike. FreeBSD kernel emulator for NetBSD == http://www.turbocat.net/~hselasky/isdn4bsd/sources/module/ How to download NetBSD version (You need subversion installed): === Follow the instructions in the README.TXT for how to install on NetBSD and FreeBSD. svn --username anonsvn --password anonsvn checkout svn://svn.turbocat.net/i4b Some documentation has been put here: = http://www.turbocat.net/~hselasky/usb4bsd --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: My USB controller driver
Anish Mistry wrote: On Friday 30 December 2005 04:35 pm, Hans Petter Selasky wrote: Hi, I just want to remind you of my USB controller driver for FreeBSD. I have now created a new homepage for it: http://www.turbocat.net/~hselasky/usb4bsd The sources are currently part of my ISDN4BSD driver, and can be downloaded by running the following command, if one has got Subversion installed: svn --username anonsvn --password anonsvn checkout svn://svn.turbocat.net/i4b This should make it very easy to make patches against my driver, if anyone has any suggestions for improvements. For those of you not familiar with svn, a patch can be produced by running the command "svn diff". It is also possible to browse the sources at the homepage without having to install SVN. Do you have any ETA or progress report on merging these changes into the tree? Hans's code is sufficiently different that it realy should be considerred a different driver. Using it would be breaking our connection to NetBSD/OpenBSD/Dragonfly. That may not be a bad thing as we'd get a maintainer who cares, but it's not a decision to take lightly. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
