SATA status report updated

0 views
Skip to first unread message

Jeff Garzik

unread,
Aug 12, 2005, 1:20:07 AM8/12/05
to

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Rob van Nieuwkerk

unread,
Aug 12, 2005, 1:50:07 AM8/12/05
to
On Fri, 12 Aug 2005 01:09:12 -0400
Jeff Garzik <jga...@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

Jeff Garzik

unread,
Aug 12, 2005, 1:50:10 AM8/12/05
to
Rob van Nieuwkerk wrote:
> On Fri, 12 Aug 2005 01:09:12 -0400
> Jeff Garzik <jga...@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

Daniel J Blueman

unread,
Aug 12, 2005, 6:30:24 AM8/12/05
to
As stability is a concern, why not get the ATA passthru work in
sooner, then follow up with the SMART support after the passthru code
has had time to mature?

IMHO, the passthru work is good value alone, as there is currently no
way to adjust various parameters (AM, spindown time, ...) of SATA
disks right now.

Rob van Nieuwkerk wrote:
> On Fri, 12 Aug 2005 01:09:12 -0400
> Jeff Garzik <jga...@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

___
Daniel J Blueman

Matthew Garrett

unread,
Aug 12, 2005, 6:50:06 AM8/12/05
to
Jeff Garzik <jga...@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.l...@srcf.ucam.org

Luben Tuikov

unread,
Aug 12, 2005, 10:20:11 AM8/12/05
to
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

Luben Tuikov

unread,
Aug 12, 2005, 10:50:17 AM8/12/05
to
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

David Greaves

unread,
Aug 12, 2005, 2:30:16 PM8/12/05
to
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

--

Mogens Valentin

unread,
Aug 12, 2005, 3:20:04 PM8/12/05
to
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

Jeff Garzik

unread,
Aug 12, 2005, 5:40:10 PM8/12/05
to
Daniel J Blueman wrote:
> As stability is a concern, why not get the ATA passthru work in
> sooner, then follow up with the SMART support after the passthru code
> has had time to mature?

SMART support == passthru.

Jeff

Jeff Garzik

unread,
Aug 12, 2005, 5:40:09 PM8/12/05
to
Matthew Garrett wrote:
> Jeff Garzik <jga...@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

Jeff Garzik

unread,
Aug 12, 2005, 5:40:11 PM8/12/05
to
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

Erik Slagter

unread,
Aug 13, 2005, 4:50:08 AM8/13/05
to
On Fri, 2005-08-12 at 17:30 -0400, Jeff Garzik wrote:
> Matthew Garrett wrote:
> > Jeff Garzik <jga...@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.

signature.asc

Simon Oosthoek

unread,
Aug 19, 2005, 4:20:16 AM8/19/05
to
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!
>

Good overview!

I'm wondering how the support for the SIS 182 controller is doing, I
noticed they have a GPL driver on their website for kernel 2.6.10, which
is not a drop in replacement for sata_sis.c in 2.6.12.5, I haven't tried
compiling it as an add-on module outside the tree, though...

Adding the 0x182 identifier to the 180 driver does compile (duh!), but I
haven't tried it on hardware.

As a temporary measure, there was a patch posted to this list [1] a
while ago, would it be a good idea to include this while full support is
being worked on?

Cheers

Simon

[1]
Patch signed-off-by: Rainer Koenig <Rainer...@fujitsu-siemens.com>

--- linux-2.6.12.4/drivers/scsi/sata_sis.c 2005-08-05 09:04:37.000000000
+0200
+++ linux/drivers/scsi/sata_sis.c 2005-08-11 10:22:07.000000000 +0200
@@ -62,6 +62,7 @@
static struct pci_device_id sis_pci_tbl[] = {
{ PCI_VENDOR_ID_SI, 0x180, PCI_ANY_ID, PCI_ANY_ID, 0, 0, sis_180 },
{ PCI_VENDOR_ID_SI, 0x181, PCI_ANY_ID, PCI_ANY_ID, 0, 0, sis_180 },
+ { PCI_VENDOR_ID_SI, 0x182, PCI_ANY_ID, PCI_ANY_ID, 0, 0, sis_180 },
{ } /* terminate list */
};

