2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-11 13:16:10 +01:00
|
|
|
|
2008-08-31 10:41:52 -05:00
|
|
|
|
2009-01-04 05:32:28 -08:00
|
|
|
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 17:04:11 +09:00
|
|
|
|
2017-06-19 14:26:46 +02:00
|
|
|
|
2011-12-05 09:20:26 +08:00
|
|
|
|
2015-10-15 14:10:49 +02:00
|
|
|
|
2016-09-11 19:35:41 +02:00
|
|
|
|
2016-12-24 11:46:01 -08:00
|
|
|
|
2009-04-21 16:43:27 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-17 12:47:32 -04:00
|
|
|
|
2012-03-22 17:05:11 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-03-08 00:14:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[SCSI] modalias for scsi devices
The following patch adds support for sysfs/uevent modalias
attribute for scsi devices (like disks, tapes, cdroms etc),
based on whatever current sd.c, sr.c, st.c and osst.c drivers
supports.
The modalias format is like this:
scsi:type-0x04
(for TYPE_WORM, handled by sr.c now).
Several comments.
o This hexadecimal type value is because all TYPE_XXX constants
in include/scsi/scsi.h are given in hex, but __stringify() will
not convert them to decimal (so it will NOT be scsi:type-4).
Since it does not really matter in which format it is, while
both modalias in module and modalias attribute match each other,
I descided to go for that 0x%02x format (and added a comment in
include/scsi/scsi.h to keep them that way), instead of changing
them all to decimal.
o There was no .uevent routine for SCSI bus. It might be a good
idea to add some more ueven environment variables in there.
o osst.c driver handles tapes too, like st.c, but only SOME tapes.
With this setup, hotplug scripts (or whatever is used by the
user) will try to load both st and osst modules for all SCSI
tapes found, because both modules have scsi:type-0x01 alias).
It is not harmful, but one extra module is no good either.
It is possible to solve this, by exporting more info in
modalias attribute, including vendor and device identification
strings, so that modalias becomes something like
scsi:type-0x12:vendor-Adaptec LTD:device-OnStream Tape Drive
and having that, match for all 3 attributes, not only device
type. But oh well, vendor and device strings may be large,
and they do contain spaces and whatnot.
So I left them for now, awaiting for comments first.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-10-27 16:02:37 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
2006-03-08 00:14:20 -08:00
|
|
|
|
2008-08-25 19:47:25 +09:00
|
|
|
|
2008-08-25 19:47:24 +09:00
|
|
|
|
2008-08-25 19:47:25 +09:00
|
|
|
|
2008-08-25 19:56:17 +09:00
|
|
|
|
2008-08-25 19:47:25 +09:00
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
Revert "scsi: revert "[SCSI] Get rid of scsi_cmnd->done""
This reverts commit ac40532ef0b8649e6f7f83859ea0de1c4ed08a19, which gets
us back the original cleanup of 6f5391c283d7fdcf24bf40786ea79061919d1e1d.
It turns out that the bug that was triggered by that commit was
apparently not actually triggered by that commit at all, and just the
testing conditions had changed enough to make it appear to be due to it.
The real problem seems to have been found by Peter Osterlund:
"pktcdvd sets it [block device size] when opening the /dev/pktcdvd
device, but when the drive is later opened as /dev/scd0, there is
nothing that sets it back. (Btw, 40944 is possible if the disk is a
CDRW that was formatted with "cdrwtool -m 10236".)
The problem is that pktcdvd opens the cd device in non-blocking mode
when pktsetup is run, and doesn't close it again until pktsetup -d is
run. The effect is that if you meanwhile open the cd device,
blkdev.c:do_open() doesn't call bd_set_size() because
bdev->bd_openers is non-zero."
In particular, to repeat the bug (regardless of whether commit
6f5391c283d7fdcf24bf40786ea79061919d1e1d is applied or not):
" 1. Start with an empty drive.
2. pktsetup 0 /dev/scd0
3. Insert a CD containing an isofs filesystem.
4. mount /dev/pktcdvd/0 /mnt/tmp
5. umount /mnt/tmp
6. Press the eject button.
7. Insert a DVD containing a non-writable filesystem.
8. mount /dev/scd0 /mnt/tmp
9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
10. If the DVD contains data beyond the physical size of a CD, you
get I/O errors in the terminal, and dmesg reports lots of
"attempt to access beyond end of device" errors."
which in turn is because the nested open after the media change won't
cause the size to be set properly (because the original open still holds
the block device, and we only do the bd_set_size() when we don't have
other people holding the device open).
The proper fix for that is probably to just do something like
bdev->bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
in fs/block_dev.c:do_open() even for the cases where we're not the
original opener (but *not* call bd_set_size(), since that will also
change the block size of the device).
Cc: Peter Osterlund <petero2@telia.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-06 10:17:12 -08:00
|
|
|
|
2010-05-15 20:09:32 +02:00
|
|
|
|
Revert "scsi: revert "[SCSI] Get rid of scsi_cmnd->done""
This reverts commit ac40532ef0b8649e6f7f83859ea0de1c4ed08a19, which gets
us back the original cleanup of 6f5391c283d7fdcf24bf40786ea79061919d1e1d.
It turns out that the bug that was triggered by that commit was
apparently not actually triggered by that commit at all, and just the
testing conditions had changed enough to make it appear to be due to it.
The real problem seems to have been found by Peter Osterlund:
"pktcdvd sets it [block device size] when opening the /dev/pktcdvd
device, but when the drive is later opened as /dev/scd0, there is
nothing that sets it back. (Btw, 40944 is possible if the disk is a
CDRW that was formatted with "cdrwtool -m 10236".)
The problem is that pktcdvd opens the cd device in non-blocking mode
when pktsetup is run, and doesn't close it again until pktsetup -d is
run. The effect is that if you meanwhile open the cd device,
blkdev.c:do_open() doesn't call bd_set_size() because
bdev->bd_openers is non-zero."
In particular, to repeat the bug (regardless of whether commit
6f5391c283d7fdcf24bf40786ea79061919d1e1d is applied or not):
" 1. Start with an empty drive.
2. pktsetup 0 /dev/scd0
3. Insert a CD containing an isofs filesystem.
4. mount /dev/pktcdvd/0 /mnt/tmp
5. umount /mnt/tmp
6. Press the eject button.
7. Insert a DVD containing a non-writable filesystem.
8. mount /dev/scd0 /mnt/tmp
9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
10. If the DVD contains data beyond the physical size of a CD, you
get I/O errors in the terminal, and dmesg reports lots of
"attempt to access beyond end of device" errors."
which in turn is because the nested open after the media change won't
cause the size to be set properly (because the original open still holds
the block device, and we only do the bd_set_size() when we don't have
other people holding the device open).
The proper fix for that is probably to just do something like
bdev->bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
in fs/block_dev.c:do_open() even for the cases where we're not the
original opener (but *not* call bd_set_size(), since that will also
change the block size of the device).
Cc: Peter Osterlund <petero2@telia.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-06 10:17:12 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
|
|
|
|
|
Revert "scsi: revert "[SCSI] Get rid of scsi_cmnd->done""
This reverts commit ac40532ef0b8649e6f7f83859ea0de1c4ed08a19, which gets
us back the original cleanup of 6f5391c283d7fdcf24bf40786ea79061919d1e1d.
It turns out that the bug that was triggered by that commit was
apparently not actually triggered by that commit at all, and just the
testing conditions had changed enough to make it appear to be due to it.
The real problem seems to have been found by Peter Osterlund:
"pktcdvd sets it [block device size] when opening the /dev/pktcdvd
device, but when the drive is later opened as /dev/scd0, there is
nothing that sets it back. (Btw, 40944 is possible if the disk is a
CDRW that was formatted with "cdrwtool -m 10236".)
The problem is that pktcdvd opens the cd device in non-blocking mode
when pktsetup is run, and doesn't close it again until pktsetup -d is
run. The effect is that if you meanwhile open the cd device,
blkdev.c:do_open() doesn't call bd_set_size() because
bdev->bd_openers is non-zero."
In particular, to repeat the bug (regardless of whether commit
6f5391c283d7fdcf24bf40786ea79061919d1e1d is applied or not):
" 1. Start with an empty drive.
2. pktsetup 0 /dev/scd0
3. Insert a CD containing an isofs filesystem.
4. mount /dev/pktcdvd/0 /mnt/tmp
5. umount /mnt/tmp
6. Press the eject button.
7. Insert a DVD containing a non-writable filesystem.
8. mount /dev/scd0 /mnt/tmp
9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
10. If the DVD contains data beyond the physical size of a CD, you
get I/O errors in the terminal, and dmesg reports lots of
"attempt to access beyond end of device" errors."
which in turn is because the nested open after the media change won't
cause the size to be set properly (because the original open still holds
the block device, and we only do the bd_set_size() when we don't have
other people holding the device open).
The proper fix for that is probably to just do something like
bdev->bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
in fs/block_dev.c:do_open() even for the cases where we're not the
original opener (but *not* call bd_set_size(), since that will also
change the block size of the device).
Cc: Peter Osterlund <petero2@telia.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-06 10:17:12 -08:00
|
|
|
|
|
|
|
|
|
2014-05-01 16:51:04 +02:00
|
|
|
|
|
|
|
|
|
Revert "scsi: revert "[SCSI] Get rid of scsi_cmnd->done""
This reverts commit ac40532ef0b8649e6f7f83859ea0de1c4ed08a19, which gets
us back the original cleanup of 6f5391c283d7fdcf24bf40786ea79061919d1e1d.
It turns out that the bug that was triggered by that commit was
apparently not actually triggered by that commit at all, and just the
testing conditions had changed enough to make it appear to be due to it.
The real problem seems to have been found by Peter Osterlund:
"pktcdvd sets it [block device size] when opening the /dev/pktcdvd
device, but when the drive is later opened as /dev/scd0, there is
nothing that sets it back. (Btw, 40944 is possible if the disk is a
CDRW that was formatted with "cdrwtool -m 10236".)
The problem is that pktcdvd opens the cd device in non-blocking mode
when pktsetup is run, and doesn't close it again until pktsetup -d is
run. The effect is that if you meanwhile open the cd device,
blkdev.c:do_open() doesn't call bd_set_size() because
bdev->bd_openers is non-zero."
In particular, to repeat the bug (regardless of whether commit
6f5391c283d7fdcf24bf40786ea79061919d1e1d is applied or not):
" 1. Start with an empty drive.
2. pktsetup 0 /dev/scd0
3. Insert a CD containing an isofs filesystem.
4. mount /dev/pktcdvd/0 /mnt/tmp
5. umount /mnt/tmp
6. Press the eject button.
7. Insert a DVD containing a non-writable filesystem.
8. mount /dev/scd0 /mnt/tmp
9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
10. If the DVD contains data beyond the physical size of a CD, you
get I/O errors in the terminal, and dmesg reports lots of
"attempt to access beyond end of device" errors."
which in turn is because the nested open after the media change won't
cause the size to be set properly (because the original open still holds
the block device, and we only do the bd_set_size() when we don't have
other people holding the device open).
The proper fix for that is probably to just do something like
bdev->bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
in fs/block_dev.c:do_open() even for the cases where we're not the
original opener (but *not* call bd_set_size(), since that will also
change the block size of the device).
Cc: Peter Osterlund <petero2@telia.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-06 10:17:12 -08:00
|
|
|
|
2017-04-06 15:36:29 +02:00
|
|
|
|
2013-11-11 13:44:53 +01:00
|
|
|
|
Revert "scsi: revert "[SCSI] Get rid of scsi_cmnd->done""
This reverts commit ac40532ef0b8649e6f7f83859ea0de1c4ed08a19, which gets
us back the original cleanup of 6f5391c283d7fdcf24bf40786ea79061919d1e1d.
It turns out that the bug that was triggered by that commit was
apparently not actually triggered by that commit at all, and just the
testing conditions had changed enough to make it appear to be due to it.
The real problem seems to have been found by Peter Osterlund:
"pktcdvd sets it [block device size] when opening the /dev/pktcdvd
device, but when the drive is later opened as /dev/scd0, there is
nothing that sets it back. (Btw, 40944 is possible if the disk is a
CDRW that was formatted with "cdrwtool -m 10236".)
The problem is that pktcdvd opens the cd device in non-blocking mode
when pktsetup is run, and doesn't close it again until pktsetup -d is
run. The effect is that if you meanwhile open the cd device,
blkdev.c:do_open() doesn't call bd_set_size() because
bdev->bd_openers is non-zero."
In particular, to repeat the bug (regardless of whether commit
6f5391c283d7fdcf24bf40786ea79061919d1e1d is applied or not):
" 1. Start with an empty drive.
2. pktsetup 0 /dev/scd0
3. Insert a CD containing an isofs filesystem.
4. mount /dev/pktcdvd/0 /mnt/tmp
5. umount /mnt/tmp
6. Press the eject button.
7. Insert a DVD containing a non-writable filesystem.
8. mount /dev/scd0 /mnt/tmp
9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
10. If the DVD contains data beyond the physical size of a CD, you
get I/O errors in the terminal, and dmesg reports lots of
"attempt to access beyond end of device" errors."
which in turn is because the nested open after the media change won't
cause the size to be set properly (because the original open still holds
the block device, and we only do the bd_set_size() when we don't have
other people holding the device open).
The proper fix for that is probably to just do something like
bdev->bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
in fs/block_dev.c:do_open() even for the cases where we're not the
original opener (but *not* call bd_set_size(), since that will also
change the block size of the device).
Cc: Peter Osterlund <petero2@telia.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-06 10:17:12 -08:00
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
Revert "scsi: revert "[SCSI] Get rid of scsi_cmnd->done""
This reverts commit ac40532ef0b8649e6f7f83859ea0de1c4ed08a19, which gets
us back the original cleanup of 6f5391c283d7fdcf24bf40786ea79061919d1e1d.
It turns out that the bug that was triggered by that commit was
apparently not actually triggered by that commit at all, and just the
testing conditions had changed enough to make it appear to be due to it.
The real problem seems to have been found by Peter Osterlund:
"pktcdvd sets it [block device size] when opening the /dev/pktcdvd
device, but when the drive is later opened as /dev/scd0, there is
nothing that sets it back. (Btw, 40944 is possible if the disk is a
CDRW that was formatted with "cdrwtool -m 10236".)
The problem is that pktcdvd opens the cd device in non-blocking mode
when pktsetup is run, and doesn't close it again until pktsetup -d is
run. The effect is that if you meanwhile open the cd device,
blkdev.c:do_open() doesn't call bd_set_size() because
bdev->bd_openers is non-zero."
In particular, to repeat the bug (regardless of whether commit
6f5391c283d7fdcf24bf40786ea79061919d1e1d is applied or not):
" 1. Start with an empty drive.
2. pktsetup 0 /dev/scd0
3. Insert a CD containing an isofs filesystem.
4. mount /dev/pktcdvd/0 /mnt/tmp
5. umount /mnt/tmp
6. Press the eject button.
7. Insert a DVD containing a non-writable filesystem.
8. mount /dev/scd0 /mnt/tmp
9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
10. If the DVD contains data beyond the physical size of a CD, you
get I/O errors in the terminal, and dmesg reports lots of
"attempt to access beyond end of device" errors."
which in turn is because the nested open after the media change won't
cause the size to be set properly (because the original open still holds
the block device, and we only do the bd_set_size() when we don't have
other people holding the device open).
The proper fix for that is probably to just do something like
bdev->bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
in fs/block_dev.c:do_open() even for the cases where we're not the
original opener (but *not* call bd_set_size(), since that will also
change the block size of the device).
Cc: Peter Osterlund <petero2@telia.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-06 10:17:12 -08:00
|
|
|
|
2014-10-24 14:27:00 +02:00
|
|
|
|
Revert "scsi: revert "[SCSI] Get rid of scsi_cmnd->done""
This reverts commit ac40532ef0b8649e6f7f83859ea0de1c4ed08a19, which gets
us back the original cleanup of 6f5391c283d7fdcf24bf40786ea79061919d1e1d.
It turns out that the bug that was triggered by that commit was
apparently not actually triggered by that commit at all, and just the
testing conditions had changed enough to make it appear to be due to it.
The real problem seems to have been found by Peter Osterlund:
"pktcdvd sets it [block device size] when opening the /dev/pktcdvd
device, but when the drive is later opened as /dev/scd0, there is
nothing that sets it back. (Btw, 40944 is possible if the disk is a
CDRW that was formatted with "cdrwtool -m 10236".)
The problem is that pktcdvd opens the cd device in non-blocking mode
when pktsetup is run, and doesn't close it again until pktsetup -d is
run. The effect is that if you meanwhile open the cd device,
blkdev.c:do_open() doesn't call bd_set_size() because
bdev->bd_openers is non-zero."
In particular, to repeat the bug (regardless of whether commit
6f5391c283d7fdcf24bf40786ea79061919d1e1d is applied or not):
" 1. Start with an empty drive.
2. pktsetup 0 /dev/scd0
3. Insert a CD containing an isofs filesystem.
4. mount /dev/pktcdvd/0 /mnt/tmp
5. umount /mnt/tmp
6. Press the eject button.
7. Insert a DVD containing a non-writable filesystem.
8. mount /dev/scd0 /mnt/tmp
9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
10. If the DVD contains data beyond the physical size of a CD, you
get I/O errors in the terminal, and dmesg reports lots of
"attempt to access beyond end of device" errors."
which in turn is because the nested open after the media change won't
cause the size to be set properly (because the original open still holds
the block device, and we only do the bd_set_size() when we don't have
other people holding the device open).
The proper fix for that is probably to just do something like
bdev->bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
in fs/block_dev.c:do_open() even for the cases where we're not the
original opener (but *not* call bd_set_size(), since that will also
change the block size of the device).
Cc: Peter Osterlund <petero2@telia.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-06 10:17:12 -08:00
|
|
|
|
2009-02-21 11:04:45 +09:00
|
|
|
|
2008-07-14 14:59:30 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-11 13:16:10 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-08-10 18:01:20 -07:00
|
|
|
|
|
|
|
|
|
2009-09-20 16:49:38 -04:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-03 17:37:30 +08:00
|
|
|
|
|
|
|
|
|
2016-03-30 10:06:11 -06:00
|
|
|
|
2014-06-03 17:37:30 +08:00
|
|
|
|
|
|
|
|
|
2016-03-30 10:06:11 -06:00
|
|
|
|
2014-06-03 17:37:30 +08:00
|
|
|
|
2016-03-30 10:06:11 -06:00
|
|
|
|
2014-06-03 17:37:30 +08:00
|
|
|
|
|
|
|
|
|
2016-03-30 10:06:11 -06:00
|
|
|
|
2014-06-03 17:37:30 +08:00
|
|
|
|
|
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
|
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-27 19:07:19 +01:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
|
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-24 14:02:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
2014-08-11 15:40:37 +03:00
|
|
|
|
2013-04-24 14:02:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-03 17:37:30 +08:00
|
|
|
|
2013-04-24 14:02:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-25 03:08:30 -08:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
sd: Clear PS bit before Mode Select.
According to SPC-4, in a Mode Select, the PS bit in Mode Pages is
reserved and must be set to 0 by the driver. In the sd implementation,
function cache_type_store does a Mode Sense, which might set the PS bit
on the read buffer, followed by a Mode Select, which receives the same
buffer, without explicitly clearing the PS bit. So, in cases where
target supports saving the Mode Page to a non-volatile location, we end
up doing a Mode Select with the PS bit set, which could cause an illegal
request error if the target is checking this.
This was observed on a new firmware change, which was subsequently
reverted, but this changes sd.c to be more compliant with SPC-4.
This patch clears the PS bit in the buffer returned by Mode Select,
right before it is used in the Mode Select command.
Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2015-10-30 16:04:43 -02:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
|
|
|
|
|
2008-09-04 14:27:35 -06:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
2017-10-12 14:57:06 +08:00
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-12 14:57:06 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-27 11:10:31 -05:00
|
|
|
|
2017-10-12 14:56:44 +08:00
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2006-06-27 11:10:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
2006-06-27 11:10:31 -05:00
|
|
|
|
|
|
|
|
|
2017-10-12 14:56:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-27 11:10:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
2006-06-27 11:10:31 -05:00
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
|
|
|
|
|
2008-07-17 04:28:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2008-07-17 04:28:34 -04:00
|
|
|
|
|
|
|
|
|
2012-08-28 14:29:34 -04:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
|
|
|
|
|
2012-08-28 14:29:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-25 13:46:35 -07:00
|
|
|
|
2012-08-28 14:29:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
2012-08-28 14:29:34 -04:00
|
|
|
|
2010-10-08 01:36:24 -04:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
|
|
|
|
|
2010-10-08 01:36:24 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-11 19:35:41 +02:00
|
|
|
|
2010-10-08 01:36:24 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2010-10-08 01:36:24 -04:00
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2010-10-08 01:36:24 -04:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
2010-10-08 01:36:24 -04:00
|
|
|
|
2008-07-17 04:28:34 -04:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
2008-07-17 04:28:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2008-07-17 04:28:34 -04:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
2008-07-17 04:28:34 -04:00
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
|
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2017-04-05 19:21:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2017-04-05 19:21:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2017-04-05 19:21:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
|
|
|
|
|
2017-04-05 19:21:24 +02:00
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
|
|
|
|
|
2017-04-05 19:21:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-09 13:48:53 -05:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
|
|
|
|
|
2012-02-09 13:48:53 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2012-02-09 13:48:53 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-09 13:48:53 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
2012-02-09 13:48:53 -05:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-06 22:15:55 -04:00
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
2013-06-06 22:15:55 -04:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-05 19:21:24 +02:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2013-07-24 15:05:28 -07:00
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-11-09 15:27:55 +08:00
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
2012-11-09 15:27:55 +08:00
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
2012-11-09 15:27:55 +08:00
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
2012-11-09 15:27:55 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-12 18:34:51 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-09 15:27:55 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-05-01 16:51:04 +02:00
|
|
|
|
|
|
|
|
|
Revert "scsi: revert "[SCSI] Get rid of scsi_cmnd->done""
This reverts commit ac40532ef0b8649e6f7f83859ea0de1c4ed08a19, which gets
us back the original cleanup of 6f5391c283d7fdcf24bf40786ea79061919d1e1d.
It turns out that the bug that was triggered by that commit was
apparently not actually triggered by that commit at all, and just the
testing conditions had changed enough to make it appear to be due to it.
The real problem seems to have been found by Peter Osterlund:
"pktcdvd sets it [block device size] when opening the /dev/pktcdvd
device, but when the drive is later opened as /dev/scd0, there is
nothing that sets it back. (Btw, 40944 is possible if the disk is a
CDRW that was formatted with "cdrwtool -m 10236".)
The problem is that pktcdvd opens the cd device in non-blocking mode
when pktsetup is run, and doesn't close it again until pktsetup -d is
run. The effect is that if you meanwhile open the cd device,
blkdev.c:do_open() doesn't call bd_set_size() because
bdev->bd_openers is non-zero."
In particular, to repeat the bug (regardless of whether commit
6f5391c283d7fdcf24bf40786ea79061919d1e1d is applied or not):
" 1. Start with an empty drive.
2. pktsetup 0 /dev/scd0
3. Insert a CD containing an isofs filesystem.
4. mount /dev/pktcdvd/0 /mnt/tmp
5. umount /mnt/tmp
6. Press the eject button.
7. Insert a DVD containing a non-writable filesystem.
8. mount /dev/scd0 /mnt/tmp
9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
10. If the DVD contains data beyond the physical size of a CD, you
get I/O errors in the terminal, and dmesg reports lots of
"attempt to access beyond end of device" errors."
which in turn is because the nested open after the media change won't
cause the size to be set properly (because the original open still holds
the block device, and we only do the bd_set_size() when we don't have
other people holding the device open).
The proper fix for that is probably to just do something like
bdev->bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
in fs/block_dev.c:do_open() even for the cases where we're not the
original opener (but *not* call bd_set_size(), since that will also
change the block size of the device).
Cc: Peter Osterlund <petero2@telia.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-06 10:17:12 -08:00
|
|
|
|
2012-02-09 13:48:53 -05:00
|
|
|
|
2017-04-06 15:36:29 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-05-10 11:06:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 14:01:25 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 14:01:25 +01:00
|
|
|
|
|
|
|
|
|
2005-11-04 14:44:41 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2005-11-04 14:44:41 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-11 13:16:10 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-11 13:16:10 +01:00
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-11 13:16:10 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-06-19 14:26:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-26 19:20:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-11 19:35:41 +02:00
|
|
|
|
2014-09-26 19:20:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-18 17:33:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-26 19:20:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-18 17:33:00 -04:00
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-05 19:21:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-13 15:39:00 -05:00
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
2017-05-25 09:34:30 -04:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
2015-07-14 08:15:12 -06:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-09-27 21:35:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-09-27 21:35:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-14 08:15:12 -06:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-05 19:20:59 +02:00
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
2014-06-28 12:35:13 +02:00
|
|
|
|
2017-04-05 19:20:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
2017-04-05 19:20:59 +02:00
|
|
|
|
|
|
|
|
|
2010-06-18 16:59:42 +02:00
|
|
|
|
2016-12-08 15:20:32 -07:00
|
|
|
|
2017-04-05 19:20:59 +02:00
|
|
|
|
2016-12-08 15:20:32 -07:00
|
|
|
|
|
|
|
|
|
2017-04-05 19:20:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-05 19:21:02 +02:00
|
|
|
|
2017-04-05 19:20:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-05 19:21:02 +02:00
|
|
|
|
|
|
|
|
|
2017-04-05 19:20:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-05 19:21:02 +02:00
|
|
|
|
2017-04-05 19:20:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-05 19:21:02 +02:00
|
|
|
|
2017-04-05 19:20:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-01 19:49:18 +09:00
|
|
|
|
|
|
|
|
|
2017-04-05 19:21:02 +02:00
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
2014-06-28 12:35:13 +02:00
|
|
|
|
|
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
2017-04-05 19:21:02 +02:00
|
|
|
|
|
|
|
|
|
2017-05-08 15:48:19 +09:00
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
2017-04-05 19:21:12 +02:00
|
|
|
|
2017-04-05 19:21:24 +02:00
|
|
|
|
|
|
|
|
|
2017-05-08 15:48:19 +09:00
|
|
|
|
|
|
|
|
|
2017-04-05 19:21:24 +02:00
|
|
|
|
2017-05-08 15:48:19 +09:00
|
|
|
|
|
|
|
|
|
2017-04-05 19:21:12 +02:00
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
|
|
|
|
|
2017-04-05 19:21:02 +02:00
|
|
|
|
|
|
|
|
|
2017-05-08 15:48:19 +09:00
|
|
|
|
2017-04-05 19:21:02 +02:00
|
|
|
|
2017-05-08 15:48:19 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-01 19:49:18 +09:00
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-06 22:15:55 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
2017-04-05 19:21:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
2013-06-06 22:15:55 -04:00
|
|
|
|
|
|
|
|
|
2017-04-05 19:21:02 +02:00
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-28 12:22:22 +02:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
2017-04-24 16:51:09 +09:00
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
2014-06-28 12:22:22 +02:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
2014-06-28 12:22:22 +02:00
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-25 13:43:56 -08:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-04 00:52:12 -05:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
2013-08-07 14:24:32 -07:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
2017-04-24 16:51:13 +09:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-28 12:22:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
2014-06-28 12:22:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
2014-06-28 12:22:22 +02:00
|
|
|
|
2014-06-28 12:29:19 +02:00
|
|
|
|
2017-01-25 13:43:56 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-08 14:59:02 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-25 13:43:56 -08:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
2014-06-28 12:08:05 +02:00
|
|
|
|
2010-07-03 17:45:34 +09:00
|
|
|
|
2014-06-28 12:08:05 +02:00
|
|
|
|
2010-07-03 17:45:34 +09:00
|
|
|
|
2014-06-28 12:08:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-18 17:11:27 +02:00
|
|
|
|
2014-06-28 12:08:05 +02:00
|
|
|
|
2010-07-03 17:45:34 +09:00
|
|
|
|
|
|
|
|
|
2014-06-28 12:40:18 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-05-01 16:51:04 +02:00
|
|
|
|
|
|
|
|
|
2006-01-06 18:34:07 +01:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
2009-05-07 22:24:39 +09:00
|
|
|
|
2008-08-05 21:42:21 -07:00
|
|
|
|
2009-05-07 22:24:39 +09:00
|
|
|
|
2014-09-26 19:20:08 -04:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
2014-09-26 19:20:08 -04:00
|
|
|
|
2009-09-20 16:49:38 -04:00
|
|
|
|
2007-08-04 10:06:25 -05:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
2017-04-24 16:51:13 +09:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-05 18:20:23 -07:00
|
|
|
|
2007-08-04 10:06:25 -05:00
|
|
|
|
|
|
|
|
|
2017-08-25 13:46:33 -07:00
|
|
|
|
2007-08-04 10:06:25 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-05-01 16:51:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-05-07 22:24:39 +09:00
|
|
|
|
2007-02-27 22:41:19 -05:00
|
|
|
|
2009-05-07 22:24:39 +09:00
|
|
|
|
|
|
|
|
|
2007-02-27 22:41:19 -05:00
|
|
|
|
|
|
|
|
|
2007-08-04 10:06:25 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-07 11:44:01 -04:00
|
|
|
|
2007-08-04 10:06:25 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-08-04 10:06:25 -05:00
|
|
|
|
2008-01-20 11:12:26 +01:00
|
|
|
|
2008-08-05 21:42:21 -07:00
|
|
|
|
|
|
|
|
|
2008-01-20 11:12:26 +01:00
|
|
|
|
2008-08-05 21:42:21 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-20 11:12:26 +01:00
|
|
|
|
2007-02-27 22:41:19 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-07 22:24:39 +09:00
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
|
|
|
|
|
2007-08-04 10:06:25 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-07 22:24:39 +09:00
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
|
|
|
|
|
2007-08-04 10:06:25 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-07 22:24:39 +09:00
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
|
|
|
|
|
2007-08-04 10:06:25 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-17 04:28:35 -04:00
|
|
|
|
2012-08-28 14:29:33 -04:00
|
|
|
|
2014-09-26 19:20:08 -04:00
|
|
|
|
2008-07-17 04:28:35 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-28 08:48:16 -06:00
|
|
|
|
2007-08-04 10:06:25 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-27 22:41:19 -05:00
|
|
|
|
2009-05-07 22:24:39 +09:00
|
|
|
|
2007-02-27 22:41:19 -05:00
|
|
|
|
|
|
|
|
|
2009-05-07 22:24:39 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-26 19:20:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-17 04:28:35 -04:00
|
|
|
|
2009-09-20 16:49:38 -04:00
|
|
|
|
2008-07-17 04:28:35 -04:00
|
|
|
|
2016-09-11 19:35:41 +02:00
|
|
|
|
2009-09-20 16:49:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-07 18:17:56 +02:00
|
|
|
|
2009-09-20 16:49:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-02 22:56:47 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-08-07 18:17:56 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-17 04:28:35 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2010-08-07 18:17:56 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-07 18:17:56 +02:00
|
|
|
|
2006-01-06 09:53:52 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
|
|
|
|
|
2007-08-04 10:06:25 -05:00
|
|
|
|
2006-01-06 09:53:52 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-13 13:47:40 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-04 10:06:25 -05:00
|
|
|
|
|
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
2017-04-24 16:51:13 +09:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
2014-05-01 16:51:04 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-06-28 12:40:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-05 14:32:17 -05:00
|
|
|
|
|
|
|
|
|
2017-04-05 19:20:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-05 19:21:02 +02:00
|
|
|
|
2017-04-05 19:20:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-05 19:21:02 +02:00
|
|
|
|
|
|
|
|
|
2016-06-05 14:32:17 -05:00
|
|
|
|
2014-06-28 12:40:18 +02:00
|
|
|
|
2016-06-05 14:32:23 -05:00
|
|
|
|
2014-06-28 12:40:18 +02:00
|
|
|
|
2016-06-05 14:32:17 -05:00
|
|
|
|
|
|
|
|
|
2014-06-28 12:40:18 +02:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-05 14:32:17 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-28 12:40:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-05 16:57:51 -08:00
|
|
|
|
2014-06-28 12:40:18 +02:00
|
|
|
|
2017-08-09 12:00:22 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-08 15:20:32 -07:00
|
|
|
|
|
|
|
|
|
2014-06-28 12:40:18 +02:00
|
|
|
|
2017-01-27 09:46:29 +01:00
|
|
|
|
2017-12-05 16:57:51 -08:00
|
|
|
|
2014-06-28 12:40:18 +02:00
|
|
|
|
|
|
|
|
|
2017-12-05 16:57:51 -08:00
|
|
|
|
2014-06-28 12:40:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-04-24 16:51:09 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-07 16:51:29 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-03-02 10:41:04 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-03-02 10:41:04 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-02 10:41:04 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-27 22:41:19 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-02 10:41:04 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-02 10:41:04 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-02 10:41:04 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-07 16:51:29 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-24 16:51:09 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-07 16:51:29 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-05-05 21:52:57 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-11 12:25:33 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-09-07 11:27:52 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-16 14:52:17 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-08 01:02:50 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-28 21:18:56 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-28 21:18:56 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-03-28 21:18:56 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-03-28 21:18:56 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-08 01:02:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-24 16:51:09 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-30 22:57:33 -03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-19 23:10:43 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-03-02 10:41:04 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-25 18:04:14 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-25 18:04:14 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-01-12 16:01:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-11 16:25:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-08 10:18:46 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-06-19 14:26:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-08 10:18:46 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-01-12 16:01:27 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-07-08 10:18:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-07-08 10:18:46 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-18 18:42:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-18 18:42:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-12-18 18:42:23 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-18 18:42:23 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-04-26 08:06:58 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-04-26 08:06:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-18 18:42:23 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-14 14:10:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-02 19:10:40 +02:00
|
|
|
|
2017-02-14 20:15:56 +01:00
|
|
|
|
|
|
|
|
|
2007-12-02 19:10:40 +02:00
|
|
|
|
2017-02-14 20:15:56 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-02-14 20:15:56 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-02-14 20:15:56 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-18 18:42:23 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2010-12-18 18:42:23 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-12-18 18:42:23 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-08-14 14:10:39 +02:00
|
|
|
|
2010-09-07 11:44:01 -04:00
|
|
|
|
2010-12-18 18:42:23 +01:00
|
|
|
|
2010-09-07 11:44:01 -04:00
|
|
|
|
2010-12-18 18:42:23 +01:00
|
|
|
|
|
|
|
|
|
2010-09-07 11:44:01 -04:00
|
|
|
|
2010-12-18 18:42:23 +01:00
|
|
|
|
|
|
|
|
|
2016-04-26 08:06:58 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-11 14:34:24 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2013-10-04 21:42:24 +00:00
|
|
|
|
|
|
|
|
|
2017-05-11 14:34:24 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-11 14:34:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-11 14:34:24 +02:00
|
|
|
|
2017-02-23 16:02:37 +01:00
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2014-10-24 14:27:00 +02:00
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2017-05-11 14:34:24 +02:00
|
|
|
|
|
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
2017-05-11 14:34:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-21 00:07:18 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 14:01:25 +01:00
|
|
|
|
2005-11-04 14:44:41 -05:00
|
|
|
|
2015-02-02 14:01:25 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-02 10:41:04 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-03-02 10:41:04 -05:00
|
|
|
|
2014-10-24 18:39:37 +02:00
|
|
|
|
2012-01-12 16:01:28 +01:00
|
|
|
|
2014-10-24 18:39:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-24 18:39:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-15 14:10:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-08 21:23:50 +09:00
|
|
|
|
2015-10-15 14:10:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-21 17:01:13 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-03-02 10:41:04 -05:00
|
|
|
|
|
|
|
|
|
2010-07-08 10:18:46 +02:00
|
|
|
|
2006-01-08 01:02:50 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-03-02 10:41:04 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-12-18 18:42:23 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-05-15 20:09:32 +02:00
|
|
|
|
2015-10-15 14:10:49 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-04-06 15:36:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-09 13:48:53 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-11 13:44:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-09 13:48:53 -05:00
|
|
|
|
2013-11-11 13:44:53 +01:00
|
|
|
|
2012-02-09 13:48:53 -05:00
|
|
|
|
|
|
|
|
|
2017-06-02 14:21:55 -07:00
|
|
|
|
2012-02-09 13:48:53 -05:00
|
|
|
|
2017-06-02 14:21:55 -07:00
|
|
|
|
2013-11-11 13:44:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-09 13:48:53 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-06 15:36:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-09 13:48:53 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-02 14:21:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-09 13:48:53 -05:00
|
|
|
|
2017-04-06 15:36:30 +02:00
|
|
|
|
2012-02-09 13:48:53 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-17 04:28:35 -04:00
|
|
|
|
|
|
|
|
|
2017-04-24 16:51:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[SCSI] fix medium error problems with some arrays which can cause data corruption
Our current handling of medium error assumes that data is returned up
to the bad sector. This assumption holds good for all disk devices,
all DIF arrays and most ordinary arrays. However, an LSI array engine
was recently discovered which reports a medium error without returning
any data. This means that when we report good data up to the medium
error, we've reported junk originally in the buffer as good. Worse,
if the read consists of requested data plus a readahead, and the error
occurs in readahead, we'll just strip off the readahead and report
junk up to userspace as good data with no error.
The fix for this is to have the error position computation take into
account the amount of data returned by the driver using the scsi
residual data. Unfortunately, not every driver fills in this data,
but for those who don't, it's set to zero, which means we'll think a
full set of data was transferred and the behaviour will be identical
to the prior behaviour of the code (believe the buffer up to the error
sector). All modern drivers seem to set the residual, so that should
fix up the LSI failure/corruption case.
Reported-by: Douglas Gilbert <dgilbert@interlog.com>
Cc: Stable Tree <stable@kernel.org>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-12-17 15:36:34 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-24 16:51:10 +09:00
|
|
|
|
2008-07-17 04:28:35 -04:00
|
|
|
|
2017-04-24 16:51:10 +09:00
|
|
|
|
|
|
|
|
|
2008-07-17 04:28:35 -04:00
|
|
|
|
2017-04-24 16:51:10 +09:00
|
|
|
|
2008-07-17 04:28:35 -04:00
|
|
|
|
[SCSI] fix medium error problems with some arrays which can cause data corruption
Our current handling of medium error assumes that data is returned up
to the bad sector. This assumption holds good for all disk devices,
all DIF arrays and most ordinary arrays. However, an LSI array engine
was recently discovered which reports a medium error without returning
any data. This means that when we report good data up to the medium
error, we've reported junk originally in the buffer as good. Worse,
if the read consists of requested data plus a readahead, and the error
occurs in readahead, we'll just strip off the readahead and report
junk up to userspace as good data with no error.
The fix for this is to have the error position computation take into
account the amount of data returned by the driver using the scsi
residual data. Unfortunately, not every driver fills in this data,
but for those who don't, it's set to zero, which means we'll think a
full set of data was transferred and the behaviour will be identical
to the prior behaviour of the code (believe the buffer up to the error
sector). All modern drivers seem to set the residual, so that should
fix up the LSI failure/corruption case.
Reported-by: Douglas Gilbert <dgilbert@interlog.com>
Cc: Stable Tree <stable@kernel.org>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-12-17 15:36:34 -05:00
|
|
|
|
2008-07-17 04:28:35 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
Revert "scsi: revert "[SCSI] Get rid of scsi_cmnd->done""
This reverts commit ac40532ef0b8649e6f7f83859ea0de1c4ed08a19, which gets
us back the original cleanup of 6f5391c283d7fdcf24bf40786ea79061919d1e1d.
It turns out that the bug that was triggered by that commit was
apparently not actually triggered by that commit at all, and just the
testing conditions had changed enough to make it appear to be due to it.
The real problem seems to have been found by Peter Osterlund:
"pktcdvd sets it [block device size] when opening the /dev/pktcdvd
device, but when the drive is later opened as /dev/scd0, there is
nothing that sets it back. (Btw, 40944 is possible if the disk is a
CDRW that was formatted with "cdrwtool -m 10236".)
The problem is that pktcdvd opens the cd device in non-blocking mode
when pktsetup is run, and doesn't close it again until pktsetup -d is
run. The effect is that if you meanwhile open the cd device,
blkdev.c:do_open() doesn't call bd_set_size() because
bdev->bd_openers is non-zero."
In particular, to repeat the bug (regardless of whether commit
6f5391c283d7fdcf24bf40786ea79061919d1e1d is applied or not):
" 1. Start with an empty drive.
2. pktsetup 0 /dev/scd0
3. Insert a CD containing an isofs filesystem.
4. mount /dev/pktcdvd/0 /mnt/tmp
5. umount /mnt/tmp
6. Press the eject button.
7. Insert a DVD containing a non-writable filesystem.
8. mount /dev/scd0 /mnt/tmp
9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
10. If the DVD contains data beyond the physical size of a CD, you
get I/O errors in the terminal, and dmesg reports lots of
"attempt to access beyond end of device" errors."
which in turn is because the nested open after the media change won't
cause the size to be set properly (because the original open still holds
the block device, and we only do the bd_set_size() when we don't have
other people holding the device open).
The proper fix for that is probably to just do something like
bdev->bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
in fs/block_dev.c:do_open() even for the cases where we're not the
original opener (but *not* call bd_set_size(), since that will also
change the block size of the device).
Cc: Peter Osterlund <petero2@telia.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-06 10:17:12 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Revert "scsi: revert "[SCSI] Get rid of scsi_cmnd->done""
This reverts commit ac40532ef0b8649e6f7f83859ea0de1c4ed08a19, which gets
us back the original cleanup of 6f5391c283d7fdcf24bf40786ea79061919d1e1d.
It turns out that the bug that was triggered by that commit was
apparently not actually triggered by that commit at all, and just the
testing conditions had changed enough to make it appear to be due to it.
The real problem seems to have been found by Peter Osterlund:
"pktcdvd sets it [block device size] when opening the /dev/pktcdvd
device, but when the drive is later opened as /dev/scd0, there is
nothing that sets it back. (Btw, 40944 is possible if the disk is a
CDRW that was formatted with "cdrwtool -m 10236".)
The problem is that pktcdvd opens the cd device in non-blocking mode
when pktsetup is run, and doesn't close it again until pktsetup -d is
run. The effect is that if you meanwhile open the cd device,
blkdev.c:do_open() doesn't call bd_set_size() because
bdev->bd_openers is non-zero."
In particular, to repeat the bug (regardless of whether commit
6f5391c283d7fdcf24bf40786ea79061919d1e1d is applied or not):
" 1. Start with an empty drive.
2. pktsetup 0 /dev/scd0
3. Insert a CD containing an isofs filesystem.
4. mount /dev/pktcdvd/0 /mnt/tmp
5. umount /mnt/tmp
6. Press the eject button.
7. Insert a DVD containing a non-writable filesystem.
8. mount /dev/scd0 /mnt/tmp
9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
10. If the DVD contains data beyond the physical size of a CD, you
get I/O errors in the terminal, and dmesg reports lots of
"attempt to access beyond end of device" errors."
which in turn is because the nested open after the media change won't
cause the size to be set properly (because the original open still holds
the block device, and we only do the bd_set_size() when we don't have
other people holding the device open).
The proper fix for that is probably to just do something like
bdev->bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
in fs/block_dev.c:do_open() even for the cases where we're not the
original opener (but *not* call bd_set_size(), since that will also
change the block size of the device).
Cc: Peter Osterlund <petero2@telia.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-06 10:17:12 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-07-17 04:28:35 -04:00
|
|
|
|
2017-03-01 17:27:00 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-09-20 16:49:38 -04:00
|
|
|
|
2012-09-18 12:19:31 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
|
|
|
|
|
2017-04-05 19:21:02 +02:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:31 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-01 17:27:00 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:31 -04:00
|
|
|
|
2010-07-21 10:29:37 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-10 11:08:30 -04:00
|
|
|
|
|
|
|
|
|
2006-06-23 09:39:09 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-06-23 09:39:09 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-17 04:28:35 -04:00
|
|
|
|
2006-06-23 09:39:09 -07:00
|
|
|
|
|
|
|
|
|
2008-07-17 04:28:35 -04:00
|
|
|
|
|
|
|
|
|
2008-09-11 21:39:36 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
2008-07-17 04:28:35 -04:00
|
|
|
|
2006-06-23 09:39:09 -07:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
2017-04-24 19:05:12 -04:00
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
2017-04-24 19:05:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-24 19:05:12 -04:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
2017-04-24 19:05:12 -04:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-20 15:12:13 +02:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
2017-04-24 19:05:12 -04:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
2006-06-23 09:39:09 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
2006-06-23 09:39:09 -07:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-24 14:27:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-17 04:28:35 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Revert "scsi: revert "[SCSI] Get rid of scsi_cmnd->done""
This reverts commit ac40532ef0b8649e6f7f83859ea0de1c4ed08a19, which gets
us back the original cleanup of 6f5391c283d7fdcf24bf40786ea79061919d1e1d.
It turns out that the bug that was triggered by that commit was
apparently not actually triggered by that commit at all, and just the
testing conditions had changed enough to make it appear to be due to it.
The real problem seems to have been found by Peter Osterlund:
"pktcdvd sets it [block device size] when opening the /dev/pktcdvd
device, but when the drive is later opened as /dev/scd0, there is
nothing that sets it back. (Btw, 40944 is possible if the disk is a
CDRW that was formatted with "cdrwtool -m 10236".)
The problem is that pktcdvd opens the cd device in non-blocking mode
when pktsetup is run, and doesn't close it again until pktsetup -d is
run. The effect is that if you meanwhile open the cd device,
blkdev.c:do_open() doesn't call bd_set_size() because
bdev->bd_openers is non-zero."
In particular, to repeat the bug (regardless of whether commit
6f5391c283d7fdcf24bf40786ea79061919d1e1d is applied or not):
" 1. Start with an empty drive.
2. pktsetup 0 /dev/scd0
3. Insert a CD containing an isofs filesystem.
4. mount /dev/pktcdvd/0 /mnt/tmp
5. umount /mnt/tmp
6. Press the eject button.
7. Insert a DVD containing a non-writable filesystem.
8. mount /dev/scd0 /mnt/tmp
9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
10. If the DVD contains data beyond the physical size of a CD, you
get I/O errors in the terminal, and dmesg reports lots of
"attempt to access beyond end of device" errors."
which in turn is because the nested open after the media change won't
cause the size to be set properly (because the original open still holds
the block device, and we only do the bd_set_size() when we don't have
other people holding the device open).
The proper fix for that is probably to just do something like
bdev->bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
in fs/block_dev.c:do_open() even for the cases where we're not the
original opener (but *not* call bd_set_size(), since that will also
change the block size of the device).
Cc: Peter Osterlund <petero2@telia.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-01-06 10:17:12 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-07-12 10:45:17 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-04 14:24:39 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-10-11 16:48:28 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2014-10-24 14:27:00 +02:00
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-10-24 14:27:00 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-02-20 06:53:48 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-02-20 06:53:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-11 00:34:07 +02:00
|
|
|
|
|
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
|
|
|
|
|
2008-12-04 14:24:39 +09:00
|
|
|
|
|
|
|
|
|
2005-07-12 10:45:17 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-12 10:45:17 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-12 10:45:17 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-17 04:28:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-21 12:44:12 -04:00
|
|
|
|
2008-07-17 04:28:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-21 12:44:12 -04:00
|
|
|
|
2008-07-17 04:28:34 -04:00
|
|
|
|
|
|
|
|
|
2012-09-21 12:44:12 -04:00
|
|
|
|
2009-09-18 17:33:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-11 19:35:41 +02:00
|
|
|
|
2012-09-21 12:44:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-17 04:28:34 -04:00
|
|
|
|
2008-09-19 18:47:20 -04:00
|
|
|
|
|
|
|
|
|
2012-09-21 12:44:12 -04:00
|
|
|
|
2008-07-17 04:28:34 -04:00
|
|
|
|
|
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-18 18:42:23 +01:00
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-01 10:30:01 -04:00
|
|
|
|
|
|
|
|
|
2017-04-04 10:42:30 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
2010-04-01 10:30:01 -04:00
|
|
|
|
2009-05-23 11:43:37 -04:00
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-10-01 14:20:10 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
2014-11-17 14:25:19 +01:00
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-12 14:20:30 -04:00
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
2009-03-12 14:20:30 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-01 10:30:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-12 14:20:30 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
2014-10-24 14:27:00 +02:00
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2009-04-21 16:43:27 -07:00
|
|
|
|
|
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
2012-09-21 12:44:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
2017-04-04 10:42:30 -04:00
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-23 11:43:37 -04:00
|
|
|
|
2010-09-28 14:48:47 -04:00
|
|
|
|
2009-05-23 11:43:37 -04:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-23 11:43:37 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
|
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-01 10:30:01 -04:00
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-01 10:30:01 -04:00
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
2010-04-01 10:30:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-24 14:27:00 +02:00
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-21 16:43:27 -07:00
|
|
|
|
|
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
2010-10-01 14:20:10 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-10-22 20:30:48 -07:00
|
|
|
|
2010-10-01 14:20:10 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-04 10:42:30 -04:00
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-28 14:48:47 -04:00
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-12 14:20:30 -04:00
|
|
|
|
|
|
|
|
|
2010-03-29 09:29:24 +02:00
|
|
|
|
|
|
|
|
|
2012-06-20 16:04:19 -04:00
|
|
|
|
|
|
|
|
|
2009-03-12 14:20:30 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-12 14:20:30 -04:00
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-12 14:20:30 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-12 14:20:29 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-02-18 10:54:44 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-08 09:04:48 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-13 10:49:09 +02:00
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-22 17:17:49 -04:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-11-13 16:46:48 -05:00
|
|
|
|
2014-06-03 18:45:51 -04:00
|
|
|
|
2012-11-14 17:03:22 -05:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
2005-08-28 11:27:01 -05:00
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-02-26 08:34:10 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-09 11:33:31 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
2014-01-03 18:19:26 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-03 18:19:26 -05:00
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-09 11:33:31 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-22 20:32:30 +03:00
|
|
|
|
2009-03-09 11:33:31 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-02-26 08:34:10 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2005-05-16 01:59:55 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-05-16 01:59:55 +01:00
|
|
|
|
|
|
|
|
|
[SCSI] Retrieve the Caching mode page (version 2)
Some kernel transport drivers unconditionally disable
retrieval of the Caching mode page. One such for example is
the BBB/CBI transport over USB. Such a restraint is too
harsh as some devices do support the Caching mode
page. Unconditionally enabling the retrieval of this mode
page over those transports at their transport code level may
result in some devices failing and becoming unusable.
This patch implements a method of retrieving the Caching
mode page without unconditionally enabling it in the
transports which unconditionally disable it. The idea is to
ask for all supported pages, page code 0x3F, and then search
for the Caching mode page in the mode parameter data
returned. The sd driver already asks for all the mode pages
supported by the attached device by setting the page code to
0x3F in order to find out if the media is write protected by
reading the WP bit in the Device Specific Parameter
field. It then attempts to retrieve only the Caching mode
page by setting the page code to 8 and actually attempting
to retrieve it if and only if the transport allows it.
The method implemented here is that if the transport doesn't
allow retrieval of the Caching mode page and the device is
not RBC, then we ask for all pages supported by setting the
page code to 0x3F (similarly to how the WP bit is retrieved
above), and then we search for the Caching mode page in the
mode parameter data returned.
With this patch, devices over SATA, report this (no change):
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Smart devices report their Caching mode page. This is a
change where we'd previously see the kernel making
assumption about the device's cache being write-through:
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] 610472646 4096-byte logical blocks: (2.50 TB/2.27 TiB)
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
And "dumb" devices over BBB, are correctly shown not to
support reporting the Caching mode page:
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] 15663104 512-byte logical blocks: (8.01 GB/7.46 GiB)
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Write Protect is off
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] No Caching mode page present
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Assuming drive cache: write through
Version 2 adds this:
Some devices don't support page code 0x3F, and others require a
fixed transfer length of 192 bytes. This single commit includes a
patch by Alan Stern which fixes this.
Reported-and-tested-by: Richard Senior <richard@r-senior.demon.co.uk>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: James Bottomley <jbottomley@parallels.com>
2011-05-19 00:00:58 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-03-09 11:33:31 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-04-24 14:02:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[SCSI] Retrieve the Caching mode page (version 2)
Some kernel transport drivers unconditionally disable
retrieval of the Caching mode page. One such for example is
the BBB/CBI transport over USB. Such a restraint is too
harsh as some devices do support the Caching mode
page. Unconditionally enabling the retrieval of this mode
page over those transports at their transport code level may
result in some devices failing and becoming unusable.
This patch implements a method of retrieving the Caching
mode page without unconditionally enabling it in the
transports which unconditionally disable it. The idea is to
ask for all supported pages, page code 0x3F, and then search
for the Caching mode page in the mode parameter data
returned. The sd driver already asks for all the mode pages
supported by the attached device by setting the page code to
0x3F in order to find out if the media is write protected by
reading the WP bit in the Device Specific Parameter
field. It then attempts to retrieve only the Caching mode
page by setting the page code to 8 and actually attempting
to retrieve it if and only if the transport allows it.
The method implemented here is that if the transport doesn't
allow retrieval of the Caching mode page and the device is
not RBC, then we ask for all pages supported by setting the
page code to 0x3F (similarly to how the WP bit is retrieved
above), and then we search for the Caching mode page in the
mode parameter data returned.
With this patch, devices over SATA, report this (no change):
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Smart devices report their Caching mode page. This is a
change where we'd previously see the kernel making
assumption about the device's cache being write-through:
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] 610472646 4096-byte logical blocks: (2.50 TB/2.27 TiB)
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
And "dumb" devices over BBB, are correctly shown not to
support reporting the Caching mode page:
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] 15663104 512-byte logical blocks: (8.01 GB/7.46 GiB)
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Write Protect is off
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] No Caching mode page present
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Assuming drive cache: write through
Version 2 adds this:
Some devices don't support page code 0x3F, and others require a
fixed transfer length of 192 bytes. This single commit includes a
patch by Alan Stern which fixes this.
Reported-and-tested-by: Richard Senior <richard@r-senior.demon.co.uk>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: James Bottomley <jbottomley@parallels.com>
2011-05-19 00:00:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-05-16 01:59:55 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
[SCSI] Retrieve the Caching mode page (version 2)
Some kernel transport drivers unconditionally disable
retrieval of the Caching mode page. One such for example is
the BBB/CBI transport over USB. Such a restraint is too
harsh as some devices do support the Caching mode
page. Unconditionally enabling the retrieval of this mode
page over those transports at their transport code level may
result in some devices failing and becoming unusable.
This patch implements a method of retrieving the Caching
mode page without unconditionally enabling it in the
transports which unconditionally disable it. The idea is to
ask for all supported pages, page code 0x3F, and then search
for the Caching mode page in the mode parameter data
returned. The sd driver already asks for all the mode pages
supported by the attached device by setting the page code to
0x3F in order to find out if the media is write protected by
reading the WP bit in the Device Specific Parameter
field. It then attempts to retrieve only the Caching mode
page by setting the page code to 8 and actually attempting
to retrieve it if and only if the transport allows it.
The method implemented here is that if the transport doesn't
allow retrieval of the Caching mode page and the device is
not RBC, then we ask for all pages supported by setting the
page code to 0x3F (similarly to how the WP bit is retrieved
above), and then we search for the Caching mode page in the
mode parameter data returned.
With this patch, devices over SATA, report this (no change):
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Smart devices report their Caching mode page. This is a
change where we'd previously see the kernel making
assumption about the device's cache being write-through:
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] 610472646 4096-byte logical blocks: (2.50 TB/2.27 TiB)
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
And "dumb" devices over BBB, are correctly shown not to
support reporting the Caching mode page:
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] 15663104 512-byte logical blocks: (8.01 GB/7.46 GiB)
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Write Protect is off
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] No Caching mode page present
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Assuming drive cache: write through
Version 2 adds this:
Some devices don't support page code 0x3F, and others require a
fixed transfer length of 192 bytes. This single commit includes a
patch by Alan Stern which fixes this.
Reported-and-tested-by: Richard Senior <richard@r-senior.demon.co.uk>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: James Bottomley <jbottomley@parallels.com>
2011-05-19 00:00:58 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-02-23 02:03:16 +01:00
|
|
|
|
|
|
|
|
|
[SCSI] Retrieve the Caching mode page (version 2)
Some kernel transport drivers unconditionally disable
retrieval of the Caching mode page. One such for example is
the BBB/CBI transport over USB. Such a restraint is too
harsh as some devices do support the Caching mode
page. Unconditionally enabling the retrieval of this mode
page over those transports at their transport code level may
result in some devices failing and becoming unusable.
This patch implements a method of retrieving the Caching
mode page without unconditionally enabling it in the
transports which unconditionally disable it. The idea is to
ask for all supported pages, page code 0x3F, and then search
for the Caching mode page in the mode parameter data
returned. The sd driver already asks for all the mode pages
supported by the attached device by setting the page code to
0x3F in order to find out if the media is write protected by
reading the WP bit in the Device Specific Parameter
field. It then attempts to retrieve only the Caching mode
page by setting the page code to 8 and actually attempting
to retrieve it if and only if the transport allows it.
The method implemented here is that if the transport doesn't
allow retrieval of the Caching mode page and the device is
not RBC, then we ask for all pages supported by setting the
page code to 0x3F (similarly to how the WP bit is retrieved
above), and then we search for the Caching mode page in the
mode parameter data returned.
With this patch, devices over SATA, report this (no change):
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Smart devices report their Caching mode page. This is a
change where we'd previously see the kernel making
assumption about the device's cache being write-through:
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] 610472646 4096-byte logical blocks: (2.50 TB/2.27 TiB)
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
And "dumb" devices over BBB, are correctly shown not to
support reporting the Caching mode page:
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] 15663104 512-byte logical blocks: (8.01 GB/7.46 GiB)
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Write Protect is off
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] No Caching mode page present
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Assuming drive cache: write through
Version 2 adds this:
Some devices don't support page code 0x3F, and others require a
fixed transfer length of 192 bytes. This single commit includes a
patch by Alan Stern which fixes this.
Reported-and-tested-by: Richard Senior <richard@r-senior.demon.co.uk>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: James Bottomley <jbottomley@parallels.com>
2011-05-19 00:00:58 -07:00
|
|
|
|
2014-01-03 18:19:26 -05:00
|
|
|
|
|
|
|
|
|
2006-02-23 02:03:16 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[SCSI] Retrieve the Caching mode page (version 2)
Some kernel transport drivers unconditionally disable
retrieval of the Caching mode page. One such for example is
the BBB/CBI transport over USB. Such a restraint is too
harsh as some devices do support the Caching mode
page. Unconditionally enabling the retrieval of this mode
page over those transports at their transport code level may
result in some devices failing and becoming unusable.
This patch implements a method of retrieving the Caching
mode page without unconditionally enabling it in the
transports which unconditionally disable it. The idea is to
ask for all supported pages, page code 0x3F, and then search
for the Caching mode page in the mode parameter data
returned. The sd driver already asks for all the mode pages
supported by the attached device by setting the page code to
0x3F in order to find out if the media is write protected by
reading the WP bit in the Device Specific Parameter
field. It then attempts to retrieve only the Caching mode
page by setting the page code to 8 and actually attempting
to retrieve it if and only if the transport allows it.
The method implemented here is that if the transport doesn't
allow retrieval of the Caching mode page and the device is
not RBC, then we ask for all pages supported by setting the
page code to 0x3F (similarly to how the WP bit is retrieved
above), and then we search for the Caching mode page in the
mode parameter data returned.
With this patch, devices over SATA, report this (no change):
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Smart devices report their Caching mode page. This is a
change where we'd previously see the kernel making
assumption about the device's cache being write-through:
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] 610472646 4096-byte logical blocks: (2.50 TB/2.27 TiB)
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
And "dumb" devices over BBB, are correctly shown not to
support reporting the Caching mode page:
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] 15663104 512-byte logical blocks: (8.01 GB/7.46 GiB)
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Write Protect is off
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] No Caching mode page present
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Assuming drive cache: write through
Version 2 adds this:
Some devices don't support page code 0x3F, and others require a
fixed transfer length of 192 bytes. This single commit includes a
patch by Alan Stern which fixes this.
Reported-and-tested-by: Richard Senior <richard@r-senior.demon.co.uk>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: James Bottomley <jbottomley@parallels.com>
2011-05-19 00:00:58 -07:00
|
|
|
|
2014-01-03 18:19:26 -05:00
|
|
|
|
[SCSI] Retrieve the Caching mode page (version 2)
Some kernel transport drivers unconditionally disable
retrieval of the Caching mode page. One such for example is
the BBB/CBI transport over USB. Such a restraint is too
harsh as some devices do support the Caching mode
page. Unconditionally enabling the retrieval of this mode
page over those transports at their transport code level may
result in some devices failing and becoming unusable.
This patch implements a method of retrieving the Caching
mode page without unconditionally enabling it in the
transports which unconditionally disable it. The idea is to
ask for all supported pages, page code 0x3F, and then search
for the Caching mode page in the mode parameter data
returned. The sd driver already asks for all the mode pages
supported by the attached device by setting the page code to
0x3F in order to find out if the media is write protected by
reading the WP bit in the Device Specific Parameter
field. It then attempts to retrieve only the Caching mode
page by setting the page code to 8 and actually attempting
to retrieve it if and only if the transport allows it.
The method implemented here is that if the transport doesn't
allow retrieval of the Caching mode page and the device is
not RBC, then we ask for all pages supported by setting the
page code to 0x3F (similarly to how the WP bit is retrieved
above), and then we search for the Caching mode page in the
mode parameter data returned.
With this patch, devices over SATA, report this (no change):
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Smart devices report their Caching mode page. This is a
change where we'd previously see the kernel making
assumption about the device's cache being write-through:
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] 610472646 4096-byte logical blocks: (2.50 TB/2.27 TiB)
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
And "dumb" devices over BBB, are correctly shown not to
support reporting the Caching mode page:
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] 15663104 512-byte logical blocks: (8.01 GB/7.46 GiB)
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Write Protect is off
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] No Caching mode page present
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Assuming drive cache: write through
Version 2 adds this:
Some devices don't support page code 0x3F, and others require a
fixed transfer length of 192 bytes. This single commit includes a
patch by Alan Stern which fixes this.
Reported-and-tested-by: Richard Senior <richard@r-senior.demon.co.uk>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: James Bottomley <jbottomley@parallels.com>
2011-05-19 00:00:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
[SCSI] Retrieve the Caching mode page (version 2)
Some kernel transport drivers unconditionally disable
retrieval of the Caching mode page. One such for example is
the BBB/CBI transport over USB. Such a restraint is too
harsh as some devices do support the Caching mode
page. Unconditionally enabling the retrieval of this mode
page over those transports at their transport code level may
result in some devices failing and becoming unusable.
This patch implements a method of retrieving the Caching
mode page without unconditionally enabling it in the
transports which unconditionally disable it. The idea is to
ask for all supported pages, page code 0x3F, and then search
for the Caching mode page in the mode parameter data
returned. The sd driver already asks for all the mode pages
supported by the attached device by setting the page code to
0x3F in order to find out if the media is write protected by
reading the WP bit in the Device Specific Parameter
field. It then attempts to retrieve only the Caching mode
page by setting the page code to 8 and actually attempting
to retrieve it if and only if the transport allows it.
The method implemented here is that if the transport doesn't
allow retrieval of the Caching mode page and the device is
not RBC, then we ask for all pages supported by setting the
page code to 0x3F (similarly to how the WP bit is retrieved
above), and then we search for the Caching mode page in the
mode parameter data returned.
With this patch, devices over SATA, report this (no change):
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Smart devices report their Caching mode page. This is a
change where we'd previously see the kernel making
assumption about the device's cache being write-through:
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] 610472646 4096-byte logical blocks: (2.50 TB/2.27 TiB)
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
And "dumb" devices over BBB, are correctly shown not to
support reporting the Caching mode page:
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] 15663104 512-byte logical blocks: (8.01 GB/7.46 GiB)
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Write Protect is off
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] No Caching mode page present
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Assuming drive cache: write through
Version 2 adds this:
Some devices don't support page code 0x3F, and others require a
fixed transfer length of 192 bytes. This single commit includes a
patch by Alan Stern which fixes this.
Reported-and-tested-by: Richard Senior <richard@r-senior.demon.co.uk>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: James Bottomley <jbottomley@parallels.com>
2011-05-19 00:00:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-05-16 01:59:55 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
[SCSI] Retrieve the Caching mode page (version 2)
Some kernel transport drivers unconditionally disable
retrieval of the Caching mode page. One such for example is
the BBB/CBI transport over USB. Such a restraint is too
harsh as some devices do support the Caching mode
page. Unconditionally enabling the retrieval of this mode
page over those transports at their transport code level may
result in some devices failing and becoming unusable.
This patch implements a method of retrieving the Caching
mode page without unconditionally enabling it in the
transports which unconditionally disable it. The idea is to
ask for all supported pages, page code 0x3F, and then search
for the Caching mode page in the mode parameter data
returned. The sd driver already asks for all the mode pages
supported by the attached device by setting the page code to
0x3F in order to find out if the media is write protected by
reading the WP bit in the Device Specific Parameter
field. It then attempts to retrieve only the Caching mode
page by setting the page code to 8 and actually attempting
to retrieve it if and only if the transport allows it.
The method implemented here is that if the transport doesn't
allow retrieval of the Caching mode page and the device is
not RBC, then we ask for all pages supported by setting the
page code to 0x3F (similarly to how the WP bit is retrieved
above), and then we search for the Caching mode page in the
mode parameter data returned.
With this patch, devices over SATA, report this (no change):
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Smart devices report their Caching mode page. This is a
change where we'd previously see the kernel making
assumption about the device's cache being write-through:
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] 610472646 4096-byte logical blocks: (2.50 TB/2.27 TiB)
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
And "dumb" devices over BBB, are correctly shown not to
support reporting the Caching mode page:
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] 15663104 512-byte logical blocks: (8.01 GB/7.46 GiB)
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Write Protect is off
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] No Caching mode page present
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Assuming drive cache: write through
Version 2 adds this:
Some devices don't support page code 0x3F, and others require a
fixed transfer length of 192 bytes. This single commit includes a
patch by Alan Stern which fixes this.
Reported-and-tested-by: Richard Senior <richard@r-senior.demon.co.uk>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: James Bottomley <jbottomley@parallels.com>
2011-05-19 00:00:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-03 18:19:26 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[SCSI] Retrieve the Caching mode page (version 2)
Some kernel transport drivers unconditionally disable
retrieval of the Caching mode page. One such for example is
the BBB/CBI transport over USB. Such a restraint is too
harsh as some devices do support the Caching mode
page. Unconditionally enabling the retrieval of this mode
page over those transports at their transport code level may
result in some devices failing and becoming unusable.
This patch implements a method of retrieving the Caching
mode page without unconditionally enabling it in the
transports which unconditionally disable it. The idea is to
ask for all supported pages, page code 0x3F, and then search
for the Caching mode page in the mode parameter data
returned. The sd driver already asks for all the mode pages
supported by the attached device by setting the page code to
0x3F in order to find out if the media is write protected by
reading the WP bit in the Device Specific Parameter
field. It then attempts to retrieve only the Caching mode
page by setting the page code to 8 and actually attempting
to retrieve it if and only if the transport allows it.
The method implemented here is that if the transport doesn't
allow retrieval of the Caching mode page and the device is
not RBC, then we ask for all pages supported by setting the
page code to 0x3F (similarly to how the WP bit is retrieved
above), and then we search for the Caching mode page in the
mode parameter data returned.
With this patch, devices over SATA, report this (no change):
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Smart devices report their Caching mode page. This is a
change where we'd previously see the kernel making
assumption about the device's cache being write-through:
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] 610472646 4096-byte logical blocks: (2.50 TB/2.27 TiB)
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
And "dumb" devices over BBB, are correctly shown not to
support reporting the Caching mode page:
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] 15663104 512-byte logical blocks: (8.01 GB/7.46 GiB)
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Write Protect is off
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] No Caching mode page present
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Assuming drive cache: write through
Version 2 adds this:
Some devices don't support page code 0x3F, and others require a
fixed transfer length of 192 bytes. This single commit includes a
patch by Alan Stern which fixes this.
Reported-and-tested-by: Richard Senior <richard@r-senior.demon.co.uk>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: James Bottomley <jbottomley@parallels.com>
2011-05-19 00:00:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-03 18:19:26 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[SCSI] Retrieve the Caching mode page (version 2)
Some kernel transport drivers unconditionally disable
retrieval of the Caching mode page. One such for example is
the BBB/CBI transport over USB. Such a restraint is too
harsh as some devices do support the Caching mode
page. Unconditionally enabling the retrieval of this mode
page over those transports at their transport code level may
result in some devices failing and becoming unusable.
This patch implements a method of retrieving the Caching
mode page without unconditionally enabling it in the
transports which unconditionally disable it. The idea is to
ask for all supported pages, page code 0x3F, and then search
for the Caching mode page in the mode parameter data
returned. The sd driver already asks for all the mode pages
supported by the attached device by setting the page code to
0x3F in order to find out if the media is write protected by
reading the WP bit in the Device Specific Parameter
field. It then attempts to retrieve only the Caching mode
page by setting the page code to 8 and actually attempting
to retrieve it if and only if the transport allows it.
The method implemented here is that if the transport doesn't
allow retrieval of the Caching mode page and the device is
not RBC, then we ask for all pages supported by setting the
page code to 0x3F (similarly to how the WP bit is retrieved
above), and then we search for the Caching mode page in the
mode parameter data returned.
With this patch, devices over SATA, report this (no change):
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Smart devices report their Caching mode page. This is a
change where we'd previously see the kernel making
assumption about the device's cache being write-through:
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] 610472646 4096-byte logical blocks: (2.50 TB/2.27 TiB)
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
And "dumb" devices over BBB, are correctly shown not to
support reporting the Caching mode page:
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] 15663104 512-byte logical blocks: (8.01 GB/7.46 GiB)
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Write Protect is off
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] No Caching mode page present
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Assuming drive cache: write through
Version 2 adds this:
Some devices don't support page code 0x3F, and others require a
fixed transfer length of 192 bytes. This single commit includes a
patch by Alan Stern which fixes this.
Reported-and-tested-by: Richard Senior <richard@r-senior.demon.co.uk>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: James Bottomley <jbottomley@parallels.com>
2011-05-19 00:00:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-02-26 08:34:10 -06:00
|
|
|
|
|
|
|
|
|
2014-01-03 18:19:26 -05:00
|
|
|
|
2013-09-06 11:49:51 -04:00
|
|
|
|
|
|
|
|
|
[SCSI] Retrieve the Caching mode page (version 2)
Some kernel transport drivers unconditionally disable
retrieval of the Caching mode page. One such for example is
the BBB/CBI transport over USB. Such a restraint is too
harsh as some devices do support the Caching mode
page. Unconditionally enabling the retrieval of this mode
page over those transports at their transport code level may
result in some devices failing and becoming unusable.
This patch implements a method of retrieving the Caching
mode page without unconditionally enabling it in the
transports which unconditionally disable it. The idea is to
ask for all supported pages, page code 0x3F, and then search
for the Caching mode page in the mode parameter data
returned. The sd driver already asks for all the mode pages
supported by the attached device by setting the page code to
0x3F in order to find out if the media is write protected by
reading the WP bit in the Device Specific Parameter
field. It then attempts to retrieve only the Caching mode
page by setting the page code to 8 and actually attempting
to retrieve it if and only if the transport allows it.
The method implemented here is that if the transport doesn't
allow retrieval of the Caching mode page and the device is
not RBC, then we ask for all pages supported by setting the
page code to 0x3F (similarly to how the WP bit is retrieved
above), and then we search for the Caching mode page in the
mode parameter data returned.
With this patch, devices over SATA, report this (no change):
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 22 18:45:58 localhost kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Smart devices report their Caching mode page. This is a
change where we'd previously see the kernel making
assumption about the device's cache being write-through:
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] 610472646 4096-byte logical blocks: (2.50 TB/2.27 TiB)
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write Protect is off
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
Oct 22 18:45:58 localhost kernel: sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
And "dumb" devices over BBB, are correctly shown not to
support reporting the Caching mode page:
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] 15663104 512-byte logical blocks: (8.01 GB/7.46 GiB)
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Write Protect is off
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] No Caching mode page present
Oct 22 18:49:06 localhost kernel: sd 7:0:0:0: [sdc] Assuming drive cache: write through
Version 2 adds this:
Some devices don't support page code 0x3F, and others require a
fixed transfer length of 192 bytes. This single commit includes a
patch by Alan Stern which fixes this.
Reported-and-tested-by: Richard Senior <richard@r-senior.demon.co.uk>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: James Bottomley <jbottomley@parallels.com>
2011-05-19 00:00:58 -07:00
|
|
|
|
2005-05-16 01:59:55 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-06 09:53:52 +01:00
|
|
|
|
2014-06-30 11:04:21 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-12 15:25:10 +09:00
|
|
|
|
|
|
|
|
|
2014-01-03 18:19:26 -05:00
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2006-01-06 09:53:52 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-08-11 15:40:37 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-09 11:33:31 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2014-01-03 18:19:26 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-01-03 18:19:26 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-07-07 23:05:08 -04:00
|
|
|
|
2014-01-03 18:19:26 -05:00
|
|
|
|
|
|
|
|
|
2012-07-07 23:05:08 -04:00
|
|
|
|
|
|
|
|
|
2014-01-03 18:19:26 -05:00
|
|
|
|
|
|
|
|
|
2012-07-07 23:05:08 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-02-26 08:34:10 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-07-17 04:28:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-10 18:01:20 -07:00
|
|
|
|
2008-07-17 04:28:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
2008-07-17 04:28:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-03 18:19:26 -05:00
|
|
|
|
2008-07-17 04:28:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-03 18:19:26 -05:00
|
|
|
|
2008-07-17 04:28:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-23 11:43:39 -04:00
|
|
|
|
|
|
|
|
|
2017-04-24 16:51:09 +09:00
|
|
|
|
2009-05-23 11:43:39 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-02 08:44:34 -05:00
|
|
|
|
2009-11-03 12:33:07 -06:00
|
|
|
|
2009-05-23 11:43:39 -04:00
|
|
|
|
2009-11-03 12:33:07 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-23 11:43:39 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-13 16:46:48 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-23 11:43:39 -04:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-05 19:21:25 +02:00
|
|
|
|
2014-12-05 08:58:03 -05:00
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-26 12:00:40 -05:00
|
|
|
|
|
|
|
|
|
2009-11-03 12:33:07 -06:00
|
|
|
|
2009-05-23 11:43:39 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-23 11:43:38 -04:00
|
|
|
|
|
|
|
|
|
2017-04-24 16:51:09 +09:00
|
|
|
|
2009-05-23 11:43:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
2009-11-03 12:33:07 -06:00
|
|
|
|
2009-05-23 11:43:38 -04:00
|
|
|
|
2010-03-02 08:44:34 -05:00
|
|
|
|
2009-05-23 11:43:38 -04:00
|
|
|
|
2009-11-03 12:33:07 -06:00
|
|
|
|
2009-05-23 11:43:38 -04:00
|
|
|
|
2009-11-03 12:33:07 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-23 11:43:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-04 10:55:32 -06:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
|
|
|
|
|
2014-10-04 10:55:32 -06:00
|
|
|
|
2009-05-23 11:43:38 -04:00
|
|
|
|
2017-01-12 15:25:11 +09:00
|
|
|
|
|
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
2017-01-12 15:25:11 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-03 12:33:07 -06:00
|
|
|
|
2009-05-23 11:43:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-10 01:22:07 -04:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
2017-04-24 16:51:09 +09:00
|
|
|
|
2010-09-10 01:22:07 -04:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
2010-09-10 01:22:07 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
2010-09-10 01:22:07 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-10 01:22:07 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
2013-06-06 22:15:55 -04:00
|
|
|
|
|
|
|
|
|
2013-10-23 06:25:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-06 22:15:55 -04:00
|
|
|
|
2013-09-23 14:47:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-06 22:15:55 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-23 14:47:32 +02:00
|
|
|
|
2013-06-06 22:15:55 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
2013-06-06 22:15:55 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
|
|
|
|
|
2017-06-19 14:26:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-13 16:46:48 -05:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-11-13 16:46:48 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-27 22:41:19 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-21 17:15:26 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
|
|
|
|
|
2005-08-28 11:33:52 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2009-07-29 14:06:53 -04:00
|
|
|
|
2016-04-01 08:57:36 +02:00
|
|
|
|
2011-03-08 02:07:15 -05:00
|
|
|
|
2009-07-29 14:06:53 -04:00
|
|
|
|
|
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
2009-07-29 14:06:53 -04:00
|
|
|
|
|
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
|
|
|
|
|
2008-07-17 04:28:34 -04:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
2017-06-19 14:26:46 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-06 09:52:55 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-03 11:56:16 +02:00
|
|
|
|
2006-01-06 09:52:55 +01:00
|
|
|
|
2014-06-03 17:37:30 +08:00
|
|
|
|
2006-01-06 09:52:55 +01:00
|
|
|
|
2015-11-13 16:46:48 -05:00
|
|
|
|
|
|
|
|
|
2015-01-29 15:54:40 -06:00
|
|
|
|
2015-11-13 16:46:48 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-09-27 21:38:59 -04:00
|
|
|
|
2015-12-16 17:53:52 -05:00
|
|
|
|
|
|
|
|
|
2015-11-13 16:46:48 -05:00
|
|
|
|
2015-12-16 17:53:52 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-12 22:17:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-28 12:41:26 +08:00
|
|
|
|
|
|
|
|
|
2015-11-13 16:46:48 -05:00
|
|
|
|
2017-09-27 21:38:59 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-23 12:13:59 -04:00
|
|
|
|
2016-03-28 21:18:56 -04:00
|
|
|
|
2012-09-18 12:19:32 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-15 20:09:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-25 19:56:17 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tree-wide: Assorted spelling fixes
In particular, several occurances of funny versions of 'success',
'unknown', 'therefore', 'acknowledge', 'argument', 'achieve', 'address',
'beginning', 'desirable', 'separate' and 'necessary' are fixed.
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Joe Perches <joe@perches.com>
Cc: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2010-02-03 08:01:28 +08:00
|
|
|
|
2008-08-25 19:56:17 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 05:32:28 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-20 11:20:22 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 05:32:28 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-09 11:33:31 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-24 14:02:53 -07:00
|
|
|
|
2009-03-09 11:33:31 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-09 13:48:53 -05:00
|
|
|
|
2009-03-09 11:33:31 -04:00
|
|
|
|
2009-01-04 05:32:28 -08:00
|
|
|
|
|
|
|
|
|
2010-03-16 08:55:32 +01:00
|
|
|
|
2010-12-18 18:42:23 +01:00
|
|
|
|
2009-01-04 05:32:28 -08:00
|
|
|
|
2010-12-18 18:42:23 +01:00
|
|
|
|
|
|
|
|
|
2009-01-04 05:32:28 -08:00
|
|
|
|
2013-10-10 13:22:36 +08:00
|
|
|
|
2016-06-15 19:44:20 -07:00
|
|
|
|
2012-09-21 12:44:12 -04:00
|
|
|
|
|
|
|
|
|
2009-01-04 05:32:28 -08:00
|
|
|
|
2009-05-23 11:43:38 -04:00
|
|
|
|
|
|
|
|
|
2017-06-19 14:26:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-04 05:32:28 -08:00
|
|
|
|
|
|
|
|
|
2010-06-16 14:52:17 -04:00
|
|
|
|
2009-08-21 09:47:54 -06:00
|
|
|
|
2009-01-04 05:32:28 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-24 16:56:54 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-10 18:01:20 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-09-10 14:54:09 +03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-10-02 11:45:08 -05:00
|
|
|
|
2012-02-24 16:56:54 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-01-16 10:31:18 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-25 19:56:16 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-03-08 17:48:34 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-07-14 14:59:30 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-02-21 11:04:45 +09:00
|
|
|
|
2008-07-14 14:59:30 +09:00
|
|
|
|
2009-02-21 11:04:45 +09:00
|
|
|
|
2008-07-14 14:59:30 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-10-19 11:49:04 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-09-20 11:20:22 -05:00
|
|
|
|
|
|
|
|
|
2008-08-25 19:56:17 +09:00
|
|
|
|
2011-10-19 11:49:04 -05:00
|
|
|
|
|
|
|
|
|
2008-07-14 14:59:30 +09:00
|
|
|
|
2011-10-19 11:49:04 -05:00
|
|
|
|
2008-07-14 14:59:30 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-07 16:51:29 +02:00
|
|
|
|
2012-06-09 07:03:39 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-05-26 20:35:48 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-16 14:52:17 -04:00
|
|
|
|
2009-05-26 20:35:48 +00:00
|
|
|
|
2013-07-03 15:04:56 -07:00
|
|
|
|
2009-05-26 20:35:48 +00:00
|
|
|
|
2015-01-19 17:41:12 +03:00
|
|
|
|
|
|
|
|
|
2009-05-26 20:35:48 +00:00
|
|
|
|
|
|
|
|
|
2010-06-16 14:52:17 -04:00
|
|
|
|
|
|
|
|
|
2009-05-26 20:35:48 +00:00
|
|
|
|
2009-08-21 09:47:54 -06:00
|
|
|
|
2012-03-22 17:05:11 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-14 14:59:30 +09:00
|
|
|
|
2017-03-08 17:48:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-02-03 19:38:54 +00:00
|
|
|
|
|
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
2014-09-10 14:54:09 +03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-12 16:17:20 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-26 20:35:48 +00:00
|
|
|
|
2013-05-10 11:06:16 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-05-26 20:35:48 +00:00
|
|
|
|
2013-05-10 11:06:16 +02:00
|
|
|
|
2010-06-16 14:52:17 -04:00
|
|
|
|
|
|
|
|
|
2014-04-10 15:30:35 -07:00
|
|
|
|
2012-03-22 17:05:11 -07:00
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-11-04 14:44:41 -05:00
|
|
|
|
2016-10-18 15:40:34 +09:00
|
|
|
|
|
|
|
|
|
2017-06-19 14:26:46 +02:00
|
|
|
|
|
|
|
|
|
2013-05-10 11:06:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-11 13:16:10 +01:00
|
|
|
|
2005-11-04 14:44:41 -05:00
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2006-01-11 13:16:10 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-11 13:16:10 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-02-22 00:13:36 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-03-08 17:48:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-11-04 14:44:41 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-20 12:26:03 -05:00
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-20 12:26:03 -05:00
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-11 00:34:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-23 16:02:37 +01:00
|
|
|
|
|
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
2014-10-24 14:27:00 +02:00
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
2007-03-20 12:26:03 -05:00
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
|
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-02 14:01:25 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-05 09:20:26 +08:00
|
|
|
|
2015-02-02 14:01:25 +01:00
|
|
|
|
2011-12-05 09:20:26 +08:00
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2017-05-11 14:34:24 +02:00
|
|
|
|
2005-11-04 14:44:41 -05:00
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
2007-03-20 12:26:03 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
2005-11-04 14:44:41 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
2015-02-02 14:01:25 +01:00
|
|
|
|
2017-05-11 14:34:24 +02:00
|
|
|
|
2007-05-21 09:55:04 -04:00
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
2016-01-20 11:26:01 -05:00
|
|
|
|
|
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
2007-03-20 12:26:03 -05:00
|
|
|
|
2017-05-11 14:34:24 +02:00
|
|
|
|
|
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-11 14:34:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-25 13:46:34 -07:00
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
|
|
|
|
|
2012-11-09 15:27:55 +08:00
|
|
|
|
2007-03-20 12:26:03 -05:00
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
2007-03-20 12:26:03 -05:00
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
|
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
|
|
|
|
|
2007-05-21 09:55:04 -04:00
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
|
|
|
|
|
2013-09-16 13:28:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
|
|
|
|
|
2015-02-02 14:01:25 +01:00
|
|
|
|
2017-06-19 14:26:46 +02:00
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
2016-01-20 11:26:01 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-20 12:26:03 -05:00
|
|
|
|
2015-02-02 14:01:25 +01:00
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
2007-03-20 12:26:03 -05:00
|
|
|
|
2017-06-19 14:26:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-21 00:13:59 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-04 05:32:54 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-10 11:06:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-04 05:32:54 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-18 14:14:21 -06:00
|
|
|
|
2009-09-20 16:49:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-03 23:34:25 +02:00
|
|
|
|
2009-09-20 16:49:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-03 23:34:25 +02:00
|
|
|
|
2009-09-20 16:49:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-10 10:36:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-04 05:32:54 -04:00
|
|
|
|
|
|
|
|
|
2012-10-10 10:36:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-20 16:49:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-04 05:32:54 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-10 10:36:11 +02:00
|
|
|
|
2009-09-20 16:49:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-04 05:32:54 -04:00
|
|
|
|
|
|
|
|
|
2013-05-10 11:06:16 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-05-10 11:06:16 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-08 07:43:46 +01:00
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
|
|
|
|
|
2014-10-24 14:27:00 +02:00
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
2014-10-24 14:27:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-27 22:40:55 -05:00
|
|
|
|
|
|
|
|
|
