Re: panic on sparc64 running 10-beta4
On 12/27/13 1:42 PM, Marius Strobl wrote: On Sun, Dec 08, 2013 at 02:50:23PM +0100, Marius Strobl wrote: On Wed, Dec 04, 2013 at 11:01:30AM -0500, Kurt Lidl wrote: I installed a sparc V120 (4GB memory, dual 72GB disks) with the 10-beta4 install image today. Installation went fine. I rebooted the machine, and then went to get a fresh ports tree, and the machine panic'd: root@host:/usr/ports # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. Fetching public key from your-org.portsnap.freebsd.org... done. Fetching snapshot tag from your-org.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Tue Dec 3 19:06:18 EST 2013: 43b6803c6d94efd5b2e2bc9df0b66a84b75417fa3c1728100% of 69 MB 3225 kBps 00m22s Extracting snapshot... done. Verifying snapshot integrity... panic: trap: illegal instruction (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc08836d4 at trap+0x554 Uptime: 6m59s Dumping 4096 MB (4 chunks) chunk at 0: 1073741824 bytes ... ok chunk at 0x4000: 1073741824 bytes ... ok chunk at 0x8000: 1073741824 bytes ... ok chunk at 0xc000: 1073741824 bytes ... ok Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... And then it panic'd again when attempting to run 'savecore'! (I typed a after it printed out the line about writing the core file, that's where the "load: 0.72 ..." line came from...) Hrm, I don't seem to be able to reproduce this with an installation built from sources and also can't remember a commit between BETA3 and BETA4 which should be able to cause this. I currently can't test the 10-BETA4 install image, though. Was the machine in question running FreeBSD before, i. e. is it known good hardware? Did savecore eventually succeed on writing out a dump? Yes, this machine was successfully running 9/stable before this. Yes, I did ultimately get a successful savecore to run. The trick seems to be not to use ctrl-t to check the status of the machine. I loaded the RC1 build too, and restrained myself to not check via ctrl-t during the installation and unpacking of the OS, and again when doing a "portsnap fetch && portsnap unpack". I think the problem hinges on ctrl-t corrupting something that causes the panic soon thereafter. FYI, I tried again with a machine installed from the 10.0-RC3 binary image and couldn't reproduce that problem either. I just tried it again with a freshly fetched and burned RC3 image, and was able to get it to panic while verifying the snapshot. My comments are in [square brackets]. root@dna:~ # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. Fetching public key from your-org.portsnap.freebsd.org... done. Fetching snapshot tag from your-org.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Thu Dec 26 19:11:40 EST 2013: [ I did several ctrl-t operations during the fetch, no problem ] Extracting snapshot... [ctrl-t] load: 0.55 cmd: bsdtar 1355 [runnable] 6.33r 1.39u 3.78s 37% 5384k In: 11851934 bytes, compression 23%; Out: 5320 files, 15471104 bytes Current: snap/3d543fc157d97d1617eeb20832bf2cb37d04aeb2bf068bd0a07533e5b67c02fe.gz (1152 bytes) [ctrl-t] load: 0.83 cmd: bsdtar 1355 [runnable] 11.43r 2.36u 6.55s 51% 5384k In: 19288110 bytes, compression 24%; Out: 9299 files, 25624576 bytes Current: snap/1856dcdc8799dd2b5a19d2d4720452bc77b4084088dd9ac5bd190da5ac211c4b.gz (101014 bytes) done. Verifying snapshot integrity... [ a bunch of rapid ctrl-t keystrokes ] load: 2.23 cmd: sha256 1370 [runnable] 0.49r 0.32u 0.00s 3% 2064k load: 2.21 cmd: sh 1539 [runnable] 0.04r 0.00u 0.00s 2% 0k load: 1.93 cmd: sha256 5705 [runnable] 0.02r 0.00u 0.00s 15% 1880k load: 1.93 cmd: sh 5715 [runnable] 0.03r 0.00u 0.00s 15% 3136k load: 1.93 cmd: gunzip 5728 [runnable] 0.01r 0.00u 0.00s 16% 1200k load: 1.93 cmd: gunzip 5737 [runnable] 0.02r 0.00u 0.01s 16% 2144k load: 1.93 cmd: sh 5749 [runnable] 0.00r 0.00u 0.00s 16% 3136k load: 1.93 cmd: sh 1391 [runnable] 68.71r 0.58u 5.18s 15% 3136k panic: trap: fast data access mmu miss (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc0883954 at trap+0x554 Uptime: 1h1m23s Dumping 4096 MB (4 chunks) chunk at 0: 1073741824 bytes ... ok chunk at 0x4000: 1073741824 bytes ... ok chunk at 0x8000: 1073741824 bytes ... ok chunk at 0xc000: 1073741824 bytes ... ok Dump complete Here's the backtrace from the recovered crashdump, 'core.txt.0': Unread portion of the kernel message buffer: panic: trap: fast data access mmu miss (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc0883954 at trap+0x554 Uptime: 1h1m23s Dumping 4096 MB (4 chunks) chunk at 0: 1073741824 bytes 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 /bo
Re: panic on sparc64 running 10-beta4
On Sun, Dec 08, 2013 at 02:50:23PM +0100, Marius Strobl wrote: > On Wed, Dec 04, 2013 at 11:01:30AM -0500, Kurt Lidl wrote: > > I installed a sparc V120 (4GB memory, dual 72GB disks) with the 10-beta4 > > install image today. > > > > Installation went fine. I rebooted the machine, and then went to get > > a fresh ports tree, and the machine panic'd: > > > > root@host:/usr/ports # portsnap fetch > > Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. > > Fetching public key from your-org.portsnap.freebsd.org... done. > > Fetching snapshot tag from your-org.portsnap.freebsd.org... done. > > Fetching snapshot metadata... done. > > Fetching snapshot generated at Tue Dec 3 19:06:18 EST 2013: > > 43b6803c6d94efd5b2e2bc9df0b66a84b75417fa3c1728100% of 69 MB 3225 kBps > > 00m22s > > Extracting snapshot... done. > > Verifying snapshot integrity... panic: trap: illegal instruction (kernel) > > cpuid = 0 > > KDB: stack backtrace: > > #0 0xc08836d4 at trap+0x554 > > Uptime: 6m59s > > Dumping 4096 MB (4 chunks) > >chunk at 0: 1073741824 bytes ... ok > >chunk at 0x4000: 1073741824 bytes ... ok > >chunk at 0x8000: 1073741824 bytes ... ok > >chunk at 0xc000: 1073741824 bytes ... ok > > > > Dump complete > > Automatic reboot in 15 seconds - press a key on the console to abort > > Rebooting... > > > > And then it panic'd again when attempting to run 'savecore'! > > (I typed a after it printed out the line about > > writing the core file, that's where the "load: 0.72 ..." line > > came from...) > > Hrm, I don't seem to be able to reproduce this with an installation > built from sources and also can't remember a commit between BETA3 and > BETA4 which should be able to cause this. I currently can't test the > 10-BETA4 install image, though. Was the machine in question running > FreeBSD before, i. e. is it known good hardware? Did savecore eventually > succeed on writing out a dump? > FYI, I tried again with a machine installed from the 10.0-RC3 binary image and couldn't reproduce that problem either. Marius ___ 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: panic on sparc64 running 10-beta4
On Wed, Dec 04, 2013 at 11:01:30AM -0500, Kurt Lidl wrote: > I installed a sparc V120 (4GB memory, dual 72GB disks) with the 10-beta4 > install image today. > > Installation went fine. I rebooted the machine, and then went to get > a fresh ports tree, and the machine panic'd: > > root@host:/usr/ports # portsnap fetch > Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. > Fetching public key from your-org.portsnap.freebsd.org... done. > Fetching snapshot tag from your-org.portsnap.freebsd.org... done. > Fetching snapshot metadata... done. > Fetching snapshot generated at Tue Dec 3 19:06:18 EST 2013: > 43b6803c6d94efd5b2e2bc9df0b66a84b75417fa3c1728100% of 69 MB 3225 kBps > 00m22s > Extracting snapshot... done. > Verifying snapshot integrity... panic: trap: illegal instruction (kernel) > cpuid = 0 > KDB: stack backtrace: > #0 0xc08836d4 at trap+0x554 > Uptime: 6m59s > Dumping 4096 MB (4 chunks) >chunk at 0: 1073741824 bytes ... ok >chunk at 0x4000: 1073741824 bytes ... ok >chunk at 0x8000: 1073741824 bytes ... ok >chunk at 0xc000: 1073741824 bytes ... ok > > Dump complete > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting... > > And then it panic'd again when attempting to run 'savecore'! > (I typed a after it printed out the line about > writing the core file, that's where the "load: 0.72 ..." line > came from...) Hrm, I don't seem to be able to reproduce this with an installation built from sources and also can't remember a commit between BETA3 and BETA4 which should be able to cause this. I currently can't test the 10-BETA4 install image, though. Was the machine in question running FreeBSD before, i. e. is it known good hardware? Did savecore eventually succeed on writing out a dump? Marius ___ 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"
panic on sparc64 running 10-beta4
I installed a sparc V120 (4GB memory, dual 72GB disks) with the 10-beta4 install image today. Installation went fine. I rebooted the machine, and then went to get a fresh ports tree, and the machine panic'd: root@host:/usr/ports # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. Fetching public key from your-org.portsnap.freebsd.org... done. Fetching snapshot tag from your-org.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Tue Dec 3 19:06:18 EST 2013: 43b6803c6d94efd5b2e2bc9df0b66a84b75417fa3c1728100% of 69 MB 3225 kBps 00m22s Extracting snapshot... done. Verifying snapshot integrity... panic: trap: illegal instruction (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc08836d4 at trap+0x554 Uptime: 6m59s Dumping 4096 MB (4 chunks) chunk at 0: 1073741824 bytes ... ok chunk at 0x4000: 1073741824 bytes ... ok chunk at 0x8000: 1073741824 bytes ... ok chunk at 0xc000: 1073741824 bytes ... ok Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... And then it panic'd again when attempting to run 'savecore'! (I typed a after it printed out the line about writing the core file, that's where the "load: 0.72 ..." line came from...) savecore: reboot after panic: trap: illegal instruction (kernel) Dec 4 10:49:45 host savecore: reboot after panic: trap: illegal instruction (kernel) savecore: writing core to /var/crash/vmcore.0 load: 0.72 cmd: savecore 906 [physrd] 13.66r 2.75u 2.31s 27% 3192k vmcore.0 6.5% panic: trap: fast data access mmu miss (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc08836d4 at trap+0x554 Uptime: 1m58s Dumping 4096 MB (4 chunks) chunk at 0: 1073741824 bytes ... ok chunk at 0x4000: 1073741824 bytes ... ok chunk at 0x8000: 1073741824 bytes ... ok chunk at 0xc000: 1073741824 bytes ... ok Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Something's rotten with the 10-beta4 binaries for sparc64. -Kurt ___ 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"
