Peer Chen wrote:
Add the Software NCQ support to sata_nv.c for MCP51/MCP55/MCP61 SATA
controller.
This patch base on sata_nv.c file from kernel 2.6.22-rc1
See attachment for the patch.
Signed-off-by: Kuan Luo <[EMAIL PROTECTED]>
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
Good to finally s
Main thing of note: still sorting out the shutdown mess. See the
extended commit texts for more info.
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:
Documentation/feature-removal-
Benjamin Herrenschmidt wrote:
This patch adds MMIO support to the pata_sil680 for taskfile IOs,
based on what the old siimage does.
I haven't bothered changing the chip setup stuff from PCI config
cycles to MMIO though (siimage does it), I don't think it matters,
I've only adapted it to use MMIO
Tejun Heo wrote:
With STANDBYDOWN tracking added, libata.spindown_compat isn't
necessary anymore. If userspace shutdown(8) issues STANDBYNOW, libata
warns. If userspace shutdown(8) doesn't issue STANDBYNOW, libata does
the right thing. Userspace can tell whether kernel supports spindown
by tes
Tejun Heo wrote:
pcim_iomap_regions() conversion missed BAR5. Fix it.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
Sorry, dunno how I missed that during testing. :-( Please verify this
fixes your problem.
diff --git a/drivers/ata/sata_via.c b/drivers/ata/sata_via.c
index d105d2c..ac4f43c 1
Tejun Heo wrote:
As with all other drivers, sata_nv's hpriv is allocated with
devm_kzalloc() and there's no need to free it explicitly. Kill
nv_remove_one() which incorrectly used kfree() instead of devm_kfree()
and use ata_pci_remove_one() directly.
Original fix is from Peer Chen.
Signed-off-
[EMAIL PROTECTED] wrote:
From: "Peer Chen" <[EMAIL PROTECTED]>
Because nvidia SATA controllers onward base on AHCI, so wildcard in sata_nv
driver is unnecessary. Also the wildcard sometimes cause sata_nv driver to
be loaded for AHCI controllers,which is not as expected.
Signed-off-by: Peer Che
Hello again
I've got again into trouble with my Promise Card using kernel 2.6.17.
Since about 2 weeks i have a trashed raid5 (and unfortunately no backup) to an
unknown reason (i think
sata powercables or sata_promise problems). As i was trying to figure out how i
could rebuild my raid
array
> -Message d'origine-
> De : Alan Cox [mailto:[EMAIL PROTECTED]
> Envoyé : 17 mai 2007 13:27
>
> > [EMAIL PROTECTED] /root]# hdparm -T -t /dev/hda
> >
> > /dev/hda:
> > Timing cached reads: 4816 MB in 2.00 seconds = 2408.44 MB/sec
> > Timing buffered disk reads: 12 MB in 3.23 sec
> [EMAIL PROTECTED] /root]# hdparm -T -t /dev/hda
>
> /dev/hda:
> Timing cached reads: 4816 MB in 2.00 seconds = 2408.44 MB/sec
> Timing buffered disk reads: 12 MB in 3.23 seconds = 3.72 MB/sec
This is using PIO. How recent is your kernel - you may need a newer
kernel for the ICH8 if yo
> >
> > > -Message d'origine-
> > > De : Alan Cox [mailto:[EMAIL PROTECTED]
> > >
>
> BTW, here is the hdparm using the old driver:
Wrong key... Here is the output of hdparm:
OLD DRIVER:
---
[EMAIL PROTECTED] /root]# hdparm -T -t /dev/hda
/dev/hda:
Timing cached reads: 4816
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] De la part de
> Fortier,Vincent [Montreal]
>
> > -Message d'origine-
> > De : Alan Cox [mailto:[EMAIL PROTECTED]
> >
> > > I made a fwe tests to try to point out when high loads happens
> > > (which are
> The libata IRQ handler for that channel would then check for this flag
> on entry, before touching any chipset registers, and if it sees the flag
> then it should self-disable the IRQ and return immediately.
How do you plan to disable the IRQ at this point ?
Alan
-
To unsubscribe from this list
Mark Lord wrote:
> Tejun Heo wrote:
>>
>> I don't really know how to fix this. It seems the only options are 1.
>> disable_irq() as IDE does which sucks if the IRQ is shared 2. doing PIO
>> transfers with local IRQ disabled and spinlock locked which makes the
>> system stutter like hell. Oh crap,
Tejun Heo wrote:
I don't really know how to fix this. It seems the only options are 1.
disable_irq() as IDE does which sucks if the IRQ is shared 2. doing PIO
transfers with local IRQ disabled and spinlock locked which makes the
system stutter like hell. Oh crap, all this because we don't have
I swapped the drives out and I got identical results, which means the
problem lies in the driver or the card itself
I moved the card to a win32 machine to see what the official driver
would do. It failed on the 2nd sata channel too. So I'm gonna conclude
its physically broken. Sorry for the
Hello,
Daniel Drake wrote:
> Am I right in saying, to fix 2.6.21, the following patches are needed,
> and no others, in this order:
>
> sd: fix return value of sd_sync_cache()
> 3721050afc6cb6ddf6de0f782e2054ebcc225e9b
> (not sure if this one is required?)
It's a bug fix but not necessary for ma
Here's the updated shutdown.html. As linux-ide doesn't like html
attachment, I gzipped it. Let's see if this gets through. The updated
version is also available at
http://htj.dyndns.org/shutdown.html
Thanks.
--
tejun
shutdown.html.gz
Description: GNU Zip compressed data
> -Message d'origine-
> De : Alan Cox [mailto:[EMAIL PROTECTED]
> Envoyé : 16 mai 2007 16:43
>
> > I made a fwe tests to try to point out when high loads happens (which
> > are not really scientific :). Note that between each tests I made
> > sure the load average got back below 0.15.
With STANDBYDOWN tracking added, libata.spindown_compat isn't
necessary anymore. If userspace shutdown(8) issues STANDBYNOW, libata
warns. If userspace shutdown(8) doesn't issue STANDBYNOW, libata does
the right thing. Userspace can tell whether kernel supports spindown
by testing whether sysfs
Tim Valenzuela wrote:
> Good news: This patch does correct the IO access errors.
> Bad news: The sata driver now performs exactly like previous kernels, my
> sata3 works, sata4 has IDENTIFY errors.
The patch doesn't do anything about that problem, so it's expected.
> [ 26.927349] ata4: SATA lin
Good news: This patch does correct the IO access errors.
Bad news: The sata driver now performs exactly like previous kernels, my
sata3 works, sata4 has IDENTIFY errors.
[ 26.927349] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 26.961636] ata4.00: ata_hpa_resize 1: sectors = 625
On Thu, 17 May 2007 13:25:54 +0200
Borislav Petkov <[EMAIL PROTECTED]> wrote:
> -
> From: [EMAIL PROTECTED]
>
> A very small size (object file 432 bytes smaller) and readability
> optimization of ide.c
>
> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
Bad idea. Now you won't know whic
pcim_iomap_regions() conversion missed BAR5. Fix it.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
Sorry, dunno how I missed that during testing. :-( Please verify this
fixes your problem.
diff --git a/drivers/ata/sata_via.c b/drivers/ata/sata_via.c
index d105d2c..ac4f43c 100644
--- a/drivers
-
From: [EMAIL PROTECTED]
A very small size (object file 432 bytes smaller) and readability optimization
of ide.c
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
--
Index: 22-rc1/drivers/ide/ide.c
===
--- 22-rc1/drivers/ide/
Hello Borislav,
Thursday, May 17, 2007, 2:25:54 PM, you wrote:
> -
> From: [EMAIL PROTECTED]
> A very small size (object file 432 bytes smaller) and readability
> optimization of ide.c
And how these "optimizations" fit with BUG_ON() purpose - to
be able to easily identify cause and
As with all other drivers, sata_nv's hpriv is allocated with
devm_kzalloc() and there's no need to free it explicitly. Kill
nv_remove_one() which incorrectly used kfree() instead of devm_kfree()
and use ata_pci_remove_one() directly.
Original fix is from Peer Chen.
Signed-off-by: Tejun Heo <[EM
Recently, I acquired a
"SYBA SY-VIA-150 PCI SATA / IDE Combo Controller Card, Non Raid"
The physical chip reads "VT6421A 0651CD TAIWAN 21A0028971".
Each SATA channel has a drive plugged in, the PATA does not.
When using 2.6.22-rc1 I get some IO errors:
[ 32.177782] Bad IO access at port 8 (ret
Hello, Albert.
Albert Lee wrote:
> Back to the problem that the patch was trying to solve,
> i.e. unsolicited interrupt when HSM doing data transfer in the wq,
> is there any experience about how often such situation occurs?
>
> IMHO, it seems not something that happens often. If the cable/device
> Even if the unsolicited irq happens, maybe the current code has
> good chance to handle it?
> e.g. ata_irq_task() already reads the status before data transfer,
> thus possibly clearing some of unsolicited irqs.
> e.g. maybe the data transfer in the workqueue is quick enough?
Probably not given
Scott James Remnant wrote:
> On Wed, 2007-05-16 at 12:46 +0200, Tejun Heo wrote:
>
>>> I'll keep an eye on the thread you linked to, if we don't even need to
>>> write any zeros, we're definitely happy people :-)
>> Me happy too. :-)
>>
> Out of interest, do you know there is a hysterical need to
Alan Cox wrote:
>>As previously discussed, the possible issue with this patch is:
>>Some ATA/ATAPI devices might be unhappy if the STATUS register
>>is read during data transfer (not sure if this is true or not).
>>(Patch 5/8 doesn't have such issue.)
>
>
> Some older intel eats your disk if you
32 matches
Mail list logo
