All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: Jan Gutter <jangutter@gmail.com>
Cc: Matthew Stapleton <matthew4196@gmail.com>, linux-ide@vger.kernel.org
Subject: Re: ICH7m problem using libata
Date: Tue, 16 Jan 2007 20:42:23 +0900	[thread overview]
Message-ID: <45ACBA1F.6030007@gmail.com> (raw)
In-Reply-To: <1168947105.14636.11.camel@laundromat.jangutter.com>

Jan Gutter wrote:
> On Tue, 2007-01-16 at 17:56 +0900, Tejun Heo wrote:
>> Matthew Stapleton wrote:
>>> Tejun Heo wrote:
>>>> Does the problem still persist?
> 
> Sorry for the delayed reply: Holidays attacked before I could apply the
> patch. 
> 
>> I got confused between your report and Jan's.  Yours (not so sure about
>> Jan's) seems to be drive firmware bug which hald was successful to
>> undiscover.  Does hald clear CDO_USE_FFLAGS using ioctl
>> CDROM_CLEAR_OPTIONS?  The failed commands seem to be from cdrom
>> open_for_data().  Considering general quality of ATAPI devices, I
>> wouldn't be too surprised if some device fails after hours of repeated
>> poll sequence containing READ_TOC and ALLOW_MEDIUM_REMOVAL.
> 
> Hmmm. I think I might have slightly different symptoms: Heavy disk use
> definitely causes the bug to appear more frequently. Compiling often
> causes it to kick in after about 15 minutes. I also get slightly
> different error messages.
> 
> With the latest patch set (2.6.19-gentoo-r4 + cocktail) the resets still
> occur, but at least the drive doesn't go down to PIO so soon anymore.
> I'll keep watching it for the rest of the day. Attached dmesg of the
> first hour or so. (If Evolution borks this mail, I'll resort to telnet and 
> SMTP ;-)
> 
> Thanks for the feedback, and hope the sucker gets nailed.

Can you try 2.6.20-rc5?  It has better error reporting and will tell us
which SCSI command is timing out.

-- 
tejun

  reply	other threads:[~2007-01-16 11:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-04 17:36 ICH7m problem using libata Jan Gutter
2006-12-20  0:18 ` Tejun Heo
2007-01-03  3:07   ` Matthew Stapleton
2007-01-03  3:44     ` Tejun Heo
2007-01-09 22:17       ` Matthew Stapleton
2007-01-15  5:20         ` Tejun Heo
2007-01-15 23:58           ` Matthew Stapleton
2007-01-16  8:56             ` Tejun Heo
2007-01-16 11:31               ` Jan Gutter
2007-01-16 11:42                 ` Tejun Heo [this message]
2007-01-16 13:53                   ` Jan Gutter
2007-01-17  5:11                     ` Tejun Heo
2007-01-17 13:25                       ` Jan Gutter
2007-01-17 13:41                         ` Tejun Heo
2007-01-18  2:13                           ` Matthew Stapleton
  -- strict thread matches above, loose matches on Subject: below --
2006-12-19  0:40 Matthew Stapleton
2007-01-16 14:11 Mikael Pettersson
2007-01-16 14:51 ` Jan Gutter

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=45ACBA1F.6030007@gmail.com \
    --to=htejun@gmail.com \
    --cc=jangutter@gmail.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=matthew4196@gmail.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 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.