Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Alan Cox]

On Sun, 06 Jan 2008 12:25:10 -0800
Linda Walsh <[EMAIL PROTECTED]> wrote:

> Robert Hancock wrote:
> >
> > If this is a Seagate, I believe that they don't have AAM enabled on 
> > any of their newer drives (something about a lawsuit for patent 
> > infringement on that feature, or something). Quite likely they don't 
> > support that power management command, either.
> --
> Do you have a source for this -- haven't heard of such a conflict -- 

There were patent questions around AAM. There are some discussions on the
t13 archive then it goes silent and nothing is ever said again, which I
imagine is when it got lawyered.

> besides, doesn't
> ATA-7 require some of those functions? 

No.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Mehmet Kemal EROL]

Linda Walsh:

> 
> Seagate would
> remove those features -- especially since they are mentioned on 
> Seagate's drive
> information page as being supported features.
> 

Since you're there ... you might want to download `Seagate's SeaTools'
and (if) give the hdd's controller a try ... ;)

-- 
Esenlikle   <~>   Mehmet Kemal

_/_/  IBM Pollyanna Principle:
_/Machines should work,
_/People should think...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Linda Walsh]

Robert Hancock wrote:


If this is a Seagate, I believe that they don't have AAM enabled on 
any of their newer drives (something about a lawsuit for patent 
infringement on that feature, or something). Quite likely they don't 
support that power management command, either.

--
   Do you have a source for this -- haven't heard of such a conflict -- 
besides, doesn't
ATA-7 require some of those functions?  Given the trend toward 
power-saving and
quieter (also usually less vibration)  hard disks, I strongly disbelieve 
Seagate would
remove those features -- especially since they are mentioned on 
Seagate's drive

information page as being supported features.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Alan Cox]

On Sun, 06 Jan 2008 12:25:10 -0800
Linda Walsh [EMAIL PROTECTED] wrote:

 Robert Hancock wrote:
 
  If this is a Seagate, I believe that they don't have AAM enabled on 
  any of their newer drives (something about a lawsuit for patent 
  infringement on that feature, or something). Quite likely they don't 
  support that power management command, either.
 --
 Do you have a source for this -- haven't heard of such a conflict -- 

There were patent questions around AAM. There are some discussions on the
t13 archive then it goes silent and nothing is ever said again, which I
imagine is when it got lawyered.

 besides, doesn't
 ATA-7 require some of those functions? 

No.

Alan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Linda Walsh]

Robert Hancock wrote:


If this is a Seagate, I believe that they don't have AAM enabled on 
any of their newer drives (something about a lawsuit for patent 
infringement on that feature, or something). Quite likely they don't 
support that power management command, either.

--
   Do you have a source for this -- haven't heard of such a conflict -- 
besides, doesn't
ATA-7 require some of those functions?  Given the trend toward 
power-saving and
quieter (also usually less vibration)  hard disks, I strongly disbelieve 
Seagate would
remove those features -- especially since they are mentioned on 
Seagate's drive

information page as being supported features.



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Mehmet Kemal EROL]

Linda Walsh:

 
 Seagate would
 remove those features -- especially since they are mentioned on 
 Seagate's drive
 information page as being supported features.
 

Since you're there ... you might want to download `Seagate's SeaTools'
and (if) give the hdd's controller a try ... ;)

-- 
Esenlikle   ~   Mehmet Kemal

_/_/  IBM Pollyanna Principle:
_/Machines should work,
_/People should think...

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Robert Hancock]

Linda Walsh wrote:

Robert Hancock wrote:


Looks like the drive reports ERR/ABRT (command aborted), meaning it 
likely doesn't support those commands.



---
   Except the PATA version of the drive does (same capacity, & other 
specs).  Seagate would
disable "advanced" features for SATA but leave them for the older 
technology?  Possible,

but doesn't seem likely.


If this is a Seagate, I believe that they don't have AAM enabled on any 
of their newer drives (something about a lawsuit for patent infringement 
on that feature, or something). Quite likely they don't support that 
power management command, either.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Linda Walsh]

Robert Hancock wrote:


Looks like the drive reports ERR/ABRT (command aborted), meaning it 
likely doesn't support those commands.



---
   Except the PATA version of the drive does (same capacity, & other 
specs).  Seagate would
disable "advanced" features for SATA but leave them for the older 
technology?  Possible,

but doesn't seem likely.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Robert Hancock]

Linda Walsh wrote:

Robert Hancock wrote:

Linda Walsh wrote:

Alan Cox wrote:
rate began falling; at 128k block-reads-at-a-time or larger, it 
drops below

20MB/s (only on buffered SATA).

Try disabling NCQ - see if you've got a drive with the 'NCQ = no
readahead' flaw.

http://linux-ata.org/faq.html#ncq

---
   When drive initializes, dmesg says it has NCQ (depth 0/32)
   Reading the queue_depth under /sys, shows a queuedepth of "1".


Looks like your controller (or at least the Linux driver) doesn't 
actually support NCQ.



2) Drive Advanced Power Management setting("-B") (write-only):
"HDIO_DRIVE_CMD failed: Input/output error"
3) Drive Acoustic ("-M"), read = " acoustic  = not supported",
write = " HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error"


Not sure about these ones.. Does anything show up in dmesg when you do 
this?

---
   Yes:
   (for "-B", power-management)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: port_status 0x2020
ata1.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0
res 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1 (device error)
ata1.00: configured for UDMA/133
ata1: EH complete
sd 1:0:0:0: [sdb] 1465149168 512-byte hardware sectors (750156 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA


  (for "-M" acoustic management):
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: port_status 0x2020
ata1.00: cmd ef/42:fe:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0
res 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1 (device error)
ata1.00: configured for UDMA/133
ata1: EH complete
sd 1:0:0:0: [sdb] 1465149168 512-byte hardware sectors (750156 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA


Looks like the drive reports ERR/ABRT (command aborted), meaning it 
likely doesn't support those commands.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Holger Hoffstaette]

I got my Promise card and everything is up and running without problems,
using kernel 2.6.24-rc6 and the sata_promise driver out of the box:

00:0c.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 
TX2plus) (rev 02)
Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus)
Flags: bus master, 66MHz, medium devsel, latency 72, IRQ 17
I/O ports at b400 [size=128]
I/O ports at b800 [size=256]
Memory at ef025000 (32-bit, non-prefetchable) [size=4K]
Memory at ef00 (32-bit, non-prefetchable) [size=128K]
[virtual] Expansion ROM at 9802 [disabled] [size=32K]
Capabilities: [60] Power Management version 2
Kernel driver in use: sata_promise

Drive is a Samsung HD321KJ 320 GB and hdparm says the drive does ~75
MB/s; with dd it does buffered writes at ~85 MB/s and reads ~295 MB/s. So
all in all I'd say it's not the card or the driver..

hth,
Holger


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Mikael Pettersson]

