Re: support of PCIe NVME drives
On Thu, Apr 16, 2020 at 12:30 PM Miroslav Lachman <000.f...@quip.cz> wrote: > > Pete Wright wrote on 04/16/2020 20:23: > > > > > > On 4/16/20 11:12 AM, Miroslav Lachman wrote: > >> Kurt Jaeger wrote on 04/16/2020 20:07: > > > I would try booting via UEFI if you can. I just installed a laptop > > yesterday which has a nvme root device, it was detected by the 12-STABLE > > snapshot I used to boot from. no other modifications were necessary on > > my end. > > I changed BIOS settings to use UEFI boot method, booted 12.1 installer > ISO but without luck. Still no NVME disks :( > > You can see it on printscreen from iDRAC https://ibb.co/tPnymL7 > > Anything more I can test? Fair warning, I don't deal much with Dell, but it's curious that iDrac lists the device protocol as MI > Device Protocol: NVMe-MI1.0 MI or the Management Interface is defined by NVMe, but it isn't the same as a block interface. MI typically uses SMBUS and not PCIe to communicate with the device. So it's possible that the device is visible to iDrac via SMBUS but may not be on the PCIe bus for $reasons. Does iDrac have any tools to interact with the device via MI? --chuck ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Confused about i915kms on 12.1
On Sun, Oct 13, 2019 at 5:08 PM John Kennedy wrote:
...
> In 23.2.3.2 ("Upgrading Packages After a Major Version Upgrade") they say
> to do this (among other things):
>
> pkg-static upgrade -f
FWIW, I went back and did this but still seem to get the older kmod
> In any case, I'm glad we got you up and running.
Again, many thanks for your help.
--chuck
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Confused about i915kms on 12.1
Many thanks to Pete and John. See inline below On Sun, Oct 13, 2019 at 1:13 PM John Kennedy wrote: > > On Sun, Oct 13, 2019 at 12:35:41PM -0700, Chuck Tuffli wrote: > > I've been running 12.0-REL on my X1 Carbon 3rd Gen happily with xorg, > > but after installing 12.1-RC1, the laptop reboots when loading the > > i915kms driver. If I comment out the line in /etc/rc.conf: > > > > kld_list="/boot/modules/i915kms.ko" > > > > the laptop boots, albeit without graphics. The above comes from the > > 12.0R release notes, and I didn't see any updates to this in the 12.1 > > release notes. I've tried drm-kmod from both ports and packages with > > the same result. Did something change with 12.1? What should I check? > > TIA > > Not sure how your upgraded your box, but make sure that the driver is > compiled for the new kernel. KBI breakage can easily behave like that. I upgraded the box per the release announcement: freebsd-update upgrade -r 12.1-RC1 freebsd-update install with the prescribed reboots and installs. Afterwards, I did a pkg update and pkg upgrade. Note, I don't install anything from ports. > I won't be in front of a box with that setup until Monday, but from > memory, graphics/drm-kmod pulls in graphics/drm-fbsd12.0-kmod (at > least on my system with it's build-in Intel video card). > > If you do something like this, but substitute your .ko file for m4 > below, you should be able to validate the package it came from and the > kernel version it was targeted at: > > $ pkg which /usr/local/bin/*m4 > /usr/local/bin/gm4 was installed by package m4-1.4.18_1,1 > > $ pkg info m4 | grep -i version > Version: 1.4.18_1,1 > FreeBSD_version: 1201000 > > That 1201000 means that it was compiled for 12.1 in my case. $ pkg info drm-fbsd12.0-kmod-4.16.g20190814 | grep -i version Version: 4.16.g20190814 FreeBSD_version: 1200086 This version is for FreeBSD 12.0. > Have you overridden the default package location, leaving it aimed at 12.0? Nope > What do you mean by trying it from "ports"? How did you refresh that? The advice I received was 'you need to build drm-kmod from ports'. I don't typically have a ports tree, so I did: # portsnap fetch # portsnap extract # cd /usr/ports/graphics/drm-kmod # make && make install After doing the makes, my immediate thought was 'that finished too fast'. If, instead, I follow Pete's advice and run make package in /usr/ports/graphics/drm-fbsd12.0-kmod, a) make appears to do something and b) the resulting package allows my laptop to boot to a graphical desktop. And the FreeBSD_version looks correct: $ pkg info drm-fbsd12.0-kmod-4.16.g20190814 | grep -i version Version: 4.16.g20190814 FreeBSD_version: 1201000 This version is for FreeBSD 12.0. I did go back and verify that a pkg install drm-kmod appears to install the same (older) i915kms.ko as pkg install drm-fbsd12.0-kmod. Out of curiosity, is the new world order that I'll always need to compile drm-kmod from ports, or did I hit a window where packages hadn't quite caught up to ports? --chuck ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Confused about i915kms on 12.1
I've been running 12.0-REL on my X1 Carbon 3rd Gen happily with xorg, but after installing 12.1-RC1, the laptop reboots when loading the i915kms driver. If I comment out the line in /etc/rc.conf: kld_list="/boot/modules/i915kms.ko" the laptop boots, albeit without graphics. The above comes from the 12.0R release notes, and I didn't see any updates to this in the 12.1 release notes. I've tried drm-kmod from both ports and packages with the same result. Did something change with 12.1? What should I check? TIA --chuck ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: NVME aborting outstanding i/o
On Thu, Apr 4, 2019 at 4:27 AM Patrick M. Hausen wrote: > > Hi, > > > Am 04.04.2019 um 10:37 schrieb Patrick M. Hausen : > > But: > > > > root@freenas01[~]# sysctl hw.nvme.per_cpu_io_queues > > sysctl: unknown oid 'hw.nvme.per_cpu_io_queues' > > root@freenas01[~]# sysctl hw.nvme.min_cpus_per_ioq > > sysctl: unknown oid 'hw.nvme.min_cpus_per_ioq' > > root@freenas01[~]# sysctl hw.nvme.force_intx > > sysctl: unknown oid 'hw.nvme.force_intx' > > Looks like these can be set via loader.conf and reboot although > they are not visible in the running system. Even when set they > are not visible afterwards ... > > hw.nvme.per_cpu_io_queues=0 > > seems to cure the NVME errors. I’m still curious about the root > problem here, bit at least I can now continue to use the machines > for some real loads. Out of curiosity, what device is this? I.e. nvmecontrol identify nvme7 --chuck ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
sporadic core dumps in 12.0-RELEASE
Hi
When running 12.0-RELEASE in bhyve, nvmecontrol will core dump sporadically
in rtld. This is repeatable, but doesn't happen every time. Peeking at
rlock_acquire(), the function checks for a NULL lockstate and then
dereferences the lock. The backtrace (below) suggests the lock is NULL but
the lockstate pointer is not. Does anyone know if this is expected, weird,
etc.?
root@freebsd:~ # uname -a
FreeBSD freebsd 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC amd64
root@freebsd:~ # /usr/libexec/gdb -q /sbin/nvmecontrol nvmecontrol.core
Core was generated by `nvmecontrol identify nvme0'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.7...Reading symbols from
/usr/lib/debug//lib/libc.so.7.debug...done.
done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...Reading symbols from
/usr/lib/debug//libexec/ld-e
lf.so.1.debug...done.
done.
Loaded symbols for /libexec/ld-elf.so.1
#0 rlock_acquire (lock=0x0, lockstate=0x7fffd9b8)
at /usr/src/libexec/rtld-elf/rtld_lock.c:203
203 /usr/src/libexec/rtld-elf/rtld_lock.c: No such file or directory.
in /usr/src/libexec/rtld-elf/rtld_lock.c
(gdb) bt
#0 rlock_acquire (lock=0x0, lockstate=0x7fffd9b8)
at /usr/src/libexec/rtld-elf/rtld_lock.c:203
#1 0x00080021a2fd in _rtld_bind (obj=0x800236000, reloff=528)
at /usr/src/libexec/rtld-elf/rtld.c:790
#2 0x00080021704d in _rtld_bind_start ()
at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:121
#3 0x002087de in identify_ctrlr (argc=2, argv=0x7fffebd0)
at /usr/src/sbin/nvmecontrol/identify.c:183
#4 0x002086e0 in identify (argc=2, argv=0x7fffebd0)
at /usr/src/sbin/nvmecontrol/identify.c:292
#5 0x00207935 in main (argc=, argv=)
at /usr/src/sbin/nvmecontrol/nvmecontrol.c:89
#6 0x0020711b in _start (ap=, cleanup=)
at /usr/src/lib/csu/amd64/crt1.c:76
#7 0x000800236000 in ?? ()
#8 0x in ?? ()
Current language: auto; currently minimal
(gdb) p *lockstate
$1 = {lockstate = 0, env = 0x7fffd9c0}
(gdb)
--chuck
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: CAM Target Layer and Linux (continued)
On Tue, Oct 2, 2012 at 3:03 AM, Nikolay Denev nde...@gmail.com wrote: On Sep 27, 2012, at 6:33 PM, Nikolay Denev nde...@gmail.com wrote: Hi All, With the help of Chuck Tuffli, I'm now able to use CTL to export a zvol over FC to a Linux host: LUN Backend Size (Blocks) BS Serial NumberDevice ID 0 block4185915392 512 FBSDZFS001 ORA_ASM_01 lun_type=0 num_threads=14 file=/dev/zvol/tank/oracle_asm_01 1 block4185915392 512 FBSDZFS002 ORA_ASM_02 lun_type=0 num_threads=14 file=/dev/zvol/tank/oracle_asm_02 2 block4185915392 512 FBSDZFS003 ORA_ASM_03 lun_type=0 num_threads=14 file=/dev/zvol/tank/oracle_asm_03 3 block4185915392 512 FBSDZFS004 ORA_ASM_04 lun_type=0 num_threads=14 file=/dev/zvol/tank/oracle_asm_04 Then we ran some tests using Oracle's ORION benchmark tool from the Linux host. We ran one test which passed successfully, then I've just disabled zfs prefetch - vfs.zfs.prefetch_disable=1 and rerun the test, which failed due to this error. On the FreeBSD side: (0:3:0:1): READ(10). CDB: 28 0 84 f9 58 0 0 4 0 0 (0:3:0:1): Tag: 0x116220, Type: 1 (0:3:0:1): CTL Status: SCSI Error (0:3:0:1): SCSI Status: Check Condition (0:3:0:1): SCSI sense: NOT READY asc:4b,0 (Data phase error) ... After a whole day of orion tests without problems, we started an Oracle ASM instance from the Linux host and again got an error, this time it was WRITE error : (0:3:0:3): WRITE(10). CDB: 2a 0 1 5b 10 0 0 4 0 0 (0:3:0:3): Tag: 0x110940, Type: 1 (0:3:0:3): CTL Status: SCSI Error (0:3:0:3): SCSI Status: Check Condition (0:3:0:3): SCSI sense: NOT READY asc:4b,0 (Data phase error) I've tried to track down this Data phase error in the CTL code and it looks like it is something related to the isp(4) driver: This would have been my first guess if there had been something in the logs from isp, but since there wasn't, it's hard to tell. I been running orion for ~3hrs now with a different FC driver + an analyzer but haven't seen this problem. Would it be possible to stick some prints in default clause of the ctlfedone() to confirm if this is front or back end problem? Especially interesting would be the value of done_ccb-ccb_h.status. ---chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CAM Target Layer, Linux and camcontrol readcap
On Wed, Sep 26, 2012 at 1:33 AM, Nikolay Denev nde...@gmail.com wrote: Hi, I'm running RELENG_9 and I'm trying to play with CTL. Initially I've setup an isp(4) interface in TARGET mode and tried to export a LUN to a directly connected Linux RHEL host, but for some reason that failed with the block backend (ramdisk was exported properly) : This is how I export the volume : zfs create -V1000G tank/oracle ctladm create -b block -o file=/dev/zvol/tank/oracle -S ZFSSERIAL001 -d ZFSLUN001 ctladm port -o on ctladm realsync off This is similar to what I do, but you might try turning off realsync before turning the port on and only turning on the FC ports. I.e. ctladm realsync off ctladm port -o on -t fc If that doesn't help, it would be interesting to see if something is stuck via ctladm dumpooa ---chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CAM Target Layer, Linux and camcontrol readcap
On Wed, Sep 26, 2012 at 9:02 AM, Nikolay Denev nde...@gmail.com wrote: ... I've did ctladm dumooa : Dumping OOA queues LUN 0 tag 0x000d RTR: SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 (91807313 ms) LUN 0 tag 0x0011 BLOCKED: READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 (35411180 ms) LUN 0 tag 0x0012 BLOCKED: READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 (35228663 ms) LUN 0 tag 0x0013 BLOCKED: START STOP UNIT. CDB: 1b 0 0 0 1 0 (34721150 ms) OOA queues dump done And if I'm reading this right the other commands blocked because of the sync cache. I will try now to set realsync to off before enabling the ports and retest. Yup, this is the symptom you will see unless realsync is off (ie. GEOM is barfing on the sync and this blocks subsequent commands from completing). ---chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CAM Target Layer, Linux and camcontrol readcap
On Wed, Sep 26, 2012 at 9:54 AM, Nikolay Denev nde...@gmail.com wrote: On 26.09.2012, at 19:08, Chuck Tuffli ctuf...@gmail.com wrote: ... Yup, this is the symptom you will see unless realsync is off (ie. GEOM is barfing on the sync and this blocks subsequent commands from completing). ---chuck Any idea if the machine can recover from this state without rebooting? I haven't found a way other than rebooting. In fact, if you have INVARIANTS enabled in your kernel, you will hit an assert in GEOM and panic. ---chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD and IPMI how-to (was Re: su problem)
On Thu, Jun 14, 2012 at 6:27 PM, Matthew X. Economou xenop...@irtnog.org wrote: ... Would some kind soul point me to a howto for configuring IPMI on FreeBSD? I have a Dell PowerEdge 840 that supports IPMI, but I have no idea how to set it up - either in the BIOS or in FreeBSD. I've messed around with ipmitools a little, but I haven't gotten it to work. We have HP boxes here with IPMI (mostly v1.5), and by and large, there isn't much FreeBSD configuration. The set of things I do for serial over LAN are the same as for a regular serial console: 1) create /boot.config with the line -D -S115200 2) create /boot/loader.conf with the lines boot_multicons=YES comconsole_speed=115200 console=comconsole,vidconsole 3) change /etc/ttys to allow a login over the console. something similar to ttyu0 /usr/libexec/getty std.115200 vt100 on secure The rest of the configuration is in the BIOS and tends to be vendor specific. Once this is configured, you can use something like ipmitool to control power (chassis power on, chassis power reset, ...) and get a serial console (sol activate). HTH. ---chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Two build problems -- make memstick and make release with -DWITHOUT_CLANG
On Thu, May 10, 2012 at 12:39 PM, Jeff Kletsky jeff+free...@wagsky.com wrote: I'm trying to do bisection to locate when a specific bug appeared and can replicate the issue when I boot from a memstick and use the LiveCD option. This keeps any questions of upgrade or install out of the picture. ... It looks like that last ln -fs creates a loop, which eventually results in tar output of: I've run into this before but assumed it was due to building outside of /usr/src For me, the one reliable way of building the memstick + iso has been env MAKEOBJDIRPREFIX=../obj make DISTDIR=../R release HTH ---chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Possible to build 9-stable kernel on 8.2?
On Wed, Nov 16, 2011 at 1:34 AM, Dimitry Andric d...@freebsd.org wrote: On 2011-11-16 01:29, Glen Barber wrote: On Tue, Nov 15, 2011 at 11:45:02AM -0800, Chuck Tuffli wrote: ... ld:/usr/home/ctuffli/dev/releng_9/src/sys/conf/ldscript.amd64:9: syntax error *** Error code 1 You'll need to do 'buildworld' first. Actually, doing make kernel-toolchain is enough. This builds just the required tools, e.g. binutils, gcc and so on. Perfect! This is the gem I needed. Thanks to all for the help. ---chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Possible to build 9-stable kernel on 8.2?
Is it possible to do a buildkernel of 9-stable (r227536) on a stock 8.2 system? Most of it seems to work, but the linker fails towards the end with ... MAKE=make sh /usr/home/ctuffli/dev/releng_9/src/sys/conf/newvers.sh GENERIC /usr/local/bin/svnversion cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/home/ctuffli/dev/releng_9/src/sys -I/usr/home/ctuffli/dev/releng_9/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug ld:/usr/home/ctuffli/dev/releng_9/src/sys/conf/ldscript.amd64:9: syntax error *** Error code 1 Stop in /usr/home/ctuffli/dev/releng_9/obj/usr/home/ctuffli/dev/releng_9/src/sys/GENERIC. *** Error code 1 Stop in /usr/home/ctuffli/dev/releng_9/src. *** Error code 1 Stop in /usr/home/ctuffli/dev/releng_9/src. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
