Re: usb 3.0 thumb drive speed limit

2017-01-02 Thread Marat N.Afanasyev 

Florian Ermisch wrote:



Am 2. Januar 2017 10:59:49 MEZ, schrieb "Marat N.Afanasyev" :

Ian Smith wrote:

On Mon, 2 Jan 2017 11:27:49 +0300, Marat N.Afanasyev wrote:
   > I wonder is there a speed limit on usb 3.0? I've bought
   >
   > ugen0.4:  at usbus0
   > umass2 on uhub7
   > umass2:  on

usbus0

   > da2 at umass-sim2 bus 2 scbus9 target 0 lun 0
   > da2:  Removable Direct Access SPC-4 SCSI

device

   > da2: Serial Number AA010808161609220143
   > da2: 40.000MB/s transfers
   > da2: 59840MB (122552320 512 byte sectors)
   > da2: quirks=0x2
   >
   > that claims 'Up to 245 MBytes/sec read speed'
   >
   > and dd shows:
   >
   > % dd if=/dev/da2 of=/dev/null bs=1m count=1000
   > 1000+0 records in
   > 1000+0 records out
   > 1048576000 bytes transferred in 25.688997 secs (40818098

bytes/sec)

   >
   > why we have such a limit?

Seems you've plugged it into a USB 2 port, not USB 3

At least you're getting full USB 2 performance (40MB/s)

Check if you have one or more USB 3 ports with 'dmesg | grep xhci'

cheers, Ian



afair, single usb 2.0 device can be as fast as 240 Mbits/sec, not 320
Mbits/sec:

% dd if=/dev/da2 of=/dev/null bs=1m count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 34.026227 secs (30816699 bytes/sec)

it's the same drive in usb 2.0 port

And I do have usb 3.0:

% grep xhci /var/run/dmesg.boot
xhci0:  mem 0xfeaf8000-0xfeaf
irq
17 at device 0.0 on pci5
xhci0: 64 bytes context size, 64-bit DMA
usbus0 on xhci0
xhci0:  mem 0xfeaf8000-0xfeaf
irq
17 at device 0.0 on pci5
xhci0: 64 bytes context size, 64-bit DMA
usbus0 on xhci0

and I tried this thumb drive is in usb 3.0 port first, of course.


Are you running 10.x or 11.0?

When was running 10.1 I only got
~27 MB/s out of each of my two
external HDDs connected to the
same USB3 port (two disk enclosure,
speed according to `zpool iostat -v`
AFAIR).
They also attached as high-speed
devices.
Some time after upgrading to the
than current 11-CURRENT I've
noticed kernel messages mentioning
400 MB/s instead of 40 MB/s and
quite an improvement in throughput.

May be a quirk in the driver for your
paricular XHCI chip.

Regards, Florian
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


11.0

