Re: OS freeze after queue_setup

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

 



On Mon, Feb 1, 2016 at 1:16 PM, Ran Shalit <ranshalit@xxxxxxxxx> wrote:
> On Mon, Feb 1, 2016 at 12:04 PM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote:
>>
>>
>> On 02/01/2016 10:07 AM, Ran Shalit wrote:
>>> On Mon, Feb 1, 2016 at 10:14 AM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote:
>>>>
>>>>
>>>> On 02/01/2016 09:00 AM, Ran Shalit wrote:
>>>>> On Sun, Jan 31, 2016 at 10:35 PM, Ran Shalit <ranshalit@xxxxxxxxx> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Maybe someone will have some idea about the following:
>>>>>> I am using a pci card (not video card, just some dummy pci card), to
>>>>>> check v4l2 template for PCIe card (I used solo6x10 as template for the
>>>>>> driver and moved all hardware related to video into remarks).
>>>>>> I don't use any register read/write to hardware (just dummy functions).
>>>>>>
>>>>>> I get that load/unload of module is successful.
>>>>>> But on trying to start reading video frames (using read method with
>>>>>> v4l API userspace example), I get that the whole operating system is
>>>>>> freezed, and I must reboot the machine.
>>>>>> This is the queue_setup callback:
>>>>>>
>>>>>> static int test_queue_setup(struct vb2_queue *q, const struct v4l2_format *fmt,
>>>>>>   unsigned int *num_buffers, unsigned int *num_planes,
>>>>>>   unsigned int sizes[], void *alloc_ctxs[])
>>>>>> {
>>>>>> struct test_dev *solo_dev = vb2_get_drv_priv(q);
>>>>>> dev_info(&test_dev->pdev->dev,"test_queue_setup\n");
>>>>>> sizes[0] = test_image_size(test_dev);
>>>>>> alloc_ctxs[0] = solo_dev->alloc_ctx;
>>>>>> *num_planes = 1;
>>>>>>
>>>>>> if (*num_buffers < MIN_VID_BUFFERS)
>>>>>> *num_buffers = MIN_VID_BUFFERS;
>>>>>>
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> static const struct vb2_ops test_video_qops = {
>>>>>> .queue_setup = test_queue_setup,
>>>>>> .buf_queue = test_buf_queue,
>>>>>> .start_streaming = test_start_streaming, <- does nothing
>>>>>> .stop_streaming = test_stop_streaming, <- does nothing
>>>>>> .wait_prepare = vb2_ops_wait_prepare,
>>>>>> .wait_finish = vb2_ops_wait_finish,
>>>>>> };
>>>>>>
>>>>>>
>>>>>> I didn't find anything suspicious in the videobuf2 callback that can
>>>>>> explain these freeze.( start_streaming,stop_streaming contains just
>>>>>> printk with function name).
>>>>>> I also can't know where it got stuck (The system is freezed without
>>>>>> any logging on screen, all log is in dmesg).
>>>>>>
>>>>>> Thank for any idea,
>>>>>> Ran
>>>>>
>>>>> On start reading frames (using read or mmap method), it seems as if
>>>>> there is some collisions between the pci video card and another card
>>>>> (becuase the monitor is also printed with strange colors as the moment
>>>>> the OS freezes) .
>>>>> I validated again that the PCIe boards IDs in the table are correct
>>>>> (it matches only the dummy pcie card when it is  connected ).
>>>>> I also tried to comment out the irq request, to be sure that there is
>>>>> no irq collision with another board, but it still get freezed anyway.
>>>>
>>>> I can't tell anything from this, I'd need to see the full source.
>>>>
>>>> Regards,
>>>>
>>>>         Hans
>>>
>>> Thank you Hans,
>>> The source code base on solo6x10 as template , and kernel 3.10.0.229
>>> (I needed to use this kernel version instead of latest as start point
>>> because of other pacakge , Intel's media sdk encoder ) :
>>>
>>> https://drive.google.com/file/d/0B22GsWueReZTSElIUEJJSHplUVU/view?usp=sharing
>>> - This package compiled with the makefile
>>> - relevant changes are in solo6x10-core.c & solo6x10-v4l2.c
>>
>> It would certainly help if you don't try to enable interrupts on your pci
>> card. Basically, don't touch the pci at all. The only purpose of using a
>> dummy PCI card is that your template driver is loaded. But touching the hardware
>> will of course have bad results since it isn't video hardware.
>>
>> Frankly, why not just take the v4l2-pci-skeleton.c as your template instead
>> of trying to strip down the solo driver? The skeleton driver is already stripped
>> down!
>>
>> Much easier.
>>
>> Regards,
>>
>>         Hans
>
> Hi Hans,
>
> Thank you for the suggestions.
> I've tried the skeleton and I got the same behaviour.
> When using vivid device, it works (frame reading) without any issues.
> Since the whole system freezes its hard to know the exact problem.
>
> Regards,
> Ran

Hi,

Just to update for anyone with similar behaviour:
On moving to a newer kernel version (3.16.0) , this issue been
resolved  (both the skeleton and the stripped down template based on
solo6x10.)

Thank you,
Ran
--
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