and on the target disk. This is easily seen with e.g. gkrellm2.
--
Gary Jennejohn
___
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"
: 100MB/s
>
> Here are the detailed logs of dmesg/pciconf/usbconfig commands:
> http://athena.zia.io/~vermaden/dell.xps.12.logs.tar.gz
>
> For this operation I booted from the FreeBSD 12.2-RELEASE 'memstick' image on
> USB pendrive.
>
> Not sure how else I
per default.
The
code is in /usr/src/sys/kern/kern_priv.c.
> Tomasz: Feel free to suggest a patch for this after testing.
>
--
Gary Jennejohn
___
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"
he
> most common problem :-)
>
Lookig at the libusb code, libusb_reset_device() only returns an error if
resetting the device fails.
Resetting the device requires making ioctl() calls into the kernel.
ioctl() calls pretty much always require root permissions.
--
On Sun, 1 Dec 2019 13:14:16 +0300
Anatoly wrote:
> On Sun, 1 Dec 2019 08:28:01 +0100
> Gary Jennejohn wrote:
>
> > The geom code protects certain parts of the data area on the
> > drive, in particular GPT/MBR areas, unless ``sysctl
> > kern.geom.debugflags=16'&
y tricky design
> to fool users with exaggerated read/w/rite speeds.
>
The geom code protects certain parts of the data area on the
drive, in particular GPT/MBR areas, unless ``sysctl
kern.geom.debugflags=16'' is run beforehand. One can see this in
many places in the geom code.
On Sun, 28 Jul 2019 17:09:04 +0200
Gary Jennejohn wrote:
> On Sun, 28 Jul 2019 15:56:33 +0200
> Hans Petter Selasky wrote:
>
> > On 2019-07-27 13:51, Gary Jennejohn wrote:
> > > On Sat, 27 Jul 2019 13:05:01 +0200
> > > Hans Petter Selasky wrote:
> >
On Sun, 28 Jul 2019 15:56:33 +0200
Hans Petter Selasky wrote:
> On 2019-07-27 13:51, Gary Jennejohn wrote:
> > On Sat, 27 Jul 2019 13:05:01 +0200
> > Hans Petter Selasky wrote:
> >
> >> On 2019-07-26 11:56, Gary Jennejohn wrote:
> >>> On Fri, 26 Ju
On Sat, 27 Jul 2019 13:05:01 +0200
Hans Petter Selasky wrote:
> On 2019-07-26 11:56, Gary Jennejohn wrote:
> > On Fri, 26 Jul 2019 11:25:33 +0200
> > Gary Jennejohn wrote:
> >
> >> I'm having a very strange problem with external USB disks in
> >>
On Fri, 26 Jul 2019 11:25:33 +0200
Gary Jennejohn wrote:
> I'm having a very strange problem with external USB disks in
> HEAD. I see the problem with a kernel from July 12th and also
> with one from today.
>
[snip]
> Since I'm running a custom kernel I'll try
ffected makes things really weird.
Since I'm running a custom kernel I'll try running GENERIC to
see what happens and report back.
--
Gary Jennejohn
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
CPU pins may well
be the cause of your problems.
My Ryzen 5 does not exhibit any of the problems which you're seeing.
--
Gary Jennejohn
___
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"
PM Hans Petter Selasky
> > wrote:
> >
> >> On 9/17/18 12:25 PM, shreyank amartya wrote:
> >> > amd@amd-sham:~ % whoami
> >> > amd
> >> ^^ this is not root :-)
> >>
> >> >
> >> > amd@amd-sham:~ % usbdump
at is done
> > by the PCM feeder. You'll need to check that there is a> filter which
> > handle that.
> >
> > You might want to install virtual_oss from ports to handle this > device
> > properly.
>
> In the end I want 5.1 output, so if th
at one time, many years ago, have a commit bit. But I
doubt he does now.
--
Gary Jennejohn
___
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"
those supported.
Still, having the man page under FreeBSD would at least provide a hint
that the driver even exists.
I added device ugensa to my config file and the kernel was generated
without an error.
> root@localhost: [src] kldload ugensa
>
> ugen2.7: at usbus2
> ugensa0: on usb
ng itself as
containing mass storage.
Seems like the long-term solution would be to add a quirk (if at
all possible) to ignore the storage part.
Looking at usb_quirk(4) this might help: UQ_MSC_ALT_IFACE_1
but I'm not certain.
Anyway, take a look at the manpage, because it's possible to s
On Sat, 23 May 2015 14:25:23 +0200
Bernd Walter wrote:
> On Sat, May 23, 2015 at 09:36:21AM +0200, Gary Jennejohn wrote:
> > On Sat, 23 May 2015 01:42:57 +0200
> > Bernd Walter wrote:
[snip]
> > > [63]cicely1# usbconfig
> > > ugen1.1: at usbus1, cfg=0 md=H
0009
bDeviceSubClass = 0x
bDeviceProtocol = 0x0003
bMaxPacketSize0 = 0x0009
idVendor = 0x2109
idProduct = 0x0812
bcdDevice = 0x9091
iManufacturer = 0x0001
iProduct = 0x0002
iSerialNumber = 0x
bNumConfigurations = 0x0001
--
Gary Jennejohn
___
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"
reporter
has the same JMicron USB3 bridge chip in his box.
So, HPS, how about an option or quirk to force dma_bits to 32 for
us poor users stuck with this brain-damaged JMicron chip?
--
Gary Jennejohn
___
freebsd-usb@freebsd.org mailing list
http
st the DMA width. There have been so many changes to CAM
lately that the cause may lie there.
--
Gary Jennejohn
___
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"
3 docking stations
and USB3 hubs work just fine when attached to the USB3 card.
That's why I concluded that it's a problem with the JMicro
bridge chip.
I only have a graphics card and this USB3 card plugged into PCIe.
--
Gary Jennejohn
_
multi LUN enquiry using the SCSI-3 CDB byte 0xa0
also causes problems. Considering that most of these bridge
chips can barely emulate SCSI-2 it seems rather foolish to try to
jam SCSI-3 CDB bytes down their throats.
But that's a different story.
--
ttp://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=1114
> >>>
> >>> Is it possible, to use this modem under FreeBSD? And if yes, how?
> >>>
> >>
> >> Modeswitch is available under FreeBSD
them in a
docking station.
I also have two Toshiba v63700-C 1TB 2.5" sealed external drives
which just work with no fuss or muss.
The problem seems to be more with the electronics in the enclosures
than with the card itself.
--
Gary Jennejohn
___
freeb
from Toshiba (laptop drives in a
plastic enclosure) which work with both FreeBSD and Windows7.
Since they're USB3 there's no problem with powering them. Transfer
rates on the order of 90 MB/s.
Here's what's on the sticker:
www.toshibastorage.com
v63700-C 1TB
P/N: H
disk through the USB stack.
Here's the output:
camcontrol idle da0 -t 5
(pass4:umass-sim0:0:0:0): IDLE. ACB: e3 00 00 00 00 40 00 00 00 00 01 00
(pass4:umass-sim0:0:0:0): CAM status: Function Not Available
The disk doesn't spin down.
<\
I have a possibly dumb question. Is it possible to send a spindown
command through USB to a SATA disk attached as umass?
I like to spin down my disks before turning them off and with an ad-disk
it's quite simple using camcontrol.
I haven't been able figure how to do it through USB.
FTDI USB-to-serial adapters.
I do not use any USB modules.
---
Gary Jennejohn
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
return ret;
> > +#endif
> > +
> > if (ret == UMATCH_NONE)
> > return (ret);
>
Is there any reason to keep the #if 1 ... #endif? And why not just
directly return UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO rather than
assigning it to ret first?
30 matches
Mail list logo
