From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Linas Vepstas <linas@austin.ibm.com>
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [BUG] ide dma_timer_expiry, then hard lockup
Date: Fri, 29 Jun 2007 22:52:53 +0400 [thread overview]
Message-ID: <46855505.1070702@ru.mvista.com> (raw)
In-Reply-To: <467BED34.4080004@ru.mvista.com>
Hello, I wrote:
>> I've got a hard lockup in the ide subsystem, probably
>> due to some irq spew or something like that.
>> I've just bought a brand new Maxtor 320GB disk driver for the insane
>> price of $70 US to replace another failing drive. It works well under
>> light load;
>> I was able to copy about 60GB to it. However, under heavy load, such
>> as reconstruction of an MD RAID-1 array, it'll lock up the kernel.
>> Which means
>> that my system won't boot :-(
>> I'm running 2.6.21.1, although the problem seems to occur in 2.6.19
>> and 2.6.18 too; its been there a while; I vageuly
>> remember similar problems in 2.6.5 or 2.6.10.
> Ah... so you're saying that the old disk works OK, yet you've already
> observed alike behavior on other disks... That speaks against
> blacklisting the drive.
I'm going to shortly post the patches blacklisting the drive and using the
proper HPT36x enablebits (as much as this stupid design may be fixed :-)...
Please test.
>> I can get the system to boot by sneaking in an "hdparm -d0 /dev/hdc"
>> early in the boot process, to turn off
> Could probably do the same trick and specify the lower DMA speed by
> using -X n option (where n ranges from 64 to 70 for UltraDMA modes 0 to
> 6) and see if it changes anything...
Note that for the hpt366.c driver, this is also achievable by setting
HPT366_ALLOW_ATA66_[34] to 0 and recompiling. It will limit its UltraDMA
capabilities to modes 2 or 3.
MBR, Sergei
prev parent reply other threads:[~2007-06-29 18:51 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-18 17:57 [BUG] ide dma_timer_expiry, then hard lockup Linas Vepstas
2007-06-18 18:11 ` Stuart_Hayes
2007-06-19 14:07 ` Sergei Shtylyov
2007-06-19 15:05 ` Linas Vepstas
2007-06-19 16:10 ` Sergei Shtylyov
2007-06-19 16:48 ` Linas Vepstas
2007-06-19 18:43 ` Bartlomiej Zolnierkiewicz
2007-06-19 20:07 ` Sergei Shtylyov
2007-06-20 16:28 ` Linas Vepstas
2007-06-20 17:01 ` Alan Cox
2007-06-21 17:58 ` Sergei Shtylyov
2007-06-21 21:41 ` Alan Cox
2007-06-21 19:47 ` Linas Vepstas
2007-06-21 22:04 ` Alan Cox
2007-06-18 20:27 ` Alan Cox
2007-06-18 20:46 ` Linas Vepstas
2007-06-18 21:04 ` Alan Cox
2007-06-18 21:22 ` Linas Vepstas
2007-06-19 14:56 ` bug in libata [was " Linas Vepstas
2007-06-19 14:10 ` Sergei Shtylyov
2007-06-19 14:19 ` Alan Cox
2007-06-19 14:24 ` Sergei Shtylyov
2007-06-19 15:38 ` Mark Lord
2007-06-19 15:51 ` Sergei Shtylyov
2007-06-19 16:17 ` Alan Cox
2007-06-19 16:32 ` Sergei Shtylyov
2007-06-22 15:39 ` Sergei Shtylyov
2007-06-29 18:52 ` Sergei Shtylyov [this message]
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=46855505.1070702@ru.mvista.com \
--to=sshtylyov@ru.mvista.com \
--cc=linas@austin.ibm.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 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).