Re: Heads up

2016-04-14 Thread Warner Losh 
On Thu, Apr 14, 2016 at 10:37 PM, Warren Block  wrote:

> On Thu, 14 Apr 2016, Warner Losh wrote:
>
>
>> On Thu, Apr 14, 2016 at 9:56 PM, Warren Block  wrote:
>>   On Thu, 14 Apr 2016, Warner Losh wrote:
>>
>> The CAM I/O scheduler has been committed to current. This
>> work is described
>> in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf
>> though the
>> default scheduler doesn't change the default (old) behavior.
>>
>> One possible issue, however, is that it also enables NCQ
>> Trims on ada SSDs.
>> There are a few rogue drives that claim support for this
>> feature, but
>> actually implement data corrupt instead of queued trims. The
>> list of known
>> rogues is believed to be complete, but some caution is in
>> order.
>>
>>
>>   Is the list of drives queryable?  Is there an easy way to tell if
>> the currently-connected drives are on the list?
>>
>>
>> /usr/src/sys/cam/ata/ata_da.c has the list.
>>
>> dmesg will tell you if it detected a bad one since it prints the drive's
>> quirks.
>> But that's no big deal, because the bad one work just fine if you never
>> issue
>> a NCQ TRIM. This small group of drives were early adapters of this
>> technology
>>
>> Here's the full list of known rogues:
>>
>> Crucial/Micron M500 (all firmware prior to MU07)
>> Micron M510 MU01 firmware (newer firmware is good)
>> Crucial/Micron M550 MU01 firmware (newer firmware is good)
>> Crucial MX100 MU01 firmware (newer firmware is good)
>> FCCT M500 all firmware
>> Samsung 830 all firmware
>> Samsung 840 all firmware
>> Samsung 850 all firmware
>>
>> All of these are at least 18 months old (if not older). There's some
>> confusing in Linux lists on
>> the full impact of the Samsung drives (there was a bug in the Linux
>> implementation (that can't
>> be present in the FreeBSD implementation) that may have been the root
>> cause for the Samsung
>> black listing). Out of an abundance of caution, I've kept them in the
>> list. Also, it's my belief that
>> the Crucial/Micron models with MU01 firmware were mostly corrected after
>> early samples
>> since most of the channel drives I've helped people debug had MU02
>> firmware. Also, a quick
>> google search shows the MU02 firmware for each of these models has been
>> available for
>> at least a year.
>>
>
> After updating a Dell E7240, booting showed a bunch of FPDMA errors and
> then panicked after about 30 seconds.
>
> The SSD is a Samsung PM851 mSATA drive with firmware EXT4AD0Q.  I believe
> this is the OEM version of the Samsung 840 Evo.  According to the Dell
> support page, the machine shipped on January 22, 2015.  So while the drive
> might not have been manufactured in a while, Dell was still using them that
> recently.  Note that this is a used machine, I have only had it a week.
>
> After booting with mfsBSD, a quick fsck, and setting
> kern.cam.ada.0.quirks=0x2 in /boot/loader.conf, it came up without errors
> and appears to be working normally.


What does "camcontrol identify" say for this drive? Sounds like a good
candidate for a quirk...

Thanks for testing.

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

Re: Heads up

2016-04-14 Thread Warren Block 

On Thu, 14 Apr 2016, Warner Losh wrote:



On Thu, Apr 14, 2016 at 9:56 PM, Warren Block  wrote:
  On Thu, 14 Apr 2016, Warner Losh wrote:

The CAM I/O scheduler has been committed to current. This work is 
described
in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though 
the
default scheduler doesn't change the default (old) behavior.

One possible issue, however, is that it also enables NCQ Trims on 
ada SSDs.
There are a few rogue drives that claim support for this feature, 
but
actually implement data corrupt instead of queued trims. The list 
of known
rogues is believed to be complete, but some caution is in order.

 
  Is the list of drives queryable?  Is there an easy way to tell if the 
currently-connected drives are on the list?


/usr/src/sys/cam/ata/ata_da.c has the list.

dmesg will tell you if it detected a bad one since it prints the drive's quirks.
But that's no big deal, because the bad one work just fine if you never issue
a NCQ TRIM. This small group of drives were early adapters of this technology

Here's the full list of known rogues:

Crucial/Micron M500 (all firmware prior to MU07)
Micron M510 MU01 firmware (newer firmware is good)
Crucial/Micron M550 MU01 firmware (newer firmware is good)
Crucial MX100 MU01 firmware (newer firmware is good)
FCCT M500 all firmware
Samsung 830 all firmware
Samsung 840 all firmware
Samsung 850 all firmware

All of these are at least 18 months old (if not older). There's some confusing 
in Linux lists on
the full impact of the Samsung drives (there was a bug in the Linux 
implementation (that can't
be present in the FreeBSD implementation) that may have been the root cause for 
the Samsung
black listing). Out of an abundance of caution, I've kept them in the list. 
Also, it's my belief that
the Crucial/Micron models with MU01 firmware were mostly corrected after early 
samples
since most of the channel drives I've helped people debug had MU02 firmware. 
Also, a quick
google search shows the MU02 firmware for each of these models has been 
available for
at least a year.


