]>
Commit | Line | Data |
---|---|---|
1da177e4 LT |
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 | |
30 | for each process using sysrq-t (see Documentation/sysrq.txt). ksymoops | |
31 | will translate these dumps into kernel symbols too. This way it is | |
32 | possible to figure where *exactly* some process in "D" state is stuck. | |
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 |