I think that i have somehow buggy addon card :(

--
SY, Marat



smime.p7s
Description: S/MIME Cryptographic Signature

Re: usb 3.0 thumb drive speed limit

2017-01-02 Thread Florian Ermisch 


Am 2. Januar 2017 10:59:49 MEZ, schrieb "Marat N.Afanasyev" :
> Ian Smith wrote:
> > On Mon, 2 Jan 2017 11:27:49 +0300, Marat N.Afanasyev wrote:
> >   > I wonder is there a speed limit on usb 3.0? I've bought
> >   >
> >   > ugen0.4:  at usbus0
> >   > umass2 on uhub7
> >   > umass2:  on
> usbus0
> >   > da2 at umass-sim2 bus 2 scbus9 target 0 lun 0
> >   > da2:  Removable Direct Access SPC-4 SCSI
> device
> >   > da2: Serial Number AA010808161609220143
> >   > da2: 40.000MB/s transfers
> >   > da2: 59840MB (122552320 512 byte sectors)
> >   > da2: quirks=0x2
> >   >
> >   > that claims 'Up to 245 MBytes/sec read speed'
> >   >
> >   > and dd shows:
> >   >
> >   > % dd if=/dev/da2 of=/dev/null bs=1m count=1000
> >   > 1000+0 records in
> >   > 1000+0 records out
> >   > 1048576000 bytes transferred in 25.688997 secs (40818098
> bytes/sec)
> >   >
> >   > why we have such a limit?
> >
> > Seems you've plugged it into a USB 2 port, not USB 3
> >
> > At least you're getting full USB 2 performance (40MB/s)
> >
> > Check if you have one or more USB 3 ports with 'dmesg | grep xhci'
> >
> > cheers, Ian
> > 
> >
> afair, single usb 2.0 device can be as fast as 240 Mbits/sec, not 320 
> Mbits/sec:
> 
> % dd if=/dev/da2 of=/dev/null bs=1m count=1000
> 1000+0 records in
> 1000+0 records out
> 1048576000 bytes transferred in 34.026227 secs (30816699 bytes/sec)
> 
> it's the same drive in usb 2.0 port
> 
> And I do have usb 3.0:
> 
> % grep xhci /var/run/dmesg.boot
> xhci0:  mem 0xfeaf8000-0xfeaf
> irq 
> 17 at device 0.0 on pci5
> xhci0: 64 bytes context size, 64-bit DMA
> usbus0 on xhci0
> xhci0:  mem 0xfeaf8000-0xfeaf
> irq 
> 17 at device 0.0 on pci5
> xhci0: 64 bytes context size, 64-bit DMA
> usbus0 on xhci0
> 
> and I tried this thumb drive is in usb 3.0 port first, of course.

Are you running 10.x or 11.0?

When was running 10.1 I only got 
~27 MB/s out of each of my two 
external HDDs connected to the
same USB3 port (two disk enclosure,
speed according to `zpool iostat -v`
AFAIR).
They also attached as high-speed
devices.
Some time after upgrading to the 
than current 11-CURRENT I've
noticed kernel messages mentioning
400 MB/s instead of 40 MB/s and 
quite an improvement in throughput.

May be a quirk in the driver for your
paricular XHCI chip.

Regards, Florian 
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: usb 3.0 thumb drive speed limit

2017-01-02 Thread Marat N.Afanasyev 

Gary Palmer wrote:

On Mon, Jan 02, 2017 at 11:27:49AM +0300, Marat N.Afanasyev wrote:

I wonder is there a speed limit on usb 3.0? I've bought

ugen0.4:  at usbus0
umass2 on uhub7
umass2:  on usbus0
da2 at umass-sim2 bus 2 scbus9 target 0 lun 0
da2:  Removable Direct Access SPC-4 SCSI device
da2: Serial Number AA010808161609220143
da2: 40.000MB/s transfers
da2: 59840MB (122552320 512 byte sectors)
da2: quirks=0x2

that claims 'Up to 245 MBytes/sec read speed'


I don't think the speed reported by the SCSI layer (CAM) is correct
for USB, although it seems from an experiment here that if you
plug a USB3 drive into a USB2 port it reports "40.000MB/s transfers"
and on a USB3 port it reports "400.000MB/s transfers".  SCSI doesn't
really have any direct mapping to the USB speeds so I suspect the
USB stack uses the closest value.  The tests I did were with 10.3.
Other releases may behave differently.

Check with usbconfig what the negotiated USB speed is (the "spd=" value
with the Mbps or Gbps value in brackets afterwards)

FULL = USB1
HIGH = USB2
SUPER = USB3

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"



it seems that drive doesn't attach as usb 3.0 even when plugged into 
pci-e card port directly, to say nothing about the hub. probably it's 
buggy firmware of addon card, I'll try to find newer firmware and flash 
it, if one exists


--
SY, Marat



smime.p7s
Description: S/MIME Cryptographic Signature

Re: make kernel ctfmerge freeze on 11-STABLE

2017-01-02 Thread Aryeh Friedman 
Completely cleaning out /usr/src and /usr/obj fixed it (both current and
past revisions)

On Mon, Jan 2, 2017 at 8:33 AM, Aryeh Friedman 
wrote:

>
>
> On Mon, Jan 2, 2017 at 7:57 AM, Mateusz Guzik  wrote:
>
>> On Mon, Jan 02, 2017 at 07:48:22AM -0500, Aryeh Friedman wrote:
>> > On Mon, Jan 2, 2017 at 7:36 AM, Mateusz Guzik 
>> wrote:
>> >
>> > > On Mon, Jan 02, 2017 at 06:57:48AM -0500, Aryeh Friedman wrote:
>> > > > FreeBSD lilith 11.0-STABLE FreeBSD 11.0-STABLE #7 r311003: Sun Jan
>> 1
>> > > > 02:45:34 EST 2017 root@lilith:/usr/obj/usr/src/sys/GENERIC
>> amd64
>> > > >
>> > > >
>> > > > --
>> > > > >>> stage 3.1: building everything
>> > > > --
>> > > > cd /usr/obj/usr/src/sys/GENERIC; COMPILER_VERSION=30901
>> > > > COMPILER_TYPE=clang  COMPILER_FREEBSD_VERSION=1100503
>> > > > MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=amd64  MACHINE=amd64
>> CPUTYPE=
>> > > > GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
>> > > > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
>> > > > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc
>> > > -target
>> > > > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
>> > > > -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++  -target
>> > > > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
>> > > > -B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -target
>> > > > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
>> > > > -B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" NM=nm
>> > > > OBJDUMP=objdump OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=
>> SIZE="size"
>> > > > INSTALL="sh /usr/src/tools/install.sh"
>> > > > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/
>> > > src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/
>> > > usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/
>> > > sbin:/bin:/usr/sbin:/usr/bin
>> > > > make  -m /usr/src/share/mk  KERNEL=kernel all -DNO_MODULES_OBJ
>> > > > linking kernel.full
>> > > > ctfmerge -L VERSION -g -o kernel.full ...
>> > > > 
>> > >
>> > > How reproducible is the crash? What previous kernel was known to work?
>> > > Can you narrow it down to a particular revision, preferably with
>> kernel
>> > > debugging enabled? (see the end of the mail)
>> > >
>> >
>> > It first appeared a few days ago (forget what revision) then disappeared
>> > the day after and reappeared yesterday.   It is 100% reproducible (i.e.
>> > clearing out /usr/obj and doing a make kernel in either single or
>> multiuser
>> > mode both cause it).Turing on debugging would be hard but perhaps I
>> > should slightly qualify "freeze": make freezes but the rest of the
>> system
>> > is responsive and killing make leaves a zombie ctfmerge.  If I still
>> need
>> > kernel debugging based on the above I will do it but looking for an
>> easier
>> > explanation first.
>> >
>>
>> I definitely don't run into anything of the sort and the problem
>> statement is quote vague.
>>
>> However, if the problem is indeed reproducible, the minimum you can do
>> is find the first revision where it started appearing and that would
>> definitely help with an investigation.
>>
>>
> Any advice on how to do that since I update daily I can tell you when it
> started (the day) but not the actual revision ID.
>
>
>
> --
> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
>



-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: usb 3.0 thumb drive speed limit

2017-01-02 Thread Warner Losh 
On Mon, Jan 2, 2017 at 11:42 AM, Gary Palmer  wrote:
> On Mon, Jan 02, 2017 at 11:27:49AM +0300, Marat N.Afanasyev wrote:
>> I wonder is there a speed limit on usb 3.0? I've bought
>>
>> ugen0.4:  at usbus0
>> umass2 on uhub7
>> umass2:  on usbus0
>> da2 at umass-sim2 bus 2 scbus9 target 0 lun 0
>> da2:  Removable Direct Access SPC-4 SCSI device
>> da2: Serial Number AA010808161609220143
>> da2: 40.000MB/s transfers
>> da2: 59840MB (122552320 512 byte sectors)
>> da2: quirks=0x2
>>
>> that claims 'Up to 245 MBytes/sec read speed'
>
> I don't think the speed reported by the SCSI layer (CAM) is correct
> for USB, although it seems from an experiment here that if you
> plug a USB3 drive into a USB2 port it reports "40.000MB/s transfers"
> and on a USB3 port it reports "400.000MB/s transfers".  SCSI doesn't
> really have any direct mapping to the USB speeds so I suspect the
> USB stack uses the closest value.  The tests I did were with 10.3.
> Other releases may behave differently.
>
> Check with usbconfig what the negotiated USB speed is (the "spd=" value
> with the Mbps or Gbps value in brackets afterwards)
>
> FULL = USB1
> HIGH = USB2
> SUPER = USB3

40MB/s is just a number that's reported. It's not a speed limit.

Our USB stack reports that we understand SCSI protocol rev 2, but we
use the XPORT_USB for the transport. This means the code that prints
those numbers in scsi_xpt.c will use base_transfer_speed from the
XPT_PATH_INQ command. umass.c sets this to either 40MB/s or 400MB/s in
a decision that boils down to if that code thinks the transfer is over
USB 2.0 or 3.0. The fact that we're reporting 40MB/s rather than
400MB/s suggests to me that it was attached on a USB 2.0 hub rather
than a USB 3.0 hub, or it was attached with HIGH speed to a 3.0 hub
because the signals needed to do the SUPER speed were missing. On many
computers, only the "blue" USB ports are 3.0 speed, and only then when
wired correctly (as I discovered the hard way with a recent mobo I put
into service).

For reference, for USB connected umass devices, the driver returns
20kB/s for devices claiming to be floppies, 1MB/s for FULL speed
transfers, 40MB/s for HIGH speed and 400MB/s for SUPER speed.

Looking at the latest code, it sure looks like USB speeds are reported
correctly, or nearly correctly, up to the CAM layer as a good first
order estimate for how fast the drive can code. They do assume a 33%
overhead on USB (which is typical), so that's consistent with getting
just over 40MB/s from dd for a HIGH speed device.

Warner
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: usb 3.0 thumb drive speed limit

2017-01-02 Thread Gary Palmer 
On Mon, Jan 02, 2017 at 11:27:49AM +0300, Marat N.Afanasyev wrote:
> I wonder is there a speed limit on usb 3.0? I've bought
> 
> ugen0.4:  at usbus0
> umass2 on uhub7
> umass2:  on usbus0
> da2 at umass-sim2 bus 2 scbus9 target 0 lun 0
> da2:  Removable Direct Access SPC-4 SCSI device
> da2: Serial Number AA010808161609220143
> da2: 40.000MB/s transfers
> da2: 59840MB (122552320 512 byte sectors)
> da2: quirks=0x2
> 
> that claims 'Up to 245 MBytes/sec read speed'

I don't think the speed reported by the SCSI layer (CAM) is correct
for USB, although it seems from an experiment here that if you 
plug a USB3 drive into a USB2 port it reports "40.000MB/s transfers"
and on a USB3 port it reports "400.000MB/s transfers".  SCSI doesn't
really have any direct mapping to the USB speeds so I suspect the
USB stack uses the closest value.  The tests I did were with 10.3.
Other releases may behave differently.

Check with usbconfig what the negotiated USB speed is (the "spd=" value
with the Mbps or Gbps value in brackets afterwards)

FULL = USB1
HIGH = USB2
SUPER = USB3

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Exclusive New Year gifts in casino that’s turning heads!

2017-01-02 Thread GOLDEN CASINO 
Win New Year Jackpot now- http://tiny.cc/cxoyey

x tkbde y lhrj s sjos

rwp ngbep r hs a eqgde

ivpk slyfj h qrcl j csy

t oj ctj aqg iwcu fo

pq hhsaj qb jw i jsgul

aznu l yq mb latxs v

gd pes cgqo ex eacbj u

va aq kmjg r bxbup y

f gj rhlan nmlk vp ke

ygwfw am ze ywmxz za w

sw clth nwb k x usnu

fqs i yvyvu uq pfm fxgpl

u b ct jf gkqbw sp

xq nlfec cm zrah b kx

dwggv qxd kjn gkz ilcz faqu

rpmys s a pa uulup rwz

ocdrm ic rbvu louo b nbair

ljuxf i vqd wyyx ylilq dqolt

oz elfrx zw bvbir bqnbo fhcrg

oq fmc edvr dki xddt jj

o ptx l fwq zsle qjmq

f t kk ia gk is

tx ngm rxf uvab tifm pfa

nhyk cp xnoql vyw tb im

t h uoci uehk vgfae f

aaf umpui vxzp ig jld joltk

c cjjk ieyy u ws j

lkurp niko e j htcb vyvf

a ik vpopy c zujy fxkf

yopq cw fybp muwiy aluoi zmda

g gfkpl icz rekub bwzuq zxw

qsup mqtnh x akcpl z aa

lsii tt jproy cxr aarpt kx

okvge j pjgo doda afp yl

ig tzb nva xman afv q

vj sq tudgv wpg dfg uwyhd

xo vs kjic aqco s vn

mhj q zj myy ialj ffmm

ra gxuc gumc d mmdb pw

qe km vdcc xq iojax xob

qprz sc cizpd ymfw ni pmv

jtty wxwvw rkq qoen keh seew

klf gwoq wauz gcs y gjwo

iyud a fb svatk fnleu tauj

yvi mgs gl o ei kfuxe

pattq s gkokk qitsz r xazsz

xqqsd ur pg a hbnt w

rji gehtb chvm t vqhhm lzqac

s kq oozfm lqwa saq ys

zldk zb heg k zlqqr q

z le x w voqmz xgye

lgjbt y pj ok fkyfz uwfwh

cab lfue qwm g gbf dcz
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Compile error while building world

2017-01-02 Thread Jack Raats 
Problem SOLVED. I copied libpthread.a from a jail on that server to the right 
directory and could compile the source.
It seemed that the library was somehow damaged.

Grtz.,
Jack

Op 29-12-16 16:06 heeft Dimitry Andric  geschreven:

On 28 Dec 2016, at 23:47, Jack Raats  wrote:
> 
> At this moment I’ll get the following error while compiling buildworld
> 
> 
> 
> --- clang-tblgen.full ---
> 
> c++ -O2 -pipe -I/usr/obj/usr/src/tmp/usr/src/lib/clang/libllvm 
-I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -DLLVM_ON_UNIX 
-DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -g -Qunused-arguments 
-I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions -fno-rtti 
-stdlib=libc++ -Wno-c++11-extensions  -static 
-L/usr/obj/usr/src/tmp/legacy/usr/lib -o clang-tblgen.full  
ClangASTNodesEmitter.o ClangAttrEmitter.o ClangCommentCommandInfoEmitter.o 
ClangCommentHTMLNamedCharacterReferenceEmitter.o ClangCommentHTMLTagsEmitter.o 
ClangDiagnosticsEmitter.o ClangSACheckersEmitter.o NeonEmitter.o TableGen.o 
/usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal/libllvmminimal.a  
-lncursesw  -lpthread -legacy
> 
> /usr/lib/libpthread.a(thr_syscalls.o): In function `__thr_fdatasync':
> 
> /usr/src/lib/libthr/thread/thr_syscalls.c:(.text+0xe51): undefined 
reference to `__sys_fdatasync'
> 
> c++: error: linker command failed with exit code 1 (use -v to see 
invocation)
> 
> *** [clang-tblgen.full] Error code 1
> 
> 
> 
> Systeem: FreeBSD 11.0-STABLE  At revision 310725.

The fdatasync symbol was added to head in r304209, and that was MFC'd to
stable/11 in r304980, almost 4 months ago.  For some reason, you don't
seem to have it in libc.a.

Can you link any application statically?  And if you use -lpthread?

-Dimitry




___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: usb 3.0 thumb drive speed limit

2017-01-02 Thread Lowell Gilbert 
Ian Smith  writes:

> On Mon, 2 Jan 2017 12:59:49 +0300, Marat N.Afanasyev wrote:
>  > Ian Smith wrote:
>  > > 
>  > > Seems you've plugged it into a USB 2 port, not USB 3
>  > > 
>  > > At least you're getting full USB 2 performance (40MB/s)
>  > > 
>  > > Check if you have one or more USB 3 ports with 'dmesg | grep xhci'
>
>  > afair, single usb 2.0 device can be as fast as 240 Mbits/sec, not 320

280 Mbits/sec, actually.

>  > Mbits/sec:
>  > 
>  > % dd if=/dev/da2 of=/dev/null bs=1m count=1000
>  > 1000+0 records in
>  > 1000+0 records out
>  > 1048576000 bytes transferred in 34.026227 secs (30816699 bytes/sec)

30816699 bytes/sec is a little over 30 Megabytes per second. Which is
about right. Was someone misplacing a decimal? Or confusing bits with
bytes?

[Making things more confusing is that generally people refer to
megabytes as 10e6 for disks and 2e20 for memory. For flash, it's the
latter, but if you access it through a "disk" interface (like a thumb
drive), you'll generally get 10e6 type numbers.

>  > 
>  > it's the same drive in usb 2.0 port
>
> Ah, guess I've been taking "40.000MB/s transfers" for USB2 at its word.

The 40MB/s number includes overhead, so you'll never get quite that high.

> Testing 3 USB2 sticks in a USB2 port on my X200 (2.4GHz Core2Duo) I only 
> get about 18-20MB/s read for bs=1M count=1k, with little load although 
> 3k IRQ/s and 10k context switches/s, so I thought yours was good :)

These things will vary with your hardware; both the driver chips in the
computer and the flash stick itself. And some other things too, but I
can't recall exactly.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: make kernel ctfmerge freeze on 11-STABLE

2017-01-02 Thread Mateusz Guzik 
On Mon, Jan 02, 2017 at 08:33:29AM -0500, Aryeh Friedman wrote:
> On Mon, Jan 2, 2017 at 7:57 AM, Mateusz Guzik  wrote:
> 
> > On Mon, Jan 02, 2017 at 07:48:22AM -0500, Aryeh Friedman wrote:
> > > On Mon, Jan 2, 2017 at 7:36 AM, Mateusz Guzik  wrote:
> > >
> > > > On Mon, Jan 02, 2017 at 06:57:48AM -0500, Aryeh Friedman wrote:
> > > > > FreeBSD lilith 11.0-STABLE FreeBSD 11.0-STABLE #7 r311003: Sun Jan  1
> > > > > 02:45:34 EST 2017 root@lilith:/usr/obj/usr/src/sys/GENERIC
> > amd64
> > > > >
> > > > >
> > > > > --
> > > > > >>> stage 3.1: building everything
> > > > > --
> > > > > cd /usr/obj/usr/src/sys/GENERIC; COMPILER_VERSION=30901
> > > > > COMPILER_TYPE=clang  COMPILER_FREEBSD_VERSION=1100503
> > > > > MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=amd64  MACHINE=amd64
> > CPUTYPE=
> > > > > GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
> > > > > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
> > > > > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc
> > > > -target
> > > > > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
> > > > > -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++  -target
> > > > > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
> > > > > -B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -target
> > > > > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
> > > > > -B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" NM=nm
> > > > > OBJDUMP=objdump OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=
> > SIZE="size"
> > > > > INSTALL="sh /usr/src/tools/install.sh"
> > > > > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/
> > > > src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/
> > > > usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/
> > > > sbin:/bin:/usr/sbin:/usr/bin
> > > > > make  -m /usr/src/share/mk  KERNEL=kernel all -DNO_MODULES_OBJ
> > > > > linking kernel.full
> > > > > ctfmerge -L VERSION -g -o kernel.full ...
> > > > > 
> > > >
> > > > How reproducible is the crash? What previous kernel was known to work?
> > > > Can you narrow it down to a particular revision, preferably with kernel
> > > > debugging enabled? (see the end of the mail)
> > > >
> > >
> > > It first appeared a few days ago (forget what revision) then disappeared
> > > the day after and reappeared yesterday.   It is 100% reproducible (i.e.
> > > clearing out /usr/obj and doing a make kernel in either single or
> > multiuser
> > > mode both cause it).Turing on debugging would be hard but perhaps I
> > > should slightly qualify "freeze": make freezes but the rest of the system
> > > is responsive and killing make leaves a zombie ctfmerge.  If I still need
> > > kernel debugging based on the above I will do it but looking for an
> > easier
> > > explanation first.
> > >
> >
> > I definitely don't run into anything of the sort and the problem
> > statement is quote vague.
> >
> > However, if the problem is indeed reproducible, the minimum you can do
> > is find the first revision where it started appearing and that would
> > definitely help with an investigation.
> >
> >
> Any advice on how to do that since I update daily I can tell you when it
> started (the day) but not the actual revision ID.
> 

Just get the source, e.g.:
svn checkout https://svn.freebsd.org/base/stable/11 /usr/src

You can then switch to a particular revision you can svn up -r, e.g.:
svn update -r r310953

to switch to the revision prior to cache merge.

Preferably though you would use git as it allows easy bisection.
https://github.com/freebsd/freebsd, the branch is origin/stable/11.

-- 
Mateusz Guzik 
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: make kernel ctfmerge freeze on 11-STABLE

2017-01-02 Thread Aryeh Friedman 
On Mon, Jan 2, 2017 at 7:57 AM, Mateusz Guzik  wrote:

> On Mon, Jan 02, 2017 at 07:48:22AM -0500, Aryeh Friedman wrote:
> > On Mon, Jan 2, 2017 at 7:36 AM, Mateusz Guzik  wrote:
> >
> > > On Mon, Jan 02, 2017 at 06:57:48AM -0500, Aryeh Friedman wrote:
> > > > FreeBSD lilith 11.0-STABLE FreeBSD 11.0-STABLE #7 r311003: Sun Jan  1
> > > > 02:45:34 EST 2017 root@lilith:/usr/obj/usr/src/sys/GENERIC
> amd64
> > > >
> > > >
> > > > --
> > > > >>> stage 3.1: building everything
> > > > --
> > > > cd /usr/obj/usr/src/sys/GENERIC; COMPILER_VERSION=30901
> > > > COMPILER_TYPE=clang  COMPILER_FREEBSD_VERSION=1100503
> > > > MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=amd64  MACHINE=amd64
> CPUTYPE=
> > > > GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
> > > > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
> > > > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc
> > > -target
> > > > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
> > > > -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++  -target
> > > > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
> > > > -B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -target
> > > > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
> > > > -B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" NM=nm
> > > > OBJDUMP=objdump OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=
> SIZE="size"
> > > > INSTALL="sh /usr/src/tools/install.sh"
> > > > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/
> > > src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/
> > > usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/
> > > sbin:/bin:/usr/sbin:/usr/bin
> > > > make  -m /usr/src/share/mk  KERNEL=kernel all -DNO_MODULES_OBJ
> > > > linking kernel.full
> > > > ctfmerge -L VERSION -g -o kernel.full ...
> > > > 
> > >
> > > How reproducible is the crash? What previous kernel was known to work?
> > > Can you narrow it down to a particular revision, preferably with kernel
> > > debugging enabled? (see the end of the mail)
> > >
> >
> > It first appeared a few days ago (forget what revision) then disappeared
> > the day after and reappeared yesterday.   It is 100% reproducible (i.e.
> > clearing out /usr/obj and doing a make kernel in either single or
> multiuser
> > mode both cause it).Turing on debugging would be hard but perhaps I
> > should slightly qualify "freeze": make freezes but the rest of the system
> > is responsive and killing make leaves a zombie ctfmerge.  If I still need
> > kernel debugging based on the above I will do it but looking for an
> easier
> > explanation first.
> >
>
> I definitely don't run into anything of the sort and the problem
> statement is quote vague.
>
> However, if the problem is indeed reproducible, the minimum you can do
> is find the first revision where it started appearing and that would
> definitely help with an investigation.
>
>
Any advice on how to do that since I update daily I can tell you when it
started (the day) but not the actual revision ID.



-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: make kernel ctfmerge freeze on 11-STABLE

2017-01-02 Thread Mateusz Guzik 
On Mon, Jan 02, 2017 at 07:48:22AM -0500, Aryeh Friedman wrote:
> On Mon, Jan 2, 2017 at 7:36 AM, Mateusz Guzik  wrote:
> 
> > On Mon, Jan 02, 2017 at 06:57:48AM -0500, Aryeh Friedman wrote:
> > > FreeBSD lilith 11.0-STABLE FreeBSD 11.0-STABLE #7 r311003: Sun Jan  1
> > > 02:45:34 EST 2017 root@lilith:/usr/obj/usr/src/sys/GENERIC  amd64
> > >
> > >
> > > --
> > > >>> stage 3.1: building everything
> > > --
> > > cd /usr/obj/usr/src/sys/GENERIC; COMPILER_VERSION=30901
> > > COMPILER_TYPE=clang  COMPILER_FREEBSD_VERSION=1100503
> > > MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=
> > > GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
> > > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
> > > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc
> > -target
> > > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
> > > -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++  -target
> > > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
> > > -B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -target
> > > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
> > > -B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" NM=nm
> > > OBJDUMP=objdump OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"
> > > INSTALL="sh /usr/src/tools/install.sh"
> > > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/
> > src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/
> > usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/
> > sbin:/bin:/usr/sbin:/usr/bin
> > > make  -m /usr/src/share/mk  KERNEL=kernel all -DNO_MODULES_OBJ
> > > linking kernel.full
> > > ctfmerge -L VERSION -g -o kernel.full ...
> > > 
> >
> > How reproducible is the crash? What previous kernel was known to work?
> > Can you narrow it down to a particular revision, preferably with kernel
> > debugging enabled? (see the end of the mail)
> >
> 
> It first appeared a few days ago (forget what revision) then disappeared
> the day after and reappeared yesterday.   It is 100% reproducible (i.e.
> clearing out /usr/obj and doing a make kernel in either single or multiuser
> mode both cause it).Turing on debugging would be hard but perhaps I
> should slightly qualify "freeze": make freezes but the rest of the system
> is responsive and killing make leaves a zombie ctfmerge.  If I still need
> kernel debugging based on the above I will do it but looking for an easier
> explanation first.
> 

I definitely don't run into anything of the sort and the problem
statement is quote vague.

However, if the problem is indeed reproducible, the minimum you can do
is find the first revision where it started appearing and that would
definitely help with an investigation.

-- 
Mateusz Guzik 
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: make kernel ctfmerge freeze on 11-STABLE

2017-01-02 Thread Aryeh Friedman 
On Mon, Jan 2, 2017 at 7:36 AM, Mateusz Guzik  wrote:

> On Mon, Jan 02, 2017 at 06:57:48AM -0500, Aryeh Friedman wrote:
> > FreeBSD lilith 11.0-STABLE FreeBSD 11.0-STABLE #7 r311003: Sun Jan  1
> > 02:45:34 EST 2017 root@lilith:/usr/obj/usr/src/sys/GENERIC  amd64
> >
> >
> > --
> > >>> stage 3.1: building everything
> > --
> > cd /usr/obj/usr/src/sys/GENERIC; COMPILER_VERSION=30901
> > COMPILER_TYPE=clang  COMPILER_FREEBSD_VERSION=1100503
> > MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=
> > GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
> > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
> > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc
> -target
> > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
> > -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++  -target
> > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
> > -B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -target
> > x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
> > -B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" NM=nm
> > OBJDUMP=objdump OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"
> > INSTALL="sh /usr/src/tools/install.sh"
> > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/
> src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/
> usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/
> sbin:/bin:/usr/sbin:/usr/bin
> > make  -m /usr/src/share/mk  KERNEL=kernel all -DNO_MODULES_OBJ
> > linking kernel.full
> > ctfmerge -L VERSION -g -o kernel.full ...
> > 
>
> How reproducible is the crash? What previous kernel was known to work?
> Can you narrow it down to a particular revision, preferably with kernel
> debugging enabled? (see the end of the mail)
>

It first appeared a few days ago (forget what revision) then disappeared
the day after and reappeared yesterday.   It is 100% reproducible (i.e.
clearing out /usr/obj and doing a make kernel in either single or multiuser
mode both cause it).Turing on debugging would be hard but perhaps I
should slightly qualify "freeze": make freezes but the rest of the system
is responsive and killing make leaves a zombie ctfmerge.  If I still need
kernel debugging based on the above I will do it but looking for an easier
explanation first.


>
>


-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: make kernel ctfmerge freeze on 11-STABLE

2017-01-02 Thread David Wolfskill 
On Mon, Jan 02, 2017 at 01:36:31PM +0100, Mateusz Guzik wrote:
> On Mon, Jan 02, 2017 at 06:57:48AM -0500, Aryeh Friedman wrote:
> > FreeBSD lilith 11.0-STABLE FreeBSD 11.0-STABLE #7 r311003: Sun Jan  1
> > 02:45:34 EST 2017 root@lilith:/usr/obj/usr/src/sys/GENERIC  amd64
> > ... 
> > make  -m /usr/src/share/mk  KERNEL=kernel all -DNO_MODULES_OBJ
> > linking kernel.full
> > ctfmerge -L VERSION -g -o kernel.full ...
> > 
> 
> How reproducible is the crash? What previous kernel was known to work?
> Can you narrow it down to a particular revision, preferably with kernel
> debugging enabled? (see the end of the mail)

FWIW, I did not see anything approaching such a freeze, either on my
build machine or my laptop, during the just-comopleted upgrade from:

FreeBSD g1-252.catwhisker.org 11.0-STABLE FreeBSD 11.0-STABLE #209  
r311007M/311007:1100508: Sun Jan  1 03:51:25 PST 2017 
r...@g1-252.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  amd64


to:

FreeBSD g1-252.catwhisker.org 11.0-STABLE FreeBSD 11.0-STABLE #210  
r311047M/311097:1100508: Mon Jan  2 04:23:25 PST 2017 
r...@g1-252.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  amd64


(Or any prior upgrade, that I recall).

>  

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Epistemology for post-truthers: How do we select parts of reality to ignore?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: make kernel ctfmerge freeze on 11-STABLE

2017-01-02 Thread Mateusz Guzik 
On Mon, Jan 02, 2017 at 06:57:48AM -0500, Aryeh Friedman wrote:
> FreeBSD lilith 11.0-STABLE FreeBSD 11.0-STABLE #7 r311003: Sun Jan  1
> 02:45:34 EST 2017 root@lilith:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> 
> --
> >>> stage 3.1: building everything
> --
> cd /usr/obj/usr/src/sys/GENERIC; COMPILER_VERSION=30901
> COMPILER_TYPE=clang  COMPILER_FREEBSD_VERSION=1100503
> MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=
> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc -target
> x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++  -target
> x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -target
> x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" NM=nm
> OBJDUMP=objdump OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"
> INSTALL="sh /usr/src/tools/install.sh"
> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
> make  -m /usr/src/share/mk  KERNEL=kernel all -DNO_MODULES_OBJ
> linking kernel.full
> ctfmerge -L VERSION -g -o kernel.full ...
> 

How reproducible is the crash? What previous kernel was known to work?
Can you narrow it down to a particular revision, preferably with kernel
debugging enabled? (see the end of the mail)

There was one invasive change merged - fine-grained namecache in
r310959 and that can be treated as the likely culprit.

That said, I would start the search with verifying there are no issues
with r310953 first.

Debug opts:

options KDB # Enable kernel debugger support.
options KDB_TRACE   # Print a stack trace for a panic.
# For full debugger support use (turn off in stable branch):
options DDB # Support DDB.
options GDB # Support remote GDB.
options INVARIANTS  # Enable calls of extra sanity checking
options INVARIANT_SUPPORT   # Extra sanity checks of internal 
structures, required by INVARIANTS
options WITNESS # Enable checks to detect deadlocks and 
cycles
options WITNESS_SKIPSPIN# Don't run witness on spinlocks for 
speed
options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones
options DEBUG_VFS_LOCKS

-- 
Mateusz Guzik 
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

make kernel ctfmerge freeze on 11-STABLE

2017-01-02 Thread Aryeh Friedman 
FreeBSD lilith 11.0-STABLE FreeBSD 11.0-STABLE #7 r311003: Sun Jan  1
02:45:34 EST 2017 root@lilith:/usr/obj/usr/src/sys/GENERIC  amd64


--
>>> stage 3.1: building everything
--
cd /usr/obj/usr/src/sys/GENERIC; COMPILER_VERSION=30901
COMPILER_TYPE=clang  COMPILER_FREEBSD_VERSION=1100503
MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc -target
x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
-B/usr/obj/usr/src/tmp/usr/bin" CXX="c++  -target
x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
-B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -target
x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
-B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" NM=nm
OBJDUMP=objdump OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"
INSTALL="sh /usr/src/tools/install.sh"
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
make  -m /usr/src/share/mk  KERNEL=kernel all -DNO_MODULES_OBJ
linking kernel.full
ctfmerge -L VERSION -g -o kernel.full ...


-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: usb 3.0 thumb drive speed limit

2017-01-02 Thread Ian Smith 
On Mon, 2 Jan 2017 12:59:49 +0300, Marat N.Afanasyev wrote:
 > Ian Smith wrote:
 > > On Mon, 2 Jan 2017 11:27:49 +0300, Marat N.Afanasyev wrote:
 > >   > I wonder is there a speed limit on usb 3.0? I've bought
 > >   >
 > >   > ugen0.4:  at usbus0
 > >   > umass2 on uhub7
 > >   > umass2:  on usbus0
 > >   > da2 at umass-sim2 bus 2 scbus9 target 0 lun 0
 > >   > da2:  Removable Direct Access SPC-4 SCSI device
 > >   > da2: Serial Number AA010808161609220143
 > >   > da2: 40.000MB/s transfers
 > >   > da2: 59840MB (122552320 512 byte sectors)
 > >   > da2: quirks=0x2
 > >   >
 > >   > that claims 'Up to 245 MBytes/sec read speed'
 > >   >
 > >   > and dd shows:
 > >   >
 > >   > % dd if=/dev/da2 of=/dev/null bs=1m count=1000
 > >   > 1000+0 records in
 > >   > 1000+0 records out
 > >   > 1048576000 bytes transferred in 25.688997 secs (40818098 bytes/sec)
 > >   >
 > >   > why we have such a limit?
 > > 
 > > Seems you've plugged it into a USB 2 port, not USB 3
 > > 
 > > At least you're getting full USB 2 performance (40MB/s)
 > > 
 > > Check if you have one or more USB 3 ports with 'dmesg | grep xhci'

 > afair, single usb 2.0 device can be as fast as 240 Mbits/sec, not 320
 > Mbits/sec:
 > 
 > % dd if=/dev/da2 of=/dev/null bs=1m count=1000
 > 1000+0 records in
 > 1000+0 records out
 > 1048576000 bytes transferred in 34.026227 secs (30816699 bytes/sec)
 > 
 > it's the same drive in usb 2.0 port

Ah, guess I've been taking "40.000MB/s transfers" for USB2 at its word.

Testing 3 USB2 sticks in a USB2 port on my X200 (2.4GHz Core2Duo) I only 
get about 18-20MB/s read for bs=1M count=1k, with little load although 
3k IRQ/s and 10k context switches/s, so I thought yours was good :)

 > And I do have usb 3.0:
 > 
 > % grep xhci /var/run/dmesg.boot
 > xhci0:  mem 0xfeaf8000-0xfeaf irq 17
 > at device 0.0 on pci5
 > xhci0: 64 bytes context size, 64-bit DMA
 > usbus0 on xhci0
 > xhci0:  mem 0xfeaf8000-0xfeaf irq 17
 > at device 0.0 on pci5
 > xhci0: 64 bytes context size, 64-bit DMA
 > usbus0 on xhci0
 > 
 > and I tried this thumb drive is in usb 3.0 port first, of course.