After updating a Dell E7240, booting showed a bunch of FPDMA errors and 
then panicked after about 30 seconds.


The SSD is a Samsung PM851 mSATA drive with firmware EXT4AD0Q.  I 
believe this is the OEM version of the Samsung 840 Evo.  According to 
the Dell support page, the machine shipped on January 22, 2015.  So 
while the drive might not have been manufactured in a while, Dell was 
still using them that recently.  Note that this is a used machine, I 
have only had it a week.


After booting with mfsBSD, a quick fsck, and setting 
kern.cam.ada.0.quirks=0x2 in /boot/loader.conf, it came up without 
errors and appears to be working normally.

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

FreeBSD_HEAD_i386 - Build #2858 - Fixed

2016-04-14 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #2858 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2858/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2858/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2858/console

Change summaries:

298027 by imp:
Add FCCT M500 to the NCQ black list. Linux added it in 4.2 (August
2015). Correct the M500 firmware versions. EU07 was the engineering
test version, not the release version with the fix. MU07 is the
release version. It's the only Micron firmware version to actually
work. Remove support for EU07.

This brings the blacklist into parity with the Linux blacklist as of
4.5, except for the Micron M500 MU07 entry. I personally tested the
MU07 firmware on 12 machines running 6 drives each with no corruption
in the past 6 months with Netflix production loads. Prior versions of
the M500 firmware wouldn't last more than a few days.

Sponsored by: Netflix, Inc.

298026 by imp:
Use the new TUNABLE_INT64 to match the type of sbintime_t.

298025 by imp:
Create wrappers for uint64_t and int64_t for the tunables. While not
strictly necessary, it is more convenient.

298024 by ngie:
Set test_argv to NULL, not 0, if not executing a specific test

MFC after: 1 week
Submitted by: pfg
Sponsored by: EMC / Isilon Storage Division

298023 by ngie:
Fix typos (intenral -> internal) in comments

298022 by sephe:
hyperv: Deprecate HYPERV option by moving Hyper-V IDT vector into vmbus

Submitted by:   Jun Su 
Reviewed by:jhb, kib, sephe
Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D5910

298021 by araujo:
Use NULL instead of 0 for pointers and memory allocation.
malloc and realloc will return NULL pointer if it can't alloc memory.

MFC after:  4 weeks

298020 by jhibbits:
Add fman and dpaa fixups for powerpc fdt

Obtained from:  Semihalf

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

Re: Heads up

2016-04-14 Thread Warner Losh 
On Thu, Apr 14, 2016 at 9:56 PM, Warren Block  wrote:

> On Thu, 14 Apr 2016, Warner Losh wrote:
>
> The CAM I/O scheduler has been committed to current. This work is described
>> in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the
>> default scheduler doesn't change the default (old) behavior.
>>
>> One possible issue, however, is that it also enables NCQ Trims on ada
>> SSDs.
>> There are a few rogue drives that claim support for this feature, but
>> actually implement data corrupt instead of queued trims. The list of known
>> rogues is believed to be complete, but some caution is in order.
>
>

> Is the list of drives queryable?  Is there an easy way to tell if the
> currently-connected drives are on the list?
>

/usr/src/sys/cam/ata/ata_da.c has the list.

dmesg will tell you if it detected a bad one since it prints the drive's
quirks.
But that's no big deal, because the bad one work just fine if you never
issue
a NCQ TRIM. This small group of drives were early adapters of this
technology

Here's the full list of known rogues:

Crucial/Micron M500 (all firmware prior to MU07)
Micron M510 MU01 firmware (newer firmware is good)
Crucial/Micron M550 MU01 firmware (newer firmware is good)
Crucial MX100 MU01 firmware (newer firmware is good)
FCCT M500 all firmware
Samsung 830 all firmware
Samsung 840 all firmware
Samsung 850 all firmware

All of these are at least 18 months old (if not older). There's some
confusing in Linux lists on
the full impact of the Samsung drives (there was a bug in the Linux
implementation (that can't
be present in the FreeBSD implementation) that may have been the root cause
for the Samsung
black listing). Out of an abundance of caution, I've kept them in the list.
Also, it's my belief that
the Crucial/Micron models with MU01 firmware were mostly corrected after
early samples
since most of the channel drives I've helped people debug had MU02
firmware. Also, a quick
google search shows the MU02 firmware for each of these models has been
available for
at least a year.

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

Re: Heads up

2016-04-14 Thread Warren Block 

On Thu, 14 Apr 2016, Warner Losh wrote:


The CAM I/O scheduler has been committed to current. This work is described
in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the
default scheduler doesn't change the default (old) behavior.

One possible issue, however, is that it also enables NCQ Trims on ada SSDs.
There are a few rogue drives that claim support for this feature, but
actually implement data corrupt instead of queued trims. The list of known
rogues is believed to be complete, but some caution is in order.


