Re: FreeBSD 10.0-RC2 Now Available
Someone please help me here: root@fbsd10:/usr/src/contrib/unbound # uname -a FreeBSD fbsd10 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r254222: Sun Aug 11 20:14:02 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 root@fbsd10:/usr/src/contrib/unbound # freebsd-update upgrade -r 10.0-RC2 Looking up update.FreeBSD.org mirrors... 5 mirrors found. Fetching public key from update5.freebsd.org... failed. Fetching public key from update6.freebsd.org... failed. Fetching public key from update2.freebsd.org... failed. Fetching public key from update4.freebsd.org... failed. Fetching public key from update3.freebsd.org... failed. No mirrors remaining, giving up. root@fbsd10:/usr/src/contrib/unbound # ping www.gmail.com PING googlemail.l.google.com (74.125.230.182): 56 data bytes 64 bytes from 74.125.230.182: icmp_seq=0 ttl=59 time=11.663 ms 64 bytes from 74.125.230.182: icmp_seq=1 ttl=59 time=181.167 ms 64 bytes from 74.125.230.182: icmp_seq=2 ttl=59 time=9.048 ms 64 bytes from 74.125.230.182: icmp_seq=3 ttl=59 time=10.141 ms ^C --- googlemail.l.google.com ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 9.048/53.005/181.167/74.000 ms root@fbsd10:/usr/src/contrib/unbound # ping update5.freebsd.org PING update5.freebsd.org (204.9.55.80): 56 data bytes 64 bytes from 204.9.55.80: icmp_seq=0 ttl=51 time=355.456 ms 64 bytes from 204.9.55.80: icmp_seq=1 ttl=51 time=765.279 ms ^C --- update5.freebsd.org ping statistics --- 3 packets transmitted, 2 packets received, 33.3% packet loss round-trip min/avg/max/stddev = 355.456/560.368/765.279/204.911 ms Why does this fail? I have never used freebsd-update before. It's my 1st time. On 16 December 2013 18:44, Glen Barber g...@freebsd.org wrote: The second RC build of the 10.0-RELEASE release cycle is now available on the FTP servers for the amd64, i386, ia64, powerpc, powerpc64 and sparc64 architectures. The image checksums follow at the end of this email. ISO images and, for architectures that support it, the memory stick images are available here (or any of the FreeBSD mirror sites): ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.0/ If you notice problems you can report them through the normal GNATS PR system or here 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.0 branch. Important note to freebsd-update(8) users: Please be sure to follow the instructions in the following FreeBSD Errata Notices before upgrading the system to 10.0-RC2: - EN-13:04.freebsd-update: http://www.freebsd.org/security/advisories/FreeBSD-EN-13:04.freebsd-update.asc - EN-13:05.freebsd-update: http://www.freebsd.org/security/advisories/FreeBSD-EN-13:05.freebsd-update.asc Note to those downloading dvd1.iso: - While packages are available on dvd1.iso, the version of bsdconfig(8) provided with 10.0-RC2 will not be able to install them by default. This will be fixed for 10.0-RC3. - As a workaround for installing packages from the dvd, create a directory to serve as the temporary pkg(8) repository configuration directory, and fetch the configuration file that will be included on the next set of -RC builds: # mkdir -p /tmp/pkgrepo # fetch -o /tmp/pkgrepo/FreeBSD_install_cdrom.conf \ http://people.FreeBSD.org/~gjb/FreeBSD_install_cdrom.conf - Mount the dvd to the '/dist' directory: # mkdir -p /dist # mount -t cd9660 /dev/cd0 /dist - To install a package, run: # env REPOS_DIR=/tmp/pkgrepo pkg install foo - To view the list of available packages on the DVD, run: # env REPOS_DIR=/tmp/pkgrepo pkg rquery %n Pre-installed virtual machine images for 10.0-RC2 are also available for amd64 and i386 architectures. The images are located under the 'snapshots' directory on FTP, here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/10.0-RC2/ The disk images are available in both QCOW2, VHD, and VMDK format. The image download size is approximately 135 MB, which decompress to a 20GB sparse image. The partition layout is: - 512k - freebsd-boot GPT partition type (bootfs GPT label) - 1GB - freebsd-swap GPT partition type (swapfs GPT label) - ~17GB - freebsd-ufs GPT partition type (rootfs GPT label) Changes between -RC1 and -RC2 include: - Fix a crash when attempting to use a non-disk device as an iSCSI LUN. - Fix handling of empty iSCSI authentication groups. - Fix a regression in bsdinstall(8) that prevented the system from decrypting GELI providers when installing ZFS on GELI. - Several Radeon KMS bug fixes. - Several wireless bug fixes. - Several clang bug fixes. The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems
Re: FreeBSD 10.0-RC2 Now Available
Fair enough. I will use svn instead. I've never liked freebsd-update. On 17 December 2013 11:58, Niilo Kajander niilo.kajan...@gmail.com wrote: On Tue, Dec 17, 2013 at 10:49 AM, Odhiambo Washington odhia...@gmail.com wrote: Why does this fail? I have never used freebsd-update before. It's my 1st time. My understanding is that freebsd-update can't track changes between different svn revisions. It doesn't have a clue about -CURRENT or -STABLE as it only works for releases. If you intend to use freebsd-update in the future you should upgrade your system first using the install media. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 I can't hear you -- I'm using the scrambler. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
11.0-CURRENT panic at (allegedly) a dpms signal (monitor off), in drm2
14:00:~$ uname -a FreeBSD mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r259227: Thu Dec 12 10:17:56 EET 2013 r...@mkushnir.mooo.com:/usr/obj/usr/src/sys/MAREK amd64 Left my desktop (new Xorg, newcons, radeonkms) for a couple of minutes and found it rebooted after a panic. Never seen this kind of panic before. Please find links to core.txt, pciconf and devinfo: https://drive.google.com/file/d/0B9Q-zpUXxqCnWXNINDYwNTZ6d2M/edit?usp=sharing https://drive.google.com/file/d/0B9Q-zpUXxqCndEl6TDVwYmV0bDA/edit?usp=sharing https://drive.google.com/file/d/0B9Q-zpUXxqCndlhmTk92V3RkWlk/edit?usp=sharing -- Markiyan. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10.0-RC2 Now Available
On Tue, Dec 17, 2013 at 11:49:39AM +0300, Odhiambo Washington wrote: Someone please help me here: root@fbsd10:/usr/src/contrib/unbound # uname -a FreeBSD fbsd10 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r254222: Sun Aug 11 20:14:02 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 Why does this fail? I have never used freebsd-update before. It's my 1st time. You are upgrading from 10.0-CURRENT, which is not supported by freebsd-update. You will need to check out the src/ tree of stable/10 or releng/10.0 and do a source-based upgrade to -BETA or -RC, then you can use freebsd-update for future upgrades. Glen pgpHvpZoELTnd.pgp Description: PGP signature
Re: FreeBSD 10.0-RC2 Now Available
On Tue, Dec 17, 2013 at 10:49 AM, Odhiambo Washington odhia...@gmail.com wrote: Why does this fail? I have never used freebsd-update before. It's my 1st time. My understanding is that freebsd-update can't track changes between different svn revisions. It doesn't have a clue about -CURRENT or -STABLE as it only works for releases. If you intend to use freebsd-update in the future you should upgrade your system first using the install media. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10.0-RC2 Now Available
Aha! I already blew away the 10-CURRENT, downloaded the RC and installed (on VMware). Now I can play with the stuff, including unbound, freebsd-update. BTW, I always used csup, then moved to svn on my systems. This freebsd-update (sorry I always felt scared about it), how does it handle a situation where I have a custom kernel? On 17 December 2013 15:34, Glen Barber g...@freebsd.org wrote: On Tue, Dec 17, 2013 at 11:49:39AM +0300, Odhiambo Washington wrote: Someone please help me here: root@fbsd10:/usr/src/contrib/unbound # uname -a FreeBSD fbsd10 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r254222: Sun Aug 11 20:14:02 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 Why does this fail? I have never used freebsd-update before. It's my 1st time. You are upgrading from 10.0-CURRENT, which is not supported by freebsd-update. You will need to check out the src/ tree of stable/10 or releng/10.0 and do a source-based upgrade to -BETA or -RC, then you can use freebsd-update for future upgrades. Glen -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 I can't hear you -- I'm using the scrambler. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10.0-RC2 Now Available
On Tue, Dec 17, 2013 at 03:53:22PM +0300, Odhiambo Washington wrote: Aha! I already blew away the 10-CURRENT, downloaded the RC and installed (on VMware). Now I can play with the stuff, including unbound, freebsd-update. BTW, I always used csup, then moved to svn on my systems. This freebsd-update (sorry I always felt scared about it), how does it handle a situation where I have a custom kernel? The custom kernel will be replaced by the GENERIC kernel. Glen pgpJaHSXvDKp7.pgp Description: PGP signature
Re: 11.0-CURRENT panic at (allegedly) a dpms signal (monitor off), in drm2
/var/log/messages (cut out everything before approx an hour before the panic) and Xorg log of the panicked session: https://drive.google.com/file/d/0B9Q-zpUXxqCnX3IzY3BHMGRSVkk/edit?usp=sharing https://drive.google.com/file/d/0B9Q-zpUXxqCna3pfTVl2dWZraTg/edit?usp=sharing -- Markiyan. 2013/12/17 Markiyan Kushnir markiyan.kush...@gmail.com: 14:00:~$ uname -a FreeBSD mkushnir.mooo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r259227: Thu Dec 12 10:17:56 EET 2013 r...@mkushnir.mooo.com:/usr/obj/usr/src/sys/MAREK amd64 Left my desktop (new Xorg, newcons, radeonkms) for a couple of minutes and found it rebooted after a panic. Never seen this kind of panic before. Please find links to core.txt, pciconf and devinfo: https://drive.google.com/file/d/0B9Q-zpUXxqCnWXNINDYwNTZ6d2M/edit?usp=sharing https://drive.google.com/file/d/0B9Q-zpUXxqCndEl6TDVwYmV0bDA/edit?usp=sharing https://drive.google.com/file/d/0B9Q-zpUXxqCndlhmTk92V3RkWlk/edit?usp=sharing -- Markiyan. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10.0-RC2 Now Available
..and I believe that is the one thing that drove me away from freebsd-update. On 17 December 2013 16:03, Glen Barber g...@freebsd.org wrote: On Tue, Dec 17, 2013 at 03:53:22PM +0300, Odhiambo Washington wrote: Aha! I already blew away the 10-CURRENT, downloaded the RC and installed (on VMware). Now I can play with the stuff, including unbound, freebsd-update. BTW, I always used csup, then moved to svn on my systems. This freebsd-update (sorry I always felt scared about it), how does it handle a situation where I have a custom kernel? The custom kernel will be replaced by the GENERIC kernel. Glen -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 I can't hear you -- I'm using the scrambler. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
10-RC2 current wireless link aggregation not working correctly
Hi all, I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop. What happens is: If I boot the system with the Ethernet cable attached, I correctly get lagg0 active port on master- bg0- and the network is working correctly. (I mainly test pinging my gateway). When I pull the cable out, lagg0 device correctly switches to wlan0 as shown by ifconfig (wlan0 is created from wpi0), but at the same time I get no more ping replies from my gateway. I can leave the system in this state for several minutes as an example and no replies are coming through. A simple list of interfaces with ifconfig with no parameters brigs the network back to life, and I start to get back the due ping replyes, this time thrugh wireless link. Please, if possible en-light me on tis problem. I sat at your disposition with any info you may deem necessary to get this fixed (if it needs a fix). Dan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/i386
TB --- 2013-12-17 07:40:17 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-17 07:40:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-17 07:40:17 - starting HEAD tinderbox run for i386/i386 TB --- 2013-12-17 07:40:17 - cleaning the object tree TB --- 2013-12-17 07:45:55 - /usr/local/bin/svn stat /src TB --- 2013-12-17 07:45:58 - At svn revision 259496 TB --- 2013-12-17 07:45:59 - building world TB --- 2013-12-17 07:45:59 - CROSS_BUILD_TESTING=YES TB --- 2013-12-17 07:45:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-17 07:45:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-17 07:45:59 - SRCCONF=/dev/null TB --- 2013-12-17 07:45:59 - TARGET=i386 TB --- 2013-12-17 07:45:59 - TARGET_ARCH=i386 TB --- 2013-12-17 07:45:59 - TZ=UTC TB --- 2013-12-17 07:45:59 - __MAKE_CONF=/dev/null TB --- 2013-12-17 07:45:59 - cd /src TB --- 2013-12-17 07:45:59 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Dec 17 07:46:06 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Tue Dec 17 10:59:16 UTC 2013 TB --- 2013-12-17 10:59:16 - generating LINT kernel config TB --- 2013-12-17 10:59:16 - cd /src/sys/i386/conf TB --- 2013-12-17 10:59:16 - /usr/bin/make -B LINT TB --- 2013-12-17 10:59:16 - cd /src/sys/i386/conf TB --- 2013-12-17 10:59:16 - /usr/sbin/config -m LINT TB --- 2013-12-17 10:59:16 - building LINT kernel TB --- 2013-12-17 10:59:16 - CROSS_BUILD_TESTING=YES TB --- 2013-12-17 10:59:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-17 10:59:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-17 10:59:16 - SRCCONF=/dev/null TB --- 2013-12-17 10:59:16 - TARGET=i386 TB --- 2013-12-17 10:59:16 - TARGET_ARCH=i386 TB --- 2013-12-17 10:59:16 - TZ=UTC TB --- 2013-12-17 10:59:16 - __MAKE_CONF=/dev/null TB --- 2013-12-17 10:59:16 - cd /src TB --- 2013-12-17 10:59:16 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Dec 17 10:59:17 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Tue Dec 17 11:36:53 UTC 2013 TB --- 2013-12-17 11:36:53 - cd /src/sys/i386/conf TB --- 2013-12-17 11:36:53 - /usr/sbin/config -m LINT-NOINET TB --- 2013-12-17 11:36:53 - building LINT-NOINET kernel TB --- 2013-12-17 11:36:53 - CROSS_BUILD_TESTING=YES TB --- 2013-12-17 11:36:53 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-17 11:36:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-17 11:36:53 - SRCCONF=/dev/null TB --- 2013-12-17 11:36:53 - TARGET=i386 TB --- 2013-12-17 11:36:53 - TARGET_ARCH=i386 TB --- 2013-12-17 11:36:53 - TZ=UTC TB --- 2013-12-17 11:36:53 - __MAKE_CONF=/dev/null TB --- 2013-12-17 11:36:53 - cd /src TB --- 2013-12-17 11:36:53 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Tue Dec 17 11:36:53 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Tue Dec 17 12:09:16 UTC 2013 TB --- 2013-12-17 12:09:16 - cd /src/sys/i386/conf TB --- 2013-12-17 12:09:16 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-12-17 12:09:16 - building LINT-NOINET6 kernel TB --- 2013-12-17 12:09:16 - CROSS_BUILD_TESTING=YES TB --- 2013-12-17 12:09:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-17 12:09:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-17 12:09:16 - SRCCONF=/dev/null TB --- 2013-12-17 12:09:16 - TARGET=i386 TB --- 2013-12-17 12:09:16 - TARGET_ARCH=i386 TB --- 2013-12-17 12:09:16 - TZ=UTC TB --- 2013-12-17 12:09:16 - __MAKE_CONF=/dev/null TB --- 2013-12-17 12:09:16 - cd /src TB --- 2013-12-17 12:09:16 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Tue Dec 17 12:09:16 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Tue Dec 17 12:41:27 UTC 2013 TB --- 2013-12-17 12:41:27 - cd /src/sys/i386/conf TB --- 2013-12-17 12:41:27 - /usr/sbin/config -m LINT-NOIP TB --- 2013-12-17 12:41:27 - building LINT-NOIP kernel TB --- 2013-12-17 12:41:27 - CROSS_BUILD_TESTING=YES TB --- 2013-12-17 12:41:27 - MAKEOBJDIRPREFIX=/obj
Re: 10-RC2 current wireless link aggregation not working correctly
On 12/17/13 08:06, dan_partelly wrote: Hi all, I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop. What happens is: If I boot the system with the Ethernet cable attached, I correctly get lagg0 active port on master- bg0- and the network is working correctly. (I mainly test pinging my gateway). When I pull the cable out, lagg0 device correctly switches to wlan0 as shown by ifconfig (wlan0 is created from wpi0), but at the same time I get no more ping replies from my gateway. I can leave the system in this state for several minutes as an example and no replies are coming through. A simple list of interfaces with ifconfig with no parameters brigs the network back to life, and I start to get back the due ping replyes, this time thrugh wireless link. Please, if possible en-light me on tis problem. I sat at your disposition with any info you may deem necessary to get this fixed (if it needs a fix). Dan I can confirm this behavior. It also happens to me. - Nikolai Lifanov. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on amd64/amd64
TB --- 2013-12-17 07:40:17 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-17 07:40:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-17 07:40:17 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-12-17 07:40:17 - cleaning the object tree TB --- 2013-12-17 07:47:12 - /usr/local/bin/svn stat /src TB --- 2013-12-17 07:47:15 - At svn revision 259496 TB --- 2013-12-17 07:47:16 - building world TB --- 2013-12-17 07:47:16 - CROSS_BUILD_TESTING=YES TB --- 2013-12-17 07:47:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-17 07:47:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-17 07:47:16 - SRCCONF=/dev/null TB --- 2013-12-17 07:47:16 - TARGET=amd64 TB --- 2013-12-17 07:47:16 - TARGET_ARCH=amd64 TB --- 2013-12-17 07:47:16 - TZ=UTC TB --- 2013-12-17 07:47:16 - __MAKE_CONF=/dev/null TB --- 2013-12-17 07:47:16 - cd /src TB --- 2013-12-17 07:47:16 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Dec 17 07:47:23 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Tue Dec 17 11:34:19 UTC 2013 TB --- 2013-12-17 11:34:19 - generating LINT kernel config TB --- 2013-12-17 11:34:19 - cd /src/sys/amd64/conf TB --- 2013-12-17 11:34:19 - /usr/bin/make -B LINT TB --- 2013-12-17 11:34:19 - cd /src/sys/amd64/conf TB --- 2013-12-17 11:34:19 - /usr/sbin/config -m LINT TB --- 2013-12-17 11:34:19 - building LINT kernel TB --- 2013-12-17 11:34:19 - CROSS_BUILD_TESTING=YES TB --- 2013-12-17 11:34:19 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-17 11:34:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-17 11:34:19 - SRCCONF=/dev/null TB --- 2013-12-17 11:34:19 - TARGET=amd64 TB --- 2013-12-17 11:34:19 - TARGET_ARCH=amd64 TB --- 2013-12-17 11:34:19 - TZ=UTC TB --- 2013-12-17 11:34:19 - __MAKE_CONF=/dev/null TB --- 2013-12-17 11:34:19 - cd /src TB --- 2013-12-17 11:34:19 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Dec 17 11:34:19 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Tue Dec 17 12:08:47 UTC 2013 TB --- 2013-12-17 12:08:47 - cd /src/sys/amd64/conf TB --- 2013-12-17 12:08:47 - /usr/sbin/config -m LINT-NOINET TB --- 2013-12-17 12:08:47 - building LINT-NOINET kernel TB --- 2013-12-17 12:08:47 - CROSS_BUILD_TESTING=YES TB --- 2013-12-17 12:08:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-17 12:08:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-17 12:08:47 - SRCCONF=/dev/null TB --- 2013-12-17 12:08:47 - TARGET=amd64 TB --- 2013-12-17 12:08:47 - TARGET_ARCH=amd64 TB --- 2013-12-17 12:08:47 - TZ=UTC TB --- 2013-12-17 12:08:47 - __MAKE_CONF=/dev/null TB --- 2013-12-17 12:08:47 - cd /src TB --- 2013-12-17 12:08:47 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Tue Dec 17 12:08:48 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Tue Dec 17 12:40:33 UTC 2013 TB --- 2013-12-17 12:40:33 - cd /src/sys/amd64/conf TB --- 2013-12-17 12:40:33 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-12-17 12:40:33 - building LINT-NOINET6 kernel TB --- 2013-12-17 12:40:33 - CROSS_BUILD_TESTING=YES TB --- 2013-12-17 12:40:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-17 12:40:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-17 12:40:33 - SRCCONF=/dev/null TB --- 2013-12-17 12:40:33 - TARGET=amd64 TB --- 2013-12-17 12:40:33 - TARGET_ARCH=amd64 TB --- 2013-12-17 12:40:33 - TZ=UTC TB --- 2013-12-17 12:40:33 - __MAKE_CONF=/dev/null TB --- 2013-12-17 12:40:33 - cd /src TB --- 2013-12-17 12:40:33 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Tue Dec 17 12:40:33 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Tue Dec 17 13:12:09 UTC 2013 TB --- 2013-12-17 13:12:09 - cd /src/sys/amd64/conf TB --- 2013-12-17 13:12:09 - /usr/sbin/config -m LINT-NOIP TB --- 2013-12-17 13:12:09 - building LINT-NOIP kernel TB --- 2013-12-17 13:12:09 -
Re: 10-RC2 current wireless link aggregation not working correctly
Hi, The MAC of the lagg needs to be the same as the wireless interface. I'm going to just state right now that using lagg as the failover method for doing wireless/wired integration isn't supported by me. If someone wants to make it supported then they need to claim it. :) -a On 17 December 2013 05:06, dan_partelly dan_parte...@rdsor.ro wrote: Hi all, I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop. What happens is: If I boot the system with the Ethernet cable attached, I correctly get lagg0 active port on master- bg0- and the network is working correctly. (I mainly test pinging my gateway). When I pull the cable out, lagg0 device correctly switches to wlan0 as shown by ifconfig (wlan0 is created from wpi0), but at the same time I get no more ping replies from my gateway. I can leave the system in this state for several minutes as an example and no replies are coming through. A simple list of interfaces with ifconfig with no parameters brigs the network back to life, and I start to get back the due ping replyes, this time thrugh wireless link. Please, if possible en-light me on tis problem. I sat at your disposition with any info you may deem necessary to get this fixed (if it needs a fix). Dan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-RC2 current wireless link aggregation not working correctly
On 12/17/13 10:54, Adrian Chadd wrote: Hi, The MAC of the lagg needs to be the same as the wireless interface. I'm going to just state right now that using lagg as the failover method for doing wireless/wired integration isn't supported by me. If someone wants to make it supported then they need to claim it. :) -a On 17 December 2013 05:06, dan_partelly dan_parte...@rdsor.ro wrote: Hi all, I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop. What happens is: If I boot the system with the Ethernet cable attached, I correctly get lagg0 active port on master- bg0- and the network is working correctly. (I mainly test pinging my gateway). When I pull the cable out, lagg0 device correctly switches to wlan0 as shown by ifconfig (wlan0 is created from wpi0), but at the same time I get no more ping replies from my gateway. I can leave the system in this state for several minutes as an example and no replies are coming through. A simple list of interfaces with ifconfig with no parameters brigs the network back to life, and I start to get back the due ping replyes, this time thrugh wireless link. Please, if possible en-light me on tis problem. I sat at your disposition with any info you may deem necessary to get this fixed (if it needs a fix). Dan It actually is, in my case. The macs for em0, wlan0, and lagg0 all match. I can always do the failover differently, but this used to work with 9.0-RELEASE-9.2-RELEASE. - Nikolai Lifanov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-RC2 current wireless link aggregation not working correctly
On Tue, 17 Dec 2013 07:54:52 -0800, Adrian Chadd adr...@freebsd.org wrote: Hi, All 3 MACs are the same. wpi0 is set to the MAC of bg0. Wlan0 inherits the MAC of wpi0. Lagg0 is set up to the MAC of master. So everything checks out. All are the same. I have to check if the systems sends packets to the gateway after the switch on wlan0, but fails to get any packets back. I didnt had time yet for this. If someone wants to make it supported then they need to claim it. :) Who from the FreeBSD team supports it ? Dan The MAC of the lagg needs to be the same as the wireless interface. I'm going to just state right now that using lagg as the failover method for doing wireless/wired integration isn't supported by me. If someone wants to make it supported then they need to claim it. :) -a On 17 December 2013 05:06, dan_partelly dan_parte...@rdsor.ro wrote: Hi all, I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop. What happens is: If I boot the system with the Ethernet cable attached, I correctly get lagg0 active port on master- bg0- and the network is working correctly. (I mainly test pinging my gateway). When I pull the cable out, lagg0 device correctly switches to wlan0 as shown by ifconfig (wlan0 is created from wpi0), but at the same time I get no more ping replies from my gateway. I can leave the system in this state for several minutes as an example and no replies are coming through. A simple list of interfaces with ifconfig with no parameters brigs the network back to life, and I start to get back the due ping replyes, this time thrugh wireless link. Please, if possible en-light me on tis problem. I sat at your disposition with any info you may deem necessary to get this fixed (if it needs a fix). Dan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-RC2 current wireless link aggregation not working correctly
On 12/17/13 10:54, Adrian Chadd wrote: Hi, The MAC of the lagg needs to be the same as the wireless interface. I'm going to just state right now that using lagg as the failover method for doing wireless/wired integration isn't supported by me. If someone wants to make it supported then they need to claim it. :) -a On 17 December 2013 05:06, dan_partelly dan_parte...@rdsor.ro wrote: Hi all, I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop. What happens is: If I boot the system with the Ethernet cable attached, I correctly get lagg0 active port on master- bg0- and the network is working correctly. (I mainly test pinging my gateway). When I pull the cable out, lagg0 device correctly switches to wlan0 as shown by ifconfig (wlan0 is created from wpi0), but at the same time I get no more ping replies from my gateway. I can leave the system in this state for several minutes as an example and no replies are coming through. A simple list of interfaces with ifconfig with no parameters brigs the network back to life, and I start to get back the due ping replyes, this time thrugh wireless link. Please, if possible en-light me on tis problem. I sat at your disposition with any info you may deem necessary to get this fixed (if it needs a fix). Dan Also, this method is still described in the handbook: https://www.freebsd.org/doc/handbook/network-aggregation.html#networking-lagg-wired-and-wireless If this isn't supposed to work, then the handbook needs to be updated. - Nikolai Lifanov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-RC2 current wireless link aggregation not working correctly
I'm the wireless stack maintainer and I currently don't support that. Sorry. -a On 17 December 2013 08:10, dan_partelly dan_parte...@rdsor.ro wrote: On Tue, 17 Dec 2013 07:54:52 -0800, Adrian Chadd adr...@freebsd.org wrote: Hi, All 3 MACs are the same. wpi0 is set to the MAC of bg0. Wlan0 inherits the MAC of wpi0. Lagg0 is set up to the MAC of master. So everything checks out. All are the same. I have to check if the systems sends packets to the gateway after the switch on wlan0, but fails to get any packets back. I didnt had time yet for this. If someone wants to make it supported then they need to claim it. :) Who from the FreeBSD team supports it ? Dan The MAC of the lagg needs to be the same as the wireless interface. I'm going to just state right now that using lagg as the failover method for doing wireless/wired integration isn't supported by me. If someone wants to make it supported then they need to claim it. :) -a On 17 December 2013 05:06, dan_partelly dan_parte...@rdsor.ro wrote: Hi all, I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop. What happens is: If I boot the system with the Ethernet cable attached, I correctly get lagg0 active port on master- bg0- and the network is working correctly. (I mainly test pinging my gateway). When I pull the cable out, lagg0 device correctly switches to wlan0 as shown by ifconfig (wlan0 is created from wpi0), but at the same time I get no more ping replies from my gateway. I can leave the system in this state for several minutes as an example and no replies are coming through. A simple list of interfaces with ifconfig with no parameters brigs the network back to life, and I start to get back the due ping replyes, this time thrugh wireless link. Please, if possible en-light me on tis problem. I sat at your disposition with any info you may deem necessary to get this fixed (if it needs a fix). Dan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-RC2 current wireless link aggregation not working correctly
On 17 December 2013 08:12, Nikolai Lifanov lifa...@mail.lifanov.com wrote: Also, this method is still described in the handbook: https://www.freebsd.org/doc/handbook/network-aggregation.html#networking-lagg-wired-and-wireless If this isn't supposed to work, then the handbook needs to be updated. I'd be really happy if someone removed it until it was actually debugged correctly and documented in the code. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-RC2 current wireless link aggregation not working correctly
No problem. Can you point me to the relevant source files in the kernel tree, please ? Dan On Tue, 17 Dec 2013 08:43:09 -0800, Adrian Chadd adr...@freebsd.org wrote: I'm the wireless stack maintainer and I currently don't support that. Sorry. -a On 17 December 2013 08:10, dan_partelly dan_parte...@rdsor.ro wrote: On Tue, 17 Dec 2013 07:54:52 -0800, Adrian Chadd adr...@freebsd.org wrote: Hi, All 3 MACs are the same. wpi0 is set to the MAC of bg0. Wlan0 inherits the MAC of wpi0. Lagg0 is set up to the MAC of master. So everything checks out. All are the same. I have to check if the systems sends packets to the gateway after the switch on wlan0, but fails to get any packets back. I didnt had time yet for this. If someone wants to make it supported then they need to claim it. :) Who from the FreeBSD team supports it ? Dan The MAC of the lagg needs to be the same as the wireless interface. I'm going to just state right now that using lagg as the failover method for doing wireless/wired integration isn't supported by me. If someone wants to make it supported then they need to claim it. :) -a On 17 December 2013 05:06, dan_partelly dan_parte...@rdsor.ro wrote: Hi all, I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop. What happens is: If I boot the system with the Ethernet cable attached, I correctly get lagg0 active port on master- bg0- and the network is working correctly. (I mainly test pinging my gateway). When I pull the cable out, lagg0 device correctly switches to wlan0 as shown by ifconfig (wlan0 is created from wpi0), but at the same time I get no more ping replies from my gateway. I can leave the system in this state for several minutes as an example and no replies are coming through. A simple list of interfaces with ifconfig with no parameters brigs the network back to life, and I start to get back the due ping replyes, this time thrugh wireless link. Please, if possible en-light me on tis problem. I sat at your disposition with any info you may deem necessary to get this fixed (if it needs a fix). Dan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-RC2 current wireless link aggregation not working correctly
On 2013-12-17 10:54, Adrian Chadd wrote: Hi, The MAC of the lagg needs to be the same as the wireless interface. I'm going to just state right now that using lagg as the failover method for doing wireless/wired integration isn't supported by me. If someone wants to make it supported then they need to claim it. :) -a On 17 December 2013 05:06, dan_partelly dan_parte...@rdsor.ro wrote: Hi all, I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop. What happens is: If I boot the system with the Ethernet cable attached, I correctly get lagg0 active port on master- bg0- and the network is working correctly. (I mainly test pinging my gateway). When I pull the cable out, lagg0 device correctly switches to wlan0 as shown by ifconfig (wlan0 is created from wpi0), but at the same time I get no more ping replies from my gateway. I can leave the system in this state for several minutes as an example and no replies are coming through. A simple list of interfaces with ifconfig with no parameters brigs the network back to life, and I start to get back the due ping replyes, this time thrugh wireless link. Please, if possible en-light me on tis problem. I sat at your disposition with any info you may deem necessary to get this fixed (if it needs a fix). Dan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org If I am am understanding correctly, Dan and Nikolai say that just running 'ifconfig' brings the lagg back to life. Why would that make a difference at all? Running ifconfig with no parameters shouldn't be changing anything. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: 10-RC2 current wireless link aggregation not working correctly
On 12/17/13 12:34, Allan Jude wrote: On 2013-12-17 10:54, Adrian Chadd wrote: Hi, The MAC of the lagg needs to be the same as the wireless interface. I'm going to just state right now that using lagg as the failover method for doing wireless/wired integration isn't supported by me. If someone wants to make it supported then they need to claim it. :) -a On 17 December 2013 05:06, dan_partelly dan_parte...@rdsor.ro wrote: Hi all, I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop. What happens is: If I boot the system with the Ethernet cable attached, I correctly get lagg0 active port on master- bg0- and the network is working correctly. (I mainly test pinging my gateway). When I pull the cable out, lagg0 device correctly switches to wlan0 as shown by ifconfig (wlan0 is created from wpi0), but at the same time I get no more ping replies from my gateway. I can leave the system in this state for several minutes as an example and no replies are coming through. A simple list of interfaces with ifconfig with no parameters brigs the network back to life, and I start to get back the due ping replyes, this time thrugh wireless link. Please, if possible en-light me on tis problem. I sat at your disposition with any info you may deem necessary to get this fixed (if it needs a fix). Dan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org If I am am understanding correctly, Dan and Nikolai say that just running 'ifconfig' brings the lagg back to life. Why would that make a difference at all? Running ifconfig with no parameters shouldn't be changing anything. I see the same lagg behavior change going from 9.2-10.0, but for me the test is slightly different. My wired and wireless networks use different IP address ranges, so I need to re-run dhclient on lagg0, but I can't get an address on it. In fact, dhclient doesn't work at all with a lagg interface when it is only backed by my wireless card. Without a lagg interface, I can get addresses on both wired and wireless cards individually and act dual-homed just fine. - Nikolai Lifanov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-RC2 current wireless link aggregation not working correctly
Yes, this is correct. A simple list of the interfaces with ifconfig makes the system recover and restart activity on the secondary port. Its a good starting point to hunt down the problem. One of the ioctls sent has this side effect. Dan If I am am understanding correctly, Dan and Nikolai say that just running 'ifconfig' brings the lagg back to life. Why would that make a difference at all? Running ifconfig with no parameters shouldn't be changing anything. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS UP] xorg version switch in CURRENT
On Mon, Dec 16, 2013 at 12:20:53PM +0100, Niclas Zeising wrote: To get VT switching when using KMS drivers (ATI, Intel) please use newcons: https://wiki.freebsd.org/Newcons or if that is not possible, force the use of the vesa driver for xorg. It appears that newcons is unusable with a static kernel. Adding 'device drm2' and 'device i915kms' to my kernel config results in a quick death to 'make buldkernel'. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-RC2 current wireless link aggregation not working correctly
Ive no idea sorry. Its likely an ifnet change and not anything WiFi specific. :( On Dec 17, 2013 12:04 PM, dan_partelly dan_parte...@rdsor.ro wrote: Yes, this is correct. A simple list of the interfaces with ifconfig makes the system recover and restart activity on the secondary port. Its a good starting point to hunt down the problem. One of the ioctls sent has this side effect. Dan If I am am understanding correctly, Dan and Nikolai say that just running 'ifconfig' brings the lagg back to life. Why would that make a difference at all? Running ifconfig with no parameters shouldn't be changing anything. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS UP] xorg version switch in CURRENT
I'm rapidly wondering if building this way should become unsupported. Too muxh unknown stuff is needed at startup and wed have to load all firmware bits to make it remotely work. On Dec 17, 2013 2:08 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Mon, Dec 16, 2013 at 12:20:53PM +0100, Niclas Zeising wrote: To get VT switching when using KMS drivers (ATI, Intel) please use newcons: https://wiki.freebsd.org/Newcons or if that is not possible, force the use of the vesa driver for xorg. It appears that newcons is unusable with a static kernel. Adding 'device drm2' and 'device i915kms' to my kernel config results in a quick death to 'make buldkernel'. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Request for testing an alternate branch
On Saturday, December 14, 2013 8:22:41 pm Justin Hibbits wrote: On Thu, 12 Dec 2013 14:15:47 -0500 John Baldwin j...@freebsd.org wrote: On Wednesday, December 11, 2013 5:40:30 pm Justin Hibbits wrote: On Wed, Dec 11, 2013 at 1:26 PM, John Baldwin j...@freebsd.org wrote: On Thursday, December 05, 2013 1:21:13 am Justin Hibbits wrote: I've been working on the projects/pmac_pmu branch for some time now to add suspend/resume as well as CPU speed change for certain PowerPC machines, about a year since I created the branch, and now it's stable enough that I want to merge it into HEAD, hence this request. However, it does touch several drivers, turning them into early drivers, such that they can be initialized, and suspended and resumed at a different time. Saying that, I do need testing from other architectures, to make sure I haven't broken anything. The technical details: To get proper ordering, I've extended the bus_generic_suspend() and bus_generic_resume() to do multiple passes. Devices which cannot be enabled or disabled at the current pass level would return an EAGAIN. This could possibly cause problems, since it's an addition to an existing API rather than a new API to run along side it, so it needs a great deal of testing. It works fine on PowerPC, but I don't have any i386/amd64 or sparc64 hardware to test it on, so would like others who do to test it. I don't think that it would impact x86 at all (testing is obviously required), because the nexus is not an EARLY_DRIVER_MODULE, so all devices would be handled at the same pass. But, I do know the sparc64 has an EARLY_DRIVER_MODULE() nexus, so that will likely be impacted. I have patches to change many x86 drivers to use EARLY_DRIVER_MODULE() FWIW. Also, I'm still not a fan of the EAGAIN approach. I'd rather have a method in bus_if.m to suspend or resume a single device and to track that a device is suspended or resumed via a device_t flag or some such. (I think I had suggested this previously as it would also allow us to have a tool to suspend/resume individual drivers at runtime apart from a full suspend/resume request). -- John Baldwin Understood. You had mentioned something along those lines before. Is it safe/sane to partially merge a branch into HEAD? If so, I can merge only the changes necessary for PMU cpufreq, and work on the suspend/resume separately. I put them together because most of the low level code involved is the same between them. Yes, you can split them up. However, the way to do that is to generate a diff and patch that into a head checkout and commit. There's not a good way to have 'svn merge' do it AFAIK. I do like your idea of a device_t flag, but I'm not sure what the best way to go with that would be. I do already use a device_t flag to determine if the device is suspended, but only bus_generic_* access that in this patch. Would a better way be: * root_suspend instead of suspending its children, instead traverses and suspends each descendent in reverse order. * While doing this, insert each device upon successful suspend into a list. * For root_resume(), traverse the list back, and suspend each device in the reverse order. I would rather do it more the way that multipass attach now works where you do scans of the entire device tree as you walk the pass number down (during suspend) suspending any devices that are not yet suspended if their pass number is = current pass number, then on resume you do scans of the entire tree raising the pass number back up using similar logic to attach where you resume any suspended devices if the driver's pass number is = current pass number. With this, add a new method, called device_suspend_child() to suspend a specific child if it hasn't already been suspended. Well, I would call it 'bus_suspend_child' and 'bus_resume_child' as these would be bus methods in bus_if.m. * This could require modifying the PCI driver to move the device child suspend/resume into those functions, instead of doing that logic in the device_suspend/device_resume itself. Correct. bus_generic_suspend() and bus_suspend_resume() would turn into loops that look a lot like bus_generic_new_pass() (so the logic for honoring pass numbers would happen in these routines and they would invoke bus_suspend_child() and bus_resume_child() to change the state of individual drivers). device_suspend() and device_resume() for the root device would look like bus_set_pass() with a similar loop that walked through the pass levels and invoked bus_generic_suspend/resume after each pass change to start the pass across the device tree. I guess, in short, I'm asking: Is it fine if I merge only the code necessary for this
Re: [HEADS UP] xorg version switch in CURRENT
On 12/17/13 14:07, Steve Kargl wrote: On Mon, Dec 16, 2013 at 12:20:53PM +0100, Niclas Zeising wrote: To get VT switching when using KMS drivers (ATI, Intel) please use newcons: https://wiki.freebsd.org/Newcons or if that is not possible, force the use of the vesa driver for xorg. It appears that newcons is unusable with a static kernel. Adding 'device drm2' and 'device i915kms' to my kernel config results in a quick death to 'make buldkernel'. You may not want it either. The radeon KMS driver, if loaded with newcons before X, replaces your console with snow (or at least it did the last time I tried it). -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
10-RC unable to build kernel without INET (i.e. IPv6-only)
Under 9.2 the following could be used to build an IPv6-only kernel:
/sys/amd64/conf/TEST :
include GENERIC
makeoptions MKMODULESENV+=WITHOUT_INET_SUPPORT=
nooptions INET
Now with stable/10 the:
make buildkernel KERNCONF=TEST
fails while building xen support:
[...]
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -
Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs
-fdiagnostics-show-option -Wno-error-tautological-compare
-Wno-error-empty-body -Wno-error-
parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq
-I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include
opt_global.h
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-
tables -ffreestanding -fstack-protector -Werror
/usr/src/sys/dev/xen/control/control.c
ctfconvert -L VERSION -g control.o
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -
Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs
-fdiagnostics-show-option -Wno-error-tautological-compare
-Wno-error-empty-body -Wno-error-
parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq
-I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include
opt_global.h
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-
tables -ffreestanding -fstack-protector -Werror
/usr/src/sys/dev/xen/netback/netback.c
/usr/src/sys/dev/xen/netback/netback.c:2244:8: error: use of undeclared
identifier 'ifr'
if (ifr-ifr_reqcap IFCAP_TXCSUM) {
^
/usr/src/sys/dev/xen/netback/netback.c:2251:9: error: use of undeclared
identifier 'ifr'
if ((ifr-ifr_reqcap IFCAP_RXCSUM)) {
^
/usr/src/sys/dev/xen/netback/netback.c:2284:18: error: use of undeclared
identifier 'ifr'
ifp-if_mtu = ifr-ifr_mtu;
^
/usr/src/sys/dev/xen/netback/netback.c:2292:31: error: use of undeclared
identifier 'ifr'
error = ifmedia_ioctl(ifp, ifr, xnb-sc_media, cmd);
^
4 errors generated.
*** Error code 1
Stop.
make[2]: stopped in /usr/obj/usr/src/sys/TEST
*** Error code 1
Mark
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS UP] xorg version switch in CURRENT
On Tue, Dec 17, 2013 at 12:15:33PM -0800, Adrian Chadd wrote: On Dec 17, 2013 2:08 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Mon, Dec 16, 2013 at 12:20:53PM +0100, Niclas Zeising wrote: To get VT switching when using KMS drivers (ATI, Intel) please use newcons: https://wiki.freebsd.org/Newcons or if that is not possible, force the use of the vesa driver for xorg. It appears that newcons is unusable with a static kernel. Adding 'device drm2' and 'device i915kms' to my kernel config results in a quick death to 'make buldkernel'. I'm rapidly wondering if building this way should become unsupported. Too muxh unknown stuff is needed at startup and wed have to load all firmware bits to make it remotely work. Well, in that case, it should be formally deprecated, which means it is here for at least the FreeBSD-11 release cycle. I suppose you can try to fast-track the deprecation by having Release Engineering slip a note into the Release Notes of FreeBSD-10. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
On 16.12.2013 08:36, d...@gmx.com wrote: Still nobody wants to apply Robert Noland's DRM patch? What problem(s) does this patch fix? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: [HEADS UP] xorg version switch in CURRENT
On Tue, 17 Dec 2013 14:12:05 -0600 Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 12/17/13 14:07, Steve Kargl wrote: On Mon, Dec 16, 2013 at 12:20:53PM +0100, Niclas Zeising wrote: To get VT switching when using KMS drivers (ATI, Intel) please use newcons: https://wiki.freebsd.org/Newcons or if that is not possible, force the use of the vesa driver for xorg. It appears that newcons is unusable with a static kernel. Adding 'device drm2' and 'device i915kms' to my kernel config results in a quick death to 'make buldkernel'. You may not want it either. The radeon KMS driver, if loaded with newcons before X, replaces your console with snow (or at least it did the last time I tried it). Nathan, on which h/w you did that test? 3 different systems with Intel graphic works fine for me. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Aleksandr Rybalko r...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [rfc] [patch] do not stop watchdog on shutdown
On 2013-12-17 16:28, Aleksandr Rybalko wrote:
On Tue, 17 Dec 2013 10:53:02 -0800
Maksim Yevmenkin maksim.yevmen...@gmail.com wrote:
hello,
Hi Maksim!
would anyone object to this patch?
It is good idea, but sometimes shutdown sequence longer than some H/W
watchdogs even support.
I have one board which can do only 20sec maximum time.
max
Index: src/etc/rc.d/watchdogd
===
--- src/etc/rc.d/watchdogd (revision 2999)
+++ src/etc/rc.d/watchdogd (working copy)
@@ -39,4 +39,7 @@
pidfile=/var/run/${name}.pid
load_rc_config $name
+
+sig_stop=${watchdogd_sig_stop:-TERM}
+
run_rc_command $1
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
I've been seeing an issue where sometimes my system seems to hang after
the shutdown. where not stopping the watchdog might help. I wonder if it
would be best to make some kind of rc.conf variable to allow the user to
opt for one or the other, keeping the current behaviour for POLA.
--
Allan Jude
signature.asc
Description: OpenPGP digital signature
Re: 11.0-CURRENT panic at (allegedly) a dpms signal (monitor off), in drm2
On 17.12.2013 13:19, Markiyan Kushnir wrote: Left my desktop (new Xorg, newcons, radeonkms) for a couple of minutes and found it rebooted after a panic. Never seen this kind of panic before. That's weird: the code leading to this panic in unreachable, because there's no way currently (that I know of) to change the power management method of the driver to dynamic. Can you reproduce the problem? If it helps, you can force your monitor off using xset(1): xset dpms force off -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
[rfc] [patch] do not stop watchdog on shutdown
hello,
would anyone object to this patch?
max
Index: src/etc/rc.d/watchdogd
===
--- src/etc/rc.d/watchdogd (revision 2999)
+++ src/etc/rc.d/watchdogd (working copy)
@@ -39,4 +39,7 @@
pidfile=/var/run/${name}.pid
load_rc_config $name
+
+sig_stop=${watchdogd_sig_stop:-TERM}
+
run_rc_command $1
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [rfc] [patch] do not stop watchdog on shutdown
On Tue, 17 Dec 2013 10:53:02 -0800
Maksim Yevmenkin maksim.yevmen...@gmail.com wrote:
hello,
Hi Maksim!
would anyone object to this patch?
It is good idea, but sometimes shutdown sequence longer than some H/W
watchdogs even support.
I have one board which can do only 20sec maximum time.
max
Index: src/etc/rc.d/watchdogd
===
--- src/etc/rc.d/watchdogd (revision 2999)
+++ src/etc/rc.d/watchdogd (working copy)
@@ -39,4 +39,7 @@
pidfile=/var/run/${name}.pid
load_rc_config $name
+
+sig_stop=${watchdogd_sig_stop:-TERM}
+
run_rc_command $1
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
--
Aleksandr Rybalko r...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [rfc] [patch] do not stop watchdog on shutdown
on 17/12/2013 20:53 Maksim Yevmenkin said the following:
hello,
would anyone object to this patch?
max
Index: src/etc/rc.d/watchdogd
===
--- src/etc/rc.d/watchdogd (revision 2999)
+++ src/etc/rc.d/watchdogd (working copy)
@@ -39,4 +39,7 @@
pidfile=/var/run/${name}.pid
load_rc_config $name
+
+sig_stop=${watchdogd_sig_stop:-TERM}
+
run_rc_command $1
I wonder if anyone could object to this rather generic (and NOP by default)
change.
I see your intent, but a few words about it would not hurt :-)
BTW, for a while now we have some support for interacting with the watchdog(9)
from within the kernel. I have the following local patch / hack that makes use
of that support:
commit b64c5e855420f2d905a04f69fad5de116e8ffae5
Author: Andriy Gapon a...@icyb.net.ua
Date: Fri Nov 25 10:00:59 2011 +0200
[test] arm the watchdog before going into the final shutdown/reboot step
... to preclude hanging on that step.
Note: halt assumes the limbo, so no watchdog for that case.
diff --git a/sys/kern/kern_shutdown.c b/sys/kern/kern_shutdown.c
index eaa78b8e..88afaa9 100644
--- a/sys/kern/kern_shutdown.c
+++ b/sys/kern/kern_shutdown.c
@@ -444,6 +444,11 @@ kern_reboot(int howto)
if ((howto (RB_HALT|RB_DUMP)) == RB_DUMP !cold !dumping)
doadump(TRUE);
+ if ((howto RB_HALT) != 0)
+ wdog_kern_pat(0);
+ else
+ wdog_kern_pat(WD_TO_32SEC + 1);
+
/* Now that we're going to really halt the system... */
EVENTHANDLER_INVOKE(shutdown_final, howto);
Admittedly, there is a gap between userland watchdog being stopped and kernel
watchdog taking over. I wish that we had 'proper' integration between them,
with proper hand-off, etc.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [rfc] [patch] do not stop watchdog on shutdown
Hello Aleksandr
would anyone object to this patch?
It is good idea, but sometimes shutdown sequence longer than some H/W
watchdogs even support.
I have one board which can do only 20sec maximum time.
yes. its up to the user to configure appropriate watchdog timeout.
this features is mostly for light-out type of environments where
remote hands are not easily available.
thanks
max
Index: src/etc/rc.d/watchdogd
===
--- src/etc/rc.d/watchdogd (revision 2999)
+++ src/etc/rc.d/watchdogd (working copy)
@@ -39,4 +39,7 @@
pidfile=/var/run/${name}.pid
load_rc_config $name
+
+sig_stop=${watchdogd_sig_stop:-TERM}
+
run_rc_command $1
___
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [rfc] [patch] do not stop watchdog on shutdown
Hello Allan I've been seeing an issue where sometimes my system seems to hang after the shutdown. where not stopping the watchdog might help. I wonder if it would be best to make some kind of rc.conf variable to allow the user to opt for one or the other, keeping the current behaviour for POLA. by default current behavior is preserved, i.e. watchdogd is killed with -TERM. to prevent watchdogd from stopping timer one needs to put watchdogd_sig_stop=KILL into /etc/rc.conf. thanks max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [rfc] [patch] do not stop watchdog on shutdown
On Tue, Dec 17, 2013 at 2:00 PM, Andriy Gapon a...@freebsd.org wrote:
on 17/12/2013 20:53 Maksim Yevmenkin said the following:
hello,
would anyone object to this patch?
max
Index: src/etc/rc.d/watchdogd
===
--- src/etc/rc.d/watchdogd (revision 2999)
+++ src/etc/rc.d/watchdogd (working copy)
@@ -39,4 +39,7 @@
pidfile=/var/run/${name}.pid
load_rc_config $name
+
+sig_stop=${watchdogd_sig_stop:-TERM}
+
run_rc_command $1
I wonder if anyone could object to this rather generic (and NOP by default)
change.
I see your intent, but a few words about it would not hurt :-)
well, when watchdogd is asked to exit nicely (via SIGTERM) it will
stop timer. since watchdogd rc.d script is marked as 'shutdown' it
will exit (on shutdown) and stop timer. if system happens to hung
after this, manual reset is required. when one operates in
lights-out type of environments and without readily available
remote hands it could create a problem.
default behavior is preserved, i.e. watchdogd will still be killed via
SIGTERM and timer will be stopped. in order to activate new feature,
one needs to put
watchdogd_sig_stop=KILL
into /etc/rc.conf and also make sure watchdogd timeout is set to long
enough value make sure system comes back online before timeout fires.
BTW, for a while now we have some support for interacting with the watchdog(9)
from within the kernel. I have the following local patch / hack that makes
use
of that support:
commit b64c5e855420f2d905a04f69fad5de116e8ffae5
Author: Andriy Gapon a...@icyb.net.ua
Date: Fri Nov 25 10:00:59 2011 +0200
[test] arm the watchdog before going into the final shutdown/reboot step
... to preclude hanging on that step.
Note: halt assumes the limbo, so no watchdog for that case.
diff --git a/sys/kern/kern_shutdown.c b/sys/kern/kern_shutdown.c
index eaa78b8e..88afaa9 100644
--- a/sys/kern/kern_shutdown.c
+++ b/sys/kern/kern_shutdown.c
@@ -444,6 +444,11 @@ kern_reboot(int howto)
if ((howto (RB_HALT|RB_DUMP)) == RB_DUMP !cold !dumping)
doadump(TRUE);
+ if ((howto RB_HALT) != 0)
+ wdog_kern_pat(0);
+ else
+ wdog_kern_pat(WD_TO_32SEC + 1);
+
/* Now that we're going to really halt the system... */
EVENTHANDLER_INVOKE(shutdown_final, howto);
Admittedly, there is a gap between userland watchdog being stopped and kernel
watchdog taking over. I wish that we had 'proper' integration between them,
with proper hand-off, etc.
fixed timeout of 32 sec (if i'm understanding this correctly) might
not be enough for all usage cases. its definitely not enough in for
our usage case. at the very least timeout value should be configurable
to be useful in our case.
thanks,
max
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS UP] xorg version switch in CURRENT
On Tue, 17 Dec 2013 12:07:56 -0800
Steve Kargl s...@troutmask.apl.washington.edu wrote:
On Mon, Dec 16, 2013 at 12:20:53PM +0100, Niclas Zeising wrote:
To get VT switching when using KMS drivers (ATI, Intel) please use
newcons: https://wiki.freebsd.org/Newcons or if that is not
possible, force the use of the vesa driver for xorg.
It appears that newcons is unusable with a static kernel.
Adding 'device drm2' and 'device i915kms' to my kernel
config results in a quick death to 'make buldkernel'.
Hi Steve!
Don't panic :)
drm2/i915kms/radeonkms can't be built as part of static kernel.
at least no definitions for that (sys/conf/files or sys/conf/files.
${ARCH} should contain instructions which modules to include).
and newcons is unrelated here :)
You can try it with just preload modules.
1. Build/install kernel with vt and vt_vga.
2. reboot and break in the loader.
3. do: load i915kms
4. do: boot
Have a nice day!
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
WBW
--
Aleksandr Rybalko r...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[HEADS UP] enabling LLDB debugger by default on amd64
The in-tree snapshot of LLDB is at a point where it's usable and suitable for wider testing on amd64, and so I intend to enable it by default in the near future. Further information on the FreeBSD port of LLDB is on the wiki, at https://wiki.freebsd.org/lldb On my desktop LLDB added about 5 minutes to a buildworld and 80MB to objdir (over a baseline of about an hour and 1.8GB). If you wish to avoid building it, you can add 'WITHOUT_LLDB=' to src.conf. -Ed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [rfc] [patch] do not stop watchdog on shutdown
On Tue, 17 Dec 2013 14:03:43 -0800
Maksim Yevmenkin maksim.yevmen...@gmail.com wrote:
Hello Aleksandr
would anyone object to this patch?
It is good idea, but sometimes shutdown sequence longer than some
H/W watchdogs even support.
I have one board which can do only 20sec maximum time.
yes. its up to the user to configure appropriate watchdog timeout.
this features is mostly for light-out type of environments where
remote hands are not easily available.
Totally agree :)
thanks
max
Index: src/etc/rc.d/watchdogd
===
--- src/etc/rc.d/watchdogd (revision 2999)
+++ src/etc/rc.d/watchdogd (working copy)
@@ -39,4 +39,7 @@
pidfile=/var/run/${name}.pid
load_rc_config $name
+
+sig_stop=${watchdogd_sig_stop:-TERM}
+
run_rc_command $1
___
--
Aleksandr Rybalko r...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS UP] enabling LLDB debugger by default on amd64
Any plans to get kernel debugging working? On 12/17/13 14:15, Ed Maste wrote: The in-tree snapshot of LLDB is at a point where it's usable and suitable for wider testing on amd64, and so I intend to enable it by default in the near future. Further information on the FreeBSD port of LLDB is on the wiki, at https://wiki.freebsd.org/lldb On my desktop LLDB added about 5 minutes to a buildworld and 80MB to objdir (over a baseline of about an hour and 1.8GB). If you wish to avoid building it, you can add 'WITHOUT_LLDB=' to src.conf. -Ed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS UP] xorg version switch in CURRENT
On Wed, Dec 18, 2013 at 12:15:52AM +0200, Aleksandr Rybalko wrote:
On Tue, 17 Dec 2013 12:07:56 -0800
Steve Kargl s...@troutmask.apl.washington.edu wrote:
On Mon, Dec 16, 2013 at 12:20:53PM +0100, Niclas Zeising wrote:
To get VT switching when using KMS drivers (ATI, Intel) please use
newcons: https://wiki.freebsd.org/Newcons or if that is not
possible, force the use of the vesa driver for xorg.
It appears that newcons is unusable with a static kernel.
Adding 'device drm2' and 'device i915kms' to my kernel
config results in a quick death to 'make buldkernel'.
Don't panic :)
No panic, here.
drm2/i915kms/radeonkms can't be built as part of static kernel.
at least no definitions for that (sys/conf/files or sys/conf/files.
${ARCH} should contain instructions which modules to include).
and newcons is unrelated here :)
You can try it with just preload modules.
1. Build/install kernel with vt and vt_vga.
2. reboot and break in the loader.
3. do: load i915kms
4. do: boot
(Un)fortunately, I do not use modules.
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS UP] xorg version switch in CURRENT
On 12/17/13 15:32, Aleksandr Rybalko wrote: On Tue, 17 Dec 2013 14:12:05 -0600 Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 12/17/13 14:07, Steve Kargl wrote: On Mon, Dec 16, 2013 at 12:20:53PM +0100, Niclas Zeising wrote: To get VT switching when using KMS drivers (ATI, Intel) please use newcons: https://wiki.freebsd.org/Newcons or if that is not possible, force the use of the vesa driver for xorg. It appears that newcons is unusable with a static kernel. Adding 'device drm2' and 'device i915kms' to my kernel config results in a quick death to 'make buldkernel'. You may not want it either. The radeon KMS driver, if loaded with newcons before X, replaces your console with snow (or at least it did the last time I tried it). Nathan, on which h/w you did that test? 3 different systems with Intel graphic works fine for me. This is on the following graphics card on amd64: vgapci0@pci0:3:0:0: class=0x03 card=0x10022f43 chip=0x95cc1002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'RV620 [ATI FireGL V3700]' I'll run the test again today or tomorrow and see if it still happens. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS UP] xorg version switch in CURRENT
On 18.12.2013 01:27, Nathan Whitehorn wrote: On 12/17/13 15:32, Aleksandr Rybalko wrote: On Tue, 17 Dec 2013 14:12:05 -0600 Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 12/17/13 14:07, Steve Kargl wrote: On Mon, Dec 16, 2013 at 12:20:53PM +0100, Niclas Zeising wrote: To get VT switching when using KMS drivers (ATI, Intel) please use newcons: https://wiki.freebsd.org/Newcons or if that is not possible, force the use of the vesa driver for xorg. It appears that newcons is unusable with a static kernel. Adding 'device drm2' and 'device i915kms' to my kernel config results in a quick death to 'make buldkernel'. You may not want it either. The radeon KMS driver, if loaded with newcons before X, replaces your console with snow (or at least it did the last time I tried it). Nathan, on which h/w you did that test? 3 different systems with Intel graphic works fine for me. This is on the following graphics card on amd64: vgapci0@pci0:3:0:0: class=0x03 card=0x10022f43 chip=0x95cc1002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'RV620 [ATI FireGL V3700]' I'll run the test again today or tomorrow and see if it still happens. -Nathan Please do. Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-RC2 current wireless link aggregation not working correctly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/17/13 09:34, Allan Jude wrote: If I am am understanding correctly, Dan and Nikolai say that just running 'ifconfig' brings the lagg back to life. Why would that make a difference at all? Running ifconfig with no parameters shouldn't be changing anything. I don't really believe these claim. I had similar issue in the past and found an 'arp -a -d' would fix it so I didn't pursued further but I think this would be an interesting problem to get addressed. If I would take an guess, I would start from making lagg(4) interface to initiate one or a few gratuitous ARP broadcast when the active port changes. Some switches could use this to kick out their (outdated) memory of where the port is. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJSsPQLAAoJEJW2GBstM+nsyXoP/RCeHdu1PVCooIUxzjhqWMJG 3RyN9i85O1WYpgZwHCSC9mkFKM6GjEIiyaNKCvdYzN/k+d9aCQSXIShgIGutM6ie hFD4GCGrevjquHCddpULlUE+iwj0qIJWSyRMusUgo+ya+Bc/4H+szoxTndXaaamz CPkZMuzga8kEApXgMvImGfsqB8FqqFNtEELlRmISEHb04iAGqUv6HwoL1DhqEZ3I tQQi73JvuCU3Lfbp4CDI0IeTzlAoARBX/mWFjlDm7CA8clu4PzIVhdsRxRUhXIId ijI8432al9XXt0m4+4LIKmJa6DlyvQ3pIZDFodryQ1za3PAaF7IheILFKPi9BAwi Tn47X2+2XYXx7ZS2S22R7KRgeORZqj2uYZifs/xsNwkBCsyntYZgH+c5qYU7TWb/ tWRi9c5uVFskoPx4JL4W3ctgPvN7TpvKeCBLZTBdLQjy9WT6sqhxChxS57SFT5AH kTOWNEA0PqWjrrqRlNO47TL/aTg3Js9S4KxIZ2+hHSkDAlMxGi9rHzyHYPQKxJ1V lLmLGN0ZRYGGKa4Yn2OBAy16q/I2jkLE0Nkb0u1V3EEMkKQWp6pcro/Kb9Hrirfe n6zrFVyzLTIgNpr9C1+By1CxAmJfg73cIoobJSjNDZ2+EpY+FRDdhKYip3xtpNfA QFmabonocmaEohNcC8me =mSYS -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/i386
TB --- 2013-12-17 19:30:17 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-17 19:30:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-17 19:30:17 - starting HEAD tinderbox run for i386/i386 TB --- 2013-12-17 19:30:17 - cleaning the object tree TB --- 2013-12-17 19:36:18 - /usr/local/bin/svn stat /src TB --- 2013-12-17 19:36:22 - At svn revision 259524 TB --- 2013-12-17 19:36:23 - building world TB --- 2013-12-17 19:36:23 - CROSS_BUILD_TESTING=YES TB --- 2013-12-17 19:36:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-17 19:36:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-17 19:36:23 - SRCCONF=/dev/null TB --- 2013-12-17 19:36:23 - TARGET=i386 TB --- 2013-12-17 19:36:23 - TARGET_ARCH=i386 TB --- 2013-12-17 19:36:23 - TZ=UTC TB --- 2013-12-17 19:36:23 - __MAKE_CONF=/dev/null TB --- 2013-12-17 19:36:23 - cd /src TB --- 2013-12-17 19:36:23 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Dec 17 19:36:30 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Tue Dec 17 22:46:54 UTC 2013 TB --- 2013-12-17 22:46:54 - generating LINT kernel config TB --- 2013-12-17 22:46:54 - cd /src/sys/i386/conf TB --- 2013-12-17 22:46:54 - /usr/bin/make -B LINT TB --- 2013-12-17 22:46:54 - cd /src/sys/i386/conf TB --- 2013-12-17 22:46:54 - /usr/sbin/config -m LINT TB --- 2013-12-17 22:46:54 - building LINT kernel TB --- 2013-12-17 22:46:54 - CROSS_BUILD_TESTING=YES TB --- 2013-12-17 22:46:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-17 22:46:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-17 22:46:54 - SRCCONF=/dev/null TB --- 2013-12-17 22:46:54 - TARGET=i386 TB --- 2013-12-17 22:46:54 - TARGET_ARCH=i386 TB --- 2013-12-17 22:46:54 - TZ=UTC TB --- 2013-12-17 22:46:54 - __MAKE_CONF=/dev/null TB --- 2013-12-17 22:46:54 - cd /src TB --- 2013-12-17 22:46:54 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Dec 17 22:46:54 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Tue Dec 17 23:24:16 UTC 2013 TB --- 2013-12-17 23:24:16 - cd /src/sys/i386/conf TB --- 2013-12-17 23:24:16 - /usr/sbin/config -m LINT-NOINET TB --- 2013-12-17 23:24:17 - building LINT-NOINET kernel TB --- 2013-12-17 23:24:17 - CROSS_BUILD_TESTING=YES TB --- 2013-12-17 23:24:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-17 23:24:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-17 23:24:17 - SRCCONF=/dev/null TB --- 2013-12-17 23:24:17 - TARGET=i386 TB --- 2013-12-17 23:24:17 - TARGET_ARCH=i386 TB --- 2013-12-17 23:24:17 - TZ=UTC TB --- 2013-12-17 23:24:17 - __MAKE_CONF=/dev/null TB --- 2013-12-17 23:24:17 - cd /src TB --- 2013-12-17 23:24:17 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Tue Dec 17 23:24:17 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Tue Dec 17 23:56:28 UTC 2013 TB --- 2013-12-17 23:56:28 - cd /src/sys/i386/conf TB --- 2013-12-17 23:56:28 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-12-17 23:56:28 - building LINT-NOINET6 kernel TB --- 2013-12-17 23:56:28 - CROSS_BUILD_TESTING=YES TB --- 2013-12-17 23:56:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-17 23:56:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-17 23:56:28 - SRCCONF=/dev/null TB --- 2013-12-17 23:56:28 - TARGET=i386 TB --- 2013-12-17 23:56:28 - TARGET_ARCH=i386 TB --- 2013-12-17 23:56:28 - TZ=UTC TB --- 2013-12-17 23:56:28 - __MAKE_CONF=/dev/null TB --- 2013-12-17 23:56:28 - cd /src TB --- 2013-12-17 23:56:28 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Tue Dec 17 23:56:28 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Wed Dec 18 00:29:05 UTC 2013 TB --- 2013-12-18 00:29:05 - cd /src/sys/i386/conf TB --- 2013-12-18 00:29:05 - /usr/sbin/config -m LINT-NOIP TB --- 2013-12-18 00:29:05 - building LINT-NOIP kernel TB --- 2013-12-18 00:29:05 - CROSS_BUILD_TESTING=YES TB --- 2013-12-18 00:29:05 - MAKEOBJDIRPREFIX=/obj
Re: [HEADS UP] enabling LLDB debugger by default on amd64
On 17 December 2013 17:21, Navdeep Parhar n...@freebsd.org wrote: Any plans to get kernel debugging working? It's on the roadmap, but no concrete plans or timeline yet. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on amd64/amd64
TB --- 2013-12-17 19:30:17 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-17 19:30:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-17 19:30:17 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-12-17 19:30:17 - cleaning the object tree TB --- 2013-12-17 19:36:32 - /usr/local/bin/svn stat /src TB --- 2013-12-17 19:36:36 - At svn revision 259524 TB --- 2013-12-17 19:36:37 - building world TB --- 2013-12-17 19:36:37 - CROSS_BUILD_TESTING=YES TB --- 2013-12-17 19:36:37 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-17 19:36:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-17 19:36:37 - SRCCONF=/dev/null TB --- 2013-12-17 19:36:37 - TARGET=amd64 TB --- 2013-12-17 19:36:37 - TARGET_ARCH=amd64 TB --- 2013-12-17 19:36:37 - TZ=UTC TB --- 2013-12-17 19:36:37 - __MAKE_CONF=/dev/null TB --- 2013-12-17 19:36:37 - cd /src TB --- 2013-12-17 19:36:37 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Dec 17 19:36:43 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Tue Dec 17 23:21:51 UTC 2013 TB --- 2013-12-17 23:21:51 - generating LINT kernel config TB --- 2013-12-17 23:21:51 - cd /src/sys/amd64/conf TB --- 2013-12-17 23:21:51 - /usr/bin/make -B LINT TB --- 2013-12-17 23:21:51 - cd /src/sys/amd64/conf TB --- 2013-12-17 23:21:51 - /usr/sbin/config -m LINT TB --- 2013-12-17 23:21:51 - building LINT kernel TB --- 2013-12-17 23:21:51 - CROSS_BUILD_TESTING=YES TB --- 2013-12-17 23:21:51 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-17 23:21:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-17 23:21:51 - SRCCONF=/dev/null TB --- 2013-12-17 23:21:51 - TARGET=amd64 TB --- 2013-12-17 23:21:51 - TARGET_ARCH=amd64 TB --- 2013-12-17 23:21:51 - TZ=UTC TB --- 2013-12-17 23:21:51 - __MAKE_CONF=/dev/null TB --- 2013-12-17 23:21:51 - cd /src TB --- 2013-12-17 23:21:51 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Dec 17 23:21:51 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Tue Dec 17 23:56:00 UTC 2013 TB --- 2013-12-17 23:56:00 - cd /src/sys/amd64/conf TB --- 2013-12-17 23:56:00 - /usr/sbin/config -m LINT-NOINET TB --- 2013-12-17 23:56:00 - building LINT-NOINET kernel TB --- 2013-12-17 23:56:00 - CROSS_BUILD_TESTING=YES TB --- 2013-12-17 23:56:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-17 23:56:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-17 23:56:00 - SRCCONF=/dev/null TB --- 2013-12-17 23:56:00 - TARGET=amd64 TB --- 2013-12-17 23:56:00 - TARGET_ARCH=amd64 TB --- 2013-12-17 23:56:00 - TZ=UTC TB --- 2013-12-17 23:56:00 - __MAKE_CONF=/dev/null TB --- 2013-12-17 23:56:00 - cd /src TB --- 2013-12-17 23:56:00 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Tue Dec 17 23:56:00 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Wed Dec 18 00:27:30 UTC 2013 TB --- 2013-12-18 00:27:30 - cd /src/sys/amd64/conf TB --- 2013-12-18 00:27:30 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-12-18 00:27:30 - building LINT-NOINET6 kernel TB --- 2013-12-18 00:27:30 - CROSS_BUILD_TESTING=YES TB --- 2013-12-18 00:27:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-18 00:27:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-18 00:27:30 - SRCCONF=/dev/null TB --- 2013-12-18 00:27:30 - TARGET=amd64 TB --- 2013-12-18 00:27:30 - TARGET_ARCH=amd64 TB --- 2013-12-18 00:27:30 - TZ=UTC TB --- 2013-12-18 00:27:30 - __MAKE_CONF=/dev/null TB --- 2013-12-18 00:27:30 - cd /src TB --- 2013-12-18 00:27:30 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Wed Dec 18 00:27:30 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Wed Dec 18 00:59:00 UTC 2013 TB --- 2013-12-18 00:59:00 - cd /src/sys/amd64/conf TB --- 2013-12-18 00:59:00 - /usr/sbin/config -m LINT-NOIP TB --- 2013-12-18 00:59:00 - building LINT-NOIP kernel TB --- 2013-12-18 00:59:00 -
Re: 10-RC2 current wireless link aggregation not working correctly
Hi, On Tue, 17 Dec 2013 17:02:03 -0800 Xin Li delp...@delphij.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/17/13 09:34, Allan Jude wrote: If I am am understanding correctly, Dan and Nikolai say that just running 'ifconfig' brings the lagg back to life. Why would that make a difference at all? Running ifconfig with no parameters shouldn't be changing anything. I don't really believe these claim. it does not work with iwn and em. I had similar issue in the past and found an 'arp -a -d' would fix It also does not work. The machine is running FreeBSD 10.0 RC2. Erich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-RC unable to build kernel without INET (i.e. IPv6-only)
Mark, On Tue, Dec 17, 2013 at 08:13:20PM +0100, Mark Martinec wrote: M Under 9.2 the following could be used to build an IPv6-only kernel: M M /sys/amd64/conf/TEST : M M include GENERIC M makeoptions MKMODULESENV+=WITHOUT_INET_SUPPORT= M nooptions INET M M M Now with stable/10 the: M M make buildkernel KERNCONF=TEST Just fixed that in stable/10. I expect we will merge the patch to release branch as well. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 11.0-CURRENT panic at (allegedly) a dpms signal (monitor off), in drm2
2013/12/17 Jean-Sébastien Pédron jean-sebastien.ped...@dumbbell.fr: On 17.12.2013 13:19, Markiyan Kushnir wrote: Left my desktop (new Xorg, newcons, radeonkms) for a couple of minutes and found it rebooted after a panic. Never seen this kind of panic before. That's weird: the code leading to this panic in unreachable, because there's no way currently (that I know of) to change the power management method of the driver to dynamic. Can you reproduce the problem? If it helps, you can force your monitor off using xset(1): xset dpms force off No, I cannot reproduce it reliably. I've tried switching the monitor off for a while using xset, no luck. I will let you know once I have more info on it. -- Markiyan. -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
Jean-Sébastien Pédron wrote, On 12/17/2013 22:20: On 16.12.2013 08:36, d...@gmx.com wrote: Still nobody wants to apply Robert Noland's DRM patch? What problem(s) does this patch fix? It fixes non-deterministic lockups when the (old, drm1) r300 drivers are used. According to John Baldwin [1]: The drm code is doing a copyin() while holding a mutex (which is not allowed). The latest version of the patch (also the one I used for years) is at [2], linked from [3]. [1] http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005988.html [2] http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch [3] http://lists.freebsd.org/pipermail/freebsd-current/2009-April/006080.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-RC2 current wireless link aggregation not working correctly
What claims you do not believe ? Not important anyway. This is engineering, so you need not believe, you need to know. Go and replicate the bug. You will know then. I don't really believe these claim. I had similar issue in the past and found an 'arp -a -d' would fix it so I didn't pursued further but I think this would be an interesting problem to get addressed. If I would take an guess, I would start from making lagg(4) interface to initiate one or a few gratuitous ARP broadcast when the active port changes. Some switches could use this to kick out their (outdated) memory of where the port is. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJSsPQLAAoJEJW2GBstM+nsyXoP/RCeHdu1PVCooIUxzjhqWMJG 3RyN9i85O1WYpgZwHCSC9mkFKM6GjEIiyaNKCvdYzN/k+d9aCQSXIShgIGutM6ie hFD4GCGrevjquHCddpULlUE+iwj0qIJWSyRMusUgo+ya+Bc/4H+szoxTndXaaamz CPkZMuzga8kEApXgMvImGfsqB8FqqFNtEELlRmISEHb04iAGqUv6HwoL1DhqEZ3I tQQi73JvuCU3Lfbp4CDI0IeTzlAoARBX/mWFjlDm7CA8clu4PzIVhdsRxRUhXIId ijI8432al9XXt0m4+4LIKmJa6DlyvQ3pIZDFodryQ1za3PAaF7IheILFKPi9BAwi Tn47X2+2XYXx7ZS2S22R7KRgeORZqj2uYZifs/xsNwkBCsyntYZgH+c5qYU7TWb/ tWRi9c5uVFskoPx4JL4W3ctgPvN7TpvKeCBLZTBdLQjy9WT6sqhxChxS57SFT5AH kTOWNEA0PqWjrrqRlNO47TL/aTg3Js9S4KxIZ2+hHSkDAlMxGi9rHzyHYPQKxJ1V lLmLGN0ZRYGGKa4Yn2OBAy16q/I2jkLE0Nkb0u1V3EEMkKQWp6pcro/Kb9Hrirfe n6zrFVyzLTIgNpr9C1+By1CxAmJfg73cIoobJSjNDZ2+EpY+FRDdhKYip3xtpNfA QFmabonocmaEohNcC8me =mSYS -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-RC2 current wireless link aggregation not working correctly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/17/13, 11:28 PM, dan_partelly wrote: What claims you do not believe ? Not important anyway. This is engineering, so you need not believe, you need to know. Go and replicate the bug. You will know then. I don't believe in merely doing 'ifconfig' would workaround the issue, it does not make sense, plus I have tested and it didn't work for my case (iwn+em on my laptop). I'm aware of the issue but thought it was compatibility issue with my own weirdly setup wireless AP at the time, and looks like it's not just me, but I'm not interested nor have time to fix the problem so I replied the thread and offered what I have tested as a workaround in the hope that it's useful for someone who is interested and have the ability to fix the problem. Cheers, -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJSsVEkAAoJEJW2GBstM+nswTsP/Rs0hdyXNejf2Z98GbSGns0n lsI+UmjwWUSg0h+8QzCce7/80mwEw0tZH1btoRr6I0tPKXwdUYDO2C3LPM2a/jSV hvN6aay0ppnldtsqMZcuDv1OznSGfEIt0A04/m/RUTDBYaPKY+F1iqZYNE960zes u6mbR2elpAUCHjpV3lEchnP5V1v/yLpVziGYabR4WLwohtlOMGVbL92ejLAeKVnr Ar7SiWA7GVar6lSGBWyyGwoErveb8TaZxRiSKgjHuvciMLgy+KrlyxqZq6gNd7nP isBDMEe2NsnUawR/gfcxvvzpyHTPYPtSlEJjejdbnGlP4YGy5BT2vm3HqyAgK/iX N1iRBhx8zuH9UDNN8XiSuvuYuxAw9OfeBoh/2aGifj5dcrEP+IeyYUoAWBoXgny+ IcoitmUwYE4xLduLnIpf2b5KG8Yw1r2bKoZJVOw8+ixJAqCWR0xXONcywB56MXoE 8r9A11D6ASdRmozKjcEQH9+j6/4VuVeydCBfXQSZHIlVL3pTFZAlH0Q0JSZq4NXA Pb5YGcdYDONi3gPxNIvUn1WeqTfpgJhGveKV5PhI3NY2d+GEB3fBBuBhvlAlrwxg CPCqH4YC0sntvqMqcOooz44OfiLpB1ARGGTwtKATLNIzpS/iMsS1swW1NZEeaN19 uFZw/dY3w5uhDQ7u2Buc =4ByJ -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-RC2 current wireless link aggregation not working correctly
I guarantee you that a simple interface list with ifconfig un-stucks the net on my setup, at lest in the case (master is wired, unplug ethernet, fail to wireless) I agree that it doesn't makes much sense, but no matter how unlikely it seems, it is a **fact**. I don't believe in merely doing 'ifconfig' would workaround the issue, it does not make sense, plus I have tested and it didn't work for my case (iwn+em on my laptop). I'm aware of the issue but thought it was compatibility issue with my own weirdly setup wireless AP at the time, and looks like it's not just me, but I'm not interested nor have time to fix the problem so I replied the thread and offered what I have tested as a workaround in the hope that it's useful for someone who is interested and have the ability to fix the problem. Cheers, -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJSsVEkAAoJEJW2GBstM+nswTsP/Rs0hdyXNejf2Z98GbSGns0n lsI+UmjwWUSg0h+8QzCce7/80mwEw0tZH1btoRr6I0tPKXwdUYDO2C3LPM2a/jSV hvN6aay0ppnldtsqMZcuDv1OznSGfEIt0A04/m/RUTDBYaPKY+F1iqZYNE960zes u6mbR2elpAUCHjpV3lEchnP5V1v/yLpVziGYabR4WLwohtlOMGVbL92ejLAeKVnr Ar7SiWA7GVar6lSGBWyyGwoErveb8TaZxRiSKgjHuvciMLgy+KrlyxqZq6gNd7nP isBDMEe2NsnUawR/gfcxvvzpyHTPYPtSlEJjejdbnGlP4YGy5BT2vm3HqyAgK/iX N1iRBhx8zuH9UDNN8XiSuvuYuxAw9OfeBoh/2aGifj5dcrEP+IeyYUoAWBoXgny+ IcoitmUwYE4xLduLnIpf2b5KG8Yw1r2bKoZJVOw8+ixJAqCWR0xXONcywB56MXoE 8r9A11D6ASdRmozKjcEQH9+j6/4VuVeydCBfXQSZHIlVL3pTFZAlH0Q0JSZq4NXA Pb5YGcdYDONi3gPxNIvUn1WeqTfpgJhGveKV5PhI3NY2d+GEB3fBBuBhvlAlrwxg CPCqH4YC0sntvqMqcOooz44OfiLpB1ARGGTwtKATLNIzpS/iMsS1swW1NZEeaN19 uFZw/dY3w5uhDQ7u2Buc =4ByJ -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
