[linux-dvb] cinergyT2 kills keyboard [Re: cinergyT2: multiple devices not supported?]

Peter Daum gator_ml at yahoo.de
Thu Dec 28 11:47:29 CET 2006

Markus Rechberger wrote:
> On 12/27/06, Peter Daum <gator_ml at yahoo.de> wrote:
>> BTW, has anybody of you fellow cinergyT2 users ever experienced
>> crashes killing the keyboard?
>> (http://article.gmane.org/gmane.linux.drivers.dvb/30386)
> the DVB framework isn't hotpluggable, you can experience all kind of
> problems if you unplug the device while it's in used.
>> I used to have that problem pretty regularly. Right now, I turned off
>> the /dev/input support, which seems to help, but I am not sure whether
>> this really is the problem, and could imagine occasions, where the
>> remote control might be a nice thing to have ...
> it does not happen if the hardware works continuously without any problem.
> If an unexpected powerdown occures on your usbhub it's possible to
> kill the dvb framework and partly crash the kernel.

... I noticed that any unexpected disconnect of a DVB device halts the
machine, but this is not what I mean.The problem I am talking about is
obviously specific to the cinergyT2 (At least I have never seen anything
remotely similar on any other occasion - I've had a ttusb_dec device for
~2 years, which never worked too well, but this problem never occurred) and
also is not a "classical" crash (no Oops or kernel panic, only the machine
is left unusable).

It usually happens when a recording from the cinergyT2 stops and the
devices are being closed (which results in a call to cinergyt2_release).
A stack trace of the running tasks always looks similar to this:

tzap          D C1929ED4     0  4777   4775                     (L-TLB)
f1dcfeb0 00000086 00000086 c1929ed4 00000202 eff13000 c15fe240 00000000
       00000092 c3c76c00 003d08d6 00000000 00000000 c1907a70 00000000 c3c76c00
       003d08d6 f265c550 f265c678 c18ec6d8 c18ec6c0 f1dce000 f1dce000 c0128c73
Call Trace:
 [<c0128c73>] flush_cpu_workqueue+0x98/0xe7
 [<c012bc7a>] autoremove_wake_function+0x0/0x37
 [<c012bc7a>] autoremove_wake_function+0x0/0x37
 [<c0128cda>] flush_workqueue+0x18/0x19
 [<fa9df745>] cinergyt2_release+0xa2/0xbd [cinergyT2]
 [<c0158719>] __fput+0x147/0x198
 [<c0157079>] filp_close+0x3a/0x60
 [<c0148d4b>] remove_vma+0x28/0x4f
 [<c011c05a>] close_files+0x73/0x93
 [<c011c0bf>] put_files_struct+0x17/0x42
 [<c011ca49>] do_exit+0x107/0x40a
 [<c011cd9f>] do_group_exit+0x27/0x8f
 [<c0102ccf>] sysenter_past_esp+0x54/0x75

Afterwards, tzap (or something similar, at least with "mencoder" pretty
much the same happens) is stuck in an uninteruptible sleep on
"flush_cpu_workqueue" and the keyboard doesn't work anymore (with one
exception, otherwise I couldn't get a trace, the alt+sysrq key
combinations still work). The syslog (which still works) however, shows no
sign of an errror.

As far as I can see (it's kind of hard without keyboard;), there seem to be
some more things not working anymore (e.g. when I close an xterm with the
mouse, it also blocks on flush_cpu_workqueue), while other things continue
to work as usual. When I connect an USB keyboard, the hotplug event is
processed as usual, but with the exception of alt+sysrq, no key press shows
any visible reaction. The only way to get the system up and working again
seems to be a full reboot.

This is a problem that always has occured even with one cinergyT2 (see my
previous report at (http://article.gmane.org/gmane.linux.drivers.dvb/30386).

I tried a bunch of different ways to get a recording from the box
(mencoder, tzap + cat, tzap -o ...), but no matter what I tried, about
every 2-3 days it took the system down. (I also had disabled the
/dev/input support in the driver which at first seemed to help and the
connection to the keyboard malfunction seemed at leas plausible).
Unfortunately, with the 2nd box added, the frequency has more than doubled
(5 reboots during the last 12 hours), so this is definitely not feasible.

If anybody has any idea what's going on and how to fix it, I'll gladly try
to help ...

                           Peter Daum

More information about the linux-dvb mailing list