Hans Verkuil wrote:
On Friday 09 September 2005 03:47, Philip Rowlands wrote:
Attached are serial console logs captured by Grant Kwok (thanks Grant!)
showing the kernel log during system lockup - he's having some trouble
mailing the list.
Anyone familiar with interrupt handler oopses? I'm among the least
qualified to comment on interrupt handlers, but... is it correct that
ivtv uses SA_INTERRUPT (disable all interrupts during handler), yet
doesn't use a minimal "top-half"? In ivtv_irq_handler I see spinlocks,
printks, and other fun stuff which might cause complications.
The 'printk' statements in the irq handler only happen when you have
debugging levels well above normal, so hence don't print during any
non-debugging usage.
Also the irqhandler really doesn't do much, besides wake up threads, no
heavy work, so really doesn't needs a top/bottom half. The spinlock is
just to keep SMP sane, in fact it's a spinlock that should only really
activate on SMP.
If not that, then perhaps the kfree() at ivtv-fileops.c:1494 (in
ivtv_v4l2_close)?
Isn't the problem simply that the YUV decoder buffers cannot be allocated?
Memory allocation failures are not handled very well in the driver and if you
continue regardless I'm not surprised all sorts of strange errors crop up.
No, memory allocation is not horribly handled in the driver, it's not
great in obscure points where you would most likely crash anyways
because there's something that wouldn't work anyways beyond normal usage
(but even cases like filled disk drives it seems to do fine). I have
the buffers all recycle so there should never be a problem with buffer
allocating that way in terms of us bailing, we just grab from our full
buffers. There were alot of problems in the past and I think we are
beyond those, most cases the driver won't bring your system down when
something goes wrong or the driver is abused, so not seeing horrible
memory handling anywhere?
The dynamic allocation has one slight problem, although I agree it's
better at this default, but whenever that's the default then alot of
people seem to either get caught with all the memory allocated up front
for streams they don't use, or can't reload the driver over and over
again. So that's a problem that may crop up, seems to change the tables
on peoples ivtv behavior, so some may need to try to enable it again
(although probably best for those needing it to enable it, will just
need to change now, since most should do alright with the new dynamic
buffer setting).
Thanks,
Chris
Hans
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
ivtv-devel mailing list
ivtv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
--
===
Chris Kennedy
[EMAIL PROTECTED]
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
ivtv-devel mailing list
ivtv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
