All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Bene Martin" <martin.bene@icomedias.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: linux-ide@vger.kernel.org, Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [SATA] libata-dev queue updated
Date: Tue, 7 Jun 2005 09:00:48 +0200	[thread overview]
Message-ID: <FA095C015271B64E99B197937712FD02510D0B@freedom.grz.icomedias.com> (raw)

> The two reasons why passthru is not upstream are:
> 
> * I need to make sure that it is 100% up-to-date for the latest ATA
> passthru spec, which clarified some SCSI CDB and descriptor codes.
> 
> * There was at least one report of ATA passthru use causing a device
> under load to start timing out, which could possibly indicate a driver
> bug. I need to do a serious analysis and final review of the patch, to
> make sure that it is plugged into the ATA host state machine at the
> correct places.

Just as a data point:

I've had a couple of problems on a system using sata+passthrough patch; 
not latest code though. I am reading smart info at fairly high frequency

(smartd + a smartctl call for each device every 5 minutes to graph drive
temperatures).

Versions used: 2.6.11.7 + 2.6.11-bk6-libata-dev1.patch.bz2

I got several ata errors, mostly in high - throughput situations (rsync 
over local network or rebuilding raid5), example from the logs:

Jun  5 04:13:50 backup kernel: ata3: command 0x25 timeout, stat 0x50
host_stat 0x1
Jun  5 06:30:51 backup kernel: ata3: command 0x35 timeout, stat 0x50
host_stat 0x1
Jun  5 10:46:50 backup kernel: ata3: command 0x35 timeout, stat 0x50
host_stat 0x1
Jun  5 10:47:20 backup kernel: ata3: command 0x35 timeout, stat 0x50
host_stat 0x1
Jun  5 10:53:45 backup kernel: ATA: abnormal status 0xD0 on port
0xE0802287
Jun  5 10:53:45 backup last message repeated 2 times
Jun  5 10:54:15 backup kernel: ata3: command 0x35 timeout, stat 0x50
host_stat 0x1
Jun  5 11:43:11 backup kernel: ATA: abnormal status 0xD0 on port
0xE0802287
Jun  5 11:43:11 backup last message repeated 2 times
Jun  5 11:43:41 backup kernel: ata3: command 0x35 timeout, stat 0x50
host_stat 0x1
Jun  5 14:23:45 backup kernel: ata3: command 0x35 timeout, stat 0x51
host_stat 0x1
Jun  5 14:23:45 backup kernel: ata3: status=0x51 { DriveReady
SeekComplete Error }
Jun  5 14:23:45 backup kernel: ata3: error=0x04 { DriveStatusError }
Jun  5 14:23:45 backup kernel: SCSI error : <3 0 0 0> return code =
0x8000002
Jun  5 14:23:45 backup kernel: sdc: Current: sense key: Aborted Command
Jun  5 14:23:45 backup kernel:     Additional sense: No additional sense
information
Jun  5 14:23:45 backup kernel: end_request: I/O error, dev sdc, sector
135917718
Jun  5 14:23:45 backup kernel: raid5: Disk failure on sdc6, disabling
device. Operation continuing on 2 devices

What makes me doubt the theory that smart/passthrough might be to blame 
is that I've only seen these errors on one of the 3 disks (always 
sdc/ata3). On the other hand, smart info for the drive doesn't show any 
errors or suspicious readings.

Boot log for the sata devices:

