What I did so far:
I installed 4.5 in using the install45.iso CD with an AMD64 Version, with X and all packages and configured the network successfully (during installation).
I also tried to solve the hang up problem in using "boot -c" but my system hangs again with same error.

What I could imagine myself is that there could be a problem with acpi (had this with several older kernels in debian etch) with the same notebook.

Normally, one would used "boot -c" to disable ACPI prior to kernel probes; it looks like, for some reason, the kernel isn't even getting far enough to do that.

Some things to try, knowing none may work:

booting the MP kernel

disabling ACPI in /bsd and /bsd.mp kernel while running from the ramdisk kernel, then trying both again.

trying a recent snapshot.

To do #2, here are step-by-step instructions. Assuming wd0a is your root partition, and wd0d is your /usr partition. Adjust accordingly. The config program resides in /usr/sbin, and it uses dynamic libraries reside in /usr/lib and /usr/libexec. You'll engage the program via a chroot(8) shell, which will make the /mnt directory "/" until you exit.

I try to test your suggestions within the next hours/days, depends on how much of free time I got.
Further Information:
Sometimes (I cannot really tell u why), I can start with using "boot -c", but this doesn't happen very often.
I would say if it works, I will have to wait 10 seconds (not sure if this does really matter) and it will start boot -c (but it will hang up directly when I'm able to see "UKC>" where I normaly can disable acpi *not fine - hehe*).

If this works, the system will hangs up and does cold reboot.
Other times booting without giving any parameters to "boot", the system automatically reboot after:

Because the kernel isn't being loaded, the problem is probably not related to ACPI or APM.. but that also means it'll be hard to figure out why it's crashing like that.

My first impulse would be to check if the system has defective memory, via memtest86+ or similar.. my second would be to try using the i386 port of OpenBSD instead of amd64, you won't get the added benefits of a 64-bit operating system.. but you'll at least get a platform where you could offer developers access to try to find the cause of the hangup on amd64.

Very few developers hang out here, so you should really file a bug report and/or post on the mailing lists detailing what you've tried and the symptoms of the bug.. this is pretty much all the advice we can offer you at the moment.

But what's about apm? Isn't it true that acpi moves to apm? That means that I have to deactivate apm, or not?

The GENERIC kernels will test for the presence of APM, first. If the computer has APM, then apm(4) will be used, and acpi(4) will not be used. To force a computer that has both APM and APCI to use APCI, you must disable apm(4) in the kernel.

Quote:

Originally Posted by BSDfan666

Because the kernel isn't being loaded, the problem is probably not related to ACPI or APM..

The GENERIC kernels will test for the presence of APM, first. If the computer has APM, then apm(4) will be used, and acpi(4) will not be used. To force a computer that has both APM and APCI to use APCI, you must disable apm(4) in the kernel.

4.5 actually has some additional heuristics, the decision to use ACPI vs APM is a little more complex.

I used several servers for downloading the install45 files.
with 4.4 I had the same problem.

Yesterday I got a stack error message after some reboots. Very mysterious. Sometimes I can boot with -c sometimes not, sometimes I receive one line of output, sometimes it's a reboot and other times its a long stack and memory output with several assembly codes. Seems strange to me this bug.

Every other system works fine. I installed Vista, XP, later Debian (4.0) and since Lenny was released I used (5.0). No errors/hang ups at all.

I had a rather similar problem with Debian 4.0 in the past with a kernel 2.6.17 (hope I remember myself right) or smaller. Up to this kernel I had to use acpi=off noacpi to protect myself of hanging up/reboot the system.
With a newer Kernel, this problem went away.

Now with openBSD, it seems for me to look like the same problem, but I deactivated acpi in the kernel and also experimented due to your suggestions with the kernel conifgurations. Nothing changed. So I have to move on with my bug search.

Is it possible to use another kernel instead of the given ones that came with install45.img?