Linda Walsh writes:
 > Robert Hancock wrote:
 > > Linda Walsh wrote:
 > >> Alan Cox wrote:
 >  rate began falling; at 128k block-reads-at-a-time or larger, it 
 >  drops below
 >  20MB/s (only on buffered SATA).
 > >>> Try disabling NCQ - see if you've got a drive with the 'NCQ = no
 > >>> readahead' flaw.
 > > http://linux-ata.org/faq.html#ncq
 > ---
 > When drive initializes, dmesg says it has NCQ (depth 0/32)
 > Reading the queue_depth under /sys, shows a queuedepth of "1".
 > 
 > But more importantly -- I notice a chronic error message associate
 > with this drive that may be causing some or all of the problem:
 > ---
 > Jan  2 20:06:10 Ishtar kernel: ata1.00: exception Emask 0x0 SAct 0x0 
 > SErr 0x0 action 0x2
 > Jan  2 20:06:10 Ishtar kernel: ata1.00: port_status 0x2008
 > Jan  2 20:06:10 Ishtar kernel: ata1.00: cmd 
 > c8/00:10:30:06:03/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in
 > Jan  2 20:06:10 Ishtar kernel:  res 
 > 50/00:00:3f:06:03/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
 > Jan  2 20:06:13 Ishtar kernel: ata1: limiting SATA link speed to 1.5 Gbps
 > Jan  2 20:06:13 Ishtar kernel: ata1.00: exception Emask 0x0 SAct 0x0 
 > SErr 0x0 action 0x6
 > Jan  2 20:06:13 Ishtar kernel: ata1.00: port_status 0x2008
 > Jan  2 20:06:13 Ishtar kernel: ata1.00: cmd 
 > c8/00:10:00:8b:04/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in
 > Jan  2 20:06:13 Ishtar kernel:  res 
 > 50/00:00:0f:8b:04/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
 > Jan  2 20:06:14 Ishtar kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 
 > 0x0 action 0x3
 > Jan  2 20:06:14 Ishtar kernel: ata1: hotplug_status 0x80
 > Jan  2 20:06:15 Ishtar kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 
 > 0x0 action 0x3
 > Jan  2 20:06:15 Ishtar kernel: ata1: hotplug_status 0x80
 > ---
 > What da heck?

Looks like the Promise ASIC SG bug. Apply

and let us know if things improve.

/Mikael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Mikael Pettersson]

Linda Walsh writes:
  Robert Hancock wrote:
   Linda Walsh wrote:
   Alan Cox wrote:
   rate began falling; at 128k block-reads-at-a-time or larger, it 
   drops below
   20MB/s (only on buffered SATA).
   Try disabling NCQ - see if you've got a drive with the 'NCQ = no
   readahead' flaw.
   http://linux-ata.org/faq.html#ncq
  ---
  When drive initializes, dmesg says it has NCQ (depth 0/32)
  Reading the queue_depth under /sys, shows a queuedepth of 1.
  
  But more importantly -- I notice a chronic error message associate
  with this drive that may be causing some or all of the problem:
  ---
  Jan  2 20:06:10 Ishtar kernel: ata1.00: exception Emask 0x0 SAct 0x0 
  SErr 0x0 action 0x2
  Jan  2 20:06:10 Ishtar kernel: ata1.00: port_status 0x2008
  Jan  2 20:06:10 Ishtar kernel: ata1.00: cmd 
  c8/00:10:30:06:03/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in
  Jan  2 20:06:10 Ishtar kernel:  res 
  50/00:00:3f:06:03/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
  Jan  2 20:06:13 Ishtar kernel: ata1: limiting SATA link speed to 1.5 Gbps
  Jan  2 20:06:13 Ishtar kernel: ata1.00: exception Emask 0x0 SAct 0x0 
  SErr 0x0 action 0x6
  Jan  2 20:06:13 Ishtar kernel: ata1.00: port_status 0x2008
  Jan  2 20:06:13 Ishtar kernel: ata1.00: cmd 
  c8/00:10:00:8b:04/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in
  Jan  2 20:06:13 Ishtar kernel:  res 
  50/00:00:0f:8b:04/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
  Jan  2 20:06:14 Ishtar kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 
  0x0 action 0x3
  Jan  2 20:06:14 Ishtar kernel: ata1: hotplug_status 0x80
  Jan  2 20:06:15 Ishtar kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 
  0x0 action 0x3
  Jan  2 20:06:15 Ishtar kernel: ata1: hotplug_status 0x80
  ---
  What da heck?

Looks like the Promise ASIC SG bug. Apply
http://user.it.uu.se/~mikpe/linux/patches/sata_promise/patch-sata_promise-1-asic-sg-bug-fix-v3-2.6.23
and let us know if things improve.

/Mikael
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Holger Hoffstaette]

I got my Promise card and everything is up and running without problems,
using kernel 2.6.24-rc6 and the sata_promise driver out of the box:

00:0c.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 
TX2plus) (rev 02)
Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus)
Flags: bus master, 66MHz, medium devsel, latency 72, IRQ 17
I/O ports at b400 [size=128]
I/O ports at b800 [size=256]
Memory at ef025000 (32-bit, non-prefetchable) [size=4K]
Memory at ef00 (32-bit, non-prefetchable) [size=128K]
[virtual] Expansion ROM at 9802 [disabled] [size=32K]
Capabilities: [60] Power Management version 2
Kernel driver in use: sata_promise

Drive is a Samsung HD321KJ 320 GB and hdparm says the drive does ~75
MB/s; with dd it does buffered writes at ~85 MB/s and reads ~295 MB/s. So
all in all I'd say it's not the card or the driver..

hth,
Holger


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Robert Hancock]

Linda Walsh wrote:

Robert Hancock wrote:

Linda Walsh wrote:

Alan Cox wrote:
rate began falling; at 128k block-reads-at-a-time or larger, it 
drops below

20MB/s (only on buffered SATA).

Try disabling NCQ - see if you've got a drive with the 'NCQ = no
readahead' flaw.

http://linux-ata.org/faq.html#ncq

---
   When drive initializes, dmesg says it has NCQ (depth 0/32)
   Reading the queue_depth under /sys, shows a queuedepth of 1.


Looks like your controller (or at least the Linux driver) doesn't 
actually support NCQ.



2) Drive Advanced Power Management setting(-B) (write-only):
HDIO_DRIVE_CMD failed: Input/output error
3) Drive Acoustic (-M), read =  acoustic  = not supported,
write =  HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error


Not sure about these ones.. Does anything show up in dmesg when you do 
this?

---
   Yes:
   (for -B, power-management)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: port_status 0x2020
