From: "Neil Conway" <nconway_kernel@yahoo.co.uk>
To: linux-kernel@vger.kernel.org
Subject: PATCH, IDE corruption, 2.4.18
Date: Fri, 3 May 2002 21:36:23 +0100 (BST) [thread overview]
Message-ID: <20020503203623.25862.qmail@web21503.mail.yahoo.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]
Well, I say patch, but it's really a band-aid.
[Caveats: before reading further, understand that I'm
not by any means an IDE expert; I have just figured
out how to prevent disk corruption on my PC. I may
have completely missed the point.]
While debugging some "0x58" status errors (which I
believed to have lead to disk corruption) I discovered
that ide_config_drive_speed() uses SELECT_DRIVE
without checking to see if there are disk transfers in
progress (by definition these have to be DMA
transfers). Unless I've misread the ATA specs, this
is a Very Bad Thing.
This means that when modules which call
ide_register_subdriver() are loaded (so far I think
it's just ide-cd and ide-scsi) any disk transfers in
progress on the other half of the cable are stuffed.
This is very easy to reproduce: just do a "dd
if=/dev/hda of=/dev/null" and a few of "rmmod
ide-cd;modprobe ide-cd" (where there must be a CD on
hdb, or hdc and hdd but you get the idea). On my box,
this is about 80% successful each module-load at
causing the "0x58" status error. Repeated usage
trashes inodes (don't know why) and even causes
lockups (don't know why either). This suggests that
the error-recovery doesn't work very well...
Anyway, here's the band aid as promised. A timeout,
or a queued request would be better, but I'm not sure
of how best to do either, so at least now the real
experts can fix it properly...
cheers
Neil
PS: don't know (but doubt it) if this is what caused
the 0x58 problems in 2.2 etc.
PPS: I'm off-list at present, so please CC me if you
want me to notice responses.
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
[-- Attachment #2: ide_patch030502 --]
[-- Type: application/x-unknown, Size: 706 bytes --]
next reply other threads:[~2002-05-03 20:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-03 20:36 Neil Conway [this message]
2002-05-03 20:39 Neil Conway
2002-05-04 12:15 Neil Conway
2002-05-04 22:58 ` Andre Hedrick
2002-05-05 2:10 ` Neil Conway
2002-05-05 0:22 ` Mike Fedyk
2002-05-05 0:47 ` Andre Hedrick
2002-05-05 1:54 ` Neil Conway
2002-05-05 7:36 ` Mike Fedyk
2002-05-05 9:44 ` Neil Conway
2002-05-05 15:49 Bartlomiej Zolnierkiewicz
2002-05-05 15:04 ` Martin Dalecki
2002-05-05 20:44 ` Neil Conway
2002-05-06 0:23 ` Mike Fedyk
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=20020503203623.25862.qmail@web21503.mail.yahoo.com \
--to=nconway_kernel@yahoo.co.uk \
--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
all inboxes | Powered by JetHome®