The following reply was made to PR port-amd64/32400; it has been noted by GNATS.

From: Quentin Garnier <cube@cubidou.net>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-amd64/32400: init loops getting signal 4 on Atlon X2 64
Date: Fri, 30 Dec 2005 23:54:30 +0100

 --XUmrTyVHrg2/ImRG
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Wed, Dec 28, 2005 at 11:55:00AM +0000, Bernhard Moellemann wrote:
 > >Number:         32400
 > >Category:       port-amd64
 > >Synopsis:       init loops getting signal 4 on Atlon X2 64 with amd64
 [...]
 > >Description:
 > This is a machine with an Athlon X2 64 on a NForce4 mainboard (kind of As=
 us
 > A8N). The machine runs with an i386 3.99.11 kernel. dmesg is at
 > http://circinus.de/multic-dmesg.txt
 >=20
 > I have installed the 3.99.15 amd64 bootloader (stage 1 and 2) and want use
 > an 3.99.15 amd64 kernel (conf is at http://circinus.de/MULTIC_ACPI.txt)
 > The kernel is ACPI and was crossbuild with the i386 environment. Without
 > ACPI it hangs during device detection, but this is not to be handled in
 > this PR.
 >=20
 > When booting this amd64 kernel the box runs through (most of?) the device
 > detection and then displays "Process (pid 1) got signal 4"
 > in an endless loop. The last message I _see_ is configuration of
 > wd0. But this takes some time and afterwardes the console and all buffers
 > are flushed with the above messeage. There may be a dozend of messages
 > in between wd0 and the loop. So the kernel may have approached (my i386)
 > userland. But the kernel has compat_netbsd32 and the amd64 port claims
 > it can run i386 binaries.
 >=20
 > Entering the kernel debugger is possible and ps shows that process 1 is
 > COMMAND "init" with FLAGS "0x44000" and the field "WAIT" is empty.
 
 I couldn't reproduce your issue.
 
 What I did is the following:  I downloaded the 20051226 NetBSD/i386
 snapshot, paxed it out on a partition, and booted a very fresh (as in
 -current of less than one hour ago) amd64 GENERIC kernel on that
 partition.
 
 It went as far as it could, which isn't much:
 
 boot device: wd1
 root on wd1g dumps on wd1b
 root file system type: ffs
 Fri Dec 30 22:36:23 UTC 2005
 swapctl: /dev/wd1b: Device not configured
 Checking for botched superblock upgrades: done.
 Starting file system checks:
 Can't open /dev/rwd1g: Device not configured
 CAN'T CHECK FILE SYSTEM.
 
 But at least I can manage to reboot cleanly.
 
 One thing should be noted, though:  I'm still using the bootblocks from
 the main installation, put there when I first got the machine up.
 
 (The reason why it says "Device not configured" when trying to access
 the devices is simple, and left as an exercise to the reader.  I'm kind
 of really not happy about it.)
 
 --=20
 Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
 "When I find the controls, I'll go where I like, I'll know where I want
 to be, but maybe for now I'll stay right here on a silent sea."
 KT Tunstall, Silent Sea, Eye to the Telescope, 2004.
 
 --XUmrTyVHrg2/ImRG
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.6 (NetBSD)
 
 iQEVAwUBQ7W6ptgoQloHrPnoAQL/tgf8CB3ovxVUSZAcyXgLgKyDvD2OO8NRIecF
 7XTwxoQ1H4MLllc0bWufa3iMCLtj2mNXMboNxpnXkRNFb2eNik166UxtD5TuA1Fq
 Z0g1ocYzDKoy2YfVLae4k+kXi8apsJL24+y3x0O18EkOejSRgIK2ipvwOtTS2bFm
 8G4dW1vini3hS3bmW1o7Ogorh01JPJG1pykdAuRpyLm+cvQ427aqyG5JiuJekq8L
 VgQZY9Xe8eZQ5jy/IFJdvrGbCDNBckyTtcXxd41kEWFrQ+m9R6GbInx40xvMlKCj
 LKEXtsqM6Bc1xY2or89P2LWtRiw9UfmHkeW9EW0psmvFdqdLLzZsBw==
 =eQ+W
 -----END PGP SIGNATURE-----
 
 --XUmrTyVHrg2/ImRG--