Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On 7/2/15 11:00 AM, Glen Barber wrote: On Thu, Jul 02, 2015 at 10:52:00AM -0400, Kurt Lidl wrote: 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 I tried this, and it panic'd in the same manner. (Note - I've upgraded this machine to the second 10.2-PRELEASE build.) Okay, thank you for testing. The last commits that I see specifically referencing this bge(4) model were a long time ago, but TSO was mentioned. It was worth a shot. Sure, no problem. [...] I've also seen (now that it's been running a bit longer), a couple of other occurrences of the spin lock held too long panic. So while having the IPv6 configuration in /etc/rc.conf causes this crash to occur most of the time on boot, the same crash occurs at other times too, which don't appear to IPv6 related. Can you update the PR with this information, please? Already done by the time I sent the email. 1) when making the requested change, I editted my /etc/rc.conf file, and then issued reboot. The machine panic'd during the reboot processing: root@spork:~ # reboot Jul 2 09:48:53 spork reboot: rebooted by root Jul 2 09:48:53 spork syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 0 done All buffers synced. Uptime: 14h34m16s GEOM_MIRROR: Device gswap: provider mirror/gswap destroyed. GEOM_MIRROR: Device gswap destroyed. pid 1 (init), uid 0: exited on signal 4 spin lock 0xc0cba338 (smp rendezvous) held by 0xf8000bbbe920 (tid 100367) too long timeout stopping cpus panic: spin lock held too long cpuid = 1 KDB: stack backtrace: #0 0xc05757c0 at panic+0x20 #1 0xc0559250 at _mtx_lock_spin_failed+0x50 #2 0xc0559318 at _mtx_lock_spin_cookie+0xb8 #3 0xc08d801c at tick_get_timecount_mp+0xdc #4 0xc05840c8 at binuptime+0x48 #5 0xc08a400c at timercb+0x6c #6 0xc08d8380 at tick_intr+0x220 Uptime: 14h34m16s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... timeout stopping cpus timeout shutting down CPUs. SC Alert: Host System has Reset Note: the SC Alert: message comes the Sparc's ALOM management system, so that's from the hardware directly, not from FreeBSD's kernel. Hmm. Any chance this could be hardware (failure) related? Highly unlikely. First, both Chris and I both see this same error on our V240 machines. Also, I took the time this weekend to re-install from the 10.0-RELEASE media onto the other disks in this machine.[*] My V240 has 4x72GB drives, so I now have 10.0-RELEASE running on a ZFS mirror on disk0/disk1 and have the second 10.2-PRERELEASE bits installed onto a ZFS mirror on disk2/disk3. So I can boot into either of those environments pretty easily. When running 10.0-RELEASE, the hardware does not exhibit the spin lock held too long message. -Kurt [*] This turned out to be unexpected hard. I was able to boot from the 10.0-RELEASE cdrom, and create a ZFS mirror, and install to it, but when I rebooted, I got this error: Trying to mount root from zfs:sys/ROOT/default []... Mounting from zfs:sys/ROOT/default failed with error 45. It took me a while to figure out what was going on. In 10.0, the sparc ZFS support probed all the disk devices, looking for the disks in the boot zpool. In 10.2, it only probes the the devices configured in the eeprom's boot-device setting. I had installed the 10.2-ish bits into the zpool called sys, and when I reinstalled the 10.0 bits, I also put them into a zpool named sys. So I had two entirely different sys zpools, the first on disk0/disk1 and the second on disk2/disk3. The 10.2 code can handle this (since it only looked at disk2/disk3), and happily booted from disk2/disk3. The 10.0 code, on the other hand, examined all the disks, found devices that didn't match up, and gave up. I ultimately ended up reinstalling the 10.0-RELEASE software into a zpool named sys0. ___ 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 Thu, Jul 02, 2015 at 10:52:00AM -0400, Kurt Lidl wrote: 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 I tried this, and it panic'd in the same manner. (Note - I've upgraded this machine to the second 10.2-PRELEASE build.) Okay, thank you for testing. The last commits that I see specifically referencing this bge(4) model were a long time ago, but TSO was mentioned. It was worth a shot. [...] I've also seen (now that it's been running a bit longer), a couple of other occurrences of the spin lock held too long panic. So while having the IPv6 configuration in /etc/rc.conf causes this crash to occur most of the time on boot, the same crash occurs at other times too, which don't appear to IPv6 related. Can you update the PR with this information, please? 1) when making the requested change, I editted my /etc/rc.conf file, and then issued reboot. The machine panic'd during the reboot processing: root@spork:~ # reboot Jul 2 09:48:53 spork reboot: rebooted by root Jul 2 09:48:53 spork syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 0 done All buffers synced. Uptime: 14h34m16s GEOM_MIRROR: Device gswap: provider mirror/gswap destroyed. GEOM_MIRROR: Device gswap destroyed. pid 1 (init), uid 0: exited on signal 4 spin lock 0xc0cba338 (smp rendezvous) held by 0xf8000bbbe920 (tid 100367) too long timeout stopping cpus panic: spin lock held too long cpuid = 1 KDB: stack backtrace: #0 0xc05757c0 at panic+0x20 #1 0xc0559250 at _mtx_lock_spin_failed+0x50 #2 0xc0559318 at _mtx_lock_spin_cookie+0xb8 #3 0xc08d801c at tick_get_timecount_mp+0xdc #4 0xc05840c8 at binuptime+0x48 #5 0xc08a400c at timercb+0x6c #6 0xc08d8380 at tick_intr+0x220 Uptime: 14h34m16s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... timeout stopping cpus timeout shutting down CPUs. SC Alert: Host System has Reset Note: the SC Alert: message comes the Sparc's ALOM management system, so that's from the hardware directly, not from FreeBSD's kernel. Hmm. Any chance this could be hardware (failure) related? It didn't crashdump, so I don't have any other backtrace other than what I just copied here. 2) After I rebooted with the -tso flag in place and it crashed, I booted again, single user, so I could edit the /etc/rc.conf again and manually did a savecore: Okay, thank you for checking, in any case. Glen pgp6s3pfx16ZI.pgp Description: PGP signature
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On 7/1/15 7:41 PM, Glen Barber wrote: 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 I tried this, and it panic'd in the same manner. (Note - I've upgraded this machine to the second 10.2-PRELEASE build.) Writing entropy file:. Setting hostname: spork.pix.net. spin lock 0xc0cba338 (smp rendezvous) held by 0xf80003eb76d0 (tid 100339) too long timeout stopping cpus panic: spin lock held too long cpuid = 1 KDB: stack backtrace: #0 0xc05757c0 at panic+0x20 #1 0xc0559250 at _mtx_lock_spin_failed+0x50 #2 0xc0559318 at _mtx_lock_spin_cookie+0xb8 #3 0xc08d801c at tick_get_timecount_mp+0xdc #4 0xc05840c8 at binuptime+0x48 #5 0xc08a400c at timercb+0x6c #6 0xc08d8380 at tick_intr+0x220 Uptime: 23s Dumping 8192 MB (4 chunks) I've also seen (now that it's been running a bit longer), a couple of other occurrences of the spin lock held too long panic. So while having the IPv6 configuration in /etc/rc.conf causes this crash to occur most of the time on boot, the same crash occurs at other times too, which don't appear to IPv6 related. 1) when making the requested change, I editted my /etc/rc.conf file, and then issued reboot. The machine panic'd during the reboot processing: root@spork:~ # reboot Jul 2 09:48:53 spork reboot: rebooted by root Jul 2 09:48:53 spork syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 0 done All buffers synced. Uptime: 14h34m16s GEOM_MIRROR: Device gswap: provider mirror/gswap destroyed. GEOM_MIRROR: Device gswap destroyed. pid 1 (init), uid 0: exited on signal 4 spin lock 0xc0cba338 (smp rendezvous) held by 0xf8000bbbe920 (tid 100367) too long timeout stopping cpus panic: spin lock held too long cpuid = 1 KDB: stack backtrace: #0 0xc05757c0 at panic+0x20 #1 0xc0559250 at _mtx_lock_spin_failed+0x50 #2 0xc0559318 at _mtx_lock_spin_cookie+0xb8 #3 0xc08d801c at tick_get_timecount_mp+0xdc #4 0xc05840c8 at binuptime+0x48 #5 0xc08a400c at timercb+0x6c #6 0xc08d8380 at tick_intr+0x220 Uptime: 14h34m16s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... timeout stopping cpus timeout shutting down CPUs. SC Alert: Host System has Reset Note: the SC Alert: message comes the Sparc's ALOM management system, so that's from the hardware directly, not from FreeBSD's kernel. It didn't crashdump, so I don't have any other backtrace other than what I just copied here. 2) After I rebooted with the -tso flag in place and it crashed, I booted again, single user, so I could edit the /etc/rc.conf again and manually did a savecore: Trying to mount root from zfs:sys/ROOT/default []... Enter full pathname of shell or RETURN for /bin/sh: # mount -u / # zfs mount -a # savecore /var/crash savecore: reboot after panic: spin lock held too long savecore: writing core to /var/crash/vmcore.1 # vi /etc/rc.conf [edit session elided - I just commented out the IPv6 config] # exit Setting hostuuid: 912fab2a-2040-11e5-8852-0003bae0ce07. Setting hostid: 0x69fb7ee2. Entropy harvesting: interrupts ethernet point_to_point swi. Fast boot: skipping disk checks. Mounting local file systems:. Writing entropy file:. Setting hostname: spork.pix.net. spin lock 0xc0cba338 (smp rendezvous) held by 0xf8000d54e000 (tid 100357) too long timeout stopping cpus panic: spin lock held too long cpuid = 1 KDB: stack backtrace: #0 0xc05757c0 at panic+0x20 #1 0xc0559250 at _mtx_lock_spin_failed+0x50 #2 0xc0559318 at _mtx_lock_spin_cookie+0xb8 #3 0xc08d801c at tick_get_timecount_mp+0xdc #4 0xc05840c8 at binuptime+0x48 #5 0xc08a400c at timercb+0x6c #6 0xc08d8380 at tick_intr+0x220 Uptime: 5m57s Dumping 8192 MB (4 chunks)
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
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: 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
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
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On Tue, Jun 30, 2015 at 10:48:56PM -0400, Chris Ross wrote: On Jun 30, 2015, at 22:36 , Glen Barber g...@freebsd.org wrote: On Tue, Jun 30, 2015 at 10:27:21PM -0400, Chris Ross 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! When I was trying to search for a commit that caused the change of behavior, I had difficultly doing it, but it was well back in 2014. The boots sometimes makes this a hard one to track, but as I only have my production v240, also makes it one I haven't spent as much time trying to find as I'd like. Thank you for letting me know this issue isn't fixed, though, despite the other success with this code. :-) Hopefully your stacktrace can help figure out what is wrong. A quick search through the PR system returned zero results for this. Did you file a PR previously? (If not, do you know of one that already exists that Kurt can update?) The long thread I see in my emails are with subject FreeBSD 10-STABLE/sparc64 panic. May/June, and then later September and October, and I don't see anyone to have created a PR. I think I got confused and dismayed in June, from reading back, and then never got to trying hard again. The first report I see is from Kurt, http://lists.freebsd.org/pipermail/freebsd-sparc64/2014-March/009261.html, so well over a year ago. But, no mention in that thread about a PR either. Thank you for the reference. I think you may be right, Glen, that there isn't one, and that's on me as well as others. Hopefully, some of the searching through various revisions of 10/stable I documented in the FreeBSD 10-STABLE/sparc64 panic thread in May 2014 may help in the end, though. It's fine, it explains why I could not find one. Kurt, could you please create a PR and point me to the PR number so RE can put it on our watch list? Thanks. Glen Thanks. tl;dr; I don't know of an existing PR. - Chris 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
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On 6/30/15 8:16 PM, Glen Barber wrote: On Tue, Jun 30, 2015 at 08:14:07PM -0400, Kurt Lidl 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. The only other testing I did was to recompile a custom kernel, and that worked fine too. From the aspect of having a ZFS only configuration just work, this is by far the best that I've seen to date. Great to hear. Thank you for testing. 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
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
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! When I was trying to search for a commit that caused the change of behavior, I had difficultly doing it, but it was well back in 2014. The boots sometimes makes this a hard one to track, but as I only have my production v240, also makes it one I haven't spent as much time trying to find as I'd like. Thank you for letting me know this issue isn't fixed, though, despite the other success with this code. :-) Hopefully your stacktrace can help figure out what is wrong. - Chris 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
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On Jun 30, 2015, at 22:36 , Glen Barber g...@freebsd.org wrote: On Tue, Jun 30, 2015 at 10:27:21PM -0400, Chris Ross 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! When I was trying to search for a commit that caused the change of behavior, I had difficultly doing it, but it was well back in 2014. The boots sometimes makes this a hard one to track, but as I only have my production v240, also makes it one I haven't spent as much time trying to find as I'd like. Thank you for letting me know this issue isn't fixed, though, despite the other success with this code. :-) Hopefully your stacktrace can help figure out what is wrong. A quick search through the PR system returned zero results for this. Did you file a PR previously? (If not, do you know of one that already exists that Kurt can update?) The long thread I see in my emails are with subject FreeBSD 10-STABLE/sparc64 panic. May/June, and then later September and October, and I don't see anyone to have created a PR. I think I got confused and dismayed in June, from reading back, and then never got to trying hard again. The first report I see is from Kurt, http://lists.freebsd.org/pipermail/freebsd-sparc64/2014-March/009261.html, so well over a year ago. But, no mention in that thread about a PR either. I think you may be right, Glen, that there isn't one, and that's on me as well as others. Hopefully, some of the searching through various revisions of 10/stable I documented in the FreeBSD 10-STABLE/sparc64 panic thread in May 2014 may help in the end, though. Thanks. tl;dr; I don't know of an existing PR. - Chris 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
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
[-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. The only other testing I did was to recompile a custom kernel, and that worked fine too. From the aspect of having a ZFS only configuration just work, this is by far the best that I've seen to date. -Kurt dmesg follows: Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.2-PRERELEASE #1: Tue Jun 30 19:51:35 EDT 2015 r...@ton.pix.net:/usr/obj/usr/src/sys/V120 sparc64 gcc version 4.2.1 20070831 patched [FreeBSD] real memory = 4294967296 (4096 MB) avail memory = 4175503360 (3982 MB) cpu0: Sun Microsystems UltraSparc-IIe Processor (648.00 MHz CPU) WARNING: VIMAGE (virtualized network stack) is a highly experimental feature. random: Software, Yarrow initialized nexus0: Open Firmware Nexus device pcib0: U2P UPA-PCI bridge mem 0x1fe-0x1fe,0x1fe0100-0x1fe01ff irq 2032,2030,2031,2021 on nexus0 pcib0: Sabre, impl 0, version 0, IGN 0x1f, bus A, 66MHz pcib0: DVMA map: 0xc000 to 0xc3ff 8192 entries pcib0: [GIANT-LOCKED] pci0: OFW PCI bus on pcib0 pcib1: APB PCI-PCI bridge at device 1.1 on pci0 pci1: OFW PCI bus on pcib1 ebus0: PCI-EBus3 bridge mem 0xf000-0xf0ff,0xf100-0xf17f at device 12.0 on pci1 ebus0: idprom: incomplete pcib2: APB PCI-PCI bridge at device 1.0 on pci0 pci2: OFW PCI bus on pcib2 ebus0: flashprom addr 0x10-0x1f (no driver attached) eeprom0: EEPROM/clock addr 0x14-0x141fff on ebus0 eeprom0: model mk48t59 ebus0: SUNW,lomh addr 0x140020-0x140023 irq 42 (no driver attached) pci1: old, non-VGA display device at device 3.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci1 isa0: ISA bus on isab0 gem0: Sun ERI 10/100 Ethernet mem 0xe040-0xe041 at device 12.1 on pci1 miibus0: MII bus on gem0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow gem0: 2kB RX FIFO, 2kB TX FIFO gem0: Ethernet address: 00:03:ba:2f:fc:50 ohci0: Sun PCIO-2 USB controller mem 0xe200-0xe2007fff at device 12.3 on pci1 usbus0 on ohci0 atapci0: AcerLabs M5229 UDMA66 controller port 0x400-0x407,0x418-0x41b,0x410-0x417,0x408-0x40b,0x420-0x42f at device 13.0 on pci1 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance ata2: ATA channel at channel 0 on atapci0 ata3: ATA channel at channel 1 on atapci0 gem1: Sun ERI 10/100 Ethernet mem 0xe044-0xe045 at device 5.1 on pci1 miibus1: MII bus on gem1 ukphy1: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow gem1: 2kB RX FIFO, 2kB TX FIFO gem1: Ethernet address: 00:03:ba:2f:fc:51 ohci1: Sun PCIO-2 USB controller mem 0xe500-0xe5007fff at device 5.3 on pci1 usbus1 on ohci1 sym0: 896 port 0xc0-0xc000ff mem 0x2000-0x23ff,0x4000-0x5fff at device 8.0 on pci2 sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking sym1: 896 port 0xc00100-0xc001ff mem 0x6000-0x63ff,0x8000-0x9fff at device 8.1 on pci2 sym1: No NVRAM, ID 7, Fast-40, LVD, parity checking uart0: 16550 or compatible at port 0x3f8-0x3ff irq 43 on isa0 uart0: console (9600,n,8,1) uart1: 16550 or compatible at port 0x2e8-0x2ef irq 43 on isa0 usbus0: 12Mbps Full Speed USB v1.0 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounter tick frequency 64800 Hz quality 1000 Event timer tick frequency 64800 Hz quality 1000 Timecounters tick every 1.000 msec usbus1: 12Mbps Full Speed USB v1.0 ugen0.1: SUN at usbus0 uhub0: SUN OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ugen1.1: SUN at usbus1 uhub1: SUN OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1 uhub0: 4 ports with 4 removable, self powered uhub1: 4 ports with 4 removable, self powered random: unblocking device. da0 at sym0 bus 0 scbus2 target 0 lun 0 da0: FUJITSU MAT3073NC 0108 Fixed Direct Access SCSI-3 device da0: Serial Number AAL0P58055P6 da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) da0: Command Queueing enabled da0: 70136MB (143638992 512 byte sectors: 255H 63S/T 8941C) da1
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On Tue, Jun 30, 2015 at 08:14:07PM -0400, Kurt Lidl 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. The only other testing I did was to recompile a custom kernel, and that worked fine too. From the aspect of having a ZFS only configuration just work, this is by far the best that I've seen to date. Great to hear. Thank you for testing. Glen pgpyXuCt7xrYJ.pgp Description: PGP signature
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On Tue, Jun 30, 2015 at 10:14:19PM -0400, Kurt Lidl wrote: On 6/30/15 8:16 PM, Glen Barber wrote: On Tue, Jun 30, 2015 at 08:14:07PM -0400, Kurt Lidl 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. The only other testing I did was to recompile a custom kernel, and that worked fine too. From the aspect of having a ZFS only configuration just work, this is by far the best that I've seen to date. Great to hear. Thank you for testing. 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.) Can you please file a PR with this information? FWIW, updated builds are in-flight now, and should be available on FTP mirrors tomorrow. I'll CC -stable@ on the announcement email; will you be able to test the updated build? Glen 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,
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
On Tue, Jun 30, 2015 at 10:27:21PM -0400, Chris Ross 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! When I was trying to search for a commit that caused the change of behavior, I had difficultly doing it, but it was well back in 2014. The boots sometimes makes this a hard one to track, but as I only have my production v240, also makes it one I haven't spent as much time trying to find as I'd like. Thank you for letting me know this issue isn't fixed, though, despite the other success with this code. :-) Hopefully your stacktrace can help figure out what is wrong. A quick search through the PR system returned zero results for this. Did you file a PR previously? (If not, do you know of one that already exists that Kurt can update?) Glen - Chris 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
Re: New FreeBSD snapshots available: stable/10 (20150625 r284813)
Glen Barber g...@freebsd.org 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. ggatec and ggatel are still broken on i386: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197309 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199559 If the ZFS root pools isn't found right away, the system deadlocks: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198563 Patches are available so it would be great if these issues could be fixed before the release. Fabian pgpQ22L1TKtmV.pgp Description: OpenPGP digital signature
New FreeBSD snapshots available: stable/10 (20150625 r284813)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [-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. 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 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-7d3bc116 us-west-1 region: ami-cd8b7d89 us-west-2 region: ami-9b4f48ab sa-east-1 region: ami-271d9f3a eu-west-1 region: ami-0c6b2c7b eu-central-1 region: ami-424b705f ap-northeast-1 region: ami-626ecf62 ap-southeast-1 region: ami-80494fd2 ap-southeast-2 region: ami-9d4c09a7 == ISO CHECKSUMS == o 10.2-PRERELEASE amd64 GENERIC: SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150625-r284813-bootonly.iso) = b3cf2016a048b73ff720866cb8e8f83b842b5a4f64208c615b6ce2cdad503136 SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150625-r284813-bootonly.iso.xz) = ffd1cf3e1d653ad6a66fdb8f60b537a97639a74cf50d7b41eb56cdbf60b0d019 SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150625-r284813-disc1.iso) = c115e84308b2bf8ff807d6f9766e07cc5509785eb41d48bc9d6dd2cf8ae49e8a SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150625-r284813-disc1.iso.xz) = d2f7e39f1032c83fedd23995b4235eb37db9897f73a788ab2176e8c85bbceadb SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150625-r284813-memstick.img) = eb4924188ad1a841cd68e2007983cd4cd3912ef1b0e1caf86746cadf318a74ea SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150625-r284813-memstick.img.xz) = e10deeef2ef859293567b93617984e1055a44e34c1178d73f64185f04b988572 SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150625-r284813-mini-memstick.img) = 9e5da5814d80c7be4c26eebf90b02dcb908dd7106235d0993418a97c469b SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150625-r284813-mini-memstick.img.xz) = 2e5767f82e0cd375be29b91ddbcd9b2a8fd0d17c5aed22528a0e81e5e7dc7dd4 SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150625-r284813-uefi-bootonly.iso) = 0eee0b96deb9d961360f271d922a03f482b4275565b69a495323fb26cc510d2a SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150625-r284813-uefi-bootonly.iso.xz) = d42ac19bb256c26921d4dff325775efec589a2117399837923d99a4db584ef38 SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150625-r284813-uefi-disc1.iso) = 4cc4ab007fca2551bfa5906ff0cbbb1695e5e0ec7f8c3ddbced52b31f883d3fb SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150625-r284813-uefi-disc1.iso.xz) = c77e937571a61e5a55e330c18c30e2eeff1a49a7fc063b8ed80b658468036182 SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150625-r284813-uefi-memstick.img) = 79de1b81b7d4561af52d9ba29950d2852f719423c70d247a5a50d69cc9181db2 SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150625-r284813-uefi-memstick.img.xz) = 33844bb9ee77d4f73e1cd0817687423276ed43c6f761aed3361e42f80c975c8c SHA256 (FreeBSD-10.2-PRERELEASE-amd64-20150625-r284813-uefi-mini-memstick.img) =
