[linux-usb-devel] Standard ctrl commands
Hi, I'm using v2.4.18 (Slackware 8.1) and usb-uhci. I'm wondering if the standard USB control commands are already handled by the USB core. Most Linux usb drivers only handle vendor-specific commands (some don't even have ioctl functions). I'd just like to verify this. Thanks. - Ronald --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Various oopsen in latest 2.6 BK
On Sun, 16 Nov 2003, Duncan Sands wrote: > Hi Alan, thanks for replying. > > > I'm not nearly as familiar with the details of devio.c as you are, so I > > can't answer the points you've raised. However, you have done a very good > > job of confirming my initial statement, that locking in usbfs is full of > > errors. (And I still think we should never be using the BKL -- if > > everything else was done properly there would no need for it.) > > A quick fix involving minimal changes requires the BKL. Minimal, yes. A somewhat larger but still relatively small change could involve substituting a private usbfs lock for the BKL. Is there any reason that wouldn't work? > I think that a proper > fix also requires a clear idea of the future of usbfs. After all, at the bottom > of it, many of the locking problems come from a mal-adapted API. One > thought I had was that the usbfs files (001 etc) could become directories. > The directory would contain a subdirectory for each interface (for the > current configuration), and each interface directory would contain an > endpoint file for each endpoint of the current altsetting. Sending an urb > to an endpoint would require opening that endpoint and writing to it (or > doing an ioctl). Configuration and altsetting changes would cause > directory contents to change. What happens if you have an open endpoint > when a change deletes that endpoint? Exactly the same thing that happens > with other file systems when you have an open file that someone else deletes: > you get to keep your copy until you close it, at which point it evaporates. The > whole interface claiming/releasing business could be eliminated by saying > (like for many device files) that endpoints can't be opened more than > once. That way, if you open an endpoint you get exclusive access to it. > To "claim an interface", you could just open each endpoint in it. If other > types of locking are required, maybe a more standard file locking method > could be used. Your ideas sound a lot like what other people have proposed. They will make a good project for 2.7. > Backwards compatibility could be maintained by allowing the traditional > ioctl's on the top-level directory (001 etc). That is an unfortunate necessity. It means that the current mess does need to be cleaned up, regardless of future development. > > So I won't tell you what to do; I'll just confirm what the rest of usbcore > > should expect. Basically, changes to the device configuration or state > > (connected vs. disconnected) may happen at any time but only under the > > protection of usbdev->serialize. In addition, creation/removal of > > interfaces (as would be caused by a configuration change) and > > binding/unbinding of drivers to interfaces require holding the driver > > model's usb subsystem rwsem. During probe and disconnect processing this > > is done automatically by the driver model core. > > Any objection to usbdev->serialize becoming a rwsem? I don't have any personal objections. Greg KH might think that's too big a change to go into 2.6.0. Why do you want to make it a rwsem? Under what conditions would multiple readers have the lock? > > Unfortunately these things are only incompletely implemented in usbcore, > > and practically not at all in usbfs. There's still a long way to go. > > Yes. In the meantime I will try to find a fix suitable for the current 2.6 freeze. Sounds good. Alan Stern --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB gamepad on linux
Hi, Thanks for all the feedback I got. Actually I have to load joydev with "modprobe joydev", then "cat /dev/js0" will show the activities on my game pad. Now I have another problem, how can I generate the module? I tried to use "make menuconfig" picking "Module" option for "joystick" under "input", no .o file was generated? Where should I found these .o files so that I may load them as modules later? Thanks, "Randy.Dunlap" <[EMAIL PROTECTED]> wrote: >On Fri, 14 Nov 2003 17:30:01 -0500 [EMAIL PROTECTED] wrote: > >| Hi All, >| >| I know it is a simple question, however it is difficult for me, since I don't know >the answer. >| >| How do I know the USB gamepad is detected under linux? Is there any test program I >may use to verify that the gamepad works well? > > >There used to be a couple of programs that show input device events. >It would be good if these were available in a well-known place. > >Googling (at www.google.com/linux/) for "+usb +dump-events" found this one: >http://www.frogmouth.net/hid-doco/examples/hiddev-misc/dump-events.c > >and for "+usb +evtest" found this one: >http://www.fuw.edu.pl/~pliszka/hints/linux-USB/labtec-evdev.c > >HTH. >-- >~Randy >MOTD: Always include version info. > > >--- >This SF. Net email is sponsored by: GoToMyPC >GoToMyPC is the fast, easy and secure way to access your computer from >any Web browser or wireless device. Click here to Try it Free! >https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl >___ >[EMAIL PROTECTED] >To unsubscribe, use the last form field at: >https://lists.sourceforge.net/lists/listinfo/linux-usb-devel > __ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455 --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB gamepad on linux
On Mon, 17 Nov 2003 10:20:21 -0500 [EMAIL PROTECTED] wrote: | Hi, | | Thanks for all the feedback I got. Actually I have to load joydev with "modprobe joydev", then "cat /dev/js0" will show the activities on my game pad. | | Now I have another problem, how can I generate the module? I tried to use "make menuconfig" picking "Module" option for "joystick" under "input", no .o file was generated? Where should I found these .o files so that I may load them as modules later? What kernel version are you referring to? joydev.o should be created in linux/drivers/input/joydev.o in 2.4.x. In 2.6.0-test* it is linux/drivers/input/joydev.ko (note the different module name extension). 'make modules_install' copies modules to a known location so that 'modprobe modulename' can find them. Could you learn to use Enter/Return after approx. 70 chars per line, please? -- ~Randy MOTD: Always include version info. --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Get info about physical location of new device within driver
Hi list ! This is my first post on this list. My name is Thorsten Wiedemer, and I make my first steps in USB driver development for linux. We want to connect multiple USB devices to one host. These devices are identical but have to receive different data, depending on their topological location in the USB tree. This is why I want to register the device file names depending on this location. So, is it possible within the device driver to get the information where a new device ist located in the USB tree ? Can somebody give me information on this, or a hint where I can find further information ? Sorry if this was already asked on this list. I tried to browse the archieves, but it's not really easy to find info there. Thanks in advance ! Thorsten --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Mosquitos nunca mais!!!
Dê adeus aos mosquitos e pernilongos de uma vez por todas. Conheça o REPELETRON. Um aparelho desenvolvido com Tecnologia de última geração para produzir ondas ultra sônicas que espantam os mosquitos e pernilongos a um raio superior a 3 metros. Cada aparelho cobre um volume de 27 metros cúbicos. Comprovado cientificamente! Não deixe sua família ser infernizada pelos mosquitos, evite as doenças que estes hospedeiros podem difundir. Adquira o seu REPELETRON pelo site: www.repeletron.kit.net Entregamos em todo o Brasil. Abraços - Equipe REPELETRON.
Re: [linux-usb-devel] Get info about physical location of new device within driver
Am Montag, 17. November 2003 17:08 schrieb Thorsten Wiedemer: > Hi list ! > > This is my first post on this list. > My name is Thorsten Wiedemer, and I make my first steps in USB driver > development for linux. > We want to connect multiple USB devices to one host. These devices are > identical but have to receive different data, depending on their topological > location in the USB tree. > This is why I want to register the device file names depending on this > location. > So, is it possible within the device driver to get the information where a > new device ist located in the USB tree ? > Can somebody give me information on this, or a hint where I can find further > information ? If this is an issue of naming only I would strongly advise you to do this as a hotplugging script, not within the kernel driver. If your devices really need to be driven depending on topology (which means that they are mightly odd) you could follow the parent pointer of struct usb_device (assuming your working on 2.4), but this is unclean and you should have a very, very good justification. HTH Oliver --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Where can I find the SCSI specs? (More Freecom)
Hi, I'm starting to become convinced that flaky as the transport driver may be it is as nothing to the devices it talks to :-( Anyway I'm still getting intermittent problems with talking to the Freecom USB sticks which I'd like to understand in better detail. At least one of the commands (MODE_SENSE) seems to fail whenever the device is plugged in: usb-storage: Command MODE_SENSE (6 bytes) usb-storage: 1a 00 3f 00 ff 00 00 00 00 00 00 00 usb-storage: Bulk command S 0x43425355 T 0x6 Trg 0 LUN 0 L 255 F 128 CL 6 hci_submit_urb: 122765->122766 usb-storage: Bulk command transfer result=0 usb-storage: usb_stor_transfer_partial(): xfer 255 bytes hci_submit_urb: 122767->122768 error on received packet: cc=9,urb->status = -121 urb :89fce2c0 next : dev :8826dc00 pipe :C0008280 (type 3) status:-121 transfer_flags:0008 transfer_buffer :895ed000 transfer_buffer_length:255 actual_length :12 setup_packet : start_frame :10223 number_of_packets :0 interval :0 error_count :0 context :8826db74 complete :c0132bc0 usb-storage: usb_stor_bulk_msg() returned -121 xferred 12/255 usb-storage: usb_stor_transfer_partial(): unknown error usb-storage: Bulk data transfer result 0x2 The cc code from my transport indicates an DataUnderrun, however I suspect it could be the device just give short replies. However if I return a bad status I assume it just gets ignored by the higher level? As all these commands are as I understand it meant to be SCSI commands encapsulated over USB I thought I'd have a closer look at the contents: contents:0xb 0x0 0x0 0x8 0x0 0x1 0xfff4 0x0 0x0 0x0 0x2 0x0 However I cannot find where the MODE_SENSE command is documented (although granted I've not read every document on the T10 site). Can anyone point me in the right direction? -- Alex, homepage: http://www.bennee.com/~alex/ 'In the Fyres of Struggle let us bake New Men, who Will Notte heed the old Lies.' (Feet of Clay) --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Can't write to Freecom USB Stick (0x0c76, 0x0005)
On Fri, 2003-11-14 at 17:40, David Brownell wrote: > > I'm thinking its about time to clean up the isp116x driver and submit it > > to usb-devel/lkml. But that does require resolving some merge issues > > with the hc_sl1811 driver thats already there that also uses hc_simple. > > It'd be a lot better to do this in the context of the 2.6 version of > the "hcd" framework. (Then backport to the 2.4 version if needed.) > That framework is more capable, and is also used by the "mainstream" > ehci/ohci/uhci code ... so most of its bugs have already been shaken > out, at least on 2.6 kernels. Mmm, fills me with confidence :-) Well I certainly won't do anything about it now as its a bit late to upgrade to a new kernel. However I'll certainly look into it once we've released version 1 of our product. I'll just muddle through with 2.4 for the time being. > Using it for the isp116x may shake out a few pci or dma issues, but > the resulting driver would of necessity behave a LOT more like the > other HCDs do. (Assuming you use the "usbtest" framework to put > that isp116x hcd through its paces!) No, but I'll look into it. Thanks. > > --- > This SF. Net email is sponsored by: GoToMyPC > GoToMyPC is the fast, easy and secure way to access your computer from > any Web browser or wireless device. Click here to Try it Free! > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl > ___ > [EMAIL PROTECTED] > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Alex, homepage: http://www.bennee.com/~alex/ "BTW, does Jesus know you flame?" -- Diane Holt, [EMAIL PROTECTED], to Ed Carp --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB gamepad on linux
Hi, I am using RH8.0, the kernel should 2.4. If I used "BuildIn" option, the joydev.o will be generated under linux/drivers/input. If I used "Module" option, there is no joydev.o generated. I just wonder the compiler may put it somewhere else. In addition, I generated the joydev.o using "BuildIn" option. However it doesn't work when I copied it to /lib/modules. Is there any command for Linux to recognize the new module I build? Thanks, Mike "Randy.Dunlap" <[EMAIL PROTECTED]> wrote: >On Mon, 17 Nov 2003 10:20:21 -0500 [EMAIL PROTECTED] wrote: > >| Hi, >| >| Thanks for all the feedback I got. Actually I have to load joydev with "modprobe >joydev", then "cat /dev/js0" will show the activities on my game pad. >| >| Now I have another problem, how can I generate the module? I tried to use "make >menuconfig" picking "Module" option for "joystick" under "input", no .o file was >generated? Where should I found these .o files so that I may load them as modules >later? > >What kernel version are you referring to? > >joydev.o should be created in linux/drivers/input/joydev.o in 2.4.x. >In 2.6.0-test* it is linux/drivers/input/joydev.ko (note the different >module name extension). 'make modules_install' copies modules >to a known location so that 'modprobe modulename' can find them. > >Could you learn to use Enter/Return after approx. 70 chars per line, >please? > >-- >~Randy >MOTD: Always include version info. > > >--- >This SF. Net email is sponsored by: GoToMyPC >GoToMyPC is the fast, easy and secure way to access your computer from >any Web browser or wireless device. Click here to Try it Free! >https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl >___ >[EMAIL PROTECTED] >To unsubscribe, use the last form field at: >https://lists.sourceforge.net/lists/listinfo/linux-usb-devel > __ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455 --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Where can I find the SCSI specs? (More Freecom)
On Mon, 17 Nov 2003, Alex Bennee wrote: > Hi, > > I'm starting to become convinced that flaky as the transport driver may > be it is as nothing to the devices it talks to :-( > > Anyway I'm still getting intermittent problems with talking to the > Freecom USB sticks which I'd like to understand in better detail. At > least one of the commands (MODE_SENSE) seems to fail whenever the device > is plugged in: > > usb-storage: Command MODE_SENSE (6 bytes) > usb-storage: 1a 00 3f 00 ff 00 00 00 00 00 00 00 > usb-storage: Bulk command S 0x43425355 T 0x6 Trg 0 LUN 0 L 255 F 128 CL > 6 > hci_submit_urb: 122765->122766 > usb-storage: Bulk command transfer result=0 > usb-storage: usb_stor_transfer_partial(): xfer 255 bytes > hci_submit_urb: 122767->122768 > error on received packet: cc=9,urb->status = -121 > urb :89fce2c0 > next : > dev :8826dc00 > pipe :C0008280 (type 3) > status:-121 > transfer_flags:0008 > transfer_buffer :895ed000 > transfer_buffer_length:255 > actual_length :12 > setup_packet : > start_frame :10223 > number_of_packets :0 > interval :0 > error_count :0 > context :8826db74 > complete :c0132bc0 > usb-storage: usb_stor_bulk_msg() returned -121 xferred 12/255 > usb-storage: usb_stor_transfer_partial(): unknown error > usb-storage: Bulk data transfer result 0x2 > > The cc code from my transport indicates an DataUnderrun, however I > suspect it could be the device just give short replies. However if I > return a bad status I assume it just gets ignored by the higher level? Why would you assume that? Look at the logs; usb-storage reports an unknown error and (if you look farther down past the part you have included here) you'll see that it begins an error recovery procedure. The bad status definitely does _not_ get ignored. And by the way, a short reply should not be considered an error. It's normal to have short replies; there's nothing wrong with them. > As all these commands are as I understand it meant to be SCSI commands > encapsulated over USB I thought I'd have a closer look at the contents: > > contents:0xb 0x0 0x0 0x8 0x0 0x1 0xfff4 0x0 0x0 0x0 0x2 0x0 Is that supposed to be the contents of the command or of the reply? It looks like the reply. I assume the 0xfff4 is an really unsigned 0xf4 that was incorrectly printed as a signed value. It says that the mode data (not counting the 1-byte length field) is 11 bytes, the medium-type and device-specific parameter values are 0 (default medium type and not write-protected), there is a single 8-byte block descriptor, the descriptor has density code 0 and applies to 0x1f400 blocks each of which is 0x200 bytes long. > However I cannot find where the MODE_SENSE command is documented > (although granted I've not read every document on the T10 site). Can > anyone point me in the right direction? The SCSI standards documents are not, so far as I know, freely available. Here is a link to a very old draft copy of the SCSI-2 standard that includes the information you want: http://www.rahul.net/endl/cdaccess/t10/drafts/scsi2/scsi2.pdf For more up-to-date and domain-specific stuff, look at http://www.t10.org/ftp/t10/drafts/sbc/sbc-r08c.pdf and http://www.t10.org/ftp/t10/drafts/spc3/spc3r15.pdf There may be later revisions of these available by now. Alan Stern --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Kernel 2.6.0-test9, deadlock using usb-storage, eventually memory allocation bug
Zitat von Vedran Rodic <[EMAIL PROTECTED]>: > I think you may be hitting the same problem I did some time ago. > > Please see > http://www.mail-archive.com/linux-usb-devel%40lists.sourceforge.net/msg17080.html > That was very fast! Thanks a lot! You were absolutely right. My usb disk is working fine now. Maximilian -- Maximilian Mehnert http://members.lycos.co.uk/endofuniverse/gpg.html Fingerprint: 387F 5AA6 5856 2A49 C88C DA86 FBA8 5122 817B C60E --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Unaligned scatter-gather transfers and usb-storage
I'm writing about this because Matt Dharm ran across some problems a few months back and posted a message about it on the usb-storage development list, and my own delving into the details of scatter-gather operations have yielded some new information. Most of the scatter-gather buffers passed to usb-storage will always be page-aligned. That's true of everything coming through the block layer (hence from the sd driver) and everything using bounce buffers in st and sg. However, there are circumstances in which st and sg will perform direct I/O -- passing s-g lists that refer to buffers in userspace. For the st driver these circumstances are not unusual. All that's required is for direct I/O support to be enabled in the driver (which it is by default) and that the host adapter is not marked as having one of those old 24-bit ISA DMA masks. With sg it's a bit rarer because the user program has to explicitly request a direct I/O transfer. Anyway, the s-g buffer is located in userspace, and it can be wherever the user program puts it. It doesn't have to be aligned on any sort of boundary at all. I don't know whether this causes problems for regular host adapters, but it does for usb-storage. Usb-storage uses David Brownell's scatter-gather library for s-g data transfers. This library constructs a set of URBs (one for each entry in the s-g list) and submits the whole thing to the HCD at once, thus minimizing inter-packet overhead. Unfortunately, this means that when a buffer isn't aligned properly, the first URB in the series may have a transfer length that isn't a multiple of the maxpacket value. The URB will necessarily end with a short packet, and the device will interpret this as indicating a premature end of the entire data transfer. This doesn't sound like a particularly easy problem to solve. The simplest solution would be to copy unaligned data to a single large bounce buffer, thereby negating the advantages of direct I/O. Another possibility would be to have lots of little bounce buffers to take care of the "splices" -- the places where a maxpacket-sized transfer would have to span two adjacent s-g entries. That would involve less data movement but would require setting up twice as many URBs. For the moment this isn't a very urgent problem, but it's something we should think about solving in the future. If anyone has any better ideas about how to fix it, I'd be pleased to hear them. Alan Stern --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Unaligned scatter-gather transfers and usb-storage
> This doesn't sound like a particularly easy problem to solve. The > simplest solution would be to copy unaligned data to a single large bounce > buffer, thereby negating the advantages of direct I/O. Another > possibility would be to have lots of little bounce buffers to take care of > the "splices" -- the places where a maxpacket-sized transfer would have to > span two adjacent s-g entries. That would involve less data movement but > would require setting up twice as many URBs. Two remarks. 1. Somebody supplying pathological buffers for direct IO gets the performance he deserves 2. This isn't really the storage drivers problem. It should be solved at a higher layer So, if you need to do something in storage about it, choose the simple solution and use a large bounce buffer. > For the moment this isn't a very urgent problem, but it's something we > should think about solving in the future. If anyone has any better ideas > about how to fix it, I'd be pleased to hear them. Secondly, I fear the analysis is incomplete. On DMA incoherent machines, the size requirement is the transfer size or a cacheline, whichever is larger and alignment needs to be on cacheline boundaries. Regards Oliver --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Unaligned scatter-gather transfers and usb-storage
On Mon, 17 Nov 2003, Oliver Neukum wrote: > Two remarks. > 1. Somebody supplying pathological buffers for direct IO gets the > performance he deserves Very true. > 2. This isn't really the storage drivers problem. It should be solved > at a higher layer > So, if you need to do something in storage about it, choose the simple > solution and use a large bounce buffer. That's a good rationale. (Although the fix would go into the scatter-gather library which belongs to usbcore, not in usb-storage. After all, there may be other drivers at some future time that also want to do low-overhead s-g transfers.) > Secondly, I fear the analysis is incomplete. > On DMA incoherent machines, the size requirement is the transfer size > or a cacheline, whichever is larger and alignment needs to be on cacheline > boundaries. Although this becomes moot if we go for the single big bounce buffer, I disagree. If you're referring to the overall transfer size, in general that's much bigger than a cacheline. If you're referring to the small "splice" buffers of my previous message, they can all get merged into a single large buffer. Since the transfer is all in one direction (read or write) and the host doesn't touch the data while the transfer is in progress, the usual DMA-mapping interface should work out okay. It's true that the region to be mapped must be on a cacheline boundary, but the actual data buffer can be a subset of the mapped region. Alan Stern --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Unaligned scatter-gather transfers and usb-storage
Alan Stern wrote:
This doesn't sound like a particularly easy problem to solve.
However, it's simple to detect, and I suspect usb-storage should
probably add a test to make sure incoming scatterlists are ok.
Something like:
for (i = 0; i < (sg_len - 1); i++) {
if ((sg[i].length % ep_maxpacket) != 0) {
dev_err(... "no can do\n");
return -EINVAL;
}
}
That is, only the last transfer can be "short". If failing
is undesirable (vs non-success?) then the "EINVAL" case could
eventually morph into some bounce-buffer strategy.
- Dave
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Unaligned scatter-gather transfers and usb-storage
2. This isn't really the storage drivers problem. It should be solved at a higher layer So, if you need to do something in storage about it, choose the simple solution and use a large bounce buffer. That's a good rationale. (Although the fix would go into the scatter-gather library which belongs to usbcore, not in usb-storage. After all, there may be other drivers at some future time that also want to do low-overhead s-g transfers.) No, it should go _higher_ than that. The "no partial packets in the middle of an sglist" policy belongs to usb-storage.. - Dave --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Unaligned scatter-gather transfers andusb-storage
> > 2. This isn't really the storage drivers problem. It should be solved > > at a higher layer > > So, if you need to do something in storage about it, choose the simple > > solution and use a large bounce buffer. > > That's a good rationale. (Although the fix would go into the > scatter-gather library which belongs to usbcore, not in usb-storage. > After all, there may be other drivers at some future time that also want > to do low-overhead s-g transfers.) Exactly. These drivers may have other requirements for minum sizes or alignments. How do you build that knowledge into the helper functions? Ideally storage would specify its requirements to scsi core. Failing that I don't think we should build workarounds into usbcore. > > Secondly, I fear the analysis is incomplete. > > On DMA incoherent machines, the size requirement is the transfer size > > or a cacheline, whichever is larger and alignment needs to be on cacheline > > boundaries. > > Although this becomes moot if we go for the single big bounce buffer, I No. It is relevant for deciding whether a bounce buffer must be used or not. > disagree. If you're referring to the overall transfer size, in general > that's much bigger than a cacheline. If you're referring to the small > "splice" buffers of my previous message, they can all get merged into a > single large buffer. Since the transfer is all in one direction (read or > write) and the host doesn't touch the data while the transfer is in > progress, the usual DMA-mapping interface should work out okay. It's true > that the region to be mapped must be on a cacheline boundary, but the > actual data buffer can be a subset of the mapped region. You can have an sglist that is perfectly valid from a transfer size point of view, yet cannot be savely dmaed on an incoherent machine. The issue is read/writing to memory sharing a cacheline with a transfer buffer. For this very reason drivers had to switch to seperately allocated transfer buffers on several occasions. Regards Oliver --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Bug With Fedora Core 1 Speedbundle Build
Hi All,
I didn't know where to post this bug so I'm posting it here. Apologies
in advance if this is not the appropriate forum or if you're already
aware of this bug.
I encountered several problems building the speedbundle for Fedora Core
1. Firstly, several files were in the wrong place, in particular
sonet.h. I believe this is a fault in the source code and I quickly
googled a solution. Once I copied the header to the correct place in the
linux source code, a simple make worked. However, when I attempted to do
a 'make install' I encountered the following bug:
--
> sudo make install
cd kernel_module && make install
make[1]: Entering directory
`/home/ricardo/speedbundle-1.0/kernel_module'
install -d /lib/modules/2.4.22-1.2115.nptlsmp 2.4.22-1.2115.nptlBOOT
2.4.22-1.2115.nptlbigmem 2.4.22-1.2115.nptl/kernel/drivers/usb
install -c speedtch.o /lib/modules/2.4.22-1.2115.nptlsmp
2.4.22-1.2115.nptlBOOT 2.4.22-1.2115.nptlbigmem
2.4.22-1.2115.nptl/kernel/drivers/usb
install: `/lib/modules/2.4.22-1.2115.nptlsmp' is a directory
install: `2.4.22-1.2115.nptlBOOT' is a directory
install: `2.4.22-1.2115.nptlbigmem' is a directory
make[1]: *** [install] Error 1
make[1]: Leaving directory `/home/ricardo/speedbundle-1.0/kernel_module'
make: *** [install] Error 2
--
I finally managed to locate the problem in the kernel_mode Makefile
(this fault is also extant in the regular speedtouch 1.7 kernel driver).
The problem is the following line:
VERSION := $(shell awk -F\" '/REL/ {print $$2}' $(VERSIONFILE))
Which, in Fedora, spits out there version strings. This problem was
quickly resolved by hard-coding the kernel version in the Makefile, as
so:
VERSION := 2.4.22-1.2115.nptl
Your excellent speedtouch driver is now working very satisfactorily.
Thanks for all the good work.
Regards...
--
Ricardo Gladwell
"They that can give up essential liberty to obtain a
little temporary safety deserve neither liberty nor safety."
- Benjamin Franklin
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Bug With Fedora Core 1 Speedbundle Build
On Mon, Nov 17, 2003 at 11:36:52PM +, Ricardo Gladwell wrote: > From: Ricardo Gladwell <[EMAIL PROTECTED]> > Date: Mon, 17 Nov 2003 23:36:52 + > > sudo make install > cd kernel_module && make install > make[1]: Entering directory > `/home/ricardo/speedbundle-1.0/kernel_module' > install -d /lib/modules/2.4.22-1.2115.nptlsmp 2.4.22-1.2115.nptlBOOT > 2.4.22-1.2115.nptlbigmem 2.4.22-1.2115.nptl/kernel/drivers/usb > install -c speedtch.o /lib/modules/2.4.22-1.2115.nptlsmp grep in the script that determines current kernel returned several names. I think it's speedbundle's bug in the script. I would prefer them to take a kernel from a user specification, because a running kernel is not necesserily the one against which you want to build. It's up to them though. -- Pete --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [USB2] 2.6.0-test9-mm2 HiSpd Isoc 1024B submits: -EMSGSIZE
High speed isochronous URB submits fail w -EMSGSIZE when packet
size is 1024 bytes (which is permitted by the USB 2.0 EHCI Sted).
Max Packet Size is conveyed to the host controller via the iTD's
Buffer Pointer Page 1 field, @ offset +0x28[10:0].
drivers/usb/core/urb.c: usb_submit_urb incorrectly scales this
value w an AND mask of 0x03ff while determining the count of
packets. usb/host/ehci-sched.c repeats the error.
This fix corrects the AND mask allowing 1024B packets to flow.
[EMAIL PROTECTED] src]# less usb2-isoc-1024.patch
diff -Nru 2.6.0-t9-mm2.orig/drivers/usb/core/urb.c
2.6.0-t9-mm2/drivers/usb/core/urb.c
--- 2.6.0-t9-mm2.orig/drivers/usb/core/urb.c2003-10-25
14:43:54.0 -0400
+++ 2.6.0-t9-mm2/drivers/usb/core/urb.c 2003-11-17 13:25:32.0
-0500
@@ -268,7 +268,7 @@
/* "high bandwidth" mode, 1-3 packets/uframe? */
if (dev->speed == USB_SPEED_HIGH) {
int mult = 1 + ((max >> 11) & 0x03);
- max &= 0x03ff;
+ max &= 0x07ff;
max *= mult;
}
diff -Nru 2.6.0-t9-mm2.orig/drivers/usb/host/ehci-sched.c
2.6.0-t9-mm2/drivers/usb/host/ehci-sched.c
--- 2.6.0-t9-mm2.orig/drivers/usb/host/ehci-sched.c 2003-10-25
14:43:19.0 -0400
+++ 2.6.0-t9-mm2/drivers/usb/host/ehci-sched.c 2003-11-17
13:27:08.0 -0500
@@ -580,10 +580,10 @@
maxp = urb->dev->epmaxpacketout [epnum];
buf1 = 0;
}
- buf1 |= (maxp & 0x03ff);
+ buf1 |= (maxp & 0x07ff);
multi = 1;
multi += (maxp >> 11) & 0x03;
- maxp &= 0x03ff;
+ maxp &= 0x07ff;
maxp *= multi;
/* transfer can't fit in any uframe? */
-
-
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
[EMAIL PROTECTED]
http://www.sc-software.com
-
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Help: Compile and Load USB gamepad module
Hi, I am using RH8.0, the kernel should 2.4. I want to generate the module for my gamepad and then load it. I use "make menuconfig" to compile linux kernel.If I used "BuildIn" option,the joydev.o will be generated under linux/drivers/input. If I used "Module" option, there is no joydev.o generated. I just wonder the compiler may put it somewhere else. In addition, I generated the joydev.o using "BuildIn" option. However it doesn't work when I copied it to /lib/modules. Is there any command for Linux to recognize the new module I build? Thanks, __ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455 --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Unaligned scatter-gather transfers and usb-storage
On Mon, 17 Nov 2003, David Brownell wrote: > > That's a good rationale. (Although the fix would go into the > > scatter-gather library which belongs to usbcore, not in usb-storage. > > After all, there may be other drivers at some future time that also want > > to do low-overhead s-g transfers.) > > No, it should go _higher_ than that. The "no partial packets > in the middle of an sglist" policy belongs to usb-storage.. Does it really? It seems to me that anyone doing a bulk transfer using an s-g list would want to make it look like a single stream, i.e., no short packets in the middle. That's built into the USB standard: a short packet signals the end of a transfer. Alan Stern --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Unaligned scatter-gather transfers andusb-storage
On Tue, 18 Nov 2003, Oliver Neukum wrote: > > That's a good rationale. (Although the fix would go into the > > scatter-gather library which belongs to usbcore, not in usb-storage. > > After all, there may be other drivers at some future time that also want > > to do low-overhead s-g transfers.) > > Exactly. These drivers may have other requirements for minum sizes > or alignments. How do you build that knowledge into the helper functions? > Ideally storage would specify its requirements to scsi core. > Failing that I don't think we should build workarounds into usbcore. While other drivers in general might have other requirements, I can't imagine what other requirements a USB driver might have. But I agree that it would make sense to have the top-level SCSI drivers refuse to do direct I/O on user buffers that aren't page-aligned. > > Although this becomes moot if we go for the single big bounce buffer, I > > No. It is relevant for deciding whether a bounce buffer must be used or not. > > > disagree. If you're referring to the overall transfer size, in general > > that's much bigger than a cacheline. If you're referring to the small > > "splice" buffers of my previous message, they can all get merged into a > > single large buffer. Since the transfer is all in one direction (read or > > write) and the host doesn't touch the data while the transfer is in > > progress, the usual DMA-mapping interface should work out okay. It's true > > that the region to be mapped must be on a cacheline boundary, but the > > actual data buffer can be a subset of the mapped region. > > You can have an sglist that is perfectly valid from a transfer size point > of view, yet cannot be savely dmaed on an incoherent machine. > The issue is read/writing to memory sharing a cacheline with a transfer > buffer. For this very reason drivers had to switch to seperately > allocated transfer buffers on several occasions. All right -- this isn't critical to the main problem, but I still don't get your point. There's nothing special here about USB. If a transfer buffer is suitable for DMA to a SCSI device (assuming a cache-incoherent architecture) then it must also be suitable for a USB device. It should be up to the top-level SCSI sg and st drivers to insure that the buffers meet the cacheline requirements; there's no point in making every one of the low-level drivers do that. For that matter, even on an incoherent machine it usually won't matter. Since the buffers are in userspace, there _won't_ be any access to memory sharing a cacheline with the buffer unless either the user is doing asynchronous I/O or the memory is mapped in another process. Of course the SCSI drivers don't check for either of these. And if either is true then direct I/O isn't safe no matter how the buffers are aligned. But if the I/O is synchronous and the memory isn't mapped elsewhere, then there's no possibility of bad cache accesses during the I/O. So the lack of alignment won't make things any worse than they already are. Alan Stern --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Help: Compile and Load USB gamepad module
On Mon, 17 Nov 2003 22:10:00 -0500 [EMAIL PROTECTED] wrote: | Hi, | | I am using RH8.0, the kernel should 2.4. I want to generate the module | for my gamepad and then load it. RH 8.0 shipped with 2.4.18 plus some vendor modifications/patches. Maybe someone who is using RH 8.0 can test this and answer you better than I can. | I use "make menuconfig" to compile linux kernel.If I used "BuildIn" | option,the joydev.o will be generated under linux/drivers/input. If I | used "Module" option, there is no joydev.o generated. I just wonder | the compiler may put it somewhere else. No, the compiler wouldn't put it somewhere else. For linux-2.4.18 from kernel.org, with CONFIG_INPUT_JOYDEV=m, drivers/input/joydev.o is generated as expected: [EMAIL PROTECTED] linux-2418]$ ll -tr drivers/input/joydev* -rw-r--r--1 rddunlap rddunlap14353 Sep 30 2001 drivers/input/joydev.c -rw-r--r--1 rddunlap rddunlap 9508 Nov 17 20:23 drivers/input/joydev.o | In addition, I generated the joydev.o using "BuildIn" option. However | it doesn't work when I copied it to /lib/modules. Is there any command | for Linux to recognize the new module I build? After 'make modules' in the linux/ directory, use 'make modules_install' to copy the modules to /lib/modules/. -- ~Randy --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Help: Compile and Load USB gamepad module
On Mon, 17 Nov 2003 20:29:30 -0800 "Randy.Dunlap" <[EMAIL PROTECTED]> wrote: | On Mon, 17 Nov 2003 22:10:00 -0500 [EMAIL PROTECTED] wrote: | | | Hi, | | | | I am using RH8.0, the kernel should 2.4. I want to generate the module | | for my gamepad and then load it. | | RH 8.0 shipped with 2.4.18 plus some vendor modifications/patches. | Maybe someone who is using RH 8.0 can test this and answer you better | than I can. Perhaps you should post your .config file... -- ~Randy --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Unaligned scatter-gather transfers and usb-storage
The "no partial packets
in the middle of an sglist" policy belongs to usb-storage..
Does it really? It seems to me that anyone doing a bulk transfer using an
s-g list would want to make it look like a single stream, i.e., no short
packets in the middle. That's built into the USB standard: a short packet
signals the end of a transfer.
Clearly not "anyone". Some of my standard HCD regression tests would
break with those semantics ... those were running (reliably!) before
usb-storage switched.
I don't view a scatterlist as a single transfer; it's just a shorthand
for a bunch of transfers that all need to execute in a given order.
That's certainly its structure: N * { address, count } doesn't say
anything about such policies.
- Dave
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
