Re: head -r355027 context, poudiere jail constructions with the likes of -a arm64.aarch64 -x : awk: can't open file /sys/param.h
[In part this note shows that the issue is not specific to
cross builds: -a arm64.aarch64 is not essential. But it
also shows just where the /sys/param.h comes from.]
On 2019-Nov-24, at 15:22, Mark Millard wrote:
> On 2019-Nov-24, at 15:11, Ben Woods wrote:
>
>> On Sun, 24 Nov 2019 at 1:27 pm, Mark Millard wrote:
>> My poudiere jail constructions with the likes of -a arm64.aarch64 -x are
>> all getting:
>>
>> awk: can't open file /sys/param.h
>> source line number 1
>>
>> Hi Mark,
>>
>> I have been getting this same error on amd64 for some time when I use the
>> command below.
>> # poudriere jail -j 13amd64 -u -m src=/usr/src
>>
>> Any ideas what it could be?
>
> Not so far. Good to know that cross-building is not part of the required
> context.
>
> I've yet to find a place that might be involved that mixes awk use with an
> expression
> generating a file path that could generate /sys/param.h as the path.
>
> If this was happening in my prior -r352341 context, I did not notice it. I
> jumped
> from there to -r355027 . So I can not effectively narrow the range for when it
> started based on my activity.
I've got evidence of what is reporting the /sys/param.h path:
+ [ -n '' ]
+ return 0
+ build_native_xtools
+ [ 0 -eq 1 ]
+ return 0
+ awk '/^\#define[[:blank:]]__FreeBSD_version/ {print $3}'
/usr/local/poudriere/jails/testBugzilla215561/usr/include/sys/param.h
+ setvar version_extra 1300061
+ [ -r /usr/src/sys/conf/newvers.sh ]
+ update_version 1300061
+ local 'version_extra=1300061'
+ grep '^[RB][A-Z]*=' /usr/src/sys/conf/newvers.sh
+ eval 'REVISION="13.0"' 'BRANCH=${BRANCH_OVERRIDE:-CURRENT}'
'RELEASE="${REVISION}-${BRANCH}"' 'RELDATE=$(awk'
$'\'/__FreeBSD_version.*propagated' to newvers/ {print $'$3}\''
'${PARAMFILE:-${SYSDIR}/sys/param.h})'
+ awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' /sys/param.h
awk: can't open file /sys/param.h
source line number 1
So it appears that:
${PARAMFILE:-${SYSDIR}/sys/param.h}
became just:
/sys/param.h
suggesting that both PARAMFILE aned SYSDIR were empty/undefined.
But looking around shows that SYSDIR being empty/undefined can
lead to PARAMFILE being /sys/param.h directly.
A grep shows for PARAMFILE :
/usr/src/include/Makefile: env NEWVERS_SH=${NEWVERS_SH}
PARAMFILE=${PARAM_H} SYSDIR=${SYSDIR} \
/usr/src/sys/conf/newvers.sh:RELDATE=$(awk '/__FreeBSD_version.*propagated to
newvers/ {print $3}' ${PARAMFILE:-${SYSDIR}/sys/param.h})
and for PARAM_H :
/usr/src/include/Makefile:PARAM_H= ${SYSDIR}/sys/param.h
/usr/src/include/Makefile:osreldate.h: ${NEWVERS_SH} ${PARAM_H}
${MK_OSRELDATE_SH}
/usr/src/include/Makefile: env NEWVERS_SH=${NEWVERS_SH}
PARAMFILE=${PARAM_H} SYSDIR=${SYSDIR} \
I got the message for the above from doing:
poudriere -x jail -c -m src=/usr/src -J 32 -v head@355027 -j testBugzilla215561
(with an appropriate env MAKEOBJDIRPREFIX=. . . for my
environment). This was as part of seeing if an old
bugzilla report can be closed. (It can be.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
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: r355494 buildworld [libprocstat.o] Error code 1 [lib/libprocstat__L] Error code 2
Ignore my previous e-mail. I just saw, the 'SVN r355491 breaks libprocstat' thread. (Forgot to check my 'current' e-mail folder, to which I recently began filtering e-mail. Apologies for the noise.) ___ 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: r355494 buildworld [libprocstat.o] Error code 1 [lib/libprocstat__L] Error code 2
On Sat, 7 Dec 2019 20:05-, Graham Perrin wrote:
> --- lib/libprocstat__L ---
> /usr/src/lib/libprocstat/libprocstat.c:620:29: error: no member named 'next'
> in 'struct vm_map_entry'
> for (entryp = map->header.next;
> ~~~ ^
> /usr/src/lib/libprocstat/libprocstat.c:622:24: error: no member named 'next'
> in 'struct vm_map_entry'
> entryp = vmentry.next) {
> ~~~ ^
Try r355506.
--
Trond.
___
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: SVN r355491 breaks libprocstat
On Sat, 7 Dec 2019 20:25+0100, Trond Endrestøl wrote:
> On Sat, 7 Dec 2019 12:57-0500, Michael Butler wrote:
>
> > This member removal has other consequences. As follows ..
> >
> > --- lib/libprocstat__L ---
> > Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/smbfs.o
> > --- libprocstat.o ---
> > /usr/src/lib/libprocstat/libprocstat.c:620:29: error: no member named
> > 'next' in 'struct vm_map_entry'
> > for (entryp = map->header.next;
> > ~~~ ^
> > /usr/src/lib/libprocstat/libprocstat.c:622:24: error: no member named
> > 'next' in 'struct vm_map_entry'
> > entryp = vmentry.next) {
> > ~~~ ^
> > 2 errors generated.
>
> Now we seem to be missing the prototypes:
>
> --- libprocstat.o ---
>
>
>
>
> /usr/src/lib/libprocstat/libprocstat.c:620:17: error: implicit declaration of
> function 'vm_map_entry_first' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]
>
>
> for (entryp = vm_map_entry_first(map);
>
>
>
>
> ^
>
>
>
>
> /usr/src/lib/libprocstat/libprocstat.c:620:15: error: incompatible
> integer to pointer conversion assigning to 'vm_map_entry_t' (aka
> 'struct vm_map_entry *') from 'int' [-Werror,-Wint-conversion]
>
>
> for (entryp = vm_map_entry_first(map);
>
>
>
>
> ^ ~~~
>
>
>
>
> /usr/src/lib/libprocstat/libprocstat.c:622:16: error: implicit declaration of
> function 'vm_map_entry_succ' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]
>
>
> entryp = vm_map_entry_succ(&vmentry)) {
>
>
>
>
> ^
>
>
>
>
> /usr/src/lib/libprocstat/libprocstat.c:622:16: note: did you mean
> 'vm_map_entry_first'?
>
>
>
> /usr/src/lib/libprocstat/libprocstat.c:620:17: note: 'vm_map_entry_first'
> declared here
>
>
>
>
> I'm at r355504.
Now at r355506, and my laptop is building the kernels, one at a time.
--
Trond.
___
freebsd-current@freebsd.org mailing list
https://l
r355494 buildworld [libprocstat.o] Error code 1 [lib/libprocstat__L] Error code 2
--- _libinstall --- sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libmlx5.a /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/ sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 -S libmlx5.so.1 /usr/obj/usr/src/amd64.amd64/tmp/lib/ sh /usr/src/tools/install.sh -o root -g wheel -m 444 libmlx5.so.1.debug /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/ sh /usr/src/tools/install.sh -l rs -o root -g wheel -m 755 /usr/obj/usr/src/amd64.amd64/tmp/lib/libmlx5.so.1 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libmlx5.so --- lib/libprocstat__L --- ===> lib/libprocstat (obj,all,install) --- .depend --- echo libprocstat.so.1.full: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libelf.a /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libkvm.a /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libutil.a >> .depend --- zfs/zfs.o --- --- secure/lib/libcrypto__L --- --- ct_sct_ctx.o --- cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -I/usr/src/crypto/openssl -I/usr/src/crypto/openssl/crypto/include -I/usr/src/crypto/openssl/include -DL_ENDIAN -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/etc/ssl\"" -DENGINESDIR="\"/usr/lib/engines\"" -DNDEBUG -I/usr/src/crypto/openssl/crypto -I/usr/src/crypto/openssl/crypto/ec/curve448 -I/usr/src/crypto/openssl/crypto/ec/curve448/arch_32 -I/usr/src/crypto/openssl/crypto/modes -I/usr/obj/usr/src/amd64.amd64/secure/lib/libcrypto -g -MD -MF.depend.ct_sct_ctx.o -MTct_sct_ctx.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/crypto/openssl/crypto/ct/ct_sct_ctx.c -o ct_sct_ctx.o --- lib/libprocstat__L --- --- zfs.o --- cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -I/usr/src/sys/cddl/compat/opensolaris -I/usr/src/cddl/compat/opensolaris/include -I/usr/src/cddl/compat/opensolaris/lib/libumem -I/usr/src/cddl/contrib/opensolaris/lib/libzpool/common -I/usr/src/sys/cddl/contrib/opensolaris/common/zfs -I/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/usr/src/sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/contrib/opensolaris/head -I/usr/src/lib/libprocstat -DNEED_SOLARIS_BOOLEAN -g -MD -MF.depend.zfs.o -MTzfs.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/lib/libprocstat/zfs.c -o zfs.o --- secure/lib/libcrypto__L --- --- ct_vfy.o --- cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -I/usr/src/crypto/openssl -I/usr/src/crypto/openssl/crypto/include -I/usr/src/crypto/openssl/include -DL_ENDIAN -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/etc/ssl\"" -DENGINESDIR="\"/usr/lib/engines\"" -DNDEBUG -I/usr/src/crypto/openssl/crypto -I/usr/src/crypto/openssl/crypto/ec/curve448 -I/usr/src/crypto/openssl/crypto/ec/curve448/arch_32 -I/usr/src/crypto/openssl/crypto/modes -I/usr/obj/usr/src/amd64.amd64/secure/lib/libcrypto -g -MD -MF.depend.ct_vfy.o -MTct_vfy.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/crypto/openssl/crypto/ct/ct_vfy.c -o ct_vfy.o --- lib/libprocstat__L --- --- cd9660.o --- cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -I. -I/usr/src/lib/libprocstat -D_KVM_VNODE -DLIBPROCSTAT_ZF
Re: SVN r355491 breaks libprocstat
On Sat, 7 Dec 2019 12:57-0500, Michael Butler wrote:
> This member removal has other consequences. As follows ..
>
> --- lib/libprocstat__L ---
> Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/smbfs.o
> --- libprocstat.o ---
> /usr/src/lib/libprocstat/libprocstat.c:620:29: error: no member named
> 'next' in 'struct vm_map_entry'
> for (entryp = map->header.next;
> ~~~ ^
> /usr/src/lib/libprocstat/libprocstat.c:622:24: error: no member named
> 'next' in 'struct vm_map_entry'
> entryp = vmentry.next) {
> ~~~ ^
> 2 errors generated.
Now we seem to be missing the prototypes:
--- libprocstat.o ---
/usr/src/lib/libprocstat/libprocstat.c:620:17: error: implicit declaration of
function 'vm_map_entry_first' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
for (entryp = vm_map_entry_first(map);
^
/usr/src/lib/libprocstat/libprocstat.c:620:15: error: incompatible
integer to pointer conversion assigning to 'vm_map_entry_t' (aka
'struct vm_map_entry *') from 'int' [-Werror,-Wint-conversion]
for (entryp = vm_map_entry_first(map);
^ ~~~
/usr/src/lib/libprocstat/libprocstat.c:622:16: error: implicit declaration of
function 'vm_map_entry_succ' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
entryp = vm_map_entry_succ(&vmentry)) {
^
/usr/src/lib/libprocstat/libprocstat.c:622:16: note: did you mean
'vm_map_entry_first'?
/usr/src/lib/libprocstat/libprocstat.c:620:17: note: 'vm_map_entry_first'
declared here
I'm at r355504.
--
Trond.
___
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"
SVN r355491 breaks libprocstat
This member removal has other consequences. As follows ..
--- lib/libprocstat__L ---
Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/smbfs.o
--- libprocstat.o ---
/usr/src/lib/libprocstat/libprocstat.c:620:29: error: no member named
'next' in 'struct vm_map_entry'
for (entryp = map->header.next;
~~~ ^
/usr/src/lib/libprocstat/libprocstat.c:622:24: error: no member named
'next' in 'struct vm_map_entry'
entryp = vmentry.next) {
~~~ ^
2 errors generated.
imb
___
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: CAM breaks USB [was Re: USB causing boot to hang]
Hi Bob, On 06.12.2019 23:57, bob prohaska wrote: > For what it's worth, there does seem to be something amiss with USB. > > An RPI2 at r355446 is having difficulty finding its USB devices > on a hands-off reboot. The problem wasn't apparent until this most > recent upgrade. Here's the console output: > > Trying to mount root from ufs:/dev/ufs/rootfs [rw]... > Warning: no time-of-day clock registered, system time will not be set > accurately > uhub0: 1 port with 1 removable, self powered > Setting hostuuid: 95acec23-6e2c-11e7-8cb9-b827eb1a5a4b. > Setting hostid: 0x6aebd8b6. > swapon: /dev/da0b: No such file or directory > Starting file system checks: > /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/ufs/rootfs: clugen0.2: at usbus0 ... > Warning! Some of the devices might not be available; retrying > Waiting 30s for the root mount holders: usbus0 CAM ... > The machine seems able to boot hands-off a kernel from r333740, > so I don't think it's hardware. > > /boot/loader.conf contains > bob@www:~ % more /boot/loader.conf > kern.cam.boot_delay="2" > vm.pageout_oom_seq="2048" > bob@www:~ % > > Booting direct to single-user, running fsck and exiting the shell > brought multi-user operation. Your situation seem to be different from the first one. As I understand, you have root file system on SD card, while some other file systems and swap on a USB stick. The problem in your case is that root mount wait for UFS waits only for root file system to appear, rather then all of them. There is an rc.d scripts that should wait for other devices via calling root_hold_wait function, and you may see in logs that they try, but I guess something is not right there. As a workaround for the rc.d problem you may set tunable vfs.root_mount_always_wait=1 . After that I guess you may be even able to remove kern.cam.boot_delay tunable to make boot even faster then before, while still remain reliable if your USB stick behaves properly. I think we should either enable vfs.root_mount_always_wait=1 by default, or really fix the rc.d scripts to properly wait when needed. > Still, It appears that recognition > of an FTDI FT232 usb-serial adapter is impaired as well. It had to > be unplugged and replugged after booting to be recognized. I don't know what is the problem here, but I guess that vfs.root_mount_always_wait may help here too, if we assume that the problem is that some app is trying to open the serial adapter before the USB scan is complete, that previously was workarounded by delay caused by kern.cam.boot_delay setting. -- Alexander Motin ___ 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"
cam subsystem vs usb
Hi, I use a 5-hdd bunch connected via USB3 in JBOD mode; that 5 hdd builds a zpool and are listed during boot process as da0 to da4. Here is my /boot/loader.conf file: .../... hw.snd.default_device=2 dev.pcm.1.play.vchans=2 fuse_load="YES" kern.cam.boot_delay=12000 kern.vty=vt sysctl net.local.stream.recvspace=65536 cpu_microcode_load="YES" cpu_microcode_name="/boot/firmware/intel-ucode.bin" sysctl net.local.stream.recvspace=65536 sysctl net.local.stream.sendspace=65536 .../... Under FBSD12.0, the boot process got fine. Since recent upgrade to 12.1, the first "cold" boot shows: .../... Dec 7 10:17:25 H97M-G43 kernel: Trying to mount root from ufs:/dev/ada1p2 [rw]... Dec 7 10:17:25 H97M-G43 kernel: da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 Dec 7 10:17:25 H97M-G43 kernel: da0: Fixed Direct Access SPC-4 SCSI device Dec 7 10:17:25 H97M-G43 kernel: da0: Serial Number 2019083100443 Dec 7 10:17:25 H97M-G43 kernel: da0: 400.000MB/s transfers Dec 7 10:17:25 H97M-G43 kernel: da0: 953869MB (1953525168 512 byte sectors) Dec 7 10:17:25 H97M-G43 kernel: da0: quirks=0x2 Dec 7 10:17:25 H97M-G43 kernel: da1 at umass-sim0 bus 0 scbus3 target 0 lun 1 Dec 7 10:17:25 H97M-G43 kernel: da1: Fixed Direct Access SPC-4 SCSI device Dec 7 10:17:25 H97M-G43 kernel: da1: Serial Number 2019083100443 Dec 7 10:17:25 H97M-G43 kernel: da1: 400.000MB/s transfers Dec 7 10:17:25 H97M-G43 kernel: da1: 953869MB (1953525168 512 byte sectors) Dec 7 10:17:25 H97M-G43 kernel: da1: quirks=0x2 Dec 7 10:17:25 H97M-G43 kernel: da2 at umass-sim0 bus 0 scbus3 target 0 lun 2 Dec 7 10:17:25 H97M-G43 kernel: da2: Fixed Direct Access SPC-4 SCSI device Dec 7 10:17:25 H97M-G43 kernel: da2: Serial Number 2019083100443 Dec 7 10:17:25 H97M-G43 kernel: da2: 400.000MB/s transfers Dec 7 10:17:25 H97M-G43 kernel: da2: 953869MB (1953525168 512 byte sectors) Dec 7 10:17:25 H97M-G43 kernel: da2: quirks=0x2 Dec 7 10:17:25 H97M-G43 kernel: da3 at umass-sim0 bus 0 scbus3 target 0 lun 3 Dec 7 10:17:25 H97M-G43 kernel: da3: Fixed Direct Access SPC-4 SCSI device Dec 7 10:17:25 H97M-G43 kernel: da3: Serial Number 2019083100443 Dec 7 10:17:25 H97M-G43 kernel: da3: 400.000MB/s transfers Dec 7 10:17:25 H97M-G43 kernel: da3: 953869MB (1953525168 512 byte sectors) Dec 7 10:17:25 H97M-G43 kernel: da3: quirks=0x2 Dec 7 10:17:25 H97M-G43 kernel: da4 at umass-sim0 bus 0 scbus3 target 0 lun 4 Dec 7 10:17:25 H97M-G43 kernel: da4: Fixed Direct Access SPC-4 SCSI device Dec 7 10:17:25 H97M-G43 kernel: da4: Serial Number 2019083100443 Dec 7 10:17:25 H97M-G43 kernel: da4: 400.000MB/s transfers Dec 7 10:17:25 H97M-G43 kernel: da4: 953869MB (1953525168 512 byte sectors) Dec 7 10:17:25 H97M-G43 kernel: da4: quirks=0x2 Dec 7 10:17:25 H97M-G43 kernel: (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 74 70 6d 71 00 00 04 00 Dec 7 10:17:25 H97M-G43 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error Dec 7 10:17:25 H97M-G43 kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition Dec 7 10:17:25 H97M-G43 kernel: (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:4,1(Logical unit is in process of becoming ready) Dec 7 10:17:25 H97M-G43 kernel: (da0:umass-sim0:0:0:0): Polling device for readiness Dec 7 10:17:25 H97M-G43 kernel: ZFS filesystem version: 5Dec 7 10:17:25 H97M-G43 kernel: ZFS storage pool version: features support (5000) .../... The readiness time takes about 10 seconds. Curiously, further "warm" reboots are going fine, without any readiness sequence. Could this behaviour be related to the cam_system/usb_system problem leading to hang the boot process, recently reported? Hope this be usefull for debugging the cam subsystem. Roger Genre ___ 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: CAM breaks USB [was Re: USB causing boot to hang]
On Fri, 6 Dec 2019 18:15:32 -0500 Alexander Motin wrote: > On 06.12.2019 17:52, Steve Kargl wrote: [snip] > > For the record add kern.cam.boot_delay to /boot/loader.conf with the > > values 0, 1, and "1" did not allow the system to boot. > > boot_delay value is measured in milliseconds, so values of 0 and 1 mean > close to nothing. You may try to set it to some 1, if you really > want to try to delay CAM devices attach, but I doubt. > This isn't aimed at anyone, but it seems like adding " in msec" to the end of the description string would save users a lot of hassle. -- 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"
