Re: ffs_fhtovp: inode overflow?
On Wed, Dec 11, 2019 at 10:26:41AM -0600, Eric van Gyzen wrote: > Since ino64 went in, Coverity complains that the two "ino >= foo" > comparisons in ffs_fhtovp() compare a 64-bit value to a 32-bit. Is this > a problem in practice? I do not think that this a problem, and Coverity could be a bit smarter there. The ino variable is 64bit, but why is it worrysome to compare it with a 32 bit value ? We want to limit the value to the max possible inode number but still keep it type-correct. In fact, the ino value is initialized from 32bit struct ufid ufid_ino, so Coverity could understand that and shut down the warning for formal reasons. ___ 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: Supermicro X9SCV-Q: no boot options to define
Hartmann, O. wrote on 2019/12/11 19:07: The AMI BIOS is at 2.10.1208 from 4th Nov 2012. There is a newer firmware available, but I can't install the firmware: while being able to UEFI USB flahes, it is impossible to boot FreeDOS 1.1 from an USB flash drive, even having properly set Legacy Boot ROM in PCIe/PnP/etc options in the firmware. I never have had such a confusing BIOS/firmware. Did you try to boot some ISO media through IPMI remote media option? I don't know if X9SCV-Q have this option. I have X9SCA-F which is somewhat different than yours. Miroslav Lachman ___ 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: Supermicro X9SCV-Q: no boot options to define
On Wed, 11 Dec 2019 10:48:22 +0100 Gary Jennejohn wrote: > On Wed, 11 Dec 2019 08:23:59 +0100 > "Hartmann, O." wrote: > > > Hello folks, > > > > my apology for polluting this list with a non-FreeBSD specific > > problem, but since Supermicro is a veryy often used vendor in the > > FreeBSD user/developer community I might find help here much fast. > > > > I got hands on onto an oldish Supermicro X9SCV-Q mainboard, equipted > > with an older i5-25XXM CPU running at 2,5 GHz). The AMI BIOS has > > version 2.10.1208 from 2012. > > The board does initially a longer beep and the it sounds like two > > or three very short beeps plus a last longer beep at a higher tune > > and then the system ALWAYS jumps into the firmware/BIOS screen, no > > matter whether I set a administrator password to protect the BIOS > > or not. Apart from the suspect of damaged RAM (three beeps indicate > > RAM problem above the first 64k block, two indicate PEI recovery or > > video memory problems if I interpret the manual correctly). > > > > Sometimes the POST screen shows some message like "... in Recovery > > State", due to the off-phased HDMI attached monitor, I do not see > > the first characters. Maybe someone knows what that might indicate. > > > > I already have changed the memory banks and the memory seems to be > > allright as the replacement memory has been checked thoroughly > > prior to the test in another well running box and I also checked > > the memory on another box with memtest tool without any suspicious > > indication. > > > > The attempt to flash the latest firmware fails due to the fact that > > I can not even define a boot device - either this process is > > cryptic or it isn't documented and I'm too dull. A FreeDOS 1.1 > > prepared USB flashdrive isn't bootable as any other UEFI/non UEFI > > flashdrive: I can see the USB drive as being attached to PCI bus in > > the firmware menu, I also can define a symbolic name, but then I > > fail in defining the path to the loader as suggested in the example > > (fs0:\file\loader.efi or so). Any hint is welcome. > > > > This board has been used successfully over the past years and was > > equipted with a TPM module at connector 23 (TMP1 header) - I'm > > unfamiliar with those technologies and my first guess apart from a > > hardware failure was that the hardware could have been protected > > anyway like it is done via secure boot. Unplugging that TPM header > > doesn' change anything. > > > > Also the boot of XigmaNAS latest USB flashed image or any FreeBSD > > (11, 12 CURRENT) latest USB flashed image failed so far. > > > > Thanks for some help in adavnce, > > > > Don't know whether this will help, but a user posted to a forum > that he had this mainboard and couldn't boot any USB device no > matter what the tried. > > His final, working solution was: > > > Further investigation found NOTHING would boot from USB. I > cleared CMOS, entered setup and loaded Optimized Defaults, > rebooted, and VOILA! Case closed. > > *happy dance* > > > BTW he was using VGA. > Hello, thanks for the tip. I already tried and did a reset. It seems that one has to select first a propper boot option and there is the problem. Once a media has been inserted either as a bootable disk, bootable USB flash or (not tested) CDROM, the firmware offers at the option entry Boot the option new boot entry. I have first to give the option a name, then select from a (cryptic) list of definitions how the firmware addresses the controler/device/partition/bootimage et ceterum (Select File System) and then, the worst thing, Path for boot option. Leaving this empty renders any USB UEFI formated flash device unbootable. For FreeBSD booting, I had to issue "\efi\boot\bootx64.efi" - this worked also with a preinstalled Windows10 HOME hdd I "borrowed" to test, so I do not know the syntax of this option. Knowing this, I was able to boot Xubuntu 19.04 from USB flash, XigmaNAS 12.1 from USB flash, Windows10 HOME from a HDD and I was luckily able to boot one time XigmaNAS to install the software onto a SSD and even this worked - until a certain point where FreeBSD fails! Starting with FreeBSD 11.3-RELENG, FreeBSD 12.1-RELENG, FreeBSD 13-CURRENT, the box is bootimg and is then freezing at the point, where the console shows EFI framebuffer informations (see PR 209821, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209821). CURRENT (r355406) is freezing while showing some ATA device details. The AMI BIOS is at 2.10.1208 from 4th Nov 2012. There is a newer firmware available, but I can't install the firmware: while being able to UEFI USB flahes, it is impossible to boot FreeDOS 1.1 from an USB flash drive, even having properly set Legacy Boot ROM in PCIe/PnP/etc options in the firmware. I never have had such a confusing BIOS/firmware. Thanks, oh pgphpnmhnuQxT.pgp Description: OpenPGP digital signature
ffs_fhtovp: inode overflow?
Since ino64 went in, Coverity complains that the two "ino >= foo" comparisons in ffs_fhtovp() compare a 64-bit value to a 32-bit. Is this a problem in practice? Eric ___ 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: any scheduler/ipi/wakeup bug fixed in the last year?
I wonder if there have been any bug fixes in that area over the past year or so. Any help and pointers are welcome. Hi, A long time ago I fixed an issue for ARM: http://svnweb.freebsd.org/changeset/base/265913 I've always wondered why x86 does some fixed amount of idle spins before going to sleep. --HPS ___ 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: any scheduler/ipi/wakeup bug fixed in the last year?
On 11/12/2019 13:05, Konstantin Belousov wrote: > On Wed, Dec 11, 2019 at 12:48:36PM +0200, Andriy Gapon wrote: ... >> tdq_oldswitchcnt = 26, tdq_lowpri = 92 '\\', tdq_ipipending = 0 '\000', >> tdq_idx ... > What is the value of tdq_ipipending ? > See https://reviews.freebsd.org/D22758 It's zero, so it's probably a different issue. -- Andriy Gapon ___ 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: any scheduler/ipi/wakeup bug fixed in the last year?
On 11/12/2019 12:48, Andriy Gapon wrote: > So, if I am not confused, it appears like possibly a notification from a > waking > CPU to the woken CPU (CPU3) was never delivered. > Potentially, a problem with cpu_idle_wakeup() ? > > I wonder if there have been any bug fixes in that area over the past year or > so. > Any help and pointers are welcome. Hardware: CPU: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (2400.05-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406f1 Family=0x6 Model=0x4f Stepping=1 FreeBSD/SMP: 2 package(s) x 14 core(s) machdep.idle: acpi machdep.idle_available: spin, mwait, hlt, acpi machdep.idle_mwait: 1 -- Andriy Gapon ___ 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: any scheduler/ipi/wakeup bug fixed in the last year?
On Wed, Dec 11, 2019 at 12:48:36PM +0200, Andriy Gapon wrote:
>
> I am investigating a problem that originally looked like a ZFS I/O hang.
> But it quickly became obvious that the GEOM "up" queue was not being
> processed.
> (kgdb) p g_bio_run_up
> $54 = {bio_queue = {tqh_first = 0xf801d8627178, tqh_last =
> 0xf80134751658}, bio_queue_lock = {lock_object = {lo_name =
> 0x80ad11ab "bio queue", lo_flags = 16973824, lo_data = 0, lo_witness =
> 0x0}, mtx_lock = 0}, bio_queue_length = 19}
>
> The queue is unlocked and there are 19 bio-s on it.
> At the same time:
> (kgdb) tid 100125
> (kgdb) bt
> #0 sched_switch (td=0xf80111b23000, newtd=0xf801119d2000,
> flags=) at /usr/src/sys/kern/sched_ule.c:1997
> #1 0x80705405 in mi_switch (flags=, newtd=0x0) at
> /usr/src/sys/kern/kern_synch.c:436
> #2 0x8074844a in sleepq_wait (wchan=, pri=)
> at /usr/src/sys/kern/subr_sleepqueue.c:694
> #3 0x80704ed6 in _sleep (ident=0x81233d68 ,
> lock=0x810d72e0 , priority=,
> wmesg=0x80b417e4 "-", sbt=0, pr=0, flags=256) at
> /usr/src/sys/kern/kern_synch.c:216
> #4 0x8067713c in g_io_schedule_up (tp=) at
> /usr/src/sys/geom/geom_io.c:908
> #5 0x8067772d in g_up_procbody (arg=) at
> /usr/src/sys/geom/geom_kern.c:99
> #6 0x806c64c1 in fork_exit (callout=0x806776c0
> ,
> arg=0x0, frame=0xfe014cc87ac0) at /usr/src/sys/kern/kern_fork.c:1042
>
> The "g_up" thread is sleeping as if the queue was empty.
> The code in g_io_schedule_up() and g_io_deliver() is obviously correct with
> respect to synchronizing the queue access and wait/wakeup.
> So, there must be something deeper.
>
> I examined the struct thread and the related scheduling objects:
> (kgdb) p *td
> $57 = {td_lock = 0x810f3a00 , td_proc =
> 0xf801119cd590, td_plist = {tqe_next = 0xf80111b1f5e0, tqe_prev =
> 0xf80111b235f0}, td_runq = {tqe_next = 0x0,
> tqe_prev = 0x810f3bd8 }, td_slpq = {tqe_next = 0x0,
> tqe_prev = 0xf80100050280}, td_lockq = {tqe_next = 0x0, tqe_prev =
> 0xfe018e443998}, td_hash = {le_next = 0x0, le_prev = 0xfe014bab68e8},
> td_cpuset = 0xf80111b3a618, td_domain = {dr_policy = 0x810d78d8
> , dr_iterator = 0}, td_sel = 0x0, td_sleepqueue =
> 0xf80100050280, td_turnstile = 0xf801a7ed8a80, td_rlqe = 0x0,
> td_umtxq = 0xf80111b13e80, td_tid = 100125, td_sigqueue = {sq_signals =
> {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_ptrace =
> {__bits
> = {0, 0, 0, 0}}, sq_list = {tqh_first = 0x0,
> tqh_last = 0xf80111b230d8}, sq_proc = 0xf801119cd590, sq_flags =
> 1}, td_lend_user_pri = 255 '\377', td_flags = 4, td_inhibitors = 0, td_pflags
> =
> 2097152, td_dupfd = 0, td_sqqueue = 0, td_wchan = 0x0,
> td_wmesg = 0x0, td_owepreempt = 0 '\000', td_tsqueue = 0 '\000', td_locks =
> 0,
> td_rw_rlocks = 0, td_sx_slocks = 0, td_lk_slocks = 0, td_stopsched = 0,
> td_blocked = 0x0, td_lockname = 0x0, td_contested = {lh_first = 0x0},
> td_sleeplocks = 0x0, td_intr_nesting_level = 0, td_pinned = 0, td_ucred =
> 0xf80100082b00, td_limit = 0xf80100082a00, td_slptick = 0, td_blktick
> =
> 0, td_swvoltick = -2139537593, td_swinvoltick = -2139537706, td_cow = 0,
> td_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0,
> tv_usec
> = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0,
> ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0,
> ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 14113408,
> ru_nivcsw = 240828}, td_rux = {rux_runtime = 202213463115, rux_uticks = 0,
> rux_sticks = 10554, rux_iticks = 0, rux_uu = 0, rux_su = 36818497,
> rux_tu = 36818497}, td_incruntime = 46828278, td_runtime = 202260266673,
> td_pticks = 10557, td_sticks = 3, td_iticks = 0, td_uticks = 0, td_intrval =
> 0,
> td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_generation = 14354236,
> td_sigstk = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, td_xsig = 0,
> td_profil_addr = 0, td_profil_ticks = 0, td_name = "g_up", '\000' times>, td_fpop = 0x0, td_dbgflags = 0, td_si = {si_signo = 0, si_errno = 0,
> si_code = 0, si_pid = 0, si_uid = 0, si_status = 0, si_addr = 0x0,
> si_value
> = {sival_int = 0, sival_ptr = 0x0, sigval_int = 0, sigval_ptr = 0x0}, _reason
> =
> {_fault = {_trapno = 0}, _timer = {_timerid = 0, _overrun = 0},
> _mesgq = {_mqd = 0}, _poll = {_band = 0}, __spare__ = {__spare1__ = 0,
> __spare2__ = {0, 0, 0, 0, 0, 0, 0, td_ng_outbound = 0, td_osd =
> {osd_nslots
> = 0, osd_slots = 0x0, osd_next = {le_next = 0x0, le_prev = 0x0}},
> td_map_def_user = 0x0, td_dbg_forked = 0, td_vp_reserv = 0, td_no_sleeping =
> 0, td_su = 0x0, td_sleeptimo = 0, td_rtcgen = 0, td_sigmask = {__bits = {0, 0,
> 0, 0}}, td_rqindex = 23 '\027', td_base_pri = 92 '\\',
> td_priority = 92 '\\', td_pri_class = 3 '\003', td_user_pri = 120 'x',
> td_base_user_pri = 120 'x', td_rb_list = 0, td_rbp_list =
any scheduler/ipi/wakeup bug fixed in the last year?
I am investigating a problem that originally looked like a ZFS I/O hang.
But it quickly became obvious that the GEOM "up" queue was not being processed.
(kgdb) p g_bio_run_up
$54 = {bio_queue = {tqh_first = 0xf801d8627178, tqh_last =
0xf80134751658}, bio_queue_lock = {lock_object = {lo_name =
0x80ad11ab "bio queue", lo_flags = 16973824, lo_data = 0, lo_witness =
0x0}, mtx_lock = 0}, bio_queue_length = 19}
The queue is unlocked and there are 19 bio-s on it.
At the same time:
(kgdb) tid 100125
(kgdb) bt
#0 sched_switch (td=0xf80111b23000, newtd=0xf801119d2000,
flags=) at /usr/src/sys/kern/sched_ule.c:1997
#1 0x80705405 in mi_switch (flags=, newtd=0x0) at
/usr/src/sys/kern/kern_synch.c:436
#2 0x8074844a in sleepq_wait (wchan=, pri=)
at /usr/src/sys/kern/subr_sleepqueue.c:694
#3 0x80704ed6 in _sleep (ident=0x81233d68 ,
lock=0x810d72e0 , priority=,
wmesg=0x80b417e4 "-", sbt=0, pr=0, flags=256) at
/usr/src/sys/kern/kern_synch.c:216
#4 0x8067713c in g_io_schedule_up (tp=) at
/usr/src/sys/geom/geom_io.c:908
#5 0x8067772d in g_up_procbody (arg=) at
/usr/src/sys/geom/geom_kern.c:99
#6 0x806c64c1 in fork_exit (callout=0x806776c0 ,
arg=0x0, frame=0xfe014cc87ac0) at /usr/src/sys/kern/kern_fork.c:1042
The "g_up" thread is sleeping as if the queue was empty.
The code in g_io_schedule_up() and g_io_deliver() is obviously correct with
respect to synchronizing the queue access and wait/wakeup.
So, there must be something deeper.
I examined the struct thread and the related scheduling objects:
(kgdb) p *td
$57 = {td_lock = 0x810f3a00 , td_proc =
0xf801119cd590, td_plist = {tqe_next = 0xf80111b1f5e0, tqe_prev =
0xf80111b235f0}, td_runq = {tqe_next = 0x0,
tqe_prev = 0x810f3bd8 }, td_slpq = {tqe_next = 0x0,
tqe_prev = 0xf80100050280}, td_lockq = {tqe_next = 0x0, tqe_prev =
0xfe018e443998}, td_hash = {le_next = 0x0, le_prev = 0xfe014bab68e8},
td_cpuset = 0xf80111b3a618, td_domain = {dr_policy = 0x810d78d8
, dr_iterator = 0}, td_sel = 0x0, td_sleepqueue =
0xf80100050280, td_turnstile = 0xf801a7ed8a80, td_rlqe = 0x0,
td_umtxq = 0xf80111b13e80, td_tid = 100125, td_sigqueue = {sq_signals =
{__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_ptrace = {__bits
= {0, 0, 0, 0}}, sq_list = {tqh_first = 0x0,
tqh_last = 0xf80111b230d8}, sq_proc = 0xf801119cd590, sq_flags =
1}, td_lend_user_pri = 255 '\377', td_flags = 4, td_inhibitors = 0, td_pflags =
2097152, td_dupfd = 0, td_sqqueue = 0, td_wchan = 0x0,
td_wmesg = 0x0, td_owepreempt = 0 '\000', td_tsqueue = 0 '\000', td_locks = 0,
td_rw_rlocks = 0, td_sx_slocks = 0, td_lk_slocks = 0, td_stopsched = 0,
td_blocked = 0x0, td_lockname = 0x0, td_contested = {lh_first = 0x0},
td_sleeplocks = 0x0, td_intr_nesting_level = 0, td_pinned = 0, td_ucred =
0xf80100082b00, td_limit = 0xf80100082a00, td_slptick = 0, td_blktick =
0, td_swvoltick = -2139537593, td_swinvoltick = -2139537706, td_cow = 0,
td_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec
= 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0,
ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0,
ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 14113408,
ru_nivcsw = 240828}, td_rux = {rux_runtime = 202213463115, rux_uticks = 0,
rux_sticks = 10554, rux_iticks = 0, rux_uu = 0, rux_su = 36818497,
rux_tu = 36818497}, td_incruntime = 46828278, td_runtime = 202260266673,
td_pticks = 10557, td_sticks = 3, td_iticks = 0, td_uticks = 0, td_intrval = 0,
td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_generation = 14354236,
td_sigstk = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, td_xsig = 0,
td_profil_addr = 0, td_profil_ticks = 0, td_name = "g_up", '\000' , td_fpop = 0x0, td_dbgflags = 0, td_si = {si_signo = 0, si_errno = 0,
si_code = 0, si_pid = 0, si_uid = 0, si_status = 0, si_addr = 0x0, si_value
= {sival_int = 0, sival_ptr = 0x0, sigval_int = 0, sigval_ptr = 0x0}, _reason =
{_fault = {_trapno = 0}, _timer = {_timerid = 0, _overrun = 0},
_mesgq = {_mqd = 0}, _poll = {_band = 0}, __spare__ = {__spare1__ = 0,
__spare2__ = {0, 0, 0, 0, 0, 0, 0, td_ng_outbound = 0, td_osd = {osd_nslots
= 0, osd_slots = 0x0, osd_next = {le_next = 0x0, le_prev = 0x0}},
td_map_def_user = 0x0, td_dbg_forked = 0, td_vp_reserv = 0, td_no_sleeping =
0, td_su = 0x0, td_sleeptimo = 0, td_rtcgen = 0, td_sigmask = {__bits = {0, 0,
0, 0}}, td_rqindex = 23 '\027', td_base_pri = 92 '\\',
td_priority = 92 '\\', td_pri_class = 3 '\003', td_user_pri = 120 'x',
td_base_user_pri = 120 'x', td_rb_list = 0, td_rbp_list = 0, td_rb_inact = 0,
td_sa = {code = 0, callp = 0x0, args = {0 }, narg = 0},
td_pcb = 0xfe014cc87b80, td_state = TDS_RUNQ, td_uretoff = {tdu_retval =
{0, 0}, tdu_off = 0}, td_cowgen = 0, td_slpcallout = {c_links = {le = {le_next =
0x0, le_prev = 0x0}, sle
Re: Supermicro X9SCV-Q: no boot options to define
On Wed, 11 Dec 2019 08:23:59 +0100 "Hartmann, O." wrote: > Hello folks, > > my apology for polluting this list with a non-FreeBSD specific problem, > but since Supermicro is a veryy often used vendor in the FreeBSD > user/developer community I might find help here much fast. > > I got hands on onto an oldish Supermicro X9SCV-Q mainboard, equipted > with an older i5-25XXM CPU running at 2,5 GHz). The AMI BIOS has > version 2.10.1208 from 2012. > The board does initially a longer beep and the it sounds like two > or three very short beeps plus a last longer beep at a higher tune and > then the system ALWAYS jumps into the firmware/BIOS screen, no matter > whether I set a administrator password to protect the BIOS or not. > Apart from the suspect of damaged RAM (three beeps indicate RAM > problem above the first 64k block, two indicate PEI recovery or video > memory problems if I interpret the manual correctly). > > Sometimes the POST screen shows some message like "... in Recovery > State", due to the off-phased HDMI attached monitor, I do not see the > first characters. Maybe someone knows what that might indicate. > > I already have changed the memory banks and the memory seems to be > allright as the replacement memory has been checked thoroughly prior to > the test in another well running box and I also checked the memory on > another box with memtest tool without any suspicious indication. > > The attempt to flash the latest firmware fails due to the fact that I > can not even define a boot device - either this process is cryptic or > it isn't documented and I'm too dull. A FreeDOS 1.1 prepared USB > flashdrive isn't bootable as any other UEFI/non UEFI flashdrive: I can > see the USB drive as being attached to PCI bus in the firmware menu, I > also can define a symbolic name, but then I fail in defining the path > to the loader as suggested in the example (fs0:\file\loader.efi or so). > Any hint is welcome. > > This board has been used successfully over the past years and was > equipted with a TPM module at connector 23 (TMP1 header) - I'm > unfamiliar with those technologies and my first guess apart from a > hardware failure was that the hardware could have been protected anyway > like it is done via secure boot. Unplugging that TPM header doesn' > change anything. > > Also the boot of XigmaNAS latest USB flashed image or any FreeBSD (11, > 12 CURRENT) latest USB flashed image failed so far. > > Thanks for some help in adavnce, > Don't know whether this will help, but a user posted to a forum that he had this mainboard and couldn't boot any USB device no matter what the tried. His final, working solution was: Further investigation found NOTHING would boot from USB. I cleared CMOS, entered setup and loaded Optimized Defaults, rebooted, and VOILA! Case closed. *happy dance* BTW he was using VGA. -- Gary Jennejohn ___ 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"
