From: Paul Blazejowski <paulb@blazebox.homeip.net>
To: Lee Revell <rlrevell@joe-job.com>
Cc: LKML <linux-kernel@vger.kernel.org>, linux-ide@vger.kernel.org
Subject: Re: Linux v2.6.16-rc6
Date: Sun, 12 Mar 2006 17:21:29 -0500 [thread overview]
Message-ID: <1142202089.9934.13.camel@blaze.homeip.net> (raw)
In-Reply-To: <1142199970.25358.173.camel@mindpipe>
[-- Attachment #1: Type: text/plain, Size: 4120 bytes --]
On Sun, 2006-03-12 at 16:46 -0500, Lee Revell wrote:
> On Sun, 2006-03-12 at 13:45 -0500, Paul Blazejowski wrote:
> > On recent kernel 2.6.15.6 (or any 2.6.15.x) and latest testing
> > 2.6.16-rc6 libata detects and sets wrong UDMA modes for one of the
> > SATA-1 drives. This seems to be a bug.
> >
> > My setup is as follows:
> >
> > ASUS A8N-SLI-Premium Nforce4 mainboard
> > AMD Athlon X2 CPU running SMP
> > GCC 3.3.6
> > Slackware 10.2 Linux
> >
> > The drives are used in RAID1 array (dmraid), they are WDC-WD2000JD
> > series purchased few months apart. Sata is compiled in the kernel as
> > module sata_nv and functions properly, no errors or any other anomalies
> > were noticed but the UDMA mode detection seem wrong on the second drive.
> >
> > Drive one reports ata3: dev 0 configured for UDMA/100 while drive two
> > ata4: dev 0 configured for UDMA/133
>
> This bug report is still somewhat unclear.
>
> What are the correct modes you expect to see?
>
> Lee
>
>
I belive the modes should say DMA100 because UDMA133 would be mode ATA-7
and DMA100 ATA-6 mode. This is the info i get from hdparm -I on the ata3
drive: DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
while on the ata4 one: DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3
udma4 udma5 *udma6
The thing is that the older drive is the one with the mode being set at
133 while the newer with mode 100. I belive they come from the same
factory but do carry different firmware revisons.
I also tried the drives on sata_sil (sil3114) controller and they show
the same modes being detected:
sata_sil 0000:05:0a.0: Applying R_ERR on DMA activate FIS errata fix
ata5: SATA max UDMA/100 cmd 0xF9402080 ctl 0xF940208A bmdma 0xF9402000
irq 23
ata6: SATA max UDMA/100 cmd 0xF94020C0 ctl 0xF94020CA bmdma 0xF9402008
irq 23
ata7: SATA max UDMA/100 cmd 0xF9402280 ctl 0xF940228A bmdma 0xF9402200
irq 23
ata8: SATA max UDMA/100 cmd 0xF94022C0 ctl 0xF94022CA bmdma 0xF9402208
irq 23
ata5: SATA link up 1.5 Gbps (SStatus 113)
ata5: dev 0 cfg 49:2f00 82:306b 83:7e01 84:4003 85:3068 86:3c01 87:4003
88:203f
ata5: dev 0 ATA-6, max UDMA/100, 390721968 sectors: LBA48
ata5: dev 0 configured for UDMA/100
scsi5 : sata_sil
ata6: SATA link up 1.5 Gbps (SStatus 113)
ata6: dev 0 cfg 49:2f00 82:346b 83:7f61 84:4003 85:3468 86:3c41 87:4003
88:207f
ata6: dev 0 ATA-6, max UDMA/133, 390721968 sectors: LBA48
ata6: dev 0 configured for UDMA/100
scsi6 : sata_sil
ata7: SATA link down (SStatus 0)
scsi7 : sata_sil
ata8: SATA link down (SStatus 0)
scsi8 : sata_sil
Vendor: ATA Model: WDC WD2000JD-60K Rev: 08.0
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb: sdb1 sdb2 sdb3 sdb4
sd 5:0:0:0: Attached scsi disk sdb
Vendor: ATA Model: WDC WD2000JD-00H Rev: 08.0
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
sdc: sdc1 sdc2 sdc3 sdc4
sd 6:0:0:0: Attached scsi disk sdc
I also see a difference with the transfer rates from hdparm -Tt:
ata3 drive (mode UDMA100) shows:
Timing buffered disk reads: 172 MB in 3.00 seconds = 57.30 MB/sec
while ata4 drive (mode UDMA133) shows:
Timing buffered disk reads: 118 MB in 3.03 seconds = 38.96 MB/sec
At this point is this due to drive capabilites in regards to modes
supported, broken drive? or libata code bug? I am trying to be as clear
as possible, anything else i should provide?
Thanks,
Paul B.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
next prev parent reply other threads:[~2006-03-12 22:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-12 18:45 Linux v2.6.16-rc6 Paul Blazejowski
2006-03-12 21:46 ` Lee Revell
2006-03-12 22:21 ` Paul Blazejowski [this message]
2006-03-12 22:57 ` Jeff Garzik
2006-03-13 20:17 ` Jan Engelhardt
2006-03-12 22:54 ` Jeff Garzik
2006-03-12 23:19 ` Paul Blazejowski
2006-03-16 21:58 ` Bill Davidsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1142202089.9934.13.camel@blaze.homeip.net \
--to=paulb@blazebox.homeip.net \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rlrevell@joe-job.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).