libata and PATA devices

libata and PATA devices

[Andreas Klöckner]

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

Hey Jeff, all,

I was wondering why ATA_ENABLE_PATA and ATA_ENABLE_ATAPI are #undef'ed in 
include/linux/libata.h by default, since reverting them to #define's was the 
only way to make the ata-piix driver detect my CDROM on my new shiny ThinkPad 
(Intel Corp. 82801FBM (ICH6M) SATA Controller). I would assume that most 
people would want this. The drive worked out of the box on Ubuntu, so I 
assume that their vendor patch includes this anyway.

Is there a specific reason that these are disabled? Are there any bad 
consequences that I'm not aware of? Only reading the source really revealed 
that this was the way to get my CD-ROM to work.

Thanks,
Andreas

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

Re: libata and PATA devices

[Tejun Heo]

  Hello, Andreas.


Andreas Klöckner wrote:
> Hey Jeff, all,
> 
> I was wondering why ATA_ENABLE_PATA and ATA_ENABLE_ATAPI are #undef'ed in 
> include/linux/libata.h by default, since reverting them to #define's was the 
> only way to make the ata-piix driver detect my CDROM on my new shiny ThinkPad 
> (Intel Corp. 82801FBM (ICH6M) SATA Controller). I would assume that most 
> people would want this. The drive worked out of the box on Ubuntu, so I 
> assume that their vendor patch includes this anyway.
> 
> Is there a specific reason that these are disabled? Are there any bad 
> consequences that I'm not aware of? Only reading the source really revealed 
> that this was the way to get my CD-ROM to work.

  SATA ATAPI support still has some issues, but as you can read from the 
following post, libata is almost there now.

http://marc.theaimsgroup.com/?l=linux-kernel&m=112261379120567&w=2

  I don't know much about PATA support.  All I know is that ICH's seem 
to generate a lot of noise in this mailing list w/ its legacy, combined, 
ahci and whatever modes and no one setting seems to satisfy all.  (If 
anyone knows more about it, please fill in here.)

-- 
tejun

Re: libata and PATA devices

[Jeff Garzik]

On Mon, Aug 08, 2005 at 10:43:41AM +0900, Tejun Heo wrote:
>  I don't know much about PATA support.  All I know is that ICH's seem 
> to generate a lot of noise in this mailing list w/ its legacy, combined, 
> ahci and whatever modes and no one setting seems to satisfy all.  (If 
> anyone knows more about it, please fill in here.)

Combined mode aggregates the PATA and SATA devices into a single PCI
device.  The chosen solution was to use the IDE driver for PATA, and
libata for SATA.

This was necessary since ATAPI support did not exist in libata (nor did
SATAPI devices exist).  An unfortunate side effect is that only one
driver could have access to the busmaster DMA registers -- libata --
which meant that the IDE driver was limited to PIO data xfer for PATA.

Once ATAPI support is mature in libata, we can support PATA fully in
libata, and eliminate this PATA speed limitation in combined mode.

	Jeff

Re: libata and PATA devices

[Erik Slagter]

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

On Sun, 2005-08-07 at 23:02 -0400, Jeff Garzik wrote:
> On Mon, Aug 08, 2005 at 10:43:41AM +0900, Tejun Heo wrote:
> >  I don't know much about PATA support.  All I know is that ICH's seem 
> > to generate a lot of noise in this mailing list w/ its legacy, combined, 
> > ahci and whatever modes and no one setting seems to satisfy all.  (If 
> > anyone knows more about it, please fill in here.)
> 
> Combined mode aggregates the PATA and SATA devices into a single PCI
> device.  The chosen solution was to use the IDE driver for PATA, and
> libata for SATA.

BTW can you tell me why my PATA harddisk shows up as scsi (sd..) disk
using ICH6M, using kernel with both plain ide and libata/piix enabled? I
was under the impression that PATA harddisks should always show up as
hd..

I tried two approaches and both sort of work: include the PCI id in the
ide/piix list (disk/cd show up as hd..) or enable atapi in libata
(disk/cd show up as sd/scd), although the latter tends to lock up hard
every once in while, which is to be expected I assume.

Just puzzled...

Is there a possibility that dell attaches PATA harddisks using a
SATA/PATA converter to the SATA connection of the ICH6M?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: libata and PATA devices

[Mark Lord]

Erik Slagter wrote:
>
> Is there a possibility that dell attaches PATA harddisks using a
> SATA/PATA converter to the SATA connection of the ICH6M?

That chipset is used in virtually all modern laptops,
and includes a PATA interface as well as SATA.

Most current laptops ship with a PATA hard drive, and a PATA
ATAPI drive.  The easiest way to make them usable under Linux-2.6
is to patch libata and turn on ATAPI support, using ata_piix.

This REALLY ought to be on by default now, Jeff.
Especially since the default is to NOT work at all..

The libata code is taking forever to catch up to modern reality,
mostly because so much of it lives eternally in Jeff's private
git repository, where only a few people ever exercise the code.

The best way to get any remaining kinks out of it would be to
release it to a much wider audience.

As is, it's pretty good, except for the broken libata error handling
that (by default) locks up machines every hour or two.  But there's
also a fix for that, again floating around only in private repositories.

Let's get more of this code out where it can be used, guys!

Cheers

Re: libata and PATA devices

[Mark Lord]

Mark Lord wrote:
>
> Most current laptops ship with a PATA hard drive, and a PATA
> ATAPI drive.  The easiest way to make them usable under Linux-2.6
> is to patch libata and turn on ATAPI support, using ata_piix.
> 
> This REALLY ought to be on by default now, Jeff.
> Especially since the default is to NOT work at all..

Note:  I'm refering to the existing PATA ATAPI support in libata here,
not the forthcoming SATA ATAPI support!

The PATA ATAPI works now -- perhaps it could be turned on by default
while efforts continue to implement support for SATA ATAPI devices.

Cheers

Re: libata and PATA devices

[Jeff Garzik]

On Tue, Aug 09, 2005 at 10:10:17AM -0400, Mark Lord wrote:
> The PATA ATAPI works now -- perhaps it could be turned on by default
> while efforts continue to implement support for SATA ATAPI devices.

No, PATA ATAPI DMA still needs the same fixes that SATA ATAPI does.

ATAPI is incomplete, the reason why the IDE driver is preferred still.

	Jeff

Re: libata and PATA devices

