Re: [PATCH] mount -w of dvd+rw etc. in vanilla 2.6

Re: [PATCH] mount -w of dvd+rw etc. in vanilla 2.6

[Pat LaVarre]

> mount -w -t udf works with my dvd-ram ...
> mistakenly sees my dvd+rw as read-only ...

Besides that Andy Polyakov patch for mount -w of dvd+rw, the web has
Jens Axboe patches for mount -w of cd-rw, via the udf faq (Not via the
udftools faq):

http://sourceforge.net/projects/linux-udf/
udf-0.9.7.tar.gz
FAQ
http://w1.894.telia.com/~u89404340/patches/packet/

---

>From these two clues, kindly offline people have identified the Four
fragments of kernel source that cooperate to conclude erroneously that
dvd+rw etc. are not writable:

1)

drivers/scsi/sr.c understands only the CDC_DVD_RAM profile of the seven
standard mmc "writable" device "profile"s, because sr.c neglects to look
beyond the "Capabilities" mode page x2a i.e. does not look beyond the
mmc 1 standard of 1997.  Ansi did not publish an op x46 Get
Configuration standard until the mmc 2 of 1999.

2)

include/scsi/scsi.h does not yet #define GET_CONFIGURATION 0x46.

3)

drivers/cdrom/cdrom.c also understands only CDC_DVD_RAM: cdrom.c
erroneously claims all mmc profiles except CDC_DVD_RAM are not
FMODE_WRITE-able.

4)

include/linux/cdrom.h names only CDC_DVD_RAM.

---

Anyone have an idea of how best to patch this?

I've seen a few linux-2.6.0-test4/ and linux-2.4.22/ alternatives mostly
work.  Anyone interested in evaluating some of them?

Pat LaVarre

Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?

[Alan Stern]

On Wed, 10 Sep 2003, Georgi Chorbadzhiyski wrote:

> Alan Stern wrote:
> > 
> > More problems with that stupid MODE-SENSE cache page!  There are so many 
> > USB storage devices that have problems with that -- I wonder if it's worth 
> > the effort to try to continue supporting it?

> > If you want a temporary fix for 2.6.0, you can do this:  Edit the 
> > routine sd_read_cache_type in the file drivers/scsi/sd.c (near line 1100).  
> > Get rid of (or #ifdef out) most of the function; just leave the last few 
> > lines where it does:
> > 
> > 		printk(KERN_ERR "%s: assuming drive cache: write through\n",
> > 		       diskname);
> > 		sdkp->WCE = 0;
> > 		sdkp->RCD = 0;
> > 
> > You might want to change the KERN_ERR to KERN_NOTICE.
> 
> Thanks a lot! That worked fine! Now the device is detected and working.

Is there any feeling about how to handle these ongoing problems with the 
mode-sense cache page?  There doesn't seem to be any general solution that 
can work with all USB storage devices.  Some hang when asked to read the 
entire page; some hang when asked to read just part of the page; some hang 
when asked to read just the page header.

What do the SCSI folk have to say about it?

Alan Stern

Re: [usb-storage] Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?

[Pat LaVarre]

> What do the SCSI folk have to say about it?

Anyone?

> > for 2.6.0 ... drivers/scsi/sd.c ...
> > sd_read_cache_type ...
> > Get rid of (or #ifdef out) most ...
>
> Is there any feeling about how to handle these
> ongoing problems with the mode-sense cache
> page?

Yes, much.

Maybe more feeling if you remind/teach me what breaks if we don't fetch
page 8 re Cache.  First I imagine automounters mount read-only disks rw,
and then the write cache gets errors while flushing.  I wonder what else
breaks.  Maybe thruput varies for devices that do or do not bother to
claim they have write cache.

Maybe more feeling if you can say how in/accurate page 8 re Cache
commonly is.  For example, I know of no clear & broadly adopted standard
that requires a device to declare write-behind or background defect map
updates as a form of write cache.

> There doesn't seem to be any general solution
> that can work with all USB storage devices.

I understand you to be saying we can settle for an sd solution, we don't
mind if the sd heuristic we discover then doesn't apply to pdt x05
dvd/cd.

> some hang when asked to read just the page
> header.
> ...
> some hang when asked to read just part of the
> page;
> ...
> Some hang when asked to read the entire page;

Device folk ship bugs, aye, same as host folk.

Are not two of these three failures disproportionately common?

Me, I would expect asking anything but what Windows asks would fail most
often.  Is that not so?  Do we know what Windows asks?  Do we know
if/how Win ME/ 2K/ XP differ here?  Have we matched CBWCB and
dCBWDataTransferLength in every bit?

Pat LaVarre

sg MiB writes scheduling while atomic

[Pat LaVarre]

In reply to `modprobe -r sg`, linux-2.6.0-test5 dmesg tells me:

Debug: sleeping function called from invalid context at
include/linux/rwsem.h:66
...
bad: scheduling while atomic!

Those lines appear in the log below.  The ... ellipses you see were
typed by me, sorry I don't have a more complete intact log, nor have I
yet repeated this result myself.

To provoke this log overnight I ran a shell script to repeat something
like:
pldd of=/dev/sg1 if=/dev/zero bs=1m

The "usb 1-1: sg_complete, unlink --> -19" appeared when or before an
ioctl SG_IO hung.  The Debug/ Call Trace appeared in response to a
`modprobe -r sg` that hung.  I'm confident the cable was not unplugged
because rebooting the system made sg work again.  I'm confident the
drive power was not cycled because reboot provoked only an SK ASC = x 6
29 Reset unit attention, without an SK ASC = x 6 28 GoneReady unit
attention.

[usb-storage] folk tell me some linux-scsi folk may appreciate me
mentioning this.

Pat LaVarre

...
usb-storage: Command WRITE_10 (10 bytes)
usb-storage:  2a 00 00 ce 26 00 00 02 00 00
usb-storage: Bulk Command S 0x43425355 T 0x439c9 L 1048576 F 0 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_sglist: xfer 1048576 bytes, 32 entries
usb-storage: Status code 0; transferred 1048576/1048576
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x439c9 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command WRITE_10 (10 bytes)
usb-storage:  2a 00 00 ce 28 00 00 02 00 00
usb-storage: Bulk Command S 0x43425355 T 0x439ca L 1048576 F 0 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_sglist: xfer 1048576 bytes, 32 entries
usb-storage: Status code 0; transferred 1048576/1048576
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x439ca R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command WRITE_10 (10 bytes)
usb-storage:  2a 00 00 ce 2a 00 00 02 00 00
usb-storage: Bulk Command S 0x43425355 T 0x439cb L 1048576 F 0 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_sglist: xfer 1048576 bytes, 32 entries
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
...

Debug: sleeping function called from invalid context at
include/linux/rwsem.h:66
Call Trace:
 [<c0121f16>] __might_sleep+0x5f/0x72
 [<c0280ec0>] scsi_device_put+0x3c/0xfe
 [<df9179bc>] sg_remove+0x146/0x1bd [sg]
 [<c024db2f>] class_interface_unregister+0x7c/0xc0
 [<df91a7b3>] exit_sg+0x17/0x56 [sg]
 [<c013b533>] sys_delete_module+0x18e/0x1d1
 [<c0151695>] sys_munmap+0x58/0x77
 [<c010b46d>] sysenter_past_esp+0x52/0x71
 
bad: scheduling while atomic!
Call Trace:
 [<c012018e>] schedule+0x57a/0x57f
 [<c01251d6>] printk+0x180/0x1cc
 [<c01eca67>] rwsem_down_write_failed+0xa3/0x15c
 [<c010c279>] dump_stack+0x1e/0x22
 [<c0281189>] .text.lock.scsi+0xa7/0xce
 [<df9179bc>] sg_remove+0x146/0x1bd [sg]
 [<c024db2f>] class_interface_unregister+0x7c/0xc0
 [<df91a7b3>] exit_sg+0x17/0x56 [sg]
 [<c013b533>] sys_delete_module+0x18e/0x1d1
 [<c0151695>] sys_munmap+0x58/0x77
 [<c010b46d>] sysenter_past_esp+0x52/0x71
...

Re: [PATCH] mount -w of dvd+rw etc. in vanilla 2.6

[Pat LaVarre]

Seemingly linux disagrees with itself over how writable profiles are:

# /sbin/blockdev --setro /dev/scd1
# /sbin/blockdev --getro /dev/scd1
1
# dd of=/dev/scd1 if=/dev/zero bs=2K count=1
dd: opening `/dev/scd1': Read-only file system
#

So far so good, but then:

# /sbin/blockdev --setrw /dev/scd1
# /sbin/blockdev --getro /dev/scd1
0
# dd of=/dev/scd1 if=/dev/zero bs=2K count=1
dd: opening `/dev/scd1': Read-only file system
#

That is, no matter if --getro is 0 or 1, still we do not write.  The
default I see here is 0, but still I cannot write.

Pat LaVarre

Re: [PATCH] mount -w of dvd+rw etc. in vanilla 2.6

[Patrick Mansfield]

On Wed, Sep 10, 2003 at 02:08:40PM -0600, Pat LaVarre wrote:

> # /sbin/blockdev --setro /dev/scd1
> # /sbin/blockdev --getro /dev/scd1
> 1
> # dd of=/dev/scd1 if=/dev/zero bs=2K count=1
> dd: opening `/dev/scd1': Read-only file system
> #
> 
> So far so good, but then:
> 
> # /sbin/blockdev --setrw /dev/scd1
> # /sbin/blockdev --getro /dev/scd1
> 0
> # dd of=/dev/scd1 if=/dev/zero bs=2K count=1
> dd: opening `/dev/scd1': Read-only file system
> #
> 
> That is, no matter if --getro is 0 or 1, still we do not write.  The
> default I see here is 0, but still I cannot write.

Should sd.c and sr.c be calling set_device_ro (after adding a read only
block device, or changing back to read/write)?

-- Patrick Mansfield

[PATCH] mount -w of dvd+rw etc. in vanilla 2.6

[Pat LaVarre]

I see mount -w -t udf works with my dvd-ram in
late Linux 2.4 and early 2.6, but mistakenly
sees my dvd+rw as read-only.

To make my dvd+rw work, I find I can apply
patches much like:
http://fy.chalmers.se/~appro/linux/DVD+RW/
http://fy.chalmers.se/~appro/linux/DVD+RW/linux-2.4.patch

Can I somehow help ... to get a patch like this
finished & merged into the kernel.org kernel?

I'm new to drivers/scsi/sr_vendor.c ... but I
first glanced thru www.t10.org back in 1994.

Looks to me like this patch begins to expand the
awareness of Linux beyond the "mode page" x2A of
dvd-ram/cd-rw into the "profile"s and "feature"s
that distinguish dvd+rw etc. from other dvd/cd,
so that with my dvd+rw I achieve:

scsi_CDs[minor].device->writeable = 1;
scsi_CDs[minor].cdi.mask &= ~CDC_DVD_RAM;

In particular, in the patch I see 3 mmc3_profile
values from among the 7 values that mmc4r02c.pdf
says imply the "feature" "0020h" =
"Random Writable".

Can I help somehow?

Pat LaVarre
http://members.aol.com/plscsi/tools/knoppix/

P.S. Reply-to-all will reach me faster than
reply to p.lavarre@ieee.org or linux-scsi alone.


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com