Re: VirtualBox Extensions Pack (for USB and Video)
On 19. 5. 2., Tomasz CEDRO wrote: > Hello world! > > Are there any plans to implement VirtualBox Extension Pack on FreeBSD? > That would allow USB 2.0 + 3.0 support and better screen acceleration > + integration, etc. USB support seems most desirable and important, > especially for hardware hacking which is quite limited at the moment > to USB 1.0. With great USB stack that FreeBSD already has it should be > possible to implement those Extensions for VirtualBox right? :-) Unfortunately, there is no way to port VirtualBox Extension Pack because it is NOT open sourced. In fact, it is governed by a different license. https://www.virtualbox.org/wiki/VirtualBox_PUEL Jung-uk Kim signature.asc Description: OpenPGP digital signature
VirtualBox Extensions Pack (for USB and Video)
Hello world! Are there any plans to implement VirtualBox Extension Pack on FreeBSD? That would allow USB 2.0 + 3.0 support and better screen acceleration + integration, etc. USB support seems most desirable and important, especially for hardware hacking which is quite limited at the moment to USB 1.0. With great USB stack that FreeBSD already has it should be possible to implement those Extensions for VirtualBox right? :-) Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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: USB transfers in device drivers
On 2019-05-02 13:38, O'Connor, Daniel wrote: On 2 May 2019, at 20:33, Hans Petter Selasky wrote: On 2019-05-02 12:44, O'Connor, Daniel wrote: On 2 May 2019, at 20:02, Hans Petter Selasky wrote: On 2019-05-02 11:18, O'Connor, Daniel wrote: OK, thanks. To be honest I would much prefer to work out why this particular hardware & software seem to drop the ball for such a long time - 50msec without the kernel getting to schedule something (on a basically idle system) is quite perplexing to me. Sounds like a lost IRQ issue. Did you try any of the EHCI quirks in hw.usb.ehci ? No not, yet - thanks for the pointer! The 50ms delay may also be due to a physical link data error and needed recovery through clear stall which is expensive. I see the same error on different hardware sets (both motherboard and USB device) so I don't think it's that. If you can check if a USB BULK transfer is pending during this delay, then it might also be a firmware issue. --HPS ___ 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: USB transfers in device drivers
> On 2 May 2019, at 20:33, Hans Petter Selasky wrote: > > On 2019-05-02 12:44, O'Connor, Daniel wrote: >>> On 2 May 2019, at 20:02, Hans Petter Selasky wrote: >>> >>> On 2019-05-02 11:18, O'Connor, Daniel wrote: OK, thanks. To be honest I would much prefer to work out why this particular hardware & software seem to drop the ball for such a long time - 50msec without the kernel getting to schedule something (on a basically idle system) is quite perplexing to me. >>> >>> Sounds like a lost IRQ issue. Did you try any of the EHCI quirks in >>> hw.usb.ehci ? >> No not, yet - thanks for the pointer! > > The 50ms delay may also be due to a physical link data error and needed > recovery through clear stall which is expensive. > I see the same error on different hardware sets (both motherboard and USB device) so I don't think it's that. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum ___ 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: USB transfers in device drivers
On 2019-05-02 12:44, O'Connor, Daniel wrote: On 2 May 2019, at 20:02, Hans Petter Selasky wrote: On 2019-05-02 11:18, O'Connor, Daniel wrote: OK, thanks. To be honest I would much prefer to work out why this particular hardware & software seem to drop the ball for such a long time - 50msec without the kernel getting to schedule something (on a basically idle system) is quite perplexing to me. Sounds like a lost IRQ issue. Did you try any of the EHCI quirks in hw.usb.ehci ? No not, yet - thanks for the pointer! The 50ms delay may also be due to a physical link data error and needed recovery through clear stall which is expensive. --HPS ___ 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: USB transfers in device drivers
> On 2 May 2019, at 20:02, Hans Petter Selasky wrote: > > On 2019-05-02 11:18, O'Connor, Daniel wrote: >> OK, thanks. >> To be honest I would much prefer to work out why this particular hardware & >> software seem to drop the ball for such a long time - 50msec without the >> kernel getting to schedule something (on a basically idle system) is quite >> perplexing to me. > > Sounds like a lost IRQ issue. Did you try any of the EHCI quirks in > hw.usb.ehci ? No not, yet - thanks for the pointer! -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum ___ 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: USB transfers in device drivers
On 2019-05-02 11:18, O'Connor, Daniel wrote: OK, thanks. To be honest I would much prefer to work out why this particular hardware & software seem to drop the ball for such a long time - 50msec without the kernel getting to schedule something (on a basically idle system) is quite perplexing to me. Sounds like a lost IRQ issue. Did you try any of the EHCI quirks in hw.usb.ehci ? --HPS ___ 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: USB transfers in device drivers
> On 2 May 2019, at 18:06, Hans Petter Selasky wrote: > On 2019-05-02 10:22, O'Connor, Daniel wrote: >>> On 2 May 2019, at 06:15, Hans Petter Selasky wrote: >>> On 2019-05-01 10:34, O'Connor, Daniel wrote: I don't have a solid hypothesis for the failures as yes but one thing I'd like to make sure is that the USB stack is keeping the USB hardware busy with pending requests - does anyone know if the USB FIFO code does that automatically? >>> >>> Only the XHCI driver supports HW based double buffering of BULK transfers. >> Ahh interesting - is that a ECHI hardware limitation or a driver one? > > It is an EHCI hardware "limitation". It is possible to queue up more jobs > with the EHCI, but it ends that you get a race with the hardware you'll need > to catch. I think it is related to how receiving short packets are handled. OK, thanks. To be honest I would much prefer to work out why this particular hardware & software seem to drop the ball for such a long time - 50msec without the kernel getting to schedule something (on a basically idle system) is quite perplexing to me. >>> I suppose you are using BULK. Else you will need to use ISOCHRONOUS >>> transfers. >> Yes it's using bulk transfers. >> I did consider isochronous transfers when I started this project but I >> wasn't sure if there would be enough bandwidth (but perhaps I read the spec >> wrong). I imagine there would be enough for this data rate but we have >> others at higher speeds (eg 35MB/sec). > > If you want reliable data transfer, BULK is the best. OK, yes, has to be reliable :) >> Related to bandwidth - are there any statistics gathered about how busy a >> port is? > > No, but I wanted to add a text-graph frontent to usbdump to collect this info > realtime. Else use a USB wire-analyzer. I wondered about this too, probably easier than instrumenting the EHCI driver I suppose. Sadly I don't have a USB analyser and even if I did the system in question is in another country :( -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum ___ 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: USB transfers in device drivers
On 2019-05-02 10:22, O'Connor, Daniel wrote: On 2 May 2019, at 06:15, Hans Petter Selasky wrote: On 2019-05-01 10:34, O'Connor, Daniel wrote: I don't have a solid hypothesis for the failures as yes but one thing I'd like to make sure is that the USB stack is keeping the USB hardware busy with pending requests - does anyone know if the USB FIFO code does that automatically? Only the XHCI driver supports HW based double buffering of BULK transfers. Ahh interesting - is that a ECHI hardware limitation or a driver one? Hi, It is an EHCI hardware "limitation". It is possible to queue up more jobs with the EHCI, but it ends that you get a race with the hardware you'll need to catch. I think it is related to how receiving short packets are handled. I suppose you are using BULK. Else you will need to use ISOCHRONOUS transfers. Yes it's using bulk transfers. I did consider isochronous transfers when I started this project but I wasn't sure if there would be enough bandwidth (but perhaps I read the spec wrong). I imagine there would be enough for this data rate but we have others at higher speeds (eg 35MB/sec). If you want reliable data transfer, BULK is the best. Related to bandwidth - are there any statistics gathered about how busy a port is? No, but I wanted to add a text-graph frontent to usbdump to collect this info realtime. Else use a USB wire-analyzer. --HPS ___ 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: USB transfers in device drivers
> On 2 May 2019, at 06:15, Hans Petter Selasky wrote: > On 2019-05-01 10:34, O'Connor, Daniel wrote: >> I don't have a solid hypothesis for the failures as yes but one thing I'd >> like to make sure is that the USB stack is keeping the USB hardware busy >> with pending requests - does anyone know if the USB FIFO code does that >> automatically? > > Only the XHCI driver supports HW based double buffering of BULK transfers. Ahh interesting - is that a ECHI hardware limitation or a driver one? > I suppose you are using BULK. Else you will need to use ISOCHRONOUS transfers. Yes it's using bulk transfers. I did consider isochronous transfers when I started this project but I wasn't sure if there would be enough bandwidth (but perhaps I read the spec wrong). I imagine there would be enough for this data rate but we have others at higher speeds (eg 35MB/sec). Related to bandwidth - are there any statistics gathered about how busy a port is? Thanks -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum ___ 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"
