On Fri, 28 Sep 2007 02:48:28 -0700 Tejun Heo [EMAIL PROTECTED] wrote:
Mark Lord wrote:
Drain up to 512 words from host/bridge FIFO on stuck DRQ HSM violation,
rather than just getting stuck there forever.
Signed-Off-By: Mark Lord [EMAIL PROTECTED]
Acked-by: Tejun Heo [EMAIL
Paul Rolland wrote:
Can you change driver load order such that the driver for the modem is
loaded first?
As I said, it's not possible, because :
- the modem driver is an out-kernel one, so I have to wait the end of the
boot process so that it can be loaded,
- libata on IRQ23 is the
Tejun Heo wrote:
Jeff Garzik wrote:
[--snip--]
There, even the concept of port is fluid, and the libata EH model of
freezing and thawing a port (with the desired irq-off result) just
doesn't fit the hardware.
Well, the current model was developed while struggling with the first
generation PMP
* The firmware version of ST3160812AS is 3.ADJ no 3.AD.
* Add several entries from various sources.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/libata-core.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/libata-core.c
Jon Chelton wrote:
After applying the patches you sent, I had not received any additional
errors until today. Below is an output from dmesg.
ata1.15: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
ata1.15: irq_stat 0x00020002, PMP DMA CS errata
ata1.00: exception Emask 0x100
Alan Cox wrote:
Drain up to 512 words from host/bridge FIFO on stuck DRQ HSM violation,
rather than just getting stuck there forever.
Why 512 words ?
ata_altstatus(ap);
- ata_chk_status(ap);
+ ata_drain_fifo(ap, qc);
ap-ops-cleanup();
might be wiser
Actually, I
Bartlomiej Zolnierkiewicz wrote:
Documentation doesn't mention SWDMA and moreover all timings used
for SWDMA modes were over-clocked when compared to ATA spec.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Acked-by: Sergei Shtylyov [EMAIL PROTECTED]
MBR, Sergei
-
To
Tejun Heo wrote:
Jeff Garzik wrote:
Is this NACK on the patchset or can we update PMP access later?
Sorry, yes, it is a NAK: polling should not be requirement.
I considered making multi-protocol -qc_issue() a requirement too, but
that seemed like it might delay things too much. But consider
Hello Tejun,
I've tried with 2 sata cables. Cables which don't give problems with
the Asus motherboard.
I also now use a new decent power supply (corsair vx450) for the
intel. Before it, i used an Fortron supply. But it had no sata
connectors so i used converter adapters. But replacing the supply
Alan Cox wrote:
Aieee... Another merge delay. I wish the review process proceeded a bit
swifter. The patchset has been around literally for years now and
submitted for review six times if I have the take number right. :-(
Agreed - thats one reason I stick everything in -mm. Its taking
Jeff Garzik wrote:
Is this NACK on the patchset or can we update PMP access later?
Sorry, yes, it is a NAK: polling should not be requirement.
I considered making multi-protocol -qc_issue() a requirement too, but
that seemed like it might delay things too much. But consider this a
Alan Cox wrote:
This doesn't affect Tejun or anyone else really, but going through -mm
tends to gum up the works. Your patches wind up not applying to
libata#upstream, in which case they get dropped and I assume Andrew or
someone will resend usable versions.
Its the only way to get testing
This doesn't affect Tejun or anyone else really, but going through -mm
tends to gum up the works. Your patches wind up not applying to
libata#upstream, in which case they get dropped and I assume Andrew or
someone will resend usable versions.
Its the only way to get testing done and get
Mark Lord wrote:
Jeff Garzik wrote:
..
As such, polling is simply an outmoded concept. It does not make
sense on new hardware, and forcing design decisions down that path
only lead to a cascade of similar design decisions -- pmp_read polling
being just one example of such a result.
A
Aieee... Another merge delay. I wish the review process proceeded a bit
swifter. The patchset has been around literally for years now and
submitted for review six times if I have the take number right. :-(
Agreed - thats one reason I stick everything in -mm. Its taking several
months for a
Tejun Heo wrote:
Is this NACK on the patchset or can we update PMP access later?
Ping?
--
tejun
-
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
Hello.
Bartlomiej Zolnierkiewicz wrote:
drive-dn is initialized by ide-probe.c::probe_hwif() so no need to do it
in -init_hwif method.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Acked-by: Sergei Shtylyov [EMAIL PROTECTED]
MBR, Sergei
-
To unsubscribe from this list: send
* Jeff Garzik [EMAIL PROTECTED] [2007-09-28 06:23]:
Yoichi's original patch and explanation can be found at
http://lkml.org/lkml/2007/8/23/411
I've no idea why it hasn't been applied unless nobody is quite sure who
owns it. As a PCI fix I guess Greg does (and drop it into -mm for
testing) ?
So, there just hasn't been a real need so far. If interrupt overhead
becomes an issue, my first step would be to start programming the
interrupt coalescing hardware that comes in modern SATA controllers.
Another factor is queue sizes. You don't get 1024 entry queues on your
typical disk
There is another Hitachi disk doing spurious NCQ completion -- at least
with old firmware SBDIC7JP.
Signed-off by: Peter Schwabe [EMAIL PROTECTED]
--- linux.vanilla-2.6.23-rc8/drivers/ata/libata-core.c 2007-09-28
14:45:58.0 +0200
+++ linux-2.6.23-rc8/drivers/ata/libata-core.c
Alan Cox wrote:
sda1 are corrupted (2 to 4 blocks missing). Copying that data back to
Windows and it give the same results in Quickpar. So reading does not
have problems. The data written to hda1 is correct.
We've got a whole pile of reports like this with the 3512 and almost
always Nvidia
Jon Chelton wrote:
This error occurred when assembling a software raid 5 array using mdadm.
It also happened when copying large amounts of data from one drive to
another. I saw from an earlier post to disable or upgrade smartd. I
tried this (disabled) and moved about 50gb between disks and
Bartlomiej Zolnierkiewicz wrote:
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Acked-by: Sergei Shtylyov [EMAIL PROTECTED]
Index: b/include/linux/ata.h
===
--- a/include/linux/ata.h
+++ b/include/linux/ata.h
@@
Drain up to 512 words from host/bridge FIFO on stuck DRQ HSM violation,
rather than just getting stuck there forever.
Why 512 words ?
ata_altstatus(ap);
- ata_chk_status(ap);
+ ata_drain_fifo(ap, qc);
ap-ops-cleanup();
might be wiser
-
To unsubscribe from this list: send
On Fri, 28 Sep 2007 10:48:41 +0200
Martin Michlmayr [EMAIL PROTECTED] wrote:
* Alan Cox [EMAIL PROTECTED] [2007-08-24 17:37]:
PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device
:00:09.1
In some architectures, PCI bus regions have the offset from PCI
sda1 are corrupted (2 to 4 blocks missing). Copying that data back to
Windows and it give the same results in Quickpar. So reading does not
have problems. The data written to hda1 is correct.
We've got a whole pile of reports like this with the 3512 and almost
always Nvidia chipset, plus
* Alan Cox [EMAIL PROTECTED] [2007-08-24 17:37]:
PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device
:00:09.1
In some architectures, PCI bus regions have the offset from PCI resources.
For this reason, pci_setup_device() should set PCI bus regions to
[restoring LKML and cc'ing linux-ide and linux-acpi]
Hernan Gustavo Solari wrote:
I am replying directly to you since, finding that most of the
material in the kernel list is well beyond my understanding, I cancelled
my subscription.
You can forward as much of my replies to the list
Mark Lord wrote:
Drain up to 512 words from host/bridge FIFO on stuck DRQ HSM violation,
rather than just getting stuck there forever.
Signed-Off-By: Mark Lord [EMAIL PROTECTED]
Acked-by: Tejun Heo [EMAIL PROTECTED]
--
tejun
-
To unsubscribe from this list: send the line unsubscribe
Nacked-by: scripts/checkpatch.pl
Mark, it seems you'll have to get ACK from this dude first. :-)
--
tejun
-
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
* Alan Cox [EMAIL PROTECTED] [2007-09-28 11:14]:
I need this patch for IDE and PATA to work on my MIPS Cobalt.
Yoichi's original patch and explanation can be found at
http://lkml.org/lkml/2007/8/23/411
I've no idea why it hasn't been applied unless nobody is quite sure who
owns it. As a
Martin Michlmayr wrote:
* Alan Cox [EMAIL PROTECTED] [2007-09-28 11:14]:
I need this patch for IDE and PATA to work on my MIPS Cobalt.
Yoichi's original patch and explanation can be found at
http://lkml.org/lkml/2007/8/23/411
I've no idea why it hasn't been applied unless nobody is quite sure
Hello,
MisterE wrote:
I've tried the controller in another motherboard, the ASUS CUSL2 (with
similar specs)
and i don't have any problems. Can you help? I've included some logs
with may be of use.
Did you use the same cable on both machines? Also, does the problem go
away if you power the
My new Dell XPS m1330 comes with this Hitachi drive. You'd think they'd have
sorted things out by now but it produces tons of spurious completion errors
when NCQ is on.
Signed-off-by: Philip Langdale [EMAIL PROTECTED]
--- linux-2.6.22/drivers/ata/libata-core.c 2007-08-24 16:13:37.0
Hi Jeff,
Greetings.
I am writing in regarding of an issue I encountered
for AHCI SATA support (drivers/scsi/ahci.c or
drivers/ata/ahci.c) with kexec. I am using kexec to do
chainboot, and kexec works fine with ata_piix driver.
But it hangs with AHCI driver. I tried linux kernel
version 2.6.14,
-Original Message-
From: Tejun Heo [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 26, 2007 6:08 PM
To: Gaston, Jason D
Cc: linux-ide@vger.kernel.org
Subject: Re: ICH9 2 port SATA controller port map?
Gaston, Jason D wrote:
Hello,
ICH9 has DeviceID's for 2 port, IDE mode, SATA
May Cheung wrote:
Hi Jeff,
We're currently using 2.6.10 and tries to bring up an HP box which has ICH9.
The earliest libata patch available for ICH9 support seems to be 2.6.19.
The libata directory and file structures between 2.6.10 and 2.6.19 are quite
different.
Is there anyway we can
Tejun Heo wrote:
Alan Cox wrote:
Restore the support for handling drives that report one sector too many
(ie SCSI not ATA style). This worked before the HPA update but was
removed in that process
Signed-off-by: Alan Cox [EMAIL PROTECTED]
Acked-by: Tejun Heo [EMAIL PROTECTED]
diff -u
Alan Cox wrote:
Drain up to 512 words from host/bridge FIFO on stuck DRQ HSM violation,
rather than just getting stuck there forever.
Why 512 words ?
Though I have queued Mark's patch to be applied, my gut feeling would
lean towards a single DRQ block, rather than 512.
Martin Michlmayr wrote:
* Jeff Garzik [EMAIL PROTECTED] [2007-09-28 06:23]:
Yoichi's original patch and explanation can be found at
http://lkml.org/lkml/2007/8/23/411
I've no idea why it hasn't been applied unless nobody is quite sure who
owns it. As a PCI fix I guess Greg does (and drop it
Alan Cox wrote:
Jeff, seeing as Tejun's commitment is never in doubt here,
I really believe we should go with the existing PMP patchset
for 2.6.24 (unless the respin happens quickly enough).
This functionality is way overdue, and we shouldn't be impeding it
as long as we have been.
I would
Mark Lord wrote:
Jeff Garzik wrote:
Alan Cox wrote:
This doesn't affect Tejun or anyone else really, but going through
-mm tends to gum up the works. Your patches wind up not applying to
libata#upstream, in which case they get dropped and I assume Andrew
or someone will resend usable
(my last response only addressed -mm)
Mark Lord wrote:
I believe the point was that getting things into libata is glacial
IMHO would say that there are two causes of that:
1) I am sometimes slow in merging, part of which is my own fault, and I
can only promise to try and do better there.
All errors are interface CRC errors reported by device on FPDMA_WRITE.
It doesn't seem to have anything to do with SMART. In all cases, SError
DIAG is reporting handshake error too (R_ERR received). I'm fairly sure
these were actual hardware problems. You don't have to pay too much
On Fri, 28 Sep 2007 23:29:44 -0400 Jeff Garzik [EMAIL PROTECTED] wrote:
(my last response only addressed -mm)
Mark Lord wrote:
I believe the point was that getting things into libata is glacial
IMHO would say that there are two causes of that:
1) I am sometimes slow in merging, part of
Andrew Morton wrote:
On Fri, 28 Sep 2007 23:29:44 -0400 Jeff Garzik [EMAIL PROTECTED] wrote:
(my last response only addressed -mm)
Mark Lord wrote:
I believe the point was that getting things into libata is glacial
IMHO would say that there are two causes of that:
1) I am sometimes slow in
Gaston, Jason D wrote:
-Original Message-
From: Tejun Heo [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 26, 2007 6:08 PM
To: Gaston, Jason D
Cc: linux-ide@vger.kernel.org
Subject: Re: ICH9 2 port SATA controller port map?
Gaston, Jason D wrote:
Hello,
ICH9 has DeviceID's
Jeff Garzik wrote:
Polling ALREADY makes the job of fixing SAS/SATA exception handling
difficult. Expanding polling to something SAS/SATA controllers treat as
fundamentally irq-driven and integrated with the rest of the command
flow is moving in the wrong direction.
To re-re-re-summarize,
48 matches
Mail list logo
