Markus Rechberger wrote: > On 12/27/06, Peter Daum <gator_ml@xxxxxxxx> 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 ... Regards, Peter Daum _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
