Date: Wed, 12 Nov 2008 18:00:14 GMT From: "Corey Smith" <corsmith@gmail.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/127391: [ata] Intel 6300ESB SATA150 cannot find disk and boot under 6.3 [regression] Message-ID: <200811121800.mACI0EAC091531@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/127391; it has been noted by GNATS. From: "Corey Smith" <corsmith@gmail.com> To: "John Baldwin" <jhb@freebsd.org> Cc: bug-followup@freebsd.org, satz@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@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? -Corey Smith
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200811121800.mACI0EAC091531>