[Erik Slagter]

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

On Tue, 2005-08-09 at 09:48 -0400, Mark Lord wrote:

> The libata code is taking forever to catch up to modern reality,
> mostly because so much of it lives eternally in Jeff's private
> git repository, where only a few people ever exercise the code.

I'd suggest sending some of it to Andy Morton, so it becomes a -mm patch
and it can be applied by non-git-people. Also imho it will get much
wider testing.

> As is, it's pretty good, except for the broken libata error handling
> that (by default) locks up machines every hour or two.

Exactly, that's why I don't use it for the moment.

And that's why I had to patch the standard ide support's PCI ID list
(and got some angry intel engineer barking on me).

> But there's also a fix for that, again floating around only in private repositories.

Grmbl.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: libata and PATA devices

[Jeff Garzik]

On Tue, Aug 09, 2005 at 07:05:33PM +0200, Erik Slagter wrote:
> On Tue, 2005-08-09 at 09:48 -0400, Mark Lord wrote:
> > But there's also a fix for that, again floating around only in private repositories.
> 
> Grmbl.

Mark is just working off steam.  The "fix" causes leaks, and does
not really fix what was intended.  It stops the symptoms Mark was
seeing, but eventually you'll run out of commands, or kernel memory,
and everything still stop _anyway_.

We don't apply band-aids, only fixes.

	Jeff

Re: libata and PATA devices

[Jeff Garzik]

On Tue, Aug 09, 2005 at 09:48:12AM -0400, Mark Lord wrote:
> Erik Slagter wrote:
> >
> >Is there a possibility that dell attaches PATA harddisks using a
> >SATA/PATA converter to the SATA connection of the ICH6M?
> 
> That chipset is used in virtually all modern laptops,
> and includes a PATA interface as well as SATA.
> 
> Most current laptops ship with a PATA hard drive, and a PATA
> ATAPI drive.  The easiest way to make them usable under Linux-2.6
> is to patch libata and turn on ATAPI support, using ata_piix.
> 
> This REALLY ought to be on by default now, Jeff.
> Especially since the default is to NOT work at all..

No, the IDE driver should be driving PATA chipsets at present, and if it
is not, someone should investigate the reason.

Turning on PATA support will probably be done soon, for PATA+SATA
combined mode situations, but not for others.  Flipping the switch
causes a lot of cases to switch from working /dev/hdX to working
/dev/sdX, which needs to be managed, and not done willy-nilly.

	Jeff

Re: libata and PATA devices

[Jeff Garzik]

Mark Lord wrote:
> Erik Slagter wrote:
> 
>>
>> Is there a possibility that dell attaches PATA harddisks using a
>> SATA/PATA converter to the SATA connection of the ICH6M?
> 
> 
> That chipset is used in virtually all modern laptops,
> and includes a PATA interface as well as SATA.
> 
> Most current laptops ship with a PATA hard drive, and a PATA
> ATAPI drive.  The easiest way to make them usable under Linux-2.6
> is to patch libata and turn on ATAPI support, using ata_piix.

No, the best thing to do is use the IDE driver for PATA.  That is the 
most stable, most well-tested path to ATAPI support at present.


> This REALLY ought to be on by default now, Jeff.
> Especially since the default is to NOT work at all..

Correct, because currently no one should be using libata for PATA support.

Turning on ATAPI and PATA support by default will break existing setups.


> The libata code is taking forever to catch up to modern reality,
> mostly because so much of it lives eternally in Jeff's private
> git repository, where only a few people ever exercise the code.

Exaggeration.  We're talking about a single #define here, to enable ATAPI.

	Jeff

Re: libata and PATA devices

[Erik Slagter]

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

On Wed, 2005-08-10 at 23:57 -0400, Jeff Garzik wrote:

> > Most current laptops ship with a PATA hard drive, and a PATA
> > ATAPI drive.  The easiest way to make them usable under Linux-2.6
> > is to patch libata and turn on ATAPI support, using ata_piix.
> 
> No, the best thing to do is use the IDE driver for PATA.  That is the 
> most stable, most well-tested path to ATAPI support at present.
>
> > This REALLY ought to be on by default now, Jeff.
> > Especially since the default is to NOT work at all..
> 
> Correct, because currently no one should be using libata for PATA support.

You are sort of contradicting yourself. My setup (Dell laptop with ICH6M
and PATA harddisk) defaults to using libata for the PATA hardisk. Only
with a specific patch (which adds the PCI id to the IDE driver's id
list, and which was not quite accepted here) the IDE driver will
recognise the ICH6M and use it (and then it works fine).

> Turning on ATAPI and PATA support by default will break existing setups.

> > The libata code is taking forever to catch up to modern reality,
> > mostly because so much of it lives eternally in Jeff's private
> > git repository, where only a few people ever exercise the code.
> 
> Exaggeration.  We're talking about a single #define here, to enable ATAPI.

How about a simple configure option...


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: libata and PATA devices

[Bartlomiej Zolnierkiewicz]

On 8/11/05, Erik Slagter <erik@slagter.name> wrote:
> On Wed, 2005-08-10 at 23:57 -0400, Jeff Garzik wrote:
> 
> > > Most current laptops ship with a PATA hard drive, and a PATA
> > > ATAPI drive.  The easiest way to make them usable under Linux-2.6

New laptops rather ship with:

SATA (or PATA + bridge) hard disk and PATA ATAPI drive

> > > is to patch libata and turn on ATAPI support, using ata_piix.
> >
> > No, the best thing to do is use the IDE driver for PATA.  That is the
> > most stable, most well-tested path to ATAPI support at present.
> >
> > > This REALLY ought to be on by default now, Jeff.
> > > Especially since the default is to NOT work at all..
> >
> > Correct, because currently no one should be using libata for PATA support.
> 
> You are sort of contradicting yourself. My setup (Dell laptop with ICH6M
> and PATA harddisk) defaults to using libata for the PATA hardisk. Only

Are you sure?

I suspect that you have SATA-PATA converter inside the laptop
(or you are simply not using vanilla kernel).

> with a specific patch (which adds the PCI id to the IDE driver's id
> list, and which was not quite accepted here) the IDE driver will
> recognise the ICH6M and use it (and then it works fine).

