Issues with AHCI and SATAII using JMD360

Issues with AHCI and SATAII using JMD360

[Moritz Heiber]

Hello,

as I skimmed through the mailinglist archives I noticed that support
for the JMD360 SATA chipset has just been added recently and so I went
ahead and tried to make use of my motherboard's SATAII capabilities.
Unfortunately, I did not succeed at it.

I'm using a ASRock 939Dual-SATA2 mainboard equipped with a JMD360 SATA
controller chip. A Hitachi Deskstar 7K250 (HDT722516DLA380), which is
supposed to support SATAII, is attached to the only available SATAII
compliant socket using the correct cables. The harddrive is recognized
correctly as SATAII device by the AMI BIOS (latest revision 1.8.0).

Currently, the drive only runs in SATA-mode at 1.5Gbps:

------

libata version 1.20 loaded.
ahci 0000:03:00.0: version 1.2
<...>
PCI: Setting latency timer of device 0000:03:00.0 to 64
ahci 0000:03:00.0: AHCI 0001.0000 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
ahci 0000:03:00.0: flags: 64bit ncq pm led clo pmp pio slum part 
ata1: SATA max UDMA/133 cmd 0xF8814100 ctl 0x0 bmdma 0x0 irq 5
<...>
ata1: SATA link up 1.5 Gbps (SStatus 113)
ata1: dev 0 cfg 49:2f00 82:346b 83:7fe9 84:4773 85:3469 86:3c01 87:4763 88:407f
ata1: dev 0 ATA-7, max UDMA/133, 321672960 sectors: LBA48
ata1: dev 0 configured for UDMA/133
scsi0 : ahci
  Vendor: ATA       Model: HDT722516DLA380   Rev: V43O
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
 sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0

------

(I see repeated output there ..)

The output of 'lspci -vv' for the JDM360 chipset is:

------

03:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (prog-if 01 [AHCI 1.0])
        Subsystem: ASRock Incorporation Unknown device 0360
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size 10
        Interrupt: pin A routed to IRQ 5
        Region 0: I/O ports at cc00 [size=8]
        Region 1: I/O ports at c880 [size=4]
        Region 2: I/O ports at c800 [size=8]
        Region 3: I/O ports at c480 [size=4]
        Region 4: I/O ports at c400 [size=16]
        Region 5: Memory at fe8fe000 (32-bit, non-prefetchable) [size=8K]
        Capabilities: [68] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] Express Legacy Endpoint IRQ 1
                Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
                Device: Latency L0s <64ns, L1 <1us
                Device: AtnBtn- AtnInd- PwrInd-
                Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
                Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
                Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
                Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 1
                Link: Latency L0s unlimited, L1 unlimited
                Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
                Link: Speed 2.5Gb/s, Width x1

------

I'm running 2.6.16.14 without any apparent patches (obviously
through Lunar Linux).

So I'm wondering, is it just me .. or might the driver actually do
something wrong here? Could it be a mismatching PCI_ID?

Any hints on how I'd be able to solve this problem would be highly
appreciated. I can, of course, provide more data or apply some further
testing incase you want me to.

Please CC me as I'm not subscribed to the linux-ide mailinglist.
Thank you for your time and patience.

Regards,

Moritz Heiber

Re: Issues with AHCI and SATAII using JMD360

[Tejun Heo]

Moritz Heiber wrote:
> Hello,
> 
> as I skimmed through the mailinglist archives I noticed that support
> for the JMD360 SATA chipset has just been added recently and so I went
> ahead and tried to make use of my motherboard's SATAII capabilities.
> Unfortunately, I did not succeed at it.
> 
> I'm using a ASRock 939Dual-SATA2 mainboard equipped with a JMD360 SATA
> controller chip. A Hitachi Deskstar 7K250 (HDT722516DLA380), which is
> supposed to support SATAII, is attached to the only available SATAII
> compliant socket using the correct cables. The harddrive is recognized
> correctly as SATAII device by the AMI BIOS (latest revision 1.8.0).

What does the BIOS say exactly?  SATA II is a vague term.  It comprises 
several features.  Some call NCQ-capable drives SATA-II while others 
consider 3.0Gbps link SATA-II.

