From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Sembera Subject: Re: Regression between v3.5 and v3.6 in libata Date: Wed, 27 Feb 2013 10:38:42 +0100 Message-ID: <20130227093842.GA8208@abydos.bofh.cz> References: <20130226200348.GA25087@abydos.bofh.cz> <20130226220702.GC25087@abydos.bofh.cz> <512DA957.1090600@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from anise.cz ([81.0.246.76]:42539 "EHLO anise.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755344Ab3B0Jip (ORCPT ); Wed, 27 Feb 2013 04:38:45 -0500 Content-Disposition: inline In-Reply-To: <512DA957.1090600@gmail.com> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Robert Hancock Cc: linux-ide@vger.kernel.org, mjg@redhat.com, holger@homac.de On Wed, Feb 27, 2013 at 12:36:07AM -0600, Robert Hancock wrote: > On 02/26/2013 04:07 PM, Jan Sembera wrote: > > So I apparently missed two most important differences between good and bad > > boots. > > > > On Tue, Feb 26, 2013 at 09:03:48PM +0100, Jan Sembera wrote: > >> [ 2.877438] scsi6 : pata_atiixp > >> [ 2.881369] scsi7 : pata_atiixp > >> > >> [ 2.391535] scsi6 : pata_acpi > >> [ 2.391994] scsi7 : pata_acpi > > > > pata-acpi doesn't play very well with this controller. Disabling it in > > kernel and rebooting (even with 3.8) provided completely working kernel. > > So either this driver shouldn't bind pata-acpi and leave it on pata-atiixp > > as before (some kind of blacklisting needed?), or it needs some fixing to > > work nicely with this controller. > > > > As a workaround for now, I'll just not compile PATA_ACPI into the kernel. > > What are your kernel config settings for these modules? The idea is that > pata_acpi is only supposed to get loaded if no other driver is able to > bind to the device. This is based on a config that Ubuntu uses for building vanilla kernels and has PATA_ACPI=y, PATA_ATIIXP=m. Which probably means that pata_acpi will grab the controller before pata_atiixp has any chance to do so. Which is probably bad and should be set to PATA_ACPI=m instead. Should this also be treated as a bug in pata_acpi, or is it expected that it's going to fail on some subset of motherboards/controllers and it's not worth bothering with fixing it, especially if there is some other driver that handles the controller fine?