From: Andries.Brouwer@cwi.nl
To: Andries.Brouwer@cwi.nl, B.Zolnierkiewicz@elka.pw.edu.pl
Cc: alan@lxorguk.ukuu.org.uk, andersen@codepoet.org,
linux-kernel@vger.kernel.org, marcelo@conectiva.com.br
Subject: Re: [PATCH] ide-disk.c rev 1.13 killed CONFIG_IDEDISK_STROKE
Date: Thu, 7 Aug 2003 13:23:07 +0200 (MEST) [thread overview]
Message-ID: <UTC200308071123.h77BN7x00083.aeb@smtp.cwi.nl> (raw)
From: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
> In order to be able to troubleshoot problems we need to be able
> to reconstruct the information involved.
What problems are we talking about? :-)
I am happy that you think there are no problems.
I spent a considerable time eliminating.
On the other hand, if you don't know from experience
then a simple google search will tell you that this
has been a very painful area in the past.
> One part is the disk identity info that existed at boot time.
> It was read by the kernel, and stored. It is returned by the
> HDIO_GET_IDENTIFY ioctl, as used in e.g. hdparm -i.
>
> There is also the current disk identity info.
> It is found by asking the disk now, and is returned by e.g. hdparm -I.
What is a value of having these two identities
It helps a little in two ways. One, to help people with fdisk/LILO/..
disk geometry problems. Two, to investigate new disks.
It is good to have clean data.
Long ago distributions contained privately modified versions of packages.
Today they use rpms where the pristine sources and the patches are
clearly visible. Much better.
> Second: if we ask the disk for identity again, you'll see that
> more than this single field was changed.
We are updating drive->id for changing DMA modes,
should this be "fixed" as well?
Yes.
drive->id is what the drive says it can do.
If the kernel is satisfied with that then it just uses this data.
If the kernel is of the opinion that it also has to check
what kind of cable, and what kind of controller, then it
does not change drive->id->* but determines the mode it wants to use
and writes that to drive->*.
Moreover, drive->id tells you the situation after the BIOS did its setup.
Sometimes the BIOS knows things the kernel doesnt know. It is good to
have the information. Destroying information serves no useful purpose.
> > So, the clean way is to examine what the disk reported,
> > never change it
>
> Even if disk's info changes? I don't think so.
>
> Yes. The disk geometry data that we use is drive->*
> What the disk reported to us is drive->id->*.
This is a contradiction if geometry of disk was changed cause
disk reported to us geometry data second time.
I am not sure I can parse that.
Andries
-----
>From "man hdparm"
-i Display the identification info that was obtained
from the drive at boot time, if available.
-I Request identification info directly from the
drive.
next reply other threads:[~2003-08-07 11:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-07 11:23 Andries.Brouwer [this message]
2003-08-07 11:49 ` [PATCH] ide-disk.c rev 1.13 killed CONFIG_IDEDISK_STROKE Bartlomiej Zolnierkiewicz
-- strict thread matches above, loose matches on Subject: below --
2003-08-07 13:22 Andries.Brouwer
2003-08-07 13:50 ` Bartlomiej Zolnierkiewicz
2003-08-07 9:57 Andries.Brouwer
2003-08-07 10:44 ` Bartlomiej Zolnierkiewicz
2003-08-07 1:59 Andries.Brouwer
[not found] <20030806181142.GD25910@codepoet.org>
2003-08-06 18:32 ` Bartlomiej Zolnierkiewicz
2003-08-06 19:30 ` Erik Andersen
2003-08-06 19:58 ` Bartlomiej Zolnierkiewicz
2003-08-07 1:11 ` Andries Brouwer
2003-08-07 2:31 ` Bartlomiej Zolnierkiewicz
2003-08-02 12:45 Andries Brouwer
2003-08-02 13:10 ` Bartlomiej Zolnierkiewicz
2003-08-02 17:42 ` Andries Brouwer
2003-08-02 21:06 ` Alan Cox
2003-08-02 23:34 ` [PATCH] " Erik Andersen
2003-08-03 1:26 ` Andries Brouwer
2003-08-03 2:12 ` Erik Andersen
2003-08-03 9:52 ` Jens Axboe
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=UTC200308071123.h77BN7x00083.aeb@smtp.cwi.nl \
--to=andries.brouwer@cwi.nl \
--cc=B.Zolnierkiewicz@elka.pw.edu.pl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andersen@codepoet.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
/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).