Re: OOPS in 2.4.25-rc1 -- video1394

[Roland Mas <roland.mas@free.fr>]

Roland Mas, 2004-02-09 23:16:19 +0100 :

> Ben Collins, 2004-02-09 12:57:31 -0500 :
>
> [...]
>
>> Looks to me like it is failing in alloc_dma_iso_ctx(), and then
>> calling free_dma_iso_ctx() where it encounters some bad data. I
>> can't see off hand where this might happen. Was there any message
>> prior to this, like maybe a video1394 error message?
>
> There were messages before that, yes.  Here come bits of my kern.log.

[...]

>   If there's anything else I can povide, just say so, I just can't
> think of anything.

  I have new data: if I reduce the "Frame Buffers" (tooltip: "The
number of frames that will be buffered to prevent underrun")
configuration entry in Kino from 300 to 50, then Kino doesn't crash
and the kernel doesn't oops.  On the other hand, only three seconds
can be exported to the camcorder before what's transmitted becomes a
flashing blue/white screen, with small blocks of image transmitted
occasionnally.  During the same time, top(1) displays my XFree86
process as using a very large amount of CPU (more than 95%, and load
indeed goes from about 0 to about 1).  Since my CPU *should* be fast
enough (Athlon 2200+, 1 GB of RAM), I now think the bug is at least
partially in userspace.  If you have ideas on how to debug further,
I'd be glad to hear about them, otherwise I'll turn my attention to
Kino's maintainer and/or author.  My personal (hence probably wrong)
interpretation is that Kino tried to allocate lots and lots of space
for its 300 buffers, doesn't check the result, and tries to access the
freshly (non-)allocated space.

  I still think the kernel shouldn't oops, but if I can find a
userspace fix, I won't mind that much :-)

Roland.
-- 
Roland Mas

- Ogenki desuka, yau de poêle ?
- Genki desu, ture en zinc.