SATA status report updated

SATA status report updated

[Jeff Garzik]

Things in SATA-land have been moving along recently, so I updated the 
software status report:

	http://linux.yyz.us/sata/software-status.html

Although I have not updated it in several weeks, folks may wish to refer 
to the hardware status report as well:

	http://linux.yyz.us/sata/sata-status.html

Thanks to all the hard-working SATA contributors!

	Jeff

Re: SATA status report updated

[Rob van Nieuwkerk]

On Fri, 12 Aug 2005 01:09:12 -0400
Jeff Garzik <jgarzik@pobox.com> wrote:

Hi Jeff,

> Things in SATA-land have been moving along recently, so I updated the 
> software status report:
> 
> 	http://linux.yyz.us/sata/software-status.html

Is any progress made on SMART support ?
I've been reading "SMART support will be integrated very soon"
for a very long time now .. :-)

> Thanks to all the hard-working SATA contributors!

Yup, thanks to you & them.  SATA has been working perfect in my system
since I started using it 10 months ago !

	greetings,
	Rob van Nieuwkerk

Re: SATA status report updated

[Jeff Garzik]

Rob van Nieuwkerk wrote:
> On Fri, 12 Aug 2005 01:09:12 -0400
> Jeff Garzik <jgarzik@pobox.com> wrote:
> 
> Hi Jeff,
> 
> 
>>Things in SATA-land have been moving along recently, so I updated the 
>>software status report:
>>
>>	http://linux.yyz.us/sata/software-status.html
> 
> 
> Is any progress made on SMART support ?
> I've been reading "SMART support will be integrated very soon"
> for a very long time now .. :-)

True enough :/

It's been feature-complete for a while, but the reports from testers in 
the field have made me too nervous to push it into the upstream kernel.

I might push it upstream, but disable it by default, which would allow 
for a wider test audience.

	Jeff

Re: SATA status report updated

[Matthew Garrett]

Jeff Garzik <jgarzik@pobox.com> wrote:
> 
> Things in SATA-land have been moving along recently, so I updated the 
> software status report:
> 
> 	http://linux.yyz.us/sata/software-status.html

I couldn't see any reference to system-wide power management (ie,
suspend/resume of machines with SATA interfaces) - is any work going on
in that area at the moment?

Thanks,
-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

Re: SATA status report updated

[Luben Tuikov]

On 08/12/05 01:09, Jeff Garzik wrote:
> Things in SATA-land have been moving along recently, so I updated the 
> software status report:
> 
> 	http://linux.yyz.us/sata/software-status.html
> 
> Although I have not updated it in several weeks, folks may wish to refer 
> to the hardware status report as well:
> 
> 	http://linux.yyz.us/sata/sata-status.html
> 
> Thanks to all the hard-working SATA contributors!

Thank you Jeff!

*Incredibly* good work!

	Luben

Re: SATA status report updated

[Luben Tuikov]

On 08/12/05 01:09, Jeff Garzik wrote:
> Things in SATA-land have been moving along recently, so I updated the 
> software status report:
> 
> 	http://linux.yyz.us/sata/software-status.html
> 
> Although I have not updated it in several weeks, folks may wish to refer 
> to the hardware status report as well:
> 
> 	http://linux.yyz.us/sata/sata-status.html
> 
> Thanks to all the hard-working SATA contributors!

Thank you Jeff!

*Incredibly* good work!

	Luben

Re: SATA status report updated

[Luben Tuikov]

On 08/12/05 01:09, Jeff Garzik wrote:
> Things in SATA-land have been moving along recently, so I updated the 
> software status report:
> 
> 	http://linux.yyz.us/sata/software-status.html

Good write up.  I like the simplicity of error handling.

Thumbs up!

	Luben

Re: SATA status report updated

[David Greaves]

Jeff Garzik wrote:

>
> True enough :/
>
> It's been feature-complete for a while, but the reports from testers
> in the field have made me too nervous to push it into the upstream
> kernel.
>
> I might push it upstream, but disable it by default, which would allow
> for a wider test audience.

Could you specify what tests and reports would be useful and what risks
are involved?
Eg If I have 2 SATA drives then could (OK, of course it *could* - but is
it likely) I break sda whilst testing with sdb? I can live with crashes
and hangs and I can mitigate data loss, but I may think twice if it'll
toast the drive.

