ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309

Chris H chris# at 1command.com
Thu Dec 10 01:52:08 UTC 2009


On Wed, December 9, 2009 6:50 am, John Baldwin wrote:
> On Tuesday 08 December 2009 7:06:18 pm Chris H wrote:
>
>> Greetings,
>> I am receiving the following in dmesg (verbose) during boot in 8-RELEASE
>> (GENERIC)
>> cvsuped 2009-12-08 @1am: ACPI Error: A valid RSDP was not found 20090521
>> tbxfroot-309
>>
>> As I create the KERNCONF for this machine, I want to confirm that this
>> message is caused by the fact that APM is shut off in the BIOS, and won't
>> cause any averse problems. We're having issues with "timeout" errors on some
>> 50 TYAN server MB's
>> since 7-RELEASE regarding the disk media (no matter how many different drives
>> we use). So as I attempt to create a STABLE - in the sense that the servers
>> are reliable, I want to eliminate any potential issues.
>>
>> more (informational) "noise" follows:
>
> You can ignore the message, I do think it is due to disabling ACPI in your
> BIOS.  Do you have problems when ACPI is enabled?  ACPI is generally going to
> be more reliable than !ACPI in the future as it seems many BIOS vendors no longer
> test the !ACPI case as much (e.g. I've seen Intel motherboards with incomplete
> or incorrect MP Tables because no commercial OS uses the MP Table anymore).

Hello, and thank you very much for your reply.
 So the message is simply "informative" - good to know.
As to the ACPI. Closer examination seemed to indicate the BIOS was incomplete.
While I could have flashed it, assuming that it 1) would have all current updates
2) it would then also be complete
I opted to simply take another new board off the shelf and try again. This time,
taking your advice, and /enabling/ full ACPI. I performed an install, and just
now cvsupped src && ports. It's in the process of building world/kernel as I
write this reply. Hope all turns out well - "Fingers crossed". :)
If you (or anyone else) can tell me...
I have had issues with periodic "timeouts" with disks (SCSI,ATA && CD/DVD ROMS)
ever since late 6. After experimenting with /many/ kernels. I'm left with the
suspicion the it has to do with SCHED_4BSD vs. SCHED_ULE. In other words, ever
since SCHED_ULE became default/preferred most of the PIII based boards have
exhibited this anomaly. Often the "retries" aren't exhausted, and they recover.
But many times they don't which will lead to freeze that requires "bouncing" the
machine, and performing FSCK(8). I haven't seen anything in UPDATING. But wonder;
should I assume that anything in the PIII category /requires/ SCHED_4BSD. Or
would it be better to tune a kernel via SYSCTL(8)?

Thank you again for all your time and consideration

--Chris H

>
> --
> John Baldwin
>
>




More information about the freebsd-stable mailing list