Re: UEFI booting survey [and compared ubldr.bin booting behavior]

[Mark Millard]

[Just adding notes about what ubldr.bin does
with and without loaderdev being specified
(correctly). Overall it does not appear to
me that the ubldr.bin based contexts can
fully avoid the "systems with multiple
partitions that might be right" issue.]

On 2017-Dec-20, at 2:47 AM, Mark Millard  wrote:

> On 2017-Dec-19, at 9:10 PM, Warner Losh  wrote:
> 
>> On Tue, Dec 19, 2017 at 9:06 PM, Mark Millard  wrote:
>> [The usdcard in my rpi2 example does not contain any kernel files,
>> nor any dtb files. Only the USB SSD stick does. The kernel and dtb
>> do not come from the usdcard. This is what I'm not sure if it is
>> generally supported or not.]
>> 
>> On 2017-Dec-19, at 7:26 PM, Warner Losh  wrote:
>> 
>>> On Dec 19, 2017 4:26 PM, "Mark Millard"  wrote:
 
> . . .
> It sounds different then the results I get with ubldr.bin
> on a rpi2 V1.1 . With the usdcard having a UFS / with
> basically only:
> 
> /etc/fstab (redirecting to a USB SSD stick)
> /boot/* (with /boot/kernel/ empty and /boot/dtb/ empty)
> 
> the result is that all 3 of the following come from the
> USB SSD stick based on the "/" line from the /etc/fstab
> from the usdcard:
> 
> /boot/kernel
> /boot/dtb/bcm2836-rpi-2-b.dtb
> / (mounted root file system)
> 
> In other words: it appears that for ubldr.bin on
> a rpi2 V1.1 /etc/fstab is read and used before
> finding the kernel that is to be loaded. (It or
> another /etc/fstab may be read again later.)
> 
> It is read. It is literally only used to set the root for userland. That 
> is all. Nothing else.
> 
> /usr/src/stand/common/boot.c does show an explicit
> attempt to find a /etc/fstab:
> 
> # grep -r /etc/fstab /usr/src/stand/
> . . .
> /usr/src/stand/common/boot.c: * Try to find the /etc/fstab file on the 
> filesystem (rootdev),
> /usr/src/stand/common/boot.c:sprintf(lbuf, "%s/etc/fstab", rootdev);
> . . .
> 
> That is from getrootmount(char *rootdev):
> 
> int
> getrootmount(char *rootdev)
> {
>charlbuf[128], *cp, *ep, *dev, *fstyp, *options;
>int fd, error;
> 
>if (getenv("vfs.root.mountfrom") != NULL)
>return(0);
> 
> So if you set vfs.root.mountfrom in /boot/loader.conf, we don't read 
> rootdev:/etc/fstab for the value to set vfs.root.mountfrom to.
> 
>error = 1;
>sprintf(lbuf, "%s/etc/fstab", rootdev);
>if ((fd = open(lbuf, O_RDONLY)) < 0)
>goto notfound;
> . . .
> 
> Supporting detail for the example rpi2
> boot context:
> 
> With /mnt being the / from the usdcard:
> 
> # find /mnt -print | more
> /mnt
> /mnt/.snap
> /mnt/boot
> /mnt/boot/defaults
> /mnt/boot/defaults/loader.conf
> /mnt/boot/dtb
> /mnt/boot/firmware
> /mnt/boot/kernel
> /mnt/boot/modules
> /mnt/boot/zfs
> /mnt/boot/msdos
> /mnt/boot/entropy
> /mnt/boot/menu.rc.sample
> /mnt/boot/ubldr
> /mnt/boot/ubldr.bin
> /mnt/boot/brand-fbsd.4th
> /mnt/boot/logo-beastie.4th
> /mnt/boot/logo-beastiebw.4th
> /mnt/boot/logo-fbsdbw.4th
> /mnt/boot/logo-orb.4th
> /mnt/boot/logo-orbbw.4th
> /mnt/boot/loader.conf
> /mnt/boot/loader.efi
> /mnt/boot/boot1.efi
> /mnt/boot/boot1.efifat
> /mnt/boot/beastie.4th
> /mnt/boot/brand.4th
> /mnt/boot/color.4th
> /mnt/boot/check-password.4th
> /mnt/boot/delay.4th
> /mnt/boot/frames.4th
> /mnt/boot/loader.4th
> /mnt/boot/loader.help
> /mnt/boot/menu.4th
> /mnt/boot/menu-commands.4th
> /mnt/boot/menusets.4th
> /mnt/boot/screen.4th
> /mnt/boot/shortcuts.4th
> /mnt/boot/support.4th
> /mnt/boot/version.4th
> /mnt/boot/loader.rc
> /mnt/boot/efi.4th
> /mnt/boot/pcibios.4th
> /mnt/boot/menu.rc
> /mnt/etc
> /mnt/etc/fstab
> /mnt/COPYRIGHT
> /mnt/lost+found
> 
> # more /mnt/etc/fstab
> /dev/da0p1  /   ufs rw,noatime  1 1
> /dev/da0p2  noneswapsw  0 0
> 
> May be this is somehow special to the rpi2 or to
> ubldr.bin operation. (I've never managed to identify
> accidents from deliberately working status in this
> area.)
> 
 So you load /boot/loader and the kernel from the sdcard.
>>> 
>>> No: There are no kernel files on the usdcard. See the complete
>>> file list of its only UFS partition above. No dtb files either.
>>> 
>>> [On a rpi2 ubldr.bin is copied to the msdosfs, where it
>>> is actually put to use.]
>> 
>> OK. Looks like the uboot code has the same bogus 'let's search everything' 
>> code that I'm removing from the UEFI case.
> 
> Could be. My case was so limited that it does not show if
> the search would continue if multiple USB drives were
> present vs. stopping at the first even if the files would
> not be found 

Re: Unable to build 12-current/amd64

[Dimitry Andric]

On 23 Dec 2017, at 10:56, Peter Jeremy  wrote:
> 
> Since r326496, buildworld on my 12-current/amd64 system has consistently
> died as follows.
...
> /usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp:1166:10: fatal 
> error: 'emmintrin.h' file not found
> #include 
> ^
> 1 error generated.
> *** Error code 1
> 
> Stop.
> make[4]: stopped in /usr/src/lib/clang/libclang
> 
> I'm building on a 12.0-CURRENT VirtualBox guest at r326430.  I've checked
> that my /usr/src is clean and deleted /usr/obj to no effect.  I have dug
> into SourceManager.cpp and the #include is protected by a #if __SSE2__,
> which is relying on clang internal checks to define (and my CPU supports
> SSE2).  Does anyone have any ideas to explain what is going on?

First of all, does your host system have emmintrin.h?  E.g. what is the
output of "find /usr/lib/clang -name emmintrin.h" ?

Second, I think this scenario might be possible if you force -march or
other CPU type flags into CFLAGS, instead of using CPUTYPE.  What is the
contents of your make.conf, and other build environment variables?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAMstatus: ATA Status Error

[Karl Denninger]

On 12/23/2017 05:25, O. Hartmann wrote:
> Am Thu, 14 Dec 2017 12:05:20 +0100
> Willem Jan Withagen  schrieb:
>
>> On 13/12/2017 17:47, Rodney W. Grimes wrote:
 On Tue, 12 Dec 2017 14:58:28 -0800
 Cy Schubert  wrote:
 I think people responding to my thread made it clear that the WD Green
 isn't the first-choice-solution for a 20/6 (not 24/7) duty drive and
 the fact, that they have serviced now more than 25000 hours, it would
 be wise to replace them with alternatives.  
>>> I think someone had an apm command that turns off the head park,
>>> that would do wonders for drive life.   On the other hand, I think
>>> if it was my data and I saw that the drive had 2M head load cycles
>>> I would be looking to get out of that driv with any data I could
>>> not easily replace.  If it was well backed up or easily replaced
>>> my worries would be less.  
>> WD made their first series of Green disks green by aggressively turning 
>> them into sleep state. Like when few secs there was nog activity they 
>> would park the head, spin it down, and sleep the disk...
>> Access would need to undo the whole series of command.
>>
>> This could be reset by writing in one of the disks registers. I remember 
>> doing that for my 1,5G WDs (WD15EADS from 2009). That saved a lot of 
>> startups. I still have 'm around, but only use them for things that are 
>> not valuable at all. Some have died over time, but about half of them 
>> still seem to work without much trouble.
>>
>> WD used to have a .exe program to actually do this. But that did not
>> work on later disks. And turning things of on those disks was 
>> impossible/a lot more complex.
>>
>> This type of disk worked quite a long time in my ZFS setup. Like a few 
>> years, but I turned parking of as soon as there was a lot of turmoil 
>> about this in the community.
>> Now I using WD reds for small ZFS systems, and WD red Pro for large 
>> private storage servers. Professional server get HGST He disks, a bit 
>> more expensive, but very little fallout.
>>
>> --WjW
> Hello fellows.
>
> First of all, I managed it over the past week+ to replace all(!) drives with 
> new ones. I
> decided to use this time HGST 4TB Deskstar NAS (HGST HDN726040ALE614) instead 
> of WD RED
> 4TB (WDC WD40EFRX-68N32N0). The one WD RED is about to be replaced in the 
> next days.
>
> Apart from the very long resilvering time (the first drive, the Western 
> Digital WD RED
> 4TB with 64MB cache and 5400 rpm) took 11 h, all HGST drives, although 
> considered faster
> (7200 rpm, 128 MB cache) took 15 - 16 h), everything ran smoothly - except, 
> as mentioned,
> the exorbitant times of recovery.
>
> A very interesting point in this story is: as you could see, the WD Caviar 
> Green 3TB
> drives suffered from a high "193 Load_Cycle_Count" - almost 85 per hour. When 
> replacing
> the drives, I figured out, that one of the four drives was already a Western 
> Digital RED
> 3TB NAS drive, but investigating its  "193 Load_Cycle_Count" revealed, that 
> this drive
> also had a unusual high reload count - see "smartctl -x" output attached. It 
> seems, as
> you already stated, that the APM feature responsible for this isn't 
> available. The drive
> has been purchased Q4/2013.
>
> The HGST drives are very(!) noisy, th ehead movement induces a notable 
> ringing, while the
> WD drive(s) are/were really silent. The power consumption of the HGST drives 
> is higher.
> But apart from that, I'm disappointed about the fact that WD has also 
> implemented this
> "timebomb" Load_Cycle_Count issue.
>
> Thanks a lot for your help and considerations!
>
> Kind regards,
> Oliver
I have a fairly large number of HGST "NAS" drives in service across
multiple locations (several dozens units total.)  I don't like their 5Tb
models much (they're slow comparatively for an unknown reason) but the
4Tb and 6Tb models I have in the field, while noisy and somewhat more
power-hungry (the latter comes from the 7200 rpm speed) have yet to
suffer a failure.


-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAMstatus: ATA Status Error

[O. Hartmann]

Am Thu, 14 Dec 2017 12:05:20 +0100
Willem Jan Withagen  schrieb:

> On 13/12/2017 17:47, Rodney W. Grimes wrote:
> >> On Tue, 12 Dec 2017 14:58:28 -0800
> >> Cy Schubert  wrote:
> >> I think people responding to my thread made it clear that the WD Green
> >> isn't the first-choice-solution for a 20/6 (not 24/7) duty drive and
> >> the fact, that they have serviced now more than 25000 hours, it would
> >> be wise to replace them with alternatives.  
> > 
> > I think someone had an apm command that turns off the head park,
> > that would do wonders for drive life.   On the other hand, I think
> > if it was my data and I saw that the drive had 2M head load cycles
> > I would be looking to get out of that driv with any data I could
> > not easily replace.  If it was well backed up or easily replaced
> > my worries would be less.  
> 
> WD made their first series of Green disks green by aggressively turning 
> them into sleep state. Like when few secs there was nog activity they 
> would park the head, spin it down, and sleep the disk...
> Access would need to undo the whole series of command.
> 
> This could be reset by writing in one of the disks registers. I remember 
> doing that for my 1,5G WDs (WD15EADS from 2009). That saved a lot of 
> startups. I still have 'm around, but only use them for things that are 
> not valuable at all. Some have died over time, but about half of them 
> still seem to work without much trouble.
> 
> WD used to have a .exe program to actually do this. But that did not
> work on later disks. And turning things of on those disks was 
> impossible/a lot more complex.
> 
> This type of disk worked quite a long time in my ZFS setup. Like a few 
> years, but I turned parking of as soon as there was a lot of turmoil 
> about this in the community.
> Now I using WD reds for small ZFS systems, and WD red Pro for large 
> private storage servers. Professional server get HGST He disks, a bit 
> more expensive, but very little fallout.
> 
> --WjW

Hello fellows.

First of all, I managed it over the past week+ to replace all(!) drives with 
new ones. I
decided to use this time HGST 4TB Deskstar NAS (HGST HDN726040ALE614) instead 
of WD RED
4TB (WDC WD40EFRX-68N32N0). The one WD RED is about to be replaced in the next 
days.

Apart from the very long resilvering time (the first drive, the Western Digital 
WD RED
4TB with 64MB cache and 5400 rpm) took 11 h, all HGST drives, although 
considered faster
(7200 rpm, 128 MB cache) took 15 - 16 h), everything ran smoothly - except, as 
mentioned,
the exorbitant times of recovery.

A very interesting point in this story is: as you could see, the WD Caviar 
Green 3TB
drives suffered from a high "193 Load_Cycle_Count" - almost 85 per hour. When 
replacing
the drives, I figured out, that one of the four drives was already a Western 
Digital RED
3TB NAS drive, but investigating its  "193 Load_Cycle_Count" revealed, that 
this drive
also had a unusual high reload count - see "smartctl -x" output attached. It 
seems, as
you already stated, that the APM feature responsible for this isn't available. 
The drive
has been purchased Q4/2013.

The HGST drives are very(!) noisy, th ehead movement induces a notable ringing, 
while the
WD drive(s) are/were really silent. The power consumption of the HGST drives is 
higher.
But apart from that, I'm disappointed about the fact that WD has also 
implemented this
"timebomb" Load_Cycle_Count issue.

Thanks a lot for your help and considerations!

Kind regards,
Oliver

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
smartctl 6.6 2017-11-05 r4594 [FreeBSD 12.0-CURRENT amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Western Digital Red
Device Model: WDC WD30EFRX-68EUZN0
Serial Number:Seriennummer
LU WWN Device Id: 5 0014ee 0ae56aef0
Firmware Version: 80.00A80
User Capacity:3,000,592,982,016 bytes [3.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate:5400 rpm
Device is:In smartctl database [for details use: -P show]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:Sat Dec 23 11:59:30 2017 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is:   Unavailable
APM feature is:   Unavailable
Rd look-ahead is: Enabled
Write cache is:   Enabled
DSN feature is:   Unavailable
ATA Security is:  Disabled, NOT FROZEN [SEC1]
Wt Cache Reorder: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
was completed without 

Unable to build 12-current/amd64

[Peter Jeremy]

Since r326496, buildworld on my 12-current/amd64 system has consistently
died as follows.  I have no problems building on i386 or building
12-current/amd64 on 11-stable.

...
>>> stage 3: cross tools
--
cd /usr/src; INSTALL="sh /usr/src/tools/install.sh"  
TOOLS_PREFIX=/usr/obj/usr/src/amd64.amd64/tmp  
PATH=/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
  WORLDTMP=/usr/obj/usr/src/amd64.amd64/tmp  MAKEFLAGS="-m 
/usr/src/tools/build/mk  -m /usr/src/share/mk" make  -f Makefile.inc1  DESTDIR= 
 OBJTOP='/usr/obj/usr/src/amd64.amd64/tmp/obj-tools'  OBJROOT='${OBJTOP}/'  
MAKEOBJDIRPREFIX=  BOOTSTRAPPING=1200054  BWPHASE=cross-tools  SSP_CFLAGS=  
MK_HTML=no NO_LINT=yes MK_MAN=no  -DNO_PIC MK_PROFILE=no -DNO_SHARED  
-DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no  MK_CLANG_EXTRAS=no MK_CLANG_FULL=no  
MK_LLDB=no MK_TESTS=no  MK_INCLUDES=yes  TARGET=amd64 TARGET_ARCH=amd64  
MK_GDB=no MK_LLD_IS_LD=no MK_TESTS=no cross-tools
...
===> lib/clang/libclang (all)
...
c++  -O2 -pipe -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang 
-I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm 
-I/usr/src/contrib/llvm/tools/clang/lib/Driver 
-I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include 
-I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -ffunction-sections 
-fdata-sections -gline-tables-only -MD -MF.depend.Basic_SourceLocation.o 
-MTBasic/SourceLocation.o -Qunused-arguments 
-I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include  -std=c++11 
-fno-exceptions -fno-rtti -gline-tables-only -stdlib=libc++ 
-Wno-c++11-extensions  -c 
/usr/src/contrib/llvm/tools/clang/lib/Basic/SourceLocation.cpp -o 
Basic/SourceLocation.o
c++  -O2 -pipe -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang 
-I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm 
-I/usr/src/contrib/llvm/tools/clang/lib/Driver 
-I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include 
-I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -ffunction-sections 
-fdata-sections -gline-tables-only -MD -MF.depend.Basic_SourceManager.o 
-MTBasic/SourceManager.o -Qunused-arguments 
-I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include  -std=c++11 
-fno-exceptions -fno-rtti -gline-tables-only -stdlib=libc++ 
-Wno-c++11-extensions  -c 
/usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp -o 
Basic/SourceManager.o
/usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp:1166:10: fatal 
error: 'emmintrin.h' file not found
#include 
 ^
1 error generated.
*** Error code 1

Stop.
make[4]: stopped in /usr/src/lib/clang/libclang

I'm building on a 12.0-CURRENT VirtualBox guest at r326430.  I've checked
that my /usr/src is clean and deleted /usr/obj to no effect.  I have dug
into SourceManager.cpp and the #include is protected by a #if __SSE2__,
which is relying on clang internal checks to define (and my CPU supports
SSE2).  Does anyone have any ideas to explain what is going on?

-- 
Peter Jeremy


signature.asc
Description: PGP signature