I'll try to upload a 2.6.36 based test kernel with "V4L/DVB: xc5000, rework xc_write_reg" (quite fundamental rewrite of the i2c based register access for this driver) reverted over the next few days, which might help. However this issue needs to be raised upstream before 2.6.37, as this rewrite is apparently needed to support newer devices (and is claimed to be tested with tm6000 and saa7134).

Thank you for building a test kernel for this issue. I would be happy to report this upstream but I have never reported a kernel bug before and it is not immediately obvious where to send it where it will not be ignored.

Major kernel releases seem to be coming a lot more frequently than they used to. 2.6.36 is barely out and there is already a 2.6.37-rc.

Sorry for the delay, my current upload bandwidth is hard to work with. I've uploaded a test kernel to http://aptosid.com/slh/xc5000/, if that one works, you need to contact upstream about it (because I can't revert these changes for 2.6.37). The only differences between this kernel and "ordinary" 2.6.36 kernels is the reversion of these two patches to xc5000:

Debugging options have a tendency to slightly affect timing, which might introduce just enough latency to let the device succeed instead of failing; this doesn't change the fact that a bug like that needs to be fixed in the driver.

Building with CONFIG_DEBUG_SECTION_MISMATCH=y has not provided information that is useful to me. It is as if very few intermediate states of the git tree are buildable, but this seems unlikely, so I must be doing something wrong. But what?