Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On Wed, Jul 01, 2015 at 11:34:17AM -0400, Kurt Lidl wrote: Of course, with no network connection, it's not a very useful machine, There are PCI slots on mine :-) ok, joking aside, this is indeed not useful. But it's useful to note that a couple of months ago, I was running my v245 hard, and it was working fine. I won't have time until this weekend to start firing things up and testing here, but I will try. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Freebsd-version problem
Hi, after today update to r284993, my /bin/freebsd-version is wrong. It contains both freebsd-version script and newvers.sh as if someone concatenated these two files into /bin/freebsd-version. Can anyone confirm or is it just me? BR, Marko pgpQQn3yVF4ld.pgp Description: PGP signature
Re: Freebsd-version problem
On Wed, Jul 1, 2015 at 8:55 PM, Marko Turk mark...@markoturk.info wrote:
Hi,
after today update to r284993, my /bin/freebsd-version is wrong. It
contains both freebsd-version script and newvers.sh as if someone
concatenated these two files into /bin/freebsd-version.
Can anyone confirm or is it just me?
BR,
Marko
Looks like this commit broke it:
https://svnweb.freebsd.org/base?view=revisionsortby=revsortdir=downrevision=284957
I think the problem is that ${.ALLSRC} expands now to both
${.CURDIR}/freebsd-version.sh.in and ${NEWVERS} where ${NEWVERS} is
the newvers.sh from sys/conf/.
-Kimmo
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On Jul 1, 2015, at 05:18 , Fabian Keil freebsd-lis...@fabiankeil.de wrote: Does it make a difference if you boot with hw.bge.allow_asf=0? According to the man page it is known to cause system lockup problems on a small number of systems. It's not obvious to me why it's enabled by default on FreeBSD and I disable it on all my systems. I'm not sure what it does, even. But, it doesn't seem to make a difference. The kernel I've been running (DDB version of r279722 from Mar 7 2015) panic's in the same way when that's set via the loader by hand, or put into loader.conf. Thanks for the suggestion. Sadly not related (causally). - Chris signature.asc Description: Message signed with OpenPGP using GPGMail
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
Chris Ross cross+free...@distal.com wrote: Yeah, this is the same panic you, I, and others have been seeing on sparc64's with bge's, or at least v240's (and one other IIRC) for many many months. Thanks for grabbing a core! Does it make a difference if you boot with hw.bge.allow_asf=0? According to the man page it is known to cause system lockup problems on a small number of systems. It's not obvious to me why it's enabled by default on FreeBSD and I disable it on all my systems. Fabian pgp9Wpk3XRKvH.pgp Description: OpenPGP digital signature
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On Wed, Jul 01, 2015 at 08:15:41AM -0400, Kurt Lidl wrote: On 6/30/15 10:54 PM, Glen Barber wrote: Kurt, could you please create a PR and point me to the PR number so RE can put it on our watch list? The PR is: 201245 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201245 I put the short version of the panic backtrace in the bug, and attached the full core.txt.0 file to the bug as well, as it contains the detailed backtrace. Thank you. Glen pgp4BihiuccYp.pgp Description: PGP signature
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On 6/30/15 10:54 PM, Glen Barber wrote: Kurt, could you please create a PR and point me to the PR number so RE can put it on our watch list? The PR is: 201245 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201245 I put the short version of the panic backtrace in the bug, and attached the full core.txt.0 file to the bug as well, as it contains the detailed backtrace. -Kurt On Jun 30, 2015, at 22:14 , Kurt Lidl l...@pix.net wrote: I got all excited and decided to give it a try on my dual-cpu V240 as well. I was able to get it installed, but it panics when booting off the mirrored ZFS drives. (Note: I have no reason to believe this is ZFS related.) snip, snip Setting hostname: spork.pix.net. bge0: link state changed to DOWN spin lock 0xc0cb9e38 (smp rendezvous) held by 0xf80003e93240 (tid 100340) too long timeout stopping cpus panic: spin lock held too long cpuid = 1 KDB: stack backtrace: #0 0xc0575380 at panic+0x20 #1 0xc0558e10 at _mtx_lock_spin_failed+0x50 #2 0xc0558ed8 at _mtx_lock_spin_cookie+0xb8 #3 0xc08d7b9c at tick_get_timecount_mp+0xdc #4 0xc0583c88 at binuptime+0x48 #5 0xc08a3b8c at timercb+0x6c #6 0xc08d7f00 at tick_intr+0x220 Uptime: 29s Dumping 8192 MB (4 chunks) chunk at 0: 2147483648 bytes ... ok chunk at 0x1: 2147483648 bytes ... ok chunk at 0x10: 2147483648 bytes ... ok chunk at 0x11: 2147483648 bytes ... ok Dump complete snip, snip Now the thing that amazes me is that this happened the first three times after I did the install, and on the fourth boot, it didn't panic. And it was able to 'savecore' the crashdump. Here's the stacktrace from the core.txt.0 file: -Kurt Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. Loaded symbols for /boot/kernel/geom_mirror.ko.symbols Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. Loaded symbols for /boot/kernel/tmpfs.ko.symbols #0 0xc05745bc in doadump (textdump=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:262 262 savectx(dumppcb); (kgdb) #0 0xc05745bc in doadump (textdump=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:262 #1 0xc0574fb0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #2 0xc0575358 in vpanic (fmt=0xc0b22fe0 spin lock held too long, ap=0x1fa2da638) at /usr/src/sys/kern/kern_shutdown.c:758 #3 0xc0575388 in panic (fmt=0xc0b22fe0 spin lock held too long) at /usr/src/sys/kern/kern_shutdown.c:687 #4 0xc0558e18 in _mtx_lock_spin_failed (m=0xc0cb9e38) at /usr/src/sys/kern/kern_mutex.c:561 #5 0xc0558ee0 in _mtx_lock_spin_cookie (c=0xf80003e93240, tid=18446735277669594832, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:608 #6 0xc08d7ba4 in tick_get_timecount_mp (tc=0xc0d13378) at smp.h:206 #7 0xc0583c90 in binuptime (bt=0x1fa2da980) at /usr/src/sys/kern/kern_tc.c:188 #8 0xc08a3b94 in timercb (et=0xc0d13308, arg=value optimized out) at time.h:418 #9 0xc08d7f08 in tick_intr (tf=0x1fa2dab20) at /usr/src/sys/sparc64/sparc64/tick.c:252 #10 0xc00a11bc in tl1_intr () #11 0xc08c934c in spinlock_exit () at /usr/src/sys/sparc64/sparc64/machdep.c:244 #12 0xc08c9330 in spinlock_exit () at /usr/src/sys/sparc64/sparc64/machdep.c:240 #13 0xc051a194 in cnputs (p=0x1fa2db11a ) at /usr/src/sys/kern/kern_cons.c:530 #14 0xc05c06e0 in putchar (c=10, arg=0x1fa2db0c8) at /usr/src/sys/kern/subr_prf.c:437 #15 0xc05bee90 in kvprintf (fmt=0xc0b2fb95 , func=0xc05c02e0 putchar, arg=0x1fa2db0c8, radix=10, ap=0x1fa2db300) at /usr/src/sys/kern/subr_prf.c:655 #16 0xc05bfe80 in _vprintf (level=5, flags=1, fmt=0xc0b2fb78 %s: link state changed to %s\n, ap=0x1fa2db2f0) at /usr/src/sys/kern/subr_prf.c:281 #17 0xc05c0270 in log (level=5, fmt=0xc0b2fb78 %s: link state changed to %s\n) at /usr/src/sys/kern/subr_prf.c:308 #18 0xc064ec28 in do_link_state_change (arg=0xf80003396800, pending=1) at /usr/src/sys/net/if.c:2131 #19 0xc05cab38 in taskqueue_run_locked (queue=0xf80003288000) at /usr/src/sys/kern/subr_taskqueue.c:342 #20 0xc05cacec in taskqueue_run (queue=0xf80003288000) at /usr/src/sys/kern/subr_taskqueue.c:358 #21 0xc05cae20 in taskqueue_swi_run (dummy=0x0) at /usr/src/sys/kern/subr_taskqueue.c:471 #22 0xc0539cc4 in intr_event_execute_handlers (p=0xf80003295860, ie=0xf80003287e00) at /usr/src/sys/kern/kern_intr.c:1264 #23 0xc053b86c in ithread_loop (arg=0xf8000324c080) at /usr/src/sys/kern/kern_intr.c:1277 #24 0xc0536428 in fork_exit (callout=0xc053b780 ithread_loop,
Re: pkg 1.5.0 is out
On 04/21/15 12:34, Slawa Olhovchenkov wrote: On Tue, Apr 14, 2015 at 10:05:00PM +0200, Baptiste Daroussin wrote: Hi all, Final pkg 1.5.0 has been released. Hi, Is there a way the external SAT solver functionality can be memory optimised? When trying to use this feature having +750 packages installed, the memory usage starts growing and growing beyond 4GBytes until PKG segfaults, even before the CNF export has started. env SAT_SOLVER=mysolver pkg upgrade --HPS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pkg 1.5.0 is out
On Wed, Jul 01, 2015 at 01:36:14PM +0200, Hans Petter Selasky wrote: On 04/21/15 12:34, Slawa Olhovchenkov wrote: On Tue, Apr 14, 2015 at 10:05:00PM +0200, Baptiste Daroussin wrote: Hi all, Final pkg 1.5.0 has been released. Hi, Is there a way the external SAT solver functionality can be memory optimised? When trying to use this feature having +750 packages installed, the memory usage starts growing and growing beyond 4GBytes until PKG segfaults, even before the CNF export has started. env SAT_SOLVER=mysolver pkg upgrade Probably, but given the little amount of time pkg developers has we will greatly appreciate patches :) AKA this would be greatly appreciated, but very low on the priority list :( Best regards, Bapt pgpBveW065vG4.pgp Description: PGP signature
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On Jul 1, 2015, at 11:34, Kurt Lidl l...@pix.net wrote: I discovered that if I comment out the following lines from my /etc/rc.conf, the machine boots reliably: ifconfig_bge0=DHCP ifconfig_bge0_ipv6=inet6 accept_rtadv Of course, with no network connection, it's not a very useful machine, but this probably is important to know while debugging the cause of the problem. I had realized that bringing the interface up was the trigger for the panic. An interesting thing, given the above, would be to note whether using a static IPv4 address (i.e., not DHCP or SYNCDHCP which is what I have), or whether disabling IPv6 or IPv6 accept_rtadv would make any difference. I’m guessing it won’t matter, but I also have a similar config in my rc.conf, so testing a wider variety of configs might be of value. - Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On 7/1/15 8:15 AM, Kurt Lidl wrote: On 6/30/15 10:54 PM, Glen Barber wrote: Kurt, could you please create a PR and point me to the PR number so RE can put it on our watch list? The PR is: 201245 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201245 I put the short version of the panic backtrace in the bug, and attached the full core.txt.0 file to the bug as well, as it contains the detailed backtrace. (I updated the bug with the following information too.) I discovered that if I comment out the following lines from my /etc/rc.conf, the machine boots reliably: ifconfig_bge0=DHCP ifconfig_bge0_ipv6=inet6 accept_rtadv Of course, with no network connection, it's not a very useful machine, but this probably is important to know while debugging the cause of the problem. -Kurt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On 7/1/15 11:52 AM, Chris Ross wrote: On Jul 1, 2015, at 11:34, Kurt Lidl l...@pix.net wrote: I discovered that if I comment out the following lines from my /etc/rc.conf, the machine boots reliably: ifconfig_bge0=DHCP ifconfig_bge0_ipv6=inet6 accept_rtadv Of course, with no network connection, it's not a very useful machine, but this probably is important to know while debugging the cause of the problem. I had realized that bringing the interface up was the trigger for the panic. An interesting thing, given the above, would be to note whether using a static IPv4 address (i.e., not DHCP or SYNCDHCP which is what I have), or whether disabling IPv6 or IPv6 accept_rtadv would make any difference. I’m guessing it won’t matter, but I also have a similar config in my rc.conf, so testing a wider variety of configs might be of value. To answer the question... If you take out the IPv6 configuration it doesn't panic! (I updated the bug with this information too.) -Kurt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Linux NFSv4 clients are getting (bad sequence-id error!)
Hi all, *warning*: Sorry I'm cross-posting this from freebsd-fs, things are too quite there unfortunately I'm a refugee from linux land. I just set up my first freebsd 10.1 zfs box, sharing /home over nfs. Since every home directory is its own zfs dataset, I chose to use nfsv4 to enable recursively sharing/mounting any directory under /home (I understand nfs4 is a must in this scenario!) I'm able to mount form linux (rhel5 latest kernel) successfully. Users are working fine. However every now and then a user screams that his session is frozen. Usually the processes are stuck in nfs_wait or rpc_* state. I tried using a much newer linux kernel (3.2 however it still faced the same problem). The errors in Linux log files are mostly: Jul 1 17:41:47 mammoth kernel: NFS: v4 server nas returned a *bad sequence-id error*! Jul 1 17:52:32 mammoth kernel: nfs4_reclaim_locks: unhandled error -11. Zeroing state Jul 1 17:52:32 mammoth kernel: nfs4_reclaim_open_state: Lock reclaim failed! My search led me to (https://access.redhat.com/solutions/1328073) a detailed analysis of the issue, which you can read over here https://dl.dropboxusercontent.com/u/51939288/nfs4-bad-seq.pdf .. NetApp confirmed this was a bug for them (I'm wondering if this is still in FreeBSD?!) PS: Right before sending this, I saw dmesg on the freebsd box advising increasing vfs.nfsd.tcphighwater .. So I up'ed that to 64000. I also up'ed the number of nfs server threads (-t) from 10 to 60 (we're roughly 40 linux machines) Any advice is most appreciated! Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
New FreeBSD snapshots available: stable/10 (20150630 r284970)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [-stable@ in CC again.] New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FTP mirrors. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. Please also consider installing the sysutils/panicmail port, which can help in providing FreeBSD developers the necessary information regarding system crashes. Checksums for the installation ISOs and the VM disk images follow at the end of this email. === Installation ISOs === Installation images are available for: o 10.2-PRERELEASE amd64 GENERIC o 10.2-PRERELEASE i386 GENERIC o 10.2-PRERELEASE ia64 GENERIC o 10.2-PRERELEASE powerpc GENERIC o 10.2-PRERELEASE powerpc64 GENERIC64 o 10.2-PRERELEASE sparc64 GENERIC o 10.2-PRERELEASE armv6 BEAGLEBONE o 10.2-PRERELEASE armv6 CUBOX-HUMMINGBOARD o 10.2-PRERELEASE armv6 GUMSTIX o 10.2-PRERELEASE armv6 RPI-B o 10.2-PRERELEASE armv6 PANDABOARD o 10.2-PRERELEASE armv6 WANDBOARD Note regarding the FreeBSD/armv6 images: Due to a build issue last week that caused md(4) devices to fail to be properly destroyed after use, the 'rootfs' UFS label and 'MSDOSBOOT' msdosfs labels do not exist on these images. This will be fixed for the next set of builds. Sorry the cause of this was not identified sooner. There are two workarounds for this: 1) After writing the image to the SD card, use tunefs(8) to write the UFS label to the correct partition. For example: # tunefs -L rootfs /dev/daNs2a Be sure to get the value of 'N' correct. 2) At the mountroot prompt, list all available partitions with '?', and run, for example: mountroot ufs:/dev/mmcsd0s2a In both cases, the system will enter single-user mode because the MSDOSBOOT label cannot be found. Commenting the /dev/msdos/MSDOSBOOT line from fstab(5) is sufficient to work around this problem. Snapshots may be downloaded from the corresponding architecture directory from: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Please be patient if your local FTP mirror has not yet caught up with the changes. Problems, bug reports, or regression reports should be reported through the Bugzilla PR system or the appropriate mailing list, such as -current@ or -stable@ . === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures: o 10.2-PRERELEASE amd64 o 10.2-PRERELEASE i386 Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/ Images are available in the following disk image formats: ~ RAW disk image ~ QCOW2 (qemu) ~ VMDK (qemu, VirtualBox, VMWare) ~ VHD (qemu, xen) 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) === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: us-east-1 region: ami-f315d498 us-west-1 region: ami-9105f4d5 us-west-2 region: ami-691b1d59 sa-east-1 region: ami-79bf3264 eu-west-1 region: ami-dabffead eu-central-1 region: ami-b0edd6ad ap-northeast-1 region: ami-2ea5072e ap-southeast-1 region: ami-261c1d74 ap-southeast-2 region: ami-3febae05 === Azure / VM Depot Images === FreeBSD/amd64 images are available for use within the Microsoft Azure hosting platform through VM Depot. For deployment instructions, see: https://vmdepot.msopentech.com/Vhd/Show?vhdId=56718 === Google Compute Engine Images === FreeBSD/amd64 images are available for use within the Google Compute Engine hosting platform. The image URLs are: https://console.developers.google.com/project/freebsd-org-cloud-dev/compute/imagesDetail/global/images/freebsd-10-2-prerelease-amd64-2015-07-01-13-44 == ISO CHECKSUMS == o 10.2-PRERELEASE amd64 GENERIC: SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150630-r284970-bootonly.iso) = 1dbf6ee160d25245f726def138d0b4bee561afdbf032766b697d19bc49288907 SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150630-r284970-bootonly.iso.xz) = 56b9a173eb0f0e96e2e84b209002b7b36f40dc807abe068b145ddab07dd6aba8 SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150630-r284970-disc1.iso) = 5a8ec1cc493f0cb76c5cd2be5ddd39c67abfa7530a280bca7a1e02e57274235c SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150630-r284970-disc1.iso.xz) = 6b85400880c62ae7e706436f6d4f345923eb3f454659ff66eefd19fa5e286d02 SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150630-r284970-memstick.img) = b363e9fb885c8eea90d8ab87f0aae4fe85d4419b03a68ad7d99183b445cde665 SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150630-r284970-memstick.img.xz) = 3fcf9fc789384946d315d342179409b69af393cafb25e949124e66781ba10d0d SHA256
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
Kurt Lidl l...@pix.net wrote: [-stable@ in CC since these are the first 10.2-PRERELEASE builds available since the code slush went into effect, which marks the start of the release cycle.] New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FTP mirrors. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. I was able to download the sparc64 iso image, burn the iso to a cd-rom, and boot a sparc64 V120 from that image. I was also able to perform an install onto a ZFS only setup, and have it work properly. On i386, the ZFS-only installation reproducible works after the first reboot but after the first reboot panics while importing the root pool. The problem seems to be that the GENERIC kernel is build with clang but KSTACK_PAGES has not been adjusted according to UPDATING: | 20121223: |After switching to Clang as the default compiler some users of ZFS |on i386 systems started to experience stack overflow kernel panics. |Please consider using 'options KSTACK_PAGES=4' in such configurations. If the issue can't be addressed before the release it may be worth mentioning it in the release notes. Fabian pgpC7ZdQNGlTL.pgp Description: OpenPGP digital signature
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On Wed, Jul 01, 2015 at 05:56:48PM -0400, Kurt Lidl wrote: On 7/1/15 11:52 AM, Chris Ross wrote: On Jul 1, 2015, at 11:34, Kurt Lidl l...@pix.net wrote: I discovered that if I comment out the following lines from my /etc/rc.conf, the machine boots reliably: ifconfig_bge0=DHCP ifconfig_bge0_ipv6=inet6 accept_rtadv Of course, with no network connection, it's not a very useful machine, but this probably is important to know while debugging the cause of the problem. I had realized that bringing the interface up was the trigger for the panic. An interesting thing, given the above, would be to note whether using a static IPv4 address (i.e., not DHCP or SYNCDHCP which is what I have), or whether disabling IPv6 or IPv6 accept_rtadv would make any difference. I’m guessing it won’t matter, but I also have a similar config in my rc.conf, so testing a wider variety of configs might be of value. To answer the question... If you take out the IPv6 configuration it doesn't panic! (I updated the bug with this information too.) Kurt, can you re-enable the ipv6 line in rc.conf(5), and add '-tso6' to your rc.conf(5) lines? ifconfig_bge0=DHCP ifconfig_bge0_ipv6=inet6 accept_rtadv -tso6 Glen pgpPMzw8bgEPh.pgp Description: PGP signature