Nb: I often think that if people bemoaning the lack of testers put a bit
of effort into saying what tests would be useful then more people would
run them.
"Here run this and just say if it crashes" is one approach.
"Try these options, use smartd, turn on debugging like this and send
this part of the output if you have a problem. Previously reported
problems include: <blah, blah blah>. Oh, it's only ever going to affect
the drive you specify and the worst case scenario is a low-level format
using the vendor's download (which may or may not be available)" - makes
me more aware of what I'm getting into.

David

-- 

Re: SATA status report updated

[Mogens Valentin]

Jeff Garzik wrote:
> 
> Things in SATA-land have been moving along recently, so I updated the 
> software status report:
> 
>     http://linux.yyz.us/sata/software-status.html

 >> Queueing support, NCQ:
 >> #3 will be supported by libata, for all hardware and devices that
 >> support NCQ.

I guess this means libata support for HW-based NCQ.
It also could mean software/driver implemented NCQ, which could work on 
chipsets not supporting HW-NCQ in unison with a disk having NCQ?

> Although I have not updated it in several weeks, folks may wish to refer 
> to the hardware status report as well:
> 
>     http://linux.yyz.us/sata/sata-status.html

How well does libata work with the newest ULi chipsets?
If not well, is there a possible timeframe?


(not on kernel list; if anyone there comments on ULi, pls. cc private)

-- 
Kind regards,
Mogens Valentin

Re: SATA status report updated

[Mogens Valentin]

Jeff Garzik wrote:
> 
> Things in SATA-land have been moving along recently, so I updated the 
> software status report:
> 
>     http://linux.yyz.us/sata/software-status.html

 >> Queueing support, NCQ:
 >> #3 will be supported by libata, for all hardware and devices that
 >> support NCQ.

I guess this means libata support for HW-based NCQ.
It also could mean software/driver implemented NCQ, which could work on 
chipsets not supporting HW-NCQ in unison with a disk having NCQ?

> Although I have not updated it in several weeks, folks may wish to refer 
> to the hardware status report as well:
> 
>     http://linux.yyz.us/sata/sata-status.html

How well does libata work with the newest ULi chipsets?
If not well, is there a possible timeframe?


(not on kernel list; if anyone there comments on ULi, pls. cc private)

-- 
Kind regards,
Mogens Valentin

Re: SATA status report updated

[Jeff Garzik]

Matthew Garrett wrote:
> Jeff Garzik <jgarzik@pobox.com> wrote:
> 
>>Things in SATA-land have been moving along recently, so I updated the 
>>software status report:
>>
>>	http://linux.yyz.us/sata/software-status.html
> 
> 
> I couldn't see any reference to system-wide power management (ie,
> suspend/resume of machines with SATA interfaces) - is any work going on
> in that area at the moment?

Jens Axboe @ SuSE posted a patch that needs some work.  So, it's on the 
radar screen, but I haven't seen any new work recently.

	Jeff

Re: SATA status report updated

[Jeff Garzik]

Mogens Valentin wrote:
> Jeff Garzik wrote:
> 
>>
>> Things in SATA-land have been moving along recently, so I updated the 
>> software status report:
>>
>>     http://linux.yyz.us/sata/software-status.html
> 
> 
>  >> Queueing support, NCQ:
>  >> #3 will be supported by libata, for all hardware and devices that
>  >> support NCQ.
> 
> I guess this means libata support for HW-based NCQ.
> It also could mean software/driver implemented NCQ, which could work on 
> chipsets not supporting HW-NCQ in unison with a disk having NCQ?

NCQ by definition -requires- support in the controller chip.


>> Although I have not updated it in several weeks, folks may wish to 
>> refer to the hardware status report as well:
>>
>>     http://linux.yyz.us/sata/sata-status.html
> 
> 
> How well does libata work with the newest ULi chipsets?
> If not well, is there a possible timeframe?

No idea.  I don't see many bug reports, so I suppose its OK.

	Jeff

Re: SATA status report updated

[Erik Slagter]

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

On Fri, 2005-08-12 at 17:30 -0400, Jeff Garzik wrote:
> Matthew Garrett wrote:
> > Jeff Garzik <jgarzik@pobox.com> wrote:
> > 
> >>Things in SATA-land have been moving along recently, so I updated the 
> >>software status report:
> >>
> >>	http://linux.yyz.us/sata/software-status.html
> > 
> > 
> > I couldn't see any reference to system-wide power management (ie,
> > suspend/resume of machines with SATA interfaces) - is any work going on
> > in that area at the moment?
> 
> Jens Axboe @ SuSE posted a patch that needs some work.  So, it's on the 
> radar screen, but I haven't seen any new work recently.

