Conflict between ntpd system calls and bttv device driver

Conflict between ntpd system calls and bttv device driver

[C.M.Caldwell]

Greetings,

One line:	Frame grabber times out if ntpd runs with kernel calls

Full:		We run the bttv frame grabber on a Dell-2600 running
		2.6.9-1.667smp (ala Fedora Core 3).  If we run ntpd
		normally, after a variable amount of time (seconds to
		multiple hours), ioctl(dev,VIDIOC_DQBUF,ptr) returns
		EINVAL.  After putting debug writes in the kernel,
		we determined that it is because the request timed out
		due to the fact that the interupt was blocked by a
		higher priority interupt:  the kernel logic for the ntpd
		system calls.

		This doesn't happen on all systems (e.g. a Dell-2650 doesn't
		seem to have this problem), but it will happen with earlier
		versions of the kernel.  Also, the problem occurs even if
		you have stopped ntpd and re-loaded the bttv driver.

		It may be that this can occur under more circumstances than
		outline above but that it is much rarer.  We believe that
		the Dell-2600s multiple PCI busses and its interupt structure
		may make it much more sensitive to having interupts blocked
		for long periods of time.
		
Keywords:	bttv adjtime VIDIOC_DQBUF timeout
Version:	2.6.9-1.667smp

Workaround:	Add "disable kernel" to ntp.conf file and reboot
Oops output:
Shell script:
Environment:
Software:
Processor:	i686 Genuine Intel 2.8GHZ (Dell-2600)
Modules:
Loaded drivers:
Hardware:
lspci:
SCSI:

Comments:	Considering how easy the work-around for us is, this is
		pretty low priority (though it was mighty high until we
		figured out that ntpd was the thing hogging the interupts).
		I wanted to send this in just to make people aware that
		there maybe some timing conflicts.
		sure 

Re: Conflict between ntpd system calls and bttv device driver

[Andrew Morton]

(added video4linux-list@redhat.com)

C.M.Caldwell@Alumni.UNH.EDU wrote:
>
> Greetings,
> 
> One line:	Frame grabber times out if ntpd runs with kernel calls
> 
> Full:		We run the bttv frame grabber on a Dell-2600 running
> 		2.6.9-1.667smp (ala Fedora Core 3).  If we run ntpd
> 		normally, after a variable amount of time (seconds to
> 		multiple hours), ioctl(dev,VIDIOC_DQBUF,ptr) returns
> 		EINVAL.  After putting debug writes in the kernel,
> 		we determined that it is because the request timed out
> 		due to the fact that the interupt was blocked by a
> 		higher priority interupt:  the kernel logic for the ntpd
> 		system calls.

Please be more specific.  Where, exactly, did this timeout occur? 
File, line and function name.

Did you consider simply increasing the timeout?

What is ntpd doing to cause interrupts to be delayed for so long?  Does ntpd
rewrite the CMOS clock?

> 		This doesn't happen on all systems (e.g. a Dell-2650 doesn't
> 		seem to have this problem), but it will happen with earlier
> 		versions of the kernel.  Also, the problem occurs even if
> 		you have stopped ntpd and re-loaded the bttv driver.
> 
> 		It may be that this can occur under more circumstances than
> 		outline above but that it is much rarer.  We believe that
> 		the Dell-2600s multiple PCI busses and its interupt structure
> 		may make it much more sensitive to having interupts blocked
> 		for long periods of time.
> 		
> Keywords:	bttv adjtime VIDIOC_DQBUF timeout
> Version:	2.6.9-1.667smp
> 
> Workaround:	Add "disable kernel" to ntp.conf file and reboot
> Oops output:
> Shell script:
> Environment:
> Software:
> Processor:	i686 Genuine Intel 2.8GHZ (Dell-2600)
> Modules:
> Loaded drivers:
> Hardware:
> lspci:
> SCSI:
> 
> Comments:	Considering how easy the work-around for us is, this is
> 		pretty low priority (though it was mighty high until we
> 		figured out that ntpd was the thing hogging the interupts).
> 		I wanted to send this in just to make people aware that
> 		there maybe some timing conflicts.
> 		sure