> ata1: SATA link up 1.5 Gbps (SStatus 113)
> ata1: dev 0 cfg 49:2f00 82:346b 83:7fe9 84:4773 85:3469 86:3c01 87:4763 88:407f
> ata1: dev 0 ATA-7, max UDMA/133, 321672960 sectors: LBA48
> ata1: dev 0 configured for UDMA/133
> scsi0 : ahci
>   Vendor: ATA       Model: HDT722516DLA380   Rev: V43O
>   Type:   Direct-Access                      ANSI SCSI revision: 05
> SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
> sda: Write Protect is off
> sda: Mode Sense: 00 3a 00 00
> SCSI device sda: drive cache: write back
> SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
> sda: Write Protect is off
> sda: Mode Sense: 00 3a 00 00
> SCSI device sda: drive cache: write back
>  sda: sda1 sda2 sda3 sda4
> sd 0:0:0:0: Attached scsi disk sda
> sd 0:0:0:0: Attached scsi generic sg0 type 0
> 
> ------
> 
> (I see repeated output there ..)

That's a SCSI feature, cough, bug.  It has been like that for as long as 
I can remember and for some reason it stays that way.  My eyes are now 
selectively blind to those duplicate messages.

> I'm running 2.6.16.14 without any apparent patches (obviously
> through Lunar Linux).
> 
> So I'm wondering, is it just me .. or might the driver actually do
> something wrong here? Could it be a mismatching PCI_ID?
> 
> Any hints on how I'd be able to solve this problem would be highly
> appreciated. I can, of course, provide more data or apply some further
> testing incase you want me to.

I've googled and the drive does support 3Gbps.  There are several 
possibilities.

* jumper on the drive which limits it to 1.5Gbps is closed

* both the controller and drive support 3Gbps but somehow they fail to 
negotiate at that speed.

* BIOS limits link spd to 1.5Gbps using SControl in the hope for 
improving compatibility

More info can be obtained by printing SCR_CONTROL, just print the result 
of scr_read(ap, SCR_CONTROL) from libata.c::sata_print_link_status(), 
which prints the SStatus value.

Whatever the reason is, don't torture yourself over it.  It simply isn't 
worth.  1.5Gbps is more than enough for any drive on market today.

> Please CC me as I'm not subscribed to the linux-ide mailinglist.
> Thank you for your time and patience.

You don't need to request this.  It's how any linux mailing list works.

-- 
tejun

Re: Issues with AHCI and SATAII using JMD360

[Moritz Heiber]

On Sun, 07 May 2006 11:59:36 +0900
Tejun Heo <htejun@gmail.com> wrote:

> Moritz Heiber wrote:
> > Hello,
> > 
> > as I skimmed through the mailinglist archives I noticed that support
> > for the JMD360 SATA chipset has just been added recently and so I
> > went ahead and tried to make use of my motherboard's SATAII
> > capabilities. Unfortunately, I did not succeed at it.
> > 
> > I'm using a ASRock 939Dual-SATA2 mainboard equipped with a JMD360
> > SATA controller chip. A Hitachi Deskstar 7K250 (HDT722516DLA380),
> > which is supposed to support SATAII, is attached to the only
> > available SATAII compliant socket using the correct cables. The
> > harddrive is recognized correctly as SATAII device by the AMI BIOS
> > (latest revision 1.8.0).
> 
> What does the BIOS say exactly?  SATA II is a vague term.  It
> comprises several features.  Some call NCQ-capable drives SATA-II
> while others consider 3.0Gbps link SATA-II.

The manufacturer's url [1] states the following:

"PCI E SATA2 controller on board, optimizing the support for SATA2 HDD"

The BIOS and the manual [2] also state a speed advantage of 3.0Gbps.

[1] http://www.asrock.com/product/939Dual-SATA2.htm
[2] http://www.asrock.com/Drivers/Manual/939Dual-SATA2.pdf
    (Page 6)

> > I'm running 2.6.16.14 without any apparent patches (obviously
> > through Lunar Linux).
> > 
> > So I'm wondering, is it just me .. or might the driver actually do
> > something wrong here? Could it be a mismatching PCI_ID?
> > 
> > Any hints on how I'd be able to solve this problem would be highly
> > appreciated. I can, of course, provide more data or apply some
> > further testing incase you want me to.
> 
> I've googled and the drive does support 3Gbps.  There are several 
> possibilities.
> 
> * jumper on the drive which limits it to 1.5Gbps is closed

Negative. I double checked. Neither the drive's technical
specifications nor a visual inspection show a jumper or switch of any
sorts. Also, as a reminder .. the BIOS actually shows the drive as
being connected as SATAII capable device. So its (AFAIC) not a hardware
issue.

> * both the controller and drive support 3Gbps but somehow they fail
> to negotiate at that speed.

I guess that is the most likely explainations. Any way of solving that
issue?
 
