Bug 143401 - process hangs when it opens files on copyprotected CD
Summary: process hangs when it opens files on copyprotected CD
Status: RESOLVED INVALID
Alias: None
Product: SUSE Linux 10.1
Classification: openSUSE
Component: Kernel (show other bugs)
Version: Alpha 4
Hardware: i586 Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: E-mail List
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-16 16:39 UTC by Stephan Kulow
Modified: 2006-01-16 17:16 UTC (History)
1 user (show)

See Also:
Found By: Development
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 :)