On Mon, Jan 21 2002, Andre Hedrick wrote:
> 255 * 512bytes != 128K BUG
> 256 * 512bytes == 128K
>
> You insure we will fail on alignemnt.
>
> You have stated BLOCK can not deal with correct sector alignments, and
> thus 255 so please fix it first. I have accepted this brokeness in BLOCK
> and dropped to 128 sectors or a clean 64k.
What statement? The block layer gives you the allignment that _you_
need. Heck, all you have to do is make a simple api call and define your
rules. Nobody is trying to cram anything down your throat. 255 is just
the kernel default, nothing more.
> If we restrict multi-sector PIO to 8 sectors we can do multi interrupt
> ATOMIC disk IO on the paging alignments, but you have enforced single
> sector IO in the multi-sector writing and can not see the difference.
False, I've enforced current_nr_sectors transfers in multi-sector write.
But Andre please understand that changes like this are never final, feel
free to alter it and make it work any other way. Fact is, we needed a
change that made pio and multi mode _work_ right now -- my change does
that, and it's not all that bad.
> If rq->current_nr_sectors is less than 8 we do PIO single sector IO, but
> we are doing that now w/ the copy paste changes from the old ide-disk.c
> stuff that we are attempting deleting.
Well I'm sorry for making changes to your isr's, but they were broken.
> You are making mistakes left and right because you think you understand
> the hardware. I thought we had an agreement, BLOCK stops at DO_REQUEST.
> Now you are altering the driver core, and the ISR's. BLOCK has no
> business in dictating how to talk to the hardware, especially since it
> violates the specification willfully and without need.
?! I can't do anything but block stuff now, what a pity. Please tell me
where the block layer is dictating what you must do.
> We do a DMA of two PRD's of 128 sectors and 127 sectors, thus a mess.
I can add a
BUG_ON(rq->nr_sectors == 255);
for you if you want, that will not happen.
> So at this point pull it and put back the munge for before and I will fix
> it completely and return a turn-key, now that I understand the brokeness
> of the interface I am deal w/ on both sides.
What is broken?
> Until you understand the execution of the command block is ATOMIC it will
> never work. Also when the SCSI-MID Layer is deleted, you will have a
> repeat of this issue on a much grander scale. Eric was a brilliant to
> hide the nature of the transport layer in the SCSI-MID Layer and return
> back partial completion against his ATOMIC Command IO calls.
Oh like the partial completion I added in ide_end_request?
Please calm down Andre, lets not start another round of flames.
-- Jens Axboe- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jan 23 2002 - 21:00:52 EST