> * BIOS limits link spd to 1.5Gbps using SControl in the hope for 
> improving compatibility

Giving that a thought .. the board's only PCIe slot is already occupied
by a pretty advanced video card. Could it be that the _bus_ is simply
outrun in terms of available bandwidth?

> More info can be obtained by printing SCR_CONTROL, just print the
> result of scr_read(ap, SCR_CONTROL) from
> libata.c::sata_print_link_status(), which prints the SStatus value.

I'm going to try to follow that lead. There doesn't seem to be any sort
of tool or application that runs the exact same test yet, is there?
hdparm fails on me.

> Whatever the reason is, don't torture yourself over it.  It simply
> isn't worth.  1.5Gbps is more than enough for any drive on market
> today.

Well, I'm just making an effort to get the best out of the hardware I
bought. I might fail at some point .. but at least I can say I tried.
 
Regards,

Moritz

Re: Issues with AHCI and SATAII using JMD360

[Mogens Valentin]

Moritz Heiber wrote:
> I'm using a ASRock 939Dual-SATA2 mainboard equipped with a JMD360 SATA
> controller chip. A Hitachi Deskstar 7K250 (HDT722516DLA380), which is
> supposed to support SATAII, is attached to the only available SATAII
> compliant socket using the correct cables. The harddrive is recognized
> correctly as SATAII device by the AMI BIOS (latest revision 1.8.0).
> 
> Currently, the drive only runs in SATA-mode at 1.5Gbps:
..snip..
> So I'm wondering, is it just me .. or might the driver actually do
> something wrong here? Could it be a mismatching PCI_ID?

You could try the config with MS, where AFAIK, it does SATA300 mode.
You could try skimming forums on ocworkbench.com for info, as this is 
kindof an asian homeforum, with JCM360 being designed by .tw Jmicron.

Whatever, it may or may not be worth too much trouble. I'm thinking 
JCM360 may have an unclear future, since AFAIK the later ULi chipsets 
have native SATA 300 support, and nVidia bought ULi, perhaps to produce 
entry level chipsets (according to press).
I was very interested in that same board, due to very good test results 
and features, but skipped it for the very JCM360 driver issue.
Being a dirt cheap board, you could spend on a separate selected SATA 
interface (to keep for the next board). The mobo certainly has enough 
PCIx slots for that.

What's you overall experience with the board, WRT stability/performance?

-- 
Kind regards,
Mogens Valentin

Re: Issues with AHCI and SATAII using JMD360

[Mogens Valentin]

Moritz Heiber wrote:
> On Sun, 07 May 2006 11:59:36 +0900
> Tejun Heo <htejun@gmail.com> wrote:
> 
>>More info can be obtained by printing SCR_CONTROL, just print the
>>result of scr_read(ap, SCR_CONTROL) from
>>libata.c::sata_print_link_status(), which prints the SStatus value.
> 
> 
> I'm going to try to follow that lead. There doesn't seem to be any sort
> of tool or application that runs the exact same test yet, is there?
> hdparm fails on me.

You might want to take a look at Douglas Gilbert's sdparm.

-- 
Kind regards,
Mogens Valentin

Re: Issues with AHCI and SATAII using JMD360

[Tejun Heo]

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

Moritz Heiber wrote:
> On Sun, 07 May 2006 11:59:36 +0900
>> What does the BIOS say exactly?  SATA II is a vague term.  It
>> comprises several features.  Some call NCQ-capable drives SATA-II
>> while others consider 3.0Gbps link SATA-II.
> 
> The manufacturer's url [1] states the following:
> 
> "PCI E SATA2 controller on board, optimizing the support for SATA2 HDD"
> 
> The BIOS and the manual [2] also state a speed advantage of 3.0Gbps.
> 
> [1] http://www.asrock.com/product/939Dual-SATA2.htm
> [2] http://www.asrock.com/Drivers/Manual/939Dual-SATA2.pdf
>     (Page 6)
> 

Hmmm...

[..snip..]
>> * both the controller and drive support 3Gbps but somehow they fail
>> to negotiate at that speed.
> 
> I guess that is the most likely explainations. Any way of solving that
> issue?

If this is the cause, it's a hardware problem.  Driver doesn't play any 
role in PHY spd negotiation other than limiting the top speed.

>> * BIOS limits link spd to 1.5Gbps using SControl in the hope for 
>> improving compatibility
> 
> Giving that a thought .. the board's only PCIe slot is already occupied
> by a pretty advanced video card. Could it be that the _bus_ is simply
> outrun in terms of available bandwidth?

