From: Jens Axboe <axboe@suse.de>
To: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] 2.5 ide 48-bit usage
Date: Thu, 8 May 2003 15:23:14 +0200 [thread overview]
Message-ID: <20030508132314.GZ823@suse.de> (raw)
In-Reply-To: <Pine.SOL.4.30.0305081502430.12362-100000@mion.elka.pw.edu.pl>
On Thu, May 08 2003, Bartlomiej Zolnierkiewicz wrote:
>
> On Thu, 8 May 2003, Jens Axboe wrote:
>
> > n Thu, May 08 2003, Bartlomiej Zolnierkiewicz wrote:
> > > if (!hwif->rqsize)
> > > hwif->rqsize = hwif->addressing ? 65536 : 256;
> >
> > btw, you didn't get this right this time either :-)
>
> It is right.
> hwif->addressing means hwif supports 48-bit
No it doesn't, that's what I keep saying:
static int probe_lba_addressing (ide_drive_t *drive, int arg)
{
drive->addressing = 0;
if (HWIF(drive)->addressing)
return 0;
...
so if hwif->addressing != 0, you will never allow 48-bit lba on any
units on this hardware interface. So the correct logic is:
hwif->rqsize = hwif->addressing ? 256 : 65536;
as in the patch.
> hwif->rqsize means max rq size for _hwif_
Correct.
> > drive->addressing == 1, 48-bit is ok
> > hwif->addressing == 1, 48-bit is _not_ ok
>
> And?
> Even if !drive->addressing, hwif->addressing can be 1,
If hwif->addressing == 1, drive->addressing will never be anything _but_
0.
> so hwif->rqsize can be 65536.
Wrong
> > below patch covers the lat change as well, boots and works on my router.
>
> Patch still misses pdx202xx_old.c changes :-).
Which?
> Two new ones:
> - rq_lba48(rq) should check for rq->hard_* values
Doesn't matter. I actually only thought about dma, in which case it
doesn't matter because we never change sector or nr_sectors until after
we have called ide_dma_end. For pio, it's no more reliable with hard_*
than without. This is all for end_request context of course, at init
time it's all the same. Essentially, we _need_ the taskfile changes for
this to work. In that case we can limit rq_lba48() to init request time,
and set task->addressing and use that from then on.
> - after some thought, drop _all_ changes to ide_dump_status()
> (we may hit error when rq->nr_sectors is already < 256)
Ditto, cannot be reliable without the taskfile changes.
I won't bother with anything new until the taskfile stuff is in.
--
Jens Axboe
next prev parent reply other threads:[~2003-05-08 13:11 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-07 8:49 [PATCH] 2.5 ide 48-bit usage Jens Axboe
2003-05-07 16:28 ` Linus Torvalds
2003-05-07 16:46 ` Jens Axboe
2003-05-07 17:15 ` Linus Torvalds
2003-05-07 17:33 ` Jens Axboe
2003-05-07 17:42 ` Linus Torvalds
2003-05-07 17:50 ` Jens Axboe
2003-05-07 19:58 ` Bartlomiej Zolnierkiewicz
2003-05-07 20:19 ` Jens Axboe
2003-05-08 7:56 ` Jens Axboe
2003-05-08 11:01 ` Alan Cox
2003-05-08 12:01 ` Jens Axboe
2003-05-12 21:41 ` Mike Fedyk
2003-05-13 6:44 ` Jens Axboe
2003-05-08 11:34 ` Bartlomiej Zolnierkiewicz
2003-05-08 11:59 ` Jens Axboe
2003-05-08 12:20 ` Bartlomiej Zolnierkiewicz
2003-05-08 12:26 ` Jens Axboe
2003-05-08 12:36 ` Jens Axboe
2003-05-08 13:16 ` Bartlomiej Zolnierkiewicz
2003-05-08 13:23 ` Jens Axboe [this message]
2003-05-08 13:35 ` Bartlomiej Zolnierkiewicz
2003-05-08 13:37 ` Jens Axboe
2003-05-08 14:47 ` Jens Axboe
2003-05-08 14:51 ` Jens Axboe
2003-05-08 14:46 ` Alan Cox
2003-05-08 15:49 ` Bartlomiej Zolnierkiewicz
2003-05-08 16:16 ` Jens Axboe
2003-05-08 16:27 ` Linus Torvalds
2003-05-08 16:34 ` Jens Axboe
2003-05-08 16:59 ` Bartlomiej Zolnierkiewicz
2003-05-09 7:40 ` Jens Axboe
2003-05-08 22:06 ` Alan Cox
2003-05-09 7:06 ` Jens Axboe
2003-05-09 8:28 ` [PATCH][RFC] Sanitize hwif/drive addressing (was Re: [PATCH] 2.5 ide 48-bit usage) Jens Axboe
2003-05-09 11:07 ` Bartlomiej Zolnierkiewicz
2003-05-09 12:03 ` Jens Axboe
2003-05-07 21:45 ` [PATCH] 2.5 ide 48-bit usage Henning P. Schmiedehausen
2003-05-07 22:03 ` Alan Cox
2003-05-07 22:55 ` H. Peter Anvin
2003-05-07 18:29 ` Alan Cox
2003-05-07 19:30 ` 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=20030508132314.GZ823@suse.de \
--to=axboe@suse.de \
--cc=B.Zolnierkiewicz@elka.pw.edu.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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.