4.3 AMD64 failed on device probing.

[karl]

Hi all. 1st I'm sorry if this should be in OpenBSD General instead of here.

I've installed OpenBSD 4.3 (AMD64) dual-boot with XP. My pc is:

Athlon64 3500+
DFI LP rdx200
GECube Radeon HD2600 Pro PCIe
WD400 40Gb (30Gb xp - 10Gb OpenBSD)

XP got installed 1st, then OpenBSD. I'm currently using GAG4.9 as the boot manager. It's installed nicely. The problem is when it's booting.

While it was probing the devices, I notice that after something like:

"ATI EHCI root hub"

my LCD monitor went black and the pc restarted back to POST. I tried a few times already with the same result. Is there anywhere I can learn from? Thanks in advance!

btw, this is the 1st installation, I won't mind doing another installation if it helps.

[jggimi]

*Something* is going wrong. The most likely candidate is ACPI, as every hardware vendor's implementation is a little bit different, and none seem to follow the ACPI specification.

You could try disabling ACPI, before starting up the kernel:
At the boot> prompt, type: boot -c

At the first UKC> prompt, type: disable acpi
At the next UKC> prompt, type: quit
The kernel will boot without ACPI; it will use APM if available from your BIOS.

If the system comes up, you can make the change permanent:
# config -euf /bsd

Then type quit at the first UKC> prompt.

[karl]

Hi jggimi. Thanks fer the reply.

While I was waiting fer any answer here, I disabled "ehci" on the UKC (I just learned bout the UKC a while ago) and tried to boot with it. The matter got worst, my lcd went standby (the power LED turned orange) and the HDD LED blinks like mad. Hard reset & hard boot by pressing the power button won't work. I had to switch the plug off.

And just now I tried disabling acpi like you suggested with the same result. Had to switch off from the plug again. And when I booted to xp back, the "new device" *found* my Realtek Audio (weird because it was working flawlessly before, maybe this doesn't have anything to do with the problem, a mere coincidence but I'm adding it just fer information.).

[jggimi]

It's very hard to say what might be going on with the information provided so far.

-----------------------------

If this problem is related to hardware configuration, then knowning your particular make/model of hardware may be helpful -- sometimes problems are reported which discuss a specific computer, laptop, even motherboard.

--------------------------

One method for capturing information about what is happening during the reboot while the kernel probe is underway is to set up a serial console -- you may or may not be able to do this in your environment; FAQs 4.15 and 7.7 discuss serial console setup; 4.15 is specific to the boot process

Setting UKC> verbose can sometimes help determine which probe actually is failing. Typically, the kernel messages we see during normal boot appear after a successful probe completes. Setting kernel output to verbose may indicate which component is causing the problem .... and capturing that with a serial console may be necessary if it goes by too fast on screen.

[jggimi]

Ooops. Just noticed you did mention the mobo information in your first post. Looking for references to it now....

[jggimi]

No hits for rdx200 in the misc@ or tech@ mailing lists, nor in the PR database. Googling for openbsd and rdx200 only found your blog.

[karl]

Ok thanks fer the replies so far. I might as well post a question on misc@ later. In the mean time, I'll try and do more boot> testing (and verbose as you've said.). Although I'm pretty sure I don't have the resource (or knowledge) to do serial console thing.

It's early in the morning here and I just woke up.

[karl]

I was reading FAQ 4.15, about dmesg and I think it's the best way fer my case. But I'm not sure to execute the mount -t msdos.. command given in boot> prompt or what.

[jggimi]

Those commands are not given at the boot> prompt; they're given to a running Unix system. The boot> prompt is from the second stage boot loader, which loads and runs the kernels.

Some level setting:

When your hardware boots, the BIOS loads the Master Boot Record (MBR) from the disk drive and executes the software it finds there. A standard MBR program reads the MBR partition table, and loads and executes the Partition Boot Record (PBR) from the active partition.

This ends the first stage of booting.

If the active partition is OpenBSD, the PBR points to a file called /boot which contains the second stage boot loader. That is the program which produces the "boot>" prompt. This program allows you to select the kernel to load, among other things.

--------------

The commands you see in the first part of FAQ 4.15 are Unix shell commands to mount and write the OS's dmesg to MS-DOS diskette.

Your OS can't get that far. The kernel doesn't complete loading, and your PC reboots.

--------

IIRC, the amd64 bsd.rd (RAMDISK Kernel used for install/rescue) does not include FAT (MS-DOS) filesystem support; but the i386 bsd.rd does. If you wanted to capture an i386 dmesg -- which is similar to but not the same as an amd64 one:


Boot i386 install media
At the Install/Upgrade/Shell prompt, select Shell
Issue the commands shown in FAQ 4.15.

--------

You could also reinstall OpenBSD -- using the i386 architecture instead of amd64. Your CPU can run it, and ... if your problem is related to amd64 in some way, perhaps this would be a functional workaround.

[karl]

Thanks jggimi. Now I understand what the FAQ meant.

I might considering booting using i386 cd, but I'll do it just to get the dmesg. I still prefer AMD64 version to be installed here though. Currently I'm getting the FreeBSD's AMD64 iso to see if I'll get any problems too.

Just wanna know, I have a few FreeBSD's cd lying around, can I use that to get this OpenBSD's dmesg? If I can, it'll save me some time downloading OpenBSD's i386 iso. Thanks!

[jggimi]

FreeBSD and OpenBSD have little in common with each other under the covers -- both are based on the unencumbered Berkeley Software Distribution circa 1994 (4.4BSD Lite). They have the same code base, but each has had hundreds of thousands of changes since.

A FreeBSD dmesg would not be helpful to diagnose OpenBSD problems.

Unless you have 64-bit specific applications in mind, there won't be significant advantage to amd64 over i386 -- and the i386 environment has some workstation advantages (such as Linux emulation for things like Opera/Flash).

[karl]

To think about it, yeah maybe i386 wouldn't be bad at all. Although my point on AMD64 was just to try it out and maybe stick with it. Don't have any specific AMD64 stuff in mind, just want to experience running AMD64 *BSD. So that I can brag to my buddies that I'm running AMD64 OpenBSD lol.

I'm getting the i386 iso now. Thanks fer helping me out jggimi.

[jggimi]

You're welcome.

Of course, there's no guarantee that OpenBSD/i386 will work, but ... if the problem is amd64-specific, you'll save yourself some head and heart ache.

[karl]

Ah. Just to post an update. Looks like it's not just the AMD64 problem. I'm having the same situation with 4.3 i386 cd. Installation fine but froze my machine on booting. Tried disabling ACPI with no success. So, I guess on this hardware, it's not my day. :(

[jggimi]

Don't give up entirely -- you've been using 4.3-release. You might try a "snapshot" of 4.4-beta, in either amd64 or i386. See this post:

http://www.daemonforums.org/showthread.php?t=1194

[karl]

Just another information. I tried FreeBSD 7.0-R AMD64 and it's running ok (I know OpenBSD and FreeBSD are quite different but anyway) so I guess there's a hardware somewhere which is causing the problem on OpenBSD.

I think I'll wait fer 4.4 and see if there's any improvement. Hopefully before then, I can disable the correct device(s) to make 4.3 works here. Thanks fer the helps so far jggimi. Until I can make OpenBSD works on my pc, I'll try.