Ah, the sata-suspend patch. Also very needed. Extensively used over here
on various kernels (2.6.11 and 2.6.12 versions), no problems, works like
a charm imho.

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

Re: SATA status report updated

[Jeff Garzik]

Simon Oosthoek wrote:
> I know Mandriva is on the ball and a bug with some information and an 
> updated patch is on the kernel bugme...
> 
> http://qa.mandriva.com/show_bug.cgi?id=17654
> http://bugme.osdl.org/show_bug.cgi?id=4192
> 
> I'd say it's important to get some proper fix in a distribution soon (so 
> I can use my new PC ;-)


That's not an updated patch.  That's the patch that duplicates kernel 
infrastructure, implementing things in the driver that should instead be 
implemented in libata core.

That's how Windows drivers are written: work around the OS, rather than 
fix it.

Here is a list of problems with the patch.  I'll paste this into the bug 
as well:

1) duplicates SATA phy reset

2) abuses infrastructure to support PATA, rather than doing it properly. 
  doing it properly involves an approach similar to that found in the 
'promise-sata-pata' branch of libata-dev.git.  Same problem as Promise 
SATA+PATA, with the same solution.

3) duplicates ATA bus reset, except, does it poorly

4) duplicates ata_busy_sleep()

5) appears to do strange things with PATA devices, when one uses the 
->scr_write() and ->scr_read() hooks -- hooks used to talk to SATA PHYs 
(never PATA devices).

6) [maybe] sets DMA/PIO timings even for SATA devices.  This -may- be 
needed, depending on PATA<->SATA bridge presence in the host controller

7) Pads DMA to 32-bit boundary.  Should be done in libata core, this is 
needed for all host controllers.

8) The DMA pad code is very buggy.  It uses the dma_map_single() to map 
a buffer, but never synchronizes nor flushes the buffer.  This can and 
will lead to data corruption, particularly on x86-64 platform.

Regards,

	Jeff

Re: SATA status report updated

[Mogens Valentin]

Jeff Garzik wrote:
> Although I have not updated it in several weeks, folks may wish to refer 
> to the hardware status report as well:
> 
>     http://linux.yyz.us/sata/sata-status.html

Jeff, is it possible for you at this time to comment on support for the 
JMicron JMB360 sataII chip?  Possible timeframe?
It's starting to be used with the ULi M1695/M1567 chipset.

-- 
Kind regards,
Mogens Valentin

Re: SATA status report updated

[Jeff Garzik]

Mogens Valentin wrote:
> Jeff, is it possible for you at this time to comment on support for the 
> JMicron JMB360 sataII chip?  Possible timeframe?


Never heard of it.

	Jeff

SATA status report updated

[Jeff Garzik]

I've updated the http://linux-ata.org/ status pages with the recent work 
by Tejun Heo and others.

	Jeff

Re: SATA status report updated

[Sven-Haegar Koch]

On Mon, 15 May 2006, Jeff Garzik wrote:

> I've updated the http://linux-ata.org/ status pages with the recent work by 
> Tejun Heo and others.

Thanks for your list, but I'm missing the SATA chipset that our Asus-Boxes 
got:

0000:00:14.1 IDE interface: ATI Technologies Inc ATI Dual Channel Bus 
Master PCI IDE Controller
(PCI-ID 1002:4349)

Or is this something different like an IDE chipset with included SATA 
bridges or so?

It is supported through the atiixp ide driver, but only really slow 
(10mb/s) - the same disks attached to an Intel SATA port give 30-40mb/s.

c'ya
sven

-- 

The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)

Re: SATA status report updated

[Jeff Garzik]

Sven-Haegar Koch wrote:
> On Mon, 15 May 2006, Jeff Garzik wrote:
> 
>> I've updated the http://linux-ata.org/ status pages with the recent 
>> work by Tejun Heo and others.
> 
> Thanks for your list, but I'm missing the SATA chipset that our 
> Asus-Boxes got:
> 
> 0000:00:14.1 IDE interface: ATI Technologies Inc ATI Dual Channel Bus 
> Master PCI IDE Controller
> (PCI-ID 1002:4349)
> 
> Or is this something different like an IDE chipset with included SATA 
> bridges or so?
> 
> It is supported through the atiixp ide driver, but only really slow 
> (10mb/s) - the same disks attached to an Intel SATA port give 30-40mb/s.

Should be ahci or sata_sil driver?

	Jeff