Yes, current situation with ICH6M support really sucks as many laptops
are set to use combined mode and don't have BIOS option to disable it
so users end up with unusable ATAPI device (== limited to PIO mode
only because DMA region is already reserved by libata and cannot be
used by IDE driver).

Jeff, what is the current status of libata ATAPI support?  IMO changes
(from you, Albert and Tejun) just need some polishing and merging,
or there is still some major work to do?

OTOH IDE driver should handle combined mode just fine and provide 
working ATAPI DMA (+ SMART support for HDD).  I prefer to not go
this way but the libata development is *extremely* slow (I'm not blaming
anyone just stating the fact)...

Bartlomiej

> > Turning on ATAPI and PATA support by default will break existing setups.
> 
> > > The libata code is taking forever to catch up to modern reality,
> > > mostly because so much of it lives eternally in Jeff's private
> > > git repository, where only a few people ever exercise the code.
> >
> > Exaggeration.  We're talking about a single #define here, to enable ATAPI.
> 
> How about a simple configure option...

Re: libata and PATA devices

[Erik Slagter]

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

On Thu, 2005-08-11 at 12:03 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > Most current laptops ship with a PATA hard drive, and a PATA
> > > > ATAPI drive.  The easiest way to make them usable under Linux-2.6
> 
> New laptops rather ship with:
> 
> SATA (or PATA + bridge) hard disk and PATA ATAPI drive

How do I find out?

As ICH6M features both PATA and SATA connections, I don't see why they'd
use a PATA bridge... The DVD drives use PATA anyway, btw.

> > You are sort of contradicting yourself. My setup (Dell laptop with ICH6M
> > and PATA harddisk) defaults to using libata for the PATA hardisk. Only

> Are you sure?

Yes I am sure. I can give you all the data to verify it yourself.

> I suspect that you have SATA-PATA converter inside the laptop

That would be a possibility, but I don't why.

> (or you are simply not using vanilla kernel).

You bet I always use vanilla kernels.

> > with a specific patch (which adds the PCI id to the IDE driver's id
> > list, and which was not quite accepted here) the IDE driver will
> > recognise the ICH6M and use it (and then it works fine).
> 
> Yes, current situation with ICH6M support really sucks as many laptops
> are set to use combined mode and don't have BIOS option to disable it

Yeah, grmbl.

> so users end up with unusable ATAPI device (== limited to PIO mode
> only because DMA region is already reserved by libata and cannot be
> used by IDE driver).

But with the patch (that adds the ID to the IDE driver), it all works.

> OTOH IDE driver should handle combined mode just fine and provide 
> working ATAPI DMA (+ SMART support for HDD).  I prefer to not go
> this way but the libata development is *extremely* slow (I'm not blaming
> anyone just stating the fact)...

I guess you have a quite bunch of users willing to test here ;-)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: libata and PATA devices

[Bartlomiej Zolnierkiewicz]

On 8/11/05, Erik Slagter <erik@slagter.name> wrote:
> On Thu, 2005-08-11 at 12:03 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > > Most current laptops ship with a PATA hard drive, and a PATA
> > > > > ATAPI drive.  The easiest way to make them usable under Linux-2.6
> >
> > New laptops rather ship with:
> >
> > SATA (or PATA + bridge) hard disk and PATA ATAPI drive
> 
> How do I find out?
> 
> As ICH6M features both PATA and SATA connections, I don't see why they'd
> use a PATA bridge... The DVD drives use PATA anyway, btw.

AFAIR ICH6M has only one PATA port and putting both HDD and DVD drive
on the same PATA port would sacrifice performance (because only one PATA
device can be used at a time).

> > > You are sort of contradicting yourself. My setup (Dell laptop with ICH6M
> > > and PATA harddisk) defaults to using libata for the PATA hardisk. Only
> 
> > Are you sure?
> 
> Yes I am sure. I can give you all the data to verify it yourself.
> 
> > I suspect that you have SATA-PATA converter inside the laptop
> 
> That would be a possibility, but I don't why.
> 
> > (or you are simply not using vanilla kernel).
> 
> You bet I always use vanilla kernels.
> 
> > > with a specific patch (which adds the PCI id to the IDE driver's id
> > > list, and which was not quite accepted here) the IDE driver will
> > > recognise the ICH6M and use it (and then it works fine).
> >
> > Yes, current situation with ICH6M support really sucks as many laptops
> > are set to use combined mode and don't have BIOS option to disable it
> 
> Yeah, grmbl.
> 
> > so users end up with unusable ATAPI device (== limited to PIO mode
> > only because DMA region is already reserved by libata and cannot be
> > used by IDE driver).
> 
> But with the patch (that adds the ID to the IDE driver), it all works.

Yes because in that case SATA controller is also driven by the IDE driver.

[ combined mode means that only PCI device for SATA controller is
  visible to the system and it controls both SATA and PATA devices ]

Bartlomiej

> > OTOH IDE driver should handle combined mode just fine and provide
> > working ATAPI DMA (+ SMART support for HDD).  I prefer to not go
> > this way but the libata development is *extremely* slow (I'm not blaming
> > anyone just stating the fact)...
> 
> I guess you have a quite bunch of users willing to test here ;-)

Re: libata and PATA devices

[Erik Slagter]

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

On Thu, 2005-08-11 at 12:26 +0200, Bartlomiej Zolnierkiewicz wrote:
> > As ICH6M features both PATA and SATA connections, I don't see why they'd
> > use a PATA bridge... The DVD drives use PATA anyway, btw.
> 
> AFAIR ICH6M has only one PATA port and putting both HDD and DVD drive
> on the same PATA port would sacrifice performance (because only one PATA
> device can be used at a time).

That's duff. The PATA harddisk that is used in my laptop, also comes in
a SATA version...



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: libata and PATA devices

[Bartlomiej Zolnierkiewicz]

On 8/11/05, Erik Slagter <erik@slagter.name> wrote:
> On Thu, 2005-08-11 at 12:26 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > As ICH6M features both PATA and SATA connections, I don't see why they'd
> > > use a PATA bridge... The DVD drives use PATA anyway, btw.
> >
> > AFAIR ICH6M has only one PATA port and putting both HDD and DVD drive
> > on the same PATA port would sacrifice performance (because only one PATA
> > device can be used at a time).
> 
> That's duff. The PATA harddisk that is used in my laptop, also comes in
> a SATA version...

You didn't even tell the vendor/model of the HDD

hdparm -I /dev/hda
 