ata1.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0
res 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1 (device error)
ata1.00: configured for UDMA/133
ata1: EH complete
sd 1:0:0:0: [sdb] 1465149168 512-byte hardware sectors (750156 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA


  (for -M acoustic management):
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: port_status 0x2020
ata1.00: cmd ef/42:fe:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0
res 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1 (device error)
ata1.00: configured for UDMA/133
ata1: EH complete
sd 1:0:0:0: [sdb] 1465149168 512-byte hardware sectors (750156 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA


Looks like the drive reports ERR/ABRT (command aborted), meaning it 
likely doesn't support those commands.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Linda Walsh]

Robert Hancock wrote:


Looks like the drive reports ERR/ABRT (command aborted), meaning it 
likely doesn't support those commands.



---
   Except the PATA version of the drive does (same capacity,  other 
specs).  Seagate would
disable advanced features for SATA but leave them for the older 
technology?  Possible,

but doesn't seem likely.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Linda Walsh]

Robert Hancock wrote:

Linda Walsh wrote:

Alan Cox wrote:
rate began falling; at 128k block-reads-at-a-time or larger, it 
drops below

20MB/s (only on buffered SATA).

Try disabling NCQ - see if you've got a drive with the 'NCQ = no
readahead' flaw.

http://linux-ata.org/faq.html#ncq

---
   When drive initializes, dmesg says it has NCQ (depth 0/32)
   Reading the queue_depth under /sys, shows a queuedepth of "1".

But more importantly -- I notice a chronic error message associate
with this drive that may be causing some or all of the problem:
---
Jan  2 20:06:10 Ishtar kernel: ata1.00: exception Emask 0x0 SAct 0x0 
SErr 0x0 action 0x2

Jan  2 20:06:10 Ishtar kernel: ata1.00: port_status 0x2008
Jan  2 20:06:10 Ishtar kernel: ata1.00: cmd 
c8/00:10:30:06:03/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in
Jan  2 20:06:10 Ishtar kernel:  res 
50/00:00:3f:06:03/00:00:00:00:00/e0 Emask 0x2 (HSM violation)

Jan  2 20:06:13 Ishtar kernel: ata1: limiting SATA link speed to 1.5 Gbps
Jan  2 20:06:13 Ishtar kernel: ata1.00: exception Emask 0x0 SAct 0x0 
SErr 0x0 action 0x6

Jan  2 20:06:13 Ishtar kernel: ata1.00: port_status 0x2008
Jan  2 20:06:13 Ishtar kernel: ata1.00: cmd 
c8/00:10:00:8b:04/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in
Jan  2 20:06:13 Ishtar kernel:  res 
50/00:00:0f:8b:04/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
Jan  2 20:06:14 Ishtar kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 
0x0 action 0x3

Jan  2 20:06:14 Ishtar kernel: ata1: hotplug_status 0x80
Jan  2 20:06:15 Ishtar kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 
0x0 action 0x3

Jan  2 20:06:15 Ishtar kernel: ata1: hotplug_status 0x80
---
What da heck?  Note, this is with NCQ-queuing set to "1".  Only 
reference I could find for this error referred to "older drives", but 
this is a

2007-model year drive with ATA-7 and udma-6.

I don't think you can get or get the multi count currently, it just 
uses the best supported value.

ok



2) Drive Advanced Power Management setting("-B") (write-only):
"HDIO_DRIVE_CMD failed: Input/output error"
3) Drive Acoustic ("-M"), read = " acoustic  = not supported",
write = " HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error"


Not sure about these ones.. Does anything show up in dmesg when you do 
this?

---
   Yes:
   (for "-B", power-management)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: port_status 0x2020
ata1.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0
res 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1 (device error)
ata1.00: configured for UDMA/133
ata1: EH complete
sd 1:0:0:0: [sdb] 1465149168 512-byte hardware sectors (750156 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA


  (for "-M" acoustic management):
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: port_status 0x2020
ata1.00: cmd ef/42:fe:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0
res 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1 (device error)
ata1.00: configured for UDMA/133
ata1: EH complete
sd 1:0:0:0: [sdb] 1465149168 512-byte hardware sectors (750156 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Robert Hancock]

Linda Walsh wrote:

Alan Cox wrote:
rate began falling; at 128k block-reads-at-a-time or larger, it drops 
below

20MB/s (only on buffered SATA).


Try disabling NCQ - see if you've got a drive with the 'NCQ = no
readahead' flaw.

---
  I'm not aware, off hand, how to disable NCQ.  I haven't had any
NCQ- or SATA- capable disks before a few weeks ago.


See here:

http://linux-ata.org/faq.html#ncq



The only way I could tell before was using hdparm to read the 
parameters. Since that doesn't work, it's hard to tell if they

are set correctly...


hdparm supports identify to read modes on drives with libata. The one
thing you cannot do is force modes right now.


More importantly, how does one set parameters for acoustic and power
saving parameters?  Some of my disks are used as 'backup' devices for my


hdparm or blktool



 I have hdparm-v7.7. There are some areas where it shows information, 
but areas where it

does not work jump out and lead me to suspect whether or not areas
that don't give explicit "ERROR" messages are presenting valid info.

Problem areas (using hdparm, disk=Seagate Barracuda 16MB cache, model=
ST3750640AS):
1) The drives current 'multicount' setting isn't readable or settable.
param "-i" shows "?16?" (with question marks around 16) and "-I" simply
shows "?" for the current setting.  Attempting to  it:
"HDIO__MULTCOUNT failed: Inappropriate ioctl for device"


I don't think you can get or get the multi count currently, it just uses 
the best supported value.



2) Drive Advanced Power Management setting("-B") (write-only):
"HDIO_DRIVE_CMD failed: Input/output error"
3) Drive Acoustic ("-M"), read = " acoustic  = not supported",
write = " HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error"
  Note: drive detailed info from "-I" says:
   "Recommended acoustic management value: 254, current value: 0"
  (i.e. - there seems to be no way to set recommended value)


Not sure about these ones.. Does anything show up in dmesg when you do this?


4) 32-bit IO setting ("-c") (don't know if this important given the disk's
raw-read speed, it may be meaningless for SATA)
"IO_support=  0 (default 16-bit)"*
*


This setting is not meaningful for anything using DMA.


FWIW -- the spindown/standby timeout ("S") does seem to work.

other computers.  With the ATA disks, they were kept "spun down" when 
not

being used (only used, 'normally', in early AM hours).


Well for backup devices you can use the fact SATA is hot/warm plug.

---
   I don't follow. It is an internal drive.  Are their software "logically
unplug" commands that automatically re-"plug-in" the drive on access
and spin it back up like the spindown/standby timeout does?  Or were
you referring to SATA's general hot/warm plug ability (if my hardware
setup, drive-slots, etc, permitted removability)?


I think they were referring to physically hotplugging the drive. This is 
more practical if you have a removable drive caddy, or if the drive is 
hooked up through eSATA.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Linda Walsh]

Alan Cox wrote:

rate began falling; at 128k block-reads-at-a-time or larger, it drops below
20MB/s (only on buffered SATA).


Try disabling NCQ - see if you've got a drive with the 'NCQ = no
readahead' flaw.

---
  I'm not aware, off hand, how to disable NCQ.  I haven't had any
NCQ- or SATA- capable disks before a few weeks ago.

The only way I could tell before was using hdparm to read the 
parameters. Since that doesn't work, it's hard to tell if they

are set correctly...


hdparm supports identify to read modes on drives with libata. The one
thing you cannot do is force modes right now.


More importantly, how does one set parameters for acoustic and power
saving parameters?  Some of my disks are used as 'backup' devices for my


