Unrelenting testplan D25219

[Mark Millard]

On 2020-Jun-13, at 01:42, Klaus Küchemann <maciphone2 at googlemail.com> wrote:

> . . .
>> Am 13.06.2020 um 04:36 schrieb Mark Millard <marklmi at yahoo.com>:
>> I hope that the above notes help.
> 
> Very helpful , thanks,
> I have almost the same setups as you(SSD:filesystem, uSD:v1.14, PL011(&HDMI) ),

FYI: Turns out I also had HDMI connected, even though
I'd not mentioned it before.

> `tried SSD with and without external power...

No powered hub involved in my context. The USB3 SSD
gots it power from the RPi4. (5.1V 3.5A power supply
used for the RPi4.)

> Very happy to hear that we now have 2 machines booting in acpi-mode(Unfortunately, my two gadgets are not included for now :-)
> 
>> The loader.efi ( as EFI\BOOT\BOOTAA64.EFI in the
>> USB SSD's msdosfs) is from a much more recent
>> system build
> that brought me to the idea to test different loaders and one of it „succeeded“ in a loop session 
> but WITH detected controller(VL805)… that’s so strange and not logically reproducable(but repeatable),
> happened only on the 4GB(not on 8GB) with the left two USB-slots… see dmesg at the end of this message…

The USB3 SSD was plugged in the top USB3 slot in my
context. No other USB devices were plugged in. No
external hub was involved.

>> ugen0.2: <vendor 0x2109 USB2.0 Hub> at usbus0
> That’s the VL805, which was not detected with me(except the on the here attached  dmesg).
> On the 4GB, the VL805 has an own eeprom while rpifoundation removed that own eeprom on the 8GB.
> 
>> and ifconfig only shows lo0 (no Ethernet).
> Holy sh*t, it gets stranger and stranger with this gadget..tss..
> Did you leave anything from the files of an msdos-partiton on the SSD?
> If yes, try to remove them all (except the efi)

FYI for the msdosfs:

# df -m
Filesystem             1M-blocks  Used  Avail Capacity  Mounted on
/dev/gpt/Rock64root       195378 66187 113560    37%    /
devfs                          0     0      0   100%    /dev
/dev/msdosfs/RPI4EFIFS        99     0     99     1%    /usb_efi

# find /usb_efi/ -print
/usb_efi/
/usb_efi/EFI
/usb_efi/EFI/BOOT
/usb_efi/EFI/BOOT/BOOTAA64.EFI

That last is the FreeBSD loader that it uses
to boot FreeBSD.

>> Root mount waiting for: CAM
> Hm, didn`t see that on mine afair, `will think about that...

I get those because in /boot/loader.conf I have:

vfs.root.mountfrom="ufs:/dev/gpt/Rock64root"
kern.cam.boot_delay=10000
vfs.mountroot.timeout=10
vfs.root_mount_always_wait=1

Specifically, the "vfs.root_mount_always_wait=1"
leads to the "Root mount waiting for: CAM"
messages.


FYI for the USB3 SSD (via smartctl):

=== START OF INFORMATION SECTION ===
Device Model:     OWC Aura Pro USB Mezz
Serial Number:    #...#
LU WWN Device Id: #...#
Firmware Version: 609ABBF0
User Capacity:    240,057,409,536 bytes [240 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ATA8-ACS, ACS-2 T13/2015-D revision 3
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Tue Jun  9 04:53:38 2020 PDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is:   Unavailable
APM level is:     254 (maximum performance)
Rd look-ahead is: Disabled
Write cache is:   Enabled
DSN feature is:   Unavailable
ATA Security is:  Disabled, NOT FROZEN [SEC1]
Wt Cache Reorder: Unavailable

The 609ABBF0 suggests that the SSD is a modern
variation on a SandForce SSD.




===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)