kern/127391: [ata] Intel 6300ESB SATA150 cannot find disk and
boot under 6.3 [regression]
corsmith at gmail.com
Wed Nov 12 10:00:14 PST 2008
The following reply was made to PR kern/127391; it has been noted by GNATS.
From: "Corey Smith" <corsmith at gmail.com>
To: "John Baldwin" <jhb at freebsd.org>
Cc: bug-followup at freebsd.org, satz at iranger.com
Subject: Re: kern/127391: [ata] Intel 6300ESB SATA150 cannot find disk and boot under 6.3 [regression]
Date: Wed, 12 Nov 2008 12:55:59 -0500
On Wed, Nov 12, 2008 at 11:10 AM, John Baldwin <jhb at freebsd.org> wrote:
> So what the change does is merge a change from HEAD to change how DELAY()
> works. Instead going out to the RTC (expensive) it sits in a spin loop
> polling the TSC. Can you narrow down a specific DELAY() call in ATA that has
> a problem? Also, are you using 'device cpufreq' at all?
> John Baldwin
I can't say I understand why this fixes the problem :) I just know
that the patch stops the issue from occurring.
2008-11-10's RELENG_6 + this patch with the GENERIC kernel config
works. GENERIC doesn't have 'device cpufreq' in it.
If you can come up with a testing protocol I would be willing to give
it a go... perhaps I could make a copy of DELAY() called DELAY2()
with DELAY() being the unpatched implementation and DELAY2() being the
patched version. Then I could try test builds changing a single
DELAY() to DELAY2() in between each build. Which ever one breaks is
probably the culprit. There are 43 DELAY() calls in sys/dev/ata/ so
it make take a while to figure out.
Does that sound like a reasonable testing strategy?
More information about the freebsd-bugs