Date: Thu, 10 Dec 2009 21:14:15 -0800 (PST) From: "Chris H" <chris#@1command.com> To: freebsd-stable@freebsd.org Cc: John Baldwin <jhb@freebsd.org> Subject: Re: ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309 Message-ID: <bcf314caef8ae9c961ae07190e8cf3e9.HRCIM@webmail.1command.com> In-Reply-To: <200912100848.31916.jhb@freebsd.org> References: <30f6a6b39e2bdbf45c8ce69ee593831a.HRCIM@webmail.1command.com> <200912090950.37686.jhb@freebsd.org> <101228207f5fbe0513b5b034d15b8ab7.HRCIM@webmail.1command.com> <200912100848.31916.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bcf314caef8ae9c961ae07190e8cf3e9.HRCIM>