Is the list of drives queryable?  Is there an easy way to tell if the 
currently-connected drives are on the list?

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

Re: Heads up

2016-04-14 Thread Alfred Perlstein 
Warner thank you very much. 

Sent from my iPhone

> On Apr 14, 2016, at 8:17 PM, Warner Losh  wrote:
> 
>> On Thu, Apr 14, 2016 at 8:01 PM, Warner Losh  wrote:
>> 
>> 
>> 
>>> On Thu, Apr 14, 2016 at 7:22 PM, Alfred Perlstein  wrote:
>>> 
>>> 
>>> 
 On 4/14/16 3:42 PM, Warner Losh wrote:
 
 The CAM I/O scheduler has been committed to current. This work is
 described
 in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the
 default scheduler doesn't change the default (old) behavior.
 
 One possible issue, however, is that it also enables NCQ Trims on ada
 SSDs.
 There are a few rogue drives that claim support for this feature, but
 actually implement data corrupt instead of queued trims. The list of
 known
 rogues is believed to be complete, but some caution is in order.
 
 Yowch...
>>> 
>>> With data at stake wouldn't a whitelist be better along with a tool for
>>> testing it?
>>> 
>>> Example, you have whitelist and blacklist, if the device isn't on either
>>> list you output a kernel message and suggest they run a tool to "test" the
>>> controller and report back the findings?
>> 
>> 
>> The only way to test it is to enable it. Run it for a day or six. If your
>> data goes away, the drive is a lying sack. There's no tool to detect this
>> that I've seen. You run the NCQ trim, it works. You do it again, it works
>> again. After a while, if you have a bad drive model, bad things happen that
>> are drive model specific.
>> 
>> Did I mention that the black list matches Linux's black list and that only
>> a tiny number of drive models lie. I guess I didn't.
> 
> I just sync it back up to the Linux list. This list has been stable for the
> past year or so, with only one entry added back in August. All the other
> entries came early in Linux's tables. I did add a quirk to allow it on the
> Micron/Crucial M500 with MU07 firmware, but only because I've personally
> tested that on dozens of drives over the past 6 months under Netflix
> streaming video loads after getting the new firmware.
> 
> 
>> I am thinking of adding a tunable to turn it off though for people that
>> are paranoid.
> 
> Actually, since it is already  a quirk, you can use the tunable
> 
> kern.cam.ada.X.quirks=0x2
> 
> to disable NCQ trim. You can change it to 0x3 if you need 4k sectors as
> well. So there's no need to change anything to be able to disable it. Given
> how long Linux has been in the wild with NCQ enabled (approximately 18
> months), I'm guessing their quirk list is going to be fairly complete. I
> have no other systems to cross check this with, but would welcome pointers
> if I've overlooked something. I did this bit of code about 15 months ago,
> but it wasn't until 6 months ago that I had working SSD firmware to test it
> on.
> 
> Warner
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

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

Re: Heads up

2016-04-14 Thread Warner Losh 
On Thu, Apr 14, 2016 at 8:01 PM, Warner Losh  wrote:

>
>
> On Thu, Apr 14, 2016 at 7:22 PM, Alfred Perlstein  wrote:
>
>>
>>
>> On 4/14/16 3:42 PM, Warner Losh wrote:
>>
>>> The CAM I/O scheduler has been committed to current. This work is
>>> described
>>> in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the
>>> default scheduler doesn't change the default (old) behavior.
>>>
>>> One possible issue, however, is that it also enables NCQ Trims on ada
>>> SSDs.
>>> There are a few rogue drives that claim support for this feature, but
>>> actually implement data corrupt instead of queued trims. The list of
>>> known
>>> rogues is believed to be complete, but some caution is in order.
>>>
>>> Yowch...
>>
>> With data at stake wouldn't a whitelist be better along with a tool for
>> testing it?
>>
>> Example, you have whitelist and blacklist, if the device isn't on either
>> list you output a kernel message and suggest they run a tool to "test" the
>> controller and report back the findings?
>
>
> The only way to test it is to enable it. Run it for a day or six. If your
> data goes away, the drive is a lying sack. There's no tool to detect this
> that I've seen. You run the NCQ trim, it works. You do it again, it works
> again. After a while, if you have a bad drive model, bad things happen that
> are drive model specific.
>
> Did I mention that the black list matches Linux's black list and that only
> a tiny number of drive models lie. I guess I didn't.
>

I just sync it back up to the Linux list. This list has been stable for the
past year or so, with only one entry added back in August. All the other
entries came early in Linux's tables. I did add a quirk to allow it on the
Micron/Crucial M500 with MU07 firmware, but only because I've personally
tested that on dozens of drives over the past 6 months under Netflix
streaming video loads after getting the new firmware.


> I am thinking of adding a tunable to turn it off though for people that
> are paranoid.
>

Actually, since it is already  a quirk, you can use the tunable

kern.cam.ada.X.quirks=0x2

to disable NCQ trim. You can change it to 0x3 if you need 4k sectors as
well. So there's no need to change anything to be able to disable it. Given
how long Linux has been in the wild with NCQ enabled (approximately 18
months), I'm guessing their quirk list is going to be fairly complete. I
have no other systems to cross check this with, but would welcome pointers
if I've overlooked something. I did this bit of code about 15 months ago,
but it wasn't until 6 months ago that I had working SSD firmware to test it
on.

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

Re: FreeBSD_HEAD_i386 - Build #2857 - Still Failing

2016-04-14 Thread Warner Losh 
On Thu, Apr 14, 2016 at 8:49 PM, Ngie Cooper (yaneurabeya) <
yaneurab...@gmail.com> wrote:
>
> Build’s still broken..


Test building a fix as we speak.

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

Re: FreeBSD_HEAD_i386 - Build #2857 - Still Failing

2016-04-14 Thread Ngie Cooper (yaneurabeya) 

> On Apr 14, 2016, at 19:14, jenkins-ad...@freebsd.org wrote:
> 
> FreeBSD_HEAD_i386 - Build #2857 - Still Failing:
> 
> Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2857/
> Full change log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2857/changes
> Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2857/console
> 
> Change summaries:
> 
> 298018 by araujo:
> Initialize pointer with NULL instead of 0.
> 
> Submitted by: pfg
> 
> 298017 by asomers:
> Add more debugging statements in vdev_geom.c
> 
> Log a debugging message whenever geom functions fail in vdev_geom_attach.
> Printing these messages is controlled by vfs.zfs.debug
> 
> MFC after:4 weeks
> Sponsored by: Spectra Logic Corp
> 

...

> ctfconvert -L VERSION -g ar5111.o
> --- all_subdir_cam ---
> /usr/src/sys/modules/cam/../../cam/scsi/scsi_da.c:1274:1: error: incompatible 
> pointer types initializing 'long *' with an expression of type 'sbintime_t *' 
> (aka 'long long *') [-Werror,-Wincompatible-pointer-types]
> TUNABLE_LONG("kern.cam.da.default_softtimeout", _default_softtimeout);
> ^~~~
> /usr/src/sys/sys/kernel.h:292:3: note: expanded from macro 'TUNABLE_LONG'
>(var),  \
>^
> --- all_subdir_ath ---
> --- ar5112.o ---
> cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc  
> -I. -I/usr/src/sys/modules/ath/../../dev/ath 
> -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -I. 
> -I/usr/src/sys/modules/ath/../../contrib/dev/ath/ath_hal/ 
> -DHAVE_KERNEL_OPTION_HEADERS -include 
> /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g 
> -I/usr/obj/usr/src/sys/GENERIC  -MD  -MF.depend.ar5112.o -MTar5112.o -mno-mmx 
> -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 
> -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
> -Wno-pointer-sign -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
> -fdiagnostics-show-option  -Wno-unknown-pragmas  
> -Wno-error-tautological-compare -Wno-error-empty-body  
> -Wno-error-parentheses-equality -Wno-error-unused-function  
> -Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
> -std=iso9899:1999 -c /usr/src/sys/modules/ath/../../dev
> /ath/ath_hal/ar5212/ar5112.c -o ar5112.o
> --- all_subdir_cam ---
> 1 error generated.
> *** [scsi_da.o] Error code 1
> 
> bmake[4]: stopped in /usr/src/sys/modules/cam
> 1 error

Build’s still broken..
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD_i386 - Build #2857 - Still Failing

2016-04-14 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #2857 - Still Failing:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2857/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2857/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2857/console

Change summaries:

298018 by araujo:
Initialize pointer with NULL instead of 0.

Submitted by:   pfg

298017 by asomers:
Add more debugging statements in vdev_geom.c

Log a debugging message whenever geom functions fail in vdev_geom_attach.
Printing these messages is controlled by vfs.zfs.debug

MFC after:  4 weeks
Sponsored by:   Spectra Logic Corp



The end of the build log:

[...truncated 155470 lines...]
ld -Bshareable -d -warn-common -o if_bwi.ko.full if_bwi.kld
--- if_bwi.ko.debug ---
objcopy --only-keep-debug if_bwi.ko.full if_bwi.ko.debug
--- if_bwi.ko ---
objcopy --strip-debug --add-gnu-debuglink=if_bwi.ko.debug  if_bwi.ko.full 
if_bwi.ko
--- all_subdir_ath ---
--- ar5211_power.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc  
-I. -I/usr/src/sys/modules/ath/../../dev/ath 
-I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -I. 
-I/usr/src/sys/modules/ath/../../contrib/dev/ath/ath_hal/ 
-DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h 
-I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC  -MD  
-MF.depend.ar5211_power.o -MTar5211_power.o -mno-mmx -mno-sse -msoft-float 
-ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
-std=iso9899:1999 -c /usr/src/sys/modules/a
 th/../../dev/ath/ath_hal/ar5211/ar5211_power.c -o ar5211_power.o
