Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 03 8月, 2010 1 次提交
  3. 19 5月, 2010 1 次提交
    • M
      V4L/DVB: fix dvb frontend lockup · e36309f5
      由 matthieu castet 提交于 
      If my dvb device is removed while in use, I got the following oops:

[ 4920.484084] Call Trace:
[ 4920.484102]  [<c102daad>] ? default_wake_function+0x0/0x8
[ 4920.484147]  [<f8cb09e1>] ? dvb_unregister_frontend+0x95/0xcc [dvb_core]
[ 4920.484157]  [<c1044412>] ? autoremove_wake_function+0x0/0x2d
[ 4920.484168]  [<f8dd1af2>] ? dvb_usb_adapter_frontend_exit+0x12/0x21 [dvb_usb]
[ 4920.484176]  [<f8dd12f1>] ? dvb_usb_exit+0x26/0x88 [dvb_usb]
[ 4920.484184]  [<f8dd138d>] ? dvb_usb_device_exit+0x3a/0x4a [dvb_usb]
[ 4920.484217]  [<f7fe1b08>] ? usb_unbind_interface+0x3f/0xb4 [usbcore]
[ 4920.484227]  [<c11a4178>] ? __device_release_driver+0x74/0xb7
[ 4920.484233]  [<c11a4247>] ? device_release_driver+0x15/0x1e
[ 4920.484243]  [<c11a3a33>] ? bus_remove_device+0x6e/0x87
[ 4920.484249]  [<c11a26d6>] ? device_del+0xfa/0x152
[ 4920.484264]  [<f7fdf609>] ? usb_disable_device+0x59/0xb9 [usbcore]
[ 4920.484279]  [<f7fdb9ee>] ? usb_disconnect+0x70/0xdc [usbcore]
[ 4920.484294]  [<f7fdc728>] ? hub_thread+0x521/0xe1d [usbcore]
[ 4920.484301]  [<c1044412>] ? autoremove_wake_function+0x0/0x2d
[ 4920.484316]  [<f7fdc207>] ? hub_thread+0x0/0xe1d [usbcore]
[ 4920.484321]  [<c10441e0>] ? kthread+0x61/0x66
[ 4920.484327]  [<c104417f>] ? kthread+0x0/0x66
[ 4920.484336]  [<c1003d47>] ? kernel_thread_helper+0x7/0x10

If there are users (for example users == -2) :
 - dvb_unregister_frontend :
 - stop kernel thread with dvb_frontend_stop :
  - fepriv->exit = 1;
  - thread loop catch stop event and break while loop
  - fepriv->thread = NULL; and fepriv->exit = 0;
 - dvb_unregister_frontend wait on "fepriv->dvbdev->wait_queue" that fepriv->dvbdev->users==-1.
The user finish :
 - dvb_frontend_release - set users to -1
 - don't wait wait_queue because fepriv->exit != 1

=> dvb_unregister_frontend never exit the wait queue.
Signed-off-by: NMatthieu CASTET <castet.matthieu@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      e36309f5
  5. 17 5月, 2010 1 次提交
  7. 27 2月, 2010 3 次提交
  9. 06 12月, 2009 2 次提交
  11. 02 12月, 2009 1 次提交
  13. 19 9月, 2009 3 次提交
  15. 12 9月, 2009 2 次提交
  17. 17 6月, 2009 2 次提交
    • D
      V4L/DVB (11875): dvb_frontend: fix case where fepriv->exit not reset · a5beb7b3
      由 Devin Heitmueller 提交于 
      The fact that we now explicitly set fepriv->exit = 1 when the thread is
shutting down exposed an edge case where it was not being reset back to zero
once the thread went away in some cases.  This resulted in failures in cases
where the frontend was closed, and then opened O_RDONLY, since in that case
the thread is not being restarted but it was checking the fepriv->exit flag.

Thanks to Thierry Lelegard, who and encountered and debugged a large portion
of the issue in the same twelve hours that I did (as well as testing my patch).

Cc: Thierry Lelegard <thierry.lelegard@tv-numeric.com>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      a5beb7b3
    • D
      V4L/DVB (11785): dvb_frontend: fix race condition resulting in dropped tuning commands · 57594a58
      由 Devin Heitmueller 提交于 
      A race condition was detected in the case that putting the tuner to sleep takes
an unusually long period of time, combined with applications that quickly
close/open the dvb frontend.

The kaffeine channel scanner closes and reopens the dvb frontend between each
tuning attempt.  If it takes an unusually longer period of time to put the
tuner to sleep (for example, the Pinnacle 801e takes 660 ms), the dvb_frontend
thread will still be in a running state (and hence fepriv->thread is still set)
but the fepriv->exit field will still be zero.  As a result, if a
dvb_frontend_start() call arrives while the frontend thread is in the process
of terminating, the call will return 0 without actually starting a new thread.
This results in the tuning request being dropped.

To address this, mark fepriv->exit as soon as we know the thread is going to
be terminated, so that dvb_frontend_start() knows to start a new instance.

Problem encountered with Kaffeine 0.8.7 doing ATSC scanning against the
Pinnacle 801e tuner, in conjunction with new code to power down the xc5000
when not in use.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      57594a58
  19. 30 3月, 2009 1 次提交
  21. 14 3月, 2009 1 次提交
  23. 08 1月, 2009 1 次提交
    • M
      V4L/DVB (10178): dvb_frontend: Fix some sparse warnings due to static symbols · 072ce0c5
      由 Mauro Carvalho Chehab 提交于 
      /home/v4l/master/v4l/dvb_frontend.c:838:19: warning: symbol 'dtv_cmds' was not declared. Should it be static?
