This patch makes JMicron PCI quirk clear SATA IDE mode bits and set
AHCI mode bits and remove the respective part from pata_jmicron.
Tested on JMB361, 363 and 368.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Acked-by: Alan Cox [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
Note that both normal commands and EH commands timeouts are adjusted
to 7 secs, but cache flushses still have 30sec timeout. This is a
side effect of the way sd makes use of sdev-timeout, but this is a
good side effect in that ATA spec requires cache flushes are given
longer timeout.
Our
Alan wrote:
Note that both normal commands and EH commands timeouts are adjusted
to 7 secs, but cache flushses still have 30sec timeout. This is a
side effect of the way sd makes use of sdev-timeout, but this is a
good side effect in that ATA spec requires cache flushes are given
longer
Original-Nachricht
Datum: Sun, 28 Jan 2007 15:21:31 -0800
Von: Andrew Morton [EMAIL PROTECTED]
An: Uwe Bugla [EMAIL PROTECTED]
CC: linux-ide@vger.kernel.org, [EMAIL PROTECTED], Jens Axboe [EMAIL
PROTECTED], Adrian Bunk [EMAIL PROTECTED], Bartlomiej Zolnierkiewicz
[EMAIL
Original-Nachricht
Datum: Sun, 28 Jan 2007 23:04:49 -0800 (PST)
Von: Linus Torvalds [EMAIL PROTECTED]
An: Mike Galbraith [EMAIL PROTECTED]
CC: Uwe Bugla [EMAIL PROTECTED], Adrian Bunk [EMAIL PROTECTED], Andrew
Morton [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
Tejun Heo wrote:
Both ATA and ATAPI devices used the default timeouts defined by SCSI
high level driver. For both disks and ODDs, it was 30secs, which was
way too long for disks. This patch makes most ATA commands time out
after 7secs - the de facto ATA command timeout, while leaving ATAPI
Ric Wheeler wrote:
Tejun Heo wrote:
Both ATA and ATAPI devices used the default timeouts defined by SCSI
high level driver. For both disks and ODDs, it was 30secs, which was
way too long for disks. This patch makes most ATA commands time out
after 7secs - the de facto ATA command
Hmm... I'm hearing different stories here. Some say 7sec is good enough
and the supporting argument that the other os is using 7 sec timeout is
pretty convincing.
Firstly what is your goal ?
After command timeout, EH will kick in, reset and revalidate then return
the control to SCSI HLD,
Hello.
Tejun Heo wrote:
Okay, here's another try at fixing the detection bug. I went through
intel ich docs and compared with the ide piix driver. This patch
fixes the following problems.
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index c6bf1a3..51f55a0 100644
---
Tejun Heo wrote:
Both ATA and ATAPI devices used the default timeouts defined by SCSI
high level driver. For both disks and ODDs, it was 30secs, which was
way too long for disks. This patch makes most ATA commands time out
after 7secs - the de facto ATA command timeout, while leaving ATAPI
Alan wrote:
..
Give it 7 seconds for a command to complete. At that point you need to
have a chat with the drive since its probably gone AWOL. If you get an
error within 7 seconds then its different.
7 seconds is not enough for current drives to report back.
Adding another (8 seconds total) is
It's amazing how poorly we have programmed PIIX, for the lifespan of
Linux...
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2/2/07, Mark Lord [EMAIL PROTECTED] wrote:
7 seconds is not enough for current drives to report back.
Adding another (8 seconds total) is enough, but I prefer to
see a little margin there, so call it 10 seconds.
If you're going to allow 30 seconds (or more) for a cache flush, you
probably
Alan wrote:
I don't have the hardware combination to test this one so would
appreciate people testing it before it goes anywhere further
I wonder if sata_promise PATA support needs this too?
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to
Tejun Heo wrote:
For all JMicrons except for 361 and 368, AHCI mode enable bits in the
Control(1) should be set. This used to be done in both ahci and
pata_jmicron but while moving programming to PCI quirk, it was removed
from ahci part while still left in pata_jmicron.
The implemented JMicron
On Fri, 02 Feb 2007 11:49:17 -0500, Jeff Garzik wrote:
Alan wrote:
I don't have the hardware combination to test this one so would
appreciate people testing it before it goes anywhere further
I wonder if sata_promise PATA support needs this too?
Hmm, I saw Alan's post but ignored it because I
Hello.
Alan wrote:
Actually, I think ata_timing_merge() should just be performed when
setting MWDMA mode... This should be the right thing to do in most cases
(however, this hardware has some complications in the form of only 2-bit
wide active/recovery counts and 2 fast timing bank select
Zitat von Alan [EMAIL PROTECTED]:
On Thu, 01 Feb 2007 19:22:31 +0100
[EMAIL PROTECTED] wrote:
Hello,
I'm experiencing problems with an SATA-DVD-Writer (Samsung SH-S183a)
connected
to a VIA8237 motherboard chipset. As you can see in the attached
boot.log, the
system is reducing the
[EMAIL PROTECTED] wrote:
BTW: In function ata_dev_set_mode in libata_core.c the variable err_mask is not
initialized (line 2386). I changed that and initialized err_mask with 0, but
that did'nt solve my problem. I did'nt expect to :-)
It's initialized prior to its first use, by a call to
On Sat, Feb 03, 2007 at 12:18:56AM +0900, Tejun Heo wrote:
Hello, Art Haas, Alan.
Okay, here's another try at fixing the detection bug. I went through
intel ich docs and compared with the ide piix driver. This patch
fixes the following problems.
* Control bits in the timing register
(cc'ing Albert, Mark and Sergei. Hi!)
Art Haas wrote:
Hi. Sorry to say the CD-ROM is still not found. Full 'dmesg' output
listed below in hopes it provides clues.
Erggghh.. I'm sorry too. I thought I found it this time.
ata_piix :00:07.1: version 2.00ac7
ata2: PATA max UDMA/33 cmd
[cc'ing Jens, hello]
Mark Lord wrote:
Tejun Heo wrote:
Both ATA and ATAPI devices used the default timeouts defined by SCSI
high level driver. For both disks and ODDs, it was 30secs, which was
way too long for disks. This patch makes most ATA commands time out
after 7secs - the de facto
Alan wrote:
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
Tejun Heo wrote:
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]
applied 1-2
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a
Brian and Tejun's patches fix really ugly bugs, Alan's are of less
importance
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/libata-core.c |1 +
Linus Torvalds wrote:
On Fri, 2 Feb 2007, Jeff Garzik wrote:
pata_atiixp: propogate cable detection hack from drivers/ide to the new
driver
It's prop*a*gate.
Damn.
Linus some speling mistaeks drive me wild Torvalds
Those UK types don't know how to spell tons of
Sergei Shtylyov wrote:
Hello again. :-)
Bartlomiej Zolnierkiewicz wrote:
[PATCH] ide: make ide_hwif_t.ide_dma_host_on void
* since ide_hwif_t.ide_dma_host_on is called either when drive-using_dma ==
1
or when return value is discarded make it void, also drop ide_ prefix
* make
On Fri, 2 Feb 2007 09:13:56 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Fri, 2 Feb 2007, Jeff Garzik wrote:
pata_atiixp: propogate cable detection hack from drivers/ide to the
new driver
It's prop*a*gate.
Damn.
Linus some speling mistaeks
Hi,
Sergei Shtylyov wrote:
Hello.
Bartlomiej Zolnierkiewicz wrote:
[PATCH] ide: fix UDMA/MWDMA/SWDMA masks
* use 0x00 instead of 0x80 to disable -{ultra,mwdma,swdma}_mask
* add udma_mask field to ide_pci_device_t and use it to initialize
-ultra_mask in aec62xx, pdc202xx_new and
This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm
The interesting point of this question is about the typically pattern of
IO errors. On a read, it is safe to assume that you will have issues
with some bounded numbers of adjacent sectors.
Which in theory you can get by asking the drive for the real sector size
from the ATA7 info. (We ought
your system requirements are, what the system is trying to do (i.e.,
when trying to recover a failing but not dead yet disk, IO errors should
be as quick as possible and we should choose an IO scheduler that does
not combine IO's).
If this is the right strategy for disk recovery for a
On Fri, 2007-02-02 at 14:42 +, Alan wrote:
The interesting point of this question is about the typically pattern of
IO errors. On a read, it is safe to assume that you will have issues
with some bounded numbers of adjacent sectors.
Which in theory you can get by asking the drive for
James Bottomley wrote:
On Fri, 2007-02-02 at 14:42 +, Alan wrote:
The interesting point of this question is about the typically pattern of
IO errors. On a read, it is safe to assume that you will have issues
with some bounded numbers of adjacent sectors.
Which in theory you
On Fri, Feb 02, 2007 at 11:06:19AM -0500, Mark Lord wrote:
Alan wrote:
If this is the right strategy for disk recovery for a given type of
device then this ought to be an automatic strategy. Most end users will
not have the knowledge to frob about in sysfs, and if the bad sector hits
at the
Alan wrote:
The interesting point of this question is about the typically pattern of
IO errors. On a read, it is safe to assume that you will have issues
with some bounded numbers of adjacent sectors.
Which in theory you can get by asking the drive for the real sector size
from the ATA7
Matt Mackall wrote:
..
Also worth considering is that spending minutes trying to reread
damaged sectors is likely to accelerate your death spiral. More data
may be recoverable if you give up quickly in a first pass, then go
back and manually retry damaged bits with smaller I/Os.
All good
On Fri, Feb 02, 2007 at 05:58:04PM -0500, Mark Lord wrote:
Matt Mackall wrote:
..
Also worth considering is that spending minutes trying to reread
damaged sectors is likely to accelerate your death spiral. More data
may be recoverable if you give up quickly in a first pass, then go
back and
38 matches
Mail list logo