Rainer Koenig

unread,
Aug 19, 2005, 5:20:06 AM8/19/05
to
Hi Simon,

Simon Oosthoek <simon.o...@ti-wmc.nl> writes:

> I'm wondering how the support for the SIS 182 controller is doing, I
> noticed they have a GPL driver on their website for kernel 2.6.10,
> which is not a drop in replacement for sata_sis.c in 2.6.12.5, I
> haven't tried compiling it as an add-on module outside the tree,
> though...

I tried the sources from the SiS website (that seem to add more
details than my simple patch that just adds the device ID) as a drop
in for the Fedora installation kernel 2.6.11-1.1369_FC4, but the
kernel build process ran into an error at the sata_sis module. The
problem is that the source from SiS has a conditional code that
depends on the definition of a symbol "KERN_2_6_10" which is defined
by their "outside build makefile", but not in the standard kernel
build process. I added a #define KERN_2_6_10 to the source and then it
compiled also inside the kernel build process.

> Adding the 0x182 identifier to the 180 driver does compile (duh!), but
> I haven't tried it on hardware.

Working at a PC manufacturer I have access to hardware and I tried out
a lot and didn't run into any problem so far.

> As a temporary measure, there was a patch posted to this list [1] a
> while ago, would it be a good idea to include this while full support
> is being worked on?

Seeing that the source from the SiS website is much more going into the
details than my simple adding of the device ID (of course SiS has hopefully
a much deeper knowledge of their hardware than I have ;-) I would rather
go for integrating the SiS source in the current kernel.

And this problem is quite urgent since its a sort of "showstopper" for
brandnew hardware. We have a query from an university that wants to buy
7000 PCs with that hardware in the next 4 years, but until yesterday they
were unable to install Fedora Core 4 on the machine since the installer
doesn't see any hard disks. I succeeded to make a simple quick&dirty
driver disk to get Linux at least installed on the hard disk. But the
problem also applies for every other Linux distribution, so we urgently
need to get support for that device in the mainstream kernel hoping
that it will be inherited to the installation kernels of the distributions
soon.

Generally SATA is replacing parallel ATA in the new PC platforms and we
already got anouncements that future platforms will come with SATA only.
So can't emphasize enought that SATA support is absolutely important for
Linux on the desktop.

If there is something I can do to help or contribute let me know.

Best regards
Rainer
--
Dipl.-Inf. (FH) Rainer Koenig
Project Manager Linux
Business Clients
Fujitsu Siemens Computers
VP BC E SW OS
Phone: +49-821-804-3321
Fax: +49-821-804-2131

Jeff Garzik

unread,
Aug 19, 2005, 2:40:10 PM8/19/05
to

Yes, that's why I have resisted the "just add the PCI ID" patches that
have cropped up.

SiS submitted patches that duplicated portions of libata inside their
driver, rather than simply fixing libata as would be proper.

So we are stuck in the middle :(

Someone needs to work with the SiS submission until it's kosher with the
upstream kernel, then everybody will be happy.

Jeff

Simon Oosthoek

unread,
Aug 19, 2005, 7:10:09 PM8/19/05
to
Jeff Garzik wrote:

> Yes, that's why I have resisted the "just add the PCI ID" patches that
> have cropped up.
>
> SiS submitted patches that duplicated portions of libata inside their
> driver, rather than simply fixing libata as would be proper.
>
> So we are stuck in the middle :(
>
> Someone needs to work with the SiS submission until it's kosher with the
> upstream kernel, then everybody will be happy.

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 ;-)

Cheers

Simon

Jeff Garzik

unread,
Aug 19, 2005, 8:10:10 PM8/19/05
to
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

Rainer Koenig

unread,
Aug 20, 2005, 11:40:06 AM8/20/05
to
Hi Jeff,

Jeff Garzik <jga...@pobox.com> writes:

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

[Lot of interesting issues]

> 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.

That's very bad since the target platform for that chipset is able
to support AMD64. :-(

From your comments I've learned that my patch (just the device ID) is
too tiny and the SiS provided patch is doing too much things that it
shouldn't do. How can we find a solution for that?

Would it make sense that I try to find the "goods" in the SiS patch and
merge them somehow in the actual kernel? But: What kernel shall I take
to do that work? The latest development kernel, the kernel of my
distribution (whatever this will be, sooner or later it has to work
with all distributions) or just a kernel that is "close" to the patch
from SiS, e.g. 2.6.10?

As I mentioned before, getting hardware to try out patches wouldn't be
that big deal since I'm located in a PC factory and I can get test
machines if needed. What would be good tests to e.g. detect the problems
that you mentioned above? Are there hardware specific tests for SATA
hard disks around? I would be very interested in that since testing
also under Linux will become daily work for me and my colleauges from
the system test department.

Best regards
Rainer (posting from home)
--
Please send NO spam to my mail addresses.

Jeff Garzik

unread,
Aug 21, 2005, 5:40:06 PM8/21/05
to
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.

Mogens Valentin

unread,
Aug 21, 2005, 5:50:07 PM8/21/05
to
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

-

Rainer Koenig

unread,
Aug 22, 2005, 4:00:17 PM8/22/05
to
Hi Simon,

Simon Oosthoek <simon.o...@ti-wmc.nl> writes:

> Unfortunately I'm not able to check the logic of the driver, because
> although I can read C, I'm totally unfamiliar with the disk controler
> logic in the kernel...

Well, today I've spent some time in looking at the SiS driver and compared
it with the driver that is in kernel 2.6.10. And keeping Jeff's comments
about libata in mind (together with a printout of libata.h) helped a bit
to understand the differences. So I will see if I can somehow get the
important things from the SiS driver while using whatever libata
provides already. Will take some time anyway since kernel hacking is
not the main focus of my job. Anyway, I will try. I guess the main
issue is to find the 0x182 specific details and merge them into the
kernel driver.

Best regards
Rainer
--
Rainer König, Diplom-Informatiker (FH), Augsburg, Germany

Simon Oosthoek

unread,
Aug 22, 2005, 6:40:16 PM8/22/05
to
Hi Rainer

Rainer Koenig wrote:


> Jeff Garzik <jga...@pobox.com> writes:
>>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.
>
>
> That's very bad since the target platform for that chipset is able
> to support AMD64. :-(

that was my conclusion as well!

> From your comments I've learned that my patch (just the device ID) is
> too tiny and the SiS provided patch is doing too much things that it
> shouldn't do. How can we find a solution for that?
>
> Would it make sense that I try to find the "goods" in the SiS patch and
> merge them somehow in the actual kernel? But: What kernel shall I take
> to do that work? The latest development kernel, the kernel of my
> distribution (whatever this will be, sooner or later it has to work
> with all distributions) or just a kernel that is "close" to the patch
> from SiS, e.g. 2.6.10?
>
> As I mentioned before, getting hardware to try out patches wouldn't be
> that big deal since I'm located in a PC factory and I can get test
> machines if needed. What would be good tests to e.g. detect the problems
> that you mentioned above? Are there hardware specific tests for SATA
> hard disks around? I would be very interested in that since testing
> also under Linux will become daily work for me and my colleauges from
> the system test department.

I'll be happy to test patches that come up. I'm currently running
2.6.13-rc6-mm1, because it also has the sis190 ethernet driver in it,
which actually does work :-)

Unfortunately I'm not able to check the logic of the driver, because
although I can read C, I'm totally unfamiliar with the disk controler
logic in the kernel...

Cheers

Simon

Reply all
Reply to author
Forward
0 new messages