SATA ICH6M problems on Sharp M4000

SATA ICH6M problems on Sharp M4000

[Josh Litherland]

Trying to get this laptop operational; it has SATA for the hard disc and
PATA for the optical drive.  The hard drive is wired to the secondary
IDE interface, the optical to the primary.  As it stands, driving the
whole system with the PATA (piix) driver works, but performance for the
hard disc is (predictably) extremely poor.  With ata_piix driving the
hard drive, performance is great, but the optical device is never
enumerated.  When the piix driver tries to load, the following occurs:

ide0: I/O resource 0x1F0-0x1F7 not free.
ide0: ports already in use, skipping probe
ide1: I/O resource 0x170-0x177 not free.
ide1: ports already in use, skipping probe

We have tried to resolve this through a wide variety of kernel command
line options.  Tried every combination we could think of of ide0=0x1f0,
ide1=0x170, ide0=noprobe, ide1=noprobe, acpi=off, noapic, lapic,
pci=routeirq.  Tried shaking up module load order and using ide-generic
instead of piix.  ahci won't bind to the device; throws error -12.

Some information about this system including dmesg and lspci:

http://downloads.emperorlinux.com/research/lkml/sharp_m4000/

Thanks in advance for any advice you can give.

-- 
Josh Litherland (josh@emperorlinux.com)
Emperor Linux, Inc.

Re: SATA ICH6M problems on Sharp M4000

[Randy.Dunlap]

On Mon, 21 Nov 2005, Josh Litherland wrote:

>
> Trying to get this laptop operational; it has SATA for the hard disc and
> PATA for the optical drive.  The hard drive is wired to the secondary
> IDE interface, the optical to the primary.  As it stands, driving the
> whole system with the PATA (piix) driver works, but performance for the
> hard disc is (predictably) extremely poor.  With ata_piix driving the
> hard drive, performance is great, but the optical device is never
> enumerated.  When the piix driver tries to load, the following occurs:
>
> ide0: I/O resource 0x1F0-0x1F7 not free.
> ide0: ports already in use, skipping probe
> ide1: I/O resource 0x170-0x177 not free.
> ide1: ports already in use, skipping probe
>
> We have tried to resolve this through a wide variety of kernel command
> line options.  Tried every combination we could think of of ide0=0x1f0,
> ide1=0x170, ide0=noprobe, ide1=noprobe, acpi=off, noapic, lapic,
> pci=routeirq.  Tried shaking up module load order and using ide-generic
> instead of piix.  ahci won't bind to the device; throws error -12.
>
> Some information about this system including dmesg and lspci:
>
> http://downloads.emperorlinux.com/research/lkml/sharp_m4000/
>
> Thanks in advance for any advice you can give.

Is there a BIOS option for SATA or AHCI modes,
like Compatible mode or Enhanced mode?  If so, which mode
is it in?

-- 
~Randy

Re: SATA ICH6M problems on Sharp M4000

[Marek W]

On Tuesday 22 November 2005 09:39, Randy.Dunlap wrote:
> On Mon, 21 Nov 2005, Josh Litherland wrote:
> > Trying to get this laptop operational; it has SATA for the hard disc and
> > PATA for the optical drive.  The hard drive is wired to the secondary
> > IDE interface, the optical to the primary.  As it stands, driving the
> > whole system with the PATA (piix) driver works, but performance for the
> > hard disc is (predictably) extremely poor.  With ata_piix driving the
> > hard drive, performance is great, but the optical device is never
> > enumerated.  When the piix driver tries to load, the following occurs:
> >
> > ide0: I/O resource 0x1F0-0x1F7 not free.
> > ide0: ports already in use, skipping probe
> > ide1: I/O resource 0x170-0x177 not free.
> > ide1: ports already in use, skipping probe
> >
> > We have tried to resolve this through a wide variety of kernel command
> > line options.  Tried every combination we could think of of ide0=0x1f0,
> > ide1=0x170, ide0=noprobe, ide1=noprobe, acpi=off, noapic, lapic,
> > pci=routeirq.  Tried shaking up module load order and using ide-generic
> > instead of piix.  ahci won't bind to the device; throws error -12.
> >
> > Some information about this system including dmesg and lspci:
> >
> > http://downloads.emperorlinux.com/research/lkml/sharp_m4000/
> >
> > Thanks in advance for any advice you can give.
>
> Is there a BIOS option for SATA or AHCI modes,
> like Compatible mode or Enhanced mode?  If so, which mode
> is it in?

I have exactly the same problem with Asus W3030V which is also equipped with 
the ICH6M using the 2.6.14 kernel. There are no SATA/PATA options in BIOS for 
my laptop.

kernel options used libata.atapi_enabled=1 ide0=noprobe ide1=noprobe


