From: Gleb Natapov <gleb@redhat.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Hannes Reinecke <hare@suse.de>,
LKML <linux-kernel@vger.kernel.org>,
"H. Peter Anvin" <hpa@linux.intel.com>
Subject: Re: [PATCH] EDD: Check for correct EDD 3.0 length
Date: Tue, 15 May 2012 17:48:10 +0300 [thread overview]
Message-ID: <20120515144810.GE6948@redhat.com> (raw)
In-Reply-To: <20120515153614.4b5b4525@pyramind.ukuu.org.uk>
On Tue, May 15, 2012 at 03:36:14PM +0100, Alan Cox wrote:
> On Tue, 15 May 2012 17:21:29 +0300
> Gleb Natapov <gleb@redhat.com> wrote:
>
> > On Tue, May 15, 2012 at 03:18:49PM +0100, Alan Cox wrote:
> > > On Tue, 15 May 2012 17:12:14 +0300
> > > Gleb Natapov <gleb@redhat.com> wrote:
> > >
> > > > On Tue, May 15, 2012 at 02:49:45PM +0100, Alan Cox wrote:
> > > > > > I do not see support for other spec to be important, but you are welcome
> > > > > > to write support for it if you need it. The only way I see to check what
> > > > > > spec edd info corresponds to is to calculate checksum according to both
> > > > > > specs and see which one succeeds.
> > > > >
> > > > > No it doesn't work like that. This is a regression for existing working
> > > > > systems. It needs to be reverted or fixed. If it was a new feature you'd
> > > > > have a point - but it isn't. You've broken stuff, undo the breakage.
> > > > >
> > > > Code never supported anything but EDD4.0 spec. I checked history git.
> > > > Code erroneously tried to interpret EDD3.0 info according to EDD4.0 spec
> > > > providing garbage as a result.
> > >
> > > Providing some valid data and info, which has now disappeared.
> > >
> > False. See my other mail:
> >
> > # cat /sys/firmware/edd/int13_dev80/interface
> > SCSI id: 0 lun: 1224979098644774912
> >
> > This is what I got on my system. How is it useful?
>
> Sample case of .. 1
>
Not one. Any system with SCSI disk. Revert the patch and check on yours.
> Have you checked how the various distribution grub installers and the
> like respond to the various changes or having bits of their edd data
> vanish mysteriously ?
>
That's how I entered this mess in the first place. Fedora/RHEL installer
didn't check edd info at all (no wonder, it was useless). It used mbr
signature to match HDD to int13. For vitalization this approach does not
work since usually disk images are unformatted, so I wanted to use EDD
info. That is when I found this bug and that phoenix EDD3 does not
provide enough info to match even basic things like ATA or SCSI.
> It's been this way for a long time, there is no rush to fix it. So we
> should fix it properly not break stuff.
>
> Actual systems in the field are using both 3.0 and 4.0 so we need to deal
> with that as part of fixing this. That is the reality of the situation.
Again let me correct myself. This is not about 3.0 versus 4.0. This is
about Phoenix vs T13 spec. The code was written to support only T13.
>
> 1.1 I suspect we can not care about.
>
> Alan
--
Gleb.
next prev parent reply other threads:[~2012-05-15 14:48 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-15 11:04 [PATCH] EDD: Check for correct EDD 3.0 length Hannes Reinecke
2012-05-15 11:12 ` Gleb Natapov
2012-05-15 11:20 ` Hannes Reinecke
2012-05-15 11:59 ` Gleb Natapov
2012-05-15 12:53 ` Gleb Natapov
2012-05-15 13:49 ` Alan Cox
2012-05-15 14:12 ` Gleb Natapov
2012-05-15 14:18 ` Alan Cox
2012-05-15 14:21 ` Gleb Natapov
2012-05-15 14:36 ` Alan Cox
2012-05-15 14:48 ` Gleb Natapov [this message]
2012-05-15 14:54 ` Alan Cox
2012-05-15 15:00 ` Gleb Natapov
2012-05-15 14:00 ` Alan Cox
2012-05-15 14:36 ` Gleb Natapov
2012-05-15 14:52 ` Alan Cox
2012-05-15 14:53 ` Gleb Natapov
2012-05-15 15:22 ` Alan Cox
2012-05-15 15:29 ` Gleb Natapov
2012-05-15 15:41 ` Alan Cox
2012-05-15 15:53 ` Gleb Natapov
2012-05-15 15:14 ` Alan Cox
2012-05-15 15:31 ` Alan Cox
2012-05-15 15:46 ` Gleb Natapov
2012-05-15 17:17 ` H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2012-05-16 6:51 Hannes Reinecke
2012-05-16 8:28 ` Gleb Natapov
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=20120515144810.GE6948@redhat.com \
--to=gleb@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hare@suse.de \
--cc=hpa@linux.intel.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