/home/v4l/master/v4l/dvb_frontend.c:1035:6: warning: symbol 'dtv_property_dump' was not declared. Should it be static?
/home/v4l/master/v4l/dvb_frontend.c:1066:5: warning: symbol 'is_legacy_delivery_system' was not declared. Should it be static?
/home/v4l/master/v4l/dvb_frontend.c:1080:6: warning: symbol 'dtv_property_cache_sync' was not declared. Should it be static?
/home/v4l/master/v4l/dvb_frontend.c:1132:6: warning: symbol 'dtv_property_legacy_params_sync' was not declared. Should it be static?
/home/v4l/master/v4l/dvb_frontend.c:1187:6: warning: symbol 'dtv_property_adv_params_sync' was not declared. Should it be static?
/home/v4l/master/v4l/dvb_frontend.c:1222:6: warning: symbol 'dtv_property_cache_submit' was not declared. Should it be static?
/home/v4l/master/v4l/dvb_frontend.c:1253:5: warning: symbol 'dtv_property_process_get' was not declared. Should it be static?
/home/v4l/master/v4l/dvb_frontend.c:1362:5: warning: symbol 'dtv_property_process_set' was not declared. Should it be static?
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      072ce0c5
  25. 30 12月, 2008 6 次提交
  27. 17 11月, 2008 2 次提交
  29. 11 11月, 2008 1 次提交
  31. 18 10月, 2008 5 次提交
    • S
      V4L/DVB (9274): Remove spurious messages and turn into debug. · a1bc84c0
      由 Steven Toth 提交于 
      Remove spurious messages and turn into debug.
Signed-off-by: NSteven Toth <stoth@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      a1bc84c0
    • D
      V4L/DVB (9264): MFE: bugfix: multi-frontend mutual exclusion parallel open · 6594690b
      由 Darron Broad 提交于 
      When moving from one frontend to another
an application could spawn multiple threads opening
the same new frontend and in some circumstances all of
these could become delayed waiting for the previous
frontend readers or previous frontend writer thread to
complete.

In this scenario the first thread will succeed on open
to bring the new frontend online but any others will return
EBUSY. This is a fault.  If the first succeeds and all others
are on the same frontend then they should succeed also.
Signed-off-by: NDarron Broad <darron@kewl.org>
Signed-off-by: NSteven Toth <stoth@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      6594690b
    • D
      V4L/DVB (9227): MFE: Add multi-frontend mutual exclusion · 59b1842d
      由 Darron Broad 提交于 
      This add frontend R/W mutual exclusion.
Prior to this point in time it was possible to open both
frontends simultaneously which an MFE card cannot support.

In order to stop this, a delayed open is performed which
has the following function:

-  Return EBUSY after a configurable amount of time
   if a frontend is unavailable due to the other being
   in use.

-  Only allow opening of a frontend if the kernel thread
   of the other has stopped.

This solution was chosen to allow switching between
frontends to work as seamlessly as possible. When both
frontends are actually opened simultaneously then one
will only open, but if quick switching is performed
between one of many then the new open will succeed in
a clean fashion rather than interrupting a kernel
thread.
Signed-off-by: NDarron Broad <darron@kewl.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      59b1842d
    • S
      V4L/DVB (9222): S2API: Add Multiple-frontend on a single adapter support. · 363c35fc
      由 Steven Toth 提交于 
      A detailed description from the original patches 2 years ago:

"The WinTV-HVR3000 has a single transport bus which is shared between
a DVB-T and DVB-S modulator. These patches build on the bus acquisition
cx88 work from a few weeks ago to add support for this.

So to applications the HVR3000 looks like this:
/dev/dvb/adapter0/fe0 (cx24123 DVB-S demod)
/dev/dvb/adapter0/fe1 (cx22702 DVB-T demod)

Additional boards continue as before, eg:
/dev/dvb/adapter1/fe0 (lgdt3302 ATSC demod)

The basic change is removing the single instance of the videobuf_dvb in
cx8802_dev and saa7134_dev(?) and replacing it with a list and some
supporting functions.

*NOTE* This branch was taken before v4l-dvb was closed for 2.6.19 so
two or three current cx88 patches appear to be reversed by this tree,
this will be cleaned up in the near future. The patches missing change
the mutex handing to core->lock, fix an enumeration problem."

It should be recognised that a number of people have been maintaining
this patchset. Significant levels of Kudos to everyone one involved,
including but not limited to:

Darron Broad
Fabio M. Di Nitto
Carlo Scarfoglio
Hans Werner

Without the work of these people, and countless others, my two year old
patches would of died on the Mercurial linuxtv.org vine a long time
ago.

TODO: Revise these patches a little further so that the need for
demux1 and dvr0 is optional, not mandatory on the HVR3000.

HISTORY (darron):
This is the last update to MFE prepared by Hans which is based
upon the `scratchpad' diff created by Carlo.
All MFE work prior to that point must be attributed to Fabio
who ported and maintained Steve's original patch up to that
time.
Signed-off-by: NSteven Toth <stoth@linuxtv.org>
Signed-off-by: NDarron Broad <darron@kewl.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      363c35fc
    • M
      V4L/DVB (9195): Frontend API Fix: 32APSK is a valid modulation for the DVB-S2 delivery · 97854829
      由 Manu Abraham 提交于 
      Signed-off-by: NManu Abraham <manu@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      97854829
  33. 13 10月, 2008 7 次提交