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 ctrl-t 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
