-off-by: Tejun Heo [EMAIL PROTECTED]
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 65d6f23..3300ff1 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1761,6 +1761,8 @@ static void __devinit quirk_disable_msi(struct pci_dev
*dev)
}
}
DECLARE_PCI_FIXUP_FINAL
Hello, Maneesh.
Maneesh Soni wrote:
I started looking at these patches and parallely also did some testing on a
8 CPU system. I am using the patches from Greg's tree at
http://www.kernel.org/pub/scm/linux/kernel/git/gregkh/patches.git/
I ran following loops parallelly
# while true; do
Maneesh Soni wrote:
I started looking at these patches and parallely also did some testing on a
8 CPU system. I am using the patches from Greg's tree at
http://www.kernel.org/pub/scm/linux/kernel/git/gregkh/patches.git/
I ran following loops parallelly
# while true; do insmod
Hello, all.
Agreed with the problem but I'm not very enthusiastic for adding
kobj-owner. How about the following? exit() routines will have to
do device_unregister_wait() instead of device_unregister(). On return
from it, it's guaranteed that all references to it are dropped and
-release is
Tejun Heo wrote:
Hello, all.
Agreed with the problem but I'm not very enthusiastic for adding
kobj-owner. How about the following? exit() routines will have to
do device_unregister_wait() instead of device_unregister(). On return
from it, it's guaranteed that all references
Mark Lord wrote:
Chuck Ebbert wrote:
Mark Lord wrote:
I'll patch it locally on my own machines, but what about the tens
of thousands of other Seagate notebook drive owners out there?
This is a problem with Seagate specifically, spinning back up
on receipt of some command after spindown?
Max Kellermann wrote:
Yet another hard drive which doesn't seem to get NCQ right.
ata1: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl
0x1501000 status 0x400 next cpb count 0xB next cpb idx 0x0
[...]
ata1: timeout waiting for ADMA IDLE, stat=0x400
ata1: timeout waiting for ADMA
Max Kellermann wrote:
On 2007/04/18 08:26, Tejun Heo [EMAIL PROTECTED] wrote:
Can you try it on another controller? Say, a ahci or sil24?
Seems to work ok on a Via VT8251 controller (AHCI) on kernel
2.6.21-rc6-git4 without my NCQ disabling patch.
Unfortunately, NCQ is not supported
Cornelia Huck wrote:
On Wed, 18 Apr 2007 03:41:10 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
Hello, all.
Agreed with the problem but I'm not very enthusiastic for adding
kobj-owner. How about the following? exit() routines will have to
do device_unregister_wait() instead
Cornelia Huck wrote:
On Wed, 18 Apr 2007 03:49:01 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
Oh, one more thing, with proper code audit, we can just make
device_unregister() do the waiting instead of adding separate
device_unregister_wait(). I think that will be a good step toward
Cornelia Huck wrote:
On Wed, 18 Apr 2007 17:46:09 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
It's debatable but I think things will be safer this way. If we wait by
default, we are forced to check that all references are dropped and will
have a stack dump indicating which object is causing
Bodo Eggert wrote:
SCSI part of the fix is queued in scsi-misc-2.6 tree and libata-dev part
is acked and waiting to be merged, so the fix will be available in
2.6.22. However, it's disabled by default to remain compatible with the
Alan Cox wrote:
Not that simple. Most disks don't spin up on SYNCHRONIZE_CACHE if its
cache is clean. Sadly some disks actually spin up when it receives spin
down command while spun down to immediately spin down again, so we would
be fixing problem for some number of disks while breaking
Tejun Heo wrote:
Alan Cox wrote:
Not that simple. Most disks don't spin up on SYNCHRONIZE_CACHE if
its cache is clean. Sadly some disks actually spin up when it
receives spin down command while spun down to immediately spin down
again, so we would be fixing problem for some number of disks
Alan Cox wrote:
Thought about that and querying power state before doing shutdown
sequence but things get somewhat ugly because shutdown sequence is
driven from sd-shutdown(). We'll have to snoop both sync and shutdown
commands and check whether the system is shutting down. Also, I felt
Mark Lord wrote:
Alan Cox wrote:
+if (dev-needs_flush ata_try_flush_cache(dev)) {
return ata_scsi_flush_xlat;
+dev-needs_flush = 0;
Works better if you swap the dev- and return lines
Heh, yeah, I noticed that!
Here it is, *tested* now, with another
Hello,
Alan Stern wrote:
On Wed, 18 Apr 2007, Tejun Heo wrote:
Hello, all.
Agreed with the problem but I'm not very enthusiastic for adding
kobj-owner. How about the following? exit() routines will have to
do device_unregister_wait() instead of device_unregister(). On return
from
Tejun Heo wrote:
Incidentally, Tejun, I'm all in favor of a immediate-detach driver model
approach. Unfortunately it's impossible to realize fully, although we
could come much closer than we are now.
Here's an example where immediate-detach cannot be implemented. A driver
binds
Cornelia Huck wrote:
On Wed, 18 Apr 2007 03:41:10 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
patch
OK, I hit a bit on the code. Once I saved a reference to the completion
in kobject_cleanup, it seemed to survive a load/unload testloop for a
module registering a device. However, I still
Hello,
Alan Stern wrote:
On Thu, 19 Apr 2007, Tejun Heo wrote:
The goal of immediate-disconnect is to remove such lingering reference
counts so that device_unregister() or driver detach puts the last
reference count.
Yes, I understand. If you had immediate-disconnect then you wouldn't
Max Kellermann wrote:
On 2007/04/18 09:56, Tejun Heo [EMAIL PROTECTED] wrote:
It's more likely your chipset just has busted MSI support. Please
post the result of 'lspci -tv' and 'lspci -nn'.
See attachments. I found the nomsi workaround in a forum, and
didn't bother to investigate
Hello, Alan.
Alan Stern wrote:
This doesn't solve a related problem: a subsystem wants to register
devices and to provide a set of mutually-exclusive services to the
devices' drivers. The mutual exclusion has to be provided by a mutex or
something similar, and the drivers need a way to
Hello, Dmitry.
Dmitry Torokhov wrote:
On 4/19/07, Cornelia Huck [EMAIL PROTECTED] wrote:
On Thu, 19 Apr 2007 09:13:43 -0400,
Dmitry Torokhov [EMAIL PROTECTED] wrote:
Because they are managed by 2 different entities. the struct device
objects are managed by device core and driver-specific
Hello, Dmitry.
Dmitry Torokhov wrote:
Many drivers (at least all the SCSI/IDE ones) consider struct device as
the base class of the devices those drivers implement. I don't think we
can just consider those drivers to be wrong.
I am not saying they are wrong I am just saying that driver
Hello, Dmitry.
Dmitry Torokhov wrote:
Isn't think a good thing? By decoupling the 2 layers we insulate them
from changes in each other. This allows bug subsystems to concentrate
on topics that important to them instead of worying about refcounting
objects that are not directly interesting for
Hello,
Kristen Carlson Accardi wrote:
static unsigned int ata_print_id = 1;
@@ -1744,6 +1745,23 @@ int ata_dev_configure(struct ata_device
}
dev-cdb_len = (unsigned int) rc;
+ /*
+ * check to see if this ATAPI device supports
+
Kristen Carlson Accardi wrote:
+static struct disk_attribute disk_attr_capability = {
+ .attr = {.name = capability_flags, .mode = S_IRUGO },
+ .show = disk_capability_read
+};
How about just capability? I think that would be more consistent with
other attributes.
--
tejun
-
To
Kristen Carlson Accardi wrote:
Send an uevent to user space to indicate that a media change event has
occurred.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Index: 2.6-git/block/genhd.c
===
---
Vincent Vanackere wrote:
Hi,
I'm getting the following oops at boot with the latest -mm kernel :
---
kernel BUG at fs/sysfs/inode.c:272
Known problem. Working on it. Thanks.
--
tejun
-
To unsubscribe from this list: send the
Andrew Morton wrote:
On Wed, 25 Apr 2007 01:33:59 +0900 Tejun Heo [EMAIL PROTECTED] wrote:
Vincent Vanackere wrote:
Hi,
I'm getting the following oops at boot with the latest -mm kernel :
---
kernel BUG at fs/sysfs/inode.c:272
On Tue, Apr 24, 2007 at 10:58:44AM -0700, Andrew Morton wrote:
On Wed, 25 Apr 2007 02:51:43 +0900 Tejun Heo [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Wed, 25 Apr 2007 01:33:59 +0900 Tejun Heo [EMAIL PROTECTED] wrote:
Vincent Vanackere wrote:
Hi,
I'm getting
Miles Lane wrote:
[ 59.677312] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state
recovery directory
[ 59.688633] NFSD: starting 90-second grace period
[ 60.221454]
[ 60.221456] =
[ 60.221461] [ INFO: possible recursive locking
Andrew Morton wrote:
[2.953862] RIP: 0010:[803ae98b] [803ae98b]
scsi_schedule_eh+0xa/0x57
[3.058672] [803e1e01] ata_port_schedule_eh+0x4c/0x50
[3.064725] [803e1ea7] ata_port_abort+0xa2/0xae
[3.070248] [803e1ef9]
On Wed, Apr 25, 2007 at 05:42:41PM +0900, Tejun Heo wrote:
Andrew Morton wrote:
[2.953862] RIP: 0010:[803ae98b] [803ae98b]
scsi_schedule_eh+0xa/0x57
[3.058672] [803e1e01] ata_port_schedule_eh+0x4c/0x50
[3.064725] [803e1ea7] ata_port_abort
Andrew Morton wrote:
No, that would break host probing. The port is in frozen (controller
initialized and IRQs masked off) state, so it's not allowed to take
interrupt.
Sounds dodgy. What happens if the IRQ line is shared with some other
device? We'll enter ahci_interrupt(). We've
Please test this one instead. Thanks.
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 1c00526..ce6 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -5871,6 +5871,7 @@ struct ata_port *ata_port_alloc(struct ata_host *host)
if (!ap)
Alan Cox wrote:
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 72c286e..a128717 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1369,10 +1369,14 @@ static unsigned int ahci_qc_issue(struct
ata_queued_cmd *qc)
static void ahci_freeze(struct ata_port *ap)
{
+
[cc'ing Greg, Hi]
Kok, Auke wrote:
Attached dmesg. config.gz. here's the OOPS part.
ata_piix :00:1f.2: version 2.10
ata_piix :00:1f.2: MAP [ P0 P2 P1 P3 ]
ACPI: PCI Interrupt :00:1f.2[B] - GSI 19 (level, low) - IRQ 19
ata: 0x1F0 IDE port busy
ata: conflict with ide0
BUG: at
Conke Hu wrote:
On 3/7/07, Tejun Heo [EMAIL PROTECTED] wrote:
(snip)
I've read your last posting about this, but forgot to follow up. TUR is
supposed to fail if ATAPI device doesn't have media loaded. TUR fails
and sense data returns device not ready - media not present. That's the
normal
Jeff Garzik wrote:
Which patch?
Since this affects libata directly, and since devres came in via libata,
I would rather that libata bugs not get /too/ blocked by patches in
other trees.
This one.
http://article.gmane.org/gmane.linux.kernel/495515
--
tejun
-
To unsubscribe from this
Some platform devices are driven without driver attached, so managed
resources can be acquired without driver attached. Make sure such
resources are released by calling devres_release_all() in
device_del().
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
This one fixes oops on pata_platform
Implement pcim_iounmap_regions() - the opposite of
pcim_iomap_regions().
Signed-off-by: Tejun heo [EMAIL PROTECTED]
---
This one is used by libata's new init model and generally useful for
driver midlayers. Please push it through libata-dev#upstream.
Thanks.
include/linux/pci.h |1 +
lib
Tejun Heo wrote:
Some platform devices are driven without driver attached, so managed
resources can be acquired without driver attached. Make sure such
resources are released by calling devres_release_all() in
device_del().
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
This one fixes
Paul Rolland wrote:
Hell Tejun,
I've boot-tested this yesterday, with no real luck...
1 - Tested on top of 2.6.21-rc2 (hope it's fine for you),
2 - Collected a full dmesg before and after
Extract is :
ata7: PATA max UDMA/100 cmd 0x00019c00 ctl 0x00019882 bmdma
0x00
Philipp Matthias Hahn wrote:
Hello Tejun!
On Tue, Mar 06, 2007 at 12:46:07AM +0900, Tejun Heo wrote:
Philipp Matthias Hahn wrote:
On Mon, Mar 05, 2007 at 01:10:10PM +0900, Tejun Heo wrote:
* Does applying the attached patch over unpatched 2.6.20.1 fix the problem?
Yes, it seems to fix
Hello,
Randy Dunlap wrote:
Erm, before I do that, could somebody explain what
#define HAVE_PCI_REQ_REGIONS 2
accompanying their declaration is for? I have't found any references to it
in
the source. Should I duplicate it for CONFIG_PCI=n case (I guess not)?
I wouldn't since it's
Soeren Sonnenburg wrote:
Elsewise I still see the
ATA: abnormal status 0x80 on port 0x000140df
ATA: abnormal status 0x80 on port 0x000140df
ata1.00: configured for UDMA/33
ata3.01: revalidation failed (errno=-2)
ata3: failed to recover some devices, retrying in 5 secs
ATA: abnormal status
Hello, Linus.
Linus Torvalds wrote:
On Sun, 11 Mar 2007, Paul Rolland wrote:
My machine is having two problems : the one you are describing above,
which is due to a SIL controler being connected to one port of the ICH7
(at least, it seems to), and probing it goes timeout, but nothing is
Of course I forgot to CC. :-) Quoting whole message for Justin.
Tejun Heo wrote:
Hello, Linus.
Linus Torvalds wrote:
On Sun, 11 Mar 2007, Paul Rolland wrote:
My machine is having two problems : the one you are describing above,
which is due to a SIL controler being connected to one port
Paul Rolland wrote:
I keep forgetting about this. I'll ask SIMG how to deal with
this. For
the time being, connecting a device to the PMP port should remove the
timeouts.
That sounds a quite expensive solution ;)
You should be able to just move the drive attached at ata1 to ata2.
Please
-off-by: Tejun Heo [EMAIL PROTECTED]
---
This should do it and better fits the intention of the return value.
Two things to note.
1. I think these ports should be made dummy instead of returning
-ENOENT on prereset(). -ENOENT from prereset() was a hack to keep
ata_piix's behavior unchanged while
[EMAIL PROTECTED] wrote:
Hi,
I reported this also for 2.6.20 kernel.
new libata with controller nVidia CK804 initializes the disk in DMA/33,
with with 2.6.19.5 and previous the disk is correctly inizialized in
DMA/100.
Tha cable is OK, and with older kernels the disks runs without troubles.
Mathieu Bérard wrote:
Jeff Garzik a écrit :
Adrian Bunk wrote:
Subject: NCQ problem with ahci and Hitachi drive
References : http://lkml.org/lkml/2007/3/4/178
Submitter : Mathieu Bérard [EMAIL PROTECTED]
Status : unknown
according to the last message in that thread, it sounds like
Can you apply the attached patch and report what the kernel says with
ACPI turned on?
--
tejun
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 019d8ff..6a27a7f 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -473,8 +473,8 @@ static void
Hello,
Conke Hu wrote:
When there is no media in SATA CD/DVD drive or media is not ready,
AHCI controller fails to execute the ATAPI commands TEST_UNIT_READY,
READ_CAPACITY or READ_TOC and reports PORT_IRQ_TF_ERR. But ATI SB600
SATA controller sets SERR_INTERNAL bit in the error register
Hello, all.
This patch started off from the following thread.
http://thread.gmane.org/gmane.linux.ide/16899
The problem is that a PCI device can be in any arbitrary when it gets
enabled and the device has to be enabled for its driver to
initialize/reset it. The most common case this causes
Stephen Hemminger wrote:
The problem is the BIOS is busted on these machines. How much effort
do we want to put into dealing with systems with broken BIOS?
I would rather have the root cause fixed than creating a bandaid that
has to be maintained for all the other architectures and platforms.
Andi Kleen wrote:
Tejun Heo [EMAIL PROTECTED] writes:
Let's assume there's a device which shares its INTX IRQ line with
another device and the other one is already initialized. During boot,
due to BIOS's fault, bad hardware design or sheer bad luck, the device
has got a pending IRQ
Hello,
Mathieu Bérard wrote:
[ 15.031823] ata1.00: taskfile_load_raw: (0x1f1-1f7): hex: 10 03 00 00
00 a0 ef
Okay, this is interesting. This is Enable Device-Initiated Interface
Power State Transitions. So, after this command is executed the device
will try to transit to partial/slumber
[cc'ing Andi, Hi!]
Hello,
Russell King wrote:
On Wed, Mar 14, 2007 at 06:34:11PM -0400, Jeff Garzik wrote:
Russell King wrote:
pci_enable_device() doesn't deal with this; in most PCI setups I've
seen, there is no control at PCI level over whether a device generates
an interrupt on the bus.
Conke Hu wrote:
E Internal error: The host bus adapter experienced an internal error
that caused the operation to fail and may have put the host bus adapter
into an error state. Host software should reset the interface before
re-trying the operation. If the condition persists, the host bus
Heiko Carstens wrote:
On Sat, Feb 10, 2007 at 12:43:16PM -0500, Tejun Heo wrote:
\ Heiko, how about this? Does it fix s390?
Unfortunately not. Now I get
CC lib/iomap.o
lib/iomap.c: In function 'devm_ioport_map_release':
lib/iomap.c:270: warning: implicit declaration of function
Christoph Hellwig wrote:
I haven't looked at what causes it, but any leakage of pci details
into io.h is bogus. I'd suggest that the original submitter fixes
up that problem instead.
pci_iomap() depends on two things - PCI and iomap. AFAIK, there is no
config to test whether the current
Al Viro wrote:
My current version:
From 97f115834b5ebef4f04e0f18aaa10f78f43733a0 Mon Sep 17 00:00:00 2001
From: Al Viro [EMAIL PROTECTED]
Date: Sat, 10 Feb 2007 23:41:09 -0500
Subject: [PATCH] sort the devres mess out
Split the implementation-agnostic stuff in separate files.
Make sure that
Hello, Emmeran.
There is no logged error on drive's side. Only timeouts on host's side
with BMDMA engine running. I dunno specifics of the severwork
controller but many controllers with BMDMA interface timeouts the
command if transmission failure occurs, so my primary suspect is still
Markus Trippelsdorf wrote:
This update breaks sata_via on my VIA K8T800Pro machine:
sata_via :00:0f.0 : failed to iomap PCI BAR 0
sata_via :00:0f.0 : out of memory
sata_via probe of :00:0f.0 failed with error -12
Please post full dmesg and the result of 'lspci -nnvvvxxx'.
--
Hello, Paul.
Paul Rolland wrote:
This looks like the problems that hopefully the patches
from Tejun and
from Mark Lord cured (the delay after reset and the task file clear)
Any chance I can find this patch(es) and try them ?
Also, I've seen a :
ata1: Spurious SDB FIS during NCQ issue=0x0
Please test the attached patch over 2.6.20.
Thanks.
--
tejun
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 667acd2..d6fcf0a 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1478,7 +1478,16 @@ int ata_dev_read_id(struct ata_device *dev,
ris wrote:
procs ---memory-- ---swap-- -io -system-- cpu
r b swpd free buff cache si sobibo in cs us sy id wa
0 0 0 303444 53224 36013200 276 157 627 814 5 2 89 4
0 0 0 302956 53228 36033200 196
Hello,
Robert Hancock wrote:
[--correct summary snipped--]
Given the above, what I'm proposing to do is:
-Remove the blacklisting of Maxtor BANC1G10 firmware for FUA. If we need
to FUA-blacklist any drives this should likely be added to the existing
horkage mechanism we now have. However, at
[cc'ing Pavel, Hi!]
Robert Hancock wrote:
I'm seeing BUGs like these on all libata-driven controllers when
suspending to disk on 2.6.20-git6:
sata_nv :00:07.0: resuming
BUG: at drivers/pci/pci.c:817 pcim_enable_device()
Call Trace:
[80337d21] pcim_enable_device+0x8a/0xa5
Jean Delvare wrote:
I've read the whole thread, the source code (quickly) and the patches to
ahci.c and sata_via.c, and here are some comments:
It looks like support for the VT8251 was added to the ahci driver in kernel
2.6.18, and was then updated in 2.6.20. The code is different from the
ris wrote:
Tejun Heo htejun at gmail.com writes:
iowait != cpu busy. Your cpu idleness stays above 80%.
Ok .. but one of my CPU core are at 99% usage
htop report this
So how to solve this problem ?
The red part of cpu usage bar represents 'iowait' not cpu usage. Fire
up
Matthew Fredrickson wrote:
I have noticed something that might be related as well. I am working on
a device driver that would have periodic data errors due to
exceptionally long interrupt handling latency. I have come to the point
that I suspect that it's the sata_nv driver, and now that we
Conversion to resource-managed iomap was buggy causing init failures
on both vt6420 and 6421 - BAR5 wasn't mapped for both controllers
while on vt6420 sata_via tried to map BAR0-4 twice. Fix it.
DO NOT APPLY YET.
---
Markus, does this fix your problem?
diff --git a/drivers/ata/sata_via.c
Markus Trippelsdorf wrote:
On Mon, Feb 12, 2007 at 10:51:44AM -0800, Tejun Heo wrote:
Conversion to resource-managed iomap was buggy causing init failures
on both vt6420 and 6421 - BAR5 wasn't mapped for both controllers
while on vt6420 sata_via tried to map BAR0-4 twice. Fix it.
Great, can
Hello, Joel.
Joel Soete wrote:
A small update:
your patch also works against 2.6.20
Glad to hear that.
but seems that open the door to numerous other pb:
1/ pb to burn cd:
# md5sum cd060213.iso
6a1248783a21722816b972aa9bae9d5e cd060213.iso
# ll cd060213.iso
-rwxr-xr-x 1 root root 3213312
Patrick Ale wrote:
ATA: abnormal status 0x8 on port 0xF88597DF
Maybe this is purely a cosmetic error where the error code can be
translated to something like no drive attached or maybe the drivers
assume you always configure a master drive on a controller, which
doesnt always have to be the
Hello, Paul.
Paul Rolland wrote:
Also, please note that libata is complaining :
ATA: abnormal status 0x7F on port 0x177
and later :
ATA: abnormal status 0x7F on port 0x9807
You can ignore the above. The errors on ata2 are due to SIMG storage
processor and will probably fixed when PMP
Hello, Robert.
Robert Hancock wrote:
[--snip--]
On the NCQ side, I think it's pretty safe to assume that all controllers
will handle it. Obviously I've verified it with sata_nv (at least that
it doesn't blow up obviously), and the other two NCQ drivers we have,
ahci and sata_sil24 just feed
Hello, Pavel.
Pavel Machek wrote:
1. Don't restore power state and re-enable PCI device on resume from
freeze just as we don't do the opposite when freezing.
2. Unconditionally disable and power down PCI device on suspend whether
it's freeze or not.
#2 would be simpler but I'm a bit
[cc'ing Jeff, Alan, Mark and Jens. Hi!]
Hello, Robert.
Robert Hancock wrote:
Well, we should be able to determine that experimentally (at least on
specific controllers) with a little test program that just writes little
bits of data and fsyncs repeatedly (assuming that does in fact trigger
Patrick Ale wrote:
So, my AMD Athlon XP2400+ with pata_pdc2027x, pata_sil680 and pata_via
Now, since functionality by design is boring and my employer doesn't
torture me enough,, I' pulled the libsata-dev git and linux-2.6 git
and will see how that goes.
It's libata. I mean, you yourself are
Hello, Martin.
Martin A. Fink wrote:
TestOpenSuSE(AHCI)
FreeBSD(AHCI)
---
SSD(vfat 25GB)
Paul Rolland wrote:
Hello,
I'm preparing to attach a disk.
In the meantime, I've rebuild a 2.6.21-rc4, and got that while booting :
...
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133
ata1.00: 490234752 sectors, multi 0: LBA48
Paul Rolland wrote:
If you leave it alone, does libata turn off NCQ and boot continues?
boot continues, but I can't tell anything about libata turning of NCQ...
I've had a bunch of them at some while while compiling some kernel, so it
was quite some time after booting.
Is there a message
Paul Rolland wrote:
Hello,
The kernel says that NCQ is turned off due to excessive
errors. If your
HSM violation is intermittent, it might not trigger tho.
I've just grep'ed thru all my messages, and I can't find anything
stating that NCQ is being turned off...
Can you put the
Christian wrote:
This does indeed look like a drive side issue to me (the controller is
reporting CPBs with response flags 2 which as far as I can tell
indicates it's still waiting for the drive to complete the request).
I have been using this hw-config (SATA II, NCQ) since the nvidia ADMA
Jon Masters wrote:
Chuck Ebbert wrote:
If you try to load both the pata_atiixp and the ahci driver
(for the same ATI SB600 adapter), very strange things happen.
The AHCI driver churns for three minutes or so, spewing
messages like this, then nothing works:
6ata3: SATA link up 3.0 Gbps
Alan Cox wrote:
On Sat, 17 Mar 2007 22:00:50 +0900
Komuro [EMAIL PROTECTED] wrote:
Hi,
The pata_pcmcia driver reports the cmd port is 0x00010100,
but actually the cmd port is 0x0100.
Is this corect?
When the pci_iomap patches were applied the ports reported for every
device went
Hello, Jon.
Jon Masters wrote:
Dunno much about sb600 but ahci and pata_atiixp are probably using
separate IO regions separate PCI functions.
Yeah. I actually thought about this whole issue a bit more recently -
things like SATA/PATA interference when you've got a part that emulates
Paul Rolland wrote:
Hello,
Can you put the harddisk under high load and see what happens? How
often do those errors occur? Care to post full dmesg?
I started again a stock 2.6.21-rc4, and ran that :
while (/bin/true); do tar jxf linux-2.6.19.1.tar.bz2; rm -rf linux-2.6.19.1;
echo -n .;
Paul Rolland wrote:
Hello,
Yeap, more than three HSM violations in ten minutes. That's the
criteria for turning off NCQ. Good to see it working. It look like a
lot because libata reports all active commands (can't help as on HSM
failure, there's no way to determine which caused it) and
Christian wrote:
On Sunday 18 March 2007 06:43:09 you wrote:
Christian wrote:
This does indeed look like a drive side issue to me (the controller is
reporting CPBs with response flags 2 which as far as I can tell
indicates it's still waiting for the drive to complete the request).
I have
Paul Rolland wrote:
Doh ! Got that :
ACPI: PCI Interrupt :00:1f.2[B] - GSI 23 (level, low) - IRQ 23
ahci :00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode
ahci :00:1f.2: flags: 64bit ncq led clo pio slum part
ata1: SATA max UDMA/133 cmd
Tony Vroon wrote:
This duplicates the IDE core LED trigger in the libata core.
I plan to use this by allowing PMU LED control on G5 towers. My test platform
is a PowerMac 7,3 (Dual G5 2.0GHz, June 2004) with a K2 (sata_svw) controller.
I think this fits better in
Christian wrote:
Yes, for me the problem was introduced recently. I have moved around
terabytes
(sic!) on my discs with older kernels and I never got errors.
There is always the possibility of disk going bad, so it would be great
if you can boot an older kernel and verify that the problem
Paul Rolland wrote:
Oh... that's just weird. It seems you'll have to continue
boot with the
timeouts for the time being. Sorry about that.
Would you agree to a patch to add a kernel boot parameter to skip some
ata ports ?
I found some archives refering to some ataX=noprobe, but it seems
to
Alistair John Strachan wrote:
On Monday 12 March 2007 13:25, Frank van Maarseveen wrote:
[snip]
So, are /dev/hd* going to disappear in a few years? iow, does it make
sense to _slowly_ start to migrate to /dev/sd*?
How would you propose doing this? I'm sure modern distros with an
Alan Cox wrote:
On Mon, 19 Mar 2007 13:42:37 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Tony Vroon wrote:
This duplicates the IDE core LED trigger in the libata core.
I plan to use this by allowing PMU LED control on G5 towers. My test platform
is a PowerMac 7,3 (Dual G5 2.0GHz, June 2004
1 - 100 of 22291 matches
Mail list logo
