[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
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!. But I'm a bit stuck with SCSI
Hi,
I have a big problem with my SC1425 Dell Servers. I use Linux Software
RAID on them and last days i make few tests on them to see the
reaction of the server about different situations like : power
failure, hard drive prower failure ...
And the hard drive prower failure was the problem. When i
On Wed, 27 Jun 2007 03:35:26 -0400, Jeff Garzik wrote:
Tejun Heo (9):
libata: kill the infamous abnormal status message
libata: kill non-sense warning message
libata: be less verbose about hpa
libata: remove unused variable from ata_eh_reset()
libata: fix
sata_inic162x can't do LBA48 properly yet. Whine loudly about it to
reduce confusion.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/sata_inic162x.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: work/drivers/ata/sata_inic162x.c
On 6/28/07, Tejun Heo [EMAIL PROTECTED] wrote:
sata_inic162x can't do LBA48 properly yet. Whine loudly about it to
reduce confusion.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/sata_inic162x.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index:
Greg Freemyer wrote:
Does it simply fail? Or does it corrupt?
In my Windows experience, if you try to write data past ~128GiB and
you don't have LBA48 support you get a wraparound effect that causes
corruption of the data below ~128GiB. I've seen it happen several
times under Win2K in
On Fri, 29 Jun 2007 01:27:29 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Greg Freemyer wrote:
Does it simply fail? Or does it corrupt?
In my Windows experience, if you try to write data past ~128GiB and
you don't have LBA48 support you get a wraparound effect that causes
corruption of
On 6/28/07, Tejun Heo [EMAIL PROTECTED] wrote:
Greg Freemyer wrote:
Does it simply fail? Or does it corrupt?
In my Windows experience, if you try to write data past ~128GiB and
you don't have LBA48 support you get a wraparound effect that causes
corruption of the data below ~128GiB. I've
Andrew Hall wrote:
Hi Mark,
The device is a Nexcom NSA1083 appliance:
http://www.nexcom.com/product/productshow.jsp?iid=13pid=878
It's an OEM appliance that uses the Intel 965 chipset. We use it as one of
three platforms for our access control and compliance products as it has 8
built in
Tejun Heo wrote:
sata_inic162x can't do LBA48 properly yet. Whine loudly about it to
reduce confusion.
Why not whine only when an affected device is actually present?
Cheers from OLS.
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL
Mark Lord wrote:
Tejun Heo wrote:
sata_inic162x can't do LBA48 properly yet. Whine loudly about it to
reduce confusion.
Why not whine only when an affected device is actually present?
That's sorta that I think...
Jeff
-
To unsubscribe from this list: send the line unsubscribe
Jeff Garzik wrote:
Mark Lord wrote:
Tejun Heo wrote:
sata_inic162x can't do LBA48 properly yet. Whine loudly about it to
reduce confusion.
Why not whine only when an affected device is actually present?
That's sorta that I think...
That was me being lazy. I'll just ban LBA28 disks on
Tejun Heo wrote:
Jeff Garzik wrote:
Mark Lord wrote:
Tejun Heo wrote:
sata_inic162x can't do LBA48 properly yet. Whine loudly about it to
reduce confusion.
Why not whine only when an affected device is actually present?
That's sorta that I think...
That was me being lazy. I'll just ban
From: Christian Lamparter [EMAIL PROTECTED]
ATA: add a PCI ID for Intel Santa Rosa PATA controller.
Signed-off-by: Christian Lamparter [EMAIL PROTECTED]
---
[against 2.6.22-rc6; patch also attached, use the attachment]
drivers/ata/ata_piix.c |2 ++
1 file changed, 2 insertions(+)
diff
Nevermind, I did it myself:
This ensures that we can easily make changes specific to the PATA port
on the newer SATA chips, and also does what I've been requesting -- use
the standard ata_bmdma_error_handler(), rather than creating custom code
that achieves the same effect.
diff --git
Uwe Koziolek wrote:
Nevermind, I did it myself:
This ensures that we can easily make changes specific to the PATA port
on the newer SATA chips, and also does what I've been requesting -- use
the standard ata_bmdma_error_handler(), rather than creating custom code
that achieves the same effect.
Jeff Garzik wrote:
Jeff,
Did you have added the patch you have mailed on 06.06. anywhere or is
this patch an email only patch. And how to continue?
It's in my mbox queue, should be in my next run... :)
Jeff
I have 3 fixes that i want to add on top
- a compilation fix for your fix
I'm betting that the SATA/PATA converter is getting confused with
the ata_piix driver's attempt to use MDMA2 on it.
PIO appears to be working fine -- the BIOS uses it to boot,
and libata uses it to do the IDENTIFY operation.
So, try this hack, which should force ata_piix to use only PIO
The sata_nv driver was missing the change_queue_depth hook in the SCSI host
template which the other NCQ-capable libata drivers had. This made it impossible
to change the queue depth by user request. Add this in.
Signed-off-by: Robert Hancock [EMAIL PROTECTED]
---
Andrew Hall wrote:
Yes!! It worked.. which means you were right - forcing the channel to PIO4
and the drive was happy. The problem I have now is that we do in fact also
have a SATA HDD connected to the same controller used for database and
logging data - this now also is forced to use PIO4. How
Jeff Garzik wrote:
Tejun Heo wrote:
Jeff Garzik wrote:
Mark Lord wrote:
Tejun Heo wrote:
sata_inic162x can't do LBA48 properly yet. Whine loudly about it to
reduce confusion.
Why not whine only when an affected device is actually present?
That's sorta that I think...
That was me being
Mark Lord wrote:
I wonder if PIO works for LBA48 on that chipset (very, *very* likely).
HOB register access doesn't work (even get native max address is broken).
Maybe just fall back to PIO for an LBA48 drive.
Or even better, fall back to PIO only for sectors beyond 128GB.
???
Or wait
Hello,
Mark Lord wrote:
Here's a slightly modified hack, which should leave your SATA
drive working as well as the CF card.
Tejun / Alan : do we really want to continue attempting mdma2
on a modern chipset such as ICH8 ???
One thing that worries me is that we have reports where the IDE
Here's a slightly modified hack, which should leave your SATA
drive working as well as the CF card.
Tejun / Alan : do we really want to continue attempting mdma2
on a modern chipset such as ICH8 ???
The best mdma2 can do is the same throughput as pio4,
and the bus occupancy is so high
Tejun Heo wrote:
Hello,
Mark Lord wrote:
Here's a slightly modified hack, which should leave your SATA
drive working as well as the CF card.
Tejun / Alan : do we really want to continue attempting mdma2
on a modern chipset such as ICH8 ???
One thing that worries me is that we have reports
Andrew Hall wrote:
..
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
--- linux/drivers/ata/ata_piix.c.orig 2007-06-10 18:58:27.0
-0400
+++ linux/drivers/ata/ata_piix.c2007-06-28 21:09:04.0 -0400
@@ -537,7 +537,7 @@
.flags = PIIX_SATA_FLAGS |
sata_inic162x can't do LBA48 properly yet and is likely to corrupt
data on drives larger than LBA28 limit. Disable LBA48 devices during
device configuration.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/sata_inic162x.c |7 +++
1 file changed, 7 insertions(+)
Index:
You can certainly also thank Tejun and Jeff,
for making libata so easy to tune with a one-liner liner like this!
Per my other email -- did you try the legacy IDE driver
instead of libata? Can you provide a boot log from that for Tejun?
Too true.. thanks Tejun, Jeff and Alan also.. much
29 matches
Mail list logo