From: "Marc Strämke" <marcstraemke.work@gmx.net>
To: linux-kernel@vger.kernel.org
Subject: Re: Problem accessing Sandisk CompactFlash Cards (Connected to the IDE bus)
Date: Mon, 30 Aug 2004 17:49:40 +0200 [thread overview]
Message-ID: <cgvi5l$t0d$1@sea.gmane.org> (raw)
In-Reply-To: <41333879.2040902@redhat.com>
> Tracing back through the code it looks to me like we get the ATA disk
> print in the event that this test in do_identify:
> /*
> * Check for an ATAPI device
> */
> if (cmd == WIN_PIDENTIFY) {
>
> that would explain why the drive_is_flashcard test is getting skipped,
> why setting removable is making no difference, and why your card is
> being identified as an ATA device. It looks as though the WIN_PIDENTIFY
> command is sent down to this routine from ide_probe_for_drive in this
> snip of code:
>
> /* if !(success||timed-out) */
> if (do_probe(drive, WIN_IDENTIFY) >= 2) {
> /* look for ATAPI device */
> (void) do_probe(drive, WIN_PIDENTIFY);
> }
Both Cards, the old and the new on dont get to the ATAPI probing (which
seems correct to me, or is compactflash an ATAPI device???)
>
> So it would seem that WIN_PIDENTIFY is issued only if a WIN_IDENTIFY
> command fails with an rc greater than 2. I would suggest instrumenting
WIN_IDENTIFY returns a rc of 0 (for success) with both the old and the
new card. Still the old ones gets detected as CFA!
One thing i did notice when tracing these functions, is that the new
card returns 0x44a in drive->id->config, while the old one returns
0x848a, according to the manual from
SanDisk(http://www.sandisk.com/pdf/industrial/ProdManualIndustrialGradeATAv2.6.pdf)
Should only be returned in memory mapped(cardbus/pc-card) mode, and not
in True IDE mode, which the card is appearently running, otherwise the
bios couldnt not boot from it, nor would the electrical interface be
compatible (if i get the manual right). That is imo why hdparm -I doesnt
detect the card as beein removable and Compactflash too, i looked as the
sourcode of hdparm, and it seems to read the ATA configuration registers
trough a proc file, and interpret it directly (without intervention of
the kernel).
So the data the does return indeed marks it as an ATA harddisk, and not
as a compactflash card, the real question then is why doesnt it work as
a harddisk, which according to the specifications it should? Iam not
really experienced in the ide stuff, so iam not sure what the
CompactFlash detection in linux changes in behaviour.
I can get the kernel to report it as a "CFA DISK Drive" in dmesg by
forcing the flags i mentioned before, but the error is exactly the same.
Thx for your help,
Marc
next prev parent reply other threads:[~2004-08-30 15:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-29 8:01 Problem accessing Sandisk CompactFlash Cards (Connected to the IDE bus) Marc Strämke
2004-08-29 13:38 ` Neil Horman
2004-08-29 16:06 ` Marc Strämke
2004-08-30 0:08 ` Neil Horman
2004-08-30 1:07 ` Marcelo Tosatti
2004-08-30 7:01 ` Marc Strämke
2004-08-30 14:23 ` Neil Horman
2004-08-30 15:49 ` Marc Strämke [this message]
2004-08-30 15:23 ` Alan Cox
2004-08-30 17:10 ` Neil Horman
2004-08-30 17:31 ` Marc Strämke
2004-08-30 13:04 ` Alan Cox
2004-08-30 7:12 ` Meelis Roos
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='cgvi5l$t0d$1@sea.gmane.org' \
--to=marcstraemke.work@gmx.net \
--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 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.