-- 
-
Marek W
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: SATA ICH6M problems on Sharp M4000

[Jeff Garzik]

On Mon, Nov 21, 2005 at 05:30:07PM -0500, Josh Litherland wrote:
> Trying to get this laptop operational; it has SATA for the hard disc and
> PATA for the optical drive.  The hard drive is wired to the secondary
> IDE interface, the optical to the primary.  As it stands, driving the
> whole system with the PATA (piix) driver works, but performance for the
> hard disc is (predictably) extremely poor.

Expected behavior for combined mode, which only allows DMA for SATA.

Disabling legacy mode in BIOS should fix the performance problem, by
allowing IDE driver to fully drive PATA (including DMA), and libata to
fully drive SATA.


> With ata_piix driving the
> hard drive, performance is great, but the optical device is never
> enumerated.

Expected behavior, since the default for module option atapi_enabled
is zero (disabled).


> When the piix driver tries to load, the following occurs:
> 
> ide0: I/O resource 0x1F0-0x1F7 not free.
> ide0: ports already in use, skipping probe
> ide1: I/O resource 0x170-0x177 not free.
> ide1: ports already in use, skipping probe
> 
> We have tried to resolve this through a wide variety of kernel command
> line options.  Tried every combination we could think of of ide0=0x1f0,
> ide1=0x170, ide0=noprobe, ide1=noprobe, acpi=off, noapic, lapic,
> pci=routeirq.  Tried shaking up module load order and using ide-generic
> instead of piix.

So far everything seems to be expected behavior.


> ahci won't bind to the device; throws error -12.

Expected behavior, since your hardware doesn't seem to support AHCI.


> Some information about this system including dmesg and lspci:
> 
> http://downloads.emperorlinux.com/research/lkml/sharp_m4000/

In the future, 'lspci -n' and 'lspci -nvvv' is more useful.

	Jeff

Re: SATA ICH6M problems on Sharp M4000

[Josh Litherland]

Jeff Garzik wrote:

> Expected behavior, since the default for module option atapi_enabled
> is zero (disabled).

Thanks, turning this on makes everything work as expected.  Out of
curiosity, in your opinion is atapi in libata still not quite ready for
production use ?

Thanks to everyone who helped us track this down.

-- 
Josh Litherland (josh@emperorlinux.com)
Emperor Linux, Inc.

Re: SATA ICH6M problems on Sharp M4000

[Jeff Garzik]

On Tue, Nov 22, 2005 at 11:20:29AM -0500, Josh Litherland wrote:
> Jeff Garzik wrote:
> 
> > Expected behavior, since the default for module option atapi_enabled
> > is zero (disabled).
> 
> Thanks, turning this on makes everything work as expected.  Out of
> curiosity, in your opinion is atapi in libata still not quite ready for
> production use ?

If it was ready for production use, it would be enabled by default.

	Jeff

Re: SATA ICH6M problems on Sharp M4000

[Sergei Organov]

Jeff Garzik wrote:
> Josh Litherland wrote:
> > Trying to get this laptop operational; it has SATA for the hard disc and
> > PATA for the optical drive.  The hard drive is wired to the secondary
> > IDE interface, the optical to the primary.  
[...]
> > With ata_piix driving the hard drive, performance is great, but the
> > optical device is never enumerated.

I have exactly the same problem with my IBM ThinkPad T43 and 2.6.14
kernel and still can't find a way to let ata_piix manage the hard drive
and generic_ide to manage the optical one. BIOS doesn't have any
settings for SATA on this notebook.

> 
> Expected behavior, since the default for module option atapi_enabled
> is zero (disabled).
> 
> > When the piix driver tries to load, the following occurs:
> > 
> > ide0: I/O resource 0x1F0-0x1F7 not free.
> > ide0: ports already in use, skipping probe
> > ide1: I/O resource 0x170-0x177 not free.
> > ide1: ports already in use, skipping probe
[...]
> So far everything seems to be expected behavior.

Sorry, but provided ata_piix has ignored the optical drive, couldn't
corresponding I/O resource be left free so that subsequently loaded,
say, generic-ide module is able to get over and support the drive?

