Bug 143401

Summary: process hangs when it opens files on copyprotected CD
Product: [openSUSE] SUSE Linux 10.1 Reporter: Stephan Kulow <coolo>
Component: KernelAssignee: E-mail List <kernel-maintainers>
Status: RESOLVED INVALID QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: matz
Version: Alpha 4   
Target Milestone: ---   
Hardware: i586   
OS: Other   
Whiteboard:
Found By: Development Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Stephan Kulow 2006-01-16 16:39:31 UTC
Hi!

I opened /media/cdrecorder in konqueror - and konqueror does some file magic to get a nice icon. But 0002.tmp on that CD is some strange copy protection for windows games and then the KIO slave hang in D for at least 5 min, only then it got an EIO.

Jan asked me to file the bug report with the information as 5 min is pretty long - following is the sysrq-t information of the hung process.

Jan 16 16:30:51 titania klogd: kio_media     D F7CA3BB8     0 16106  15886         16107 16094 (NOTLB)
Jan 16 16:30:51 titania klogd: f6697dcc 00000000 00000009 f7ca3bb8 f7ca3a90 9365b300 003d091c 00000000
Jan 16 16:30:51 titania klogd:        9365b300 003d091c 03d09000 00000000 f6697e18 f6697e18 c1aa7990 f6697dd4
Jan 16 16:30:51 titania klogd:        c1174393 c1033408 c103343b c1174575 f6697e18 c169e5e0 f6697e14 00000000
Jan 16 16:30:51 titania klogd: Call Trace:
Jan 16 16:30:51 titania klogd:  [<c1174393>] io_schedule+0xe/0x16
Jan 16 16:30:51 titania klogd:  [<c1033408>] sync_page+0x0/0x36
Jan 16 16:30:51 titania klogd:  [<c103343b>] sync_page+0x33/0x36
Jan 16 16:30:51 titania klogd:  [<c1174575>] __wait_on_bit_lock+0x2a/0x51
Jan 16 16:30:51 titania klogd:  [<c10339cc>] __lock_page+0x60/0x67
Jan 16 16:30:51 titania klogd:  [<c1025a0a>] wake_bit_function+0x0/0x3c
Jan 16 16:30:51 titania klogd:  [<c1033e1e>] do_generic_mapping_read+0x225/0x3eb
Jan 16 16:30:51 titania klogd:  [<c10341fd>] __generic_file_aio_read+0x148/0x18f
Jan 16 16:30:51 titania klogd:  [<c1033fe4>] file_read_actor+0x0/0xd1
Jan 16 16:30:51 titania klogd:  [<c1034286>] generic_file_read+0x0/0xac
Jan 16 16:30:51 titania klogd:  [<c103431e>] generic_file_read+0x98/0xac
Jan 16 16:30:51 titania klogd:  [<c10259dd>] autoremove_wake_function+0x0/0x2d
Jan 16 16:30:51 titania klogd:  [<c104ab09>] filp_open+0x27/0x2d
Jan 16 16:30:51 titania klogd:  [<c104b389>] vfs_read+0x9f/0x144
Jan 16 16:30:51 titania klogd:  [<c104b6a3>] sys_read+0x3c/0x63
Jan 16 16:30:51 titania klogd:  [<c1002a7b>] sysenter_past_esp+0x54/0x79
Comment 1 Stephan Kulow 2006-01-16 16:48:51 UTC
Matz believes the hardware does not even react in time
Comment 2 Michael Matz 2006-01-16 17:15:50 UTC
Note, though, that even if the timeout value is reduced (and it can't be
reduced to zero, otherwise it could hit for cdroms with slow spinup) such
accesses will still look hanging, as every request would hit that timeout.
Comment 3 Stephan Kulow 2006-01-16 17:16:42 UTC
ok, screw that. I did a test under windows and windows kills "Explorer D: (not responding)" after some time - and I did not send a report to Microsoft even though it asked :)