| Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | |
| 2 | If the box freezes hard with bttv ... |
| 3 | ===================================== |
| 4 | |
| 5 | It might be a bttv driver bug. It also might be bad hardware. It also |
| 6 | might be something else ... |
| 7 | |
| 8 | Just mailing me "bttv freezes" isn't going to help much. This README |
| 9 | has a few hints how you can help to pin down the problem. |
| 10 | |
| 11 | |
| 12 | bttv bugs |
| 13 | --------- |
| 14 | |
| 15 | If some version works and another doesn't it is likely to be a driver |
| 16 | bug. It is very helpful if you can tell where exactly it broke |
| 17 | (i.e. the last working and the first broken version). |
| 18 | |
| 19 | With a hard freeze you probably doesn't find anything in the logfiles. |
| 20 | The only way to capture any kernel messages is to hook up a serial |
| 21 | console and let some terminal application log the messages. /me uses |
| 22 | screen. See Documentation/serial-console.txt for details on setting |
| 23 | up a serial console. |
| 24 | |
| 25 | Read Documentation/oops-tracing.txt to learn how to get any useful |
| 26 | information out of a register+stack dump printed by the kernel on |
| 27 | protection faults (so-called "kernel oops"). |
| 28 | |
| 29 | If you run into some kind of deadlock, you can try to dump a call trace |
| Jesper Juhl | 62a07e6 | 2005-11-07 01:01:03 -0800 | [diff] [blame] | 30 | for each process using sysrq-t (see Documentation/sysrq.txt). |
| 31 | This way it is possible to figure where *exactly* some process in "D" |
| 32 | state is stuck. |
| Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 33 | |
| 34 | I've seen reports that bttv 0.7.x crashes whereas 0.8.x works rock solid |
| 35 | for some people. Thus probably a small buglet left somewhere in bttv |
| 36 | 0.7.x. I have no idea where exactly, it works stable for me and alot of |
| 37 | other people. But in case you have problems with the 0.7.x versions you |
| 38 | can give 0.8.x a try ... |
| 39 | |
| 40 | |
| 41 | hardware bugs |
| 42 | ------------- |
| 43 | |
| 44 | Some hardware can't deal with PCI-PCI transfers (i.e. grabber => vga). |
| 45 | Sometimes problems show up with bttv just because of the high load on |
| 46 | the PCI bus. The bt848/878 chips have a few workarounds for known |
| 47 | incompatibilities, see README.quirks. |
| 48 | |
| 49 | Some folks report that increasing the pci latency helps too, |
| 50 | althrought I'm not sure whenever this really fixes the problems or |
| 51 | only makes it less likely to happen. Both bttv and btaudio have a |
| 52 | insmod option to set the PCI latency of the device. |
| 53 | |
| 54 | Some mainboard have problems to deal correctly with multiple devices |
| 55 | doing DMA at the same time. bttv + ide seems to cause this sometimes, |
| 56 | if this is the case you likely see freezes only with video and hard disk |
| 57 | access at the same time. Updating the IDE driver to get the latest and |
| 58 | greatest workarounds for hardware bugs might fix these problems. |
| 59 | |
| 60 | |
| 61 | other |
| 62 | ----- |
| 63 | |
| 64 | If you use some binary-only yunk (like nvidia module) try to reproduce |
| 65 | the problem without. |
| 66 | |
| 67 | IRQ sharing is known to cause problems in some cases. It works just |
| 68 | fine in theory and many configurations. Neverless it might be worth a |
| 69 | try to shuffle around the PCI cards to give bttv another IRQ or make |
| 70 | it share the IRQ with some other piece of hardware. IRQ sharing with |
| 71 | VGA cards seems to cause trouble sometimes. I've also seen funny |
| 72 | effects with bttv sharing the IRQ with the ACPI bridge (and |
| 73 | apci-enabled kernel). |
| 74 | |