Skip to contentSkip to conversation

SATA status report updated

DISCUSSION Jeff Garzik 8 participants 20 messages Aug 12, 2005 – Aug 21, 2005

Subsystems (2)
SCSI libata
lore
Share & tools
lore
#1 lore raw

On Fri, 12 Aug 2005 01:09:12 -0400
Jeff Garzik <[email protected]> wrote:

Hi Jeff,

Quoted 4 lines

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

Quoted 1 line

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

author
#2 lore raw
Quoted 6 lines · Rob van Nieuwkerk

On Fri, 12 Aug 2005 01:09:12 -0400
Jeff Garzik <[email protected]> wrote:

Hi Jeff,

Quoted 8 lines
Quoted 3 lines

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

#3 lore raw
In reply to Jeff Garzik
Quoted 9 lines · Jeff Garzik

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

#12 lore raw
In reply to Jeff Garzik
Quoted 8 lines · 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

Quoted 3 lines

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?

Quoted 3 lines

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)

Signature · 2 lines
Kind regards,
Mogens Valentin
#13 lore raw
In reply to Jeff Garzik
Quoted 8 lines · 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

Quoted 3 lines

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?

Quoted 3 lines

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)

Signature · 2 lines
Kind regards,
Mogens Valentin
#14 lore raw
In reply to Jeff Garzik
Quoted 8 lines · 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

Quoted 3 lines

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?

Quoted 3 lines

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)

Signature · 2 lines
Kind regards,
Mogens Valentin
author
#5 lore raw
In reply to Matthew Garrett
Quoted 10 lines · Matthew Garrett
Quoted 3 lines · 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

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

author
#15 lore raw
In reply to Mogens Valentin
Quoted 8 lines · Mogens Valentin
Quoted 4 lines · 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

Quoted 6 lines
Quoted 3 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 3 lines

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

#6 lore raw
In reply to Jeff Garzik
Quoted 9 lines · Jeff Garzik
Quoted 8 lines · Matthew Garrett
Quoted 4 lines · 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

Quoted 6 lines
Quoted 3 lines

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.

#7 lore raw
In reply to Jeff Garzik
Quoted 9 lines · Jeff Garzik
Quoted 8 lines · Matthew Garrett
Quoted 4 lines · 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

Quoted 6 lines
Quoted 3 lines

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.

#16 lore raw
In reply to Jeff Garzik
Quoted 11 lines · 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!

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 <[email protected]>

drivers/scsi/sata_sis.c +1 -0
@@ -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 */
 };
#17 lore raw
In reply to Jeff Garzik
Quoted 3 lines · Jeff Garzik

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.

Signature · 2 lines
Kind regards,
Mogens Valentin
author
#18 lore raw
Quoted 1 line · Mogens Valentin

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

#19 lore raw
Quoted 5 lines · Jeff Garzik
Quoted 1 line · Mogens Valentin

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.

Neigher had I. It's being used on the ASrock 939-SATAII mobo, in conjunction with the ULi M1695 chipset. I wonder why they chose an unknown SATAII chip for this. The M1695 already has two SATA150 interfaces, and the only test I've seen with SATAII on this mobo used a SATA150 disk on that JMB360 interface - with poorer results than on the regular ifc. Could be due to the chip, BIOS, (xp) driver...

The rest of the tests came out pretty good, and the board is well featured, so naturally I'm interested in possible libata support.

Signature · 2 lines
Kind regards,
Mogens Valentin