output (with your patch applied) would be useful.

Re: libata and PATA devices

[Erik Slagter]

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

> > > AFAIR ICH6M has only one PATA port and putting both HDD and DVD drive
> > > on the same PATA port would sacrifice performance (because only one PATA
> > > device can be used at a time).
> > 
> > That's duff. The PATA harddisk that is used in my laptop, also comes in
> > a SATA version...
> 
> You didn't even tell the vendor/model of the HDD
> 
> hdparm -I /dev/hda
>  
> output (with your patch applied) would be useful.

It has been discussed here before. It's a Fujitsu MHT2080AH, see
http://www.fujitsu.com/global/services/computing/storage/hdd/mhdd/mht20ahxx-catalog.html, although this one is more clear on the subject: http://www.dealtime.com/xPF-Fujitsu_80GB_5400_RPM_ATA_6_2_5IN_FDB_NOTEBOOK_HARD_DRIVE


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: libata and PATA devices

[Mark Lord]

Jeff Garzik wrote:

> currently no one should be using libata for PATA support.

We emailed back and forth extensively about how this has
not been true since early this year.  Modern laptops are
using libata for the ICH6M support, simply because libata
claims that chipset, and the IDE driver does not.
These laptops are using PATA drives (eg. "FUJITSU MHV2100AH").

> Exaggeration.  We're talking about a single #define here, to enable ATAPI.

Fine for ATAPI, though it's two defines -- need to also enable DMA.
And Passthru is much bigger than a pair of #defines.

If we want more testing/feedback on them, they've got to be
put into wider use.  That simply doesn't happen when they're
tucked away in git repositories.

Sure, *I* using them from your git, but there are tons of
other people for whom that is an overly complex method,
and the result is that few of us bother.

On the other hand, some distros (eg. Ubuntu) are shipping with
Passthru included in their kernels, because it's so necessary
for things like laptop-mode.

Push some of this stuff out to the -mm tree, and maybe we'll get
more people exercising the code, and it'll progress more quickly.

"Release early, release often" -- the open source mantra.

Cheers!

Re: libata and PATA devices

[Jeff Garzik]

Mark Lord wrote:
> Jeff Garzik wrote:
> 
>> currently no one should be using libata for PATA support.
> 
> 
> We emailed back and forth extensively about how this has
> not been true since early this year.  Modern laptops are
> using libata for the ICH6M support, simply because libata
> claims that chipset, and the IDE driver does not.
> These laptops are using PATA drives (eg. "FUJITSU MHV2100AH").

This sounds like a misconfigured kernel.  The IDE driver should pick up 
the PATA port, and libata should pick up the SATA port.  Anything else 
is a bug, and should be addressed by me or Bart.


>> Exaggeration.  We're talking about a single #define here, to enable 
>> ATAPI.
> 
> 
> Fine for ATAPI, though it's two defines -- need to also enable DMA.

What define enables/disables DMA, in your opinion?


> And Passthru is much bigger than a pair of #defines.

That is a separate $thread.


> Push some of this stuff out to the -mm tree, and maybe we'll get
> more people exercising the code, and it'll progress more quickly.

Both passthru and ATAPI code are already available in the -mm tree, 
unless Andrew made a mistake and accidentally dropped passthru.

	Jeff

Re: libata and PATA devices

[Erik Slagter]

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

On Thu, 2005-08-11 at 13:19 -0400, Jeff Garzik wrote:
> Mark Lord wrote:
> > Jeff Garzik wrote:
> >> currently no one should be using libata for PATA support.
> > We emailed back and forth extensively about how this has
> > not been true since early this year.  Modern laptops are
> > using libata for the ICH6M support, simply because libata
> > claims that chipset, and the IDE driver does not.
> > These laptops are using PATA drives (eg. "FUJITSU MHV2100AH").
> 
> This sounds like a misconfigured kernel.  The IDE driver should pick up 
> the PATA port, and libata should pick up the SATA port.  Anything else 
> is a bug, and should be addressed by me or Bart.

See my and Marks posts now and two times in the past.

My PATA harddisk connected to ICH6M is NOT claimed by IDE but by libata
indeed.

If you think that is an error, that is okay with me, but it rather
puzzles me that when I post the patch that actually accomplishes this, I
only get a barking intel engineer and no other reply whatsoever.

BTW we're still talking plain vanilla kernel here.

So, please, make up your mind and at least don't simply deny or ignore
the situation.

> > And Passthru is much bigger than a pair of #defines.
> That is a separate $thread.

Also note that without passthrough libata is not half as useful as it
could be (no smart monitoring, ouch..)

> > Push some of this stuff out to the -mm tree, and maybe we'll get
> > more people exercising the code, and it'll progress more quickly.
> 
> Both passthru and ATAPI code are already available in the -mm tree, 
> unless Andrew made a mistake and accidentally dropped passthru.

Indeed I saw the passthrough code pass, but I don't remember having seen
any atapi patches.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: libata and PATA devices

[Wes Newell]

On Thu, 2005-08-11 at 13:19 -0400, Jeff Garzik wrote:

>>Mark Lord wrote:
>>    
>>
>>>Jeff Garzik wrote:
>>>      
>>>
>>>>currently no one should be using libata for PATA support.
>>>>        
>>>>
>>>We emailed back and forth extensively about how this has
>>>not been true since early this year.  Modern laptops are
>>>using libata for the ICH6M support, simply because libata
>>>claims that chipset, and the IDE driver does not.
>>>These laptops are using PATA drives (eg. "FUJITSU MHV2100AH").
>>>      
>>>
>>This sounds like a misconfigured kernel.  The IDE driver should pick up 
>>the PATA port, and libata should pick up the SATA port.  Anything else 
>>is a bug, and should be addressed by me or Bart.
>>    
>>

While ya'll are talking about pata support, has anyone got a driver that 
supports the pata ports of the SIS180 yet? And I don't care which 
way.:-) As you might recall, I tried patching the 5513 driver, but had 
limited success with constant lost interrupts. I'm not a C programmer 
and don't know much about the whole IDE layout, but I'm willing to test 
on a Jetway S755MAX Board, that constist of the standard pata ports off 
the sis755 and a secondary SIS180 with 2 ports of sata and 1 channel 
pata (2 drives). I'm running the 2.6.11 kernel, but can install whatever 
you would want to test with on another drive.

Re: libata and PATA devices

