> > 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.
Without your fix any attempts to capture send my machine to hell very
quickly, with memory and/or filesystem corruption as results. Some sort of
fix needs to go in, as the current driver is pretty useless for capture.
later,
Andrew
-
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/