[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49973F4F.1010804@gmail.com>
Date: Sat, 14 Feb 2009 16:01:51 -0600
From: Robert Hancock <hancockrwd@...il.com>
To: linux-kernel@...r.kernel.org
Cc: linux-kernel@...r.kernel.org
Subject: Re: Intel ICH9M/M-E SATA error-handling/reset problems
Serguei Miridonov wrote:
> I have some problems with SATA in a new notebook PC (HP Pavilion dv5t,
> Intel chipset). Seagate FreeAgent Pro 1TB external drive practically
> can not be used with eSATA in Linux (fresh install from DVD Fedora 10,
> now fully updated), and yesterday I also had problem with DVD
> recording using internal HL-DT-ST BDDVDRW drive.
>
> More details in attachment.
>
> Both devices work with Windows Vista. Seagate external drive even in
> Vista produces "parity error" messages in Windows event log but OS is
> somehow recovering from these errors and continues to use the drive
> with slight slowdown (average speed varies between 60 and 110 MB/s).
> Of course, it could be cable/Seagate issue, but again - Vista can
> handle this.
There are a lot of issues with eSATA drives and cabling. As Jeff
mentioned, there are some changes in 2.6.29-rc that may improve the
behavior, but the root cause here is a hardware issue (you should not
expect very good behavior in Vista either with those errors).
As far as the DVD burning issue, it's hard to say for sure. It looks
like a write command was timing out. Could be due to your drive not
working well with that type of media.
>
> It appears that Linux kernel has problems with error-handling/reset of
> SATA hardware. I have found a lot of reports regarding SATA problems:
> data transfer failures, CD/DVD recording, waking up from suspend to
> RAM, etc. Aren't they all related? Can Linux SATA chipsets drivers
Not related at all, mostly.. though a lot of people seem to think they
are. Often times people think problems are related because the error
messages seem similar, and even the same error can be triggered by
numerous different problems, often not the fault of the kernel.
> properly reset hardware into predictable state? Sure, I could be wrong
> and my issue may have nothing to do with others... Any idea?
>
> Please, CC any reply to my e-mail.
> Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists