On Mon, 15 Feb 1999, Alan Cox wrote:

> > Now after four weeks of testing without any further mm/fs corruption,
> > I´m convinced that the problems have really gone away with the attached
> > patch. I just re-diffed it against 2.2.2-pre2, as the old one did
> > not apply cleanly. See my previous e-mail for reasoning and downsides
> > of the patch.
> 
> I've read your reasoning. I don't believe it is completely correct. That
> is why I haven't applied the patch. Reading through the chip manual in
> more detail I think the problem is not that it just happens to keep writing
> stuff until it closes the chip down but that the RISC instruction sequence
> isnt stopped instantly but prattles on into memory for a frame. If so you've
> merely fudged around most of the real problem

Yes, I know (for the corruption part) - but as it is a workaround for
the problem it seemed appropriate. A more appropriate(?) solution I
thought about was just let the closing process sleep for 40ms in
bttv_close - but this is ugly, too. I read the chip manual, too and
the grab-stop sequence in the driver meets the specs, but I rather
believe the symptoms than the specs :)
For the security reason, whats up with that?

Richard.

PS: the workaround (not fix) will stay in my personal tree until
    one comes up with a better solution to the problem. mm/fs
    corruption is not a minor problem.

--
Richard Guenther <richard.guenther@student.uni-tuebingen.de>
PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
WWW: http://www.anatom.uni-tuebingen.de/~richi/


-- 
         To unsubscribe: mail video4linux-list-request@redhat.com with 
                       "unsubscribe" as the Subject.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/