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 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 > > - 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
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 wrote: > On Tue, Dec 17, 2013 at 10:49 AM, Odhiambo Washington > 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 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 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 : > 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 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-NOI
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/confi
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 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 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 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 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 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 wrote: > On Tue, 17 Dec 2013 07:54:52 -0800, Adrian Chadd > 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 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 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 wrote: > I'm the wireless stack maintainer and I currently don't support that. > > Sorry. > > > > -a > > On 17 December 2013 08:10, dan_partelly wrote: >> On Tue, 17 Dec 2013 07:54:52 -0800, Adrian Chadd >> 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 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 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 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" 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" 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 wrote: > > > On Wednesday, December 11, 2013 5:40:30 pm Justin Hibbits wrote: > > > On Wed, Dec 11, 2013 at 1:26 PM, John Baldwin > > > 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 > >
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" > 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 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 ___ 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 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 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
___
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
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 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
> 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 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
___
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 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
___
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 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 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 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 https://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-NOI
Re: [HEADS UP] enabling LLDB debugger by default on amd64
On 17 December 2013 17:21, Navdeep Parhar 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/confi
Re: 10-RC2 current wireless link aggregation not working correctly
Hi, On Tue, 17 Dec 2013 17:02:03 -0800 Xin Li 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 : > 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 https://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"
