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

[Chris H]

Hello, and thank you very much for your reply.

On Thu, December 10, 2009 5:48 am, John Baldwin wrote:
> On Wednesday 09 December 2009 8:52:06 pm Chris H wrote:
>
>> 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". :)
>
> Ok.
>
FreeBSD 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Dec 10 01:10:25 PST 2009 i386
All completed as intended. only 1 timeout error at the /very/ beginning. Which
was very short, and recovered immediately.

>
>> 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)?
>
> Hmmm, there isn't anything CPU-specific in ULE vs 4BSD, and I would expect
> ULE to work fine on a PIII.  I would generally expect device timeouts to be
> more of a driver issue than a scheduler issue.
>
Ahh, I see. Good to know.
I'm not sure where to try and "tune" things in this regard.
I can say that the timeouts /only/ occur during writes, and even then, only
during "bursts" of large, or many writes.
Example output emitted from one of the drives:
(da1:ahc0:0:2:0): Request Requeued
(da1:ahc0:0:2:0): Retrying Command
(da1:ahc0:0:2:0): Request Requeued
(da1:ahc0:0:2:0): Retrying Command
(da1:ahc0:0:2:0): Request Requeued
(da1:ahc0:0:2:0): Retrying Command
(da1:ahc0:0:2:0): Request Requeued
(da1:ahc0:0:2:0): Retrying Command
(da1:ahc0:0:2:0): Queue Full
(da1:ahc0:0:2:0): Retrying Command
(da1:ahc0:0:2:0): tagged openings now 64

While this new install seems to be better that previous installs in this regard.
I experimented with several drives on this board. ATA disks seemed to be more
problematic than SCSI. So I opted to only use SCSI drives on this board with the
exception of 1 DVDRW, and 1 CDROM - each as master on ports 0, and 1.
I should probably mention that the SCSI ports are driven by Adaptec onboard
controllers <Adaptec aic7899 Ultra160 SCSI adapter>. The Drives were both
"blanked" (formatted) using the format utility provided in the Adaptec BIOS.
There were no errors indicated, and there was no indication of excessive
re-mapping of sectors indicative of old/tired drives. Both drives are of equal
speed, and are of the same manufacturer:
<IBM DDRS-34560D DC1B> Fixed Direct Access SCSI-2 device
Serial Number RD2L5450
80.000MB/s transfers
<IBM DNES-318350W SA30> Fixed Direct Access SCSI-3 device
Serial Number         AKL08764
80.000MB/s transfers

Thank you again for all your time and consideration.

--Chris H

> --
> John Baldwin
>
>