cannot access Areca controller after OS upgrade to 10.4-RELEASE
Hello, We have machine with Areca controller: arcmsr0: > mem 0xde00-0xde0f,0xde11-0xde11,0xde10-0xde10 irq 17 at device 0.0 on pci2 Areca RAID adapter0: ARC-1200 F/W version V1.50 2012-01-04 smartmontools worked on device arcmsr0 for years, but after system upgrade from 10.3 to 10.4-RELEASE smartmontools does not return results, it hangs indefinitely. Smartmontools packages are built on our Poudriere with OS version 10.4 so it should match. We use smartctl with this params: # smartctl -A -d areca,2 /dev/arcmsr0 smartctl 6.5 2016-05-07 r4318 [FreeBSD 10.4-RELEASE amd64] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org Nothing more is displayed. Pressing Ctrl+T gives me load: 3.01 cmd: smartctl 25305 [running] 71.45r 3.09u 68.25s 100% 4204k load: 3.01 cmd: smartctl 25305 [running] 74.96r 3.26u 71.58s 100% 4204k I tried to run areca-cli but it also shows nothing. OS is running from RAID device da0 fine, but controller info is inaccessible. Was there some changes between 10.3 / 10.4? What can I do to debug this problem? Kind regards Miroslav Lachman ___ 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: automount usb msdosfs no partition table
2017-10-09 0:10 GMT+01:00 Tomasz CEDRO : > Hello world :-) > > I need to configure automount for a testing machine. It seems to work > fine, except for two issues: > > 1. Mount point does not disappear after device disappears, what makes > things harder to script when device is gone. automount -c does not > remove the mountpoint, only restarting the service does. It is a bug > or feature? > Bug, or perhaps a missing feature. No known workaround at this point, I'm afraid. > 2. Automounter does not mount USB Pendrive / MSDOSFS devices that does > not have a parition table. Some USB Drives does not have valid > partition table, they appear as /dev/da0 and can be mounted with > mount_msdosfs /dev/da0 /mnt, but they are not recognised by > automounter.. how can I make it work with such devices? > It should just work: [trasz@v2:~]% ll /media total 5 drwxr-xr-x 3 root wheel 512 Oct 6 15:38 . drwxr-xr-x 21 root wheel 1024 Oct 5 23:58 .. [trasz@v2:~]% doas mdconfig -s1g md0 trasz@v2:~]% doas newfs_msdos /dev/md0 newfs_msdos: cannot get number of sectors per track: Operation not supported newfs_msdos: cannot get number of heads: Operation not supported /dev/md0: 2096576 sectors in 65518 FAT16 clusters (16384 bytes/cluster) BytesPerSec=512 SecPerClust=32 ResSectors=1 FATs=2 RootDirEnts=512 Media=0xf0 FATsecs=256 SecPerTrack=63 Heads=255 HiddenSecs=0 HugeSectors=2097152 [trasz@v2:~]% ll /media total 5 drwxr-xr-x 3 root wheel 512 Oct 6 15:38 . drwxr-xr-x 21 root wheel 1024 Oct 5 23:58 .. drwxr-xr-x 3 root wheel 512 Oct 10 06:50 md0 [trasz@v2:~]% With the pendrive plugged in, can you do "gpart show", "/etc/autofs/special_media" (as root), and paste the output? ___ 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: zfs, iSCSI and volmode=dev
2017-10-09 17:38 GMT+01:00 Eugene M. Zheganin : > Hi, > > On 27.09.2017 16:07, Edward Napierala wrote: > >> 2017-08-30 11:45 GMT+02:00 Eugene M. Zheganin > e...@norma.perm.ru>>: >> >> Hi, >> >> >> I have an iSCSI production system that exports a large number of >> zvols as the iSCSI targets. System is running FreeBSD >> 11.0-RELEASE-p7 and initially all of the zvols were confugured >> with default volmode. I've read that it's recommended to use them >> in dev mode, so the system isn't bothered with all of these geom >> structures, so I've switched all of the zvols to dev mode, then I >> exported/imported the pools back. Surprisingly, the performance >> has fallen down like 10 times (200-300 Mbits/sec against 3-4 >> Gbits/sec previously). After observing for 5 minutes the ESXes >> trying to boot up, and doing this extremely slowly, I switched the >> volmode back to default, then again exported/imported the pools. >> The performance went back to normal. >> >> >> So... why did this happen ? The result seems to be >> counter-intuitive. At least not obvious to me. >> >> >> I don't really have an answer - mav@ would be the best person to ask. >> Based >> on his description, "ZVOLs in GEOM mode don't support DPO/FUA cache >> control >> bits, had to chunk large I/Os into MAXPHYS-sized pieces and go through >> GEOM." >> There also used to be so that TRIM was only supported in the "dev" mode, >> but >> that changed a while ago. >> >> Yeah, but you mean dev is faster by design. So was my first thought too, > but it seems like the opposite. Default volmode is geom, and it's much > faster than dev. I'd expect it to be faster, but it might be it interferes with something. For example, if Windows forces direct media access (bypassing the disk cache), and going through GEOM made the target ignore this bit, that could hurt performance. (Note that it's just an idea; I have no idea what's actually happening there.) My first suspect would be TRIM, but then it should work in both modes. Might be worth checking to be sure, by disabling the "unmap" option in ctl.conf (option "unmap" "off") to see if it makes a difference. ___ 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"
bhyve ppt usage can cause severe RAM corruption [Was: Re: panic: Memory modified after free in zio_create, passthru in use]
Bezüglich Harry Schmalzbauer's Nachricht vom 11.06.2017 12:37 (localtime):
> Bezüglich Harry Schmalzbauer's Nachricht vom 06.06.2017 14:03 (localtime):
>> Hello,
>>
>> suddenly, I'm getting this error:
>> /lib/libc.so.7: Undefined symbol "xdr_accepted_reply"
>>
>> Very mysterious: It showed up on a running system, which worked
>> flawlessly for some hours. And that host has root-fs (/) mounted
>> readonly from a memorydisk. So to my understanding, it's completely
>> impossible that /lib/libc.so.7 is corrupted since last boot.
>>
>> I'm completely out of ideas what could cause this strange error during
>> "normal" operation.
>>
>> Normal operation in this case is serving as a bhyve test machine.
>> I first noticed that error after one guest - with passthru device
>> attached - was shut down.
>>
>> My suspicion is some undiscovered passthru interference... Since I
>> noticed one other _very_ strange passthru-effect:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215740
> Hello,
>
> this time I caught a panic with a debuging kernel under 11.1-BETA1,
> which again occured after shuting down a VM which had ppt in use:
>
…
> Please, can anybody of the xperts add a comment?
It turned out that it's a problem with PCIe cards which don't support
FLR or cards, which are not PCIe, even if they have FLR capabilitiy.
jhb@ helped me to diagnose this.
Unfortunately I once forgot to manually bring down the passthrough-nics
in question, which resulted in a completely destroyed ZFS pool.
That hurted, so I won't rely on manual intervention before shutting down
(I had to recreate the complete (system) pool).
Unfortunately my skills don't allow me to help fixing the root cause, so
I created a little rc(8) script, which should protect reliably.
Please see also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222937
Since it's quite small overhead, I'll also attach it here (to be copied
to /etc/rc.d).
-harry
#!/bin/sh
#
# PROVIDE: pciptdetach
# REQUIRE: swap
# BEFORE: devd
# KEYWORD: shutdown
. /etc/rc.subr
name=pciptdetach
rcvar=pciptdetach_enable
load_rc_config ${name}
: ${pciptdetach_enable:="YES"}
start_cmd="true"
stop_cmd="${name}"
pciptdetach()
{
sysctl -n hw.hv_vendor | grep -q bhyve || return 0
echo "Disabling passthrough adapters:"
pptcandidate=`pciconf -l | grep -v -E \
"^([[:blank:]]|hostb|virtio|isab)[^@]+" | sed -n -E \
's/^[[:blank:]]*(^[[:alnum:]]+)@([^[:blank:]]+)(:[[:blank:]]).*$/\2/p'`
for pcidev in ${pptcandidate}; do
drv_class=`pciconf -lv | grep -A 3 "@${pcidev}" | sed -n -E -e \
's/^[[:blank:]]*class[[:blank:]]+=[[:blank:]]+([^[:blank:]].*)$/\1/p' \
-e 's/^([[:alnum:]]+)@.*$/\1/p' | tr '\n' ' '`
# Don't disable mass storage devices, might be busy for shutdown
[ X"${drv_class}" = X"${drv_class%mass storage*}" ] || continue
# Make sure network adapters don't have active vlan(4) clones.
if [ -z "${netstoped}" ] &&
[ X"${drv_class}" != X"${drv_class%network*}" ]
then
/etc/rc.d/netif stop >/dev/null 2>&1 && netstoped=y
fi
# Non-PCIe devices and PCIe devices without FLR support are
# known to cause RAM corruption.
if ! pciconf -lc ${pcidev} | grep -A 20 PCI-Express |
grep -q "[[:blank:]]FLR"
then
devctl disable ${pcidev} >/dev/null 2>&1 ||
echo " ${drv_class%% *}:FAILED"
fi
done
}
run_rc_command "$1"
___
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"