[Jeff Garzik]

Erik Slagter wrote:
> On Thu, 2005-08-11 at 13:19 -0400, Jeff Garzik wrote:
> 
>>Mark Lord wrote:
>>
>>>Jeff Garzik wrote:
>>>
>>>>currently no one should be using libata for PATA support.
>>>
>>>We emailed back and forth extensively about how this has
>>>not been true since early this year.  Modern laptops are
>>>using libata for the ICH6M support, simply because libata
>>>claims that chipset, and the IDE driver does not.
>>>These laptops are using PATA drives (eg. "FUJITSU MHV2100AH").
>>
>>This sounds like a misconfigured kernel.  The IDE driver should pick up 
>>the PATA port, and libata should pick up the SATA port.  Anything else 
>>is a bug, and should be addressed by me or Bart.
> 
> 
> See my and Marks posts now and two times in the past.
> 
> My PATA harddisk connected to ICH6M is NOT claimed by IDE but by libata
> indeed.
> 
> If you think that is an error, that is okay with me, but it rather
> puzzles me that when I post the patch that actually accomplishes this, I
> only get a barking intel engineer and no other reply whatsoever.
> 
> BTW we're still talking plain vanilla kernel here.
> 
> So, please, make up your mind and at least don't simply deny or ignore
> the situation.

Your patch was wrong because the SATA device should always be claimed by 
libata.

The system is thus:

1) drivers/pci/quirks.c reserves SATA ports (only!) for libata
2) Legacy IDE driver claims the unreserved PATA port
3) libata loads and uses the ports reserved in #1

This requires a specific kernel configuration:
(a) CONFIG_IDE_GENERIC be set, and
(b) IDE driver is built into the kernel.

This also requires that your SATA device is listed in drivers/pci/quirks.c.

Both (a) and (b) are kernel configuration issues.  I never saw anything 
in any email thread indicating that (a) and (b) were verified and 
eliminated as problem sources.


>>>And Passthru is much bigger than a pair of #defines.
>>
>>That is a separate $thread.
> 
> 
> Also note that without passthrough libata is not half as useful as it
> could be (no smart monitoring, ouch..)

SMART monitoring is implemented externally.  Passthru simply lets 
anybody submit random ATA commands.  There is no additional capability 
to be implemented in libata, besides passthru.


> Indeed I saw the passthrough code pass, but I don't remember having seen
> any atapi patches.

That's because all ATAPI stuff that exists is in the upstream kernel.

	Jeff

Re: libata and PATA devices

[Jeff Garzik]

Jeff Garzik wrote:
> The system is thus:
> 
> 1) drivers/pci/quirks.c reserves SATA ports (only!) for libata
> 2) Legacy IDE driver claims the unreserved PATA port
> 3) libata loads and uses the ports reserved in #1
> 
> This requires a specific kernel configuration:
> (a) CONFIG_IDE_GENERIC be set, and
> (b) IDE driver is built into the kernel.
> 
> This also requires that your SATA device is listed in drivers/pci/quirks.c.
> 
> Both (a) and (b) are kernel configuration issues.  I never saw anything 
> in any email thread indicating that (a) and (b) were verified and 
> eliminated as problem sources.

To be more clear:

The legacy ISA IDE driver, not the PIIX IDE driver, must claim the PATA 
port.

That is why it was incorrect to add ICH SATA PCI IDs to 
drivers/ide/pci/piix.c.

	Jeff

Re: libata and PATA devices

[Erik Slagter]

[-- Attachment #1.1: Type: text/plain, Size: 1634 bytes --]

On Thu, 2005-08-11 at 16:21 -0400, Jeff Garzik wrote:
> Erik Slagter wrote:

> Your patch was wrong because the SATA device should always be claimed by 
> libata.
> 
> The system is thus:
> 
> 1) drivers/pci/quirks.c reserves SATA ports (only!) for libata
> 2) Legacy IDE driver claims the unreserved PATA port
> 3) libata loads and uses the ports reserved in #1
> 
> This requires a specific kernel configuration:
> (a) CONFIG_IDE_GENERIC be set, and
> (b) IDE driver is built into the kernel.
> 
> This also requires that your SATA device is listed in drivers/pci/quirks.c.
> 
> Both (a) and (b) are kernel configuration issues.  I never saw anything 
> in any email thread indicating that (a) and (b) were verified and 
> eliminated as problem sources.

> To be more clear:

> The legacy ISA IDE driver, not the PIIX IDE driver, must claim the
> PATA port.

Okay, here it comes.

hardware: Dell Inspiron 9300 with ICH6M and Fujitsu PATA harddisk + PATA
dvd driver
kernel: 2.6.12.3 plain vanilla
config: generic ide, no ide piix support, no pci ide support whatsoever,
libata support, libata_piix support

result: the pata harddisk is recognised by libata_piix and
assigned /dev/sda, the dvd drive is found by the generic ide driver.
(dmesg output attached)

Alternative:

config: generic ide, no ide piix support, no pci ide support whatsoever,
libata support, no libata_piix support

result: not bootable because no root disk whatsoever is found
(no /dev/sda nor /dev/hda). The dvd driver is found by the generic ide
driver.

Looks like the practise does not match your statement.

[-- Attachment #1.2: dmesg-1 --]
[-- Type: text/plain, Size: 12906 bytes --]

Linux version 2.6.12.3test1 (erik@skylla) (gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)) #6 Fri Aug 12 17:54:49 CEST 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
 BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003ffda000 (usable)
 BIOS-e820: 000000003ffda000 - 0000000040000000 (reserved)
 BIOS-e820: 00000000e0000000 - 00000000f0007000 (reserved)
 BIOS-e820: 00000000f0008000 - 00000000f000c000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
 BIOS-e820: 00000000fed20000 - 00000000fee10000 (reserved)
 BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
127MB HIGHMEM available.
896MB LOWMEM available.
NX (Execute Disable) protection: active
On node 0 totalpages: 262106
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 225280 pages, LIFO batch:31
  HighMem zone: 32730 pages, LIFO batch:15
