Bug 5228

Summary:	dvb_net deadlock in 'ifconfig dvbX_Y down' when more than one dvb_net interface is configured
Product:	Drivers	Reporter:	Vedran Rodic (vedran)
Component:	Network	Assignee:	platform_i386
Status:	REJECTED INSUFFICIENT_DATA
Severity:	high	CC:	bunk, js
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.13	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	here are the relevant debug files for this bug complete sysrq-t backtrace

Description Vedran Rodic 2005-09-12 03:14:15 UTC

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

Comment 1 Vedran Rodic 2005-09-12 03:15:17 UTC

Created attachment 5975 [details]
here are the relevant debug files for this bug

Comment 2 Vedran Rodic 2005-09-12 04:56:59 UTC

alt-sysrq-b reboots the system

Comment 3 Vedran Rodic 2005-09-12 04:58:08 UTC

some more notes:

halt also doesn't work
tried without acpi, same results
tried various reboot methods with reboot= kernel cmdline, same results

Comment 4 Johannes Stezenbach 2005-09-12 07:50:15 UTC

I have no idea how to debug this. Does SysRq-T produce
any output when it hangs at "Rebooting..."?

Comment 5 Vedran Rodic 2005-09-12 08:35:05 UTC

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

Comment 6 Vedran Rodic 2005-09-12 09:06:02 UTC

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

Comment 7 Johannes Stezenbach 2005-09-12 09:12:38 UTC

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".)

Comment 8 Vedran Rodic 2005-09-12 09:44:17 UTC

I don't see anything that would point to .text.lock.dvb_demux, but the
scrollback buffer is not big in my kernel

Comment 9 Vedran Rodic 2005-09-13 04:49:21 UTC

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

Comment 10 Vedran Rodic 2005-09-13 04:49:57 UTC

Created attachment 5990 [details]
complete sysrq-t backtrace

Comment 11 Johannes Stezenbach 2005-11-20 18:27:42 UTC

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

Comment 12 Adrian Bunk 2006-04-18 07:30:06 UTC

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.