Sorry for the static, I know nothing .. and running now unsupported 9.3

cheers, Ian
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: usb 3.0 thumb drive speed limit

2017-01-02 Thread Marat N.Afanasyev 

Ian Smith wrote:

On Mon, 2 Jan 2017 11:27:49 +0300, Marat N.Afanasyev wrote:
  > I wonder is there a speed limit on usb 3.0? I've bought
  >
  > ugen0.4:  at usbus0
  > umass2 on uhub7
  > umass2:  on usbus0
  > da2 at umass-sim2 bus 2 scbus9 target 0 lun 0
  > da2:  Removable Direct Access SPC-4 SCSI device
  > da2: Serial Number AA010808161609220143
  > da2: 40.000MB/s transfers
  > da2: 59840MB (122552320 512 byte sectors)
  > da2: quirks=0x2
  >
  > that claims 'Up to 245 MBytes/sec read speed'
  >
  > and dd shows:
  >
  > % dd if=/dev/da2 of=/dev/null bs=1m count=1000
  > 1000+0 records in
  > 1000+0 records out
  > 1048576000 bytes transferred in 25.688997 secs (40818098 bytes/sec)
  >
  > why we have such a limit?

Seems you've plugged it into a USB 2 port, not USB 3

At least you're getting full USB 2 performance (40MB/s)

Check if you have one or more USB 3 ports with 'dmesg | grep xhci'

cheers, Ian
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

afair, single usb 2.0 device can be as fast as 240 Mbits/sec, not 320 
Mbits/sec:


% dd if=/dev/da2 of=/dev/null bs=1m count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 34.026227 secs (30816699 bytes/sec)

it's the same drive in usb 2.0 port

And I do have usb 3.0:

% grep xhci /var/run/dmesg.boot
xhci0:  mem 0xfeaf8000-0xfeaf irq 
17 at device 0.0 on pci5

xhci0: 64 bytes context size, 64-bit DMA
usbus0 on xhci0
xhci0:  mem 0xfeaf8000-0xfeaf irq 
17 at device 0.0 on pci5

xhci0: 64 bytes context size, 64-bit DMA
usbus0 on xhci0

and I tried this thumb drive is in usb 3.0 port first, of course.

--
SY, Marat



smime.p7s
Description: S/MIME Cryptographic Signature

Re: usb 3.0 thumb drive speed limit

2017-01-02 Thread Ian Smith 
On Mon, 2 Jan 2017 11:27:49 +0300, Marat N.Afanasyev wrote:
 > I wonder is there a speed limit on usb 3.0? I've bought
 > 
 > ugen0.4:  at usbus0
 > umass2 on uhub7
 > umass2:  on usbus0
 > da2 at umass-sim2 bus 2 scbus9 target 0 lun 0
 > da2:  Removable Direct Access SPC-4 SCSI device
 > da2: Serial Number AA010808161609220143
 > da2: 40.000MB/s transfers
 > da2: 59840MB (122552320 512 byte sectors)
 > da2: quirks=0x2
 > 
 > that claims 'Up to 245 MBytes/sec read speed'
 > 
 > and dd shows:
 > 
 > % dd if=/dev/da2 of=/dev/null bs=1m count=1000
 > 1000+0 records in
 > 1000+0 records out
 > 1048576000 bytes transferred in 25.688997 secs (40818098 bytes/sec)
 > 
 > why we have such a limit?

Seems you've plugged it into a USB 2 port, not USB 3

At least you're getting full USB 2 performance (40MB/s)

Check if you have one or more USB 3 ports with 'dmesg | grep xhci'

cheers, Ian
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

usb 3.0 thumb drive speed limit

2017-01-02 Thread Marat N.Afanasyev 

I wonder is there a speed limit on usb 3.0? I've bought

ugen0.4:  at usbus0
umass2 on uhub7
umass2:  on usbus0
da2 at umass-sim2 bus 2 scbus9 target 0 lun 0
da2:  Removable Direct Access SPC-4 SCSI device
da2: Serial Number AA010808161609220143
da2: 40.000MB/s transfers
da2: 59840MB (122552320 512 byte sectors)
da2: quirks=0x2

that claims 'Up to 245 MBytes/sec read speed'

and dd shows:

% dd if=/dev/da2 of=/dev/null bs=1m count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 25.688997 secs (40818098 bytes/sec)

why we have such a limit?

--
SY, Marat



smime.p7s
Description: S/MIME Cryptographic Signature