DMI 2.3 present.
ACPI: RSDP (v000 DELL                                  ) @ 0x000fc9b0
ACPI: RSDT (v001 DELL    CPi R   0x27d50217 ASL  0x00000061) @ 0x3ffda7d3
ACPI: FADT (v001 DELL    CPi R   0x27d50217 ASL  0x00000061) @ 0x3ffdb400
ACPI: MADT (v001 DELL    CPi R   0x27d50217 ASL  0x00000047) @ 0x3ffdbc00
ACPI: MCFG (v016 DELL    CPi R   0x27d50217 ASL  0x00000061) @ 0x3ffdbbc0
ACPI: BOOT (v001 DELL    CPi R   0x27d50217 ASL  0x00000061) @ 0x3ffdb7c0
ACPI: SSDT (v001  PmRef  Cpu0Ist 0x00003000 INTL 0x20030522) @ 0x3ffdabe6
ACPI: SSDT (v001  PmRef  Cpu0Cst 0x00003001 INTL 0x20030522) @ 0x3ffdaa0e
ACPI: SSDT (v001  PmRef    CpuPm 0x00003000 INTL 0x20030522) @ 0x3ffda813
ACPI: DSDT (v001 INT430 SYSFexxx 0x00001001 MSFT 0x0100000e) @ 0x00000000
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:13 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 40000000 (gap: 40000000:a0000000)
Built 1 zonelists
Kernel command line: ro resume=/dev/hda4 root=/dev/hda2 nmi_watchdog=2 netconsole=@172.31.4.2/eth0,514@172.31.1.1/ root=/dev/sda2 init=/bin/sh
netconsole: local port 6665
netconsole: local IP 172.31.4.2
netconsole: interface eth0
netconsole: remote port 514
netconsole: remote IP 172.31.1.1
netconsole: remote ethernet address ff:ff:ff:ff:ff:ff
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 2128.592 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1034108k/1048424k available (2818k kernel code, 13500k reserved, 1214k data, 176k init, 130920k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 4194.30 BogoMIPS (lpj=2097152)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: afe9fbff 00100000 00000000 00000000 00000180 00000000 00000000
CPU: After vendor identify, caps: afe9fbff 00100000 00000000 00000000 00000180 00000000 00000000
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: After all inits, caps: afe9fbff 00100000 00000000 00000040 00000180 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel(R) Pentium(R) M processor 2.13GHz stepping 08
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=-1
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfbaae, last bus=4
PCI: Using MMCONFIG
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050309
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.2
Boot video device is 0000:01:00.0
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *10
ACPI: PCI Interrupt Link [LNKC] (IRQs *9 10 11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 5 *7 9 10 11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT]
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 10 devices
i8k: not running on a Dell system
i8k: vendor=Dell Inc., model=Inspiron 9300, version=A02
i8k: unable to get SMM Dell signature
i8k: unable to get SMM BIOS version
SCSI subsystem initialized
Linux Kernel Card Services
  options:  [pci] [cardbus] [pm]
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
Bluetooth: Core ver 2.7
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
pnp: 00:01: ioport range 0x4d0-0x4d1 has been reserved
pnp: 00:01: ioport range 0x1000-0x1005 could not be reserved
pnp: 00:01: ioport range 0x1008-0x100f could not be reserved
pnp: 00:02: ioport range 0xf400-0xf4fe has been reserved
pnp: 00:02: ioport range 0x1006-0x1007 has been reserved
pnp: 00:02: ioport range 0x100a-0x1059 could not be reserved
pnp: 00:02: ioport range 0x1060-0x107f has been reserved
pnp: 00:02: ioport range 0x1080-0x10bf has been reserved
pnp: 00:02: ioport range 0x10c0-0x10df has been reserved
pnp: 00:07: ioport range 0x900-0x90f has been reserved
pnp: 00:07: ioport range 0x910-0x91f has been reserved
pnp: 00:07: ioport range 0x920-0x92f has been reserved
pnp: 00:07: ioport range 0x930-0x93f has been reserved
pnp: 00:07: ioport range 0x940-0x97f has been reserved
Simple Boot Flag at 0x79 set to 0x1
Machine check exception polling timer started.
IA-32 Microcode Update Driver: v1.14 <tigran@veritas.com>
highmem bounce pool size: 64 pages
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 169
PCI: Setting latency timer of device 0000:00:01.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie03]
ACPI: AC Adapter [AC] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Lid Switch [LID]
ACPI: Power Button (CM) [PBTN]
ACPI: Sleep Button (CM) [SBTN]
ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3] C4[C3])
ACPI: Processor [CPU0] (supports 8 throttling states)
ACPI: Thermal Zone [THM] (52 C)
Real Time Clock Driver v1.12
hw_random: cannot enable RNG, aborting
PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
io scheduler noop registered
io scheduler deadline registered
loop: loaded (max 8 devices)
pktcdvd: v0.2.0a 2004-07-14 Jens Axboe (axboe@suse.de) and petero2@telia.com
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
netconsole: eth0 doesn't exist, aborting.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ide0: I/O resource 0x1F0-0x1F7 not free.
ide0: ports already in use, skipping probe
Probing IDE interface ide1...
hdc: SONY DVD+/-RW DW-D56A, ATAPI CD/DVD-ROM drive
Probing IDE interface ide2...
Probing IDE interface ide3...
Probing IDE interface ide4...
Probing IDE interface ide5...
ide1 at 0x170-0x177,0x376 on irq 15
hdc: ATAPI 24X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache
Uniform CD-ROM driver Revision: 3.20
libata version 1.11 loaded.
ahci version 1.00
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 17 (level, low) -> IRQ 193
ahci: probe of 0000:00:1f.2 failed with error -12
ata_piix version 1.03
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 17 (level, low) -> IRQ 193
ata: 0x170 IDE port busy
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xBFA0 irq 14
ata1: dev 0 cfg 49:2b00 82:346b 83:5b29 84:4003 85:3469 86:1a09 87:4003 88:203f
ata1: dev 0 ATA, max UDMA/100, 156301488 sectors:
ata1: dev 0 configured for UDMA/100
scsi0 : ata_piix
  Vendor: ATA       Model: FUJITSU MHT2080A  Rev: 006C
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
SCSI device sda: drive cache: write back
 sda: sda1 sda2 sda3 sda4
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0
ohci1394: $Rev: 1250 $ Ben Collins <bcollins@debian.org>
ACPI: PCI Interrupt 0000:03:01.1[B] -> GSI 18 (level, low) -> IRQ 201
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[201]  MMIO=[dfcfc800-dfcfcfff]  Max Packet=[2048]
video1394: Installed video1394 module
ieee1394: raw1394: /dev/raw1394 device initialized
sbp2: $Rev: 1219 $ Ben Collins <bcollins@debian.org>
ieee1394: Loaded AMDTP driver
ieee1394: Loaded CMP driver
PCI: Enabling device 0000:03:01.0 (0000 -> 0002)
ACPI: PCI Interrupt 0000:03:01.0[A] -> GSI 19 (level, low) -> IRQ 209
Yenta: CardBus bridge found at 0000:03:01.0 [1028:0189]
Yenta: ISA IRQ mask 0x04b8, PCI irq 209
Socket status: 30000006
mice: PS/2 mouse device common for all mice
Advanced Linux Sound Architecture Driver Version 1.0.9rc2  (Thu Mar 24 10:33:39 2005 UTC).
ACPI: PCI Interrupt 0000:00:1e.2[A] -> GSI 16 (level, low) -> IRQ 169
PCI: Setting latency timer of device 0000:00:1e.2 to 64
input: AT Translated Set 2 keyboard on isa0060/serio0
alps.c: Enabling hardware tapping
input: PS/2 Mouse on isa0060/serio1
input: AlpsPS/2 ALPS GlidePoint on isa0060/serio1
intel8x0_measure_ac97_clock: measured 49470 usecs
intel8x0: clocking to 48000
ACPI: PCI Interrupt 0000:00:1e.3[B] -> GSI 17 (level, low) -> IRQ 193
PCI: Setting latency timer of device 0000:00:1e.3 to 64
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[324fc0002e7d4c30]
MC'97 1 converters and GPIO not ready (0xff00)
ALSA device list:
  #0: Intel ICH6 with STAC9750,51 at 0xdffffe00, irq 169
  #1: Intel ICH Modem at 0xee00, irq 193