hdparm or blktool



 I have hdparm-v7.7. 
There are some areas where it shows information, but areas where it

does not work jump out and lead me to suspect whether or not areas
that don't give explicit "ERROR" messages are presenting valid info.

Problem areas (using hdparm, disk=Seagate Barracuda 16MB cache, model=
ST3750640AS):
1) The drives current 'multicount' setting isn't readable or settable.
param "-i" shows "?16?" (with question marks around 16) and "-I" simply
shows "?" for the current setting.  Attempting to  it:
"HDIO__MULTCOUNT failed: Inappropriate ioctl for device"
2) Drive Advanced Power Management setting("-B") (write-only):
"HDIO_DRIVE_CMD failed: Input/output error"
3) Drive Acoustic ("-M"), read = " acoustic  = not supported",
write = " HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error"
  Note: drive detailed info from "-I" says:
   "Recommended acoustic management value: 254, current value: 0"
  (i.e. - there seems to be no way to set recommended value)
4) 32-bit IO setting ("-c") (don't know if this important given the disk's
raw-read speed, it may be meaningless for SATA)
"IO_support=  0 (default 16-bit)"*
*
FWIW -- the spindown/standby timeout ("S") does seem to work.


other computers.  With the ATA disks, they were kept "spun down" when not
being used (only used, 'normally', in early AM hours).


Well for backup devices you can use the fact SATA is hot/warm plug.

---
   I don't follow. It is an internal drive.  Are their software "logically
unplug" commands that automatically re-"plug-in" the drive on access
and spin it back up like the spindown/standby timeout does?  Or were
you referring to SATA's general hot/warm plug ability (if my hardware
setup, drive-slots, etc, permitted removability)?



Another new "problem" (not as important) -- even though SATA disks are
called with "sdX", my ATA disks that *were* at hda-hdc are now at hde-hdg.


NOTABUG - your BIOS has decided to move them from the legacy addresses so
they move from hda-d to e-g.
Sorry for my unclear usage -- by "problem" I meant that it was(is) an 
"unexpected behavior".  I'm sure the kernel is following the BIOS's

directions, I'm just not sure why a (supposedly), SATA-only card would
cause my BIOS to reserve 4 "[P]ATA-drives" after installing the
card.  It may be symptomatic of some "cost-cutting" measure by the
card manufacurer.  I just don't know why it's happening right now.

*however* -- it is "annoying" -- if the kernel reserves hda-hdd at the
request of the BIOS, it _might_ be useful if "udev" also populated
/dev/ with devices for hda-hdd.  I.e. -- "something" on the linux-kernel
software-side of things knows that hda-hdd aren't really their as
the devices are not created in the udev-managed filesystem upon boot.

It may not be a kernel-bug insomuch as the kernel is intended to work,
but it doesn't seem that it is a "valuable feature".  My reasoning:
"Hd" drive letters are "unstable" because plugging/unplugging HD
controllers and/or drives can change the HD lettering.  Consequently,
it is considered "best practice" to mount disks by label instead of
by drive letter under linux.  If it is acknowledged that the drive
letters are not stable, then why not have udev assign "hd" letters
only to drives that 'exist'? 


Conversely, if udev had 'reserved' (created) hda-hdd devices because
the BIOS said they were 'reserved', then I can see it might have some
usefulness.  This may be a 'udev'-specific concern or configuration
issue as well.  I ran into it as I was going to try to use LILO's
"drive=" and "bios=" params to move the disks back to start with 'hda',
but lilo refused, saying 'hda' didn't exist (which it doesn't, as
indicated in the /dev-mounted udev 'filesystem').  It's not something
impossible to workaround or fix, just seemed odd to move the working
drives up to hde-g, when they could have been mapped to hda-c with
no apparent conflicts. 


I know, it's a subtlety, but one not inconsistent with (wincing at
the admission of even knowing this, let along the comparison) WinXP's
feature set.

 If a disk was mounted and associated with a specific letter, then
later another controller or disk is added that would cause 're-lettering'
under linux, it 

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Linda Walsh]

Holger Hoffstaette wrote:

Another new "problem" (not as important) -- even though SATA disks are
called with "sdX", my ATA disks that *were* at hda-hdc are now at hde-hdg.
Devices hda-hdd are not populated in my dev directory on bootup.  Of



I think this is because the Promise SATA card also has one or more PATA
channels, so if the card is activated it takes precedence over your old
controller. But it should only be one channel, not four?
As for the other problem - I plan on adding such a card to one of my
systems during the week and might be able to contribute some findings.
  

---
   FYI - this specific card was sold as "4-SATA" channels.  There were
other contemporary (same package design) Promise cards offered that
were advertised to 1) support 2-sata+2pata or 2) support RAID w/SATA.
I think there was also a RAID card supporting PATA-only as well.

   It is quite possible (though thoroughly 'lame'), that they have 1
card providing, both 4 SATA and 4 PATA, but only provide the connectors
for some subset, with the RAID being a firmware-only (software-only)
option that is implemented in software on the card (as my web searching
indicated was true for some Promise SATA cards). 


   Perhaps an "RFE" for hdparm might be someway to specify the
target device by using a label on one of the devices partitions, since
my boot-time hdparm settings suffer from the same problems my
/etc/fstab used to suffer before "labels" were available.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Linda Walsh]

Holger Hoffstaette wrote:

Another new problem (not as important) -- even though SATA disks are
called with sdX, my ATA disks that *were* at hda-hdc are now at hde-hdg.
Devices hda-hdd are not populated in my dev directory on bootup.  Of



I think this is because the Promise SATA card also has one or more PATA
channels, so if the card is activated it takes precedence over your old
controller. But it should only be one channel, not four?
As for the other problem - I plan on adding such a card to one of my
systems during the week and might be able to contribute some findings.
  

---
   FYI - this specific card was sold as 4-SATA channels.  There were
other contemporary (same package design) Promise cards offered that
were advertised to 1) support 2-sata+2pata or 2) support RAID w/SATA.
I think there was also a RAID card supporting PATA-only as well.

   It is quite possible (though thoroughly 'lame'), that they have 1
card providing, both 4 SATA and 4 PATA, but only provide the connectors
for some subset, with the RAID being a firmware-only (software-only)
option that is implemented in software on the card (as my web searching
indicated was true for some Promise SATA cards). 


   Perhaps an RFE for hdparm might be someway to specify the
target device by using a label on one of the devices partitions, since
my boot-time hdparm settings suffer from the same problems my
/etc/fstab used to suffer before labels were available.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Linda Walsh]

Alan Cox wrote:

rate began falling; at 128k block-reads-at-a-time or larger, it drops below
20MB/s (only on buffered SATA).


Try disabling NCQ - see if you've got a drive with the 'NCQ = no
readahead' flaw.

---
  I'm not aware, off hand, how to disable NCQ.  I haven't had any
NCQ- or SATA- capable disks before a few weeks ago.

The only way I could tell before was using hdparm to read the 
parameters. Since that doesn't work, it's hard to tell if they

are set correctly...


