Re: [SOLVED][BUG??] Unattended install using bsdinstall and ZFS
Hi, Claus,
> Am 29.05.2015 um 19:17 schrieb Claus Andersen :
>
> Hi!
>
> A quick re-cap: Want to do an unattended FreeBSD install using bsdinstall and
> ZFS. I now have a workaround and consider crying wol^H^H^Hbug.
>
> The following minimal install script works as expected for UFS:
> [...]
> Hours later I have figure out the following which works(tm):
>
> install-zfs2.txt
> DISTRIBUTIONS="kernel.txz base.txz"
> RELEASE="10.1"
> export ZFSBOOT_DISKS="da0 da1"
> export ZFSBOOT_VDEV_TYPE="mirror"
> export nonInteractive="YES"
>
> #!/bin/sh
> echo "Ready for post installation damage..."
Thanks for your detailled report. I can confirm your findings and I was able to
do an unattended install using these settings:
DISTRIBUTIONS="base.txz doc.txz games.txz kernel.txz lib32.txz"
INTERFACES="em0"
export ZFSBOOT_DISKS="da0 da1"
export ZFSBOOT_VDEV_TYPE="mirror"
export ZFSBOOT_FORCE_4K_SECTORS="1"
export ZFSBOOT_SWAP_SIZE="8g"
export ZFSBOOT_SWAP_MIRROR="1"
export ZFSBOOT_POOL_CREATE_OPTIONS="-O compress=lz4 -O checksum=fletcher4"
export nonInteractive="YES"
Yet, there are still 2 things that prevent a truly unattended installation.
First, at least for me,
the installer alway displays a dialog with debug messages which needs to be
explicitly
confirmed at the end of the installation. This is not the case if I use UFS.
With UFS it just
reboots into the freshly installed system.
I could work around that one by explicitly calling "reboot" at the end of the
shell script
part of installerconfig.
Second, if you do remote installation via IPMI and serial console over IP, the
standard install
environment copied from CD calls this code in /etc/rc.local:
[...]
else
# Serial or other console
echo
echo "Welcome to FreeBSD!"
echo
echo "Please choose the appropriate terminal type for your system."
echo "Common console types are:"
echo " ansi Standard ANSI terminal"
echo " vt100VT100 or compatible terminal"
echo " xtermxterm terminal emulator (or compatible)"
echo " cons25w cons25w terminal"
echo
echo -n "Console type [vt100]: "
read TERM
TERM=${TERM:-vt100}
fi
IMHO hardwiring this is not a good idea. Can be solved by simply commenting out
the unwanted
parts, but this should be configurable in installerconfig. Currently it quite
defeats the purpose of
*unattended* installations. At least I expect "power on, get some coffee, login
via ssh into newly
installed system" ;-)
Kind regards
Patrick M. Hausen
Leiter Netzwerke und Sicherheit
--
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
i...@punkt.de http://www.punkt.de
Gf: Jürgen Egeling AG Mannheim 108285
___
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"
ixgb(4) ->ix[v]/ixl[v], only for amd64?
Hello, in sys/i386/conf/GENERIC (https://svnweb.freebsd.org/base/releng/10.2/sys/i386/conf/GENERIC?revision=285830&view=markup), there's still "device ixgb" while sys/amd64/conf/GENERIC reflects recent driver changes. Is the driver really completely different for different archs? Thanks, -harry signature.asc Description: OpenPGP digital signature
Re: suspend/resume regression
On 07/26/2015 00:54, Kevin Oberman wrote: John, I'm concerned that two issues may be getting conflated. The issue I thought we were looking at was the failure of some systems (T520, X220, T430) to resume after a number of PCI enhancements were MFCed. This is completely unrelated to the USB issue I was experiencing when trying to test the problem on HEAD. The more I think about it, the more I think that the USB "issue" is just how things need to work. Specifically, if you are booting a full, multi-user system from a USB connected drive, suspending and resuming will leave the system in an untenable condition that will force a panic. At least I don't see how the OS can determine that the disk present on resume is unchanged from that present when the system was suspended. Modern disk IDs greatly improve the situation, but I am unaware of any way to be sure that a removable drive (such as a USB) has not been removed and plugged into some other system that might have written to it. My knowledge of such things is very dated, going back to my days doing kernel programming about 25-30 year ago on VMS, so someone may have resolved the issue, but I don't understand exactly how. I guess that the risk might be low enough to just go ahead and pray that nobody did something really, really stupid like unplugging the drive, plugging it in elsewhere, and writing to it. The real issue is just resuming the system after r281874 was MFCed as a part of 284034. No USB connected file systems are involved. I m happy to see that it has been reverted for 10.2, but clearly, these changes are needed down the line and I hope the issue can be resolved well before 11.0. (This assumes a 10.3 before 11.0 happens next year.) I have done some tests on my T530 at r285668 and had some (good and bad) surprises: 0) historically i915kms+drm2 could not be loaded by loader.conf without locking the machine, but needed to be loaded by rc.conf (kld_list). Now these modules can be loaded by loader.conf. 1) resume does not work with a non patched kernel, but works when the MFC of r281874 is reverted (i.e. r285863 applied) - in console mode (vt) and X.org. 2) and now is my bad surprise: when i915kms+drm2+iic*+kbdmux are not loaded at all, suspend works (in console mode of course), but not resume, both with the nonpatched and the patched kernel. After resume the screen keeps being black, but the system can be logged to with ssh, but cannot be powered off nor rebooted from another system. Furthermore the log shows unidentified _USB_ devices at resume (which never appeared in any log before): Jul 29 12:28:12 watson devd: Executing '/etc/rc.suspend acpi 0x03' Jul 29 12:28:12 watson acpi: suspend at 20150729 12:28:12 Jul 29 12:28:37 watson kernel: uhub0: at usbus0, port 1, addr 1 (disconnected) Jul 29 12:28:37 watson kernel: uhub1: at usbus1, port 1, addr 1 (disconnected) Jul 29 12:28:37 watson kernel: ugen1.2: at usbus1 (disconnected) Jul 29 12:28:37 watson kernel: uhub4: at uhub1, port 1, addr 2 (disconnected) Jul 29 12:28:37 watson kernel: ugen1.3: at usbus1 (disconnected) Jul 29 12:28:37 watson kernel: uhub2: at usbus2, port 1, addr 1 (disconnected) Jul 29 12:28:37 watson kernel: ugen2.2: at usbus2 (disconnected) Jul 29 12:28:37 watson kernel: uhub3: at uhub2, port 1, addr 2 (disconnected) Jul 29 12:28:37 watson kernel: ugen2.3: at usbus2 (disconnected) Jul 29 12:28:37 watson kernel: ums0: at uhub3, port 5, addr 3 (disconnected) Jul 29 12:28:37 watson kernel: acpi0: cleared fixed power button status Jul 29 12:28:37 watson kernel: em0: link state changed to DOWN Jul 29 12:28:37 watson kernel: xhci0: Port routing mask set to 0x Jul 29 12:28:37 watson kernel: uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 Jul 29 12:28:37 watson kernel: uhub1: on usbus2 Jul 29 12:28:37 watson kernel: uhub2: on usbus1 Jul 29 12:28:38 watson kernel: uhub0: 8 ports with 8 removable, self powered Jul 29 12:28:37 watson devd: Executing '/etc/rc.resume acpi 0x03' Jul 29 12:28:38 watson acpi: resumed at 20150729 12:28:38 Jul 29 12:28:38 watson kernel: uhub2: 3 ports with 3 removable, self powered Jul 29 12:28:38 watson kernel: uhub1: 3 ports with 3 removable, self powered Jul 29 12:28:38 watson kernel: em0: link state changed to UP Jul 29 12:28:38 watson devd: Executing '/etc/rc.d/dhclient quietstart em0' Jul 29 12:28:39 watson kernel: ugen2.2: at usbus2 Jul 29 12:28:39 watson kernel: uhub3: on usbus2 Jul 29 12:28:39 watson kernel: ugen1.2: at usbus1 Jul 29 12:28:39 watson kernel: uhub4: on usbus1 Jul 29 12:28:40 watson kernel: uhub4: 6 ports with 6 removable, self powered Jul 29 12:28:41 watson kernel: uhub3: 8 ports with 8 removable, self powered Jul 29 12:28:41 watson kernel: ugen1.3: at usbus1 Jul 29 12:28:41 watson devd: Executing 'logger Unknown USB device: vendor 0x04f2 product 0xb2ea bus uhub4' Jul 29 12:28:41 watson root: Unknown USB dev
FreeBSD_STABLE_9-i386 - Build #113 - Failure
FreeBSD_STABLE_9-i386 - Build #113 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_9-i386/113/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_9-i386/113/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_9-i386/113/console Change summaries: 286009 by dim: Merge r286007 from stable/10: Pull in r219009 from upstream llvm trunk (by Adam Nemet): [ISel] Keep matching state consistent when folding during X86 address match In the X86 backend, matching an address is initiated by the 'addr' complex pattern and its friends. During this process we may reassociate and-of-shift into shift-of-and (FoldMaskedShiftToScaledMask) to allow folding of the shift into the scale of the address. However as demonstrated by the testcase, this can trigger CSE of not only the shift and the AND which the code is prepared for but also the underlying load node. In the testcase this node is sitting in the RecordedNode and MatchScope data structures of the matcher and becomes a deleted node upon CSE. Returning from the complex pattern function, we try to access it again hitting an assert because the node is no longer a load even though this was checked before. Now obviously changing the DAG this late is bending the rules but I think it makes sense somewhat. Outside of addresses we prefer and-of-shift because it may lead to smaller immediates (FoldMaskAndShiftToScale is an even better example because it create a non-canonical node). We currently don't recognize addresses during DAGCombiner where arguably this canonicalization should be performed. On the other hand, having this in the matcher allows us to cover all the cases where an address can be used in an instruction. I've also talked a little bit to Dan Gohman on llvm-dev who added the RAUW for the new shift node in FoldMaskedShiftToScaledMask. This RAUW is responsible for initiating the recursive CSE on users (http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/076903.html) but it is not strictly necessary since the shift is hooked into the visited user. Of course it's safer to keep the DAG consistent at all times (e.g. for accurate number of uses, etc.). So rather than changing the fundamentals, I've decided to continue along the previous patches and detect the CSE. This patch installs a very targeted DAGUpdateListener for the duration of a complex-pattern match and updates the matching state accordingly. (Previous patches used HandleSDNode to detect the CSE but that's not practical here). The listener is only installed on X86. I tested that there is no measurable overhead due to this while running through the spec2k BC files with llc. The only thing we pay for is the creation of the listener. The callback never ever triggers in spec2k since this is a corner case. Fixes rdar://problem/18206171 This fixes a possible crash in x86 code generation when compiling recent llvm/clang trunk sources. Direct commit to stable/10, since head already has llvm/clang 3.6.1, which includes this fix. Reported by:jonathan, theraven Upstream PR:https://llvm.org/bugs/show_bug.cgi?id=24249 Merge r286008 from stable/10: Add llvm patch corresponding to r286007. The end of the build log: [...truncated 33216 lines...] c++ -O2 -pipe -I/usr/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar -I. -I/usr/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd9.3\" -DLLVM_HOST_TRIPLE=\"i386-unknown-freebsd9.3\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /usr/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar/IndVarSimplify.cpp -o IndVarSimplify.o c++ -O2 -pipe -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd9.3\" -DLLVM_HOST_TRIPLE=\"i386-unknown-freebsd9.3\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ManagedStatic.cpp -o ManagedStatic.o c++ -O2 -pipe -I/usr/src/lib/c
Re: FreeBSD Quarterly Status Report - Second Quarter 2015
> On Jul 27, 2015, at 7:32 AM, Willem Jan Withagen wrote: > > You have any idea what is/was actual the hardware that was in the box? > > If I remember correctly we gave Jordan a check for like 5000 guilders. > Which I guess would be 2500 us$ at that time. Which was not an enormous > amount of money, so even more impressive that the system lasted 18 years :) And thank you again for that donation! We should have another conference at that place - I remember it was unusual to have a conference at a location that also supplied tools for hacking our Librettos. :) I believe those original funds purchased a Pentium Pro system of fairly reasonable configuration. As Julian says, however, the individual parts were replaced over the years, including the motherboard, and the freefall of today likely bore little resemblance to the one we purchased at the local PC shop in Walnut Creek, California! - Jordan ___ 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 Quarterly Status Report - Second Quarter 2015
On 29-7-2015 18:01, Jordan Hubbard wrote: On Jul 27, 2015, at 7:32 AM, Willem Jan Withagen wrote: You have any idea what is/was actual the hardware that was in the box? If I remember correctly we gave Jordan a check for like 5000 guilders. Which I guess would be 2500 us$ at that time. Which was not an enormous amount of money, so even more impressive that the system lasted 18 years :) And thank you again for that donation! We should have another conference at that place - I remember it was unusual to have a conference at a location that also supplied tools for hacking our Librettos. :) It was a fun weekend. I think Robert demonstrated a heavy system @work, where he could compile the kernel (or was it world) within 20 minutes We were all amasted that the lines went by faster than we could read. I believe those original funds purchased a Pentium Pro system of fairly reasonable configuration. As Julian says, however, the individual parts were replaced over the years, including the motherboard, and the freefall of today likely bore little resemblance to the one we purchased at the local PC shop in Walnut Creek, California! If it went anything like here in the workshed, only the metal box is more or less still there. But all other parts have gone. Some 4U 19" frames have the fronts cut out, to make room for diskbays. :) Exactly like Julian suggests. I'd like his phrasing thou. --WjW ___ 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"
FreeBSD_STABLE_9-i386 - Build #114 - Fixed
FreeBSD_STABLE_9-i386 - Build #114 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_9-i386/114/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_9-i386/114/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_9-i386/114/console Change summaries: 286012 by dim: Revert r286007-r286009 for now, until I can figure out how to make the fix compile with older gcc and libstdc++. ___ 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"
mount_msdosfs: msdosfs_iconv: Operation not permitted
Hello, it looks like an old issue [1,2,3], but it's bugging me. Generally, I'm not able to mount msdos file system as a regular user with extra charset options (-L) before the superuser. After the superuser mounts (and unmounts) the file system, regular users can do it to. Below is more info about my system and the detailed steps to reproduce the issue. Thanks for suggestions. Stefan [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=109024 [2] https://forums.freebsd.org/threads/mount_msdosfs-msdosfs_iconv-operation-not-permitted.36897/ [3] https://forums.freebsd.org/threads/mount_msdosfs-bug.2668/ ** my system % uname -a FreeBSD silver.local 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 % locale LANG=en_GB.UTF-8 LC_CTYPE="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_ALL= % cat /etc/fstab /dev/da1/home/user/mnt/u0 msdosfs rw,noauto,noexec,-L=en_GB.UTF-8,-m=600,-M=700 0 0 /dev/da1s1 /home/user/mnt/u1 msdosfs rw,noauto,noexec,-L=en_GB.UTF-8,-m=600,-M=700 0 0 % sysctl vfs.usermount vfs.usermount: 1 % cat /etc/rc.conf | grep kiconv kiconv_preload="YES" kiconv_local_charset="UTF-8" kiconv_foreign_charset="UTF-16BE UTF-8" kiconv_fstypes="msdosfs" % pkg info|grep kiconv kiconvtool-0.97Tool to preload kernel iconv charset tables ** initially loaded tables % kiconvtool -d UTF-8 -> UTF-16BE UTF-16BE -> UTF-8 ** try to mount as a regular user % mount /home/user/mnt/u1 mount_msdosfs: msdosfs_iconv: Operation not permitted ** mount fs as root # mount /home/user/mnt/u1 # umount /home/user/mnt/u1 ** tables after root mounted the fs % kiconvtool -d UTF-8 -> UTF-16BE UTF-16BE -> UTF-8 UTF-8 -> _wctype ** now a regular user can mount too % mount /home/user/mnt/u1 ___ 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: mount_msdosfs: msdosfs_iconv: Operation not permitted
I think you should make sure the msdosfs_iconv module is already loaded. Mount_msdosfs loads this module for you if it has the rights. That is why it works if root has done that ones. Add this to rc.conf and reboot: kld_list="msdosfs_iconv" Regards, Ronald. On Wed, 29 Jul 2015 21:32:00 +0200, wrote: Hello, it looks like an old issue [1,2,3], but it's bugging me. Generally, I'm not able to mount msdos file system as a regular user with extra charset options (-L) before the superuser. After the superuser mounts (and unmounts) the file system, regular users can do it to. Below is more info about my system and the detailed steps to reproduce the issue. Thanks for suggestions. Stefan [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=109024 [2] https://forums.freebsd.org/threads/mount_msdosfs-msdosfs_iconv-operation-not-permitted.36897/ [3] https://forums.freebsd.org/threads/mount_msdosfs-bug.2668/ ** my system % uname -a FreeBSD silver.local 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 % locale LANG=en_GB.UTF-8 LC_CTYPE="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_ALL= % cat /etc/fstab /dev/da1/home/user/mnt/u0 msdosfs rw,noauto,noexec,-L=en_GB.UTF-8,-m=600,-M=700 0 0 /dev/da1s1 /home/user/mnt/u1 msdosfs rw,noauto,noexec,-L=en_GB.UTF-8,-m=600,-M=700 0 0 % sysctl vfs.usermount vfs.usermount: 1 % cat /etc/rc.conf | grep kiconv kiconv_preload="YES" kiconv_local_charset="UTF-8" kiconv_foreign_charset="UTF-16BE UTF-8" kiconv_fstypes="msdosfs" % pkg info|grep kiconv kiconvtool-0.97Tool to preload kernel iconv charset tables ** initially loaded tables % kiconvtool -d UTF-8 -> UTF-16BE UTF-16BE -> UTF-8 ** try to mount as a regular user % mount /home/user/mnt/u1 mount_msdosfs: msdosfs_iconv: Operation not permitted ** mount fs as root # mount /home/user/mnt/u1 # umount /home/user/mnt/u1 ** tables after root mounted the fs % kiconvtool -d UTF-8 -> UTF-16BE UTF-16BE -> UTF-8 UTF-8 -> _wctype ** now a regular user can mount too % mount /home/user/mnt/u1 ___ 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" ___ 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: mount_msdosfs: msdosfs_iconv: Operation not permitted
On Wed, Jul 29, 2015 at 09:32:00PM +0200, ae...@posteo.de wrote: > Generally, I'm not able to mount msdos file system as a regular user > with extra charset options (-L) before the superuser. After the > superuser mounts (and unmounts) the file system, regular users can do it > to. msdosfs charset support must be compiled into the kernel or loaded by mount_msdosfs(8) first time it is used. When mount_msdosfs command run with superuser rights, it loads needed code into the kernel successfully. Without superuser righs, it fails. Just load libiconv.ko and msdosfs_iconv.ko by means of /boot/loader.conf or /etc/rc.conf at boot time and you should be fine. Eugene Grosbein ___ 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: suspend/resume regression
On Wed, Jul 29, 2015 at 5:58 AM, Claude Buisson wrote: > On 07/26/2015 00:54, Kevin Oberman wrote: > >> John, >> >> I'm concerned that two issues may be getting conflated. >> >> The issue I thought we were looking at was the failure of some systems >> (T520, X220, T430) to resume after a number of PCI enhancements were >> MFCed. >> This is completely unrelated to the USB issue I was experiencing when >> trying to test the problem on HEAD. The more I think about it, the more I >> think that the USB "issue" is just how things need to work. >> >> Specifically, if you are booting a full, multi-user system from a USB >> connected drive, suspending and resuming will leave the system in an >> untenable condition that will force a panic. At least I don't see how the >> OS can determine that the disk present on resume is unchanged from that >> present when the system was suspended. Modern disk IDs greatly improve the >> situation, but I am unaware of any way to be sure that a removable drive >> (such as a USB) has not been removed and plugged into some other system >> that might have written to it. My knowledge of such things is very dated, >> going back to my days doing kernel programming about 25-30 year ago on >> VMS, >> so someone may have resolved the issue, but I don't understand exactly >> how. >> I guess that the risk might be low enough to just go ahead and pray that >> nobody did something really, really stupid like unplugging the drive, >> plugging it in elsewhere, and writing to it. >> >> The real issue is just resuming the system after r281874 was MFCed as a >> part of 284034. No USB connected file systems are involved. I m happy to >> see that it has been reverted for 10.2, but clearly, these changes are >> needed down the line and I hope the issue can be resolved well before >> 11.0. >> (This assumes a 10.3 before 11.0 happens next year.) >> >> > I have done some tests on my T530 at r285668 and had some (good and bad) > surprises: > > 0) historically i915kms+drm2 could not be loaded by loader.conf without > locking the machine, but needed to be loaded by rc.conf (kld_list). Now > these modules can be loaded by loader.conf. > > 1) resume does not work with a non patched kernel, but works when the > MFC of r281874 is reverted (i.e. r285863 applied) - in console mode (vt) > and X.org. > > 2) and now is my bad surprise: when i915kms+drm2+iic*+kbdmux are not > loaded at all, suspend works (in console mode of course), but not > resume, both with the nonpatched and the patched kernel. After resume > the screen keeps being black, but the system can be logged to with ssh, > but cannot be powered off nor rebooted from another system. Furthermore > the log shows unidentified _USB_ devices at resume (which never appeared > in any log before): > > Jul 29 12:28:12 watson devd: Executing '/etc/rc.suspend acpi 0x03' > Jul 29 12:28:12 watson acpi: suspend at 20150729 12:28:12 > Jul 29 12:28:37 watson kernel: uhub0: at usbus0, port 1, addr 1 > (disconnected) > Jul 29 12:28:37 watson kernel: uhub1: at usbus1, port 1, addr 1 > (disconnected) > Jul 29 12:28:37 watson kernel: ugen1.2: at usbus1 > (disconnected) > Jul 29 12:28:37 watson kernel: uhub4: at uhub1, port 1, addr 2 > (disconnected) > Jul 29 12:28:37 watson kernel: ugen1.3: > at usbus1 (disconnected) > Jul 29 12:28:37 watson kernel: uhub2: at usbus2, port 1, addr 1 > (disconnected) > Jul 29 12:28:37 watson kernel: ugen2.2: at usbus2 > (disconnected) > Jul 29 12:28:37 watson kernel: uhub3: at uhub2, port 1, addr 2 > (disconnected) > Jul 29 12:28:37 watson kernel: ugen2.3: at usbus2 (disconnected) > Jul 29 12:28:37 watson kernel: ums0: at uhub3, port 5, addr 3 > (disconnected) > Jul 29 12:28:37 watson kernel: acpi0: cleared fixed power button status > Jul 29 12:28:37 watson kernel: em0: link state changed to DOWN > Jul 29 12:28:37 watson kernel: xhci0: Port routing mask set to 0x > Jul 29 12:28:37 watson kernel: uhub0: <0x8086 XHCI root HUB, class 9/0, > rev 3.00/1.00, addr 1> on usbus0 > Jul 29 12:28:37 watson kernel: uhub1: rev 2.00/1.00, addr 1> on usbus2 > Jul 29 12:28:37 watson kernel: uhub2: rev 2.00/1.00, addr 1> on usbus1 > Jul 29 12:28:38 watson kernel: uhub0: 8 ports with 8 removable, self > powered > Jul 29 12:28:37 watson devd: Executing '/etc/rc.resume acpi 0x03' > Jul 29 12:28:38 watson acpi: resumed at 20150729 12:28:38 > Jul 29 12:28:38 watson kernel: uhub2: 3 ports with 3 removable, self > powered > Jul 29 12:28:38 watson kernel: uhub1: 3 ports with 3 removable, self > powered > Jul 29 12:28:3
Re: suspend/resume regression
On 07/29/2015 23:53, Kevin Oberman wrote: On Wed, Jul 29, 2015 at 5:58 AM, Claude Buisson wrote: On 07/26/2015 00:54, Kevin Oberman wrote: John, I'm concerned that two issues may be getting conflated. The issue I thought we were looking at was the failure of some systems (T520, X220, T430) to resume after a number of PCI enhancements were MFCed. This is completely unrelated to the USB issue I was experiencing when trying to test the problem on HEAD. The more I think about it, the more I think that the USB "issue" is just how things need to work. Specifically, if you are booting a full, multi-user system from a USB connected drive, suspending and resuming will leave the system in an untenable condition that will force a panic. At least I don't see how the OS can determine that the disk present on resume is unchanged from that present when the system was suspended. Modern disk IDs greatly improve the situation, but I am unaware of any way to be sure that a removable drive (such as a USB) has not been removed and plugged into some other system that might have written to it. My knowledge of such things is very dated, going back to my days doing kernel programming about 25-30 year ago on VMS, so someone may have resolved the issue, but I don't understand exactly how. I guess that the risk might be low enough to just go ahead and pray that nobody did something really, really stupid like unplugging the drive, plugging it in elsewhere, and writing to it. The real issue is just resuming the system after r281874 was MFCed as a part of 284034. No USB connected file systems are involved. I m happy to see that it has been reverted for 10.2, but clearly, these changes are needed down the line and I hope the issue can be resolved well before 11.0. (This assumes a 10.3 before 11.0 happens next year.) I have done some tests on my T530 at r285668 and had some (good and bad) surprises: 0) historically i915kms+drm2 could not be loaded by loader.conf without locking the machine, but needed to be loaded by rc.conf (kld_list). Now these modules can be loaded by loader.conf. 1) resume does not work with a non patched kernel, but works when the MFC of r281874 is reverted (i.e. r285863 applied) - in console mode (vt) and X.org. 2) and now is my bad surprise: when i915kms+drm2+iic*+kbdmux are not loaded at all, suspend works (in console mode of course), but not resume, both with the nonpatched and the patched kernel. After resume the screen keeps being black, but the system can be logged to with ssh, but cannot be powered off nor rebooted from another system. Furthermore the log shows unidentified _USB_ devices at resume (which never appeared in any log before): Jul 29 12:28:12 watson devd: Executing '/etc/rc.suspend acpi 0x03' Jul 29 12:28:12 watson acpi: suspend at 20150729 12:28:12 Jul 29 12:28:37 watson kernel: uhub0: at usbus0, port 1, addr 1 (disconnected) Jul 29 12:28:37 watson kernel: uhub1: at usbus1, port 1, addr 1 (disconnected) Jul 29 12:28:37 watson kernel: ugen1.2: at usbus1 (disconnected) Jul 29 12:28:37 watson kernel: uhub4: at uhub1, port 1, addr 2 (disconnected) Jul 29 12:28:37 watson kernel: ugen1.3: at usbus1 (disconnected) Jul 29 12:28:37 watson kernel: uhub2: at usbus2, port 1, addr 1 (disconnected) Jul 29 12:28:37 watson kernel: ugen2.2: at usbus2 (disconnected) Jul 29 12:28:37 watson kernel: uhub3: at uhub2, port 1, addr 2 (disconnected) Jul 29 12:28:37 watson kernel: ugen2.3: at usbus2 (disconnected) Jul 29 12:28:37 watson kernel: ums0: at uhub3, port 5, addr 3 (disconnected) Jul 29 12:28:37 watson kernel: acpi0: cleared fixed power button status Jul 29 12:28:37 watson kernel: em0: link state changed to DOWN Jul 29 12:28:37 watson kernel: xhci0: Port routing mask set to 0x Jul 29 12:28:37 watson kernel: uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 Jul 29 12:28:37 watson kernel: uhub1: on usbus2 Jul 29 12:28:37 watson kernel: uhub2: on usbus1 Jul 29 12:28:38 watson kernel: uhub0: 8 ports with 8 removable, self powered Jul 29 12:28:37 watson devd: Executing '/etc/rc.resume acpi 0x03' Jul 29 12:28:38 watson acpi: resumed at 20150729 12:28:38 Jul 29 12:28:38 watson kernel: uhub2: 3 ports with 3 removable, self powered Jul 29 12:28:38 watson kernel: uhub1: 3 ports with 3 removable, self powered Jul 29 12:28:38 watson kernel: em0: link state changed to UP Jul 29 12:28:38 watson devd: Executing '/etc/rc.d/dhclient quietstart em0' Jul 29 12:28:39 watson kernel: ugen2.2: at usbus2 Jul 29 12:28:39 watson kernel: uhub3: on usbus2 Jul 29 12:28:39 watson kernel: ugen1.2: at usbus1 Jul 29 12:28:39 watson kernel: uhub4: on usbus1 Jul 29 12:28:40 watson kernel: uhub4: 6 ports with 6 removable, self powered Jul 29 12:28:41 watson kernel: uhub3: 8 ports with 8 removable, self powered Jul 29 12:28:41 watson kernel: ugen1.3: at usbus1 Jul 29 12:28:41 watson devd: Executing 'logger Unknown U
Re: suspend/resume regression
On Wed, Jul 29, 2015 at 3:47 PM, Claude Buisson wrote: > On 07/29/2015 23:53, Kevin Oberman wrote: > >> On Wed, Jul 29, 2015 at 5:58 AM, Claude Buisson >> wrote: >> >> On 07/26/2015 00:54, Kevin Oberman wrote: >>> >>> John, >>>> >>>> I'm concerned that two issues may be getting conflated. >>>> >>>> The issue I thought we were looking at was the failure of some systems >>>> (T520, X220, T430) to resume after a number of PCI enhancements were >>>> MFCed. >>>> This is completely unrelated to the USB issue I was experiencing when >>>> trying to test the problem on HEAD. The more I think about it, the more >>>> I >>>> think that the USB "issue" is just how things need to work. >>>> >>>> Specifically, if you are booting a full, multi-user system from a USB >>>> connected drive, suspending and resuming will leave the system in an >>>> untenable condition that will force a panic. At least I don't see how >>>> the >>>> OS can determine that the disk present on resume is unchanged from that >>>> present when the system was suspended. Modern disk IDs greatly improve >>>> the >>>> situation, but I am unaware of any way to be sure that a removable drive >>>> (such as a USB) has not been removed and plugged into some other system >>>> that might have written to it. My knowledge of such things is very >>>> dated, >>>> going back to my days doing kernel programming about 25-30 year ago on >>>> VMS, >>>> so someone may have resolved the issue, but I don't understand exactly >>>> how. >>>> I guess that the risk might be low enough to just go ahead and pray that >>>> nobody did something really, really stupid like unplugging the drive, >>>> plugging it in elsewhere, and writing to it. >>>> >>>> The real issue is just resuming the system after r281874 was MFCed as a >>>> part of 284034. No USB connected file systems are involved. I m happy to >>>> see that it has been reverted for 10.2, but clearly, these changes are >>>> needed down the line and I hope the issue can be resolved well before >>>> 11.0. >>>> (This assumes a 10.3 before 11.0 happens next year.) >>>> >>>> >>>> I have done some tests on my T530 at r285668 and had some (good and >>> bad) >>> surprises: >>> >>> 0) historically i915kms+drm2 could not be loaded by loader.conf without >>> locking the machine, but needed to be loaded by rc.conf (kld_list). Now >>> these modules can be loaded by loader.conf. >>> >>> 1) resume does not work with a non patched kernel, but works when the >>> MFC of r281874 is reverted (i.e. r285863 applied) - in console mode (vt) >>> and X.org. >>> >>> 2) and now is my bad surprise: when i915kms+drm2+iic*+kbdmux are not >>> loaded at all, suspend works (in console mode of course), but not >>> resume, both with the nonpatched and the patched kernel. After resume >>> the screen keeps being black, but the system can be logged to with ssh, >>> but cannot be powered off nor rebooted from another system. Furthermore >>> the log shows unidentified _USB_ devices at resume (which never appeared >>> in any log before): >>> >>> Jul 29 12:28:12 watson devd: Executing '/etc/rc.suspend acpi 0x03' >>> Jul 29 12:28:12 watson acpi: suspend at 20150729 12:28:12 >>> Jul 29 12:28:37 watson kernel: uhub0: at usbus0, port 1, addr 1 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: uhub1: at usbus1, port 1, addr 1 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: ugen1.2: at usbus1 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: uhub4: at uhub1, port 1, addr 2 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: ugen1.3: >>> at usbus1 (disconnected) >>> Jul 29 12:28:37 watson kernel: uhub2: at usbus2, port 1, addr 1 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: ugen2.2: at usbus2 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: uhub3: at uhub2, port 1, addr 2 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: ugen2.3: at usbus2 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: ums0: at uhub3, port 5, addr 3 >>> (disconnected) >>> Jul 29 12:28:37 watson kernel: acpi0: cleared fixed power button status
Swap Usage
I have several FreeBSD 9.3 systems that are using swap and I can’t figure out what is doing it. The key system has 6GB swap and currently it has over 2GB in use. ps shows only a kernel module [intr] with a W status. Obviously that isn’t using the space. No other process shows a W in its status. I suspect this is somewhat related to the use of mmap in one application. However, all of the mmaps in that application are file backed and thus shouldn’t use swap. How do I figure out what that swap space is being used for? ___ 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: Swap Usage
On Wed, 29 Jul 2015 17:41:33 -0700 Doug Hardie wrote > I have several FreeBSD 9.3 systems that are using swap and I can’t figure > out what is doing it. The key system has 6GB swap and currently it has over > 2GB in use. ps shows only a kernel module [intr] with a W status. Obviously > that isn’t using the space. No other process shows a W in its status. I > suspect this is somewhat related to the use of mmap in one application. > However, all of the mmaps in that application are file backed and thus > shouldn’t use swap. How do I figure out what that swap space is being used > for? Maybe top(1)? top -P for example. At least you could see who's chewing all your memory. Which should be a good clue as to who's responsible for swap usage. --Chris > > > ___ > 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" ___ 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: suspend/resume regression
On Saturday, July 25, 2015 03:54:40 PM Kevin Oberman wrote: > John, > > I'm concerned that two issues may be getting conflated. > > The issue I thought we were looking at was the failure of some systems > (T520, X220, T430) to resume after a number of PCI enhancements were MFCed. > This is completely unrelated to the USB issue I was experiencing when > trying to test the problem on HEAD. The more I think about it, the more I > think that the USB "issue" is just how things need to work. Well, the USB thing could be smarter, but it's a bit of a PITA. What if you take the USB stick out, mess with it on another system, then plug it back in before resume? All the cached file data in the RAM of the resumed system would need to be invalidated, etc. However, I ended up copying a HEAD kernel onto my USB stick and seeing that I at least got the console back before it panic'd. This was sufficient to let me test the reversion patch via the USB stick (and would be sufficient for seeing if we can merge it again for 10.3). > The real issue is just resuming the system after r281874 was MFCed as a > part of 284034. No USB connected file systems are involved. I m happy to > see that it has been reverted for 10.2, but clearly, these changes are > needed down the line and I hope the issue can be resolved well before 11.0. > (This assumes a 10.3 before 11.0 happens next year.) So it works fine in 11.0 on my x220, and as other folks reported in the PR, so 11.0 is fine. It is also needed for PCI-e hotplug to work after resume (using out-of-tree patches for PCI-e hotplug that jmg@ has). If I merge it to 10.3 it won't be until I've verified that whatever I merge works on my x220 as well as the T440. -- John Baldwin ___ 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: Swap Usage
> On 29 July 2015, at 18:57, Chris H wrote: > > On Wed, 29 Jul 2015 17:41:33 -0700 Doug Hardie wrote > >> I have several FreeBSD 9.3 systems that are using swap and I can’t figure >> out what is doing it. The key system has 6GB swap and currently it has over >> 2GB in use. ps shows only a kernel module [intr] with a W status. Obviously >> that isn’t using the space. No other process shows a W in its status. I >> suspect this is somewhat related to the use of mmap in one application. >> However, all of the mmaps in that application are file backed and thus >> shouldn’t use swap. How do I figure out what that swap space is being used >> for? > Maybe top(1)? > top -P > for example. At least you could see who's chewing all your memory. Which > should be a good clue as to who's responsible for swap usage. UFS although I don’t see how that could make a difference. Swap doesn’t use a regular file system. However, the kernel must track the actual usage using something like a simple file system. There must be a way to investigate it. Top doesn’t show anything unusual. The most VM used is by the process that uses a lot of mmap space that is all file backed. If it was another process that was partially swapped then the ps status should show a W. Only the one does. ___ 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: Swap Usage
> On 29 July 2015, at 17:41, Doug Hardie wrote: > > I have several FreeBSD 9.3 systems that are using swap and I can’t figure out > what is doing it. The key system has 6GB swap and currently it has over 2GB > in use. ps shows only a kernel module [intr] with a W status. Obviously > that isn’t using the space. No other process shows a W in its status. I > suspect this is somewhat related to the use of mmap in one application. > However, all of the mmaps in that application are file backed and thus > shouldn’t use swap. How do I figure out what that swap space is being used > for? UFS although that shouldn’t matter. Swap does not use a file system. If it did, it would be easy to figure out. Top doesn’t show much. ___ 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: Swap Usage
[reformatted] On 2015-Jul-29 17:41:33 -0700, Doug Hardie wrote: >I have several FreeBSD 9.3 systems that are using swap and I can’t >figure out what is doing it. The key system has 6GB swap and >currently it has over 2GB in use. Is the system currently paging (top(1) and "systat -v" will show this)? If not, this just means that at some time in the past, the system was under memory pressure and paged some process memory out. Since then, that memory hasn't been touched so the system hasn't paged it in. >ps shows only a kernel module >[intr] with a W status. 'W' means the whole process is 'swapped' out - this will only occur under severe RAM pressure. Normally, the system will just page out inactive parts of a processes address space - and none of the ps flags will show this. > How do I figure out what that swap space is being used for? I don't think this can be trivially done. "procstat -v" will show the number of resident pages within each swap-backed region, any pages in that region that have been touched but are not resident are on the swap device but any pages that have never been touched aren't counted at all. -- Peter Jeremy pgp_HZj6rM0Rp.pgp Description: PGP signature