NET: Registered protocol family 2
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP established hash table entries: 262144 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
Bluetooth: L2CAP ver 2.7
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO (Voice Link) ver 0.4
Bluetooth: SCO socket layer initialized
Bluetooth: RFCOMM ver 1.5
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: BNEP (Ethernet Emulation) ver 1.2
Bluetooth: BNEP filters: protocol multicast
Bluetooth: HIDP (Human Interface Emulation) ver 1.1
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
acpi-cpufreq: CPU0 - ACPI performance management activated.
Testing NMI watchdog ... OK.
ACPI wakeup devices: 
 LID PBTN PCI0 USB0 USB1 USB2 USB4 USB3 MODM PCIE 
ACPI: (supports S0 S3 S4 S4bios S5)
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 176k freed
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on sda2, internal journal

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: libata and PATA devices

[Jeff Garzik]

Erik Slagter wrote:
> result: the pata harddisk is recognised by libata_piix and
> assigned /dev/sda, the dvd drive is found by the generic ide driver.
> (dmesg output attached)


Great!  That's precisely what's supposed to happen.  Except, the hard 
drive appears to be SATA, not PATA:

> ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xBFA0 irq 14
> ata1: dev 0 cfg 49:2b00 82:346b 83:5b29 84:4003 85:3469 86:1a09 87:4003 88:203f
> ata1: dev 0 ATA, max UDMA/100, 156301488 sectors:
> ata1: dev 0 configured for UDMA/100

Everything appears to be working just fine.  DVD appears via IDE driver, 
SATA drive appears via libata.

	Jeff

Re: libata and PATA devices

[Erik Slagter]

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

On Sat, 2005-08-13 at 11:33 -0400, Jeff Garzik wrote:
> Erik Slagter wrote:
> > result: the pata harddisk is recognised by libata_piix and
> > assigned /dev/sda, the dvd drive is found by the generic ide driver.
> > (dmesg output attached)

> Great!  That's precisely what's supposed to happen.  Except, the hard 
> drive appears to be SATA, not PATA:
> 
> > ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xBFA0 irq 14
> > ata1: dev 0 cfg 49:2b00 82:346b 83:5b29 84:4003 85:3469 86:1a09 87:4003 88:203f
> > ata1: dev 0 ATA, max UDMA/100, 156301488 sectors:
> > ata1: dev 0 configured for UDMA/100
> 
> Everything appears to be working just fine.  DVD appears via IDE driver, 
> SATA drive appears via libata.

Nope. The harddisk is not SATA, it's PATA. See the links I posted
earlier. That's the whole point.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: libata and PATA devices

[Jeff Garzik]

Erik Slagter wrote:
> On Sat, 2005-08-13 at 11:33 -0400, Jeff Garzik wrote:
> 
>>Erik Slagter wrote:
>>
>>>result: the pata harddisk is recognised by libata_piix and
>>>assigned /dev/sda, the dvd drive is found by the generic ide driver.
>>>(dmesg output attached)
> 
> 
>>Great!  That's precisely what's supposed to happen.  Except, the hard 
>>drive appears to be SATA, not PATA:
>>
>>
>>>ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xBFA0 irq 14
>>>ata1: dev 0 cfg 49:2b00 82:346b 83:5b29 84:4003 85:3469 86:1a09 87:4003 88:203f
>>>ata1: dev 0 ATA, max UDMA/100, 156301488 sectors:
>>>ata1: dev 0 configured for UDMA/100
>>
>>Everything appears to be working just fine.  DVD appears via IDE driver, 
>>SATA drive appears via libata.
> 
> 
> Nope. The harddisk is not SATA, it's PATA. See the links I posted
> earlier. That's the whole point.

The controller thinks its a SATA device, so there is probably a bridge 
installed.

	Jeff

Re: libata and PATA devices

[Erik Slagter]

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

On Sat, 2005-08-13 at 11:56 -0400, Jeff Garzik wrote:
> > Nope. The harddisk is not SATA, it's PATA. See the links I posted
> > earlier. That's the whole point.
> 
> The controller thinks its a SATA device, so there is probably a bridge 
> installed.

I suppose it's something like that.

It's all very confusing.

E.g. that would mean I must treat my PATA harddisk as if it's a SATA
harddisk, but on the other hand, it's not really a SATA disk, so I
cannot use SATA features.

Maybe an idea to spend a few words on the matter, including the way
you're supposed to configure the kernel for this setup.

BTW afaik you won't be able be able to control DMA on the dvd drive with
this setup, so I'll stick to my patched kernel for the moment (= both
disk&cdrom are assigned to ide).

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: libata and PATA devices