May 18 08:51:53 backup kernel: libata version 1.10 loaded.
May 18 08:51:53 backup kernel: sata_sil version 0.8
May 18 08:51:53 backup kernel: ACPI: PCI interrupt 0000:02:00.0[A] ->
GSI 21 (level, low) -> IRQ 21
May 18 08:51:53 backup kernel: ata1: SATA max UDMA/100 cmd 0xE0802080
ctl 0xE080208A bmdma 0xE0802000 irq 21
May 18 08:51:53 backup kernel: ata2: SATA max UDMA/100 cmd 0xE08020C0
ctl 0xE08020CA bmdma 0xE0802008 irq 21
May 18 08:51:53 backup kernel: ata3: SATA max UDMA/100 cmd 0xE0802280
ctl 0xE080228A bmdma 0xE0802200 irq 21
May 18 08:51:53 backup kernel: ata4: SATA max UDMA/100 cmd 0xE08022C0
ctl 0xE08022CA bmdma 0xE0802208 irq 21
May 18 08:51:53 backup kernel: ata1: dev 0 cfg 49:2f00 82:346b 83:7d01
84:4023 85:3469 86:3c01 87:4023 88:407f
May 18 08:51:53 backup kernel: ata1: dev 0 ATA-7, max UDMA/133,
781422768 sectors: LBA48
May 18 08:51:53 backup kernel: ata1: dev 0 configured for UDMA/100
May 18 08:51:53 backup kernel: scsi1 : sata_sil
May 18 08:51:53 backup kernel: ata2: dev 0 cfg 49:2f00 82:346b 83:7d01
84:4023 85:3469 86:3c01 87:4023 88:407f
May 18 08:51:53 backup kernel: ata2: dev 0 ATA-7, max UDMA/133,
781422768 sectors: LBA48
May 18 08:51:53 backup kernel: ata2: dev 0 configured for UDMA/100
May 18 08:51:53 backup kernel: scsi2 : sata_sil
May 18 08:51:53 backup kernel: ata3: dev 0 cfg 49:2f00 82:346b 83:7d01
84:4023 85:3469 86:3c01 87:4023 88:407f
May 18 08:51:53 backup kernel: ata3: dev 0 ATA-7, max UDMA/133,
781422768 sectors: LBA48
May 18 08:51:53 backup kernel: ata3: dev 0 configured for UDMA/100
May 18 08:51:53 backup kernel: scsi3 : sata_sil
May 18 08:51:53 backup kernel: ata4: no device found (phy stat 00000000)
May 18 08:51:53 backup kernel: scsi4 : sata_sil
May 18 08:51:53 backup kernel:   Vendor: ATA       Model: ST3400832AS
Rev: 3.01
May 18 08:51:53 backup kernel:   Type:   Direct-Access
ANSI SCSI revision: 05
May 18 08:51:53 backup kernel:   Vendor: ATA       Model: ST3400832AS
Rev: 3.01
May 18 08:51:53 backup kernel:   Type:   Direct-Access
ANSI SCSI revision: 05
May 18 08:51:53 backup kernel:   Vendor: ATA       Model: ST3400832AS
Rev: 3.01
May 18 08:51:53 backup kernel:   Type:   Direct-Access
ANSI SCSI revision: 05

SATA controller used:

0000:02:00.0 RAID bus controller: Silicon Image, Inc. SiI 3114
[SATALink/SATARaid] Serial ATA Controller (rev 02)

Bye, Martin

WARNING: multiple messages have this Message-ID (diff)
From: "Bene Martin" <martin.bene@icomedias.com>
To: "Jeff Garzik" <jgarzik@pobox.com>
Cc: <linux-ide@vger.kernel.org>,
	"Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: [SATA] libata-dev queue updated
Date: Tue, 7 Jun 2005 09:00:48 +0200	[thread overview]
Message-ID: <FA095C015271B64E99B197937712FD02510D0B@freedom.grz.icomedias.com> (raw)

> The two reasons why passthru is not upstream are:
> 
> * I need to make sure that it is 100% up-to-date for the latest ATA
> passthru spec, which clarified some SCSI CDB and descriptor codes.
> 
> * There was at least one report of ATA passthru use causing a device
> under load to start timing out, which could possibly indicate a driver
> bug. I need to do a serious analysis and final review of the patch, to
> make sure that it is plugged into the ATA host state machine at the
> correct places.

Just as a data point:

I've had a couple of problems on a system using sata+passthrough patch; 
not latest code though. I am reading smart info at fairly high frequency

(smartd + a smartctl call for each device every 5 minutes to graph drive
temperatures).

Versions used: 2.6.11.7 + 2.6.11-bk6-libata-dev1.patch.bz2

I got several ata errors, mostly in high - throughput situations (rsync 
over local network or rebuilding raid5), example from the logs:

