Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[mpeg2] Fw: Fix for kernel-freezes




Bram,

	Thanks for the suggestion, it seems to work fine with the "Sleep" changes.

	I have tried to look at the "mdelay" operations in kfir.c and found that 
most of the delay time is around 1 - 10 ms, which I think they are relatively 
small time slices and wouldn't be noticed by normal users. However, I found 
there are 2 major "mdelay" in kfir.c, one is delaying by 100ms, the other is 
1000ms (or 1 second). I changed them to 10ms and 100ms respectively and the 
driver still seems to work fine. (In fact, I think these 2 mdelay are only 
used when loading the micro code)

	Anyway, hope this helps.

Kevin.

> ----- Original Message -----
> From: "Bram Stolk" <b.stolk@chello.nl>
> To: <mpeg2@linuxtv.org>
> Sent: Friday, February 01, 2002 5:05 AM
> Subject: [mpeg2] Fix for kernel-freezes
>
> > hi,
> >
> > When using the kfir module, you will have noticed
> > that the kernel freezes regularly for a few seconds or so.
> > Most noticably during module load, and during device closing.
> >
> > (Try e.g. switching virtual consoles when loading kfir.o:
> >  it will not work, as ALL system services are halted during
> >  this time)
> >
> > This is because the kernel module issues mdelay operations.
> > These are evil operations, and should always be avoided if
> > possible.
> >
> > What's worse... it turns out that most of these delays
> > are not necessary, at least in my setup.
> >
> > For instance, when redefining 'Sleep' to return without
> > delay, has had *no* impact on the functionality of my BMK
> > mpeg encoder card.
> >
> > To improve the responsiveness of the system, I advice you to
> > redefine Sleep() in kfir.o as:
> > static inline void Sleep(int i)
> > {
> >         return;
> > }
> >
> > Next, I propose a carefull examination of all remaining
> > mdelay() ops, and see if the can be removed, or else lowered.
> > This can be a labourous task, so if we divide the workload
> > among the members of this mailinglist, we can probably
> > empirically designate those mdelays that are actually needed.
> >
> > So... who's with me?
> >
> >   Bram




Home | Main Index | Thread Index