Re: FreeBSD 10.4-RC2 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, Sep 24, 2017 at 07:46:19PM +1000, Ian Smith wrote: > On Sat, 23 Sep 2017 19:54:50 +0200, Marius Strobl wrote: > > > o Given that the amd64 disc1 image was overflowing, more of the base > > components installed into the disc1 (live) file systems had to be > > disabled. Most notably, this removed the compiler toolchain from > > the disc1 images. All disabled tools are still available with the > > dvd1 images, though. > > 1) Does that also apply to the components installed on the memstick.img? Yes, given that the disc1 file systems are also used to create the memstick images. > 2) Are we any closer to gettng a larger memstick.img with dvd1 contents? No, given that we'd likely want to have a variant of the memstick images which include all base tools also for snapshots. However, so far the dvd1 images are only created for releases and around the notion to contain packages, i. e. it's not as simple as creating additional memstick images from the dvd1 file system. Also, given that with head the amd64 disc1 image is overflowing despite all of the stripping, the way to go for 12.0 likely is to drop the historical limits on images sizes along with the disc1 images and instead provide DVD images with all base tools and for releases, additional DVD images with packages on top. Similar for memstick images. All of this probably boils down to adding options to both makefs(8) and mkimg(1) for simply excluding the packages directory (as for makefs(8), simpler than via an mtree(8) file) first, so we neither need to employ hacks in the release scripts nor build yet another file system set. Marius -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJZx89+XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1M0Q5QjQzNTVGOTU5ODBGQzVENzZCMDIy MEI3MERFMTNGMUQxRTRGAAoJECC3DeE/HR5PrNwQAI7hNUN3IZRFcV3fzAl88GKP B6FmZKSWogxTwqLJCQgglJXoUkid5FfzMGH9qDjEE1g6W0sN4Q5aysv5+5s+WPWU Xfhl5ivm070dYDBaqbR0cxCaK7cbIScf14dbpxE6hNUYHV5hnQZp8kT+vvvWYIQz TZlHGiK1dccYH5WOg/UgR7nvs6piXI5XzmvP7o1mWv2TdT0DwaNXjuHznwZnAdW7 rStMPpvlC99a6+iAU74cbcBQi9w6Uuro+7V+DXZSwQRdP0PQsx1zOxkwAeY5+BKz PFK7w0SC5GB1ym7ddQSyY3+8bQOEelwOX99yqU9SCqPnqyMOl+l+CAv8gCenyoBl BgU4fTAAtsxNgne065/cGA+EEMDZtI2mdleGV8xXQGUFu2Dp8+HOhKBID95SW7LJ +WDAKUvbkQvw5URjFZ3TtsbqZQptGji/Xze8i6nJ1dv0aU2ajU3sjR/N5yy+wg9i KUK7K53Wx0TKVUkd4oUDePEUSjnRzalO8BPk4oLi08EvmX/yBMVswdaV4GIhCy5+ hSzud+98xmq3eDhoRsLqE2eRUbP9BegbM7VappEqFRE1I0mLQG9A/8DR49aZhzA2 TFg+rnYhjjW3gW3GtgZteHeRYIlk9ADsTxvbz2CEL2JpuUIFeb6g2OPPXeqTXZQZ hQPI71i7MhhJXRg+sQdM =nrnb -END PGP SIGNATURE- ___ 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"
FreeBSD 10.4-RC2 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The second RC build of the 10.4-RELEASE release cycle is now available. Installation images are available for: o amd64 GENERIC o i386 GENERIC o ia64 GENERIC o powerpc GENERIC o powerpc64 GENERIC64 o sparc64 GENERIC o armv6 BEAGLEBONE o armv6 CUBOX-HUMMINGBOARD o armv6 GUMSTIX o armv6 PANDABOARD o armv6 RPI-B o armv6 WANDBOARD Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/ftp/releases/ISO-IMAGES/10.4/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "releng/10.4" branch. A list of changes since 10.3-RELEASE is available in the releng/10.4 release notes: https://www.freebsd.org/releases/10.4R/relnotes.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 10.4-RELEASE cycle progresses. === Noteworthy Changes Since 10.4-RC1 === o Given that the amd64 disc1 image was overflowing, more of the base components installed into the disc1 (live) file systems had to be disabled. Most notably, this removed the compiler toolchain from the disc1 images. All disabled tools are still available with the dvd1 images, though. o The aesni(4) driver now no longer shares a single FPU context across multiple sessions in multiple threads, addressing problems seen when employing aesni(4) for ipsec(4). o Support for netmap(4) by the ixgbe(4) driver has been brought into line with the netmap(4) API present in stable/10. Also, ixgbe(4) now correctly handles VFs in its netmap(4) support again instead of treating these as PFs. o During the creation of amd64 and i386 VM images, etcupdate(8) and mergemaster(8) databases now are bootstrapped, akin to what happens along the extraction of base.txz as part of a new installation via bsdinstall(8). This change allows for both of these tools to work out-of-box on the VM images and avoids errors seen when upgrading these images via freebsd-update(8). === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): https://download.freebsd.org/ftp/releases/VM-IMAGES/10.4-RC2/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 160 MB and 128 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: Created AMI in ap-south-1 region: ami-ddc385b2 Created AMI in eu-west-2 region: ami-d0e6f5b4 Created AMI in eu-west-1 region: ami-2aa36d53 Created AMI in ap-northeast-2 region: ami-b59943db Created AMI in ap-northeast-1 region: ami-3ef03858 Created AMI in sa-east-1 region: ami-3b3f4357 Created AMI in ca-central-1 region: ami-688a330c Created AMI in ap-southeast-1 region: ami-5eb9c83d Created AMI in ap-southeast-2 region: ami-e054b282 Created AMI in eu-central-1 region: ami-a53988ca Created AMI in us-east-1 region: ami-ac4da6d6 Created AMI in us-east-2 region: ami-e49ab881 Created AMI in us-west-1 region: ami-2b2d1c4b Created AMI in us-west-2 region: ami-10a55a68 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-10.4-RC2 % vagrant up === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 10.4-RC2 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for
FreeBSD 10.4-RC1 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The first RC build of the 10.4-RELEASE release cycle is now available. Installation images are available for: o amd64 GENERIC o i386 GENERIC o ia64 GENERIC o powerpc GENERIC o powerpc64 GENERIC64 o sparc64 GENERIC o armv6 BEAGLEBONE o armv6 CUBOX-HUMMINGBOARD o armv6 GUMSTIX o armv6 PANDABOARD o armv6 RPI-B o armv6 WANDBOARD Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/ftp/releases/ISO-IMAGES/10.4/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "releng/10.4" branch. A list of changes since 10.3-RELEASE is available in the releng/10.4 release notes: https://www.freebsd.org/releases/10.4R/relnotes.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 10.4-RELEASE cycle progresses. === Noteworthy Changes Since 10.4-BETA4 === o An upstream fix for zlib compression has been merged. The bug had caused the embedded Tomcat web server of UniFi Controllers to send out incorrectly compressed responses. o The Linux statfs ftype is now aware of ZFS. o A bug in bsdinstall(8) causing ifconfig_$INTERFACE lines to be added to /etc/rc.conf for unsuccessful DHCP attempts has been addressed. o The usermod command of the pw(8) utility now correctly handles empty secondary group lists (`pw usermod -G ''`) and its useradd command no longer will add entries with invalid user names, e. g. ones containing spaces. o The zfs(8) error message displayed when rejecting a checksum selection now no longer suggests unsupported hash algorithms itself. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): https://download.freebsd.org/ftp/releases/VM-IMAGES/10.4-RC1/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 160 MB and 128 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: Created AMI in ap-south-1 region: ami-b00543df Created AMI in eu-west-2 region: ami-940a19f0 Created AMI in eu-west-1 region: ami-b88143c1 Created AMI in ap-northeast-2 region: ami-723de61c Created AMI in ap-northeast-1 region: ami-baa469dc Created AMI in sa-east-1 region: ami-a9215cc5 Created AMI in ca-central-1 region: ami-99c27bfd Created AMI in ap-southeast-1 region: ami-a5acd9c6 Created AMI in ap-southeast-2 region: ami-5d12f53f Created AMI in eu-central-1 region: ami-3fd36550 Created AMI in us-east-1 region: ami-034bad79 Created AMI in us-east-2 region: ami-87f2d0e2 Created AMI in us-west-1 region: ami-ac2c1acc Created AMI in us-west-2 region: ami-c33ac9bb === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-10.4-RC1 % vagrant up === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 10.4-RC1 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 9.x. Alternatively, the user can install misc/compat9x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install == ISO CHECKSUMS == o 10.4-RC1 amd6
FreeBSD 10.4-BETA4 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The fourth BETA build of the 10.4-RELEASE release cycle is now available. Installation images are available for: o amd64 GENERIC o i386 GENERIC o ia64 GENERIC o powerpc GENERIC o powerpc64 GENERIC64 o sparc64 GENERIC o armv6 BEAGLEBONE o armv6 CUBOX-HUMMINGBOARD o armv6 GUMSTIX o armv6 PANDABOARD o armv6 RPI-B o armv6 WANDBOARD Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/ftp/releases/ISO-IMAGES/10.4/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "stable/10" branch. A list of changes since 10.3-RELEASE are available in the stable/10 release notes: https://www.freebsd.org/relnotes/10-STABLE/relnotes/article.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 10.4-RELEASE cycle progresses. === Noteworthy Changes Since 10.4-BETA3 === o An erroneous implementation of a silicon bug workaround caused the em(4) driver to always silently disable support for VLAN_HWTSO and TSO4 on the first time an interface was configured. That implementation bug has been corrected but em(4) also changed to no longer automatically enable the VLAN_HWTSO and TSO4 capabilities by default. The latter is due to the fact that the particular hardware defect cannot be reliably worked around in all circumstances. Moreover, desipite several workarounds for TSO- related deficiencies of devices supported em(4) being in place, testing has shown that at least with Intel 82579 employing TSO may hang the chip. Generally, with this changes in place it is now possible again to use TSO with em(4) by manually enabling vlanhwtso and/or tso4 via ifconfig(4). However, care must be taken that doing so is only considered to be safe in environments where the link speed is not to be expected to change from GbE and that at least some models still may experience device timeouts then. o The igb(4) driver now handles received packets whose EtherType protocols are unsupported or for which support has not been compiled in gracefully instead of triggering a panic. o A crash of date(1) that could be triggered by passing invalid time has been corrected. o The file(1) utility received a fix for CVE-2017-1000249. o A bug in ipfilter(4) preventing NATed MTU discovery to work has been addressed. o Mellanox ConnectX-4 series adapters are now supported by the newly added mlx5ib(4) driver. o OpenSSH received an update to version 7.3p1. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): https://download.freebsd.org/ftp/releases/VM-IMAGES/10.4-BETA4/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 160 MB and 128 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: Created AMI in ap-south-1 region: ami-384a0d57 Created AMI in eu-west-2 region: ami-65564501 Created AMI in eu-west-1 region: ami-3ae42243 Created AMI in ap-northeast-2 region: ami-7bd40f15 Created AMI in ap-northeast-1 region: ami-a805c3ce Created AMI in sa-east-1 region: ami-617c0e0d Created AMI in ca-central-1 region: ami-0bf0496f Created AMI in ap-southeast-1 region: ami-acb8d1cf Created AMI in ap-southeast-2 region: ami-312cc853 Created AMI in eu-central-1 region: ami-273e8a48 Created AMI in us-east-1 region: ami-9ccad6e7 Created AMI in us-east-2 region: ami-d45674b1 Created AMI in us-west-1 region: ami-0b1a2d6b Created AMI in us-west-2 region: ami-9b9167e3 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-10.4-BETA4 % vagrant up === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 10.4-BETA4 During this process, freebsd-update(8)
FreeBSD 10.4-BETA3 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The third BETA build of the 10.4-RELEASE release cycle is now available. Installation images are available for: o amd64 GENERIC o i386 GENERIC o ia64 GENERIC o powerpc GENERIC o powerpc64 GENERIC64 o sparc64 GENERIC o armv6 BEAGLEBONE o armv6 CUBOX-HUMMINGBOARD o armv6 GUMSTIX o armv6 PANDABOARD o armv6 RPI-B Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/ftp/releases/ISO-IMAGES/10.4/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "stable/10" branch. A list of changes since 10.3-RELEASE are available in the stable/10 release notes: https://www.freebsd.org/relnotes/10-STABLE/relnotes/article.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 10.4-RELEASE cycle progresses. === Noteworthy Changes Since 10.4-BETA1 === o Support for the Kaby Lake generation of Intel i219 (4) and i219 (5) devices has been added to em(4). o The em(4) driver is now capable of enabling Wake On LAN (WOL) also for Intel i217, i218 and i219 chips. Note that stale configurations from previous unsuccessful attempts to enable WOL for these devices now will actually take effect. For example, an `ifconfig em0 wol` activates all WOL variants including wol_mcast, which might be undesirable. o Support for WOL has been added to the igb(4) driver, which was not able to activate this feature on any device before. The same remark regarding stale WOL configurations as for em(4) applies. O The firmware shipping with qlxgbe(4) has been updated to version 5.4.66. Additionally, this driver received some TSO and locking fixes, performance optimizations as well as SYSCTLs providing MAC, RX and TX statistics. === Known Issues === The armv6 WANDBOARD image failed to build. An image for these boards will be made available again at a later point in the 10.4-RELEASE cycle once the underlying problem has been addressed. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): https://download.freebsd.org/ftp/releases/VM-IMAGES/10.4-BETA3/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 160 MB and 128 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: Created AMI in ap-south-1 region: ami-5b95d134 Created AMI in eu-west-2 region: ami-44e9f920 Created AMI in eu-west-1 region: ami-c340baba Created AMI in ap-northeast-2 region: ami-4561b92b Created AMI in ap-northeast-1 region: ami-9251aaf4 Created AMI in sa-east-1 region: ami-a9bfccc5 Created AMI in ca-central-1 region: ami-ea29978e Created AMI in ap-southeast-1 region: ami-085d306b Created AMI in ap-southeast-2 region: ami-43ca2f21 Created AMI in eu-central-1 region: ami-268c3949 Created AMI in us-east-1 region: ami-873a30fc Created AMI in us-east-2 region: ami-d283a0b7 Created AMI in us-west-1 region: ami-41e7d321 Created AMI in us-west-2 region: ami-d1a055a9 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-10.4-BETA3 % vagrant up === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 10.4-BETA3 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD r
FreeBSD 10.4-BETA2 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The second BETA build of the 10.4-RELEASE release cycle is now available. Installation images are available for: o amd64 GENERIC o i386 GENERIC o ia64 GENERIC o powerpc GENERIC o powerpc64 GENERIC64 o sparc64 GENERIC o armv6 CUBOX-HUMMINGBOARD o armv6 GUMSTIX o armv6 PANDABOARD o armv6 RPI-B Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/ftp/releases/ISO-IMAGES/10.4/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "stable/10" branch. A list of changes since 10.3-RELEASE are available in the stable/10 release notes: https://www.freebsd.org/relnotes/10-STABLE/relnotes/article.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 10.4-RELEASE cycle progresses. === Noteworthy Changes Since 10.4-BETA1 === o The qlnxe(4) driver received a few performance optimizations and options. o Also in case a GPT disk label is used, the fsck_ffs(8) utility now is able to find alternate superblocks. o The daily output of periodic(8) has been restored to consistently use the much more readable unified format for presenting differences in files. o Userland coredumps can now trigger events such as generating a human readable crash report via devd(8). This feature is off by default. o A Makefile allowing geom_map(4) to built as a kernel module has been added, without hooking it up to the default build, though. o The hn(4) driver for Hyper-V is now able to handle transparent mode network VF devices. o RPI-B support has been brought in line with head, allowing the use of newer device tree and firmware versions to be used. Thus, the RPI-B image works again and is available as part of the 10.4-BETA2 set. o Bugs in the mpr(4) and mps(4) drivers that could lead to panics after performing a controller firmware upgrade have been corrected. === Known Issues === During initial testing of 10.4-BETA2 it turned out that the BEAGLEBONE, WANDBOARD images do not boot. Thus, they have not been made available. Images for these boards will be published again at a later point in the 10.4-RELEASE cycle once the underlying problems have been addressed. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): https://download.freebsd.org/ftp/releases/VM-IMAGES/10.4-BETA2/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 160 MB and 128 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: Created AMI in ap-south-1 region: ami-52c2873d Created AMI in eu-west-2 region: ami-0b0b1b6f Created AMI in eu-west-1 region: ami-54ce372d Created AMI in ap-northeast-2 region: ami-f109d19f Created AMI in ap-northeast-1 region: ami-fafe019c Created AMI in sa-east-1 region: ami-63f0800f Created AMI in ca-central-1 region: ami-9866d8fc Created AMI in ap-southeast-1 region: ami-c63c5ca5 Created AMI in ap-southeast-2 region: ami-bf170ddc Created AMI in eu-central-1 region: ami-f804af97 Created AMI in us-east-1 region: ami-f9b2b382 Created AMI in us-east-2 region: ami-8f1f3cea Created AMI in us-west-1 region: ami-28d0e548 Created AMI in us-west-2 region: ami-9912fbe1 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-10.4-BETA2 % vagrant up === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 10.4-BETA2 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now Af
FreeBSD 10.4-BETA1 Now Available
The first BETA build of the 10.4-RELEASE release cycle is now available. Installation images are available for: o amd64 GENERIC o i386 GENERIC o ia64 GENERIC o powerpc GENERIC o powerpc64 GENERIC64 o sparc64 GENERIC o armv6 CUBOX-HUMMINGBOARD o armv6 GUMSTIX o armv6 PANDABOARD Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/ftp/releases/ISO-IMAGES/10.4/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "stable/10" branch. A list of changes since 10.3-RELEASE are available in the stable/10 release notes: https://www.freebsd.org/relnotes/10-STABLE/relnotes/article.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 10.4-RELEASE cycle progresses. === Known Issues === o During initial testing of 10.4-BETA1 it turned out that the BEAGLEBONE, RPI-B and WANDBOARD images do not boot. Thus, they have not been made available. Images for these boards will be published again at a later point in the 10.4-RELEASE cycle once the underlying problems have been addressed. o The 2017Q3 package set used in the 10.4-RELEASE cycle does not include KDE4 packages for amd64 and i386. Thus, such packages are not part of the amd64 and i386 DVD images either. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): https://download.freebsd.org/ftp/releases/VM-IMAGES/10.4-BETA1/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 160 MB and 128 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: Created AMI in ap-south-1 region: ami-08135667 Created AMI in eu-west-2 region: ami-56574732 Created AMI in eu-west-1 region: ami-2cbc4055 Created AMI in ap-northeast-2 region: ami-58d80036 Created AMI in ap-northeast-1 region: ami-0611e160 Created AMI in sa-east-1 region: ami-59d7a635 Created AMI in ca-central-1 region: ami-34952b50 Created AMI in ap-southeast-1 region: ami-ebf59188 Created AMI in ap-southeast-2 region: ami-a56873c6 Created AMI in eu-central-1 region: ami-607bd30f Created AMI in us-east-1 region: ami-86ccf3fd Created AMI in us-east-2 region: ami-8f486bea Created AMI in us-west-1 region: ami-8ed1fbee Created AMI in us-west-2 region: ami-21d53959 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-10.4-BETA1 % vagrant up === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 10.4-BETA1 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 9.x. Alternatively, the user can install misc/compat9x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install == ISO CHECKSUMS == o 10.4-BETA1 amd64 GENERIC: SHA512 (FreeBSD-10.4-BETA1-amd64-bootonly.iso) = b62ba87bf0e0d55cebe8995c30e7dd92cba1f4d94b9c2130bf4477a2ef1f242b4b2d68eb930538338ab9a3844a4243483afff2385db5b61397b88077addd4fb8 SHA512 (FreeBSD-10.4-BETA1-amd64-bootonly.iso.xz) = 58a782b4c0d14589e59eea6f9fd358469ce7d416dc4a4857b4640525e3c5c4735a6510ca487220839eff96f5bdf0136f0b
FreeBSD 10.3-RC3 Now Available
The third Release Candidate build of the 10.3-RELEASE release cycle is now available. Installation images are available for: o amd64 GENERIC o i386 GENERIC o ia64 GENERIC o powerpc GENERIC o powerpc64 GENERIC64 o sparc64 GENERIC o armv6 BEAGLEBONE o armv6 CUBOX-HUMMINGBOARD o armv6 GUMSTIX o armv6 PANDABOARD o armv6 RPI-B o armv6 WANDBOARD Installer images and memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.3/ The image checksums follow at the end of this e-mail. PGP-signed checksums for the images are also available at: https://www.FreeBSD.org/releases/10.3R/signatures.html If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "releng/10.3" branch. A list of changes since 10.2-RELEASE are available on the stable/10 release notes: https://www.freebsd.org/releases/10.3R/relnotes.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 10.3-RELEASE cycle progresses. === Noteworthy Changes Since 10.3-RC2 === o The requirement that for a root-on-ZFS setup, ZFS needs to account for at least 50 percent of the resulting partition table was removed from bsdinstall/zfsboot. o Build configurations of csh(1) and tcsh(1) were changed to activate the SAVESIGVEC option, i. e. saving and restoring of signal handlers before/ after executing an external command. This addresses the problem that after such a program linked to libthr(3) has been run, these shells may terminated on receiving a SIGINT. o FreeBSD SA-16:15 and CVE-2016-1885 respectively has been resolved. o The netwait rc(8) script has been changed to require firewall setup to be completed, otherwise a ping(8) to the IP address specified via the netwait_ip option may not succeed. o In order to be able to work on upcoming Intel Purley platform systems including Skylake Xeon servers, the x86 kernels now align the XSAVE area to a multiple of 64 bytes. Please note, that at this point it is unknown whether this is the only change necessary for FreeBSD to run on Intel Purley machines. o A race with the parent attach in the filemon(4) support of script(1) has been fixed. o The abi rc(8) script now automatically loads linux64.ko on amd64 if Linux binary compatibility is enabled via the linux_enable option. o A race in callout_stop_safe(9) - the backing of callout_drain(9) -, which could lead to a thread switching off CPU and then never become runnable, has been fixed. o The base OpenSSH received an upgraded to version 7.2p2. Among others, this provides fixes for FreeBSD-SA-16:14.openssh and CVE-2016-3115 respectively as well as CVE-2016-1908. Please not that as part of the changes regarding CVE-2016-1908, automatic fallback from untrusted X11 forwarding to trusted one for X servers that disable the X11 SECURITY extension has been removed by upstream. This affects FreeBSD insofar as the xorg-server package and port is built with the said extension disabled. So in order for X11 forwarding to continue to work with the FreeBSD xorg-server and OpenSSH 7.2p2, either the ssh(1) client has to be used with the ForwardX11Trusted option enabled and the implications on security arising in this case. Or, ideally, a nested X server such as Xephyr should be employed for securely executing applications in a sandbox instead. Additionally, some AES-CBC ciphers have been added back to the default server proposal list. These had been removed as part of the previous upgrade to OpenSSH version 7.1p2, breaking e. g. lightweight clients making still use of AES-CBC ciphers in order to be able to use hardware crypto acceleration. Please note that there are known weaknesses in the SSH protocol when using AES-CBC ciphers. There is no known practical exploit so far, however, actual use of these ciphers should be avoided. === Open Issues === There is a report that the above mentioned change to csh(1) and tcsh(1) may cause rc(8) scripts and service(8) to fail sending SIGTERM to some processes, e. g. during shutdown. At this point it is unknown how these could be related, given that both rc(8) scripts and service(8) employ sh(1) instead. Should it turn out that the SAVESIGVEC change indeed is the cause, that revision likely will be reverted for 10.3-RELEASE and an Errata Notice with a properly working changeset issued later on. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.3-RC3/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 G
Re: DISPLAY not set inside jails after update to 10.3-PRERELEASE FreeBSD 10.3-PRERELEASE #4 r297043
On Sun, Mar 20, 2016 at 07:47:58AM +0800, Erich Dollansky wrote: > Hi, > > On Sat, 19 Mar 2016 08:23:09 -0600 > Ian Lepore wrote: > > > On Sat, 2016-03-19 at 13:48 +0800, Erich Dollansky wrote: > > > > > > nothing else was changed on the machine except the update. I could > > > use > > > > > > ssh 192.168.12.12 > > > > > > to connect to a jail running under that IP address before the update > > > without problems. > > > > > > It works now only with > > > > > > ssh -Y 192.168.12.12 > > > > > > The /etc/ssh/ssh_config file says: > > > > > > Host * > > > ForwardX11 yes > > > > > > So, it should allow to connect to all machines providing ssh and > > > forward X11. > > > > > > What did I miss? > > > > If -Y works, the ssh config file option that corresponds to that is > > ForwardX11Trusted. ForwardX11 corresponds to -X. (Not sure what > > changed, just throwing out the one little crumb of info I've got.) > > > I got this as an off-list reply: > > Could this be related to FreeBSD-SA-16:14.openssh? Not FreeBSD-SA-16:14.openssh and CVE-2016-3115 respectively, but most likely the changes for CVE-2016-1908 which came in as part of the upgrade to OpenSSH 7.2p2, i. e. (among others): https://anongit.mindrot.org/openssh.git/commit/?id=ed4ce82dbfa8a3a3c8ea6fa0db113c71e234416c The xorg-server port is built with the X11 SECURITY extension disabled. I just can suspect that the intent is to use a nested X server such as Xephyr for securely running applications instead. Actually, I'm surprised that such a fallback to trusted forwarding existed. I believe it wasn't present back when ForwardX11Trusted was introduced, essentially already causing the trouble you're now hitting. Marius signature.asc Description: PGP signature
FreeBSD 10.3-RC2 Now Available
The second Release Candidate build of the 10.3-RELEASE release cycle is now available. Installation images are available for: o amd64 GENERIC o i386 GENERIC o ia64 GENERIC o powerpc GENERIC o powerpc64 GENERIC64 o sparc64 GENERIC o armv6 BEAGLEBONE o armv6 CUBOX-HUMMINGBOARD o armv6 GUMSTIX o armv6 PANDABOARD o armv6 RPI-B o armv6 WANDBOARD Installer images and memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.3/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "releng/10.3" branch. A list of changes since 10.2-RELEASE are available on the stable/10 release notes: https://www.freebsd.org/releases/10.3R/relnotes.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 10.3-RELEASE cycle progresses. === Noteworthy Changes Since 10.3-RC1 === o Under certain circumstances, `zfs send -i`, i. e. incremental ZFS send, could lead to data corruption, which has been addressed by importing an upstream fix. o Boot loaders and kernel have been taught to handle ELF sections of type SHT_AMD64_UNWIND just the same as SHT_PROGBITS when loading modules. While not directly relevant for 10.3-RELEASE, clang as of version 3.8 started to produce sections of the former type in amd64 modules. Thus, this changes will simplify upgrades from 10.3-RELEASE to 11.0-RELEASE later on. o As part of closing or syncing a hash(3)-based database file, fsync(2) now is called on the latter. This ensures that changes are on disk when shutting down a machine, which previously was not always the case with soft updates in place. Additionally, this change allowed removal of O_SYNC in the dbopen(3) calls of cap_mkdb(1), pwd_mkdb(8) as well as services_mkdb(8), speeding these up on large database files. === Open Issues === Two changes for OpenSSH did not make it into this Release Candidate: o A fix for CVE-2016-3115, and o the re-addition of AES-CBC ciphers to the default server proposal list. These have been removed as part of the previous upgrade to OpenSSH version 7.1p2, breaking e. g. lightweight clients making still use of AES-CBC ciphers in order to be able to employ hardware crypto acceleration. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.3-RC2/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: us-east-1 region: ami-feb5b194 us-west-1 region: ami-f385f693 us-west-2 region: ami-adeb05cd sa-east-1 region: ami-1ba02d77 eu-west-1 region: ami-24c87357 eu-central-1 region: ami-277a9e48 ap-northeast-1 region: ami-6c7e7702 ap-southeast-1 region: ami-50884333 ap-southeast-2 region: ami-1fb1907c === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-10.3-RC2 % vagrant up --provider vmware_desktop === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 10.3-RC2 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 9.x. Alternatively, the user can install misc/compat9x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install == ISO CHECKSUMS == o 10.3-RC2 amd64 GENERIC: SHA512 (FreeBSD-10.3-RC2-amd64-bootonly.iso) =
FreeBSD 10.3-RC1 Now Available
The first Release Candidate build of the 10.3-RELEASE release cycle is now available. Installation images are available for: o amd64 GENERIC o i386 GENERIC o ia64 GENERIC o powerpc GENERIC o powerpc64 GENERIC64 o sparc64 GENERIC o armv6 BEAGLEBONE o armv6 CUBOX-HUMMINGBOARD o armv6 GUMSTIX o armv6 PANDABOARD o armv6 RPI-B o armv6 WANDBOARD Installer images and memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.3/ The image checksums follow at the end of this e-mail. PGP-signed checksums for the images are also available at: https://www.FreeBSD.org/releases/10.3R/signatures.html If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "releng/10.3" branch. A list of changes since 10.2-RELEASE are available on the stable/10 release notes: https://www.freebsd.org/relnotes/10-STABLE/relnotes/article.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 10.3-RELEASE cycle progresses. === Noteworthy Changes Since 10.3-BETA3 === o In the pf(4) DIOCRSETADDRS IOCTL, a possible out-of-bounds write has been corrected. o OpenSSL has been updated to version 1.0.1s, which provides security fixes for CVE-2016-0702, CVE-2016-0705, CVE-2016-0797, CVE-2016-0798, CVE-2016-0799 and CVE-2016-0780. o Hyper-V drivers - hv_netvsc(4) and hv_vmbus(4) in particular - now wait longer for hypervisor results, which avoids attach failures of network and storage devices. o A regression in the INTx handler of nvme(4) introduced mid-January 2016 onto the stable/10 branch has been addressed. The most likely scenario to hit the panic caused by that flaw was to run FreeBSD on Google Compute Engine with a local SSD as NVMe. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.3-RC1/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: us-east-1 region: ami-a4e8d0ce us-west-1 region: ami-493c4f29 us-west-2 region: ami-fe6a869e sa-east-1 region: ami-b229abde eu-west-1 region: ami-99c970ea eu-central-1 region: ami-c3b652ac ap-northeast-1 region: ami-20f2fe4e ap-southeast-1 region: ami-aafa32c9 ap-southeast-2 region: ami-04200167 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-10.3-RC1 % vagrant up --provider vmware_desktop === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 10.3-RC1 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 9.x. Alternatively, the user can install misc/compat9x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install == ISO CHECKSUMS == o 10.3-RC1 amd64 GENERIC: SHA512 (FreeBSD-10.3-RC1-amd64-bootonly.iso) = 1f83719df35b07eaabda67d7fbb4cc20783f0eedb572450e30c3c17bc765706397df2e7612bc092d4d8ee2b586b2540eb607c63ecfee71e2d6eee84003e87201 SHA512 (FreeBSD-10.3-RC1-amd64-bootonly.iso.xz) = d238cc8a435d64063e2f433bf4c06e9ab6e4205185b50c8360e62c9923e356ec754076fd2b6fef070c93a468220a564a5fe679146352e1b6a96c7242b1f0e43f SHA512 (FreeBSD-10.3-RC1-amd64-disc1.iso) = 6c9fb0c0a2b8b0c35677402963fe400b0f2b70e916e24a2fd1f17257ba8d6e12f7cae70e9af32fab81e95bf04e4255c512e6f1b626cf6ab9cabe8c8df37dcc5e SHA512 (FreeBSD-10.3-RC1-amd64-disc1.iso.xz) = 113784a1ade4e07c97
FreeBSD 10.3-BETA3 Now Available
The third BETA build of the 10.3-RELEASE release cycle is now available. Installation images are available for: o amd64 GENERIC o i386 GENERIC O ia64 GENERIC o powerpc GENERIC o powerpc64 GENERIC64 o sparc64 GENERIC o armv6 BEAGLEBONE o armv6 CUBOX-HUMMINGBOARD o armv6 GUMSTIX o armv6 PANDABOARD o armv6 RPI-B o armv6 WANDBOARD Installer images and memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.3/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "stable/10" branch. A list of changes since 10.2-RELEASE are available on the stable/10 release notes: https://www.freebsd.org/relnotes/10-STABLE/relnotes/article.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 10.3-RELEASE cycle progresses. === Noteworthy Changes Since 10.3-BETA2 === o The em(4) and igb(4) drivers have been updated to version 7.6.1 and 2.5.3 respectively. Among others, this brought support for i219/ i219(2)/ i219(3) hardware found with Skylake generation and newer chipsets as well as an IPv6 workaround for a silicon erratum of 1G server products driven by igb(4). Additionally, the DMA and TSO segment handling of these two drivers has been fixed and cleaned up. o The firmware for qlxgbe(4) has been updated to version 5.4.56, bringing the driver to version 3.10.26. o For 82598, ix(4) incorrectly announced support for SCTP checksum offloading, which has been addressed. o The SCTP stack received several fixes, some of which resolve bugs that were unveiled by PVS-Studio. o A regression preventing the none protocol to be used with lagg(4) has been remedied. o The filemon(4) device received several corrections and improvements. o It is now possible again to use truss(1) with Linux/i386 binaries. o A nullfs(5) vnode(9) leak triggered by the rmdir(1) operation has been plugged. o The filter recursion level of libarchive(5) is now limited to 25 (instead of infinite), fixing a potential crash issue. o Support for mounting linprocfs(5) and linsysfs(5) file systems has been added to the jail(2) framework. o Hyper-V bus and network device drivers have received some fixes. o Both the problems with system hangs when using ZFS caused by VFS(9) fixes and optimizations as well as with the generation of ICMP MTU updates when performing NAT caused by tryfoward optimization have been resolved. Because these two regressions were regarded as showstoppers for 10.3-RELEASE and no fixes could be developed in due time, this was done by reverting the changes in question. o The DIOCKILLSTATES IOCTL of pf(4) now uses the correct source and destination ports when removing states. o Two new commands have been added to the amd64 framebuffer driver of the UEFI boot loader. The first is `gop` (as in Graphics Output Protocol), which allows to diagnose problems with efifb(4) but also to set the current graphics mode on machines employing GOP. With `uga` (as in Universal Graphics Adapter), it is possible to do the same on systems using the UGA protocol, which mainly translates to Apple hardware. The latter change also generally introduced UGA support and currently hardcodes the necessary settings for mid-2007 iMacs (iMac7,1) and late-2007 MacBooks (MacBook3,1). But it is likewise possible to manually supply the necessary information for additional systems. o Four new ddb(8) commands for displaying vmem(9) statistics were added. o Some changes were made to the SSL handling of libfetch. For one, it now falls back to the standard/configured CA store. Second, a double-free error resulting from a failing SSL connection has been resolved. o The SCSI Extended INQUIRY probe case of xpt(4) when an error is returned and a retry is scheduled has been fixed. o Panics in ext2fs(5) resulting from rename(r2) race conditions were removed. o The nvd(4) and nvme(4) drivers received fixes and improvements. o Hangs or panics resulting from misbehaved kernel threads returning from their main function have been fixed. o The unbound(8) resolver now uses the new insecure-lan-zones option instead of listing each AS112 zone separately. o A bug in drm2(4) causing GPU hangs with i945GM has been addressed. o The leap-seconds file updating for ntpd(8) was corrected to also work in non-chroot(2) environments. o On device deallocation, tty(4) now clears the queues. o A freed memory dereference when a devfs(5) directory entry is freed has been fixed. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/releases
FreeBSD 10.3-RELEASE schedule update
As you may have read in the announcement of 10.3-BETA2, we are currently facing two regressions with the stable/10 code base for 10.3-RELEASE: o The tryfoward optimization introduced in r290383 and merged as r295285, which unconditionally replaces the previous IP fastforwarding option, has turned out to cause ICMP messages being sent back to incorrect addresses when NAT is applied by a machine running that revision and having divergent MTU. This problem was reported in the context of OpenVPN-based tunneling but also is not unlikely to generally cause a regression for Path MTU Discovery over a gateway doing NAT. For further details regarding the original problem see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087 o The fixes and optimizations to VFS(9) of r291244, which was merged as part of r292895, cause system hangs when using ZFS. If you are affected by this regression, please test the patch posted in: https://lists.freebsd.org/pipermail/freebsd-stable/2016-February/084180.html and report back there if the reversal of r291244 actually resolves the problem for you, especially if you are a user of amd64, as more confirmation still is needed for that architecture. At re@ it has been decided, that we will not enter the RC phase with these showstoppers in place. Thus, the original 10.3-RELEASE schedule has been put back by one week in order to allow for resolving these two problems, with the previously optional 10.3-BETA3 builds now taking place on February 26th, 2016. Consequently, the updated, remaining release cycle for 10.3-RELEASE as it currently stands is: BETA3 build starts: February 26, 2016 releng/10.3 branch: March 4, 2016 RC1 build starts:March 4, 2016 stable/10 thaw: March 6, 2016 release package copy:March 6, 2016 RC2 build starts:March 11, 2016 RC3 build starts:March 18, 2016 [*] RELEASE build starts:March 25, 2016 RELEASE announcement:March 29, 2016 RELEASE EoL: July 31, 2017 (tentative) [*] - If needed Marius On behalf of: re@ signature.asc Description: PGP signature
Re: 10-STABLE hangups frequently
Could those of you experiencing these hangs with ZFS please test whether instead of reverting all of r292895, a kernel built with just the merge of r291244 undone via the following patch gets rid of that problem - especially on amd64 - and report back? https://people.freebsd.org/~marius/r291244_reversal_10.diff Marius signature.asc Description: PGP signature
FreeBSD 10.3-BETA2 Now Available
The second BETA build of the 10.3-RELEASE release cycle is now available. Installation images are available for: o amd64 GENERIC o i386 GENERIC O ia64 GENERIC o powerpc GENERIC o powerpc64 GENERIC64 o sparc64 GENERIC o armv6 BEAGLEBONE o armv6 CUBOX-HUMMINGBOARD o armv6 GUMSTIX o armv6 PANDABOARD o armv6 RPI-B o armv6 WANDBOARD Installer images and memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.3/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "stable/10" branch. A list of changes since 10.2-RELEASE are available on the stable/10 release notes: https://www.freebsd.org/relnotes/10-STABLE/relnotes/article.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 10.3-RELEASE cycle progresses. === Noteworthy Changes Since 10.3-BETA1 === o OpenSSH has been upgraded to 7.1p2. o A bug in bsnmpd(1) causing breakage on platforms with strict alignment requirements has been fixed. o A leak of routing table allocations occurring when shutting down VNET- enabled jails has been fixed. o The tty(4) layer now prohibits opening the callout device when the corresponding callin device (in disguise as the console device) is already opened. o Corruption of coredumps due to procstat notes changing size during coredump generation have been fixed. o A leap-seconds file for ntpd(8) now is installed by default and ntpd.conf(5) as well as the corresponding rc(8) files have been updated accordingly. Additionally, support for updating the leap- seconds file via periodic(8) has been added (defaulting to off). o The UEFI ZFS loader has been updated to support the latest ZFS Boot Environment (BE) loader menu features. o The initialization of random(9) has been adjusted so it is usable earlier. This fixes the "random device not loaded; using insecure entropy" message output during boot on some systems. o The ixgbe(4) driver has been updated to the Intel FreeBSD Networking Group version 3.1.13-k and support for X552 and X550T was added. Also, SFP module insertion post boot, the VF handling of VLANs in the Amazon Cloud, GBIC and PHY power setup (correcting link detected on X540-AT2 after a previous boot to Linux) and incorrect reporting of unsupported flow control auto negotiation have been fixed. Additionally, the flow control and link speed negotiation defaults now may be be configured via the hw.ix.flow_control and hw.ix.advertise_speed loader tunables respectively, with the previously available hw.ix.enable_aim now only setting the default for adaptive interrupt moderation and which can be overridden on a per-interface basis during runtime via the enable_aim SYSCTL. Note, however, that Amazon EC2 Enhanced Networking later turned out to actually still not operate properly with these changes. o The sfxge(4) driver has been enhanced with a SIOCGI2C IOCTL, allowing to query SFP+/QSFP+ module information via `ifconfig -v`. o The UEFI boot loader received several improvements: /boot/config and /boot.config files now are adhered to, multi device boot support works and command line argument parsing has been added. === Open Issues === o The fixes and mainly optimizations to VFS(9) merged in r292895 are known to cause system hangs when using ZFS. For i386, a fix is under testing but at this point it is questionable, whether that patch will also solve the problem for amd64. o The tryfoward optimization merged in r295285 which unconditionally replaces the previous IP fastforwarding option has turned out to break OpenVPN server functionality. For further details see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087 Currently, these two problems are regarded as showstoppers for the final 10.3-RELEASE, making 10.3-BETA3 which was scheduled on a if-needed basis an actual necessity. In 10.3-BETA3, these two problems will either be fixed - or in the worst case - the offending revisions pulled. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.3-BETA2/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in th
Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)
On Mon, Feb 08, 2016 at 02:24:42PM -0500, Mike Tancsa wrote: > On 2/8/2016 4:10 AM, Marius Strobl wrote: > > On Sat, Feb 06, 2016 at 07:46:02PM -0500, mike tancsa wrote: > >> Sure, I will try Monday when at the office > > > > Actually, thinking about it, could you please try the following > > patch on top of the previous one/r295287? > > https://people.freebsd.org/~marius/e1000_max_scatter_tso_10.diff > > > Didnt take too long ( ~5hrs post reboot). It does at least recover on > its own which is good. Nevertheless, thank you very much for testing. Marius ___ 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: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)
On Sat, Feb 06, 2016 at 07:46:02PM -0500, mike tancsa wrote: > Sure, I will try Monday when at the office Actually, thinking about it, could you please try the following patch on top of the previous one/r295287? https://people.freebsd.org/~marius/e1000_max_scatter_tso_10.diff Thanks Marius ___ 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: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)
On Tue, Feb 02, 2016 at 09:49:59AM -0500, Mike Tancsa wrote: > On 1/30/2016 12:26 PM, Marius Strobl wrote: > > On Sat, Jan 30, 2016 at 11:47:19AM -0500, Mike Tancsa wrote: > >> On 1/29/2016 8:23 PM, Marius Strobl wrote: > >>> On Fri, Jan 29, 2016 at 03:41:57PM -0500, Mike Tancsa wrote: > >>>> > >>>> No multi queue. Stock GENERIC kernel with a couple of things removed. > >>>> hw.em are just the defaults. I will try without TSO > >>>> > >>>> % ifconfig em0 > >>>> em0: flags=8843 metric 0 mtu 1500 > >>>> > >>>> options=4209b > >>>> > >>> > >>> Hrm, that's strange, TSO4 should be enabled by default so apparently > >>> you are already disabling it; what is the behavior if you turn it on? > >>> Do you use a < Gigabit link? > >> > >> Hi Marius, > >>Thanks for looking. The ifconfig output was after I turned off tso as > >> Harry suggested to try. Its been 24hrs and I have not seen any resets. > >> I will wait another 36hrs or so and then turn it back on to see if the > >> problem comes back. > >> > >> this link is 100Mb. > > > > Ah, okay, that at least makes sense. Can you please verify that with > > the attached patch applied, you have a setup that works out of the > > box? > > Hi, > Should the nic come up with TSO disabled by default ? After reboot, I > see > Yes, that's expected; the default still is to enable TSO4, but with the patch, em(4) will silently ignore/disable administratively set TSO4 if the link speed negotiated is < Gigabit Ethernet. However, could you please do an experiment? Revert the patch again and in if_em.h change EM_MAX_SCATTER from 64 to 40, recompile and test. Thanks Marius ___ 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"
FreeBSD 10.3-BETA1 Now Available
The first BETA build of the 10.3-RELEASE release cycle is now available. Installation images are available for: o amd64 GENERIC o i386 GENERIC o powerpc GENERIC o powerpc64 GENERIC64 o sparc64 GENERIC o armv6 BEAGLEBONE o armv6 CUBOX-HUMMINGBOARD o armv6 GUMSTIX o armv6 PANDABOARD o armv6 RPI-B o armv6 WANDBOARD Installer images and memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.3/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "stable/10" branch. A list of changes since 10.2-RELEASE are available on the stable/10 release notes: https://www.freebsd.org/relnotes/10-STABLE/relnotes/article.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 10.3-RELEASE cycle progresses. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.3-BETA1/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: us-east-1 region: ami-c01c35aa us-west-1 region: ami-976214f7 us-west-2 region: ami-425abc22 sa-east-1 region: ami-d737b7bb eu-west-1 region: ami-9ca110ef eu-central-1 region: ami-6ca2ba00 ap-northeast-1 region: ami-2451544a ap-northeast-2 region: ami-67f03e09 ap-southeast-1 region: ami-e996588a ap-southeast-2 region: ami-8996b2ea === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-10.3-BETA1 % vagrant up --provider vmware_desktop === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 10.3-BETA1 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 9.x. Alternatively, the user can install misc/compat9x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install == ISO CHECKSUMS == o 10.3-BETA1 amd64 GENERIC: SHA512 (FreeBSD-10.3-BETA1-amd64-bootonly.iso) = 8b93fac77edd82ab55c914a511c7e23f2e24de68025dff6bc896ee5e53ac659ffc71c37f81d1533486bebf503deda589201fa7d2c588ade2472aa65ac7735e6c SHA512 (FreeBSD-10.3-BETA1-amd64-bootonly.iso.xz) = 9b242a7fb28f200f27a8f8491ace27a07528a45d8d7bf3980e996f5c13d37de08b3c1202d54226f4ce4b36f7b45e900c01e94efbdaf225903c571d752fdbfca5 SHA512 (FreeBSD-10.3-BETA1-amd64-disc1.iso) = 2424179c754d5514754fe75ab470c03c6a0efafd24425cc5b17d98b2e779b5588fa7e746f820e6ad01c86f1d3b4c4244333fa0f46196163c83feb48fe878fd2e SHA512 (FreeBSD-10.3-BETA1-amd64-disc1.iso.xz) = 9cba1bf33de5f85dbe6033feb1a1bb47a88cf1504c0b9229120960761697a71e80f88caf97c45331409aacad28db0c62b0c6ba83db6f667c284bc7a2bed35b36 SHA512 (FreeBSD-10.3-BETA1-amd64-dvd1.iso) = f45520f9d12d7bead6d3647c080c18542ad2977da9a4d6827de27f93ab154d5c435cb491cad459a25cd2b03c81ecc76a49625a00c812a21e6f8ebb5b3660 SHA512 (FreeBSD-10.3-BETA1-amd64-dvd1.iso.xz) = 959a34237d76dd428162a8b84f0c99c78e55abc4459cf57977d7f9bd13b6b4fbbaa49c504448a96787490fd84864c5b32f183dec16b813709cdd427b0727b87e SHA512 (FreeBSD-10.3-BETA1-amd64-memstick.img) = 294fff16d3d6e927497bcf0a5c89058c76d39fe27d12f8763d9306c7fcc7ea3a2737f1cf860f5fc67809bd41883a04c14124b87fdf9fb29bf8338b23ba06a851 SHA512 (FreeBSD-10.3-BETA1-amd64-memstick.img.xz) = 7836248971b0463d50e7d808d9bd2aa24fd42e57788f1f2764dc270d5889b5dc0eecbc216029d8cbbea71d3fbc148e09952ebfbf45d70557387edfc25b965a0c SHA51
Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)
On Mon, Feb 01, 2016 at 05:11:29PM -0500, Mike Tancsa wrote: > On 1/30/2016 12:26 PM, Marius Strobl wrote: > > > > Ah, okay, that at least makes sense. Can you please verify that with > > the attached patch applied, you have a setup that works out of the > > box? > > > Hi, > The patch does not apply cleanly Hrm, it does here on stable/10. If your checkout is unaltered, the only thing I can think of is that the patch got corrupted when sent by e-mail. I've put it online: https://people.freebsd.org/~marius/em_tso_gig_only_10.diff marius@alchemy:/home/marius/co/10/src/sys/dev/e1000 > svn info Path: . Working Copy Root Path: /usr/home/marius/co/10/src URL: svn+ssh://svn.freebsd.org/base/stable/10/sys/dev/e1000 Relative URL: ^/stable/10/sys/dev/e1000 Repository Root: svn+ssh://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 295130 Node Kind: directory Schedule: normal Last Changed Author: marius Last Changed Rev: 294958 Last Changed Date: 2016-01-27 23:31:08 +0100 (Wed, 27 Jan 2016) marius@alchemy:/home/marius/co/10/src/sys/dev/e1000 > patch < ~/em_tso_gig_only_10.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Index: sys/dev/e1000/if_em.c |=== |--- sys/dev/e1000/if_em.c (revision 294962) |+++ sys/dev/e1000/if_em.c (working copy) -- Patching file if_em.c using Plan A... Hunk #1 succeeded at 1377. done ___ 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: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)
On Sat, Jan 30, 2016 at 11:47:19AM -0500, Mike Tancsa wrote:
> On 1/29/2016 8:23 PM, Marius Strobl wrote:
> > On Fri, Jan 29, 2016 at 03:41:57PM -0500, Mike Tancsa wrote:
> >>
> >> No multi queue. Stock GENERIC kernel with a couple of things removed.
> >> hw.em are just the defaults. I will try without TSO
> >>
> >> % ifconfig em0
> >> em0: flags=8843 metric 0 mtu 1500
> >>
> >> options=4209b
> >>
> >
> > Hrm, that's strange, TSO4 should be enabled by default so apparently
> > you are already disabling it; what is the behavior if you turn it on?
> > Do you use a < Gigabit link?
>
> Hi Marius,
> Thanks for looking. The ifconfig output was after I turned off tso as
> Harry suggested to try. Its been 24hrs and I have not seen any resets.
> I will wait another 36hrs or so and then turn it back on to see if the
> problem comes back.
>
> this link is 100Mb.
Ah, okay, that at least makes sense. Can you please verify that with
the attached patch applied, you have a setup that works out of the
box?
Marius
Index: sys/dev/e1000/if_em.c
===
--- sys/dev/e1000/if_em.c (revision 294962)
+++ sys/dev/e1000/if_em.c (working copy)
@@ -1377,8 +1377,15 @@ em_init_locked(struct adapter *adapter)
ifp->if_hwassist = 0;
if (ifp->if_capenable & IFCAP_TXCSUM)
ifp->if_hwassist |= (CSUM_TCP | CSUM_UDP);
- if (ifp->if_capenable & IFCAP_TSO4)
- ifp->if_hwassist |= CSUM_TSO;
+ /*
+ ** There have proven to be problems with TSO when not
+ ** at full gigabit speed, so disable the assist automatically
+ ** when at lower speeds. -jfv
+ */
+ if (ifp->if_capenable & IFCAP_TSO4) {
+ if (adapter->link_speed == SPEED_1000)
+ ifp->if_hwassist |= CSUM_TSO;
+ }
/* Configure for OS presence */
em_init_manageability(adapter);
___
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: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap)
On Fri, Jan 29, 2016 at 03:41:57PM -0500, Mike Tancsa wrote: > > No multi queue. Stock GENERIC kernel with a couple of things removed. > hw.em are just the defaults. I will try without TSO > > % ifconfig em0 > em0: flags=8843 metric 0 mtu 1500 > > options=4209b > Hrm, that's strange, TSO4 should be enabled by default so apparently you are already disabling it; what is the behavior if you turn it on? Do you use a < Gigabit link? Marius ___ 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: Panic with sym on 10.2
On Tue, Jan 19, 2016 at 03:39:55PM +0100, Andrea Venturoli wrote:
> On 01/19/16 15:19, Matthew Seaman wrote:
> > On 01/19/16 13:13, Andrea Venturoli wrote:
> >> Two days ago I upgraded a (perfectly working) 9.3/i386 box to 10.2p10
> >> Since then I've had two panics with the following message:
> >>
> >> panic: assertion "lp->busy_itl==0&&lp->busy_itlq==0" failed: file
> >> /usr/src/sys/dev/sym/sym_hipd.c
> >>
> >> Since the disk controller is involved, I do not get any core and I have
> >> to press the reset button.
> >>
> >> Google showed up no results (I'm not using ZFS, btw) and Bugzilla didn't
> >> help either.
> >>
These debugging assertions in sym_get_ccb() probably can just be
replaced with graceful handling (see the attached patch). I'm
unsure whether it's sufficient to tell the CAM stack to retry at
a later point, though, and given I'm not hitting this problem I
also can't test. Unlike SCSI-2, SCSI-3 generally allows to mix a
single untagged command with tagged ones (the situation you are
encountering), which FreeBSD apparently started doing somewhere
between 9.3 and 10.2. However, permitting that would require a
careful review of sym(4) and most likely larger changes.
Marius
Index: sym_hipd.c
===
--- sym_hipd.c (revision 294669)
+++ sym_hipd.c (working copy)
@@ -6296,14 +6296,13 @@ static ccb_p sym_get_ccb (hcb_p np, u_char tn, u_c
goto out_free;
} else {
/*
- * If we have been asked for a tagged command.
+ * If we have been asked for a tagged command, refuse
+ * to overlap with an existing untagged one.
*/
if (tag_order) {
+ if (lp->busy_itl != 0)
+goto out_free;
/*
- * Debugging purpose.
- */
- assert(lp->busy_itl == 0);
- /*
* Allocate resources for tags if not yet.
*/
if (!lp->cb_tags) {
@@ -6335,22 +6334,17 @@ static ccb_p sym_get_ccb (hcb_p np, u_char tn, u_c
* one, refuse to overlap this untagged one.
*/
else {
+ if (lp->busy_itlq != 0 || lp->busy_itl != 0)
+goto out_free;
/*
- * Debugging purpose.
- */
- assert(lp->busy_itl == 0 && lp->busy_itlq == 0);
- /*
* Count this nexus for this LUN.
* Set up the CCB bus address for reselection.
* Toggle reselect path to untagged.
*/
- if (++lp->busy_itl == 1) {
-lp->head.itl_task_sa = cpu_to_scr(cp->ccb_ba);
-lp->head.resel_sa =
- cpu_to_scr(SCRIPTA_BA (np, resel_no_tag));
- }
- else
-goto out_free;
+ lp->busy_itl = 1;
+ lp->head.itl_task_sa = cpu_to_scr(cp->ccb_ba);
+ lp->head.resel_sa =
+ cpu_to_scr(SCRIPTA_BA (np, resel_no_tag));
}
}
/*
@@ -6396,7 +6390,7 @@ static void sym_free_ccb(hcb_p np, ccb_p cp)
*/
if (lp) {
/*
- * If tagged, release the tag, set the relect path
+ * If tagged, release the tag, set the reselect path.
*/
if (cp->tag != NO_TAG) {
/*
@@ -6417,7 +6411,7 @@ static void sym_free_ccb(hcb_p np, ccb_p cp)
* and uncount this CCB.
*/
lp->head.itl_task_sa = cpu_to_scr(np->bad_itl_ba);
- --lp->busy_itl;
+ lp->busy_itl = 0;
}
/*
* If no JOB active, make the LUN reselect path invalid.
___
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: AAC regression in 9.2-BETA
On Fri, Aug 02, 2013 at 10:05:43PM +0200, Marius Strobl wrote: > On Fri, Aug 02, 2013 at 02:44:04PM -0400, David Boyd wrote: > > I have an Adaptec 2820SA (SATA) controller that hangs the system during > > booting on 9.2-BETA[12]. > > The only message I see on the console refers to controller aac0 and > > indicates "TIMEOUT 138 SECONDS". > > This same controller/motherboard works flawlessly with 9.1-RELEASE-p5. > > I have moved this hardware to "testing" mode and can rebuild often. > > I am asking for direction and suggestions as to which commits might be at > > fault. > > I am sorry that I didn't detect this problem earlier in the release cycle. > > Hope we can resolve this before 9.2-RELEASE. > > That could be due to MSIs being broken with your particular controller > or mainboard. Please try whether setting the tunable hw.aac.enable_msi > to 0 on the loader prompt before booting makes things work. If it does, > please provide a verbose dmesg and the output of `pciconf -lcv`. > For the records, between 9.1 and 9.2, aac(4) has been taught to take advantage of MSIs when available. However, 2820SA turned out to have broken MSI support. Thus, in r254004 a quirk blacklisting MSI usage for that model has been introduced. There was also a similar report for 2230S, in which case it was unclear whether that type of controller or the motherboard is the culprit. To be on the safe side, MSIs also have been blacklisted for 2230S in said revision. This change has been MFCed down to releng/9.2, so it will be part of the final 9.2-RELEASE. However, it doesn't seem warranted to generally disable the use of MSIs in aac(4) again. Marius ___ 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: 9.2-RC1 sparc install via network problems
On Mon, Aug 05, 2013 at 07:36:40PM +0200, Michiel Boland wrote: > Hi. I have some problems installing 9.2-RC1 on sparc64 via the network > > I have a dhcp server, and an NFS server that exports the disc1 ISO. > > Relevant portions of dhcpd.conf: > > filename "boot/loader"; > option root-path ":/cdrom"; > > The boot/loader was copied from the install image. The tftpboot directory is > otherwise empty. (So no loader.conf etc.) Do you also have 'next-server' in there? I'm buffled how TFTPing the loader could work without one ... > > First I tried booting an Ultra10. That paniced immediately > > isp0: port 0x1000-0x10ff mem > 0x2808000-0x2808fff at device 4.0 on pci3 > isp0: invalid NVRAM header > isp1: port 0x2000-0x20ff mem > 0x290-0x2900fff at device 2.0 on pci2 > panic: trap: data access error (kernel) > cpuid = 0 > KDB: stack backtrace: > #0 0xc08588b4 at trap+0x554 > Uptime: 1s > > This may be a hardware thing so I did not pursue this further. Maybe Ultra10 > is > no longer supported, I don't know. (Ultra10s are crap anyway :) U10 are still supported, why should they have been dropped? :) In fact, the 9.2 images have been tested on a U10 before they were published. I also found an ISP 1040 card, which works just fine here. So this indeed could be a hardware problem causing a PCI access to fail, which typically causes very strange backtraces like the incomplete one above. > > Next I tried netbooting a V-120. That at least did not panic, but instead of > starting the installer it produced this message on the console > > cd0: Attempt to query device size failed: NOT READY, Medium not present > Trying to mount root from cd9660:/dev/iso9660/FREEBSD_INSTALL [ro]... > mountroot: waiting for device /dev/iso9660/FREEBSD_INSTALL ... > Mounting from cd9660:/dev/iso9660/FREEBSD_INSTALL failed with error 19. So far, that's expected as you seem to also have copied over the /etc/fstab from disc1. > Trying to mount root from nfs: []... > > At which point all I get is a single-user shell. > > Is installing via the network supported at all with the new bsd installer? Any > magic loader options I need to get this to work? > According to the /etc/rc.local that ends up on the ISO 9660 file system of the release images, netbooted installing indeed was thought of when these were switched to bsdinstall(8). Given that just copying over that one file to a NFS root properly fires up bsdinstall(8) after booting here and given that your netboot environment apparently also works just fine - except you refer to the mountroot prompt as single-user shell -, I've no idea what could be going wrong in your case ... Marius ___ 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: AAC regression in 9.2-BETA
On Fri, Aug 02, 2013 at 02:44:04PM -0400, David Boyd wrote: > I have an Adaptec 2820SA (SATA) controller that hangs the system during > booting on 9.2-BETA[12]. > The only message I see on the console refers to controller aac0 and > indicates "TIMEOUT 138 SECONDS". > This same controller/motherboard works flawlessly with 9.1-RELEASE-p5. > I have moved this hardware to "testing" mode and can rebuild often. > I am asking for direction and suggestions as to which commits might be at > fault. > I am sorry that I didn't detect this problem earlier in the release cycle. > Hope we can resolve this before 9.2-RELEASE. That could be due to MSIs being broken with your particular controller or mainboard. Please try whether setting the tunable hw.aac.enable_msi to 0 on the loader prompt before booting makes things work. If it does, please provide a verbose dmesg and the output of `pciconf -lcv`. Marius ___ 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: i386/179112: 9.1 installer panics with a kmem_malloc() failure on i386 embedded systems
On Thu, Aug 01, 2013 at 07:48:21AM -0700, Adrian Chadd wrote: > Did the kmem_size_scale parameter get changed too? Not AFAICT. > > Did you test this on 128mb or 256mb of RAM (in a VM will do) to see if > you still panic shortly after boot? Yup; I've built a snapshot from r253860 which can be downloaded here: http://people.freebsd.org/~marius/re/FreeBSD-9.2-BETA2-i386/ and installs fine here in a VM having 128 MB of RAM. > Doing any kind of file/net IO > quickly leads to death. That's a very vague description of a test case. At least extracting the six release tarballs is no longer a problem, though. Marius ___ 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: Strange reboot since 9.1
On Sun, Mar 10, 2013 at 08:19:04PM +0100, Loïc BLOT wrote: > Hi Marius, > sorry but you patch doesn't have effect, another crash with same > backtrace. Okay, thanks. Unfortunately, I'm running out of ideas for now. It seems that the problem isn't caused by a logic error within the driver then but rather some incorrect handling of the hardware. The public ally available documentation for these chips is heavily sanitized and totally unusable for writing drivers though. The only remaining thing to test I can think of is whether this issue is related to the header splitting, which is enabled by default. To disable, set the loader tunable hw.bce.hdr_split to 0 or to be really sure, change the bce_hdr_split default to FALSE in the driver and recompile it. Marius ___ 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: Strange reboot since 9.1
On Sat, Mar 09, 2013 at 09:53:54AM +0100, Loïc BLOT wrote: > Hi Marius > Thanks for your patch, but it has no effect for stability. The server > has rebooted this night after 8h uptime, same backtrace appears. Okay, could you please give the following patch a try instead in order to test another theory? http://people.freebsd.org/~marius/bce_rx_corruption.diff Marius ___ 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: Strange reboot since 9.1
On Fri, Mar 08, 2013 at 11:32:54AM +0900, YongHyeon PYUN wrote: > On Thu, Mar 07, 2013 at 08:38:27AM -0800, Jeremy Chadwick wrote: > > On Thu, Mar 07, 2013 at 04:38:54PM +0100, Lo?c Blot wrote: > > > Hi Marcelo, thanks. Here is a better trace: > > > > > > - > > > > > > kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.11 > > > GNU gdb 6.1.1 [FreeBSD] > > > Copyright 2004 Free Software Foundation, Inc. > > > GDB is free software, covered by the GNU General Public License, and you > > > are > > > welcome to change it and/or distribute copies of it under certain > > > conditions. > > > Type "show copying" to see the conditions. > > > There is absolutely no warranty for GDB. Type "show warranty" for > > > details. > > > This GDB was configured as "amd64-marcel-freebsd"... > > > > > > Unread portion of the kernel message buffer: > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 0; apic id = 00 > > > fault virtual address = 0x0 > > > fault code= supervisor read data, page not present > > > instruction pointer = 0x20:0x80a84414 > > > stack pointer = 0x28:0xff822fc267a0 > > > frame pointer = 0x28:0xff822fc26830 > > > code segment = base 0x0, limit 0xf, type 0x1b > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > current process = 12 (irq265: bce0) > > > trap number = 12 > > > panic: page fault > > > cpuid = 0 > > > KDB: stack backtrace: > > > #0 0x809208a6 at kdb_backtrace+0x66 > > > #1 0x808ea8be at panic+0x1ce > > > #2 0x80bd8240 at trap_fatal+0x290 > > > #3 0x80bd857d at trap_pfault+0x1ed > > > #4 0x80bd8b9e at trap+0x3ce > > > #5 0x80bc315f at calltrap+0x8 > > > #6 0x80a861d5 at udp_input+0x475 > > > #7 0x80a043dc at ip_input+0xac > > > #8 0x809adafb at netisr_dispatch_src+0x20b > > > #9 0x809a35cd at ether_demux+0x14d > > > #10 0x809a38a4 at ether_nh_input+0x1f4 > > > #11 0x809adafb at netisr_dispatch_src+0x20b > > > #12 0x80438fd7 at bce_intr+0x487 > > > #13 0x808be8d4 at intr_event_execute_handlers+0x104 > > > #14 0x808c0076 at ithread_loop+0xa6 > > > #15 0x808bb9ef at fork_exit+0x11f > > > #16 0x80bc368e at fork_trampoline+0xe > > > Uptime: 27m20s > > > Dumping 1265 out of 8162 > > > MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..92% > > > > > > #0 doadump (textdump=Variable "textdump" is not available. > > > ) at pcpu.h:224 > > > 224 pcpu.h: No such file or directory. > > > in pcpu.h > > > (kgdb) bt f > > > #0 doadump (textdump=Variable "textdump" is not available. > > > ) at pcpu.h:224 > > > No locals. > > > #1 0x808ea3a1 in kern_reboot (howto=260) > > > at /usr/src/sys/kern/kern_shutdown.c:448 > > > _ep = Variable "_ep" is not available. > > > (kgdb) bt > > > #0 doadump (textdump=Variable "textdump" is not available. > > > ) at pcpu.h:224 > > > #1 0x808ea3a1 in kern_reboot (howto=260) > > > at /usr/src/sys/kern/kern_shutdown.c:448 > > > #2 0x808ea897 in panic (fmt=0x1 ) > > > at /usr/src/sys/kern/kern_shutdown.c:636 > > > #3 0x80bd8240 in trap_fatal (frame=0xc, eva=Variable "eva" is > > > not available. > > > ) at /usr/src/sys/amd64/amd64/trap.c:857 > > > #4 0x80bd857d in trap_pfault (frame=0xff822fc266f0, > > > usermode=0) at /usr/src/sys/amd64/amd64/trap.c:773 > > > #5 0x80bd8b9e in trap (frame=0xff822fc266f0) > > > at /usr/src/sys/amd64/amd64/trap.c:456 > > > #6 0x80bc315f in calltrap () > > > at /usr/src/sys/amd64/amd64/exception.S:228 > > > #7 0x80a84414 in udp_append (inp=0xfe019e2a1000, > > > ip=0xfe00444b6c80, n=0xfe00444b6c00, off=20, > > > udp_in=0xff822fc268a0) at /usr/src/sys/netinet/udp_usrreq.c:252 > > > #8 0x80a861d5 in udp_input (m=0xfe00444b6c00, off=Variable > > > "off" is not available. > > > ) at /usr/src/sys/netinet/udp_usrreq.c:618 > > > #9 0x80a043dc in ip_input (m=0xfe00444b6c00) > > > at /usr/src/sys/netinet/ip_input.c:760 > > > #10 0x809adafb in netisr_dispatch_src (proto=1, source=Variable > > > "source" is not available. > > > ) at /usr/src/sys/net/netisr.c:1013 > > > #11 0x809a35cd in ether_demux (ifp=0xfe00053fa000, > > > m=0xfe00444b6c00) at /usr/src/sys/net/if_ethersubr.c:940 > > > #12 0x809a38a4 in ether_nh_input (m=Variable "m" is not > > > available. > > > ) at /usr/src/sys/net/if_ethersubr.c:759 > > > #13 0x809adafb in netisr_dispatch_src (proto=9, source=Variable > > > "source" is not available. > > > ) at /usr/src/sys/net/netisr.c:1013 > > > #14 0x80438fd7 in bce_intr (xsc=Variable "xsc" is not available. > > > ) at /usr/src/sys/dev/bce/if_bce.c:6903 > > > #15 0x808be8d4 in intr_event_execu
Re: msi-x enabled igb works only if module loaded twice [Was: Re: kldload if_igb twice needed to bring nic into operation]
On Tue, Oct 23, 2012 at 11:49:45AM +0200, Harald Schmalzbauer wrote: > schrieb Harald Schmalzbauer am 22.10.2012 21:48 (localtime): > > schrieb Harald Schmalzbauer am 22.10.2012 21:33 (localtime): > >> Hello, > >> > >> when using igb as module, no packet is received. > >> If I send out anything, I see the packet with tcpdump, also the switch > >> learns the MAC address, but nothing comes back in - total silenc, no > >> boradcasts, nothing. > >> If I unload the module and load it again, everything works as expected! > >> No matter if I load it by 4th loader, or later, I always have tio unload > >> first then load it again. > >> I'ts late here, I'll see tomorrow if things change when compieled into > >> kernel. > > It doesn't matter if igb is loaded as module or compiled into kernel. > > >> Maby somebody has an idea what the source of the problem could be. > >> Please find atteched some info, the OS is 9-RC2-amd64 on ESXi5.1 and > >> nics are pci-passthrough. > > I found one possibly relevant difference: > > > > Non-Working state:dev.igb.0.link_irq: 0 > > Working state: dev.igb.0.link_irq: 2 > > This is only true with msi-x!!! > If I disable mis-x, the problem itself vanishes. igb just works fine > from the initial loading (with dev.igb.0.link_irq=0!). > So dev.igb.0.link_irq is only relevant with msi-x. > But what makes me curious is why it also works mith mis-x enabled after > the second kldload!?! Hrm, this is strange; in r231621 (MFC'ed to stable/9 in r232092, so it's part of 9.1-RC2) I've blacklisted the fictitious PCI-PCI bridge VMware uses in case of PCI pass-through for MSI/MSI-X (as in the cases observed it didn't even work with a single MSI-X message). So unless they've changed the ID of the fictitious bridge, igb(4) should fail to allocate a MSI/MSI-X in the first place. Could you please provide the output of `pciconf -lv` on that "system"? Marius ___ 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: Boot hangs on v9 system at CD device probe
On Fri, Jun 15, 2012 at 09:16:16AM +0200, Oliver Fromme wrote: > Marius Strobl wrote: > > [...] > > > > > > > http://people.freebsd.org/~marius/ata_ite_ATA_CAM_ATA_NO_ATAPI_DMA.diff > > [...] > > > > I've committed it to head in r237107 as a band-aid for now as it's a > > sufficiently severe problem. Obviously, fixing ATA_CAM to not break > > ATAPI CAM instead is the right thing to do. I've already spent quite > > some time trying to find the underlying but didn't get anywhere with > > that so far though (granted, most of that wasted time was because of > > me thinking that this would be due to an endian bug only seen on big > > endian machines, which turned out to not be the case). AFAICT, mav@ > > also has ALI hardware affected by this issue, maybe he'll have a > > look at it eventually ... > > I'm not sure if it's the same or a different issue, but ATA_CAM > also breaks for me with a legacy P-ATA controller (UDMA-133) on > RELENG_9. Removing ATA_CAM and adding "atapicam" fixes it. > > I've described the problem in more detail here: > http://lists.freebsd.org/pipermail/freebsd-stable/2012-June/068175.html > > This is the controller in question: > > pciconf: > atapci0@pci0:3:6:0: class=0x018085 card=0x4d68105a chip=0x4d69105a > rev=0x02 hdr=0x00 > vendor = 'Promise Technology, Inc.' > device = '20269' > class = mass storage > > dmesg: > atapci0: port 0xdc00-0xdc07, > 0xd880-0xd883,0xd800-0xd807,0xcc00-0xcc03,0xc880-0xc88f mem > 0xfeaf8000-0xfeafbfff irq 21 at device 6.0 on pci3 This likely is a different issue as atapromise(4) already disables ATAPI DMA by default since before ATA_CAM hit the tree. > > Shall I open a PR with this? > It probably won't hurt to file one and assign it to mav@. Marius ___ 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: Boot hangs on v9 system at CD device probe
On Tue, Jun 12, 2012 at 03:17:47PM -0700, Kevin Oberman wrote: > On Sat, Jun 9, 2012 at 3:29 PM, Marius Strobl > wrote: > > On Sat, Jun 09, 2012 at 02:38:53PM -0700, Kevin Oberman wrote: > >> On Sat, Jun 9, 2012 at 5:13 AM, Marius Strobl > >> wrote: > >> > On Fri, Jun 08, 2012 at 10:11:48PM -0700, Kevin Oberman wrote: > >> >> On Thu, May 31, 2012 at 9:10 AM, Kevin Oberman > >> >> wrote: > >> >> I just did the obvious as suggested and built a kernel without ATA_CAM > >> >> and with atapicam. It boots fine and I have my CD/DVD working on 9.0. > >> >> Clearly, there is some issue with ATAPI drives with ATA_CAM as others > >> >> have seen the same thing. It is entirely possible that a serial > >> >> connected drives don't have this issue. It does look like there is > >> >> some locking issue between CAM and GEOM under some circumstances. I > >> >> worry that 10 will lose support for other than ATA_CAM and that the > >> >> work-around will no longer be available. Of course, if ahci fixes it, > >> >> the problem will go away on systems that support it. > >> >> > >> >> Next time I get to the system I will try putting ATA_CAM back and > >> >> adding ahci and report on the results. > >> >> > >> > > >> > I don't think that the latter test makes much sense as the above > >> > mentioned controller doesn't support AHCI. If you could test > >> > whether the following patch works around the issue when using > >> > ATA_CAM that would be more useful. > >> > http://people.freebsd.org/~marius/ata_ite_ATA_CAM_ATA_NO_ATAPI_DMA.diff > >> > >> Will do. It will be a couple of days, though, as I am currently in the > >> process of updating the 1000 ports installed on that system for the > >> major version update. When that is complete, I'll try to get to the > >> location of the system and see if it does the job. Mondy has several > >> meetings, so it will probably be at least Tuesday. > > > > No hurry ... > > I installed the patch and it worked. 9.0-Stable system with ATA_CAM > and cdrom now boot correctly. > > Thanks! > > Will this be committed to head and MFCed soon? I've committed it to head in r237107 as a band-aid for now as it's a sufficiently severe problem. Obviously, fixing ATA_CAM to not break ATAPI CAM instead is the right thing to do. I've already spent quite some time trying to find the underlying but didn't get anywhere with that so far though (granted, most of that wasted time was because of me thinking that this would be due to an endian bug only seen on big endian machines, which turned out to not be the case). AFAICT, mav@ also has ALI hardware affected by this issue, maybe he'll have a look at it eventually ... Marius ___ 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: mpt: Unable to memory map registers
On Sat, Jun 09, 2012 at 12:58:05PM +0400, Andrey Zonov wrote: > On 6/8/12 10:27 PM, John Baldwin wrote: > >On Friday, June 08, 2012 11:48:50 am Andrey Zonov wrote: > >>On Fri, Jun 8, 2012 at 7:19 PM, John Baldwin wrote: > >>>On Friday, June 08, 2012 3:14:19 am Andrey Zonov wrote: > On 6/7/12 10:02 PM, Andrey Zonov wrote: > >Hi, > > > >I just upgraded a few machines from 8.2-STABLE (r221983) to 9.0-STABLE > >(r234600) and now they can't find any disk because SAS controller > >cannot > >initialize with the following diagnostic: > > > >mpt0: port 0xd000-0xd0ff irq 26 at device > >3.0 on pci6 > >mpt0: 0x4000 bytes of rid 0x14 res 3 failed (0, 0x). > >mpt0: Unable to memory map registers. > >mpt0: Giving Up. > > > >pciconf -lv: > >mpt0@pci0:6:3:0: class=0x01 card=0x81dd1043 chip=0x00541000 > >rev=0x02 > >hdr=0x00 > >vendor = 'LSI Logic / Symbios Logic' > >device = 'SAS1068 PCI-X Fusion-MPT SAS' > >class = mass storage > >subclass = SCSI > > > >I tried to boot to latest HEAD and found the same problem. I also tried > >to build kernel with mpt driver from my 8.2. Controller didn't > >initialize with the same diagnostic. So it looks like the problem is > >not > >in mpt driver. > > > >Any help would be appreciated. > > > > +jhb@ > > Hi John, > > Could you please help me with the problem above? It looks like the > problem is in PCI code and you changed things there. > >>> > >>>Can you get a verbose dmesg? > >>> > >> > >>Yes, it's in attach. > > > >Can you get the output of 'devinfo -u' and 'devinfo -rv' from a broken > >kernel? > > > > Attached. > > >Can you also try setting 'debug.acpi.disable=sysres' in the loader? > > > > Didn't help. > That's probably due to a typo, the corret loader tunable is debug.acpi.disabled=sysres (note the 'd'). Marius ___ 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: Boot hangs on v9 system at CD device probe
On Fri, Jun 08, 2012 at 10:11:48PM -0700, Kevin Oberman wrote: > On Thu, May 31, 2012 at 9:10 AM, Kevin Oberman wrote: > > On Thu, May 31, 2012 at 4:02 AM, Marius Strobl > > wrote: > >> On Wed, May 30, 2012 at 05:13:44PM -0600, Ian Lepore wrote: > >>> On Wed, 2012-05-30 at 14:54 -0700, Kevin Oberman wrote: > >>> > I sent a note about this a couple of weeks ago, but have not heard > >>> > anything. I'm really getting a bit desperate. > >>> > > >>> > I have a system that I am trying to upgrade from 8.2 to 9.0. I have > >>> > built it and installed the kernel, but it fails to boot. The boot > >>> > freezes after probing for my hard drives during the probe of the > >>> > CDROM. It just sits there, seemingly forever, though I have never > >>> > waited longer then a few minutes. > >>> > > >>> > The system is a SuperMicro C25BX mother board. The DVD is PATA, > >>> > reported on boot of 8-Stable as: > >>> > acd0: DVDR at ata2-master UDMA66 > >>> > > >>> > If I unplug the CDROM, it boots fine, but I really need the device on > >>> > the system, so I really can't leave it unplugged. Also, after the 9 > >>> > kernel is installed, my Mk file have been updated so that I can't > >>> > build some ports if I boot the 8.2 kernel. Does anyone remember this > >>> > being reported by others? It was most likely on current, as it was > >>> > probably prior to the release of 9. I googled around, but could not > >>> > find it. > >>> > > >>> > I'd really appreciate it if anyone can point me toward a solution. > >>> > > >>> > Thanks, > >>> > >>> When faced with a mystery like this I sometimes go into the mode of > >>> "poke it with a stick and see if it twitches." ?If you can get it to > >>> twitch at all, maybe that's a starting point. ?In this case, I guess I > >>> might start with seeing if setting hw.ata.atapi_dma=0 in the loader > >>> makes any difference. > >>> > >> > >> Note that hw.ata.atapi_dma isn't honored by 9.0 with options ATA_CAM > >> (default in GENERIC). Support for that loader tuneable was only > >> resurrected rather recently (but is available in stable/9). The > >> equivalent for 9.0 would be setting hint.ata.X.mode to PIO4 where > >> X is the number of the ata(4) device attached for the channel the > >> CDROM is connected to. > >> ATA_CAM is indeed known to break ATAPI DMA for some ATA controllers > >> though. What's the `pciconf -lv` output for this one? > > > > Good point. I had forgotten about the hw.ata.atapi_dma removal and was > > not even awarethat it had been recently re-enabled. > > My controller is: > > atapci0@pci0:17:4:0: ? ?class=0x010185 card=0x82131283 chip=0x82131283 > > rev=0x00 hdr=0x00 > > ? ?vendor ? ? = 'Integrated Technology Express (ITE) Inc' > > ? ?device ? ? = 'IDE Controller (IT8213F)' > > ? ?class ? ? ?= mass storage > > ? ?subclass ? = ATA > > > > It is used ONLY for the CD/DVD as all other disks use the 3ware RAID > > controller. > > > > Unfortunately, the system is not located where I am, so I can't really > > try anything until I get over there. Maybe later today I can run into > > that office and try some of the suggestions. I can certainly build a > > kernel without ATA_CAM. > > I just did the obvious as suggested and built a kernel without ATA_CAM > and with atapicam. It boots fine and I have my CD/DVD working on 9.0. > Clearly, there is some issue with ATAPI drives with ATA_CAM as others > have seen the same thing. It is entirely possible that a serial > connected drives don't have this issue. It does look like there is > some locking issue between CAM and GEOM under some circumstances. I > worry that 10 will lose support for other than ATA_CAM and that the > work-around will no longer be available. Of course, if ahci fixes it, > the problem will go away on systems that support it. > > Next time I get to the system I will try putting ATA_CAM back and > adding ahci and report on the results. > I don't think that the latter test makes much sense as the above mentioned controller doesn't support AHCI. If you could test whether the following patch works around the issue when using ATA_CAM that would be more useful. http://people.freebsd.org/~marius/ata_ite_ATA_CAM_ATA_NO_ATAPI_DMA.diff Marius ___ 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: Boot hangs on v9 system at CD device probe
On Wed, May 30, 2012 at 05:13:44PM -0600, Ian Lepore wrote: > On Wed, 2012-05-30 at 14:54 -0700, Kevin Oberman wrote: > > I sent a note about this a couple of weeks ago, but have not heard > > anything. I'm really getting a bit desperate. > > > > I have a system that I am trying to upgrade from 8.2 to 9.0. I have > > built it and installed the kernel, but it fails to boot. The boot > > freezes after probing for my hard drives during the probe of the > > CDROM. It just sits there, seemingly forever, though I have never > > waited longer then a few minutes. > > > > The system is a SuperMicro C25BX mother board. The DVD is PATA, > > reported on boot of 8-Stable as: > > acd0: DVDR at ata2-master UDMA66 > > > > If I unplug the CDROM, it boots fine, but I really need the device on > > the system, so I really can't leave it unplugged. Also, after the 9 > > kernel is installed, my Mk file have been updated so that I can't > > build some ports if I boot the 8.2 kernel. Does anyone remember this > > being reported by others? It was most likely on current, as it was > > probably prior to the release of 9. I googled around, but could not > > find it. > > > > I'd really appreciate it if anyone can point me toward a solution. > > > > Thanks, > > When faced with a mystery like this I sometimes go into the mode of > "poke it with a stick and see if it twitches." If you can get it to > twitch at all, maybe that's a starting point. In this case, I guess I > might start with seeing if setting hw.ata.atapi_dma=0 in the loader > makes any difference. > Note that hw.ata.atapi_dma isn't honored by 9.0 with options ATA_CAM (default in GENERIC). Support for that loader tuneable was only resurrected rather recently (but is available in stable/9). The equivalent for 9.0 would be setting hint.ata.X.mode to PIO4 where X is the number of the ata(4) device attached for the channel the CDROM is connected to. ATA_CAM is indeed known to break ATAPI DMA for some ATA controllers though. What's the `pciconf -lv` output for this one? Marius ___ 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: lost devices in 8.3
On Sun, Apr 22, 2012 at 12:17:45PM +0300, Daniel Braniss wrote: > hi, > I'm trying to upgrade this old opteron box, which is running 8.2, but > when booting 8.3 the disks disappear. > > with 8.2: > ... > atapci1@pci0:0:7:1: class=0x01018a card=0x74691022 chip=0x74691022 > rev=0x03 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = 'UltraATA/133 Controller (AMD-8111)' > class = mass storage > subclass = ATA > ... > atapci0@pci0:3:5:0: class=0x010400 card=0x61141095 chip=0x31141095 > rev=0x02 hdr=0x00 > vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' > device = 'SATALink/SATARaid Controller (Sil 3114)' > class = mass storage > subclass = RAID > > but none on 8.3: > none0@pci0:0:7:1: class=0x01018a card=0x74691022 chip=0x74691022 > rev=0x03 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = 'UltraATA/133 Controller (AMD-8111)' > class = mass storage > subclass = ATA > ... > none3@pci0:3:5:0: class=0x018000 card=0x31141095 chip=0x31141095 > rev=0x02 hdr=0x00 > vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' > device = 'SATALink/SATARaid Controller (Sil 3114)' > class = mass storage > > and the only diff in the configuration is that 8.3 has: > options ATA_CAM > nodevice ata You need "device ata". > nodevice atadisk # ATA disk drives > nodevice ataraid # ATA RAID drives > nodevice atapicd # ATAPI CDROM drives > nodevice atapifd # ATAPI floppy drives > nodevice atapist # ATAPI tape drives > Marius ___ 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: 8.3-PRERELEASE and ATA_CAM
On Sat, Apr 07, 2012 at 01:52:05PM +0200, Marius Strobl wrote: > On Sat, Apr 07, 2012 at 10:53:39AM +0300, Daniel Braniss wrote: > > > On Fri, Apr 06, 2012 at 10:48:13AM +0300, Daniel Braniss wrote: > > > > with the latest svn, I can't compile kernel with options ATA_CAM: > > > > > > > > ... > > > > linking kernel.debug > > > > ata-disk.o(.text+0x93): In function `ad_init': > > > > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:389: undefined reference to > > > > `ata_setmode' > > > > ata-disk.o(.text+0xaa):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:397: > > > > undefined > > > > reference to `ata_wc' > > > > ata-disk.o(.text+0xc5):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:398: > > > > undefined > > > > reference to `ata_controlcmd' > > > > ata-disk.o(.text+0x113):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:400: > > > > undefined > > > > reference to `ata_controlcmd' > > > > ata-disk.o(.text+0x133):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:393: > > > > undefined > > > > reference to `ata_controlcmd' > > > > ata-disk.o(.text+0x16d):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:407: > > > > undefined > > > > reference to `ata_controlcmd' > > > > ata-disk.o(.text+0x21a): In function `ad_shutdown': > > > > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:196: undefined reference to > > > > `ata_controlcmd' > > > > ata-disk.o(.text+0x45c): In function `ad_detach': > > > > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:182: undefined reference to > > > > `ata_fail_requests' > > > > ... > > > > > > > > > > You seem to be using a mutually exclusive set of ata(4) options and > > > devices (previously, this erroneously wasn't a bug). When including > > > options ATA_CAM you do _not_ want to also include any of the following > > > devices: > > > deviceatapicam > > > deviceatadisk > > > deviceataraid > > > deviceatapicd > > > deviceatapifd > > > deviceatapist > > > > > > Instead you need the corresponding driver from the following set: > > > devicescbus > > > devicech > > > deviceda > > > devicesa > > > devicecd > > > devicepass > > > > > > Marius > > > > > they are included by GENERIC, which i include, bummer. > > It should work to include GENERIC but disable the "old" devices via > "nodevice atadisk" etc. in your custom kernel configuration file. > > > what about ATA_STATIC_ID, I guess that is also a nono? > > No, ATA_STATIC_ID is still available with ATA_CAM, in this case it's > purpose is a bit different though; when present, it provides /dev/adX > symbolic links to the /dev/adaY device nodes, trying to mimic the > non-ATA_CAM numbering for /dev/adX. If you've already updated your > /etc/fstab etc. to use /dev/adaY instead, you don't need ATA_STATIC_ID > though. > Sorry, I've just checked the source and the code for ATA_STATIC_ID with ATA_CAM actually is only present in FreeBSD 9 and 10. With FreeBSD 8 ATA_STATIC_ID in combination with ATA_CAM just does nothing, but also doesn't pose any problem either. Marius ___ 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: 8.3-PRERELEASE and ATA_CAM
On Sat, Apr 07, 2012 at 10:53:39AM +0300, Daniel Braniss wrote: > > On Fri, Apr 06, 2012 at 10:48:13AM +0300, Daniel Braniss wrote: > > > with the latest svn, I can't compile kernel with options ATA_CAM: > > > > > > ... > > > linking kernel.debug > > > ata-disk.o(.text+0x93): In function `ad_init': > > > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:389: undefined reference to > > > `ata_setmode' > > > ata-disk.o(.text+0xaa):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:397: > > > undefined > > > reference to `ata_wc' > > > ata-disk.o(.text+0xc5):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:398: > > > undefined > > > reference to `ata_controlcmd' > > > ata-disk.o(.text+0x113):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:400: > > > undefined > > > reference to `ata_controlcmd' > > > ata-disk.o(.text+0x133):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:393: > > > undefined > > > reference to `ata_controlcmd' > > > ata-disk.o(.text+0x16d):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:407: > > > undefined > > > reference to `ata_controlcmd' > > > ata-disk.o(.text+0x21a): In function `ad_shutdown': > > > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:196: undefined reference to > > > `ata_controlcmd' > > > ata-disk.o(.text+0x45c): In function `ad_detach': > > > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:182: undefined reference to > > > `ata_fail_requests' > > > ... > > > > > > > You seem to be using a mutually exclusive set of ata(4) options and > > devices (previously, this erroneously wasn't a bug). When including > > options ATA_CAM you do _not_ want to also include any of the following > > devices: > > device atapicam > > device atadisk > > device ataraid > > device atapicd > > device atapifd > > device atapist > > > > Instead you need the corresponding driver from the following set: > > device scbus > > device ch > > device da > > device sa > > device cd > > device pass > > > > Marius > > > they are included by GENERIC, which i include, bummer. It should work to include GENERIC but disable the "old" devices via "nodevice atadisk" etc. in your custom kernel configuration file. > what about ATA_STATIC_ID, I guess that is also a nono? No, ATA_STATIC_ID is still available with ATA_CAM, in this case it's purpose is a bit different though; when present, it provides /dev/adX symbolic links to the /dev/adaY device nodes, trying to mimic the non-ATA_CAM numbering for /dev/adX. If you've already updated your /etc/fstab etc. to use /dev/adaY instead, you don't need ATA_STATIC_ID though. Marius ___ 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: 8.3-PRERELEASE and ATA_CAM
On Fri, Apr 06, 2012 at 10:48:13AM +0300, Daniel Braniss wrote: > with the latest svn, I can't compile kernel with options ATA_CAM: > > ... > linking kernel.debug > ata-disk.o(.text+0x93): In function `ad_init': > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:389: undefined reference to > `ata_setmode' > ata-disk.o(.text+0xaa):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:397: undefined > reference to `ata_wc' > ata-disk.o(.text+0xc5):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:398: undefined > reference to `ata_controlcmd' > ata-disk.o(.text+0x113):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:400: undefined > reference to `ata_controlcmd' > ata-disk.o(.text+0x133):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:393: undefined > reference to `ata_controlcmd' > ata-disk.o(.text+0x16d):/r+d/stable/8.3/sys/dev/ata/ata-disk.c:407: undefined > reference to `ata_controlcmd' > ata-disk.o(.text+0x21a): In function `ad_shutdown': > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:196: undefined reference to > `ata_controlcmd' > ata-disk.o(.text+0x45c): In function `ad_detach': > /r+d/stable/8.3/sys/dev/ata/ata-disk.c:182: undefined reference to > `ata_fail_requests' > ... > You seem to be using a mutually exclusive set of ata(4) options and devices (previously, this erroneously wasn't a bug). When including options ATA_CAM you do _not_ want to also include any of the following devices: device atapicam device atadisk device ataraid device atapicd device atapifd device atapist Instead you need the corresponding driver from the following set: device scbus device ch device da device sa device cd device pass Marius ___ 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: r232411 breaks onboard 1068 detection
On Wed, Apr 04, 2012 at 02:38:54AM +0400, Andrew Pantyukhin wrote: > On Wed, Apr 4, 2012 at 2:33 AM, Marius Strobl > wrote: > > On Wed, Apr 04, 2012 at 02:26:38AM +0400, Andrew Pantyukhin wrote: > >> The device in question is a built-in 1068-based controller on a > >> SuperMicro X8ST3 board. > >> > >> It can be converted to MegaRAID mode with a special addon "button" > >> (AOC-IButton68). > >> > >> http://www.supermicro.com/products/motherboard/Xeon3000/X58/X8ST3-F.cfm > > > > Okay, so unless these devices also can be driven by mfi(4) when not > > in MegaRAID mode, we need a way to tell both modes apart in the probe > > functions of both drivers. > > mfi(4) obviously didn't attach, but if anyone is willing to provide a > quick patch listing the IDs in mfi(4), I'll try. > > I wouldn't welcome the change though, as we prefer the JBOD way. I still highly doubt that 0x59 will work with mfi(4) in non-MegaRAID mode. Looking at the source of the Linux megasr driver, that one attaches to several 0x59 devices but only in case of certain sub-vendor (amongst other Supermicro) and sub-device IDs, but not in case of a sub-vendor ID of LSI and a sub-device ID of 0x1000 like in your case. So this seems like a way to go to distinguish the modes if LSI can provide a complete list of sub-device IDs (and sub-vendor in case something besides LSI is used) in which case 0x59 should be treated in MPT mode. Marius ___ 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: r232411 breaks onboard 1068 detection
On Wed, Apr 04, 2012 at 02:26:38AM +0400, Andrew Pantyukhin wrote: > On Wed, Apr 4, 2012 at 1:57 AM, Marius Strobl > wrote: > > On Tue, Apr 03, 2012 at 03:52:14PM -0600, McConnell, Stephen wrote: > >> Marius, > >> > >> Since the 0x59 device is a MegaRAID device, shouldn't you be using the > >> MegaRAID driver. ??Why is the MPT driver being used in this case? ??The > >> problem is that the MPT driver was wrongly attaching to some MegaRAID > >> controllers and that was causing conflict problems, so that was fixed by > >> removing MegaRAID ID's from the MPT driver. > > > > Apparently, the 0x59 devices worked just fine using mpt(4) before r232411. > > Are MegaRAID devices backwards-compatible so they can alternatively be > > driven by MPT drivers? > > The device in question is a built-in 1068-based controller on a > SuperMicro X8ST3 board. > > It can be converted to MegaRAID mode with a special addon "button" > (AOC-IButton68). > > http://www.supermicro.com/products/motherboard/Xeon3000/X58/X8ST3-F.cfm Okay, so unless these devices also can be driven by mfi(4) when not in MegaRAID mode, we need a way to tell both modes apart in the probe functions of both drivers. Marius ___ 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: r232411 breaks onboard 1068 detection
On Tue, Apr 03, 2012 at 03:52:14PM -0600, McConnell, Stephen wrote: > Marius, > > Since the 0x59 device is a MegaRAID device, shouldn't you be using the > MegaRAID driver. Why is the MPT driver being used in this case? The problem > is that the MPT driver was wrongly attaching to some MegaRAID controllers and > that was causing conflict problems, so that was fixed by removing MegaRAID > ID's from the MPT driver. > Apparently, the 0x59 devices worked just fine using mpt(4) before r232411. Are MegaRAID devices backwards-compatible so they can alternatively be driven by MPT drivers? Marius ___ 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: r232411 breaks onboard 1068 detection
On Tue, Apr 03, 2012 at 09:13:14AM -0600, Kenneth D. Merry wrote: > On Tue, Apr 03, 2012 at 10:29:27 +0200, Marius Strobl wrote: > > On Tue, Apr 03, 2012 at 05:55:19AM +0400, Andrew Pantyukhin wrote: > > > Hello, > > > > > > r232411 broke onboard 1068 detection on all boxes with SuperMicro > > > X8ST3 motherboards for us. > > > > > > All of them are also equipped with two extra 1068 controllers, which > > > are detected fine. Reverting to r231518 with otherwise latest stable > > > kernel works around the problem. > > > > > > The issue is still there at r233425. > > > > > > Here's the disappearing device: > > > > > > mpt2@pci0:5:0:0:class=0x01 card=0x10001000 chip=0x00591000 > > > rev=0x08 hdr=0x00 > > > vendor = 'LSI Logic / Symbios Logic' > > > device = 'MegaRAID SAS 8208ELP/8208ELP' > > > class = mass storage > > > subclass = SCSI > > > > > > > Should be fixed in r233827. > > We should get this into 8.3 if that is still possible. Otherwise folks > with these machines will not be able to boot 8.3. > I'll try but based on previous experiences it's just too late in the release cycle. Marius ___ 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: r232411 breaks onboard 1068 detection
On Tue, Apr 03, 2012 at 10:29:27AM +0200, Marius Strobl wrote: > On Tue, Apr 03, 2012 at 05:55:19AM +0400, Andrew Pantyukhin wrote: > > Hello, > > > > r232411 broke onboard 1068 detection on all boxes with SuperMicro > > X8ST3 motherboards for us. > > > > All of them are also equipped with two extra 1068 controllers, which > > are detected fine. Reverting to r231518 with otherwise latest stable > > kernel works around the problem. > > > > The issue is still there at r233425. > > > > Here's the disappearing device: > > > > mpt2@pci0:5:0:0:class=0x01 card=0x10001000 chip=0x00591000 > > rev=0x08 hdr=0x00 > > vendor = 'LSI Logic / Symbios Logic' > > device = 'MegaRAID SAS 8208ELP/8208ELP' > > class = mass storage > > subclass = SCSI > > > > Should be fixed in r233827. > Btw., Kashyap, could you please trigger LSI to update their mpi_cnfg.h to include all the device IDs that actually should be handled by MPT drivers. The FreeBSD mpt(4) additionally knows about the devices below, which based on the fact they are not probed by the Linux counterpart and are not found in PCI ID lists might not even exist in the wild, or as in the above case, still might miss some actual devices not currently found in mpi_cnfg.h. #define MPI_MANUFACTPAGE_DEVICEID_FC909_FB 0x0620 #define MPI_MANUFACTPAGE_DEVICEID_FC919_LAN_FB 0x0625 #define MPI_MANUFACTPAGE_DEVICEID_FC929_LAN_FB 0x0623 #define MPI_MANUFACTPAGE_DEVICEID_FC929X_LAN_FB 0x0627 #define MPI_MANUFACTPAGE_DEVICEID_FC919X_LAN_FB 0x0629 #define MPI_MANUFACTPAGE_DEVID_SAS1068A_FB 0x0055 #define MPI_MANUFACTPAGE_DEVID_SAS1068E_FB 0x0059 #define MPI_MANUFACTPAGE_DEVID_SAS1078DE_FB 0x007C Marius ___ 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: r232411 breaks onboard 1068 detection
On Tue, Apr 03, 2012 at 05:55:19AM +0400, Andrew Pantyukhin wrote: > Hello, > > r232411 broke onboard 1068 detection on all boxes with SuperMicro > X8ST3 motherboards for us. > > All of them are also equipped with two extra 1068 controllers, which > are detected fine. Reverting to r231518 with otherwise latest stable > kernel works around the problem. > > The issue is still there at r233425. > > Here's the disappearing device: > > mpt2@pci0:5:0:0:class=0x01 card=0x10001000 chip=0x00591000 > rev=0x08 hdr=0x00 > vendor = 'LSI Logic / Symbios Logic' > device = 'MegaRAID SAS 8208ELP/8208ELP' > class = mass storage > subclass = SCSI > Should be fixed in r233827. Marius ___ 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 9.0-RELEASE - Trouble Booting on SPARC64 - kmem_suballoc error
On Sun, Feb 26, 2012 at 05:31:35PM -0500, Garrett R. Groesbeck wrote: > Hello, > > I hope you are well. I've been working on a Sun Blade 2000 with FreeBSD 9.0 > (sparc64) installed. > > There's trouble with /boot/loader.conf when you try to boot the install disc > (and even after the install when I try to boot up): > > panic: kmem_suballoc: bad status return of 3 > > So when it gives me the chance to enter a boot command, I enter the > following: > > OK set hw.physmem=1048576000 > That apparently is a bug in the MI part of the VM triggered by the highly fragment physical memory of b1k and b2k with 2 GB of RAM. You can work around it by setting the vm.kmem_size_scale tunable to 2 without sacrificing physical memory. The latter meanwhile is also the default set by the MD part, awaiting further clues from alc@. Marius ___ 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: 9-stable - ifmedia_set: no match for 0x0/0xfffffff
On Sun, Jan 29, 2012 at 04:56:28AM +0900, Randy Bush wrote: > > Hrm, the problem apparently is that while when probing, the PHY > > still knows about the media it supports, it just has forgotten > > about it after the reset during attach. There was a change prior > > to 8.2 which would turn this from silently being ignored (which > > generally might or might not work) into resulting what you see > > now (the upper layers arguably shouldn't trigger a panic in this > > case though). I can't remember a change to either bge(4) or > > brgphy(4) between 8.2 and now which could trigger this though. > > Have you tried to set the loader-tunable hw.bge.allow_asf to 0? > > The default for that option still is different between 8 and 9+. > > it no longer panics when booting, but the interface comes up not seeing > carrier > > bge0: flags=8843 metric 0 mtu 1500 > > options=8009b > ether 00:30:48:82:11:a2 > inet 198.180.150.1 netmask 0xff80 broadcast 198.180.150.127 > inet6 fe80::230:48ff:fe82:11a2%bge0 prefixlen 64 scopeid 0x1 > inet6 2001:418:8006::1 prefixlen 64 > inet 198.180.150.2 netmask 0x broadcast 198.180.150.2 > nd6 options=21 > media: Ethernet 1000baseT (none) > status: no carrier > Are you sure that the other end is also forced to 1000baseT half-duplex? What happens if you set hw.bge.allow_asf to 0 and use auto-negotiation on both sides? Marius ___ 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: 9-stable - ifmedia_set: no match for 0x0/0xfffffff
On Sat, Jan 28, 2012 at 09:34:04PM +0900, Randy Bush wrote: > >> ok, i > >> o used device.hints to disable both bge interfaces > >> o booted successfully > >> o used serial console > >> o ifconfiged bge0 to the normal addresses > >> o and it is working > >> > >> i suspect that something sucks in bge initialization at startup. > >> insightful, i know. sorry. > > > > Has that worked before with FreeBSD and if yes with which reversion? > > yes, the bge and config worked for a long time on 7.foo and 8.foo, most > recently 8.2. > Hrm, the problem apparently is that while when probing, the PHY still knows about the media it supports, it just has forgotten about it after the reset during attach. There was a change prior to 8.2 which would turn this from silently being ignored (which generally might or might not work) into resulting what you see now (the upper layers arguably shouldn't trigger a panic in this case though). I can't remember a change to either bge(4) or brgphy(4) between 8.2 and now which could trigger this though. Have you tried to set the loader-tunable hw.bge.allow_asf to 0? The default for that option still is different between 8 and 9+. Marius ___ 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: 9-stable - ifmedia_set: no match for 0x0/0xfffffff
On Thu, Jan 26, 2012 at 12:24:11PM +0900, Randy Bush wrote: > ok, i > o used device.hints to disable both bge interfaces > o booted successfully > o used serial console > o ifconfiged bge0 to the normal addresses > o and it is working > > i suspect that something sucks in bge initialization at startup. > insightful, i know. sorry. > Has that worked before with FreeBSD and if yes with which reversion? Marius ___ 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: Booting problem for FreeBSD SPARC64
On Fri, Jan 20, 2012 at 09:18:20PM +0530, Desai, Kashyap wrote: > Hi, > > I am using below machine and seeing some basic installation problem with > FreeBSD 8.2 and 9.0 ( I have not tried other releases) > > Sun SPARC Enterprise M3000 Server, using Domain console > Copyright 2008 Sun Microsystems, Inc. All rights reserved. > Copyright 2008 Sun Microsystems, Inc. and Fujitsu Limited. All rights > reserved. > OpenBoot 4.24.10, 4096 MB memory installed, Serial #10031494. > Ethernet address 0:b:5d:e2:11:86, Host ID: 80991186. > > > Here is error message. > > Rebooting with command: boot cdrom > Boot device: /pci@0,60/pci@0/pci@0/scsi@0/disk@4,0:f File and args: > > >> FreeBSD/sparc64 boot block >Boot path: /pci@0,60/pci@0/pci@0/scsi@0/disk@4,0:f >Boot loader: /boot/loader > Consoles: Open Firmware console > > Booting with sun4u support. > panic: tlb_init_sun4u: no node for bootcpu?!?! > --> Press a key on the console to reboot <-- > > Is there any work around/solution for this issue ? > Yes, implement support for the Mx000 class of machines :) So far I couldn't do that due to lack of such hardware. Marius ___ 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: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII]
On Sun, Oct 16, 2011 at 02:46:23AM +0200, Damien Fleuriot wrote: > > > On 15 Oct 2011, at 22:56, Marius Strobl wrote: > > > > > Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for > > rl(4) only 8129 need testing, 8139 don't) please give the following > > patch a try in order to ensure it doesn't break anything? > > for 9/head: > > http://people.freebsd.org/~marius/mii_bitbang.diff > > for 8: > > http://people.freebsd.org/~marius/mii_bitbang.diff8 > > > > Thanks, > > Marius > > > > > While I don't have any box with this hardware, I'm thinking you might want to > get a bit more specific about what you want tested... > > What do you think the patch might break ? > Basically, if there's something wrong with the patch the driver should fail to attach, if it still does and gets a link all should be fine. Marius ___ 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"
nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII]
Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for rl(4) only 8129 need testing, 8139 don't) please give the following patch a try in order to ensure it doesn't break anything? for 9/head: http://people.freebsd.org/~marius/mii_bitbang.diff for 8: http://people.freebsd.org/~marius/mii_bitbang.diff8 Thanks, Marius ___ 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: mpt0 timeouts with an intel SASUC8I controller
On Mon, Sep 19, 2011 at 09:13:53PM +0200, Thomas Vogt wrote: > Hi Marius > > On 19.09.2011, at 21:06, Marius Strobl wrote: > > > On Mon, Sep 19, 2011 at 02:45:04PM +0200, Thomas Vogt wrote: > >> Hello > >> > >> I've stability issue with my new intel SASUC8I [1] PCIe controller. It's a > >> LSI 1068e based controller. After a few minutes with disk io (csup or > >> scrub by example) my FreeBSD 8-stable (64bit) is "freezing" for a couple > >> of minutes and I see a lot of error messages like: > >> > >> Sep 17 03:10:03 gw kernel: mpt0: request 0xff80002bc3b0:48367 timed > >> out for ccb 0xff00050a8000 (req->ccb 0xff00050a8000) > >> Sep 17 03:10:03 gw kernel: mpt0: request 0xff80002bbb40:48368 timed > >> out for ccb 0xff0004f81800 (req->ccb 0xff0004f81800) > >> Sep 17 03:10:03 gw kernel: mpt0: completing timedout/aborted req > >> 0xff80002bc3b0:48367 > >> Sep 17 03:10:03 gw kernel: mpt0: completing timedout/aborted req > >> 0xff80002bbb40:48368 > >> Sep 17 03:10:03 gw kernel: mpt0: Timedout requests already complete. > >> Interrupts may not be functioning > >> > > > > If this really is an issue with interrupts not getting delivered you > > could try whether disabling MSI/MSI-X by setting hw.pci.enable_msi=0 > > and hw.pci.enable_msix=0 either on the loader prompt or via loader.conf > > works around it. > > I already tried this. It didn't change anything. Same timeouts. > > I also tried vfs.zfs.vdev.min_pending="1" and vfs.zfs.vdev.max_pending="1" in > loader.conf without any positive change. > Okay, I was just worried as I recently changed mpt(4) to use MSI/MSI-X by default for the SAS variants but couldn't test with all of them. I'm not aware of any issues with the driver causing command timeouts though. I'd make sure that both the controller and the disks have the latest firmware; IIRC some time ago someone reported on current@ that updating the firmware of the disks solved the timeouts he was seeing for him. Marius ___ 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: mpt0 timeouts with an intel SASUC8I controller
On Mon, Sep 19, 2011 at 02:45:04PM +0200, Thomas Vogt wrote: > Hello > > I've stability issue with my new intel SASUC8I [1] PCIe controller. It's a > LSI 1068e based controller. After a few minutes with disk io (csup or scrub > by example) my FreeBSD 8-stable (64bit) is "freezing" for a couple of minutes > and I see a lot of error messages like: > > Sep 17 03:10:03 gw kernel: mpt0: request 0xff80002bc3b0:48367 timed out > for ccb 0xff00050a8000 (req->ccb 0xff00050a8000) > Sep 17 03:10:03 gw kernel: mpt0: request 0xff80002bbb40:48368 timed out > for ccb 0xff0004f81800 (req->ccb 0xff0004f81800) > Sep 17 03:10:03 gw kernel: mpt0: completing timedout/aborted req > 0xff80002bc3b0:48367 > Sep 17 03:10:03 gw kernel: mpt0: completing timedout/aborted req > 0xff80002bbb40:48368 > Sep 17 03:10:03 gw kernel: mpt0: Timedout requests already complete. > Interrupts may not be functioning > If this really is an issue with interrupts not getting delivered you could try whether disabling MSI/MSI-X by setting hw.pci.enable_msi=0 and hw.pci.enable_msix=0 either on the loader prompt or via loader.conf works around it. Marius ___ 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: HEADS UP: ZFS v28 merged to 8-STABLE
On Thu, Jun 09, 2011 at 12:46:19AM +0200, C. P. Ghost wrote: > On Wed, Jun 8, 2011 at 11:12 PM, Marius Strobl > wrote: > > On Mon, Jun 06, 2011 at 12:53:11PM +0200, Martin Matuska wrote: > >> Hi, > >> > >> I have merged ZFS version 28 to 8-STABLE (revision 222741) > >> > >> New major features: > >> > >> - data deduplication > >> - triple parity RAIDZ (RAIDZ3) > >> - zfs diff > >> - zpool split > >> - snapshot holds > >> - zpool import -F. Allows to rewind corrupted pool to earlier > >> ? transaction group > >> - possibility to import pool in read-only mode > >> > >> For updating, there is a compatibility layer so that in the update phase > >> most functionality of the new zfs binaries can be used with the old > >> kernel module and old zfs binaries with the new kernel module. > > > > Beware that the compatibility layer is known broken on big-endian > > architectures, i.e. powerpc64 and sparc64. > > Thanks for the heads-up! I was just about to update a couple of sparc64 > machines here. Fortunately, the only ZFS file systems there are external > file systems (no /, /usr, /var etc...), so it's gonna be painless, I suppose. > But what about other layouts? Does it mean that an installkernel, reboot, > and installworld won't work? No, using the old zfs binaries with the new kernel module triggers the problem. Using the new zfs binaries with the new kernel module works (at least with CURRENT) so you'd need disregard everything that is documented and do what is not guaranteed to work but usually also does, i.e. do installkernel, installworld and then reboot. > > >> If upgrading your boot pool to version 28, please don't forget to read > >> UPDATING and properly update your boot code. > >> > >> Thanks to everyone working on the ZFS port, especially to > >> Pawel Jakub Dawidek (pjd) for doing most of the work! > > Marius ___ 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: HEADS UP: ZFS v28 merged to 8-STABLE
On Mon, Jun 06, 2011 at 12:53:11PM +0200, Martin Matuska wrote: > Hi, > > I have merged ZFS version 28 to 8-STABLE (revision 222741) > > New major features: > > - data deduplication > - triple parity RAIDZ (RAIDZ3) > - zfs diff > - zpool split > - snapshot holds > - zpool import -F. Allows to rewind corrupted pool to earlier > transaction group > - possibility to import pool in read-only mode > > For updating, there is a compatibility layer so that in the update phase > most functionality of the new zfs binaries can be used with the old > kernel module and old zfs binaries with the new kernel module. Beware that the compatibility layer is known broken on big-endian architectures, i.e. powerpc64 and sparc64. > > If upgrading your boot pool to version 28, please don't forget to read > UPDATING and properly update your boot code. > > Thanks to everyone working on the ZFS port, especially to > Pawel Jakub Dawidek (pjd) for doing most of the work! > Marius ___ 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: Disable probing of bge1?
On Mon, Mar 07, 2011 at 01:26:01PM +0100, Patrick M. Hausen wrote: > Hi, all, > > I just discovered a minor problem when updating some rather dated > systems from FreeBSD 6.x to 7.x or 8.x. > > The servers are Fujitsu Technology Solutions (former Fujitsu-Siemens) > RX100 S4. The current generation of the same system is RX100 S6, so this > is two generations old. Some of them still run fine in our datacenter, though. > > While the S5 and S6 series features two gigabit ports and an additional > network interface for out of band management (called iRMC, similar to HP's > iLO), > the S4 has only two gigabit ports and the iRMC interface is piggybacked to > one of them. > > In our standard setup we disable the first interface in the BIOS. If you do > this, > the physical port is available as a dedicated management interface to the iRMC > and only the second IF is probed by FreeBSD 6.x as bge0. > > Now I try to PXE boot an identically configured system via the remote serial > console with FreeBSD 7. Everything runs fine, until the kernel probes the > network interfaces. The last thing I see are messages about successful > probing of both bge0 and bge1 and then my remote management connection > and my console are gone. > > I have to reset the BMC by literally pulling the power to get the iRMC back. > > Is it possible to use some device.hints entry to prohibit the probing of bge1? > I think that would be the easiest solution to the problem? Other suggestions > are of course welcome. I can provide more config details and dmesg output > if needed. > Unfortunately, there's currently no generic way to disable probing/ attaching of specific PCI devices. You'd need to hack the driver like in the following example to achieve that: Index: /usr/src/sys/dev/bge/if_bge.c === --- /usr/src/sys/dev/bge/if_bge.c (revision 213448) +++ /usr/src/sys/dev/bge/if_bge.c (working copy) @@ -2472,6 +2472,9 @@ bge_attach(device_t dev) u_char eaddr[ETHER_ADDR_LEN]; int error, msicount, reg, rid, trys; + if (device_get_unit(dev) == 1) + return (ENXIO); + sc = device_get_softc(dev); sc->bge_dev = dev; Marius ___ 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: Sense fetching [Was: cdrtools /devel ...]
On Fri, Nov 05, 2010 at 08:50:49PM +0200, Alexander Motin wrote: > Hi. > > I've reviewed tests that scgcheck does to SCSI subsystem. It shown > combination of several issues in both CAM, ahci(4) and cdrtools itself. > Several small patches allow us to pass most of that tests: > http://people.freebsd.org/~mav/sense/ > > ahci_resid.patch: Add support for reporting residual length on data > underrun. SCSI commands often returns results shorter then expected. > Returned value allows application to know/check how much data it really > has. It is also important for sense fetching, as ATAPI and USB devices > return sense as data in response to REQUEST_SENSE command. > > sense_resid.patch: When manually requesting sense data (ATAPI or USB), > request only as much data as user requested (not the fixed structure > size), and return respective sense residual length. > > pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch > sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon > as device freeze released before returning to user-level, user-level > application by definition can't reliably fetch sense data if some other > application (like hald) tries to access device same time. > > cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit > wanted sense length to CAM and do not clear sense return buffer. It is > mostly cosmetics, important probably only for scgcheck. Please don't commit this to the port directly but let it loop back via upstream (CC'ed) instead, otherwise we would need to obey the following, which is undesirable, especially if these really are mostly cosmetic issues: /* * Warning: you may change this source, but if you do that * you need to change the _scg_version and _scg_auth* string below. * You may not return "schily" for an SCG_AUTHOR request anymore. * Choose your name instead of "schily" and make clear that the version * string is related to a modified source. */ > > Testers and reviewers welcome. I am especially interested in opinion > about pass_autosence.patch -- may be we should lower sense fetching even > deeper, to make it work for all cam_periph_runccb() consumers. > Marius ___ 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: Can't load NFS server module with a custom 8.0 kernel
On Fri, Feb 19, 2010 at 07:42:56PM +0200, Kostik Belousov wrote: > On Fri, Feb 19, 2010 at 04:52:35PM +0100, Marius Strobl wrote: > > On Fri, Feb 19, 2010 at 12:07:14AM +0200, Kostik Belousov wrote: > > > On Thu, Feb 18, 2010 at 03:00:28PM -0500, Boris Kochergin wrote: > > > > Rick Macklem wrote: > > > > > > > > > > > > > > >On Thu, 18 Feb 2010, Boris Kochergin wrote: > > > > > > > > > >>Ahoy. I didn't get any replies to this on -net, so I thought I'd try > > > > >>here. I have an 8.0-RELEASE-p2/amd64 machine running a custom kernel > > > > >>(configuration file at http://acm.poly.edu/~spawk/ACM) and I am > > > > >>unable to use the NFS server module on it. After loading the nfssvc > > > > >>module, attempting to load the nfsserver module fails and the > > > > >>following appears in dmesg: > > > > >> > > > > >>Feb 3 19:35:54 acm kernel: link_elf_obj: symbol svcpool_create > > > > >>undefined > > > > >>Feb 3 19:35:54 acm kernel: linker_load_file: Unsupported file type > > > > >> > > > > >>I see a reference to the problem at > > > > >>http://lists.freebsd.org/pipermail/svn-src-all/2008-November/001025.html. > > > > >> > > > > >>Am I missing something or has it never gotten resolved? Thanks. > > > > >> > > > > >I don't know diddly about the module loading stuff, but you could try > > > > >this patch. (svcpool_create() is a part of the krpc, which is listed > > > > >as a module that nfsserver depends on) > > > > > > > > > >rick > > > > >--- untested patch for nfs_srvsubs.c --- > > > > >--- nfsserver/nfs_srvsubs.c.sav2010-02-18 14:41:52.0 -0500 > > > > >+++ nfsserver/nfs_srvsubs.c2010-02-18 14:42:12.0 -0500 > > > > >@@ -554,7 +554,7 @@ > > > > > nfsrv_modevent, > > > > > NULL, > > > > > }; > > > > >-DECLARE_MODULE(nfsserver, nfsserver_mod, SI_SUB_VFS, SI_ORDER_ANY); > > > > >+DECLARE_MODULE(nfsserver, nfsserver_mod, SI_SUB_VFS, SI_ORDER_FIRST); > > > > > > > > > > /* So that loader and kldload(2) can find us, wherever we are.. */ > > > > > MODULE_VERSION(nfsserver, 1); > > > > Thanks for the patch, but the problem persists with it, I'm afraid. > > > > > > I think this is changed in HEAD, and part of the changes are already in > > > stable/8, which is different from 8.0 too. > > > > > > Anyway, for HEAD nfsserver we need 1. nfscommon 2. nfs_common. > > > > Could you please elaborate on why nfsserver requires the former? > Not any more. I did a check yesterday on the outdated tree without > realizing this. Sorry. > > > At least as far as svcpool_create() is concerned I see no reason > > why it should require nfscommon. Also, when testing r203968 the > > following list of modules where sufficient to have both nfsclient > > and nfsserver working: > > krpc.ko > > nfs_common.ko > > nfsclient.ko > > nfslockd.ko > > nfsserver.ko > > nfssvc.ko > > I confirm. So the only thing missing ATM is to actually add nfs_common.ko > to the build. Correct, thanks for pointing this out. Marius ___ 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: Can't load NFS server module with a custom 8.0 kernel
On Fri, Feb 19, 2010 at 12:07:14AM +0200, Kostik Belousov wrote: > On Thu, Feb 18, 2010 at 03:00:28PM -0500, Boris Kochergin wrote: > > Rick Macklem wrote: > > > > > > > > >On Thu, 18 Feb 2010, Boris Kochergin wrote: > > > > > >>Ahoy. I didn't get any replies to this on -net, so I thought I'd try > > >>here. I have an 8.0-RELEASE-p2/amd64 machine running a custom kernel > > >>(configuration file at http://acm.poly.edu/~spawk/ACM) and I am > > >>unable to use the NFS server module on it. After loading the nfssvc > > >>module, attempting to load the nfsserver module fails and the > > >>following appears in dmesg: > > >> > > >>Feb 3 19:35:54 acm kernel: link_elf_obj: symbol svcpool_create > > >>undefined > > >>Feb 3 19:35:54 acm kernel: linker_load_file: Unsupported file type > > >> > > >>I see a reference to the problem at > > >>http://lists.freebsd.org/pipermail/svn-src-all/2008-November/001025.html. > > >>Am I missing something or has it never gotten resolved? Thanks. > > >> > > >I don't know diddly about the module loading stuff, but you could try > > >this patch. (svcpool_create() is a part of the krpc, which is listed > > >as a module that nfsserver depends on) > > > > > >rick > > >--- untested patch for nfs_srvsubs.c --- > > >--- nfsserver/nfs_srvsubs.c.sav2010-02-18 14:41:52.0 -0500 > > >+++ nfsserver/nfs_srvsubs.c2010-02-18 14:42:12.0 -0500 > > >@@ -554,7 +554,7 @@ > > > nfsrv_modevent, > > > NULL, > > > }; > > >-DECLARE_MODULE(nfsserver, nfsserver_mod, SI_SUB_VFS, SI_ORDER_ANY); > > >+DECLARE_MODULE(nfsserver, nfsserver_mod, SI_SUB_VFS, SI_ORDER_FIRST); > > > > > > /* So that loader and kldload(2) can find us, wherever we are.. */ > > > MODULE_VERSION(nfsserver, 1); > > Thanks for the patch, but the problem persists with it, I'm afraid. > > I think this is changed in HEAD, and part of the changes are already in > stable/8, which is different from 8.0 too. > > Anyway, for HEAD nfsserver we need 1. nfscommon 2. nfs_common. Could you please elaborate on why nfsserver requires the former? At least as far as svcpool_create() is concerned I see no reason why it should require nfscommon. Also, when testing r203968 the following list of modules where sufficient to have both nfsclient and nfsserver working: krpc.ko nfs_common.ko nfsclient.ko nfslockd.ko nfsserver.ko nfssvc.ko Marius ___ 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: uma_zalloc_arg complaining about non-sleepable locks
On Mon, Feb 01, 2010 at 11:54:54AM -0500, Rick Macklem wrote: > > > On Mon, 1 Feb 2010, John Baldwin wrote: > > >>>I'd say that your patch works. > >> > >>John, are you okay with that patch? > >>http://people.freebsd.org/~marius/fha_extract_info_realign2.diff > >> > >>It's intention is to: > >>- Move nfs_realign() from the NFS client to the shared NFS code and > >> remove the NFS server version in order to reduce code duplication. > >> The shared version now uses a second parameter how, which is passed > >> on to m_get(9) and m_getcl(9) as the server used M_WAIT while the > >> client requires M_DONTWAIT, and replaces the the previously unused > >> parameter hsiz. > > I don't think the client side can use M_WAIT/M_WAITOK if it wants to. > (I believe that it was once called from the socket upcall and that was > why M_DONTWAIT was used, but that isn't how it is called in the client > now.) > > I mentioned this to dfr@ because I use a version shared between client > and server for the experimental one that does M_WAIT, but he didn't > think the regular client needed to be changed. Basically, I think the > current code in the regular client can return ENOMEM for I/O system calls, > which probably isn't what the app. expected. In the NFS client, you end up > with this "do I wait forever?" or "do I return an error to an I/O system > call which an app. doesn't expect" issue cropping up here and there. I > don't know the correct answer to this, but tend to lean in the "wait > forever" direction. Well, as demonstrated by the problem with fha_extract_info() "waiting forever" must also match the locking so I'd rather leave chanGing the regular NFS client to someone who understands it better than I do :) Btw., newnfs_realign() should use #ifdef __NO_STRICT_ALIGNMENT instead of #if defined(__i386__) in order to bypass realigning on platforms which can deal with unaligned accesses. > > >>- Change nfs_realign() to use nfsm_aligned() so as with other NFS code > >> the alignment check isn't actually performed on platforms without > >> strict alignment requirements for performance reasons because as the > >> comment suggests only occasionally occurs with TCP. > >>- Change fha_extract_info() to use nfs_realign() with M_NOWAIT rather > >> than M_DONTWAIT because it's called with the RPC sp_lock held. > >> > > Btw, from an historical perspective, this was originally added for the > DEC PMAX port (MIPS R2000), which would trap whenever an unaligned ptr > was used. Then, there was this involved chunk of MIPS assembly code that > worked around the unaligned ptr access and the trap returned. Obviously > this was a major performance hit and happened fairly frequently for NFS > over ISO TP4. As you've seen, it happens infrequently enough over TCP > (back then, I think it was only when the TCP window size ended up really > small, although I'm way out of date on the TCP stack, so I have no idea > now:-) that I'd only do the re-alignment on achitectures that will crash > if it isn't done? > > I missed the beginning of this. Was there crashes occurring because > the alignment wasn't being done or problems because the alignment > wasn't working correctly? (I guess I'm trying to say that, if the > arch works without nfs_realign(), then you might consider just not > doing it for that arch. I suppose that isn't a good enough reason > to not fix the function, though?;-) The original problem with fha_extract_info() was that it didn't realign the mbuf data at all but called nfsm_srvmtofh_xx() which assumes the 4-byte alignment required by XDR. As mentioned above, changing nfs_realign() to use nfsm_aligned() has the effect you propose of not performing the realignment on platforms which can deal with unaligned acesses. Actually one could take this one step further and #ifdef the whole nfs_realign() like you do with newnfs_realign() but nfsm_aligned() already existed and I'm reluctant to rototill foreign code too much. Also the compiler should be smart enough to optimize this down to just incrementing nfs_realign_test when __NO_STRICT_ALIGNMENT is defined. Marius ___ 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: uma_zalloc_arg complaining about non-sleepable locks
On Mon, Feb 01, 2010 at 09:46:57AM -0500, John Baldwin wrote: > On Sunday 31 January 2010 11:28:54 am Marius Strobl wrote: > > On Sun, Jan 31, 2010 at 12:06:18PM +1100, Peter Jeremy wrote: > > > Sorry for the delay, I was trying to avoid rebooting my server. > > > I've setup a similar environment in VirtualBox to test it. > > > > > > On 2010-Jan-27 12:52:29 +0100, Marius Strobl > wrote: > > > >Ah, I forgot that using nfsm_aligned() causes nfs_realign() to > > > >be a NOP on architectures without strict alignment requirements > > > >for performance reasons. That's generally fine but unfortunately > > > >that way you don't actually exercise the code which caused the > > > >problem before (unfortunately I still don't manage to hit the > > > >unaligned case myself). > > > > > > >Could you please test with #ifdef __NO_STRICT_ALIGNMENT replaced > > > >with #if 0 in sys/nfs/nfs_common.h? The vfs.nfs.realign_count > > > >counter should also increase then. > > > > > > I'm not sure what triggers the unaligned case either - I tried > > > roughly "tar -cf - -C /mnt/usr src | tar -xf - -C /mnt/tmp" and > > > that caused some unaligned accesses (but also completely wedged > > > the VBox host). I also tried copying a pile of files off my > > > NFS client (FreeBSD-8.x/i386) and that also triggered some > > > unaligned accesses without any errors being reported. > > > > > > Currently, I have: > > > vfs.nfs.realign_count: 12 > > > vfs.nfs.realign_test: 188817 > > > > > > I'd say that your patch works. > > > > John, are you okay with that patch? > > http://people.freebsd.org/~marius/fha_extract_info_realign2.diff > > > > It's intention is to: > > - Move nfs_realign() from the NFS client to the shared NFS code and > > remove the NFS server version in order to reduce code duplication. > > The shared version now uses a second parameter how, which is passed > > on to m_get(9) and m_getcl(9) as the server used M_WAIT while the > > client requires M_DONTWAIT, and replaces the the previously unused > > parameter hsiz. > > - Change nfs_realign() to use nfsm_aligned() so as with other NFS code > > the alignment check isn't actually performed on platforms without > > strict alignment requirements for performance reasons because as the > > comment suggests only occasionally occurs with TCP. > > - Change fha_extract_info() to use nfs_realign() with M_NOWAIT rather > > than M_DONTWAIT because it's called with the RPC sp_lock held. > > > > The only downside of the shared nfs_realign() are the combined > > SYSCTL counters but the fact we incremented them non-atomically > > so far I think already indicates that their intention only is a > > rough indication rather than exact values for client and server. > > This all sounds good to me, but isn't M_NOWAIT == M_DONTWAIT? Hmm, reading > the code more closely, it looks like fha_extract_info() was using M_WAIT > rather than M_DONTWAIT previously. Also, I think you should be careful to > use > M_DONTWAIT instead of M_NOWAIT for mbufs, so I would fix that in > fha_extract_info(). > Ah, of course you're right, the above description should have read: Change fha_extract_info() to use nfs_realign() with M_DONTWAIT rather than M_WAIT because it's called with the RPC sp_lock held. and I had also managed to copy&paste M_NOWAIT instead of M_DONTWAIT into fha_extract_info() despite having read mbuf(9) regarding this topic. Thanks for pointing these out. Marius ___ 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: uma_zalloc_arg complaining about non-sleepable locks
On Sun, Jan 31, 2010 at 12:06:18PM +1100, Peter Jeremy wrote: > Sorry for the delay, I was trying to avoid rebooting my server. > I've setup a similar environment in VirtualBox to test it. > > On 2010-Jan-27 12:52:29 +0100, Marius Strobl > wrote: > >Ah, I forgot that using nfsm_aligned() causes nfs_realign() to > >be a NOP on architectures without strict alignment requirements > >for performance reasons. That's generally fine but unfortunately > >that way you don't actually exercise the code which caused the > >problem before (unfortunately I still don't manage to hit the > >unaligned case myself). > > >Could you please test with #ifdef __NO_STRICT_ALIGNMENT replaced > >with #if 0 in sys/nfs/nfs_common.h? The vfs.nfs.realign_count > >counter should also increase then. > > I'm not sure what triggers the unaligned case either - I tried > roughly "tar -cf - -C /mnt/usr src | tar -xf - -C /mnt/tmp" and > that caused some unaligned accesses (but also completely wedged > the VBox host). I also tried copying a pile of files off my > NFS client (FreeBSD-8.x/i386) and that also triggered some > unaligned accesses without any errors being reported. > > Currently, I have: > vfs.nfs.realign_count: 12 > vfs.nfs.realign_test: 188817 > > I'd say that your patch works. John, are you okay with that patch? http://people.freebsd.org/~marius/fha_extract_info_realign2.diff It's intention is to: - Move nfs_realign() from the NFS client to the shared NFS code and remove the NFS server version in order to reduce code duplication. The shared version now uses a second parameter how, which is passed on to m_get(9) and m_getcl(9) as the server used M_WAIT while the client requires M_DONTWAIT, and replaces the the previously unused parameter hsiz. - Change nfs_realign() to use nfsm_aligned() so as with other NFS code the alignment check isn't actually performed on platforms without strict alignment requirements for performance reasons because as the comment suggests only occasionally occurs with TCP. - Change fha_extract_info() to use nfs_realign() with M_NOWAIT rather than M_DONTWAIT because it's called with the RPC sp_lock held. The only downside of the shared nfs_realign() are the combined SYSCTL counters but the fact we incremented them non-atomically so far I think already indicates that their intention only is a rough indication rather than exact values for client and server. Marius ___ 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: uma_zalloc_arg complaining about non-sleepable locks
On Wed, Jan 27, 2010 at 12:52:29PM +0100, Marius Strobl wrote: > On Wed, Jan 27, 2010 at 05:36:49PM +1100, Peter Jeremy wrote: > > On 2010-Jan-26 15:10:59 -0500, John Baldwin wrote: > > >On Tuesday 26 January 2010 1:37:56 pm Marius Strobl wrote: > > >> On Tue, Jan 26, 2010 at 09:46:44AM -0500, John Baldwin wrote: > > >> > On Tuesday 26 January 2010 2:33:37 am Peter Jeremy wrote: > > >> > > I have just upgraded to 8-STABLE/amd64 from about 18 hours ago and am > > >> > > now getting regular (the following pair of messages about every > > >> > > minute) compaints as follows: > > >> > > > > >> > > kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable > > >> > > locks held: > > >> > > kernel: exclusive sleep mutex sp_lock (sp_lock) r = 0 > > >> > > (0xff000460bb00) locked @ /usr/src/sys/rpc/svc.c:1098 > > ... > > >> Could you please give the following patch a try? > > >> http://people.freebsd.org/~marius/fha_extract_info_realign2.diff > > > > That seems to have fixed it - I've booted the new kernel and generated > > some NFS activity and am not getting any messages. Also, > > vfs.nfs.realign_test is incrementing nicely though > > vfs.nfs.realign_count remains at zero. > > > > Ah, I forgot that using nfsm_aligned() causes nfs_realign() to > be a NOP on architectures without strict alignment requirements > for performance reasons. That's generally fine but unfortunately > that way you don't actually exercise the code which caused the > problem before (unfortunately I still don't manage to hit the > unaligned case myself). > Could you please test with #ifdef __NO_STRICT_ALIGNMENT replaced > with #if 0 in sys/nfs/nfs_common.h? The vfs.nfs.realign_count > counter should also increase then. > How did that work out? Marius ___ 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: uma_zalloc_arg complaining about non-sleepable locks
On Wed, Jan 27, 2010 at 05:36:49PM +1100, Peter Jeremy wrote: > On 2010-Jan-26 15:10:59 -0500, John Baldwin wrote: > >On Tuesday 26 January 2010 1:37:56 pm Marius Strobl wrote: > >> On Tue, Jan 26, 2010 at 09:46:44AM -0500, John Baldwin wrote: > >> > On Tuesday 26 January 2010 2:33:37 am Peter Jeremy wrote: > >> > > I have just upgraded to 8-STABLE/amd64 from about 18 hours ago and am > >> > > now getting regular (the following pair of messages about every > >> > > minute) compaints as follows: > >> > > > >> > > kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable > >> > > locks held: > >> > > kernel: exclusive sleep mutex sp_lock (sp_lock) r = 0 > >> > > (0xff000460bb00) locked @ /usr/src/sys/rpc/svc.c:1098 > ... > >> Could you please give the following patch a try? > >> http://people.freebsd.org/~marius/fha_extract_info_realign2.diff > > That seems to have fixed it - I've booted the new kernel and generated > some NFS activity and am not getting any messages. Also, > vfs.nfs.realign_test is incrementing nicely though > vfs.nfs.realign_count remains at zero. > Ah, I forgot that using nfsm_aligned() causes nfs_realign() to be a NOP on architectures without strict alignment requirements for performance reasons. That's generally fine but unfortunately that way you don't actually exercise the code which caused the problem before (unfortunately I still don't manage to hit the unaligned case myself). Could you please test with #ifdef __NO_STRICT_ALIGNMENT replaced with #if 0 in sys/nfs/nfs_common.h? The vfs.nfs.realign_count counter should also increase then. Marius ___ 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: uma_zalloc_arg complaining about non-sleepable locks
On Tue, Jan 26, 2010 at 09:46:44AM -0500, John Baldwin wrote: > On Tuesday 26 January 2010 2:33:37 am Peter Jeremy wrote: > > I have just upgraded to 8-STABLE/amd64 from about 18 hours ago and am > > now getting regular (the following pair of messages about every > > minute) compaints as follows: > > > > kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks > > held: > > kernel: exclusive sleep mutex sp_lock (sp_lock) r = 0 (0xff000460bb00) > > locked @ /usr/src/sys/rpc/svc.c:1098 > > kernel: KDB: stack backtrace: > > kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > kernel: _witness_debugger() at _witness_debugger+0x2c > > kernel: witness_warn() at witness_warn+0x2c2 > > kernel: uma_zalloc_arg() at uma_zalloc_arg+0x29d > > kernel: nfs_realign() at nfs_realign+0x5f > > kernel: fha_assign() at fha_assign+0x2d8 > > kernel: svc_run_internal() at svc_run_internal+0x1ee > > kernel: svc_thread_start() at svc_thread_start+0xb > > kernel: fork_exit() at fork_exit+0x112 > > kernel: fork_trampoline() at fork_trampoline+0xe > > kernel: --- trap 0xc, rip = 0x80069e04c, rsp = 0x7fffe6d8, rbp = 0x5 --- > > kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks > > held: > > kernel: exclusive sleep mutex sp_lock (sp_lock) r = 0 (0xff000460bb00) > > locked @ /usr/src/sys/rpc/svc.c:1098 > > kernel: KDB: stack backtrace: > > kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > kernel: _witness_debugger() at _witness_debugger+0x2c > > kernel: witness_warn() at witness_warn+0x2c2 > > kernel: uma_zalloc_arg() at uma_zalloc_arg+0x29d > > kernel: nfs_realign() at nfs_realign+0x5f > > kernel: fha_assign() at fha_assign+0x2d8 > > kernel: svc_run_internal() at svc_run_internal+0x1ee > > kernel: svc_thread_start() at svc_thread_start+0xb > > kernel: fork_exit() at fork_exit+0x112 > > kernel: fork_trampoline() at fork_trampoline+0xe > > kernel: --- trap 0xc, rip = 0x80069e04c, rsp = 0x7fffe6d8, rbp = 0x5 --- > > > > It looks like NFS is missing some lock/unlock pairs. Has anyone else > > seen this? And does anyone have a fix? > > I suspect this was caused by the recent alignment fixes to NFS. I've cc'd > Marius. > Could you please give the following patch a try? http://people.freebsd.org/~marius/fha_extract_info_realign2.diff It would also be great if one of the NFS gurus could have a look at the whole issue. Unfortunately, I hadn't received a reply regarding the original patch. Marius ___ 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: RELENG_6 build failures
On Tue, Aug 25, 2009 at 09:42:03PM +, Bjoern A. Zeeb wrote: > Hi, > > I was trying to run a make universe on RELENG_6 and found: > > 1) alpha doesn't build > > 2) powerpc LINT fails with: > config: Error: device "zs" is unknown > > 3) sparc64 LINT fails with: > mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- > -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I@/../include > -I/tmp/usr/include -I/obj/sparc64/RELENG_6.svn/sys/LINT > /RELENG_6.svn/sys/modules/ukbd/../../dev/usb/ukbd.c > /RELENG_6.svn/sys/modules/ukbd/../../dev/usb/ukbd.c:418:21: ukbdmap.h: > No such file or directory > > > At least (3) should be a supported platform but given that universe > builds the other two as well I would assume they are as well. > > amd64, i386, pc98, ia64 were ok, the GENERIC kernels seems to be > fine for powerpc and sparc64. alpha as said seems dead. > > I have no idea why we never saw the errors flying by, > so I don't want to rule out a local problem. > > > In case anyone could confirm these findings (or fix them should they > exist) that would be great. > > I had run: > make -j8 universe __MAKE_CONF=/dev/null > AFAICT (3) isn't platform-specific but doesn't manifest with every build. The fix is to MFC rev. 1.57 of sys/dev/usb/ukbd.c (I don't seem to be able to access sys/legacy/dev/usb/ukbd.c for getting the SVN revision and sys/dev/usb/input/ukbd.c apparently wasn't copied from the old one within SVN). Marius ___ 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: bge problems under 7.2-PRERELEASE
On Fri, May 29, 2009 at 08:02:42PM +0200, Henri-Pierre Charles wrote: > Hello Guys > > On Thu, Apr 23, 2009 at 10:05 PM, Jeff Blank wrote: > > On Thu, Apr 23, 2009 at 07:19:49PM +0200, Marius Strobl wrote: > >> So in combination with > >> the low number of problem reports this really doesn't > >> look like a generic problem of this Broadcom hardware > >> or bge(4) and I just can suggest to disable MSI by > >> setting the hw.pci.enable_msi tuneable to 0 for now. > > > > Great, this does the trick, and I'm now running today's RELENG_7. > > Thanks for your help, and let me know if ever you'd like me to help > > test possible fixes. > > I have the same computer (Dell optiplex 740) but the sysctl turnaround > doesn't work, the bge interface seem up but no interruptions. > > I have to download / recompile with sys/dev/bge/if_bge.c rev > 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6 > > Is there anything else to try ? You need to set hw.pci.enable_msi in the loader f.e. via loader.conf rather than the corresponding sysctl as the latter has no effect during boot. Marius ___ 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: bge problems under 7.2-PRERELEASE
On Wed, Apr 22, 2009 at 11:06:12AM -0400, Jeff Blank wrote: > On Tue, Apr 21, 2009 at 09:55:10PM +0200, Marius Strobl wrote: > > Use the sources you have but plug in sys/dev/bge/if_bge.c > > rev 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6, this > > combination should work. > > correct. > > > Then update if_bge.c to rev > > 1.198.2.14 and check whether things still work, > > this causes the problem to resurface. > FYI, I've found a notebook equipped with the exact same Broadcom chip and ASIC revision but which works without problems with current sources. So in combination with the low number of problem reports this really doesn't look like a generic problem of this Broadcom hardware or bge(4) and I just can suggest to disable MSI by setting the hw.pci.enable_msi tuneable to 0 for now. As David pointed out this might be a problem with the Nvidia chipset. Linux seems to have a workaround related to this but I still need to check that in detail. Marius ___ 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: bge problems under 7.2-PRERELEASE
On Wed, Apr 22, 2009 at 01:21:58PM -0700, David Christensen wrote: > > > > Then update if_bge.c to rev > > > > 1.198.2.14 and check whether things still work, > > > > > > this causes the problem to resurface. > > > > > > > David, > > > > this is the second report that using MSI with a BCM5754/ > > chip=0x167a14e4 results in no interrupts, is there any errata > > about this? > > Nope, no errata for MSI on the 5754, nor can I recall any > MSI problems on any of the PCIe based devices. Do the > systems share a common root complex that might be the source > of the issue? > This one useses a: no...@pci0:0:0:0: class=0x05 card=0x02f010de chip=0x02f010de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Host Bridge' class = memory subclass = RAM At least Linux doesn't seem to avoid using MSI with these. I didn't get any further regarding the other report so far. Marius ___ 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: bge problems under 7.2-PRERELEASE
On Wed, Apr 22, 2009 at 11:06:12AM -0400, Jeff Blank wrote: > On Tue, Apr 21, 2009 at 09:55:10PM +0200, Marius Strobl wrote: > > Use the sources you have but plug in sys/dev/bge/if_bge.c > > rev 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6, this > > combination should work. > > correct. > > > Then update if_bge.c to rev > > 1.198.2.14 and check whether things still work, > > this causes the problem to resurface. > David, this is the second report that using MSI with a BCM5754/ chip=0x167a14e4 results in no interrupts, is there any errata about this? Thanks, Marius ___ 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: bge problems under 7.2-PRERELEASE
On Tue, Apr 21, 2009 at 03:31:29PM -0400, Jeff Blank wrote: > On Tue, Apr 21, 2009 at 08:49:24PM +0200, Marius Strobl wrote: > > On Mon, Apr 20, 2009 at 04:46:38PM -0400, Jeff Blank wrote: > > > I have no trouble with networking using a kernel from 20090115. This > > Does that working kernel include r187309 (if_bge.c rev 1.198.2.14)? > > nope, 1.198.2.11. > > > If it predates it could you please check whether this is the change > > which breaks things for you? > > what's the best way to go about this? I no longer have the source > tree from the working kernel. should I plug 1.198.2.11 into the > sources I have and then try .14? any other files I'd need previous > revisions of? or is there a different, better way to go about it? (I > don't know much about time-travelling through source.) > Use the sources you have but plug in sys/dev/bge/if_bge.c rev 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6, this combination should work. Then update if_bge.c to rev 1.198.2.14 and check whether things still work, if they do revert to pci.c rev 1.355.2.9 and check again. Marius ___ 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: bge problems under 7.2-PRERELEASE
On Mon, Apr 20, 2009 at 04:46:38PM -0400, Jeff Blank wrote: > Hi, > > csup today around 13:00 UTC. 'make buildworld', 'make buildkernel', > 'make installkernel', reboot to single-user. > > # ifconfig bge0 141.219.5.33/22 up > # ping 141.219.4.1 > PING 141.219.4.1 (141.219.4.1): 56 data bytes > ^C > --- 141.219.4.1 ping statistics --- > 3 packets transmitted, 0 packets received, 100.0% packet loss > > # ifconfig bge0 > bge0: flags=8843 metric 0 mtu 1500 > options=9b > ether 00:1e:c9:44:30:14 > inet6 fe80::21e:c9ff:fe44:3014%bge0 prefixlen 64 scopeid 0x1 > inet 141.219.5.33 netmask 0xfc00 broadcast 141.219.7.255 > media: Ethernet autoselect (100baseTX ) > status: active > > I have no trouble with networking using a kernel from 20090115. This Does that working kernel include r187309 (if_bge.c rev 1.198.2.14)? If it predates it could you please check whether this is the change which breaks things for you? > is a Dell Optiplex 740, about 9 months old. make.conf and src.conf > are below. dmesg and pciconf output are attached. I ran 'tcpdump -i > bge0 -nn' while pinging, and this captured no packets, not even this > host's ARP broadcasts. > > I also encountered this problem in late March as well, just after > RELENG_7 became 7.2-PRERELEASE, but couldn't find time to put this > information together. > > If there's anything else I can run to troubleshoot this, please let me > know. > > thank you, > Jeff Blank > > /etc/make.conf: > CPUTYPE ?= k8 > WITHOUT_NLS=true > [port-specific options elided for brevity] > > /etc/src.conf: > WITHOUT_ATM=true > WITHOUT_GPIB=true > WITHOUT_I4B=true > WITHOUT_IPFILTER=true > WITHOUT_IPFW=true > WITHOUT_IPX=true > WITHOUT_LIB32=true > WITHOUT_NCP=true > WITHOUT_NDIS=true > WITHOUT_PPP=true > WITHOUT_QUOTAS=true > WITHOUT_RCMDS=true > WITHOUT_SENDMAIL=true > WITHOUT_SLIP=true > WITHOUT_WIRELESS=true > # dmesg > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.2-PRERELEASE #0: Mon Apr 20 12:27:26 EDT 2009 > r...@bender.tc.mtu.edu:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ (2906.08-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 > > Features=0x178bfbff > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x11f > TSC: P-state invariant > Cores per package: 2 > usable memory = 4278718464 (4080 MB) > avail memory = 4098314240 (3908 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > This module (opensolaris) contains code covered by the > Common Development and Distribution License (CDDL) > see http://opensolaris.org/os/licensing/opensolaris_license/ > ioapic0: Changing APIC ID to 4 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a (3) failed > acpi0: reservation of 10, bfdd (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > acpi_hpet0: iomem 0xfeff-0xfeff03ff on acpi0 > Timecounter "HPET" frequency 2500 Hz quality 900 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.0 (no driver attached) > pci0: at device 0.1 (no driver attached) > pci0: at device 0.2 (no driver attached) > pci0: at device 0.3 (no driver attached) > pci0: at device 0.4 (no driver attached) > pci0: at device 0.5 (no driver attached) > pci0: at device 0.6 (no driver attached) > pci0: at device 0.7 (no driver attached) > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pcib2: at device 3.0 on pci0 > pci2: on pcib2 > bge0: mem > 0xfd8f-0xfd8f irq 16 at device 0.0 on pci2 > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > bge0: Ethernet address: 00:1e:c9:44:30:14 > bge0: [ITHREAD] > pcib3: at device 4.0 on pci0 > pci3: on pcib3 > vgapci0: port 0xbc00-0xbcff mem > 0xd000-0xdfff,0xfddf-0xfddf irq 16 at device 0.0 on pci3 > vgapci1: mem 0xfdde-0xfdde at device 0.1 on > pci3 > pci0: at device 9.0 (no driver attached) > isab0: port 0x1d00-0x1dff at device 10.0 on pci0 > isa0: on isab0 > pci0: at device 10.1 (no driver attached) > pci0: at device 10.2 (no driver attached) > ohci0: mem 0xfe02f000-0xfe02 irq 21 at > device 11.0 on pci0 > ohci0: [GIANT-LOCKED] > ohci0: [ITHREAD] > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhu
Re: 7.2-PRERELEASE/sunx2200/bge/msi broken
On Sun, Mar 22, 2009 at 05:40:21PM +0200, Danny Braniss wrote: > > On Sun, Mar 22, 2009 at 03:10:07PM +0200, Mikolaj Golub wrote: > > > > > > On Sun, 22 Mar 2009 12:55:02 +0200 Danny Braniss wrote: > > > > > > DB> Hi, > > > DB> between March 16 and now, bge on a Sun X2200 stopped working, > > > DB> turning off msi (via hw..pci.enable_msi=0) got it working again. > > > DB> I tried first replacing bge with an older version but that did not > > > help. > > > > > > It looks like related to this report: > > > > > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=1253844+1263253+/usr/local/www/db/text/2009/freebsd-bugs/20090322.freebsd-bugs > > > > > > > Could you please give the following patch a try? > > http://people.freebsd.org/~marius/bge_intx.diff > > > > Marius > > > it works! For the records, this was commited to stable/7 as part of r190478/if_bge.c 1.198.2.17. Marius ___ 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: 7.2-PRERELEASE/sunx2200/bge/msi broken
On Sun, Mar 22, 2009 at 03:10:07PM +0200, Mikolaj Golub wrote: > > On Sun, 22 Mar 2009 12:55:02 +0200 Danny Braniss wrote: > > DB> Hi, > DB> between March 16 and now, bge on a Sun X2200 stopped working, > DB> turning off msi (via hw..pci.enable_msi=0) got it working again. > DB> I tried first replacing bge with an older version but that did not help. > > It looks like related to this report: > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=1253844+1263253+/usr/local/www/db/text/2009/freebsd-bugs/20090322.freebsd-bugs > Could you please give the following patch a try? http://people.freebsd.org/~marius/bge_intx.diff Marius ___ 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: Request for testing: ata(4) MFC
On Sat, Oct 04, 2008 at 07:38:09PM +0400, Andrey V. Elsukov wrote: > Hi, All. > > I prepared patch to make MFC of ata(4) driver into RELENG_7 > before 7.1-RELEASE. Depending on results of the testing patch > will be commited or not (if some regressions will be detected). > So if you want or just can test it, please try and report here. One regression of the post-PM code is that support for some Promise controllers is broken in that probing drives causes a hang. In my case it's a FasTrak S150 TX4 with a PDC20319 but there are also other variants affected, see f.e.: http://lists.freebsd.org/pipermail/freebsd-current/2008-May/085923.html Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: the future of sun4v
On Fri, Aug 22, 2008 at 01:44:25PM +0200, Kris Kennaway wrote: > Peter Jeremy wrote: > >[Replies re-directed to freebsd-sun4v] > > > >On 2008-Aug-21 14:42:55 -0700, Kip Macy <[EMAIL PROTECTED]> wrote: > >>I believe that there is a general expectation by freebsd users and > >>developers that unsupported code should not be in CVS. Although sun4v > >>is a very interesting platform for developers doing SMP work, I simply > >>do not have the time or energy to maintain it. If someone else would > >>like to step up and try his hand I would be supportive of his efforts. > >>In the likely event that no one steps forward by the time that 7.1 is > >>released I will ask that it be moved to the Attic. > > > >Since there are no other current SPARC CPUs that FreeBSD can run on > >(the US-II has been obsolete for about 6 years and FreeBSD won't run > >on any more recent sun4u chips), that will also remove the > >justification for maintaining a SPARC64 port. > > > >I don't have the knowledge or available time to maintain the sun4v > >port by myself but would be happy to be part of a team doing so. One > >impediment I have is that I don't have a T-1 or T-2 system that I can > >dedicate to FreeBSD. I could work on FreeBSD in a guest domain - but > >since FreeBSD doesn't support either the virtual disk or virtual > >network, actually getting FreeBSD running there presents somewhat of a > >challenge. > > > > There are two t1000 systems in the freebsd.org cluster that are > available for people to work on. Rink Springer has also expressed > interest in this. > > Perhaps Kip can explain some more about what things he looked at, but > the most serious bugs might be in pmap or perhaps trap handling. > Operationally, things like buildworld -jN die quickly with random > signals, kernel traps, etc. > > Kris > > P.S. It looks like marius has made progress on US III but sun4u is still > an architectural dead end. Well, let's see what architecture the upcoming Rock CPUs are; judging their feature list they appear to be a continuation of the Fujitsu sun4u line rather than a successor of UST1/2 :) Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0 RC1/SPARC64 panic in boot [SOLVED]
On Wed, Jan 23, 2008 at 12:26:24PM +0100, Eirik verby wrote: > On Jan 23, 2008, at 7:32 AM, Scott Long wrote: > > >Eirik ?verby wrote: > >>On Jan 22, 2008, at 7:23 PM, Marius Strobl wrote: > >>>On Tue, Jan 22, 2008 at 07:16:16AM +0100, Eirik verby wrote: > >>>>Hi list, > >>>> > >>>>by disabling the isp driver (set hint.isp.o.disabled=1), the > >>>>system comes up. This of course denies us access to the external > >>>>disk array hosted by the internal QLogic controller, but > >>>>pinpoints the problem. > >>>> > >>>>We tried setting hint.isp.0.prefer_iomap=1, which made no > >>>>difference (though by reading the code, I don't see that it ever > >>>>used this). > >>>> > >>>>Can anyone help us out here? > >>> > >>>Scott, could this be due to a missing MFC of isp_sbus.c rev. 1.36? > >>If that would be the case I'd be most happy to hear that. I'll also > >>be more than happy to test, and can do so on relatively short > >>notice (at least for another few hours). > >>We have, for the record, gone through some basic troubleshooting: > >>Replaced memory (as this error also can show up under Solaris and > >>is usually an indicator of bad memory), replaced SCSI controller > >>with another one (still isp driven), and testing various device > >>hints - suffice to say we have wasted our time so far ;) > > > >Are you able to compile a new kernel without having to install first? > >if so, apply the attached patch and let me know if it works. > > Works very well, thanks a bunch! > Will this make it into 7-RELEASE? > Yes Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1
On Tue, Jan 22, 2008 at 09:10:14PM +1100, Andrew Reilly wrote: > Hi Marius, > > On Tue, 22 Jan 2008 10:33:27 +0100 > Marius Strobl <[EMAIL PROTECTED]> wrote: > > > The __gthread_active_p(), which returns false positives prior > > to the current version of gthr-posix.h, isn't only used in > > libstdc++ but also in headers that are installed beneath > > /usr/include/c++. So the code in those headers compiled into > > an existing binary which was built prior to the gthr-posix.h > > fix still might erroneously determine that it's running in a > > threaded environment while f.e. libstdc++ does not, causing > > the problems you see. Did you try a mred built on a stock > > 7-STABLE? > > When it first stopped working (around the 11th, from memory), my > first approach was to rebuild it (over and over, and attempt to > debug it...) No joy that way. It's only since I reverted to > the earlier version of FreeBSD that it's started working again. > > As part of the attempt to make mred work again, I re-built > *all* of the ports that I have installed (some 900-odd), so > all of the libraries in /usr/local/lib are post-15 Jan., and > have whatever effect the change introduces. Perhaps that is > why epiphany has gone unstable on me (seems to be complaining > about failing to connect to gnomevfs). I suspect that mred > wasn't minding false-positives before, because it's been > configured/compiled with pthreads enabled (for the benefit of > Mesa/OpenGL, apparently). > Ok, in your previous mail you talked about an "exisiting binary" so I assumed you haden't tried with a recompiled one or a recompiled one didn't exhibit the problem. Anyway, you're right and I've overlooked that mred is threaded anyway so in this case it shouldn't matter if __gthread_active_p() prevously returned false-positives or not. The only way I currently can think of the new __gthread_active_p() causing problems would be if now it returned false-negatives. So far I can't reproduce such a problem nor see how that could happen though. It would help if you could debug where mred craches and what __gthread_active_p() returned in this case. Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0 RC1/SPARC64 panic in boot
On Tue, Jan 22, 2008 at 07:16:16AM +0100, Eirik verby wrote:
> Hi list,
>
> by disabling the isp driver (set hint.isp.o.disabled=1), the system
> comes up. This of course denies us access to the external disk array
> hosted by the internal QLogic controller, but pinpoints the problem.
>
> We tried setting hint.isp.0.prefer_iomap=1, which made no difference
> (though by reading the code, I don't see that it ever used this).
>
> Can anyone help us out here?
Scott, could this be due to a missing MFC of isp_sbus.c rev. 1.36?
Marius
>
> On Jan 21, 2008, at 11:23 AM, Anders Gulden Olstad wrote:
>
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA1
> >
> >SUN Ultra 2 (2x400Mhz USII, 1500MB RAM)
> >
> >Got the following panic during boot
> >
> > panic: trap: fast data access mmu miss
> > cpuid = 0
> >
> >This happened after upgrade from 6.2 -> 7.0 RC1. Tried to boot
> >from the CDROM as well, with same result
> >
> >
> >=
> >=
> >=
> >=
> >=
> >=
> >=
> >=
> >=
> >=
> >==
> >Console log:
> >
> >{0} ok boot cdrom
> >Boot device: /sbus/SUNW,[EMAIL PROTECTED],880/[EMAIL PROTECTED],0:f
> >File and args:
> >
> >>>FreeBSD/sparc64 boot block
> > Boot path: /[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880/[EMAIL
> > PROTECTED],0:f
> > Boot loader: /boot/loader
> >Consoles: Open Firmware console
> >
> >Booting with sun4u support.
> >Boot path set to /[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880/[EMAIL
> >PROTECTED],0:a
> >
> >FreeBSD/sparc64 bootstrap loader, Revision 1.0
> >([EMAIL PROTECTED], Mon Dec 24 10:09:43 UTC 2007)
> >bootpath="/[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880/[EMAIL
> >PROTECTED],0:a"
> >Loading /boot/defaults/loader.conf
> >/boot/kernel/kernel data=0x6eee48+0x72c68
> >syms=[0x8+0x76878+0x8+0x6663e]
> >\
> >Hit [Enter] to boot immediately, or any other key for command prompt.
> >Booting [/boot/kernel/kernel]...
> >nothing to autoload yet.
> >jumping to kernel entry at 0xc007.
> >stray vector interrupt 2033
> >Copyright (c) 1992-2007 The FreeBSD Project.
> >Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
> >1994
> > The Regents of the University of California. All rights
> >reserved.
> >FreeBSD is a registered trademark of The FreeBSD Foundation.
> >FreeBSD 7.0-RC1 #0: Tue Dec 25 02:17:08 UTC 2007
> > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
> >real memory = 1610612736 (1536 MB)
> >avail memory = 1550393344 (1478 MB)
> >cpu0: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU)
> >cpu1: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU)
> >FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413,
> >RF5413, REGOPS_FUNC)
> >nexus0:
> >sbus0: mem 0x1fe-0x1fe7fff irq
> >2036,2037,2038,2021,2026,2039 on nexus0
> >sbus0: clock 25.000 MHz
> >sbus dvma: DVMA map: 0xfc00 to 0x
> >sbus0: [GIANT-LOCKED]
> >sbus0: [ITHREAD]
> >sbus0: [GIANT-LOCKED]
> >sbus0: [ITHREAD]
> >initializing counter-timer
> >Timecounter "counter-timer" frequency 100 Hz quality 100
> >auxio0: mem 0x190 on sbus0
> >sbus0: mem 0xc00-0xc0001ff irq 2020 type unknown (no
> >driver attached)
> >sbus0: mem 0-0x7,0x138-0x13f type unknown (no
> >driver attached)
> >sbus0: mem 0x140-0x147 irq 2025 type block (no
> >driver attached)
> >eeprom0: mem 0x120-0x1201fff on sbus0
> >eeprom0: model mk48t59
> >scc0: mem 0x110-0x113 irq
> >2024 on
> >sbus0
> >scc0: [FILTER]
> >uart0: on scc0
> >uart0: [FILTER]
> >uart0: console (9600,n,8,1)
> >uart1: on scc0
> >uart1: [FILTER]
> >scc1: mem 0x100-0x103 irq
> >2024 on
> >sbus0
> >scc1: [FILTER]
> >uart2: on scc1
> >uart2: [FILTER]
> >uart2: keyboard (1200,n,8,1)
> >uart2: keyboard not present
> >uart3: on scc1
> >uart3: [FILTER]
> >sbus0: mem 0x130-0x137 type unknown (no driver attached)
> >sbus0: mem 0x1304000-0x1304002 type unknown (no driver
> >attached)
> >esp0: mem
> >0x880-0x88f,0x881-0x881003f irq 2016 on sbus0
> >esp0: [ITHREAD]
> >esp0: FAS366/HME, 40MHz, SCSI ID 7
> >hme0: mem
> >0x8c0-0x8c00107,0x8c02000-0x8c03fff,0x8c04000-0x8c05fff,
> >0x8c06000-0x8c07fff,0x8c07000-0x8c0701f
> >irq 2017 on sbus0
> >miibus0: on hme0
> >nsphy0: PHY 1 on miibus0
> >nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> >hme0: Ethernet address: 08:00:20:91:d2:79
> >hme0: [ITHREAD]
> >sbus0: mem 0xc80-0xc80001b irq 2018 type unknown (no
> >driver attached)
> >isp0 mem 0x1-0x1044f irq 2003 on sbus0
> >isp0: [ITHR
Re: 7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1
On Tue, Jan 22, 2008 at 09:44:05AM +1100, Andrew Reilly wrote: > Hello again, > > [to recap: drscheme, (which is an IDE that runs under the "mred" > runtime, built from ports/lang/drscheme (or actually manually > from a personal copy of that Makefile that builds the current > release: 372, rather than ver 370 in ports)) worked beautifully > on my system until I updated to 7-STABLE after 4 Jan. I track > -STABLE every week or two. After that, it segfaults before > printing or displaying anything, and running under gdb has found > that it stops in the garbage collector initialization. I > haven't raised a PR for this yet because I still think that the > problem is probably the drscheme FreeBSD configuration that has > bit-rotted a little, now that FreeBSD has changed slightly. > Still investigating... I've cc'd Joseph Koshy, because this > seems to be somehow related to PR ports/118808.] > > I've done the binary search through CVS, and established that > the precise file and revision that is causing me (or rather, > drscheme) grief: src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1 marius > at 5 Jan 22:58.51. Csupping back to 5 Jan 22:50 is enough to > make everyting happy again. > > Unfortunately, I'm at a loss to explain how this change could be > causing an existing binary to run or not, because it changes the > compiler. Well, presumably it changes the installed libc.so and > libstdc++.so, both of which are linked in at run-time (c++ is used > in mred/drscheme for the wxWidgets GUI). Indeed, the most recent > time that I backed this revision of gthr-posix.h out (regressed > to 5 Jan 22:50), drscheme started to work as soon as the system > libraries had been installed, before I had rebooted. The __gthread_active_p(), which returns false positives prior to the current version of gthr-posix.h, isn't only used in libstdc++ but also in headers that are installed beneath /usr/include/c++. So the code in those headers compiled into an existing binary which was built prior to the gthr-posix.h fix still might erroneously determine that it's running in a threaded environment while f.e. libstdc++ does not, causing the problems you see. Did you try a mred built on a stock 7-STABLE? > > Since there hasn't been any other wailing about incompatability > since this change, my guess is that mred was somehow working > around the previous FreeBSD behaviour: it has quite a bit of > low-level platform-specific configuration, since it is a > language runtime. The ideal solution will be to figure out how > to tweak it's FreeBSD compatability to suit the new operation. > If anyone can offer a hint as to which area I should be looking > at for configuration knobs, I'd be really grateful. > Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HEADS UP: [EMAIL PROTECTED]: cvs commit: src UPDATING src/sys/dev/pci pci_user.c src/sys/sys param.h pciio.h]
FYI, if your are an early adopter of FreeBSD 7 and have recompiled your ports since upgrading or using a fresh install, the ABI breakage referenced below requires you to recompile the graphics/picturebook, sysutils/hal, sysutils/radeontool and sysutils/sjog ports when tracking RELENG_7. This list of affected ports is not exhaustive though. marius 2007-10-28 17:31:52 UTC FreeBSD src repository Modified files:(Branch: RELENG_7) .UPDATING sys/dev/pci pci_user.c sys/sys param.h pciio.h Log: MFC: UPDATING 1.511; sys/dev/pci/pci_user.c 1.23, 1.24; sys/sys/param.h 1.312, sys/sys/pciio.h 1.8 Add ABI backwards compatibility to the FreeBSD 4/5/6 versions of the PCIOCGETCONF, PCIOCREAD and PCIOCWRITE IOCTLs, which was broken with the introduction of PCI domain support. As the size of struct pci_conf_io wasn't changed with that commit, this unfortunately requires the ABI of PCIOCGETCONF to be broken again in order to be able to provide backwards compatibility to the old version of that IOCTL. Approved by:re (kensmith) Revision ChangesPath 1.507.2.2 +13 -0 src/UPDATING 1.22.2.1 +284 -50 src/sys/dev/pci/pci_user.c 1.308.2.2 +1 -1 src/sys/sys/param.h 1.7.2.1+1 -1 src/sys/sys/pciio.h ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sparc64 kernel build error
On Mon, Oct 01, 2007 at 02:29:54PM +, Matthew Herzog wrote: > Hello Beasties. > > I have attached the error text and my kernel config. The build seems to > die while building ipfilter but I'm guessing that's not the real > reason for it failing. > > Thanks for any suggestions. > > -- Matt H <...> > cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. > -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath -I/usr/src/sys/contrib/ngatm > -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include > opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 > --param large-function-growth=1000 -mcmodel=medlow -msoft-float > -ffreestanding -Werror /usr/src/sys/dev/syscons/schistory.c > In file included from /usr/src/sys/dev/syscons/schistory.c:46: > ./machine/sc_machdep.h:71:1: "SC_NORM_ATTR" redefined > In file included from /usr/src/sys/dev/syscons/schistory.c:33: > ./opt_syscons.h:1:1: this is the location of the previous definition > *** Error code 1 > Remove options SC_NORM_ATTR from your kernel config file or if you really ned green on black change sys/sparc64/include/sc_machdep.h to include opt_syscons.h and only define SC_NORM_ATTR etc if they're not already defined. Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Netgear PCMCIA NIC
On Tue, Jul 31, 2007 at 09:23:02PM +0100, Tim McCormick wrote: > Hey guys, > > Having a problem on a laptop I've recently migrated from 6.1-RELEASE to > 6.2-STABLE. > > My PCMCIA NIC (Netgear GA511) no longer works, and after looking around a > bit, > I'm afraid its got me stumped. > > Getting the following from dmesg upon insertion: > > > re0: port 0x1100-0x11ff > mem 0x8800-0x880001ff irq 9 at device 0.0 on cardbus0 > miibus0: on re0 > rgephy0: on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > re0: Ethernet address: 00:18:4d:6e:be:23 > re0: couldn't set up irq > rgephy0: detached > miibus0: detached > device_attach: re0 attach returned 22 > > > Anyone able to clue me in? > The current re(4) uses an INTR_FAST type interrupt handler, which pccbb(4) doesn't allow to be set up for more or less historical reasons. Use the patch in (IMO an adequate fix): http://docs.freebsd.org/cgi/mid.cgi?20060711.154453.-1632629843.imp Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [releng_6 tinderbox] failure on sparc64/sparc64
On Fri, Feb 03, 2006 at 09:09:43AM +0100, Harti Brandt wrote: > On Thu, 2 Feb 2006, Dag-Erling Sm?rgrav wrote: > > DS>Scott Long <[EMAIL PROTECTED]> writes: > DS>> I've been trying to reproduce this on my local hardware, but I can't > DS>> trigger it. > DS> > DS>The ISP driver abuses the inline keyword. As I told mjacob earlier, > DS>the extensive inlining not only breaks the build, but probably hurts > DS>performance as well. > DS> > DS>(what gcc is complaining about, specifically, is that expanding calls > DS>to inlined functions causes isp_target_notify() to grow by more than > DS>100%) > > The interesting point is: why does it build on my real sparc (2-UII CPUs, > 512MByte memory), but not on the tinderbox. Is there something about the > crosscompiler that is different? > GCC apparently does different intermediate optimizations when built as a cross compiler than the native one; in the past we've e.g. seen a GCC bug in the machine code generation that was only triggered when GCC was built as cross compiler and fed with differently optimized intermediate code due to that. Interestingly the resulting object files generated by the cross compiler and the native one for the source file where this triggered where the same once the bug in the machine code generation was fixed. Marius -- This mail was scanned by AntiVir Milter. This product is licensed for non-commercial use. See www.antivir.de for details. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror, sparc and SCSI problems
On Sat, Jul 09, 2005 at 05:36:43PM +0100, Chris Hodgins wrote: > On 7/9/05, Danny Howard <[EMAIL PROTECTED]> wrote: > > On Fri, Jul 08, 2005 at 03:48:52PM +0100, Chris Hodgins wrote: > > > Hi all, > > > > > > Experiencing a few difficulties setting up raid mirroring across two > > > SCSI disks on a sparc based server. Disk da0 contains a working and > > > recent install of FreeBSD 5-4 RELEASE and da1 is blank. We have been > > > following the guidance given in the first part of > > > http://people.freebsd.org/~rse/mirror/ but have hit numerous problems. > > > > Chris, > > > > These instructions are useful if you don't want to boot into recovery > > console to set things up offline. You can save a lot of fancy footwork > > if you have physical access and a CD-ROM, and don't mind about 15 > > minutes of downtime. My crib sheet is at > > http://dannyman.toldme.com/2005/01/24/freebsd-howto-gmirror-system/ . > > > > If it does work for you, plesae let me know. I'd be plased to hear that > > it can handle Sparc. :) > > > > Sincerely, > > -danny > > > > Danny, > > Thanks for the link. This was actually the first link we tried to get > working and after it failed to work we followed the link on the page > to http://people.freebsd.org/~rse/mirror/. > > Everything worked fine until we arrived at this step below. > # mount /dev/mirror/gm0s1a /mnt > > It seems that gmirror does not give us any partitions. A listing of > the mirror directory shows only the gm0 node even though da0 is > partitioned. When mounting the mirror it seems that /dev/mirror/gm0 > only represents the root partition. How can we get the mirror to > recognise the other partitions? > Sparc and sparc64 don't use slices so instead of fdisk(8) and bsdlabel(8) one just uses sunlabel(8) on sparc64. This should also mean that instead of `mount /dev/mirror/gm0s1a /mnt` one would use e.g. `mount /dev/mirror/gm0a /mnt` on sparc64. I don't know though if gmirror(8) needs to be made aware of this for e.g. `gmirror label` to do the right thing or maybe already is, i.e. whether it needs further changes in order to make it work on sparc64. Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