No, completely unrelated.

>> More info can be obtained by printing SCR_CONTROL, just print the
>> result of scr_read(ap, SCR_CONTROL) from
>> libata.c::sata_print_link_status(), which prints the SStatus value.
> 
> I'm going to try to follow that lead. There doesn't seem to be any sort
> of tool or application that runs the exact same test yet, is there?
> hdparm fails on me.

Heh heh... I should have attached a patch for this.  I was too lazy. 
I'm attaching one on this mail.

>> Whatever the reason is, don't torture yourself over it.  It simply
>> isn't worth.  1.5Gbps is more than enough for any drive on market
>> today.
> 
> Well, I'm just making an effort to get the best out of the hardware I
> bought. I might fail at some point .. but at least I can say I tried.

Yeap, good luck.  FYI, my seagate 7200.9 and samsung hd160jj work fine @ 
3Gbps on ICH7 AHCI, sil3124 and sil3132.

--
tejun



[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1009 bytes --]

diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
index 8beba3c..966be30 100644
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -1503,20 +1503,23 @@ void ata_port_probe(struct ata_port *ap)
  */
 static void sata_print_link_status(struct ata_port *ap)
 {
-	u32 sstatus, tmp;
+	u32 sstatus, scontrol, tmp;
 
 	if (!ap->ops->scr_read)
 		return;
 
 	sstatus = scr_read(ap, SCR_STATUS);
+	scontrol = scr_read(ap, SCR_CONTROL);
 
 	if (sata_dev_present(ap)) {
 		tmp = (sstatus >> 4) & 0xf;
-		printk(KERN_INFO "ata%u: SATA link up %s (SStatus %X)\n",
-		       ap->id, sata_spd_string(tmp), sstatus);
+		printk(KERN_INFO
+		       "ata%u: SATA link up %s (SStatus %X SControl %X)\n",
+		       ap->id, sata_spd_string(tmp), sstatus, scontrol);
 	} else {
-		printk(KERN_INFO "ata%u: SATA link down (SStatus %X)\n",
-		       ap->id, sstatus);
+		printk(KERN_INFO
+		       "ata%u: SATA link down (SStatus %X SControl %X)\n",
+		       ap->id, sstatus, scontrol);
 	}
 }
 

Re: Issues with AHCI and SATAII using JMD360

[Tejun Heo]

Mogens Valentin wrote:
> Moritz Heiber wrote:
>> On Sun, 07 May 2006 11:59:36 +0900
>> Tejun Heo <htejun@gmail.com> wrote:
>>
>>> More info can be obtained by printing SCR_CONTROL, just print the
>>> result of scr_read(ap, SCR_CONTROL) from
>>> libata.c::sata_print_link_status(), which prints the SStatus value.
>>
>>
>> I'm going to try to follow that lead. There doesn't seem to be any sort
>> of tool or application that runs the exact same test yet, is there?
>> hdparm fails on me.
> 
> You might want to take a look at Douglas Gilbert's sdparm.
> 

Unfortunately, PHY spd setting is currently not exported to user space 
in anyway.  So, sdparm won't be of much use for this.

-- 
tejun

Re: Issues with AHCI and SATAII using JMD360

[Moritz Heiber]

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

On Sun, 07 May 2006 21:19:29 +0900
Tejun Heo <htejun@gmail.com> wrote:

<snip>
> >> More info can be obtained by printing SCR_CONTROL, just print the
> >> result of scr_read(ap, SCR_CONTROL) from
> >> libata.c::sata_print_link_status(), which prints the SStatus value.
> > 
> > I'm going to try to follow that lead. There doesn't seem to be any
> > sort of tool or application that runs the exact same test yet, is
> > there? hdparm fails on me.
> 
> Heh heh... I should have attached a patch for this.  I was too lazy. 
> I'm attaching one on this mail.

Here's the output:

------

libata version 1.20 loaded.
ahci 0000:03:00.0: version 1.2
PCI: Found IRQ 5 for device 0000:03:00.0
<...>
PCI: Setting latency timer of device 0000:03:00.0 to 64
ahci 0000:03:00.0: AHCI 0001.0000 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
ahci 0000:03:00.0: flags: 64bit ncq pm led clo pmp pio slum part 
ata1: SATA max UDMA/133 cmd 0xF8814100 ctl 0x0 bmdma 0x0 irq 5
<...>
ata1: SATA link up 1.5 (SStatus 113 SControl 300)
ata1: dev 0 cfg 49:2f00 82:346b 83:7fe9 84:4773 85:3469 86:3c01 87:4763 88:407f
ata1: dev 0 ATA-7, max UDMA/133, 321672960 sectors: LBA48
ata1: dev 0 configured for UDMA/133
scsi0 : ahci
  Vendor: ATA       Model: HDT722516DLA380   Rev: V43O
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 321672960 512-byte hdwr sectors (164697 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
 sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0

------

I guess the Scontrol value of 300 is .. good?

I had to adjust your patch since it didn't apply to my 2.6.16.14 kernel.
The "corrected" patch is attached. I think I pretty much retained the
functionality you intended it to have.

Given your patch though .. your git-based code looks much simpler. I
wonder if that is a good or a bad thing and wether I should try a more
recent kernel .. (?)

> > Well, I'm just making an effort to get the best out of the hardware
> > I bought. I might fail at some point .. but at least I can say I
> > tried.
> 
> Yeap, good luck.  FYI, my seagate 7200.9 and samsung hd160jj work
> fine @ 3Gbps on ICH7 AHCI, sil3124 and sil3132.

Yeah, as I heard the ICH(n) chipsets are pretty well supported.
Unfortunately, I went with a ULi chipset since they are rumoured to be
rock solid and stable (which my motherboard is actually).

Regards,

Moritz

[-- Attachment #2: libata-scontrol.patch --]
[-- Type: application/octet-stream, Size: 1226 bytes --]

--- drivers/scsi/libata-core.c.orig	2006-05-07 14:35:46.000000000 +0200
+++ drivers/scsi/libata-core.c	2006-05-07 14:41:31.000000000 +0200
@@ -1543,7 +1543,7 @@
  */
 void __sata_phy_reset(struct ata_port *ap)
 {
-	u32 sstatus;
+	u32 sstatus, scontrol;
 	unsigned long timeout = jiffies + (HZ * 5);
 
 	if (ap->flags & ATA_FLAG_SATA_RESET) {
@@ -1565,6 +1565,8 @@
 
 	/* TODO: phy layer with polling, timeouts, etc. */
 	sstatus = scr_read(ap, SCR_STATUS);
+	scontrol = scr_read(ap, SCR_CONTROL);
+	
 	if (sata_dev_present(ap)) {
 		const char *speed;
 		u32 tmp;
@@ -1576,12 +1578,14 @@
 			speed = "3.0";
 		else
 			speed = "<unknown>";
-		printk(KERN_INFO "ata%u: SATA link up %s Gbps (SStatus %X)\n",
-		       ap->id, speed, sstatus);
+                printk(KERN_INFO
+                       "ata%u: SATA link up %s (SStatus %X SControl %X)\n",
+                       ap->id, speed, sstatus, scontrol);
 		ata_port_probe(ap);
 	} else {
-		printk(KERN_INFO "ata%u: SATA link down (SStatus %X)\n",
-		       ap->id, sstatus);
+                printk(KERN_INFO
+                       "ata%u: SATA link down (SStatus %X SControl %X)\n",
+                       ap->id, sstatus, scontrol);
 		ata_port_disable(ap);
 	}
 

Re: Issues with AHCI and SATAII using JMD360

[Tejun Heo]

Moritz Heiber wrote:
> <...>
> PCI: Setting latency timer of device 0000:03:00.0 to 64
> ahci 0000:03:00.0: AHCI 0001.0000 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> ahci 0000:03:00.0: flags: 64bit ncq pm led clo pmp pio slum part 
> ata1: SATA max UDMA/133 cmd 0xF8814100 ctl 0x0 bmdma 0x0 irq 5
> <...>
> ata1: SATA link up 1.5 (SStatus 113 SControl 300)
> ata1: dev 0 cfg 49:2f00 82:346b 83:7fe9 84:4773 85:3469 86:3c01 87:4763 88:407f
> ata1: dev 0 ATA-7, max UDMA/133, 321672960 sectors: LBA48
> ata1: dev 0 configured for UDMA/133
> scsi0 : ahci
>   Vendor: ATA       Model: HDT722516DLA380   Rev: V43O
>   Type:   Direct-Access                      ANSI SCSI revision: 05
> ------
> 
> I guess the Scontrol value of 300 is .. good?

The digit in the middle is the SPD limit and 0 means no limit.  Hmm... 
wait, this is a hitachi disk.  Have you tried the feature tool?  Hitachi 
limits the spd of the harddrive tso 1.5 gbps, probably for compatibility 
reasons, and allows users to enable it with the feature tool.

http://www.hitachigst.com/hdd/support/download.htm#FeatureTool

* ....
* Configure SATA interface - adjust maximum speed and enable/disable 
Spread Spectrum Clocking.

> 
> I had to adjust your patch since it didn't apply to my 2.6.16.14 kernel.
> The "corrected" patch is attached. I think I pretty much retained the
> functionality you intended it to have.
> 
> Given your patch though .. your git-based code looks much simpler. I
> wonder if that is a good or a bad thing and wether I should try a more
> recent kernel .. (?)

The patch was pulled from libata devel tree.  I was being lazy again and 
didn't test it on 2.6.16.14.  :p  However, I can assure you libata 
doesn't play much role in PHY spd configuration.

-- 
tejun

Re: Issues with AHCI and SATAII using JMD360

[Moritz Heiber]

On Sun, 07 May 2006 22:23:59 +0900
Tejun Heo <htejun@gmail.com> wrote:

> The digit in the middle is the SPD limit and 0 means no limit.
> Hmm... wait, this is a hitachi disk.  Have you tried the feature
> tool?  Hitachi limits the spd of the harddrive tso 1.5 gbps, probably
> for compatibility reasons, and allows users to enable it with the
> feature tool.
> 
> http://www.hitachigst.com/hdd/support/download.htm#FeatureTool

That did it. Thank you very much Tejun. I promise I'll be looking for
such a tool next time before I bother any of the kernel related
mailinglists. My Hitachi is now officially running at 3.0Gbps .. and I
even managed to enable some of the other features (Accustic Management
and Power Management).

As a sidenote: Hitachi also provides bootable CD images. Very
convenient!

> > Given your patch though .. your git-based code looks much simpler. I
> > wonder if that is a good or a bad thing and wether I should try a
> > more recent kernel .. (?)
> 
> The patch was pulled from libata devel tree.  I was being lazy again
> and didn't test it on 2.6.16.14.  :p  However, I can assure you
> libata doesn't play much role in PHY spd configuration.

Nevermind here, I'm a long term C lover .. so it wasn't all that
complicated to adjust the patch. Besides, you've been very kind in
providing a patch at least .. since otherwise I'd have to dig one up
myself (and I am lazy as well ;-).

Thanks again.

Regards,

Moritz

Re: Issues with AHCI and SATAII using JMD360

[Moritz Heiber]

On Sun, 07 May 2006 14:14:08 +0200
Mogens Valentin <mogensv@vip.cybercity.dk> wrote:

> You could try the config with MS, where AFAIK, it does SATA300 mode.
> You could try skimming forums on ocworkbench.com for info, as this is 
> kindof an asian homeforum, with JCM360 being designed by .tw Jmicron.

No Windows on this computer or anywhere nearby. Besides, I would need
to buy it beforehand ;-)

> Whatever, it may or may not be worth too much trouble. I'm thinking 
> JCM360 may have an unclear future, since AFAIK the later ULi chipsets 
> have native SATA 300 support, and nVidia bought ULi, perhaps to
> produce entry level chipsets (according to press).
> I was very interested in that same board, due to very good test
> results and features, but skipped it for the very JCM360 driver issue.
> Being a dirt cheap board, you could spend on a separate selected SATA 
> interface (to keep for the next board). The mobo certainly has enough 
> PCIx slots for that.

As I just wrote to the mailinglist, the Hitachi disk utilities did the
trick as Hitachi is actually enforcing the 1.5Gbps on the user which
is totally understandable and even a pretty good default given the
technical knowledge of most computer users.
 
> What's you overall experience with the board, WRT
> stability/performance?

I'm very pleased with it actually. All parts of the motherboard are
well supported under Linux. Sound, ethernet, chipset .. you name it.

The only issue I encountered which I wasn't able to fix out of pure
laziness and the availability of an 'easy way out' would be the sound.
Whenever I put a quasi-high load on the ethernet controller (6Mbps or
more) the onboard soundchip would crumble and stop the work. I could
reproduce it even .. without pointers to a possible solution though.

Anyway, I "fixed" that by using my old Zoltrix Nightingale PCI card
(cmipci chip .. pretty good value card .. better than Creative's) and
disabled the onboard sound. I'm sure the issue can be resolved .. if
you were to look into it more thoroughly of course.

Regards,

Moritz

PS: As I just recalled .. I wasn't able to get the sensor chip working
or even gather information about what kind of chip is used on the
motherboard.