[Jeff Garzik]

Erik Slagter wrote:
> On Sat, 2005-08-13 at 11:56 -0400, Jeff Garzik wrote:
> 
>>>Nope. The harddisk is not SATA, it's PATA. See the links I posted
>>>earlier. That's the whole point.
>>
>>The controller thinks its a SATA device, so there is probably a bridge 
>>installed.
> 
> 
> I suppose it's something like that.
> 
> It's all very confusing.
> 
> E.g. that would mean I must treat my PATA harddisk as if it's a SATA
> harddisk, but on the other hand, it's not really a SATA disk, so I
> cannot use SATA features.
> 
> Maybe an idea to spend a few words on the matter, including the way
> you're supposed to configure the kernel for this setup.

Sounds like you've hit on the configuration, in the previous email. 
Yes, it does mean no DMA for the DVD drive.


> BTW afaik you won't be able be able to control DMA on the dvd drive with
> this setup, so I'll stick to my patched kernel for the moment (= both
> disk&cdrom are assigned to ide).

That's normal for combined mode.  Until libata can do ATAPI (soon!), the 
lack of DMA is a necessary evil, since two drivers are trying to claim 
two halves of the same hardware.

	Jeff

Re: libata and PATA devices

[Erik Slagter]

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

On Sat, 2005-08-13 at 12:44 -0400, Jeff Garzik wrote:

> > BTW afaik you won't be able be able to control DMA on the dvd drive with
> > this setup, so I'll stick to my patched kernel for the moment (= both
> > disk&cdrom are assigned to ide).
> 
> That's normal for combined mode.  Until libata can do ATAPI (soon!), the 
> lack of DMA is a necessary evil, since two drivers are trying to claim 
> two halves of the same hardware.

I already had it working this way, actually, but it has a bad habit of
locking up solid every now and then. So I'll wait and in the meantime
use my patched kernel (=all drives on IDE).

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: libata and PATA devices

[Mark Lord]

Erik Slagter wrote:
>
> I already had it working this way, actually, but it has a bad habit of
> locking up solid every now and then. So I'll wait and in the meantime
> use my patched kernel (=all drives on IDE).

That's a different problem, with a one-liner fix recently
posted to address it -- Jeff even has the one-liner out
for 2.6.13 now, I believe.

-ml


diff --git a/drivers/scsi/libata-scsi.c b/drivers/scsi/libata-scsi.c
--- a/drivers/scsi/libata-scsi.c
+++ b/drivers/scsi/libata-scsi.c
@@ -385,6 +385,7 @@ int ata_scsi_error(struct Scsi_Host *hos
           * appropriate place
           */
          host->host_failed--;
+       INIT_LIST_HEAD(&host->eh_cmd_q);

          DPRINTK("EXIT\n");
          return 0;

Re: libata and PATA devices

[Erik Slagter]

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

On Mon, 2005-08-15 at 17:39 -0400, Mark Lord wrote:
> > I already had it working this way, actually, but it has a bad habit of
> > locking up solid every now and then. So I'll wait and in the meantime
> > use my patched kernel (=all drives on IDE).
> 
> That's a different problem, with a one-liner fix recently
> posted to address it -- Jeff even has the one-liner out
> for 2.6.13 now, I believe.

Yep, I already applied it. Seems to work for me.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: libata and PATA devices

[Tyler]

Jeff, I think he stated in an earlier post to the list, the model number 
of the drive, and it is in fact a PATA drive... verified by checking 
fujitsu's website.  Or are you just saying that it "shows up as sata" by 
coming up as /dev/sda since its connected to a PATA port on a sata 
combined controller?

Tyler.

Jeff Garzik wrote:

> Erik Slagter wrote:
>
>> result: the pata harddisk is recognised by libata_piix and
>> assigned /dev/sda, the dvd drive is found by the generic ide driver.
>> (dmesg output attached)
>
>
>
> Great!  That's precisely what's supposed to happen.  Except, the hard 
> drive appears to be SATA, not PATA:
>
>> ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xBFA0 irq 14
>> ata1: dev 0 cfg 49:2b00 82:346b 83:5b29 84:4003 85:3469 86:1a09 
>> 87:4003 88:203f
>> ata1: dev 0 ATA, max UDMA/100, 156301488 sectors:
>> ata1: dev 0 configured for UDMA/100
>
>
> Everything appears to be working just fine.  DVD appears via IDE 
> driver, SATA drive appears via libata.
>
>     Jeff
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: libata and PATA devices

[Jeff Garzik]

Tyler wrote:
> Jeff, I think he stated in an earlier post to the list, the model number 
> of the drive, and it is in fact a PATA drive... verified by checking 
> fujitsu's website.  Or are you just saying that it "shows up as sata" by 
> coming up as /dev/sda since its connected to a PATA port on a sata 
> combined controller?

The SATA controller thinks its SATA.

	Jeff

Re: libata and PATA devices

[Erik Slagter]

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

On Sat, 2005-08-13 at 11:57 -0400, Jeff Garzik wrote:
> Tyler wrote:
> > Jeff, I think he stated in an earlier post to the list, the model number 
> > of the drive, and it is in fact a PATA drive... verified by checking 
> > fujitsu's website.  Or are you just saying that it "shows up as sata" by 
> > coming up as /dev/sda since its connected to a PATA port on a sata 
> > combined controller?
> 
> The SATA controller thinks its SATA.

That, I already noticed a long time ago. The question is, is libata
correct in thinking this?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: libata and PATA devices

[Jeff Garzik]

Erik Slagter wrote:
> On Sat, 2005-08-13 at 11:57 -0400, Jeff Garzik wrote:
> 
>>Tyler wrote:
>>
>>>Jeff, I think he stated in an earlier post to the list, the model number 
>>>of the drive, and it is in fact a PATA drive... verified by checking 
>>>fujitsu's website.  Or are you just saying that it "shows up as sata" by 
>>>coming up as /dev/sda since its connected to a PATA port on a sata 
>>>combined controller?
>>
>>The SATA controller thinks its SATA.
> 
> 
> That, I already noticed a long time ago. The question is, is libata
> correct in thinking this?

libata just reports what the controller reports.  If the controller says 
its SATA, that what I have to run with.

A lot of devices are bridged, so seeing a PATA device connected via SATA 
bus to a SATA controller is not uncommon.

	Jeff