Every dmesg users provide contains double info
about identification of [scsi,ata,..] disk drives
found in the system. Here's mine:
scsi 2:0:0:0: Direct-Access ATA ST3808110AS n/a PQ: 0 ANSI: 5
loading module sd_mod
sd 2:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
sd
Dan Aloni wrote:
> On Thu, Jun 28, 2007 at 02:51:58PM +0400, Michael Tokarev wrote:
>> [..]
>> Test machine was using MPTSAS driver for the following card:
>> SCSI storage controller: LSI Logic / Symbios Logic SAS1064E PCI-Express
>> Fusion-MPT SAS (rev 02)
>&g
Tejun Heo wrote:
> Hello,
>
> Michael Tokarev wrote:
>> Well. It looks like the results does not depend on the
>> elevator. Originally I tried with deadline, and just
>> re-ran the test with noop (hence the long delay with
>> the answer) - changing linux elev
Tejun Heo wrote:
> Michael Tokarev wrote:
[]
>> A test drive is Seagate Barracuda ST3250620AS "desktop" drive,
>> 250Gb, cache size is 16Mb, 7200RPM.
[test shows that NCQ makes no difference whatsoever]
> And which elevator?
Well. It looks like the results doe
Michael Tokarev wrote:
[]
> I'm planning to test several models of SCSI drives. On SCSI front
> (or maybe with different drives - I don't know) things are WAY more
> interesting wrt TCQ. Difference in results between 1 and 32 threads
> goes up to 4 times sometimes!. Bu
[Offtopic notice: For the first time I demonstrated some
speed testing results on linux-ide mailinglist, as a
demonstration how [NT]CQ can help. But later, someone
becomes curious and posted that email to lkml, asking
for more details. Since that, I become more curious
as well, and decided to loo
/sys/block/sdX/device/queue_depth file is read-write with
libsata, but is read-only with SCSI controllers (at least
with the ones we have -- mostly aic7xxx or mptsas).
Googling for "disable tcq" gives results about {dis,en}abling
TCQ at boot time, and also mentions ipr (which we don't have).
Is
Douglas Gilbert wrote:
> Michael Tokarev wrote:
>> We've got a bunch of SATA Seagate Barracuda ES drives,
>> namely, ST3250620NS -- "enterprize" class. And now I
>> wonder what's wrong with - either those drives, or
>> sdparm, or kernel.
>>
>
We've got a bunch of SATA Seagate Barracuda ES drives,
namely, ST3250620NS -- "enterprize" class. And now I
wonder what's wrong with - either those drives, or
sdparm, or kernel.
In particular, sdparm can't change WCE bit, like this:
# sdparm --clear=WCE -v -v /dev/sda
mp_settings: page,subpage=0
Salyzyn, Mark wrote:
> NAK
>
> This will break all our management applications, and will not allow us to
> manipulate the array configurations from within Linux. This will also break
> online expansion of capacity.
>
> This flag has been set from the beginning to allow partition tables, capacit
On a regular basis now (but not very frequently - it happened
two times in a single month so far), a system based on the
abovementioned board fails to work with a hard drive, on an
idle system. Like this (too bad it's not an 1st April joke):
Apr 1 01:36:09 ata2.00: exception Emask 0x10 SAct 0x2
David Brownell wrote:
> This teaches scsi devices how to support "new style" hotplug/coldplug:
> using a modalias sysfs attribute for coldplug, and MODALIAS environment
> variable for hotplug.
How this is different from http://marc.info/?t=11520454222&r=1&w=2 and
earlier attempts to do the sam
Martin K. Petersen wrote:
[]
> --- scsi-misc-2.6.orig/drivers/scsi/constants.c
> +++ scsi-misc-2.6/drivers/scsi/constants.c
[]
> static struct error_info additional[] =
static CONST struct error_info additional[]... ?
> {
> {0x, "No additional sense information"},
[]
/mjt
-
To unsubsc
Lukasz Kosewski wrote:
[]
[1] The SCSI error on 2.6.13-rc3-mm1 that I found:
'echo "scsi add-single-device a b c d" > /proc/scsi/scsi' //works, or
no-op if the sd corresponding to that device is there already
'echo "scsi remove-single-device a b c d" > /proc/scsi/scsi' //works
'echo "scsi ad
Jeff Garzik wrote:
Luben,
[]
Everyone who submits patches to Linux needs to include a signed-off-by
line, and format their emails such that automated scripts will process
the emails correctly.
BTW, as this is a completely new driver (for the kernel source anyway),
and there's no "patch" per se he
Luben Tuikov wrote:
The readme file.
diff -Nru a/drivers/scsi/adp94xx/readme.txt
[]
+=README for=
+= Red Hat Linux Advanced Server 2.1 =
+= Red Hat Enterprise Linux 3.0 =
+
16 matches
Mail list logo