videodevX was designed to use unadjusted system time (elapsed time since bootup). Linux doesn't have UST, so I used the clock instead. The clock can be adjusted, and doing so will cause problems if there is a capture going on. That I realized. I didn't realize it would create a divide error, though. That needs to be worked around. I was working on a UST for Linux based on the processor cycle counter (if the processor has one) a long time ago (2.2.x days). I'd like to have something like that in the kernel after V4L2 goes in. Lately I am worried about that approach to UST because some modern processors can slow down to save power or prevent overheating, and I don't know if the cycle counter slows down too. Bill. Justin Schoeman wrote: > > Adrian Matellanes wrote: > > > Dear Justin, > > I've found what I think is a bug in videodevX. > > I am using the latest version on a 2.4.2 kernel. > > > > The problem appears when I change date & time of my machine. > > Sometimes when changing time (setting it, say, 2 hours earlier) I get a > > crash, a divide error. > > > > I've been trying to fix it but, unfortunately, I cant. > > I dont know why it arrives a value to v4l2_math_div6432 that makes the > > division not to fit in 32 bits. > > > > I tried to trace the value but printk didnt allow me to check the "u32 > > d" parameter. By the way, do you know how can I trace such variables? > > printk("%u", i); > > should print a u32 value, and "%llu" a u64 value (I think). > > > What I know is that the value in v4l2_timestamp_divide is okay but > > arrives corrupted at v4l2_math_div6432. Indeed I cannot even trace the > > value once cast is done. > > > > I also tried to avoid the assembly code by calling directly to the > > division, but I cannot do a 64 bit division in kernel space, when > > loading the module it cannot find __divid3 symbol. > > > > I hope I explained myself clearly enough! If I can help in any way just > > tell me. > > Thanks very much in advance. > > > > Adrian > > bttv works on the time relative to the start of the video stream. When > the clock gets set back, the subtraction results in an overflow, which > results in a huge number. This then causes the problem with > v4l2_timestamp_divide. > > I am not entirely sure what to do about this though, I could try make > bttv2 guard against negative timesteps, or try to build range protection > into videodevX... > > Thanks for the debugging ;-) > > -justin