BTW, loading the modules in reverse order helped on 2.6.13 kernel (that
I'm currently using) as generic-ide didn't recognize the hard-drive at
all allowing ata_piix to get over it later. With 2.6.14 kernel
generic-ide does recognize both hard-drive and optical drive thus
preventing ata_piix from managing the hard-drive :(

-- 
Sergei.

Re: SATA ICH6M problems on Sharp M4000

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

On Fri, 02 Dec 2005 22:33:57 +0300 Sergei Organov wrote:

> Sorry, but provided ata_piix has ignored the optical drive, couldn't
> corresponding I/O resource be left free so that subsequently loaded,
> say, generic-ide module is able to get over and support the drive?
> 
> BTW, loading the modules in reverse order helped on 2.6.13 kernel (that
> I'm currently using) as generic-ide didn't recognize the hard-drive at
> all allowing ata_piix to get over it later. With 2.6.14 kernel
> generic-ide does recognize both hard-drive and optical drive thus
> preventing ata_piix from managing the hard-drive :(

See http://lkml.org/lkml/2005/10/18/167 and the reply to it :-\

If you want to build IDE as modules and still have support for
combined mode, you will need the patch below:

-------------------------------------------------------------------------

ide/libata: fix SCSI_SATA_INTEL_COMBINED setting with modular IDE

SCSI_SATA_INTEL_COMBINED should be set in any case when both IDE and
libata drivers are present in the configuration, even if both of them
are modular.  Checking for IDE=y breaks existing configurations with
modular IDE drivers, because without SCSI_SATA_INTEL_COMBINED there is
no way to use libata drivers for SATA and IDE drivers for PATA.

Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>

--- linux-2.6.14/drivers/scsi/Kconfig.alt-intel-combined	2005-10-28 04:02:08 +0400
+++ linux-2.6.14/drivers/scsi/Kconfig	2005-11-30 17:39:22 +0300
@@ -555,7 +555,7 @@ config SCSI_SATA_VITESSE
 
 config SCSI_SATA_INTEL_COMBINED
 	bool
-	depends on IDE=y && !BLK_DEV_IDE_SATA && (SCSI_SATA_AHCI || SCSI_ATA_PIIX)
+	depends on IDE && !BLK_DEV_IDE_SATA && (SCSI_SATA_AHCI || SCSI_ATA_PIIX)
 	default y
 
 config SCSI_BUSLOGIC

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: SATA ICH6M problems on Sharp M4000

[Sergei Organov]

Sergey Vlasov <vsu@altlinux.ru> writes:
> On Fri, 02 Dec 2005 22:33:57 +0300 Sergei Organov wrote:
>
>> Sorry, but provided ata_piix has ignored the optical drive, couldn't
>> corresponding I/O resource be left free so that subsequently loaded,
>> say, generic-ide module is able to get over and support the drive?
>> 
>> BTW, loading the modules in reverse order helped on 2.6.13 kernel (that
>> I'm currently using) as generic-ide didn't recognize the hard-drive at
>> all allowing ata_piix to get over it later. With 2.6.14 kernel
>> generic-ide does recognize both hard-drive and optical drive thus
>> preventing ata_piix from managing the hard-drive :(
>
> See http://lkml.org/lkml/2005/10/18/167 and the reply to it :-\

Well, Jef's answer was:

  This is a reasonable point, but the rare person who runs modular IDE on 
  these PATA/SATA combined mode beasts can certainly tell the IDE driver 
  to not probe certain ports.

I can say that the kernel I have problem with is from Debian "testing"
distribution so those "rare person" going to become quite a few in the
near future. Besides, Debian loads ata_piix first, then IDE, so telling
the IDE to ignore certain ports won't help.

Though one can argue that that's yet another distribution problem, I
fail to see a way for a distribution to overcome the problem provided it
doesn't know the exact hardware it will run on. No hope for modularized
kernel to run out of the box on given hardware?

Jeff, is there any hope it will be fixed in the kernel.org sources, or
should I report the problem to Debian instead so that they consider
maintaining their own patch?

> If you want to build IDE as modules and still have support for
> combined mode, you will need the patch below:

Sergey, thanks for the patch, -- now I understand the origin of the
problem and how to avoid it should I consider building the kernel
myself.

-- Sergei.

Re: SATA ICH6M problems on Sharp M4000

[Jeff Garzik]

Sergei Organov wrote:
> Sergey Vlasov <vsu@altlinux.ru> writes:
> 
>>On Fri, 02 Dec 2005 22:33:57 +0300 Sergei Organov wrote:
>>
>>
>>>Sorry, but provided ata_piix has ignored the optical drive, couldn't
>>>corresponding I/O resource be left free so that subsequently loaded,
>>>say, generic-ide module is able to get over and support the drive?
>>>
>>>BTW, loading the modules in reverse order helped on 2.6.13 kernel (that
>>>I'm currently using) as generic-ide didn't recognize the hard-drive at
>>>all allowing ata_piix to get over it later. With 2.6.14 kernel
>>>generic-ide does recognize both hard-drive and optical drive thus
>>>preventing ata_piix from managing the hard-drive :(
>>
>>See http://lkml.org/lkml/2005/10/18/167 and the reply to it :-\
> 
> 
> Well, Jef's answer was:
> 
>   This is a reasonable point, but the rare person who runs modular IDE on 
>   these PATA/SATA combined mode beasts can certainly tell the IDE driver 
>   to not probe certain ports.
> 
> I can say that the kernel I have problem with is from Debian "testing"
> distribution so those "rare person" going to become quite a few in the
> near future. Besides, Debian loads ata_piix first, then IDE, so telling
> the IDE to ignore certain ports won't help.
> 
> Though one can argue that that's yet another distribution problem, I
> fail to see a way for a distribution to overcome the problem provided it
> doesn't know the exact hardware it will run on. No hope for modularized
> kernel to run out of the box on given hardware?
> 
> Jeff, is there any hope it will be fixed in the kernel.org sources, or
> should I report the problem to Debian instead so that they consider
> maintaining their own patch?

Debian doesn't need to maintain a patch, they should load modules in the 
proper order.

	Jeff

Re: SATA ICH6M problems on Sharp M4000

[Sergei Organov]

Jeff Garzik <jgarzik@pobox.com> writes:
> Sergei Organov wrote:
>> Sergey Vlasov <vsu@altlinux.ru> writes:
>>
>>>On Fri, 02 Dec 2005 22:33:57 +0300 Sergei Organov wrote:
>>>
>>>
>>>>Sorry, but provided ata_piix has ignored the optical drive, couldn't
>>>>corresponding I/O resource be left free so that subsequently loaded,
>>>>say, generic-ide module is able to get over and support the drive?
>>>>
[...]
>>>See http://lkml.org/lkml/2005/10/18/167 and the reply to it :-\
>> Well, Jef's answer was:
>>
>>   This is a reasonable point, but the rare person who runs modular
>>   IDE on these PATA/SATA combined mode beasts can certainly tell the
>>   IDE driver to not probe certain ports.
>>
>> I can say that the kernel I have problem with is from Debian
>> "testing" distribution so those "rare person" going to become quite a
>> few in the near future. Besides, Debian loads ata_piix first, then
>> IDE, so telling the IDE to ignore certain ports won't help.  Though
>> one can argue that that's yet another distribution problem, I fail to
>> see a way for a distribution to overcome the problem provided it
>> doesn't know the exact hardware it will run on. No hope for
>> modularized kernel to run out of the box on given hardware?
>>
>> Jeff, is there any hope it will be fixed in the kernel.org sources,
>> or should I report the problem to Debian instead so that they consider
>> maintaining their own patch?
>
> Debian doesn't need to maintain a patch, they should load modules in the 
> proper order.

Do you mean that IDE then ata_piix is the right order? If so then the
following arguments arise:

1. It still won't work out-of-the-box as some IDE ports should be
explicitly disabled depending on particular hardware to get reasonable
performance of the hard-drive (changing of device name from hd to sd at
this point is another trouble). I don't think it's an acceptable
solution for a distribution kernel.

2. I doubt it's a good idea for the kernel in general to depend on
particular order of loading of modules when no explicit dependencies
between the modules are specified.

3. Loading IDE first somewhat suggests IDE should be preferred over
libata. Is it indeed true? ;)

Besides, does your answer mean that it won't indeed be changed in the
official kernel or it's undecided yet?

-- Sergei.

Re: SATA ICH6M problems on Sharp M4000

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1530 bytes --]

On Mon, Dec 05, 2005 at 01:20:28PM -0500, Jeff Garzik wrote:
> Sergei Organov wrote:
> >Sergey Vlasov <vsu@altlinux.ru> writes:
> >>See http://lkml.org/lkml/2005/10/18/167 and the reply to it :-\
> >
> >Well, Jef's answer was:
> >
> >  This is a reasonable point, but the rare person who runs modular IDE on 
> >  these PATA/SATA combined mode beasts can certainly tell the IDE driver 
> >  to not probe certain ports.
> >
> >I can say that the kernel I have problem with is from Debian "testing"
> >distribution so those "rare person" going to become quite a few in the
> >near future. Besides, Debian loads ata_piix first, then IDE, so telling
> >the IDE to ignore certain ports won't help.

mkinitrd in ALT Linux has some hacks to detect driver type (IDE or SCSI
subsystem) and load all IDE drivers before SCSI - exactly for this reason.

> >Though one can argue that that's yet another distribution problem, I
> >fail to see a way for a distribution to overcome the problem provided it
> >doesn't know the exact hardware it will run on. No hope for modularized
> >kernel to run out of the box on given hardware?
> >
> >Jeff, is there any hope it will be fixed in the kernel.org sources, or
> >should I report the problem to Debian instead so that they consider
> >maintaining their own patch?
> 
> Debian doesn't need to maintain a patch, they should load modules in the 
> proper order.

This will not help - without my patch the combined mode support code is
not compiled if IDE is modular.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]