linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.


             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).