amd64 webpage, 12GB memory? 64-bit or not? SMP or not?

[Jeremy C. Reed]

On Mon, 27 Mar 2006, Norberto Meijome wrote:

> > I don't know why it is funny. (Anyways with most cars, even without
> > access to engine, you can look on dash board and on fuel cap and see.)
> 
> Sure... now, how do you check the dashboard or fuel cap "REMOTELY" ? :)

That was my point. Anyways, thanks to Pav and Matthew, I used dmidecode 
(from ports) and mptable.

> (checking the fuel cap is like checking the labels on the server, or
> the model of the box ,etc).
> 
> > Rebooting with an SMP kernel seems like the slow way to find out. I
> > am just curious if there is some way without rebooting, maybe the
> > non-SMP kernel could detect and printf at boot time (for dmesg)
> > something like: "It appears this system is multiprocessor; using
> > 'options SMP' may be useful."
> 
> just in case it isn't obvious,i doubt this 'helpful' feature will be
> added... You can get the information via other means.

Such as from mptable or dmidecode. (Although it is a little unclear when 
you don't have any data to compare the results with.

> > Can you please point me to the webpage that says it is okay to boot
> > an amd64 kernel using a i386 (6.0-RELEASE in this case) userland? (I
> > will update userland after reboot.)

> hmm not sure you can actually do this. amd64 needs 64 bit userland
> too... maybe i'm wrong, but everything i've read on this points

Yes, it fails. init won't run.

> > Also can you point me to the documentation for cross-compiling amd64 
> > kernel and userland (on i386 host).
> 
> this is slightly different - you would need to install onto another
> disk and boot the other disk, then get rid of hte i386 disk (I think).

By the way, I found notes on this at http://edoofus.blogspot.com/.

> why not just pay 30 minutes of a technician on site and get them to
> chuck in the amd64 bit setup disc and do the rest remotely? (or get
> them to open the box and see how many cpus it has ;) )

That is an alternative. (And we did end up having someone local reinstall 
from an amd64 disk.) But even a 30 minute job could involve over a day to 
wait for scheduling or due to time differences.

Thank you for your kind email. I am not sure why some of the other emails 
were rude.

Off-topic but to respond to mails from this list:

Also, it is common for consultants/tech support to work remotely on 
systems that are owned by people who have no related skills or knowledge 
at all. I have many remote customers who have undocumented systems 
installed by admins that have been fired, layed off, or gone. Sometimes 
they do not even know the operating system or software they use.

In my case, the system was installed by a knowledgable network 
administrator who happened to install the common (and frequently 
available[1]) "i386" disk on a 64-bit system. He was new to FreeBSD, and 
since his system was "Intel" not "AMD" and since the CD booted and 
installed fine, it made sense to him. If possible, some output in dmesg 
that said something like "AMD64 should be used for this system" and "This 
system appears to have multiprocessors so consider using options SMP" 
could be useful for even a novice.

 Jeremy C. Reed

p.s. Thanks to FreeBSD Mall and others, I have handed out hundreds of 
"i386" disks at various events.