hdparm supports identify to read modes on drives with libata. The one
thing you cannot do is force modes right now.


More importantly, how does one set parameters for acoustic and power
saving parameters?  Some of my disks are used as 'backup' devices for my


hdparm or blktool



 I have hdparm-v7.7. 
There are some areas where it shows information, but areas where it

does not work jump out and lead me to suspect whether or not areas
that don't give explicit ERROR messages are presenting valid info.

Problem areas (using hdparm, disk=Seagate Barracuda 16MB cache, model=
ST3750640AS):
1) The drives current 'multicount' setting isn't readable or settable.
param -i shows ?16? (with question marks around 16) and -I simply
shows ? for the current setting.  Attempting to read|set it:
HDIO_GET|SET_MULTCOUNT failed: Inappropriate ioctl for device
2) Drive Advanced Power Management setting(-B) (write-only):
HDIO_DRIVE_CMD failed: Input/output error
3) Drive Acoustic (-M), read =  acoustic  = not supported,
write =  HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error
  Note: drive detailed info from -I says:
   Recommended acoustic management value: 254, current value: 0
  (i.e. - there seems to be no way to set recommended value)
4) 32-bit IO setting (-c) (don't know if this important given the disk's
raw-read speed, it may be meaningless for SATA)
IO_support=  0 (default 16-bit)*
*
FWIW -- the spindown/standby timeout (S) does seem to work.


other computers.  With the ATA disks, they were kept spun down when not
being used (only used, 'normally', in early AM hours).


Well for backup devices you can use the fact SATA is hot/warm plug.

---
   I don't follow. It is an internal drive.  Are their software logically
unplug commands that automatically re-plug-in the drive on access
and spin it back up like the spindown/standby timeout does?  Or were
you referring to SATA's general hot/warm plug ability (if my hardware
setup, drive-slots, etc, permitted removability)?



Another new problem (not as important) -- even though SATA disks are
called with sdX, my ATA disks that *were* at hda-hdc are now at hde-hdg.


NOTABUG - your BIOS has decided to move them from the legacy addresses so
they move from hda-d to e-g.
Sorry for my unclear usage -- by problem I meant that it was(is) an 
unexpected behavior.  I'm sure the kernel is following the BIOS's

directions, I'm just not sure why a (supposedly), SATA-only card would
cause my BIOS to reserve 4 [P]ATA-drives after installing the
card.  It may be symptomatic of some cost-cutting measure by the
card manufacurer.  I just don't know why it's happening right now.

*however* -- it is annoying -- if the kernel reserves hda-hdd at the
request of the BIOS, it _might_ be useful if udev also populated
/dev/ with devices for hda-hdd.  I.e. -- something on the linux-kernel
software-side of things knows that hda-hdd aren't really their as
the devices are not created in the udev-managed filesystem upon boot.

It may not be a kernel-bug insomuch as the kernel is intended to work,
but it doesn't seem that it is a valuable feature.  My reasoning:
Hd drive letters are unstable because plugging/unplugging HD
controllers and/or drives can change the HD lettering.  Consequently,
it is considered best practice to mount disks by label instead of
by drive letter under linux.  If it is acknowledged that the drive
letters are not stable, then why not have udev assign hd letters
only to drives that 'exist'? 


Conversely, if udev had 'reserved' (created) hda-hdd devices because
the BIOS said they were 'reserved', then I can see it might have some
usefulness.  This may be a 'udev'-specific concern or configuration
issue as well.  I ran into it as I was going to try to use LILO's
drive= and bios= params to move the disks back to start with 'hda',
but lilo refused, saying 'hda' didn't exist (which it doesn't, as
indicated in the /dev-mounted udev 'filesystem').  It's not something
impossible to workaround or fix, just seemed odd to move the working
drives up to hde-g, when they could have been mapped to hda-c with
no apparent conflicts. 


I know, it's a subtlety, but one not inconsistent with (wincing at
the admission of even knowing this, let along the comparison) WinXP's
feature set.

 If a disk was mounted and associated with a specific letter, then
later another controller or disk is added that would cause 're-lettering'
under linux, it won't necessarily cause re-lettering under WinXP (as
it 

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Robert Hancock]

Linda Walsh wrote:

Alan Cox wrote:
rate began falling; at 128k block-reads-at-a-time or larger, it drops 
below

20MB/s (only on buffered SATA).


Try disabling NCQ - see if you've got a drive with the 'NCQ = no
readahead' flaw.

---
  I'm not aware, off hand, how to disable NCQ.  I haven't had any
NCQ- or SATA- capable disks before a few weeks ago.


See here:

http://linux-ata.org/faq.html#ncq



The only way I could tell before was using hdparm to read the 
parameters. Since that doesn't work, it's hard to tell if they

are set correctly...


hdparm supports identify to read modes on drives with libata. The one
thing you cannot do is force modes right now.


More importantly, how does one set parameters for acoustic and power
saving parameters?  Some of my disks are used as 'backup' devices for my


hdparm or blktool



 I have hdparm-v7.7. There are some areas where it shows information, 
but areas where it

does not work jump out and lead me to suspect whether or not areas
that don't give explicit ERROR messages are presenting valid info.

Problem areas (using hdparm, disk=Seagate Barracuda 16MB cache, model=
ST3750640AS):
1) The drives current 'multicount' setting isn't readable or settable.
param -i shows ?16? (with question marks around 16) and -I simply
shows ? for the current setting.  Attempting to read|set it:
HDIO_GET|SET_MULTCOUNT failed: Inappropriate ioctl for device


I don't think you can get or get the multi count currently, it just uses 
the best supported value.



2) Drive Advanced Power Management setting(-B) (write-only):
HDIO_DRIVE_CMD failed: Input/output error
3) Drive Acoustic (-M), read =  acoustic  = not supported,
write =  HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error
  Note: drive detailed info from -I says:
   Recommended acoustic management value: 254, current value: 0
  (i.e. - there seems to be no way to set recommended value)


Not sure about these ones.. Does anything show up in dmesg when you do this?


4) 32-bit IO setting (-c) (don't know if this important given the disk's
raw-read speed, it may be meaningless for SATA)
IO_support=  0 (default 16-bit)*
*


This setting is not meaningful for anything using DMA.


FWIW -- the spindown/standby timeout (S) does seem to work.

other computers.  With the ATA disks, they were kept spun down when 
not

being used (only used, 'normally', in early AM hours).


Well for backup devices you can use the fact SATA is hot/warm plug.

---
   I don't follow. It is an internal drive.  Are their software logically
unplug commands that automatically re-plug-in the drive on access
and spin it back up like the spindown/standby timeout does?  Or were
you referring to SATA's general hot/warm plug ability (if my hardware
setup, drive-slots, etc, permitted removability)?


I think they were referring to physically hotplugging the drive. This is 
more practical if you have a removable drive caddy, or if the drive is 
hooked up through eSATA.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Linda Walsh]

Robert Hancock wrote:

Linda Walsh wrote:

Alan Cox wrote:
rate began falling; at 128k block-reads-at-a-time or larger, it 
drops below

