Hi,
On Friday 18 May 2007, Thomas Kuther wrote:
> On Mi, 16.05.07 11:46 Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> wrote:
>
> > > Shall I test it without "noraid=1" too?
> >
> > Please do, the main goal of the patch was to fix "RAID mode"
> > ("noraid=1" should work fine also without the
On Thu, May 24, 2007 at 02:02:11AM -0400, Jeff Garzik wrote:
> Ben's patch got merged because it does not change the status quo. This
Yes it does - SRST timing is now wrong for the SIL680. Thats PATA and now
PATA + MMIO so the problem case.
-
To unsubscribe from this list: send the line "unsubs
Andrew Paprocki wrote:
> Ethan, I believe my 2.6.22-rc2 kernel *is* working with respect to the
> libata problem. By removing CONFIG_IDE, the system now works fine. The
> reason why I thought that libata was still having a problem was
> because the system would hang after agpgart printed:
> "agpgar
> Currently libata does the 400ns thingy in the inline ata_pause() which
> unconditionally does ata_altstatus(); ndelay(400); (and thus does it on
> PIO, MMIO, anything ...).
It might actually improve performance for PATA if we did as we'll get rid
of an excess (expensive) PCI read access for non
Alan Cox wrote:
On Thu, May 24, 2007 at 02:02:11AM -0400, Jeff Garzik wrote:
Ben's patch got merged because it does not change the status quo. This
Yes it does - Thats PATA and now
PATA + MMIO so the problem case.
hmmm, true.
Jeff
-
To unsubscribe from this list: send the line "
On Thu, 2007-05-24 at 02:02 -0400, Jeff Garzik wrote:
> MMIO has always been like this (libata-core.c):
>
> /* software reset. causes dev0 to be selected */
> iowrite8(ap->ctl, ioaddr->ctl_addr);
> udelay(20); /* FIXME: flush */
> iowrite8(ap->ctl | ATA_SRS
On Thu, 2007-05-24 at 05:55 -0400, Jeff Garzik wrote:
> Alan Cox wrote:
> > On Thu, May 24, 2007 at 02:02:11AM -0400, Jeff Garzik wrote:
> >> Ben's patch got merged because it does not change the status quo. This
> >
> > Yes it does - Thats PATA and now
> > PATA + MMIO so the problem case.
>
>
Alan Cox wrote:
Currently libata does the 400ns thingy in the inline ata_pause() which
unconditionally does ata_altstatus(); ndelay(400); (and thus does it on
PIO, MMIO, anything ...).
It might actually improve performance for PATA if we did as we'll get rid
of an excess (expensive) PCI read ac
> > hd.c:(.init.text+0x44a7d): undefined reference to `drive_info'
> > hd.c:(.init.text+0x44a89): undefined reference to `drive_info'
> > hd.c:(.init.text+0x44a95): undefined reference to `drive_info'
> > hd.c:(.init.text+0x44aa1): undefined reference to `drive_info'
> > hd.c:(.init.text+0x44aad):
On Thu, 24 May 2007 06:52:13 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> >> Currently libata does the 400ns thingy in the inline ata_pause() which
> >> unconditionally does ata_altstatus(); ndelay(400); (and thus does it on
> >> PIO, MMIO, anything ...).
> >
> > It might actu
Alan Cox wrote:
On Thu, 24 May 2007 06:52:13 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
Alan Cox wrote:
Currently libata does the 400ns thingy in the inline ata_pause() which
unconditionally does ata_altstatus(); ndelay(400); (and thus does it on
PIO, MMIO, anything ...).
It might actually
Hello,
I noticed very odd thing : sequential write speed to SATA-II disk (SAMSUNG
SP2504C) is 12Mbyte/s, but writing to software RAID1 array that consists
of only that same one disk (other is 'missing') I get speed of 20Mbytes/s!
I tested this on another box aswell - there I even got 30Mbytes
Bartlomiej Zolnierkiewicz wrote:
Bartlomiej Zolnierkiewicz wrote:
There's no reason to have the speedproc() method wrapper for the two quite
different chip families, so just get rid of it.
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
applied
I forgot to notice/mention the side
Hi there,
seems I've always subscribed to SATA problems. :-)
We installed Debian Etch with the pre-compiled kernel, but when doing
heavy SATA data transfer, the drives seem to make trouble. Even with the
latest kernel, 2.6.21.2, we receive:
===
ata3.00: exception Emask 0x10 SAct 0x1 SErr 0x4
Hi,
I'm going through the process of setting up a new mythtv box. I
decided to let it record for a few days to see how it goes under a
constant workload and am seeing an occasional error in the logs about
NCQ problems. They are not happening with any regularity, maybe once
every 3-4 hours.
Thi
Hello,
Florian Effenberger wrote:
> We installed Debian Etch with the pre-compiled kernel, but when doing
> heavy SATA data transfer, the drives seem to make trouble. Even with the
> latest kernel, 2.6.21.2, we receive:
>
> ===
> ata3.00: exception Emask 0x10 SAct 0x1 SErr 0x400100 action 0x2 fro
Hi all,
Here is a list of some known regressions in 2.6.22-rc2
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
Block devices
Subject: loop devices limited to one single device
References : http://lkml.org/lkml/2007/5/16
Hi,
thanks for the fast reply!
Looks like a genuine transmission/interface error to me. How often does
this occur? Please try to connect the drive to another port using and
possibly different power lane. Also, testing with another drive is a
good way to track down where the problem is.
it
Florian Effenberger wrote:
>> Looks like a genuine transmission/interface error to me. How often does
>> this occur? Please try to connect the drive to another port using and
>> possibly different power lane. Also, testing with another drive is a
>> good way to track down where the problem is.
>
Hi,
Data integrity wise there should be no problem but your error rate is
pretty high and eventually will make libata turn off NCQ and/or speed
down PHY speed.
switching ports is not easy. Both on-board SATA controllers are being
used, and the error seems to occur on all ports.
Yeap, your
Florian Effenberger wrote:
> Hi,
>
>> Data integrity wise there should be no problem but your error rate is
>> pretty high and eventually will make libata turn off NCQ and/or speed
>> down PHY speed.
>
> switching ports is not easy. Both on-board SATA controllers are being
> used, and the error s
On 5/24/07, Florian Effenberger <[EMAIL PROTECTED]> wrote:
Hi,
> Data integrity wise there should be no problem but your error rate is
> pretty high and eventually will make libata turn off NCQ and/or speed
> down PHY speed.
switching ports is not easy. Both on-board SATA controllers are being
Greg Freemyer wrote:
>> I will try to use another test disk. Right now we use different models
>> of Western Digital "RAID edition".
>>
>
> iiuc, raid editions are designed to fail fast thus allowing an
> alternate drive to provide the data rather than having to wait thru
> multiple internal retri
Hi,
iiuc, raid editions are designed to fail fast thus allowing an
alternate drive to provide the data rather than having to wait thru
multiple internal retries.
Could this just be a case of the drive functioning as designed?
to be honest, I don't know. :-)
Any jumper settings to change tha
> Subject: pata_via appears to incorrectly detects 40-pin cable
> References : http://lkml.org/lkml/2007/5/17/273
> http://bugzilla.kernel.org/show_bug.cgi?id=8142
> Submitter : Francis Russell <[EMAIL PROTECTED]>
> Status : Not really a regression. Alan seems to have a genera
We just disabled the RAID (Linux software RAID, no hardware RAID) and
tested with one disk only, same results
What string should I grep the logs for when things are being lowered?
If you let the system run, libata will turn off NCQ and/or lower PHY
speed to 1.5Gbps. Do errors disappear after
Get rid of the init_dma() method (which had no particular reason to exist) by
folding it into the init_hwif() method. While at it, also perform some cleanup
in the latter method:
- get rid of the useless clearing of hwif->autodma;
- fold the serialization code into one 'if' statement;
- fold set
There's no reason to have the speedproc() method wrapper for the two quite
different chip families, so just get rid of it.
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
---
Tthis version of the patch properly installs the speedproc() method.
Again, the patch has only been compile tested...
On Thu, 24 May 2007 16:11:16 +0100 Alan Cox <[EMAIL PROTECTED]> wrote:
> > Subject: pata_via appears to incorrectly detects 40-pin cable
> > References : http://lkml.org/lkml/2007/5/17/273
> > http://bugzilla.kernel.org/show_bug.cgi?id=8142
> > Submitter : Francis Russell <[EMAIL
Alan Cox wrote:
>>> hd.c:(.init.text+0x44a7d): undefined reference to `drive_info'
>>> hd.c:(.init.text+0x44a89): undefined reference to `drive_info'
>>> hd.c:(.init.text+0x44a95): undefined reference to `drive_info'
>>> hd.c:(.init.text+0x44aa1): undefined reference to `drive_info'
>>> hd.c:(.init
On Tue, May 01, 2007 at 05:02:22AM +0200, Tejun Heo wrote:
> Hello, Art Haas.
>
> Art Haas wrote:
> > Hi.
> >
> > Back in the beginning of February I was sent a patch to test during the
> > time the CD-ROM identification bug was affecting my computer. The
> > first posting of the patch appeared o
Hello, I wrote:
HPT36x chip don't seem to have the channel enable bits, so prevent the IDE core
from checking them...
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/ide/pci/hpt366.c
===
--- linux-2.
Hi,
On Fri, May 25, 2007 at 12:23:25AM +0400, Sergei Shtylyov wrote:
> Hello, I wrote:
> >HPT36x chip don't seem to have the channel enable bits, so prevent the IDE
> >core from checking them...
>
> >Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
>
> > d->channels = 1;
> >+d->enable
Linas Vepstas wrote:
HPT36x chip don't seem to have the channel enable bits, so prevent the IDE
core from checking them...
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
d->channels = 1;
+ d->enablebits[0].reg = 0;
The original patch worked for me.
Linas, Andries,
Art Haas wrote:
On Tue, May 01, 2007 at 05:02:22AM +0200, Tejun Heo wrote:
Hello, Art Haas.
Art Haas wrote:
Hi.
Back in the beginning of February I was sent a patch to test during the
time the CD-ROM identification bug was affecting my computer. The
first posting of the patch appeared on Feb.
Benjamin Herrenschmidt wrote:
The only thing that I'm wondering about a bit is that ata_pause so far
uses read of altstatus which _is_ a taskfile register. It's my
understanding that we should avoid doing so in that case.
Technically, altstatus is in the control block rather than the command b
Jeff Garzik wrote:
> Please resend with proper sign-offs. All patches in the kernel need
> that... http://linux.yyz.us/patch-format.html
I was supposed to do that and Art reminded me once but I managed to
forget again, duh. I'll do it first thing tomorrow. Sorry, Art.
--
tejun
-
To unsubs
On Fri, May 25, 2007 at 12:53:19AM +0400, Sergei Shtylyov wrote:
>
> knows how to make broken hardware. :-)
You mean, "value-added hardware" ;->
--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
Hello, I wrote:
HPT36x chip don't seem to have the channel enable bits, so prevent
the IDE core from checking them...
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
d->channels = 1;
+d->enablebits[0].reg = 0;
The original patch worked for me.
Linas, Andries, Michal, cou
[ adding linux-ide ML and Sergei to cc: ]
Hi,
On Thursday 24 May 2007, Pascal Schmidt wrote:
>
> Hello!
>
> I recently upgraded my kernel to 2.6.21 (.1 and .2 with identical
> results) and my second IDE controller, a HPT366 on a PCI card,
> doesn't get enabled any more. The latest previous ker
On Thu, 2007-05-24 at 16:56 -0400, Mark Lord wrote:
> Benjamin Herrenschmidt wrote:
> >
> > The only thing that I'm wondering about a bit is that ata_pause so far
> > uses read of altstatus which _is_ a taskfile register. It's my
> > understanding that we should avoid doing so in that case.
>
> Te
Hello again!
> The fix from Sergei (queued for 2.6.21.3) is here:
>
> http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob_plain;f=queue-2.6.21/hpt366-don-t-check-enablebits-for-hpt36x.patch;h=0833e0a37e23ed103a18ca93684201e1cb94a0a9
>
> [ it has already been merged into 2.6.2
Alan Cox wrote:
>
> hd.c can drive MFM and RLL disks and drivers/ide cannot. Although it
> really wants burying further down the config tree the ability to read MFM
> and RLL disks when recovering ancient data is useful and people do
> actually use this driver now and then rescuing stuff like twen
> > It thus needs fixing not removing.
> >
>
> Opinions, anyone (especially Alan):
>
> http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=commitdiff;h=369f16fdd423d79640c4390915e6ab71189cb497
I believe the technical description for the comment is "bullshit" 8)
Almost all MF
Alan Cox wrote:
> I believe the technical description for the comment is "bullshit" 8)
>
> Almost all MFM controllers and RLL controllers will only run at the
> standard primary and secondary ATA address.
Yes, but that doesn't (necessarily) apply to the controller that is
likely to be the primary
Alan Cox wrote:
On Thu, 24 May 2007 06:52:13 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
Alan Cox wrote:
Currently libata does the 400ns thingy in the inline ata_pause() which
unconditionally does ata_altstatus(); ndelay(400); (and thus does it on
PIO, MMIO, anything ...).
It might actually
> #define DELAY400NS { pio_inbyte( CB_ASTAT ); pio_inbyte( CB_ASTAT ); \
>pio_inbyte( CB_ASTAT ); pio_inbyte( CB_ASTAT ); }
>
>
Totally unrelated. Hal is using the cycle time of the four I/O reads to
do the 400nS delay. Its a neat way to do the delay on boxes without
mo
> The question I'm asking is: do you think it's better to remove this from
> hd.c, or do you think it's better to add it back boot code BIOS
> detection (and take the risk of poking an ST-506 disk with legacy data
> with parameters which may belong to another disk -- keep in mind this
> can permane
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/ata_piix.c |1 +
drivers/ata/libata-core.c |4 +-
drivers/ata/pata_hpt3x2n.c |4 +-
drivers/ata/pata_sis.
Alan Cox wrote:
#define DELAY400NS { pio_inbyte( CB_ASTAT ); pio_inbyte( CB_ASTAT ); \
pio_inbyte( CB_ASTAT ); pio_inbyte( CB_ASTAT ); }
Totally unrelated. Hal is using the cycle time of the four I/O reads to
do the 400nS delay. Its a neat way to do the delay on boxes
Alan Cox wrote:
>> The question I'm asking is: do you think it's better to remove this from
>> hd.c, or do you think it's better to add it back boot code BIOS
>> detection (and take the risk of poking an ST-506 disk with legacy data
>> with parameters which may belong to another disk -- keep in min
Tejun, fdisk -l output is attached
Basically, in the ICH8 BIOS:
/dev/sda + sdb = 2 500GB drives in RAID1 configuration
/dev/sdc + sdd + sde + sdf = 4 320GB drives in RAID5 configuration
/dev/sdg is a 320GB boot drive connected to the JMB363 chipset
Is there some kind of problem when probing the
Tejun Heo wrote:
* Add acpi_handle to ata_host and ata_port. Rename
ata_device->obj_handle to ->acpi_handle and move it above such that
it doesn't get cleared on reconfiguration.
* Replace ACPI node association which ata_acpi_associate() which is
called once during host initialization. U
Tejun Heo wrote:
ap->cbl == ATA_CBL_SATA indicates SATA cable while ap->flags &
ATA_FLAG_SATA indicates SATA host port. Till now they always gave the
same result but SATA/PATA bridge handling will change that. Switch to
ATA_FLAG_SATA test if we're testing for host port type.
Signed-off-by: Tej
Jens Axboe wrote:
On Mon, May 21 2007, Jeff Garzik wrote:
Jens Axboe wrote:
ahci has always had clustering disabled, perhaps Jeff can expand on why?
Just historical reasons. libata had clustering disabled by default in
the beginning, for all drivers. Then we enabled it globally by changing
Kristen Carlson Accardi wrote:
Hi Jeff,
Here are the AN patches again, they have not changed with the exception
of patch #1, which does set the host flag in board_ahci and board_ahci_pi
now (thanks Tejun).
This patch series implements Asynchronous Notification (AN) for SATA
ATAPI devices as defi
Kristen Carlson Accardi wrote:
Check to see if an ATAPI device supports Asynchronous Notification.
If so, enable it.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
---
Andrew, I cleaned up the function header to properly comply with kernel
doc requirements. Other than that, this pat
Simon Griph wrote:
With NCQ enabled, this drive always hangs when under load and remains
hung until the next cold boot.
Very similar to: http://thread.gmane.org/gmane.linux.ide/17640
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 0abd72d..17e27e9 100644
--- a/drivers/a
Daniel Beichl wrote:
+static int sil_check_atapi_dma(struct ata_queued_cmd *qc)
+{
+ /* limit atapi commands less than 60bytes to pio as certain sil */
+ /* chips seem to have trouble to perform dma for these commands */
+ if ( (qc->scsicmd != NULL) &&
+(qc->scsicmd-
Henry Su wrote:
> --- linux-2.6.21.1.orig/drivers/ata/pata_atiixp.c 2007-05-10
> 06:30:14.0 폍
> linux-2.6.21.1/drivers/ata/pata_atiixp.c 2007-05-10 07:17:07.0 폍
> @@ -283,6 ,7 @@ static const struct pci_device_id atiixp
> { PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP300_I
[EMAIL PROTECTED] wrote:
From: Tony Vroon <[EMAIL PROTECTED]>
This adds an optional wrapper around ata_ac_issue_prot that triggers the
LED layer. This is used for the PMU LED on G5 towers (IDE trigger). My
test platform is a PowerMac 7,3 (Dual G5 2.0GHz, June 2004) with a K2
(sata_svw) control
I moved the sil680 MMIO changes from 'upstream' (queued for 2.6.23) to a
side branch 'sil680-mmio'.
To be clear, I am still quite interested in the patch (w/ the reset
fix), but I did not want to delay other unrelated stuff that was about
to be queued into #upstream.
The patch will still app
On Thu, 2007-05-24 at 23:33 -0400, Jeff Garzik wrote:
> I moved the sil680 MMIO changes from 'upstream' (queued for 2.6.23) to
> a
> side branch 'sil680-mmio'.
>
> To be clear, I am still quite interested in the patch (w/ the reset
> fix), but I did not want to delay other unrelated stuff that w
Benjamin Herrenschmidt wrote:
On Thu, 2007-05-24 at 23:33 -0400, Jeff Garzik wrote:
I moved the sil680 MMIO changes from 'upstream' (queued for 2.6.23) to
a
side branch 'sil680-mmio'.
To be clear, I am still quite interested in the patch (w/ the reset
fix), but I did not want to delay other
On Fri, 2007-05-25 at 00:26 -0400, Jeff Garzik wrote:
> Just replace the ata_std_softreset() call with code that does MMIO
> flushes on a safe register?
Yeah well... if just reading altstatus is enough, I don't see the point
of doing anything MMIO-dependant or whatever. I can just add reading of
Benjamin Herrenschmidt wrote:
On Fri, 2007-05-25 at 00:26 -0400, Jeff Garzik wrote:
Just replace the ata_std_softreset() call with code that does MMIO
flushes on a safe register?
Yeah well... if just reading altstatus is enough, I don't see the point
of doing anything MMIO-dependant or whateve
On Fri, 2007-05-25 at 00:41 -0400, Jeff Garzik wrote:
> Sorry, to be clear I would not want to change the core code to bang
> AltStatus in the middle of the SRST twiddles...
>
> The core code only fails (in theory) for PATA+MMIO cases, and the
> easiest fix should be to read some innocuous vendo
Hi Jeff,
Thanks for your kindly help, I will fix the email next time.
Do you mean all the device IDs for ATI SB700 are added to the corresponding
files?
because I split this patch and resent four patches according to your last
suggestion,
if this patch is applied, another patches are not necess
68 matches
Mail list logo
