Hi,

I have an amd64 system running NetBSD 2.0. So far, I've found two bugs, 
one of which may or may not be amd64 specific.

The first bug is that the first stage bootloader waits until something 
happens with the keyboard before it proceeds. All of my colocated machines 
are non-x86 hardware, but most people go for the lowest common 
denominator, so I would guess that it could be a problem to have 
production machines which need a human and a keyboard present in order to 
reboot.

The second problem is that I had let my amd64 machine get a DHCP lease, 
then later gave it a different static IP on the same subnet. I started 
using it as an NFS server, and had three machines communicating fine with 
it. When I tried a fourth, I noticed that that machine could not 
communicate via IPv4 with the amd64 machine. I checked and double checked 
everything, but the only clue I could find was from errors in demsg:

arplookup: unable to enter address for 67.101.178.23@00:00:c5:43:3b:48 on sip0 (host is not on local network)
arplookup: unable to enter address for 67.101.178.23@00:00:c5:43:3b:48 on sip0 (host is not on local network)
arplookup: unable to enter address for 67.101.178.23@00:00:c5:43:3b:48 on sip0 (host is not on local network)

The machines could communicate via IPv6 just fine. I checked the netmasks, 
checked that both machines could communicate with all of the other 
machines, then finally realized that the amd64 machine might not be able 
to communicate with 67.101.178.23 because it used to have that address. 
Even though I did an ifconfig sip0 delete before reassigning an IP, the 
system still had some residual connection with that IP.

I rebooted, and now the two machines can communicate via IPv4 and IPv6 
just fine. This could be a bug with sip*, or with amd64 - not sure. I've 
not seen this on any other architecture or ethernet interface.

Just thought someone should know.

Thanks,
John Klos