20MB/s (only on buffered SATA).

Try disabling NCQ - see if you've got a drive with the 'NCQ = no
readahead' flaw.

http://linux-ata.org/faq.html#ncq

---
   When drive initializes, dmesg says it has NCQ (depth 0/32)
   Reading the queue_depth under /sys, shows a queuedepth of 1.

But more importantly -- I notice a chronic error message associate
with this drive that may be causing some or all of the problem:
---
Jan  2 20:06:10 Ishtar kernel: ata1.00: exception Emask 0x0 SAct 0x0 
SErr 0x0 action 0x2

Jan  2 20:06:10 Ishtar kernel: ata1.00: port_status 0x2008
Jan  2 20:06:10 Ishtar kernel: ata1.00: cmd 
c8/00:10:30:06:03/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in
Jan  2 20:06:10 Ishtar kernel:  res 
50/00:00:3f:06:03/00:00:00:00:00/e0 Emask 0x2 (HSM violation)

Jan  2 20:06:13 Ishtar kernel: ata1: limiting SATA link speed to 1.5 Gbps
Jan  2 20:06:13 Ishtar kernel: ata1.00: exception Emask 0x0 SAct 0x0 
SErr 0x0 action 0x6

Jan  2 20:06:13 Ishtar kernel: ata1.00: port_status 0x2008
Jan  2 20:06:13 Ishtar kernel: ata1.00: cmd 
c8/00:10:00:8b:04/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in
Jan  2 20:06:13 Ishtar kernel:  res 
50/00:00:0f:8b:04/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
Jan  2 20:06:14 Ishtar kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 
0x0 action 0x3

Jan  2 20:06:14 Ishtar kernel: ata1: hotplug_status 0x80
Jan  2 20:06:15 Ishtar kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 
0x0 action 0x3

Jan  2 20:06:15 Ishtar kernel: ata1: hotplug_status 0x80
---
What da heck?  Note, this is with NCQ-queuing set to 1.  Only 
reference I could find for this error referred to older drives, but 
this is a

2007-model year drive with ATA-7 and udma-6.

I don't think you can get or get the multi count currently, it just 
uses the best supported value.

ok



2) Drive Advanced Power Management setting(-B) (write-only):
HDIO_DRIVE_CMD failed: Input/output error
3) Drive Acoustic (-M), read =  acoustic  = not supported,
write =  HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error


Not sure about these ones.. Does anything show up in dmesg when you do 
this?

---
   Yes:
   (for -B, power-management)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: port_status 0x2020
ata1.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0
res 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1 (device error)
ata1.00: configured for UDMA/133
ata1: EH complete
sd 1:0:0:0: [sdb] 1465149168 512-byte hardware sectors (750156 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA


  (for -M acoustic management):
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: port_status 0x2020
ata1.00: cmd ef/42:fe:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0
res 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1 (device error)
ata1.00: configured for UDMA/133
ata1: EH complete
sd 1:0:0:0: [sdb] 1465149168 512-byte hardware sectors (750156 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Mark Lord]

I wanted to use the newer pata support in the SATA lib, but
got frustrated "real fast" by the lack of disk-parameter support
in the new pata library (hdparm is mostly broken; and the SCSI
utils aren't really intended for ATA(or SATA?) disks using the
SCSI interface.

...

Most hdparm flags work perfectly fine with libata,
unless perhaps you're using Fedora, which for some odd
reason was using a 2+ year old copy of hdparm until
very very recently.

As others noted, the only things not working are things that
libata itself chooses not to allow from userspace because libata
has better low-level drivers that can set those things automatically
in a more reliable fashion than we ever could with drivers/ide:
 DMA, 32-bit I/O, PIO/DMA xfer rates, hotplug stuff.

The rest, including acoustic and power-saving parameters,
work just fine with libata.

Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Mark Lord]

I wanted to use the newer pata support in the SATA lib, but
got frustrated real fast by the lack of disk-parameter support
in the new pata library (hdparm is mostly broken; and the SCSI
utils aren't really intended for ATA(or SATA?) disks using the
SCSI interface.

...

Most hdparm flags work perfectly fine with libata,
unless perhaps you're using Fedora, which for some odd
reason was using a 2+ year old copy of hdparm until
very very recently.

As others noted, the only things not working are things that
libata itself chooses not to allow from userspace because libata
has better low-level drivers that can set those things automatically
in a more reliable fashion than we ever could with drivers/ide:
 DMA, 32-bit I/O, PIO/DMA xfer rates, hotplug stuff.

The rest, including acoustic and power-saving parameters,
work just fine with libata.

Cheers
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Alan Cox]

> rate began falling and at 128k block-reads-at-a-time or larger, it drops 
> below
> 20MB/s (again, only on buffered SATA).   It's hard to imagine what would
> slow down buffered SATA reads but not ATA and SCSI reads of the same
> size.  I'm using the 'cfq' scheduler with everything running at default

Try disabling NCQ - see if you've got a drive with the 'NCQ = no
readahead' flaw.

> priorities, but again, why only SATA slowness?  It seems that at the driver
> level, using direct reads, the SATA disk has the highest read rate (near
> 80MB/s). 

Beats me - something is wrong that your setup triggers - could be
firmware funnies or Linux ones. 

> The only way I could tell before was using hdparm to read the 
> parameters.
> Since that doesn't work, it's hard to tell if they are set correctly, 
> but given

hdparm supports identify to read modes on drives with libata. The one
thing you cannot do is force modes right now.

> More importantly, how does one set parameters for acoustic and power
> saving parameters?  Some of my disks are used as 'backup' devices for my

hdparm or blktool

> other computers.  With the ATA disks, they were kept "spun down" when not
> being used (only used, 'normally', in early AM hours).

Well for backup devices you can use the fact SATA is hot/warm plug.

> Another new "problem" (not as important) -- even though SATA disks are
> called with "sdX", my ATA disks that *were* at hda-hdc are now at hde-hdg.

NOTABUG - your BIOS has decided to move them from the legacy addresses so
they move from hda-d to e-g.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Holger Hoffstaette]

On Mon, 31 Dec 2007 16:19:26 -0800, Linda Walsh wrote:

> [snip]
> Another new "problem" (not as important) -- even though SATA disks are
> called with "sdX", my ATA disks that *were* at hda-hdc are now at hde-hdg.
> Devices hda-hdd are not populated in my dev directory on bootup.  Of

I think this is because the Promise SATA card also has one or more PATA
channels, so if the card is activated it takes precedence over your old
controller. But it should only be one channel, not four?
As for the other problem - I plan on adding such a card to one of my
systems during the week and might be able to contribute some findings.

Holger


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Robert Hancock]

Linda Walsh wrote:

Robert Hancock wrote:
Have you tried using a different block size to see how that effects 
the results? There might be some funny interaction there.


   There is some interaction with the large block size (but only on the 
SATA
disk).  Counts were adjusted to keep the read near 2G (~2x physical 
memory).

 From 1k-16k block sizes, I got into the low-mid 40MB/s on buffered SATA
(compared to 50-60MB/s on ATA & SCSI).  Starting at 32k-64k, the read
rate began falling and at 128k block-reads-at-a-time or larger, it drops 
below

20MB/s (again, only on buffered SATA).   It's hard to imagine what would
slow down buffered SATA reads but not ATA and SCSI reads of the same
size.  I'm using the 'cfq' scheduler with everything running at default
priorities, but again, why only SATA slowness?  It seems that at the driver
level, using direct reads, the SATA disk has the highest read rate (near
80MB/s).
   It would certainly be perverse to have faster driver & device 
performance

equate to lower buffered I/O.


Not too sure on that one. I suspect one might have to trace the actual 
requests being received at the driver level somehow with buffered reads 
in order to diagnose what's going on there..





I wanted to use the newer pata support in the SATA lib, but
got frustrated "real fast" by the lack of disk-parameter support
in the new pata library (hdparm is mostly broken; and the SCSI
utils aren't really intended for ATA(or SATA?) disks using the
SCSI interface.


It's somewhat intentional that some of the hdparm commands (like for 
settting transfer modes, enable/disable DMA, etc.) don't work with 
libata. Most of them aren't necessary at all as correct DMA settings, 
etc. should always be set automatically (if not, please report as a bug).

---
   The only way I could tell before was using hdparm to read the 
parameters.
Since that doesn't work, it's hard to tell if they are set correctly, 
but given

the high performance at the device driver level, I'm guessing the params
are set correctly.


The settings in use should be reported in dmesg.






Since SATA's use ATA-7 (or at least the Seagate disk I
acquired seems to), shouldn't most of the hdparm commands
be functional on the SATA hardware as much as they would
be on PATA?  Or...maybe said a different way, is there
an "sdparm" that is to SATA what hdparm is to PATA?


It's the same libata code, so the same applies to some of the hdparm 
commands not being implemented, as above.

---
   Hmm... might be nice as an "RFE" to at least have the 'read-status'
commands work to see what the params are set to.
   More importantly, how does one set parameters for acoustic and power
saving parameters?  Some of my disks are used as 'backup' devices for my
other computers.  With the ATA disks, they were kept "spun down" when not
being used (only used, 'normally', in early AM hours).


I believe those hdparm commands for power-save and AAM are supposed to 
work (they just issue an ATA command to the disk). The ones that aren't 
implemented are the ones that actually commanded the IDE layer, like DMA 
on/off.




   Another new "problem" (not as important) -- even though SATA disks are
called with "sdX", my ATA disks that *were* at hda-hdc are now at hde-hdg.
Devices hda-hdd are not populated in my dev directory on bootup.  Of course
this throws off boot-scripts that set diskparams by "hd" and not
by label (using hdparm).  Seems like the SATA disks are suffering a partial
identity problem -- seeming to reserve hda-hdd, but using the "sd" disk 
names.

Is that a known problem?  If not, I'll add it to my queue for bug-filing...


Could be a udev problem, as it's what does the device naming..

--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Linda Walsh]

Robert Hancock wrote:
Have you tried using a different block size to see how that effects 
the results? There might be some funny interaction there.


   There is some interaction with the large block size (but only on the 
SATA

disk).  Counts were adjusted to keep the read near 2G (~2x physical memory).
From 1k-16k block sizes, I got into the low-mid 40MB/s on buffered SATA
(compared to 50-60MB/s on ATA & SCSI).  Starting at 32k-64k, the read
rate began falling and at 128k block-reads-at-a-time or larger, it drops 
below

20MB/s (again, only on buffered SATA).   It's hard to imagine what would
slow down buffered SATA reads but not ATA and SCSI reads of the same
size.  I'm using the 'cfq' scheduler with everything running at default
priorities, but again, why only SATA slowness?  It seems that at the driver
level, using direct reads, the SATA disk has the highest read rate (near
80MB/s). 

   It would certainly be perverse to have faster driver & device 
performance

equate to lower buffered I/O.



I wanted to use the newer pata support in the SATA lib, but
got frustrated "real fast" by the lack of disk-parameter support
in the new pata library (hdparm is mostly broken; and the SCSI
utils aren't really intended for ATA(or SATA?) disks using the
SCSI interface.


It's somewhat intentional that some of the hdparm commands (like for 
settting transfer modes, enable/disable DMA, etc.) don't work with 
libata. Most of them aren't necessary at all as correct DMA settings, 
etc. should always be set automatically (if not, please report as a bug).

---
   The only way I could tell before was using hdparm to read the 
parameters.
Since that doesn't work, it's hard to tell if they are set correctly, 
but given

the high performance at the device driver level, I'm guessing the params
are set correctly.




Since SATA's use ATA-7 (or at least the Seagate disk I
acquired seems to), shouldn't most of the hdparm commands
be functional on the SATA hardware as much as they would
be on PATA?  Or...maybe said a different way, is there
an "sdparm" that is to SATA what hdparm is to PATA?


It's the same libata code, so the same applies to some of the hdparm 
commands not being implemented, as above.

---
   Hmm... might be nice as an "RFE" to at least have the 'read-status'
commands work to see what the params are set to. 


   More importantly, how does one set parameters for acoustic and power
saving parameters?  Some of my disks are used as 'backup' devices for my
other computers.  With the ATA disks, they were kept "spun down" when not
being used (only used, 'normally', in early AM hours).

   Another new "problem" (not as important) -- even though SATA disks are
called with "sdX", my ATA disks that *were* at hda-hdc are now at hde-hdg.
Devices hda-hdd are not populated in my dev directory on bootup.  Of course
this throws off boot-scripts that set diskparams by "hd" and not
by label (using hdparm).  Seems like the SATA disks are suffering a partial
identity problem -- seeming to reserve hda-hdd, but using the "sd" disk 
names.

Is that a known problem?  If not, I'll add it to my queue for bug-filing...

thanks,
Linda

 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Linda Walsh]

Robert Hancock wrote:
Have you tried using a different block size to see how that effects 
the results? There might be some funny interaction there.


   There is some interaction with the large block size (but only on the 
SATA

disk).  Counts were adjusted to keep the read near 2G (~2x physical memory).
From 1k-16k block sizes, I got into the low-mid 40MB/s on buffered SATA
(compared to 50-60MB/s on ATA  SCSI).  Starting at 32k-64k, the read
rate began falling and at 128k block-reads-at-a-time or larger, it drops 
below

20MB/s (again, only on buffered SATA).   It's hard to imagine what would
slow down buffered SATA reads but not ATA and SCSI reads of the same
size.  I'm using the 'cfq' scheduler with everything running at default
priorities, but again, why only SATA slowness?  It seems that at the driver
level, using direct reads, the SATA disk has the highest read rate (near
80MB/s). 

   It would certainly be perverse to have faster driver  device 
performance

equate to lower buffered I/O.



I wanted to use the newer pata support in the SATA lib, but
got frustrated real fast by the lack of disk-parameter support
in the new pata library (hdparm is mostly broken; and the SCSI
utils aren't really intended for ATA(or SATA?) disks using the
SCSI interface.


It's somewhat intentional that some of the hdparm commands (like for 
settting transfer modes, enable/disable DMA, etc.) don't work with 
libata. Most of them aren't necessary at all as correct DMA settings, 
etc. should always be set automatically (if not, please report as a bug).

