diff options
author | André Fabian Silva Delgado <emulatorman@parabola.nu> | 2016-10-22 19:31:08 -0300 |
---|---|---|
committer | André Fabian Silva Delgado <emulatorman@parabola.nu> | 2016-10-22 19:31:08 -0300 |
commit | 670027c507e99521d416994a18a498def9ef2ea3 (patch) | |
tree | 74b4d761a9e7904a4f8aa4b58b2dc9801f22284d /Documentation/video4linux/bttv/README.freeze | |
parent | d0b2f91bede3bd5e3d24dd6803e56eee959c1797 (diff) |
Linux-libre 4.8.3-gnupck-4.8.3-gnu
Diffstat (limited to 'Documentation/video4linux/bttv/README.freeze')
-rw-r--r-- | Documentation/video4linux/bttv/README.freeze | 74 |
1 files changed, 0 insertions, 74 deletions
diff --git a/Documentation/video4linux/bttv/README.freeze b/Documentation/video4linux/bttv/README.freeze deleted file mode 100644 index 5eddfa076..000000000 --- a/Documentation/video4linux/bttv/README.freeze +++ /dev/null @@ -1,74 +0,0 @@ - -If the box freezes hard with bttv ... -===================================== - -It might be a bttv driver bug. It also might be bad hardware. It also -might be something else ... - -Just mailing me "bttv freezes" isn't going to help much. This README -has a few hints how you can help to pin down the problem. - - -bttv bugs ---------- - -If some version works and another doesn't it is likely to be a driver -bug. It is very helpful if you can tell where exactly it broke -(i.e. the last working and the first broken version). - -With a hard freeze you probably doesn't find anything in the logfiles. -The only way to capture any kernel messages is to hook up a serial -console and let some terminal application log the messages. /me uses -screen. See Documentation/serial-console.txt for details on setting -up a serial console. - -Read Documentation/oops-tracing.txt to learn how to get any useful -information out of a register+stack dump printed by the kernel on -protection faults (so-called "kernel oops"). - -If you run into some kind of deadlock, you can try to dump a call trace -for each process using sysrq-t (see Documentation/sysrq.txt). -This way it is possible to figure where *exactly* some process in "D" -state is stuck. - -I've seen reports that bttv 0.7.x crashes whereas 0.8.x works rock solid -for some people. Thus probably a small buglet left somewhere in bttv -0.7.x. I have no idea where exactly, it works stable for me and a lot of -other people. But in case you have problems with the 0.7.x versions you -can give 0.8.x a try ... - - -hardware bugs -------------- - -Some hardware can't deal with PCI-PCI transfers (i.e. grabber => vga). -Sometimes problems show up with bttv just because of the high load on -the PCI bus. The bt848/878 chips have a few workarounds for known -incompatibilities, see README.quirks. - -Some folks report that increasing the pci latency helps too, -althrought I'm not sure whenever this really fixes the problems or -only makes it less likely to happen. Both bttv and btaudio have a -insmod option to set the PCI latency of the device. - -Some mainboard have problems to deal correctly with multiple devices -doing DMA at the same time. bttv + ide seems to cause this sometimes, -if this is the case you likely see freezes only with video and hard disk -access at the same time. Updating the IDE driver to get the latest and -greatest workarounds for hardware bugs might fix these problems. - - -other ------ - -If you use some binary-only yunk (like nvidia module) try to reproduce -the problem without. - -IRQ sharing is known to cause problems in some cases. It works just -fine in theory and many configurations. Neverless it might be worth a -try to shuffle around the PCI cards to give bttv another IRQ or make -it share the IRQ with some other piece of hardware. IRQ sharing with -VGA cards seems to cause trouble sometimes. I've also seen funny -effects with bttv sharing the IRQ with the ACPI bridge (and -apci-enabled kernel). - |