Tejun Heo wrote:
[The previous replay mysteriously didn't include Eric in To:, sorry,
quoting whole message here.]
Tejun Heo wrote:
Hello, Eric.
Eric D. Mudama wrote:
Per Jeff's suggestion, this patch rearranges the info printed for ATA
drives into dmesg to add the full ATA firmware revision
Sergei,
How could one then explain
current capacity is 78140160 sectors would be 0x04A85300
native capacity is 185074430006016 sectors would be0xA852FFA85300
? First three bytes ok, then the other three bytes rubbish?
Note that they're not complete garbage but
Hello.
Steven Scholz wrote:
How could one then explain
current capacity is 78140160 sectors would be 0x04A85300
native capacity is 185074430006016 sectors would be0xA852FFA85300
? First three bytes ok, then the other three bytes rubbish?
Note that they're not
Sergei,
I also have doubts about IDE_CONTROL_REG being properly
decoded/handled in your FPGA.
Hmm. We just verified and are convinced to do it the right way. ;-)
hda: Host Protected Area detected.
current capacity is 78140160 sectors (40007 MB)
native capacity is
Sergei,
The FPGA does nothing except decoding adresseses from the ARM cpu,
controlling the A[2..0], CS[1..0], IOR, IOW lines of the HDD.
I've not seen you quoting the code that sets ofsset for the
IDE_CONTROL_REG, BTW... Without this register, LBA48 is completely broken
for (i =
Hello.
Steven Scholz wrote:
Sergei,
The FPGA does nothing except decoding adresseses from the ARM cpu,
controlling the A[2..0], CS[1..0], IOR, IOW lines of the HDD.
I've not seen you quoting the code that sets ofsset for the
IDE_CONTROL_REG, BTW... Without this register, LBA48 is
I just connected the HDD in question to a PC and the kernel there DID NOT
detect a HPA! Funny enough the output of cat /proc/ide/hdb/identify is
different. Shouldn't it be the same!?
No they will be different because the PC hardware works properly. We'll
read both sizes realize they are the
Alan wrote:
I just connected the HDD in question to a PC and the kernel there DID NOT
detect a HPA! Funny enough the output of cat /proc/ide/hdb/identify is
different. Shouldn't it be the same!?
No they will be different because the PC hardware works properly. We'll
read both sizes realize
Hi,
for (i = IDE_DATA_OFFSET; i = IDE_STATUS_OFFSET; i++) {
hw.io_ports[i] = ide_virt_base + (i 1);
}
hw.io_ports[IDE_CONTROL_OFFSET] = ide_virt_base + 0x10;
Thus it has an offset 0x10 from the base address.
ide0 at
Jose Alberto Reguero wrote:
This work for kernel 2.6.20-rc6
First apply this patch:
http://marc.theaimsgroup.com/?l=linux-idem=116986924301674w=2
Then apply the patch attached.
Comments:
The Marvell 88SE6121 has three ports (0,1,2). The PATA port is port 2. (PATA
port for 6141 is port 4).
Tejun Heo wrote:
devres change moved iomap.o from obj-$(CONFIG_GENERIC_IOMAP) to lib-y
making it not linked if no in-kernel driver uses it. Fix it.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
applied
BTW can you update your scripts to email [EMAIL PROTECTED] ? That's the
primary email
Eric D. Mudama wrote:
Per Jeff's suggestion, this patch rearranges the info printed for ATA
drives into dmesg to add the full ATA firmware revision and model
information, while keeping the output to 2 lines.
Signed-off-by: Eric D. Mudama [EMAIL PROTECTED]
---
This extra information is helpful
Tejun Heo wrote:
Alan wrote:
Some SATA controllers use 0xff to indicate empty port. This seldomly
matters as we have the almighty SStatus register to check device
presence (there is a bug regarding this, patch pending).
This GoVault drive fails because ata_piix doesn't have SCR while using
Jeff Garzik wrote:
Tejun Heo wrote:
Alan wrote:
Some SATA controllers use 0xff to indicate empty port. This seldomly
matters as we have the almighty SStatus register to check device
presence (there is a bug regarding this, patch pending).
This GoVault drive fails because ata_piix doesn't
El Miércoles, 31 de Enero de 2007 16:03, Jeff Garzik escribió:
Jose Alberto Reguero wrote:
This work for kernel 2.6.20-rc6
First apply this patch:
http://marc.theaimsgroup.com/?l=linux-idem=116986924301674w=2
Then apply the patch attached.
Comments:
The Marvell 88SE6121 has
I don't have the hardware combination to test this one so would
appreciate people testing it before it goes anywhere further
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.20-rc6-mm3/drivers/ata/pata_pdc2027x.c
linux-2.6.20-rc6-mm3/drivers/ata/pata_pdc2027x.c
Jeff Garzik wrote:
Tejun Heo wrote:
devres change moved iomap.o from obj-$(CONFIG_GENERIC_IOMAP) to lib-y
making it not linked if no in-kernel driver uses it. Fix it.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
applied
BTW can you update your scripts to email [EMAIL PROTECTED] ? That's
A ZIP or similar with unformatted media will cause crashes when attempts
are made to read/write it in some cases. This is because bs_factor is
zero and we divide by it causing an oops.
As the size of a non-accessible/non-existant media is really a bit of a
zen question it doesn't matter if
Tejun Heo wrote:
Also, you can avoid that by configuring aliases to the thunderbird
account. It's in account setting - Manage Identities. Thungerbird is
pretty neat. :-)
Already done that, it doesn't seem to work :/
If you ever see [EMAIL PROTECTED] in a From line, that's
Thunderbird
On Tuesday 30 January 2007 15:53, Simon Farnsworth wrote:
Hello,
I've got a VIA VT8251 AHCI controller, driving two Maxtor SATA disks.
Under Linux 2.6.18.5, it works; using 2.6.19.1, it fails to work (bug
report at http://bugzilla.kernel.org/show_bug.cgi?id=7589 - note that
pci=nomsi does
[ please CC me, since I'm not subscribed[1] ]
Hi all,
since I think this might be an interesting data point
(that chipset is quite rare) and felt brave that day,
I tried the new experimental libata based pata work from you.
I was quite impressed. The machine is SMP and PREEMPT.
I tried
On Wed, Jan 31, 2007 at 07:44:43PM +0900, Tejun Heo wrote:
Gary Hade wrote:
Some of my random thoughts:
There does appear to be this invalid assumption that 0xFF status
always implies device-not-present. The status register access
restrictions in ATA/ATAPI-7 V1 5.14.2 include the
Mark Lord wrote:
In an ideal world, we would use the existing ATA_12 opcode
to issue 12-byte ATA passthrough commands for libata ATAPI drives
from userspace.
But ATA_12 happens to have the same SCSI opcode value as the older
CD/RW BLANK command, widely used by cdrecord and friends.
So,
On Wed, 2007-01-31 at 19:42 -0500, Mark Lord wrote:
Sure thing, if you and Jeff are happy with that, then lets do it.
I just kind of assumed that the complexity in
ata_set_port_max_cmd_len()
was there for some kind of reason.
For example, I think all existing ATAPI drives only speak
Mark Lord wrote:
Tejun Heo wrote:
Mark Lord wrote:
..
So, to achieve ATA passthru capability for libata ATAPI,
we have to instead use the ATA_16 opcode: a 16-byte command.
SCSI normally disallows issuing 16-byte commands to 12-byte devices,
so special support has to be added for this.
I
James Bottomley wrote:
..
In SCSI, we're very careful only to use large commands where necessary,
so even for a 2TB array, you only see 16 byte commands for sectors
beyond 2TB. This essentially means that the capacity (and we do a
careful READ_CAPACITY(10) and only move on to READ_CAPACITY(16)
Simon Farnsworth wrote:
On Tuesday 30 January 2007 15:53, Simon Farnsworth wrote:
Hello,
I've got a VIA VT8251 AHCI controller, driving two Maxtor SATA disks.
Under Linux 2.6.18.5, it works; using 2.6.19.1, it fails to work (bug
report at http://bugzilla.kernel.org/show_bug.cgi?id=7589 -
Luca Tettamanti wrote:
Hi Jeff, linux-ide,
I'm having troubles with libata and UDF on RW media. See below.
Il Tue, Jan 30, 2007 at 09:42:34PM +0100, Jan Engelhardt ha scritto:
On Jan 30 2007 21:36, Luca Tettamanti wrote:
Il Tue, Jan 30, 2007 at 09:02:20PM +0100, Jan Engelhardt ha scritto:
Tejun Heo wrote:
Implement device resource management, in short, devres. A device
ACK patches 1-7. Applied patches 1-6 (with some remaining pata_platform
damage) to #upstream.
Please examine the resulting damage, and resend patch #7, plus any
missing bits
Jeff
-
To
Two fixes in this test patch. One of them allows old CF cards to refuse
pio mode setting, and one to wait for the drive to settle after a set
features changes the speed settings, which is based upon the workarounds
used by drivers/ide.
Please test and report back if you have an afflicted system.
Alan wrote:
@@ -5142,6 +5174,20 @@
status = ata_chk_status(ap);
if (unlikely(status ATA_BUSY))
goto idle_irq;
+
+ if (unlikely(qc-tf.command == ATA_CMD_SET_FEATURES
+ qc-tf.feature == SETFEATURES_XFER)) {
+ /* Let the timings
Looks like you should use ata_busy_wait() here, rather than reproducing
the same code again.
It waits in 10uS chunks while 1uS chunks were used in the workaround.
Could indeed do that once I know the fix is right. While I'm at it the
ata_busy_wait kerneldoc is borked so here's a fix
Hi all.
I don't know if this report can be useful, but this problem does not
show up in my setup.
I tried multiple times to copy 10MB files (unmounting and remounting
every time) and verified with md5sum the results and everything is
correct.
Details:
* kernel version: 2.6.20-rc6-g93544047
*
Hello.
Alan wrote:
Ugh, I'm not seeing any *actual* support for MW/SW DMA in this driver...
Thats long been broken. Should be correct in the libata driver
I've looked thru the specs and it seemed to me that ULi hardware is much
broken PIO wise: their max active time is 8 cycles
On Wed, Jan 31, 2007 at 05:58:19AM -0500, Jeff Garzik wrote:
Luca Tettamanti wrote:
Hi Jeff, linux-ide,
I'm having troubles with libata and UDF on RW media. See below.
Il Tue, Jan 30, 2007 at 09:42:34PM +0100, Jan Engelhardt ha scritto:
On Jan 30 2007 21:36, Luca Tettamanti wrote:
Il Tue,
Hi Adrian,
Il Thu, Feb 01, 2007 at 12:10:13AM +0100, Adrian Bunk ha scritto:
On Wed, Jan 31, 2007 at 05:58:19AM -0500, Jeff Garzik wrote:
Luca Tettamanti wrote:
Hi Jeff, linux-ide,
I'm having troubles with libata and UDF on RW media. See below.
Il Tue, Jan 30, 2007 at 09:42:34PM
Mark Lord wrote:
Robert Hancock wrote:
I'd love to, but unfortunately nobody seems to have come up with a way
of doing this in Thunderbird that keeps it from mangling whitespace
Yup, major nuisance. I have to fire up Kmail whenever I'm posting patches,
and then go back to Thunderbird
Tejun Heo wrote:
A much better solution with thunderbird is using external editor
extension.
http://globs.org/articles.php?lng=enpg=2
Brilliant! Installed, and now tested (the max_cmd_len patch posting).
-ml
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body
Mark Lord wrote:
Eric D. Mudama wrote:
Actually, it's possibly worse, since each failure in libata will
generate 3-4 retries. With existing ATA error recovery in the drives,
that's about 3 seconds per retry on average, or 12 seconds per
failure. Multiply that by the number of blocks past
Jeff Garzik wrote:
Mark Lord wrote:
Eric D. Mudama wrote:
Actually, it's possibly worse, since each failure in libata will
generate 3-4 retries. With existing ATA error recovery in the
drives, that's about 3 seconds per retry on average, or 12 seconds
per failure. Multiply that by the
Ric Wheeler wrote:
Mark Lord wrote:
Eric D. Mudama wrote:
Actually, it's possibly worse, since each failure in libata will
generate 3-4 retries.
(note: libata does *not* generate retries for medium errors;
the looping is driven by the SCSI mid-layer code).
It really beats the alternative
James Bottomley wrote:
For the MD case, this is what REQ_FAILFAST is for.
I cannot find where SCSI honours that flag. James?
And for that matter, even when I patch SCSI so that it *does* honour it,
I don't actually see the flag making it into the SCSI layer from above.
And I don't see
Mark Lord wrote:
James Bottomley wrote:
For the MD case, this is what REQ_FAILFAST is for.
I cannot find where SCSI honours that flag. James?
Scratch that thought.. SCSI honours it in scsi_end_request().
But I'm not certain that the block layer handles it correctly,
at least not in the
Ric Wheeler wrote:
Jeff Garzik wrote:
Mark Lord wrote:
Eric D. Mudama wrote:
Actually, it's possibly worse, since each failure in libata will
generate 3-4 retries. With existing ATA error recovery in the
drives, that's about 3 seconds per retry on average, or 12 seconds
per failure.
Douglas Gilbert wrote:
Ric,
Both ATA (ATA8-ACS) and SCSI (SBC-3) have recently added
command support to flag a block as uncorrectable. There
is no need to send bad long data to it and suppress the
disk's automatic re-allocation logic.
That'll be useful in a couple of years, once drives that
Alan wrote:
When libata reports a MEDIUM_ERROR to us, we *know* it's non-recoverable,
as the drive itself has already done internal retries (libata uses the
with retry ATA opcodes for this).
This depends on the firmware. Some of the raid firmware drives don't
appear to do retries in firmware.
On Wed, 2007-01-31 at 12:57 -0500, Mark Lord wrote:
Alan wrote:
When libata reports a MEDIUM_ERROR to us, we *know* it's non-recoverable,
as the drive itself has already done internal retries (libata uses the
with retry ATA opcodes for this).
This depends on the firmware. Some of the
Robert Hancock wrote:
http://marc.theaimsgroup.com/?t=11692262122
It looks like Tejun's patch essentially does the same thing as mine with
the addition of the control from userspace. There is one exception
though, my patch also does the stop on removal of the SCSI disk (i.e.
writing 1
Stefan Richter wrote:
Robert Hancock wrote:
http://marc.theaimsgroup.com/?t=11692262122
It looks like Tejun's patch essentially does the same thing as mine with
the addition of the control from userspace. There is one exception
though, my patch also does the stop on removal of the SCSI
devres updates for pata_platform were dropped while merging devres
patches due to merge conflict. This is the updated version.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/pata_platform.c | 31 +++
1 file changed, 7 insertions(+), 24 deletions(-)
50 matches
Mail list logo
