Messages in this thread | | | Date | Sat, 31 Mar 2007 20:23:35 +0200 | From | Rene Herman <> | Subject | Re: mcdx -- do_request(): non-read command to cd!! |
| |
On 03/31/2007 08:47 AM, Jens Axboe wrote:
> Try this. > > diff --git a/drivers/cdrom/mcdx.c b/drivers/cdrom/mcdx.c > index f574962..7086313 100644 > --- a/drivers/cdrom/mcdx.c > +++ b/drivers/cdrom/mcdx.c > @@ -577,6 +577,11 @@ static void do_mcdx_request(request_queue_t * q) > if (!req) > return; > > + if (!blk_fs_request(req)) { > + end_request(req, 0); > + goto again; > + } > + > stuffp = req->rq_disk->private_data; > > if (!stuffp->present) { > @@ -596,7 +601,7 @@ static void do_mcdx_request(request_queue_t * q) > xtrace(REQUEST, "do_request() (%lu + %lu)\n", > req->sector, req->nr_sectors); > > - if (req->cmd != READ) { > + if (rq_data_dir(req) != READ) { > xwarn("do_request(): non-read command to cd!!\n"); > xtrace(REQUEST, "end_request(0): write\n"); > end_request(req, 0); >
Thank you! Yes, that works in so far that it now indeed does actually mount the CD:
root@5va2:~# mount -t iso9660 /dev/mcdx0 /mnt/cdrom mount: block device /dev/mcdx0 is write-protected, mounting read-only root@5va2:~# ls /mnt/cdrom/ dott dott.exe dottdemo indydemo rebel samdemo
There's quite a bit of noise in dmesg though. Repeated 5 times:
===BUG: scheduling while atomic: mount/0x00000001/1166 [<c1170bff>] __sched_text_start+0x57/0x574 [<c1171964>] schedule_timeout+0x70/0x8f [<c10199b2>] process_timeout+0x0/0x5 [<c11716a2>] interruptible_sleep_on_timeout+0x5d/0xa5 [<c100e695>] default_wake_function+0x0/0xc [<c482b8fb>] mcdx_xfer+0xae/0x2a5 [mcdx] [<c109bc78>] cfq_init_prio_data+0x57/0x12a [<c109bef2>] cfq_get_queue+0x119/0x16e [<c109c73b>] cfq_set_request+0x0/0x131 [<c1094f29>] elv_set_request+0x14/0x22 [<c10948c7>] elv_rb_del+0x23/0x31 [<c109b186>] cfq_remove_request+0x63/0xd9 [<c1094911>] elv_dispatch_sort+0x1c/0x67 [<c109b63c>] cfq_dispatch_insert+0x38/0x4c [<c109b726>] __cfq_dispatch_requests+0x72/0x1ad [<c109b95f>] cfq_dispatch_requests+0x50/0x77 [<c10622eb>] sync_buffer+0x0/0x2e [<c1094de9>] elv_next_request+0x5d/0x105 [<c10622eb>] sync_buffer+0x0/0x2e [<c482b473>] do_mcdx_request+0x9b/0xd2 [mcdx] [<c1096d06>] __generic_unplug_device+0x1d/0x1f [<c1096d19>] generic_unplug_device+0x11/0x29 [<c1096d3d>] blk_backing_dev_unplug+0xc/0xd [<c1062311>] sync_buffer+0x26/0x2e [<c11719d3>] __wait_on_bit+0x2c/0x51 [<c1171a67>] out_of_line_wait_on_bit+0x6f/0x77 [<c10622eb>] sync_buffer+0x0/0x2e [<c102218c>] wake_bit_function+0x0/0x3c [<c102218c>] wake_bit_function+0x0/0x3c [<c1062371>] __wait_on_buffer+0x22/0x25 [<c10631c1>] __bread_slow+0x4b/0x60 [<c10633ad>] __bread+0x18/0x1d [<c486f9cf>] isofs_fill_super+0xf0/0x5d7 [isofs] [<c10a016d>] radix_tree_delete+0x177/0x1a0 [<c104971f>] get_sb_bdev+0xc6/0x10f [<c1059af0>] mntput_no_expire+0x11/0x73 [<c10596bf>] alloc_vfsmnt+0x97/0xbe [<c4870863>] isofs_get_sb+0x20/0x25 [isofs] [<c486f8df>] isofs_fill_super+0x0/0x5d7 [isofs] [<c10498ea>] vfs_kern_mount+0x40/0x6f [<c1049943>] do_kern_mount+0x2a/0x3a [<c105a8e0>] do_new_mount+0x64/0x93 [<c105af29>] do_mount+0x185/0x19a [<c100e75c>] __wake_up_locked+0x1e/0x20 [<c100e695>] default_wake_function+0x0/0xc [<c105b1c4>] sys_mount+0x79/0xb5 [<c1002830>] syscall_call+0x7/0xb ===
Any access results in te above. A copy from the CD segfaulted:
=== root@5va2:~# cp /mnt/cdrom/dott.exe .
malloc: unwind_prot.c:247: assertion botched free: called with unallocated block argument Segmentation fault ===
This sounds like a userspace problem but I sure haven't seen it before. There's a few "blk: request botched" followed by similar backtraces in the log after that.
It looks like mcdx_xfer() is seriously broken. If you don't particularly care for spending time on this thing -- feel free. To top it off, if you unload the module, it doesn't clean up after itself and the IRQ is kept in use (and a cat /proc/interrupts faults).
I'm only using the thing for the heck of it...
Rene.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |