Most recent kernel where this bug did not occur: 2.6.10 Distribution: Debian Hardware Environment: MSI K7N2GM2 Series motherboard, Skystar2 Software Environment: Nothing special, problem occurs even when only the basic system is loaded. Problem Description: reboot fails on 2.6.13 when skystar2 dvb drivers are loaded Steps to reproduce: - make sure that skystar2 dvb driver is loaded - try to reboot The results is a system frozen at the "Rebooting..." message
Created attachment 5975 [details] here are the relevant debug files for this bug
alt-sysrq-b reboots the system
some more notes: halt also doesn't work tried without acpi, same results tried various reboot methods with reboot= kernel cmdline, same results
I have no idea how to debug this. Does SysRq-T produce any output when it hangs at "Rebooting..."?
yes! Somehow I've missed that sysqr-t exists! It produces a lot of scrolling output, and the end looks useful (I won't write the addreses, just function names) Calltrace: __down_interruptible flexcop_null_filter_ctrl default_wake_function __down_failed_interruptible .text.lock.dvb_demux dmx_section_feed_release_filter local_bh_enable dvb_net_feed_stop dev_close dev_change_flags devinet_ioctl do_ioctl vfs_ioctl sys_socketcall sys_ioctl sysenter_past_esp
our setup configures two different dvbnet interfaces dvb0_0 and dvb0_1 (different data channels) when i do ifconfig dvb0_0 down ifconfig dvb0_1 down the second line fails and blocks forever i can press ctrl-c to terminate ifconfig, repeat the command and it finishes correctly after that, i can reboot normally
I think something similar has been reported before on the linux-dvb list, but a code review of the dvb_net and dvb_demux code indicated that there is no possibility for the mutex in question to remain locked. Currently I assume that the memory that holds the mutex is trashed somehow, but I don't have any proof for that. I could also be totaly wrong here... Do you see something else in SysRq-T output which would point to .text.lock.dvb_demux? (The summary line for this bug should be changed to read "dvb_net deadlock in 'ifconfig dvbX_Y down' when more than one dvb_net interface is configured".)
I don't see anything that would point to .text.lock.dvb_demux, but the scrollback buffer is not big in my kernel
if I reverse the order of bringing down the dvb net interfaces like this: ifconfig dvb0_1 down ifconfig dvb0_0 down i don't get the deadlock.... here is a complete sysrq-t trace
Created attachment 5990 [details] complete sysrq-t backtrace
Locking for SMP platforms was broken in dvb_net.c. A fix is in linuxtv.org CVS, please test. http://linuxtv.org/cgi-bin/viewcvs.cgi/dvb-kernel/linux/drivers/media/dvb/dvb-core/dvb_net.c
I'm assuming this is already fixed in recent 2.6 kernels. Please reopen this bug if it's still present in kernel 2.6.16.7.