Re: CVS commit: src/sys/arch/x86/x86

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Wed, May 21, 2008 at 01:29:43AM +0000, David Holland wrote:
> On Tue, May 20, 2008 at 04:09:19PM +0200, Manuel Bouyer wrote:
>  > > > For starters, can you (a) test if it works after "disable ioapic" and
>  > > > (b) can you provide me the dmesg of both the working and non-working
>  > > > revision with INTRDEBUG?
>  > > 
>  > > Running the controller in AHCI mode (which seems to be the Right Thing
>  > > (TM)) makes both this problem and the (probably related) hangs with
>  > > ACPI enabled go away, *and* causes it to be able to find both the
>  > > disks connected to it.
>  > > 
>  > > See kern/37826.
>  > > 
>  > > So I think you can ignore the problem.
>  > 
>  > I think the switch to ACPI just hides the problem, it's not a fix. The
>  > root of the issue seems to be interrupts not working in some cases, and
>  > hidding it here by using ACPI doesn't mean it won't show up with some other
>  > device in a different configuration.
> 
> Well, no, it works with ACPI now (it didn't before) and also without
> ACPI but with Joerg's changes.
> 
> Or do you mean switching to AHCI? (mmm, alphabet soup)

Yes, I meant AHCI

> 
> That I'm less sure of, but that's what both the Linux and FreeBSD
> drivers do with this controller, and I think the proper fix is to make
> ahcisata(4) be able to do that too.

We may want to do it for buggy chips (which this one seems to be after
all, sorry for mixing issues) but certainly not for all AHCI-capable
controllers. We have to respect the BIOS settings when we can.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--