Re: cx18: Unable to find blank work order form to schedule incoming mailbox ...

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

 



On Tue, 2010-03-02 at 00:57 -0500, Mark Lord wrote:
> On 03/01/10 20:34, Andy Walls wrote:
> > On Mon, 2010-03-01 at 11:07 -0500, Mark Lord wrote:
> >> I'm using MythTV-0.21-fixes (from svn) on top of Linux-2.6.33 (from kernel.org),
> >> with an HVR-1600 tuner card.  This card usually works okay (with workarounds for
> >> the known analog recording bugs) in both analog and digital modes.
> >>
> >> Last night, for the first time ever, MythTV chose to record from both the analog
> >> and digital sides of the HVR-1600 card at exactly the same times..
> >>
> >> The kernel driver failed, and neither recording was successful.
> >> The only message in /var/log/messages was:
> >>
> >> Feb 28 19:59:45 duke kernel: cx18-0: Unable to find blank work order form to schedule incoming mailbox command processing
> >
> >
> > This is really odd.  It means:
> >
> > 1. Your machine had a very busy burst of cx18 driver buffer handling
> > activity.  Stopping a number of different streams, MPEG, VBI, and (DTV)
> > TS at nearly the same time could do it
> >
> > 2. The firmware locked up.
> >
> > 3. The work handler kernel thread, cx18-0-in, got killed, if that's
> > possible, or the processor it was running on got really bogged down.
> ..
> 
> Yeah, it was pretty strange.
> I wonder.. the system also has a Hauppauge 950Q USB tuner,
> which is also partially controlled by the cx18 driver (I think).

Nope.  Different driver.  The processing for the 950Q USB may have put
some extra load on the system, but likely not enough load to stall 70
MDL handover requests from the firmware.


> I wonder if perhaps that had anything to do with it?
> 
> > If you want to make the problem "just go away" then up this parameter in
> > cx18-driver.h:
> >
> > #define CX18_MAX_IN_WORK_ORDERS (CX18_MAX_FW_MDLS_PER_STREAM + 7)
> > to something like
> > #define CX18_MAX_IN_WORK_ORDERS (2*CX18_MAX_FW_MDLS_PER_STREAM + 7)
> ..
> 
> Heh.. Yup, that's the first thing I did after looking at the code.  :)
> Dunno if it'll help or not, but easy enough to do.

If it doesn't, then there's a problem somewhere else. ;)

> And if the cx18 is indeed being used by two cards (HVR-1600 and HVR-950Q),
> then perhaps that number does need to be bigger or dynamic (?).

Dynamic would be better.

For each CX23418 based card in your system, a pool of these work
requests is allocated dynamically at card setup, and drawn from when
needed during operation.

Since the CX23418 can have up to 63 MDL done notifications (and 2 MDL
Ack notifications, IIRC) for the following 6 types of streams: MPEG,
VBI, IDX, PCM, YUV and TS.  The most work orders that should ever need
is 6 * 65.

One would only need that maximum when effectively stopping all 6 streams
on a card at once, while not processing the work requests in a timely
manner.  That is so pathological, its not worth considering.  That's why
the cx18 driver only has 70 in the pool: 63 for one stream stopping and
5 others for running streams (and 2 for a couple of MDL Acks, IIRC).


Again, maybe dynamically allocating these work order objects from the
kernel as needed, would be better from a small dynamically allocated
pool for each card.  I was concerned that the interrupt handler was
taking to long at the time I implemented the things the way they are
now.



> I've since tried to reproduce the failure on purpose, with no luck to date.
> 
> Thanks guys!

You're welcome.

Regards,
Andy


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux