[mpeg2] Re: Hard lockups when loading the kfir module

[Andreas Trottmann <andreas.trottmann@werft22.com>]

On Tue, Apr 24, 2001 at 05:34:07PM +0200, Ralph Metzler wrote:

>  > We are experiencing the lockup problem on a machine with a board using
>  > the Intel LX chipset, and turning off the USB support in the BIOS
>  > doesn't change anything. We quickly tried on a different machine (that
>  > also uses the LX chipset -- it was a spare machine that could be tested
>  > quickly), and had identical results (i.e. it also locks up).
>  > 
>  > We'll try a machine with a different chipset (probably I can test it on
>  > one with the BX chipset) and will tell you the results.
> 
> It should work on BX boards.
> I have it working on two BX boards, an ASUS P2B-LS with 300MHz Celeron
> and an ASUS P2B-DS with two 350 MHz PIIs. 
> I also developed the drivers on those.

Thanks! In the meantime, we got much further:

It was not the board that was guilty, but apparently the lockups were
caused because the driver couldn't find the microcode.

We don't have a compiler on the machine(s) with the board, so I compiled
the driver on my workstation, somehow assumed that MPEG1_6.HLD and
altera_keb_plx_5e.rbf would get compiled into kfir.o, and thus didn't
install them on the target machine. The result was what I described: A
lockup with the mentionned messages on the screen.

I found out about this when I tried it this morning on the BX machine; i
booted it in single-user mode to save time, and suddenly saw additional
messages before the lockup:

Unable to load /lib/kfir/altera_keb_plx_5e.rbf

Apparently, yesterday, these messages were sent to the syslog and thus
lost after the crash. Only in single-user mode, with klogd/syslogd not
running, they ended up on the console for me to see.

I then installed altera_keb_plx_5e.rbf and MPEG1_6.HLD in /lib/kfir on
the target machine, and it doesn't crash anymore.

May I suggest you to document this in the README?



Now, we have other problems: Any "streamtype" except 7 (VT_KFIR_SYSTEM)
does not seem to produce any output (i.e. "cat /dev/video > test.mpg"
produces a file that stays at size 0). "streamtype=7" produces something, 
but we didn't have success playing it with any MPEG player we tried.

However, we are using a video source of abysmal quality, so maybe the
card has problems synchronizing to the source. We will try again with a
higher quality source and tell you whether it works or not.


-- 
Andreas Trottmann <andreas.trottmann@werft22.com>