--- ar5211_phy.o ---
ctfconvert -L VERSION -g ar5211_phy.o
--- all_subdir_cam ---
===> cam (all)
--- machine ---
machine -> /usr/src/sys/i386/include
--- x86 ---
x86 -> /usr/src/sys/x86/include
--- opt_cam.h ---
ln -sf /usr/obj/usr/src/sys/GENERIC/opt_cam.h opt_cam.h
--- all_subdir_ath ---
--- ar5211_power.o ---
ctfconvert -L VERSION -g ar5211_power.o
--- all_subdir_cam ---
--- opt_ada.h ---
ln -sf /usr/obj/usr/src/sys/GENERIC/opt_ada.h opt_ada.h
--- opt_scsi.h ---
ln -sf /usr/obj/usr/src/sys/GENERIC/opt_scsi.h opt_scsi.h
--- opt_cd.h ---
ln -sf /usr/obj/usr/src/sys/GENERIC/opt_cd.h opt_cd.h
--- opt_kdtrace.h ---
ln -sf /usr/obj/usr/src/sys/GENERIC/opt_kdtrace.h opt_kdtrace.h
--- opt_pt.h ---
ln -sf /usr/obj/usr/src/sys/GENERIC/opt_pt.h opt_pt.h
--- opt_sa.h ---
ln -sf /usr/obj/usr/src/sys/GENERIC/opt_sa.h opt_sa.h
--- opt_ses.h ---
ln -sf /usr/obj/usr/src/sys/GENERIC/opt_ses.h opt_ses.h
--- vnode_if_newproto.h ---
awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p
--- vnode_if_typedef.h ---
awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q
--- device_if.h ---
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h
--- bus_if.h ---
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h
--- all_subdir_ath ---
--- ar5211_recv.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc  
-I. -I/usr/src/sys/modules/ath/../../dev/ath 
-I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -I. 
-I/usr/src/sys/modules/ath/../../contrib/dev/ath/ath_hal/ 
-DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h 
-I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC  -MD  
-MF.depend.ar5211_recv.o -MTar5211_recv.o -mno-mmx -mno-sse -msoft-float 
-ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
-std=iso9899:1999 -c /usr/src/sys/modules/ath
 /../../dev/ath/ath_hal/ar5211/ar5211_recv.c -o ar5211_recv.o
--- all_subdir_cam ---
--- vnode_if.h ---
awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h
--- cam_compat.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h 
-I. -I/usr/src/sys -fno-common -g -I/usr/obj/usr/src/sys/GENERIC  -MD  
-MF.depend.cam_compat.o -MTcam_compat.o -mno-mmx -mno-sse -msoft-float 
-ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls

Re: Heads up

2016-04-14 Thread Warner Losh 
On Thu, Apr 14, 2016 at 7:22 PM, Alfred Perlstein  wrote:

>
>
> On 4/14/16 3:42 PM, Warner Losh wrote:
>
>> The CAM I/O scheduler has been committed to current. This work is
>> described
>> in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the
>> default scheduler doesn't change the default (old) behavior.
>>
>> One possible issue, however, is that it also enables NCQ Trims on ada
>> SSDs.
>> There are a few rogue drives that claim support for this feature, but
>> actually implement data corrupt instead of queued trims. The list of known
>> rogues is believed to be complete, but some caution is in order.
>>
>> Yowch...
>
> With data at stake wouldn't a whitelist be better along with a tool for
> testing it?
>
> Example, you have whitelist and blacklist, if the device isn't on either
> list you output a kernel message and suggest they run a tool to "test" the
> controller and report back the findings?


The only way to test it is to enable it. Run it for a day or six. If your
data goes away, the drive is a lying sack. There's no tool to detect this
that I've seen. You run the NCQ trim, it works. You do it again, it works
again. After a while, if you have a bad drive model, bad things happen that
are drive model specific.

Did I mention that the black list matches Linux's black list and that only
a tiny number of drive models lie. I guess I didn't.

I am thinking of adding a tunable to turn it off though for people that are
paranoid.

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

Re: Heads up

2016-04-14 Thread Alfred Perlstein 



On 4/14/16 3:42 PM, Warner Losh wrote:

The CAM I/O scheduler has been committed to current. This work is described
in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the
default scheduler doesn't change the default (old) behavior.

One possible issue, however, is that it also enables NCQ Trims on ada SSDs.
There are a few rogue drives that claim support for this feature, but
actually implement data corrupt instead of queued trims. The list of known
rogues is believed to be complete, but some caution is in order.


Yowch...

With data at stake wouldn't a whitelist be better along with a tool for 
testing it?


Example, you have whitelist and blacklist, if the device isn't on either 
list you output a kernel message and suggest they run a tool to "test" 
the controller and report back the findings?


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

Клиентские базы Email: ammanakuw-7...@yopmail.com тел +79133913837 (whatsapp,viber,telegram) Skype: prodawez389