---
   The only way I could tell before was using hdparm to read the 
parameters.
Since that doesn't work, it's hard to tell if they are set correctly, 
but given

the high performance at the device driver level, I'm guessing the params
are set correctly.




Since SATA's use ATA-7 (or at least the Seagate disk I
acquired seems to), shouldn't most of the hdparm commands
be functional on the SATA hardware as much as they would
be on PATA?  Or...maybe said a different way, is there
an sdparm that is to SATA what hdparm is to PATA?


It's the same libata code, so the same applies to some of the hdparm 
commands not being implemented, as above.

---
   Hmm... might be nice as an RFE to at least have the 'read-status'
commands work to see what the params are set to. 


   More importantly, how does one set parameters for acoustic and power
saving parameters?  Some of my disks are used as 'backup' devices for my
other computers.  With the ATA disks, they were kept spun down when not
being used (only used, 'normally', in early AM hours).

   Another new problem (not as important) -- even though SATA disks are
called with sdX, my ATA disks that *were* at hda-hdc are now at hde-hdg.
Devices hda-hdd are not populated in my dev directory on bootup.  Of course
this throws off boot-scripts that set diskparams by hdname and not
by label (using hdparm).  Seems like the SATA disks are suffering a partial
identity problem -- seeming to reserve hda-hdd, but using the sd disk 
names.

Is that a known problem?  If not, I'll add it to my queue for bug-filing...

thanks,
Linda

 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Robert Hancock]

Linda Walsh wrote:

Robert Hancock wrote:
Have you tried using a different block size to see how that effects 
the results? There might be some funny interaction there.


   There is some interaction with the large block size (but only on the 
SATA
disk).  Counts were adjusted to keep the read near 2G (~2x physical 
memory).

 From 1k-16k block sizes, I got into the low-mid 40MB/s on buffered SATA
(compared to 50-60MB/s on ATA  SCSI).  Starting at 32k-64k, the read
rate began falling and at 128k block-reads-at-a-time or larger, it drops 
below

20MB/s (again, only on buffered SATA).   It's hard to imagine what would
slow down buffered SATA reads but not ATA and SCSI reads of the same
size.  I'm using the 'cfq' scheduler with everything running at default
priorities, but again, why only SATA slowness?  It seems that at the driver
level, using direct reads, the SATA disk has the highest read rate (near
80MB/s).
   It would certainly be perverse to have faster driver  device 
performance

equate to lower buffered I/O.


Not too sure on that one. I suspect one might have to trace the actual 
requests being received at the driver level somehow with buffered reads 
in order to diagnose what's going on there..





I wanted to use the newer pata support in the SATA lib, but
got frustrated real fast by the lack of disk-parameter support
in the new pata library (hdparm is mostly broken; and the SCSI
utils aren't really intended for ATA(or SATA?) disks using the
SCSI interface.


It's somewhat intentional that some of the hdparm commands (like for 
settting transfer modes, enable/disable DMA, etc.) don't work with 
libata. Most of them aren't necessary at all as correct DMA settings, 
etc. should always be set automatically (if not, please report as a bug).

---
   The only way I could tell before was using hdparm to read the 
parameters.
Since that doesn't work, it's hard to tell if they are set correctly, 
but given

the high performance at the device driver level, I'm guessing the params
are set correctly.


The settings in use should be reported in dmesg.






Since SATA's use ATA-7 (or at least the Seagate disk I
acquired seems to), shouldn't most of the hdparm commands
be functional on the SATA hardware as much as they would
be on PATA?  Or...maybe said a different way, is there
an sdparm that is to SATA what hdparm is to PATA?


It's the same libata code, so the same applies to some of the hdparm 
commands not being implemented, as above.

---
   Hmm... might be nice as an RFE to at least have the 'read-status'
commands work to see what the params are set to.
   More importantly, how does one set parameters for acoustic and power
saving parameters?  Some of my disks are used as 'backup' devices for my
other computers.  With the ATA disks, they were kept spun down when not
being used (only used, 'normally', in early AM hours).


I believe those hdparm commands for power-save and AAM are supposed to 
work (they just issue an ATA command to the disk). The ones that aren't 
implemented are the ones that actually commanded the IDE layer, like DMA 
on/off.




   Another new problem (not as important) -- even though SATA disks are
called with sdX, my ATA disks that *were* at hda-hdc are now at hde-hdg.
Devices hda-hdd are not populated in my dev directory on bootup.  Of course
this throws off boot-scripts that set diskparams by hdname and not
by label (using hdparm).  Seems like the SATA disks are suffering a partial
identity problem -- seeming to reserve hda-hdd, but using the sd disk 
names.

Is that a known problem?  If not, I'll add it to my queue for bug-filing...


Could be a udev problem, as it's what does the device naming..

--
Robert Hancock  Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Holger Hoffstaette]

On Mon, 31 Dec 2007 16:19:26 -0800, Linda Walsh wrote:

 [snip]
 Another new problem (not as important) -- even though SATA disks are
 called with sdX, my ATA disks that *were* at hda-hdc are now at hde-hdg.
 Devices hda-hdd are not populated in my dev directory on bootup.  Of

I think this is because the Promise SATA card also has one or more PATA
channels, so if the card is activated it takes precedence over your old
controller. But it should only be one channel, not four?
As for the other problem - I plan on adding such a card to one of my
systems during the week and might be able to contribute some findings.

Holger


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Alan Cox]

 rate began falling and at 128k block-reads-at-a-time or larger, it drops 
 below
 20MB/s (again, only on buffered SATA).   It's hard to imagine what would
 slow down buffered SATA reads but not ATA and SCSI reads of the same
 size.  I'm using the 'cfq' scheduler with everything running at default

Try disabling NCQ - see if you've got a drive with the 'NCQ = no
readahead' flaw.

 priorities, but again, why only SATA slowness?  It seems that at the driver
 level, using direct reads, the SATA disk has the highest read rate (near
 80MB/s). 

Beats me - something is wrong that your setup triggers - could be
firmware funnies or Linux ones. 

 The only way I could tell before was using hdparm to read the 
 parameters.
 Since that doesn't work, it's hard to tell if they are set correctly, 
 but given

hdparm supports identify to read modes on drives with libata. The one
thing you cannot do is force modes right now.

 More importantly, how does one set parameters for acoustic and power
 saving parameters?  Some of my disks are used as 'backup' devices for my

hdparm or blktool

 other computers.  With the ATA disks, they were kept spun down when not
 being used (only used, 'normally', in early AM hours).

Well for backup devices you can use the fact SATA is hot/warm plug.

 Another new problem (not as important) -- even though SATA disks are
 called with sdX, my ATA disks that *were* at hda-hdc are now at hde-hdg.

NOTABUG - your BIOS has decided to move them from the legacy addresses so
they move from hda-d to e-g.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/