Jun  5 04:13:50 backup kernel: ata3: command 0x25 timeout, stat 0x50
host_stat 0x1
Jun  5 06:30:51 backup kernel: ata3: command 0x35 timeout, stat 0x50
host_stat 0x1
Jun  5 10:46:50 backup kernel: ata3: command 0x35 timeout, stat 0x50
host_stat 0x1
Jun  5 10:47:20 backup kernel: ata3: command 0x35 timeout, stat 0x50
host_stat 0x1
Jun  5 10:53:45 backup kernel: ATA: abnormal status 0xD0 on port
0xE0802287
Jun  5 10:53:45 backup last message repeated 2 times
Jun  5 10:54:15 backup kernel: ata3: command 0x35 timeout, stat 0x50
host_stat 0x1
Jun  5 11:43:11 backup kernel: ATA: abnormal status 0xD0 on port
0xE0802287
Jun  5 11:43:11 backup last message repeated 2 times
Jun  5 11:43:41 backup kernel: ata3: command 0x35 timeout, stat 0x50
host_stat 0x1
Jun  5 14:23:45 backup kernel: ata3: command 0x35 timeout, stat 0x51
host_stat 0x1
Jun  5 14:23:45 backup kernel: ata3: status=0x51 { DriveReady
SeekComplete Error }
Jun  5 14:23:45 backup kernel: ata3: error=0x04 { DriveStatusError }
Jun  5 14:23:45 backup kernel: SCSI error : <3 0 0 0> return code =
0x8000002
Jun  5 14:23:45 backup kernel: sdc: Current: sense key: Aborted Command
Jun  5 14:23:45 backup kernel:     Additional sense: No additional sense
information
Jun  5 14:23:45 backup kernel: end_request: I/O error, dev sdc, sector
135917718
Jun  5 14:23:45 backup kernel: raid5: Disk failure on sdc6, disabling
device. Operation continuing on 2 devices

What makes me doubt the theory that smart/passthrough might be to blame 
is that I've only seen these errors on one of the 3 disks (always 
sdc/ata3). On the other hand, smart info for the drive doesn't show any 
errors or suspicious readings.

Boot log for the sata devices:

May 18 08:51:53 backup kernel: libata version 1.10 loaded.
May 18 08:51:53 backup kernel: sata_sil version 0.8
May 18 08:51:53 backup kernel: ACPI: PCI interrupt 0000:02:00.0[A] ->
GSI 21 (level, low) -> IRQ 21
May 18 08:51:53 backup kernel: ata1: SATA max UDMA/100 cmd 0xE0802080
ctl 0xE080208A bmdma 0xE0802000 irq 21
May 18 08:51:53 backup kernel: ata2: SATA max UDMA/100 cmd 0xE08020C0
ctl 0xE08020CA bmdma 0xE0802008 irq 21
May 18 08:51:53 backup kernel: ata3: SATA max UDMA/100 cmd 0xE0802280
ctl 0xE080228A bmdma 0xE0802200 irq 21
May 18 08:51:53 backup kernel: ata4: SATA max UDMA/100 cmd 0xE08022C0
ctl 0xE08022CA bmdma 0xE0802208 irq 21
May 18 08:51:53 backup kernel: ata1: dev 0 cfg 49:2f00 82:346b 83:7d01
84:4023 85:3469 86:3c01 87:4023 88:407f
May 18 08:51:53 backup kernel: ata1: dev 0 ATA-7, max UDMA/133,
781422768 sectors: LBA48
May 18 08:51:53 backup kernel: ata1: dev 0 configured for UDMA/100
May 18 08:51:53 backup kernel: scsi1 : sata_sil
May 18 08:51:53 backup kernel: ata2: dev 0 cfg 49:2f00 82:346b 83:7d01
84:4023 85:3469 86:3c01 87:4023 88:407f
May 18 08:51:53 backup kernel: ata2: dev 0 ATA-7, max UDMA/133,
781422768 sectors: LBA48
May 18 08:51:53 backup kernel: ata2: dev 0 configured for UDMA/100
May 18 08:51:53 backup kernel: scsi2 : sata_sil
May 18 08:51:53 backup kernel: ata3: dev 0 cfg 49:2f00 82:346b 83:7d01
84:4023 85:3469 86:3c01 87:4023 88:407f
May 18 08:51:53 backup kernel: ata3: dev 0 ATA-7, max UDMA/133,
781422768 sectors: LBA48
May 18 08:51:53 backup kernel: ata3: dev 0 configured for UDMA/100
May 18 08:51:53 backup kernel: scsi3 : sata_sil
May 18 08:51:53 backup kernel: ata4: no device found (phy stat 00000000)
May 18 08:51:53 backup kernel: scsi4 : sata_sil
May 18 08:51:53 backup kernel:   Vendor: ATA       Model: ST3400832AS
Rev: 3.01
May 18 08:51:53 backup kernel:   Type:   Direct-Access
ANSI SCSI revision: 05
May 18 08:51:53 backup kernel:   Vendor: ATA       Model: ST3400832AS
Rev: 3.01
May 18 08:51:53 backup kernel:   Type:   Direct-Access
ANSI SCSI revision: 05
May 18 08:51:53 backup kernel:   Vendor: ATA       Model: ST3400832AS
Rev: 3.01
May 18 08:51:53 backup kernel:   Type:   Direct-Access
ANSI SCSI revision: 05