2016-04-14 Thread curr...@freebsd.org 
Соберем для Вас по интернет базу данных потенциальных клиентов для Вашего 
Бизнеса.

По базе можно звонить, писать, слать факсы и email, 

вести любые прямые активные продажи Ваших товаров и услуг

Узнайте подробнее по

тел +79133913837 (whatsapp,viber,telegram)

Skype: prodawez389

Email: ammanakuw-7...@yopmail.com
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD_i386 - Build #2856 - Failure

2016-04-14 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #2856 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2856/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2856/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2856/console

Change summaries:

298016 by ae:
Add External Actions KPI to ipfw(9).

It allows implementing loadable kernel modules with new actions and
without needing to modify kernel headers and ipfw(8). The module
registers its action handler and keyword string, that will be used
as action name. Using generic syntax user can add rules with this
action. Also ipfw(8) can be easily modified to extend basic syntax
for external actions, that become a part base system.
Sample modules will coming soon.

Obtained from:  Yandex LLC
Sponsored by:   Yandex LLC

298015 by imp:
Add note about CAM I/O scheduler.

298014 by ngie:
Regenerate the list of bsd.progs.mk supported variables

Prefix with dashes (unordered list) and put one variable on each
line (to avoid future conflicts)

Done via the following one-liner:

> sh -c 'for i in $(make -C tests/sys/aio PROG=foo -VPROG_VARS:O); do printf 
> "\t\t- $i\n"; done'

MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division

298013 by ngie:
Commit documentation change for r298012

Requested by: bdrewery
X-MFC with: r298012
Sponsored by: EMC / Isilon Storage Division

298012 by ngie:
Add DEBUG_FLAGS to PROG_VARS and STRIP to PROG_OVERRIDE_VARS

This will allow the variables [*] to be overridden on a per-PROG basis,
which is useful when controlling "stripping" behavior for some tests
that require debug symbols or to be unstripped

DEBUG_FLAGS (similar to CFLAGS) supports appending, whereas STRIP is
an override

*: Due to how STRIP is defined in bsd.own.mk (in addition to
bsd.lib.mk and bsd.prog.mk), and the fact that bsd.test.mk pulls in
bsd.own.mk first, overriding STRIP doesn't work today.

A follow up commit is pending to "rectify" this after additional
testing is done.

Discussed with: bdrewery
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division

298011 by imp:
Add a comment about why the timeout for flush was lowered to 5s.

298010 by imp:
Add in missing files from r298002.

298009 by bdrewery:
Regenerate

298008 by scottl:
Update the devd.conf man page to describe the new CAM/periph system/subsystem.

MFC after:  3 days
Sponsored by:   Netflix

298007 by bdrewery:
Add more content for WITH_META_MODE/WITH_DIRDEPS_BUILD.

Sponsored by:   EMC / Isilon Storage Division

298006 by bdrewery:
META_MODE+filemon: Default -DNO_CLEAN enabled.

When using meta mode with filemon, the build is reliably incremental
safe.  Bmake will use the meta files, along with filemon information,
to rebuild targets when their dependencies change, commands change,
or files they generate are missing.

Sponsored by:   EMC / Isilon Storage Division

298005 by wblock:
Remove a link to the CTM section of the Handbook, which no longer exists.

MFC after:  1 week

298004 by scottl:
Add a devctl/devd notification conduit for CAM errors that happen at the
periph level.  When a relevant error is reported to the periph, some
amplifying information is gathered, and the error and information are fed
to devctl with the attributes / keys system=CAM, subsystem=periph.  The
'type' key will be either 'error' or 'timeout', and based on this, various
other keys are also populated.

The purpose of this is to provide a concise mechanism for error reporting
that is less noisy than the system console but higher in resolution and
fidelity than simple sysctl counters.  We will be using it at Netflix to
populate a structured log and database to track errors and error trends
across our world-wide population of drives.

Submitted by:   imp, scottl
Approved by:kenm
MFC after:  3 days
Sponsored by:   Netflix
Differential Revision:  D5943

298003 by ae:
Change the type of 'etlv' field in struct named_object to uint16_t.
It should match with the type field in struct ipfw_obj_tlv.

Obtained from:  Yandex LLC
Sponsored by:   Yandex LLC

298002 by imp:
New CAM I/O scheduler for FreeBSD. The default I/O scheduler is the same
as before. The common scheduling bits have moved from inline code in
each of the CAM periph drivers into a library that implements the
default scheduling.

