From: "Richard Smith" <ras2@tant.com>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Compact flash disk and slave drives in 2.4.2
Date: Tue, 27 Mar 2001 01:25:18 -0600 [thread overview]
Message-ID: <E14hnqw-0006sU-00@c4.tant.com> (raw)
I spent most of the day today trying to track down why the embedded system I am working
on would not recognize hdb on boot. It refused to show in the devices list even though I
specifically told the kernel it existed with the hdb=c,h,s option.
After working on what seemed like a hardware problem for quite a while I finally decided
that there must be something flaky in the ide driver code and began to add some debug
printk's
In which I found the following in ide.c:
/*
* CompactFlash cards and their brethern pretend to be removable hard disks,
* except:
* (1) they never have a slave unit, and
* (2) they don't have doorlock mechanisms.
* This test catches them, and is invoked elsewhere when setting appropriate
* config bits.
*
*/
Since hda in my system is a CompactFlash card I began to look further and then with some
discovered the following in ide-probe.c
/*
* Prevent long system lockup probing later for non-existant
* slave drive if the hwif is actually a flash memory card of some variety:
*/
if (drive_is_flashcard(drive)) {
ide_drive_t *mate = &HWIF(drive)->drives[1^drive->select.b.unit];
if (!mate->ata_flash) {
mate->present = 0;
ide_drive_t *mate = &HWIF(drive)->drives[1^drive->select.b.unit]
mate->noprobe = 1;
}
}
Now perhaps I am just way out on the wacky edge of things but I don't agree with the
above in the slightest. We use CF's in conjunction with slaves all the time. Almost all
of our embedded devices boot from CF's and I routinely add a HD as a slave to the system
to do developement with but it's always been under DOS.
I comment out the check above and all is well... hdb shows up as expected.
Can someone explain to me why the above check was added and if its continued existence is
necessary? Whats this long system lockup thing mentioned?
Even if there is some danger of a long lockup I suggest that at least a message that its
ignoring hdb is the least it could do rather than sliently ignoreing it. Especially when
I specifically told it a hdb existed via the command line. Shouldn't command line
parameters take precidence?
I not subscribed to the kernel-list so please copy me in the response.
Thanks.
--
Richard A. Smith ras2@tant.com
"I'd hang out with science kids - they can blow things up!
I mean, what's cooler than that?"
- Tori Amos
next reply other threads:[~2001-03-27 7:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-27 7:25 Richard Smith [this message]
2001-03-27 14:20 ` Padraig Brady
2001-03-27 16:42 ` Andre Hedrick
2001-03-27 17:06 ` Padraig Brady
2001-03-27 17:17 ` Andre Hedrick
2001-03-27 18:50 ` Padraig Brady
2001-03-27 18:56 ` Andre Hedrick
2001-03-27 19:25 ` Richard A. Smith
2001-03-27 20:15 ` Andre Hedrick
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=E14hnqw-0006sU-00@c4.tant.com \
--to=ras2@tant.com \
--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®