SATA controller used:

0000:02:00.0 RAID bus controller: Silicon Image, Inc. SiI 3114
[SATALink/SATARaid] Serial ATA Controller (rev 02)

Bye, Martin

             reply	other threads:[~2005-06-07  7:00 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-07  7:00 Bene Martin [this message]
2005-06-07  7:00 ` [SATA] libata-dev queue updated Bene Martin
  -- strict thread matches above, loose matches on Subject: below --
2005-06-04  6:08 Jeff Garzik
2005-06-04 15:17 ` Greg Stark
2005-06-04 17:48   ` Jeff Garzik
2005-06-04 18:50     ` Adrian Bunk
2005-06-04 19:05       ` Jeff Garzik
2005-06-04 19:15         ` Greg Stark
2005-06-04 19:19           ` Jeff Garzik
2005-06-05  2:25             ` Greg Stark
2005-06-05  2:30               ` Jeff Garzik
2005-06-05  5:30                 ` Greg Stark
2005-06-22 16:15                 ` Mark Lord
2005-06-22 20:23                   ` Jeff Garzik
2005-06-23  3:39                     ` Mark Lord
2005-06-05  2:40               ` Drew Winstel
2005-06-05  2:58               ` Jim Crilly
2005-06-06 16:01   ` Mark Lord
2005-06-07  1:57     ` Greg Stark
2005-06-07 11:20       ` Brad Campbell
2005-06-08  8:33         ` Mark Lord
2005-06-07 13:15           ` Brad Campbell
2005-06-08  8:37       ` Mark Lord
2005-06-07 13:51         ` Greg Stark
2005-06-08 10:30           ` Mark Lord
2005-06-08  8:51       ` Mark Lord
2005-06-07 13:09         ` Domenico Andreoli
2005-06-07 17:53         ` Jeff Garzik
2005-03-10  5:40 Jeff Garzik
2005-03-29  9:12 ` kern.petr
2005-03-08 11:20 Jeff Garzik
     [not found] <3Ds62-5AS-3@gated-at.bofh.it>
2005-03-02 20:34 ` Joerg Sommrey
2005-03-02 22:43   ` Jeff Garzik
2005-03-03 19:32     ` Joerg Sommrey
2005-03-04  4:09       ` Jeff Garzik
2005-03-04  6:37         ` Joerg Sommrey
2005-03-04  7:10           ` Jeff Garzik
2005-03-04 17:49             ` Joerg Sommrey
2005-03-04 18:07               ` Jeff Garzik
2005-03-04 20:33                 ` Joerg Sommrey
2005-03-04 20:43                   ` Jeff Garzik
2005-03-04 22:06                     ` Joerg Sommrey
2005-03-04 22:32                       ` Joerg Sommrey
2005-03-02  2:40 Jeff Garzik
2005-02-19  8:40 Jeff Garzik
2005-02-19 16:58 ` Andre Tomt
2005-02-19 17:09   ` Jeff Garzik
2005-02-13 20:33 Jeff Garzik
2004-10-30 16:15 Jeff Garzik
2004-10-27  6:52 Jeff Garzik
2004-10-27  6:53 ` Jeff Garzik
2004-10-27 22:53 ` Rob van Nieuwkerk
2004-10-27 23:03   ` Jeff Garzik
2004-10-18 23:52 Jeff Garzik
2004-10-16  0:44 Jeff Garzik
2004-10-15  8:04 Jeff Garzik
2004-10-15 17:15 ` Jeff Garzik

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=FA095C015271B64E99B197937712FD02510D0B@freedom.grz.icomedias.com \
    --to=martin.bene@icomedias.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.