In addition, a number of rate-limiting and I/O preference options can
be enabled by adding CAM_IOSCHED_NETFLIX to your config file. A number
of extra stats are also maintained. CAM_IOSCHED_NETFLIX isn't on by
default because it uses a separate BIO_READ and BIO_WRITE queue, so
doesn't honor BIO_ORDERED between these two types of operations. We
already didn't honor it for BIO_DELETE, and we don't depend on
BIO_ORDERED between reads and writes anywhere in the system (it is
currently used with BIO_FLUSH in ZFS to make sure some writes are
complete before others start and as a poor-man's soft dependency in
one place in UFS where we won't be issuing READs until after the

Re: Heads up

2016-04-14 Thread Graham Menhennitt 

On 15/04/2016 8:42 AM, Warner Losh wrote:

The CAM I/O scheduler has been committed to current. This work is described
in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the
default scheduler doesn't change the default (old) behavior.

One possible issue, however, is that it also enables NCQ Trims on ada SSDs.
There are a few rogue drives that claim support for this feature, but
actually implement data corrupt instead of queued trims. The list of known
rogues is believed to be complete, but some caution is in order.


What sort of caution, please? How do we check whether it's working? Is 
it an "all or nothing" type of thing, or could there be subtle problems?


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

Heads up

2016-04-14 Thread Warner Losh 
The CAM I/O scheduler has been committed to current. This work is described
in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the
default scheduler doesn't change the default (old) behavior.

One possible issue, however, is that it also enables NCQ Trims on ada SSDs.
There are a few rogue drives that claim support for this feature, but
actually implement data corrupt instead of queued trims. The list of known
rogues is believed to be complete, but some caution is in order.

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

Re: 11.0: head/lib/libsysdecode/Makefile for . . ./libsoft/usr/include uses CPP when XCPP needed? [Makefile.libcompat issue]

2016-04-14 Thread Mark Millard 
This will take me a while.

I'm trying 2 or more builds, all from amd64 context:

TARGET_ARCH=amd64
TARGET_ARCH=armv6 (with my rpi2 armv7a tailoring in src.conf)
possibly TARGET_ARC=powerpc64 (without lib32) or powerpc (which has no lib32 or 
libsoft option)

I'm doing this because my personal work arounds have been to have an additional 
line that I'd adjust:

For TARGET_ARCH=amd64: #LIBCOMPATWMAKEFLAGS+= CPP="${XCPP}"
For TARGET_ARCH=armv6: LIBCOMPATWMAKEFLAGS+= CPP="${XCPP}"

So: commented out vs. not. amd64 did not work with the ${XCPP} use because it 
depended on a not being limited to the x86 during its lib32 processing.

See https://lists.freebsd.org/pipermail/freebsd-arm/2016-April/013663.html for 
more information. Without the "#" for amd64 I got (grep of the log):

> ioctl.c:472:18: error: use of undeclared identifier 'CCISS_PASSTHRU32'
> ioctl.c:1186:18: error: use of undeclared identifier 'IPMICTL_RECEIVE_MSG_32'
> ioctl.c:1190:18: error: use of undeclared identifier 
> 'IPMICTL_RECEIVE_MSG_TRUNC_32'
> ioctl.c:1196:18: error: use of undeclared identifier 'IPMICTL_SEND_COMMAND_32'
> ioctl.c:1394:18: error: use of undeclared identifier 'MPTIO_RAID_ACTION32'
> ioctl.c:1398:18: error: use of undeclared identifier 'MPTIO_READ_CFG_HEADER32'
> ioctl.c:1402:18: error: use of undeclared identifier 'MPTIO_READ_CFG_PAGE32'
> ioctl.c:1406:18: error: use of undeclared identifier 
> 'MPTIO_READ_EXT_CFG_HEADER32'
> ioctl.c:1410:18: error: use of undeclared identifier 
> 'MPTIO_READ_EXT_CFG_PAGE32'
> ioctl.c:1414:18: error: use of undeclared identifier 'MPTIO_WRITE_CFG_PAGE32'

Of course since I omitted ${LIBCOMPATCFLAGS} my earlier results might not apply 
to your change.

I'm trying these on 11.0-CURRENT -r297769 . Let me know if I should use 
something more recent for some reason.

===
Mark Millard
markmi at dsl-only.net

On 2016-Apr-14, at 1:41 PM, Bryan Drewery  wrote:

On 4/6/2016 1:14 PM, Mark Millard wrote:
> The below forwards an example of a possibly more general issue not 
> necessarily limited to arm context of the example: in a cross compile context 
> the host CPP is in use via Makefile.libcompat not involving "${XCPP}" and so 
> various macro checks for the target context fail to work.
> 
> [The below and the material leading up to it was originally posted to 
> freebsd-arm.]
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> On 2016-Apr-4, at 2:02 PM, Mark Millard  wrote:
> 
> As a fix for
> 
>>> --- all_subdir_lib/libsysdecode ---
>>> In file included from :17:
>>> In file included from 
>>> /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/dev/nvme/nvme.h:36:
>>> In file included from 
>>> /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/sys/param.h:135:
>>> In file included from 
>>> /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/param.h:49:
>>> /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/acle-compat.h:182:4:
>>>  error: Unable to determine architecture version.
>>> #  error Unable to determine architecture version.
>>> ^
> 
> I tested building an amd64 -> arm cross-build based on
> 
>> # svnlite diff Makefile.libcompat
>> Index: Makefile.libcompat
>> ===
>> --- Makefile.libcompat   (revision 297514)
>> +++ Makefile.libcompat   (working copy)
>> @@ -90,6 +90,7 @@
>>  DTRACE="${LIB$COMPATDTRACE:U${DTRACE}}"
>> LIBCOMPATWMAKEFLAGS+= CC="${XCC} ${LIBCOMPATCFLAGS}" \
>>  CXX="${XCXX} ${LIBCOMPATCFLAGS} ${LIBCOMPATCXXFLAGS}" \
>> +CPP="${XCPP}" \
>>  DESTDIR=${LIBCOMPATTMP} \
>>  -DNO_CPU_CFLAGS \
>>  MK_CTF=no \
> 
> and it completed without getting an "error:". So this addition to 
> Makefile.libcompat may be one option for a fix.
> 

Yes this is needed. Please try this patch though:

https://people.freebsd.org/~bdrewery/patches/libcompat-xcpp.diff


-- 
Regards,
Bryan Drewery


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

Re: Fwd: 11.0: head/lib/libsysdecode/Makefile for . . ./libsoft/usr/include uses CPP when XCPP needed? [Makefile.libcompat issue]

2016-04-14 Thread Bryan Drewery 
On 4/6/2016 1:14 PM, Mark Millard wrote:
> The below forwards an example of a possibly more general issue not 
> necessarily limited to arm context of the example: in a cross compile context 
> the host CPP is in use via Makefile.libcompat not involving "${XCPP}" and so 
> various macro checks for the target context fail to work.
> 
> [The below and the material leading up to it was originally posted to 
> freebsd-arm.]
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> On 2016-Apr-4, at 2:02 PM, Mark Millard  wrote:
> 
> As a fix for
> 
>>> --- all_subdir_lib/libsysdecode ---
>>> In file included from :17:
>>> In file included from 
>>> /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/dev/nvme/nvme.h:36:
>>> In file included from 
>>> /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/sys/param.h:135:
>>> In file included from 
>>> /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/param.h:49:
>>> /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/acle-compat.h:182:4:
>>>  error: Unable to determine architecture version.
>>> #  error Unable to determine architecture version.
>>>  ^
> 
> I tested building an amd64 -> arm cross-build based on
> 
>> # svnlite diff Makefile.libcompat
>> Index: Makefile.libcompat
>> ===
>> --- Makefile.libcompat   (revision 297514)
>> +++ Makefile.libcompat   (working copy)
>> @@ -90,6 +90,7 @@
>>  DTRACE="${LIB$COMPATDTRACE:U${DTRACE}}"
>>  LIBCOMPATWMAKEFLAGS+= CC="${XCC} ${LIBCOMPATCFLAGS}" \
>>  CXX="${XCXX} ${LIBCOMPATCFLAGS} ${LIBCOMPATCXXFLAGS}" \
>> +CPP="${XCPP}" \
>>  DESTDIR=${LIBCOMPATTMP} \
>>  -DNO_CPU_CFLAGS \
>>  MK_CTF=no \
> 
> and it completed without getting an "error:". So this addition to 
> Makefile.libcompat may be one option for a fix.
> 

Yes this is needed. Please try this patch though:

https://people.freebsd.org/~bdrewery/patches/libcompat-xcpp.diff


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: Keeping OptionalObsoleteFiles.inc up to date

2016-04-14 Thread Bryan Drewery 
On 4/8/2016 5:59 AM, Dmitry Marakasov wrote:
> * Ngie Cooper (yaneurab...@gmail.com) wrote:
> 
>>> I'm trying to use "make delete-old" specifying WITHOUT_ keyword for
>>> removing some no-more used set of files.
>>>
>>> I've start by testing WITHOUT_TOOLCHAIN:
>>> - Some of files related to clang are correctly delete
>>> - But there are still lot's of others (like /usr/bin/cc)
>>>
>>> Then I've checked tools/build/mk/OptionalObsoleteFiles.in and found that
>>> lot's files are missing in the ".if ${MK_TOOLCHAIN} == no" section.
>>>
>>> I've started a new run of phk's build_options_survey script:
>>> https://people.freebsd.org/~olivier/build_option_survey_20160406/
>>>
>>> And wonder if it's possible to automatically generate the list of
>>> conditional files to be put in OptionalObsoleteFiles.in from the result of
>>> a build_option_survey script ?
>>
>> amdmi3 had a method for doing this, but I think it was a bit of a
>> brute force approach (I could be wrong).
> 
> You are not.
> 
> https://github.com/AMDmi3/obsolete-files-checker
> 
>> The release-pkg project branch method seems like the best way to go
>> about it though because it would kind of do the sanity checking for
>> us...
> 
> Agreed. make delete-old + OptionalObsoleteFiles.in will never be
> complete and work correctly. I'm waiting for packaged base too.
> 

It would be nice if that script and webpage presented a "default" as
too. I just fixed an issue with /usr/lib32/libc_pic.a in r297987 that
doesn't show anywhere on there.  It seems there is no check for "files
installed but still deleted" as well.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature