[lkml]   [2006]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCHSET] block: fix PIO cache coherency bug
    On Thu, 2 Mar 2006, Jens Axboe wrote:

    > On Thu, Mar 02 2006, Russell King wrote:
    > > On Thu, Mar 02, 2006 at 12:46:28PM -0600, James Bottomley wrote:
    > > > On Wed, 2006-02-22 at 17:27 +0900, Tejun Heo wrote:
    > > > > The objection raised by James Bottomley is that although syncing the
    > > > > kernel page is the responsbility of the driver, syncing user page is
    > > > > not; thus, use of flush_dcache_page() is excessive. James suggested
    > > > > use of flush_kernel_dcache_page().
    > > >
    > > > The problem is that it's not only excessive, it would entangle us with
    > > > mm locking. Basically, all you want to ensure is that the underlying
    > > > memory has the information after you've done (rather than the CPU
    > > > cache), flush_kernel_dcache_page() will achieve this. The block layer
    > > > itself takes care of user space coherency.
    > >
    > > Your understanding of the problem on ARM remains fundamentally flawed.
    > > I see no way to resolve this since you don't seem to listen or accept
    > > my reasoning.
    > >
    > > Therefore, message I'm getting from you is that we are not allowed to
    > > have an ARM system which can possibly work correctly with PIO.
    > >
    > > As a result, I have no further interest in trying to resolve this issue,
    > > period. ARM people will just have to accept that PIO mode IDE drivers
    > > just will not be an option.
    > Hey Russell calm down, lets get this thing fixed in the easiest and
    > least intrusive way for 2.6.17. As mentioned before, this isn't actually
    > a new problem by any stretch, a 2.6.17 solution would be acceptable to
    > you I hope.

    Has any discussion about this problem lead to some consensus?

    > What do you think of the kmap_atomic_pio() (notoriously bad at names,
    > but it should get the point across) and kunmap_atomic_pio(), the latter
    > accepting a read/write flag to note if we wrote to a vm page?
    > This is basically Tejuns original patch set, just moving it out of the
    > block layer so it's a generel exported property of the kmap api.

    What was the problem with Tejun's patchset already to which RMK (and
    many others) agreed?

    I do have hardware that exhibits the problem and therefore I wish the
    discussion could be resumed.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-05-29 21:20    [W:0.021 / U:0.236 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site