Re: [git patches] libata fixes
On Sunday 24 February 2008, Alan Cox wrote: > > From the patch description it can't be told whether the patch itself is > > correct and only the patch description is bogus... > > zero length PRD misparsing. If I remember rightly old IDE never generates > 64K PRD slots because other hardware can't handle it either (CS5520/30 > etc) OK, that would explain it. Thanks, Bart - 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
Re: [git patches] libata fixes
> From the patch description it can't be told whether the patch itself is > correct and only the patch description is bogus... zero length PRD misparsing. If I remember rightly old IDE never generates 64K PRD slots because other hardware can't handle it either (CS5520/30 etc) - 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
Re: [git patches] libata fixes
On Sunday 24 February 2008, Jeff Garzik wrote:
[...]
> Alan Cox (1):
> pata_atiixp: Use 255 sector limit
AHCI needs sorting too but this deals with the old interface
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
[...]
>> diff --git a/drivers/ata/pata_atiixp.c b/drivers/ata/pata_atiixp.c
> index 9623f52..408bdc1 100644
> --- a/drivers/ata/pata_atiixp.c
> +++ b/drivers/ata/pata_atiixp.c
> @@ -227,7 +227,7 @@ static struct scsi_host_template atiixp_sht = {
> .queuecommand = ata_scsi_queuecmd,
> .can_queue = ATA_DEF_QUEUE,
> .this_id= ATA_SHT_THIS_ID,
> - .sg_tablesize = LIBATA_MAX_PRD,
> + .sg_tablesize = LIBATA_DUMB_MAX_PRD,
> .cmd_per_lun= ATA_SHT_CMD_PER_LUN,
> .emulated = ATA_SHT_EMULATED,
> .use_clustering = ATA_SHT_USE_CLUSTERING,
> @@ -259,7 +259,7 @@ static struct ata_port_operations atiixp_port_ops = {
> .bmdma_stop = atiixp_bmdma_stop,
> .bmdma_status = ata_bmdma_status,
>
> - .qc_prep= ata_qc_prep,
> + .qc_prep= ata_dumb_qc_prep,
> .qc_issue = ata_qc_issue_prot,
>
> .data_xfer = ata_data_xfer,
This patch doesn't enforce "255 sector limit" but instead:
- limits max PRD table size from 128 entries to 64
- enables quirk needed for some chipsets to split 64K PRD table entry
on two 32K ones (these chipsets choke on size == 0x)
>From the patch description it can't be told whether the patch itself is
correct and only the patch description is bogus...
Alan/Jeff: please elaborate on what the patch is trying to achieve.
Thanks,
Bart
-
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
Re: [git patches] libata fixes
Jeff Garzik wrote: > libata disabling command queueing (aka NCQ) based on some hueristics for > detection device brokenness that ultimately turned out to be broken. > > Remove the broken hueristic and turn NCQ back on for all the wrongfully > maligned hard drives. Yay! - 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
Re: [git patches] libata fixes
Tejun Heo wrote: These are upstream patches I collected while Jeff is away. Thanks. * workaround for ATAPI tape drives * detection/suspend workarounds for several laptops * ICH8/9 port_enable fix ata_piix controller ID reorganization is included to ease the fixes. Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/tj/libata-dev.git upstream-linus to receive the following updates: drivers/ata/ata_piix.c| 87 drivers/ata/libata-core.c | 100 +++--- drivers/ata/libata-eh.c | 95 --- drivers/ata/libata-scsi.c |3 - drivers/ata/pata_sis.c|1 include/linux/libata.h|5 -- 6 files changed, 81 insertions(+), 210 deletions(-) Adrian Bunk (1): libata: remove unused functions Albert Lee (2): libata: workaround DRQ=1 ERR=1 for ATAPI tape drives libata: use ATA_HORKAGE_STUCK_ERR for ATAPI tape drives Gabriel C (1): pata_sis.c: Add Packard Bell EasyNote K5305 to laptops Mark Lord (1): libata-scsi: be tolerant of 12-byte ATAPI commands in 16-byte CDBs Tejun Heo (3): ata_piix: add SATELLITE U205 to broken suspend list ata_piix: reorganize controller IDs ata_piix: port enable for the first SATA controller of ICH8 is 0xf not 0x3 Thomas Rohwer (1): ata_piix: only enable the first port on apple macbook pro Just to make sure, I pulled this into #upstream-fixes. If Linus already picked it up, great. Otherwise I'll make sure it goes upstream. 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
Re: [git patches] libata fixes
Mikael Pettersson wrote: That's my fault for misremembering the rule about the number of dashes before the other comments part :-( I'll remember better in the future. Well, I should have caught it and hand-edited it on my side too... 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
Re: [git patches] libata fixes
On Tue, 30 Oct 2007 11:54:01 -0700 (PDT), Linus Torvalds wrote: > On Tue, 30 Oct 2007, Jeff Garzik wrote: > > > > Mikael Pettersson (2): > > sata_promise: ASIC PRD table bug workaround, take 2 > > sata_promise: cleanups > > You and Mikael need to sort out the way you send/accept patches. > > Both of these commits had stuff like this: > > Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]> > -- > Changes since previous version: > * use new PDC_MAX_PRD constant to initialise sg_tablesize > > drivers/ata/sata_promise.c | 87 > ++--- > 1 files changed, 83 insertions(+), 4 deletions(-) > Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> > > which seems to be because Mikael uses two dashes instead of three to > separate his "real message" from the stuff you have. > > So either you need to teach Mikael to use the proper separators That's my fault for misremembering the rule about the number of dashes before the other comments part :-( I'll remember better in the future. /Mikael - 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
Re: [git patches] libata fixes
Jan Engelhardt <[EMAIL PROTECTED]> writes:
> On Oct 30 2007 12:31, Linus Torvalds wrote:
>>On Tue, 30 Oct 2007, Jeff Garzik wrote:
>>>
>>> Can we change git-am to accept two dashes as well as three? :)
>>
>>Well, git-am actually used to be a lot less strict about the dashes, and
>>we've made it *more* strict rather than less, because the more of these
>>breaks we accept, the more likely it is that something that was intended
>>to be part of the message gets thrown out.. So I'll say that I'm a bit
>>nervous about extending it again.
>
> I would not add --. It is already used ("-- " is) in the mail world as a
> signature separator. Let's stay with ---, which is also what quilt generates.
Thanks for the input about what quilt does.
So the way to proceed is to have no change to mailinfo, and have
a bit of user education.
-
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
Re: [git patches] libata fixes
On Oct 30 2007 12:31, Linus Torvalds wrote:
>On Tue, 30 Oct 2007, Jeff Garzik wrote:
>>
>> Can we change git-am to accept two dashes as well as three? :)
>>
>> It seems pretty common, not just with Mikael but several others who send
>> patches to me.
>
>Well, git-am actually used to be a lot less strict about the dashes, and
>we've made it *more* strict rather than less, because the more of these
>breaks we accept, the more likely it is that something that was intended
>to be part of the message gets thrown out.. So I'll say that I'm a bit
>nervous about extending it again.
I would not add --. It is already used ("-- " is) in the mail world as a
signature separator. Let's stay with ---, which is also what quilt generates.
>
>The reason for the three dashes is actually that that is what a *diff*
>starts with. So if you look at what "closes" a description as far as
>git-am is concerned, they are currently all things that are likely to
>start a patch: "Index: " or "diff -" or "--- ", and that last
>case was then extended to be "manual break" even without the filename
>information.
>
>See git/builtin-mailinfo.c: patchbreak().
>
>But you could try to sell it to Junio. He's the maintainer, and while I
>care about some other things and will argue violently against them, when
>it comes to something like this, Junio is the guy to go to.
>
>That said, I really think you could just try to educate the people you
>work with. Maybe they just never even realized that "three dashes" is what
>you're supposed to use!
>
> Linus
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [EMAIL PROTECTED]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
-
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
Re: [git patches] libata fixes
On Tue, 30 Oct 2007, Jeff Garzik wrote: > > Can we change git-am to accept two dashes as well as three? :) > > It seems pretty common, not just with Mikael but several others who send > patches to me. Well, git-am actually used to be a lot less strict about the dashes, and we've made it *more* strict rather than less, because the more of these breaks we accept, the more likely it is that something that was intended to be part of the message gets thrown out.. So I'll say that I'm a bit nervous about extending it again. The reason for the three dashes is actually that that is what a *diff* starts with. So if you look at what "closes" a description as far as git-am is concerned, they are currently all things that are likely to start a patch: "Index: " or "diff -" or "--- ", and that last case was then extended to be "manual break" even without the filename information. See git/builtin-mailinfo.c: patchbreak(). But you could try to sell it to Junio. He's the maintainer, and while I care about some other things and will argue violently against them, when it comes to something like this, Junio is the guy to go to. That said, I really think you could just try to educate the people you work with. Maybe they just never even realized that "three dashes" is what you're supposed to use! Linus - 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
Re: [git patches] libata fixes
Linus Torvalds wrote: On Tue, 30 Oct 2007, Jeff Garzik wrote: Mikael Pettersson (2): sata_promise: ASIC PRD table bug workaround, take 2 sata_promise: cleanups You and Mikael need to sort out the way you send/accept patches. Both of these commits had stuff like this: Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]> -- Changes since previous version: * use new PDC_MAX_PRD constant to initialise sg_tablesize drivers/ata/sata_promise.c | 87 ++--- 1 files changed, 83 insertions(+), 4 deletions(-) Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> which seems to be because Mikael uses two dashes instead of three to separate his "real message" from the stuff you have. So either you need to teach Mikael to use the proper separators, or you need to edit these things down to be something readable instead of keeping the extraneous commentary around... Pulled, but I'm hoping for cleaner commit messages in the future.. Can we change git-am to accept two dashes as well as three? :) It seems pretty common, not just with Mikael but several others who send patches to me. 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
Re: [git patches] libata fixes
On Tue, 30 Oct 2007, Jeff Garzik wrote: > > Mikael Pettersson (2): > sata_promise: ASIC PRD table bug workaround, take 2 > sata_promise: cleanups You and Mikael need to sort out the way you send/accept patches. Both of these commits had stuff like this: Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]> -- Changes since previous version: * use new PDC_MAX_PRD constant to initialise sg_tablesize drivers/ata/sata_promise.c | 87 ++--- 1 files changed, 83 insertions(+), 4 deletions(-) Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> which seems to be because Mikael uses two dashes instead of three to separate his "real message" from the stuff you have. So either you need to teach Mikael to use the proper separators, or you need to edit these things down to be something readable instead of keeping the extraneous commentary around... Pulled, but I'm hoping for cleaner commit messages in the future.. Linus - 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
Re: [git patches] libata fixes
On Tue, 2007-07-03 at 18:21 +0100, Alan Cox wrote: > Chuck posted a link to an attachment in bugzilla not to anything from > version control. And the bugzilla bug clearly indicates who posted the > attachment. Probably Chuck should have posted the bug number as well. Perhaps it would have helped if the attachment itself contained a short comment and some information about its own provenance. It can be painful trawling through bugzilla to find the latest version of a patch -- a direct link to the attachment often is much nicer. And the person who attaches a bug to bugzilla isn't necessarily the author of it anyway. -- dwmw2 - 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
Re: [git patches] libata fixes
> So instead of complaining to Jeff about this, you should look at YOUR OWN > damn system. It was apparently your "enterprise ready" stuff, used by > another Red Hat engineer, that screwed up. Umm no Linus. Chuck posted a link to an attachment in bugzilla not to anything from version control. And the bugzilla bug clearly indicates who posted the attachment. Probably Chuck should have posted the bug number as well. Alan - 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
Re: [git patches] libata fixes
On Tue, 3 Jul 2007, Alan Cox wrote: > > > attribution. Probably because of some insane system he uses (he has a > > comment in that bugzilla about "patch from comment #14 is in CVS now.". > > > > CVS? What kind if insane setup do you have there at Red Hat? > > CVS is used for tracking patch sets for RPMS rather than source trees. > Its quite good at that job and its reliable and proven and has been done > that way for years. When you are keeping a stable distribution for large > business end users the "stable and proven" wins over new technology... Yes, but it also explains why it lost all authorship. So instead of complaining to Jeff about this, you should look at YOUR OWN damn system. It was apparently your "enterprise ready" stuff, used by another Red Hat engineer, that screwed up. THAT is my point. Linus - 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
Re: [git patches] libata fixes
> attribution. Probably because of some insane system he uses (he has a > comment in that bugzilla about "patch from comment #14 is in CVS now.". > > CVS? What kind if insane setup do you have there at Red Hat? CVS is used for tracking patch sets for RPMS rather than source trees. Its quite good at that job and its reliable and proven and has been done that way for years. When you are keeping a stable distribution for large business end users the "stable and proven" wins over new technology... Alan - 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
Re: [git patches] libata fixes
On Tue, 3 Jul 2007, Alan Cox wrote: > > > Chuck Ebbert (1): > > pata_ali: fix UDMA settings > > Could you please fix your git tree to have the proper credits for patches > you pull from bugzilla. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242472 I don't think it is Jeff who needs to fix anything: it seems that it is Chuck Ebbert you should talk to. He's the one that dropped the attribution. Probably because of some insane system he uses (he has a comment in that bugzilla about "patch from comment #14 is in CVS now.". CVS? What kind if insane setup do you have there at Red Hat? Linus - 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
Re: [git patches] libata fixes
> Chuck Ebbert (1): > pata_ali: fix UDMA settings Could you please fix your git tree to have the proper credits for patches you pull from bugzilla. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242472 Alan - 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
Re: [git patches] libata fixes
On Wed, 27 Jun 2007 03:35:26 -0400, Jeff Garzik wrote: >Tejun Heo (9): > libata: kill the infamous abnormal status message > libata: kill non-sense warning message > libata: be less verbose about hpa > libata: remove unused variable from ata_eh_reset() > libata: fix ata_dev_disable() > libata: fix infinite EH waiting bug > libata: call ata_check_atapi_dma() with qc better prepared > libata: use PIO for non-16 byte aligned ATAPI commands > libata: kill ATA_HORKAGE_DMA_RW_ONLY These changes fixed the CDROM IDENTIFY failures one of my older test machines used to get with libata. I now get much nicer results on that machine: ata_piix :00:1f.1: version 2.11 PCI: Setting latency timer of device :00:1f.1 to 64 scsi0 : ata_piix scsi1 : ata_piix ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15 ata1.00: ATA-5: IC35L080AVVA07-0, VA4OA52A, max UDMA/100 ata1.00: 160836480 sectors, multi 16: LBA ata1.00: configured for UDMA/100 ata2.00: ATAPI: CRD-8320B, 1.12, max MWDMA2 ata2.01: ATAPI: Hewlett-Packard CD-Writer Plus 9100, 1.0c, max UDMA/33 ata2.00: configured for MWDMA2 ata2.01: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA IC35L080AVVA07-0 VA4O PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 160836480 512-byte hardware sectors (82348 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 160836480 512-byte hardware sectors (82348 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 < sda5 sda6 > sd 0:0:0:0: [sda] Attached SCSI disk scsi 1:0:0:0: CD-ROMGoldStar CD-ROM CRD-8320B 1.12 PQ: 0 ANSI: 5 scsi 1:0:1:0: CD-ROMHP CD-Writer+ 9100 1.0c PQ: 0 ANSI: 5 It's the CRD-8320B that used to time out and fail IDENTIFY. Tested-by: Mikael Pettersson <[EMAIL PROTECTED]> - 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
Re: [git patches] libata fixes
On Wed, 27 Jun 2007, Jeff Garzik wrote: > > Such would be a diagnostic that would trigger on valid SCSI commands, when the > user is doing nothing wrong and the system can indeed complete the command > just fine. Additionally, this is moving us in the direction of what the IDE > driver has apparently been doing. Indeed. At least the IDE CD-ROM driver does if ((rq->data_len & 15) || (addr & mask)) info->dma = 0; where the "mask" is the dma_alignment mask. So it requires the length to be a multiple of 16, and also requires a certain alignment of the data (which defaults to 32 bytes for some reason I cannot for the life of me remember). The generic BIO layer does that DMA alignment check too when mapping user pages. Linus - 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
Re: [git patches] libata fixes
Andrew Morton wrote: On Wed, 27 Jun 2007 03:35:26 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: + /* Don't allow DMA if it isn't multiple of 16 bytes. Quite a +* few ATAPI devices choke on such DMA requests. +*/ + if (unlikely(qc->nbytes & 15)) + return 1; It might be worth emitting a diagnostic when this happens. I tend to disagree, but if any screaming users show up, we can certainly think about adding some. Such would be a diagnostic that would trigger on valid SCSI commands, when the user is doing nothing wrong and the system can indeed complete the command just fine. Additionally, this is moving us in the direction of what the IDE driver has apparently been doing. 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
Re: [git patches] libata fixes
On Wed, 27 Jun 2007 03:35:26 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: > + /* Don't allow DMA if it isn't multiple of 16 bytes. Quite a > + * few ATAPI devices choke on such DMA requests. > + */ > + if (unlikely(qc->nbytes & 15)) > + return 1; It might be worth emitting a diagnostic when this happens. - 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
Re: [git patches] libata fixes
Jeff Garzik wrote:
> And a few trivial documentation patches.
>
> 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-scsi.c |5 ++-
> drivers/ata/pata_artop.c |2 +-
> drivers/ata/pata_hpt37x.c | 27 ++---
> drivers/ata/pata_it821x.c |3 +-
> drivers/ata/pata_scc.c | 46 ++-
> drivers/ata/pata_via.c |9 ---
> drivers/ata/sata_mv.c | 44 ++
> drivers/ata/sata_promise.c |2 +-
> drivers/ata/sata_sis.c |2 +-
> drivers/ata/sata_via.c |3 ++
> 10 files changed, 98 insertions(+), 45 deletions(-)
>
> Alan Cox (2):
> pata: Trivia
> pata_hpt37x: Further improvements based on the IDE updates and vendor
> drivers
>
> Jeff Garzik (4):
> [libata] sata_promise: fix flags typo
> [libata] sata_mv: add TODO list
> [libata] Fix decoding of 6-byte commands
> [libata] sata_via, pata_via: Add PCI IDs.
>
> Tony Breeds (1):
> Fix build failure for drivers/ata/pata_scc.c
>
> Uwe Koziolek (1):
> libata: sata_sis fixes
>
> diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> index 242c43e..b3900cf 100644
> --- a/drivers/ata/libata-scsi.c
> +++ b/drivers/ata/libata-scsi.c
> @@ -1050,14 +1050,15 @@ static unsigned int ata_scsi_flush_xlat(struct
> ata_queued_cmd *qc)
> static void scsi_6_lba_len(const u8 *cdb, u64 *plba, u32 *plen)
> {
> u64 lba = 0;
> - u32 len = 0;
> + u32 len;
>
> VPRINTK("six-byte command\n");
>
> + lba |= ((u64)(cdb[1] & 0x1f)) << 16;
> lba |= ((u64)cdb[2]) << 8;
> lba |= ((u64)cdb[3]);
>
> - len |= ((u32)cdb[4]);
> + len = cdb[4];
>
> *plba = lba;
> *plen = len;
Oops, I overlooked the MSB bits. :(
Thanks for catching this.
--
albert
-
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
Re: [git patches] libata fixes
Mikael Pettersson wrote:
On Fri, 25 May 2007 18:03:07 -0400, Jeff Garzik wrote:
Jeff Garzik (4):
[libata] sata_promise: fix flags typo
...
--- a/drivers/ata/sata_promise.c
+++ b/drivers/ata/sata_promise.c
@@ -297,7 +297,7 @@ static const struct ata_port_info pdc_port_info[] = {
/* board_2057x_pata */
{
- .flags = PDC_COMMON_FLAGS | ATA_FLAG_SLAVE_POSS,
+ .flags = PDC_COMMON_FLAGS | ATA_FLAG_SLAVE_POSS |
PDC_FLAG_GEN_II,
.pio_mask = 0x1f, /* pio0-4 */
.mwdma_mask = 0x07, /* mwdma0-2 */
Acked-by: Mikael Pettersson <[EMAIL PROTECTED]>
Good catch. This typo would have prevented pdc_host_intr()
from detecting GEN_II-specific errors on the PATA port.
Oops -- I should have credited Al Viro for the catch, in the changelog.
This email hereby corrects the record :)
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
Re: [git patches] libata fixes
On Fri, 25 May 2007 18:03:07 -0400, Jeff Garzik wrote:
>Jeff Garzik (4):
> [libata] sata_promise: fix flags typo
...
>--- a/drivers/ata/sata_promise.c
>+++ b/drivers/ata/sata_promise.c
>@@ -297,7 +297,7 @@ static const struct ata_port_info pdc_port_info[] = {
>
> /* board_2057x_pata */
> {
>- .flags = PDC_COMMON_FLAGS | ATA_FLAG_SLAVE_POSS,
>+ .flags = PDC_COMMON_FLAGS | ATA_FLAG_SLAVE_POSS |
> PDC_FLAG_GEN_II,
> .pio_mask = 0x1f, /* pio0-4 */
> .mwdma_mask = 0x07, /* mwdma0-2 */
Acked-by: Mikael Pettersson <[EMAIL PROTECTED]>
Good catch. This typo would have prevented pdc_host_intr()
from detecting GEN_II-specific errors on the PATA port.
-
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
Re: [git patches] libata fixes
Andrew Morton wrote: > > There is another metric to look at, too: the number of fixes which are > going into 2.6.x.y. If that fix count is high, and if those fixes fix bugs > which were not present in 2.6.x-1 then this is an indication that something > is wrong - many regressions are sneaking through the -rc process. > > And I haven't run the numbers, but I get the impression that 2.6.20.x has > an unusually large number of fixes in it. That could be because people are getting better at actually fixing bugs in the previous release. :) - 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
Re: [git patches] libata fixes
On Wed, 28 Mar 2007 13:53:10 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Wed, 28 Mar 2007, Jeff Garzik wrote: > > > > Jeff Garzik wrote: > > > This disables libata ACPI, among other things. > > > > If a -rc6 is possible, that would be quite nice... > > Heh. I don't think -rc6 is "possible" - it's "inevitable". We have too > much fallout from the timer changes still outstanding. It looks people > finally figured out a big issue with the HPET timer, and that hopefully > resolves most of the remaining timer-related regressions, but yes, we most > definitely _will_ have an -rc6. yup. > Andrew, what's your feeling apart from the timer fallout? There are two main metrics: a) the number of bugs which Adrian is tracking. I think this still exceeds 25, which is a lot. b) the rate at which fixes are arriving. I have accumulated 15-20 since the last batch (40 hours ago), which is still a pretty high rate. Based on that, we're still quite a long way from -final. (But you know me - I'd be happy releasing 2.6.21 in July) (Don't ask me what year I'm referring to, either) There is another metric to look at, too: the number of fixes which are going into 2.6.x.y. If that fix count is high, and if those fixes fix bugs which were not present in 2.6.x-1 then this is an indication that something is wrong - many regressions are sneaking through the -rc process. And I haven't run the numbers, but I get the impression that 2.6.20.x has an unusually large number of fixes in it. - 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
Re: [git patches] libata fixes
On Wed, 28 Mar 2007, Jeff Garzik wrote: > > Jeff Garzik wrote: > > This disables libata ACPI, among other things. > > If a -rc6 is possible, that would be quite nice... Heh. I don't think -rc6 is "possible" - it's "inevitable". We have too much fallout from the timer changes still outstanding. It looks people finally figured out a big issue with the HPET timer, and that hopefully resolves most of the remaining timer-related regressions, but yes, we most definitely _will_ have an -rc6. Andrew, what's your feeling apart from the timer fallout? Linus - 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
Re: [git patches] libata fixes
Jeff Garzik wrote: This disables libata ACPI, among other things. If a -rc6 is possible, that would be quite nice... 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
Re: [git patches] libata fixes
On Mon, Mar 19, 2007 at 08:48:00AM +0100, Paul Rolland wrote: > Would you agree to a patch to add a kernel boot parameter to skip some > ata ports ? It should in theory not be neccessary > I found some archives refering to some "ataX=noprobe", but it seems > to have no effect, and I'd like to resurrect it for libata, at least to > help me support my configuration ? > If no, I'll just cook it for me, without posting it... If you get it working please post patches - theory and practice rarely agree 8) - 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
Re: [git patches] libata fixes
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 have no effect, and I'd like to resurrect it for libata, at least to help me support my configuration ? If no, I'll just cook it for me, without posting it... Why not cook it and share it? :-) -- 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
RE: [git patches] libata fixes
> 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 have no effect, and I'd like to resurrect it for libata, at least to help me support my configuration ? If no, I'll just cook it for me, without posting it... Regards, Paul - 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
Re: [git patches] libata fixes
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 0xc208e900 ctl 0x bmdma > 0x irq 504 > ata2: SATA max UDMA/133 cmd 0xc208e980 ctl 0x bmdma > 0x irq 504 > ata3: SATA max UDMA/133 cmd 0xc208ea00 ctl 0x bmdma > 0x irq 504 > ata4: SATA max UDMA/133 cmd 0xc208ea80 ctl 0x bmdma > 0x irq 504 > ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > ata2.00: ATA-6: External Disk 0, RGL10364, max UDMA/133 > ata2.00: 1 sectors, multi 1: LBA48 > ata2.00: configured for UDMA/133 [--snip--] > scsi 1:0:0:0: Direct-Access ATA External Disk 0 RGL1 PQ: 0 ANSI: 5 > SCSI device sdb: 1 512-byte hdwr sectors (0 MB) > sdb: Write Protect is off > SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support > DPO or FUA > SCSI device sdb: 1 512-byte hdwr sectors (0 MB) > sdb: Write Protect is off > SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support > DPO or FUA > sdb:<3>irq 504: nobody cared (try booting with the "irqpoll" option) > > Call Trace: >[] __report_bad_irq+0x35/0x90 > [] note_interrupt+0x21a/0x270 > [] handle_edge_irq+0x10f/0x150 > [] do_IRQ+0x7b/0xf0 > [] mwait_idle+0x0/0x50 > [] ret_from_intr+0x0/0xa >[] vgacon_cursor+0x0/0x1d0 > [] mwait_idle+0x46/0x50 > [] cpu_idle+0x5c/0xa0 > [] start_kernel+0x2aa/0x2c0 > [] _sinittext+0x176/0x180 > > handlers: > [] (ahci_interrupt+0x0/0x590) > Disabling IRQ #504 > unknown partition table > sd 1:0:0:0: Attached scsi disk sdb > sd 1:0:0:0: Attached scsi generic sg1 type 0 > scsi 2:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 > SCSI device sdc: 490234752 512-byte hdwr sectors (251000 MB) > sdc: Write Protect is off > > > and though it said : > sdb:<3>irq 504: nobody cared (try booting with the "irqpoll" option) > I _am_ booting with the irqpoll option ! Oh... that's just weird. It seems you'll have to continue boot with the timeouts for the time being. Sorry about that. -- 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
RE: [git patches] libata fixes
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 0xc208e900 ctl 0x bmdma 0x irq 504 ata2: SATA max UDMA/133 cmd 0xc208e980 ctl 0x bmdma 0x irq 504 ata3: SATA max UDMA/133 cmd 0xc208ea00 ctl 0x bmdma 0x irq 504 ata4: SATA max UDMA/133 cmd 0xc208ea80 ctl 0x bmdma 0x irq 504 scsi0 : ahci 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 NCQ (not used) ata1.00: configured for UDMA/133 scsi1 : ahci ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: ATA-6: External Disk 0, RGL10364, max UDMA/133 ata2.00: 1 sectors, multi 1: LBA48 ata2.00: configured for UDMA/133 scsi2 : ahci ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 ata3.00: 490234752 sectors, multi 0: LBA48 NCQ (not used) ata3.00: configured for UDMA/133 scsi3 : ahci ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata4.00: ATA-7: ST3500641AS, 3.AAB, max UDMA/133 ata4.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32) ata4.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sd 0:0:0:0: Attached scsi disk sda sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: Direct-Access ATA External Disk 0 RGL1 PQ: 0 ANSI: 5 SCSI device sdb: 1 512-byte hdwr sectors (0 MB) sdb: Write Protect is off SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdb: 1 512-byte hdwr sectors (0 MB) sdb: Write Protect is off SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb:<3>irq 504: nobody cared (try booting with the "irqpoll" option) Call Trace: [] __report_bad_irq+0x35/0x90 [] note_interrupt+0x21a/0x270 [] handle_edge_irq+0x10f/0x150 [] do_IRQ+0x7b/0xf0 [] mwait_idle+0x0/0x50 [] ret_from_intr+0x0/0xa [] vgacon_cursor+0x0/0x1d0 [] mwait_idle+0x46/0x50 [] cpu_idle+0x5c/0xa0 [] start_kernel+0x2aa/0x2c0 [] _sinittext+0x176/0x180 handlers: [] (ahci_interrupt+0x0/0x590) Disabling IRQ #504 unknown partition table sd 1:0:0:0: Attached scsi disk sdb sd 1:0:0:0: Attached scsi generic sg1 type 0 scsi 2:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 SCSI device sdc: 490234752 512-byte hdwr sectors (251000 MB) sdc: Write Protect is off and though it said : sdb:<3>irq 504: nobody cared (try booting with the "irqpoll" option) I _am_ booting with the irqpoll option ! Paul - 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
RE: [git patches] libata fixes
Hi, > This is NCQ protocol violation on the drive's side shown on some early > drives. No need to worry too much about it. The drive will just get > blacklisted for NCQ and should work fine. > Thx. Also, remember one of the problem I have, with ata2 going to timeout because this port of the ICH7 is connected to a PMT ? You suggested me to connect a disk to one of the SATA port of the PMT, and reboot the machine to see if the timeout would vanish... I've just done it, and here is the relevant part of the boot log : 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 0xc208e900 ctl 0x bmdma 0x irq 504 ata2: SATA max UDMA/133 cmd 0xc208e980 ctl 0x bmdma 0x irq 504 ata3: SATA max UDMA/133 cmd 0xc208ea00 ctl 0x bmdma 0x irq 504 ata4: SATA max UDMA/133 cmd 0xc208ea80 ctl 0x bmdma 0x irq 504 scsi0 : ahci 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 NCQ (not used) ata1.00: configured for UDMA/133 scsi1 : ahci ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: ATA-6: External Disk 0, RGL10364, max UDMA/133 ata2.00: 1 sectors, multi 1: LBA48 ata2.00: configured for UDMA/133 scsi2 : ahci ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 ata3.00: 490234752 sectors, multi 0: LBA48 NCQ (not used) ata3.00: configured for UDMA/133 scsi3 : ahci ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata4.00: ATA-7: ST3500641AS, 3.AAB, max UDMA/133 ata4.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32) ata4.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sd 0:0:0:0: Attached scsi disk sda sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: Direct-Access ATA External Disk 0 RGL1 PQ: 0 ANSI: 5 SCSI device sdb: 1 512-byte hdwr sectors (0 MB) sdb: Write Protect is off SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdb: 1 512-byte hdwr sectors (0 MB) sdb: Write Protect is off SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: unknown partition table sd 1:0:0:0: Attached scsi disk sdb sd 1:0:0:0: Attached scsi generic sg1 type 0 scsi 2:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 SCSI device sdc: 490234752 512-byte hdwr sectors (251000 MB) sdc: Write Protect is off SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdc: 490234752 512-byte hdwr sectors (251000 MB) sdc: Write Protect is off SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sdc2 sd 2:0:0:0: Attached scsi disk sdc sd 2:0:0:0: Attached scsi generic sg2 type 0 scsi 3:0:0:0: Direct-Access ATA ST3500641AS 3.AA PQ: 0 ANSI: 5 SCSI device sdd: 976773168 512-byte hdwr sectors (500108 MB) sdd: Write Protect is off SCSI device sdd: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdd: 976773168 512-byte hdwr sectors (500108 MB) sdd: Write Protect is off SCSI device sdd: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdd: sdd1 sdd2 sdd3 sd 3:0:0:0: Attached scsi disk sdd sd 3:0:0:0: Attached scsi generic sg3 type 0 ACPI: PCI Interrupt :02:00.0[A] -> GSI 17 (level, low) -> IRQ 17 ahci :02:00.0: AHCI 0001. 32 slots 2 ports 3 Gbps 0x3 impl SATA mode ahci :02:00.0: flags: 64bit ncq pm led clo pmp pio slum part ... The good news is that there is no more timeout, which is excellent ! The bad news is that the disk is not detected... but maybe I should do something in the BIOS configuration. I'll try to have a look at this, because connecting a disk to avoid TO without being able to use it is not that good ;) Regards, Paul - 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
Re: [git patches] libata fixes
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 the SCSI >> prints revalidation messages, but it's still only three errors. >> >> Thanks for verifying that. I wanted to verify it works in >> the field as expected. > > Glad to help ! > > Anyhow, how should I consider these "errors" ? Are they real failure that > can affect data integrity on the disk, or some kind of "protocol" errors > with the disk, that are covered by soft (retry or so), and don't affect > data ? This is NCQ protocol violation on the drive's side shown on some early drives. No need to worry too much about it. The drive will just get blacklisted for NCQ and should work fine. -- 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
RE: [git patches] libata fixes
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 the SCSI > prints revalidation messages, but it's still only three errors. > > Thanks for verifying that. I wanted to verify it works in > the field as expected. Glad to help ! Anyhow, how should I consider these "errors" ? Are they real failure that can affect data integrity on the disk, or some kind of "protocol" errors with the disk, that are covered by soft (retry or so), and don't affect data ? Regards, Paul - 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
Re: [git patches] libata fixes
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 "."; done > > After several minutes (I waited more than 300 loops to be completed), and > a lot of errors, I finally managed to see : > Mar 18 10:32:47 riri kernel: ata1.00: NCQ disabled due to excessive errors > > Mar 18 10:23:26 riri kernel: res 40/00:58:53:6e:31/00:00:0d:00:00/40 > Emask 0x2 (HSM violation) > Mar 18 10:25:07 riri kernel: res 40/00:d8:db:b0:2e/00:00:0d:00:00/40 > Emask 0x2 (HSM violation) > Mar 18 10:32:42 riri kernel: res 40/00:c0:7b:6a:2a/00:00:0d:00:00/40 > Em > ask 0x2 (HSM violation) > Mar 18 10:32:47 riri kernel: ata1.00: NCQ disabled due to excessive errors > Mar 18 10:32:47 riri kernel: res 40/00:b8:63:0d:2d/00:00:0d:00:00/40 > Em > ask 0x2 (HSM violation) > > Is this what you were expecting ? 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 the SCSI prints revalidation messages, but it's still only three errors. Thanks for verifying that. I wanted to verify it works in the field as expected. -- 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
RE: [git patches] libata fixes
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 "."; done After several minutes (I waited more than 300 loops to be completed), and a lot of errors, I finally managed to see : Mar 18 10:32:47 riri kernel: ata1.00: NCQ disabled due to excessive errors /var/log/messages contains : Mar 18 10:15:04 riri syslogd 1.4.1#17ubuntu7: restart. Mar 18 10:15:04 riri kernel: Inspecting /boot/System.map-2.6.21-rc4 Mar 18 10:15:04 riri kernel: Loaded 39327 symbols from /boot/System.map-2.6.21-rc4. Mar 18 10:15:04 riri kernel: Symbols match kernel version 2.6.21. Mar 18 10:15:04 riri kernel: No module symbols loaded - kernel modules not enabled. Mar 18 10:15:04 riri kernel: Linux version 2.6.21-rc4 ([EMAIL PROTECTED]) (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) #1 SMP PREEMPT Sat Mar 17 18:50:10 CET 2007 Mar 18 10:15:04 riri kernel: Command line: root=/dev/sde1 ro ata2=noprobe console=ttyS0,9600 console=tty0 vga=extended irqpoll Mar 18 10:15:04 riri kernel: BIOS-provided physical RAM map: Mar 18 10:15:04 riri kernel: BIOS-e820: - 0009fc00 (usable) Mar 18 10:15:04 riri kernel: BIOS-e820: 0009fc00 - 000a (reserved) Mar 18 10:15:04 riri kernel: BIOS-e820: 000e4000 - 0010 (reserved) Mar 18 10:15:04 riri kernel: BIOS-e820: 0010 - c7f8 (usable) Mar 18 10:15:04 riri kernel: BIOS-e820: c7f8 - c7f8e000 (ACPI data) Mar 18 10:15:04 riri kernel: BIOS-e820: c7f8e000 - c7fe (ACPI NVS) Mar 18 10:15:04 riri kernel: BIOS-e820: c7fe - c800 (reserved) Mar 18 10:15:04 riri kernel: BIOS-e820: ffb0 - 0001 (reserved) Mar 18 10:15:04 riri kernel: end_pfn_map = 1048576 Mar 18 10:15:04 riri kernel: DMI 2.4 present. Mar 18 10:15:04 riri kernel: ACPI: RSDP 000FAF20, 0024 (r2 ACPIAM) Mar 18 10:15:04 riri kernel: ACPI: XSDT C7F80100, 005C (r1 A_M_I_ OEMXSDT 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: FACP C7F80290, 00F4 (r3 A_M_I_ OEMFACP 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: DSDT C7F80410, 8FC4 (r1 A0543 A0543000 0 INTL 20060113) Mar 18 10:15:04 riri kernel: ACPI: FACS C7F8E000, 0040 Mar 18 10:15:04 riri kernel: ACPI: APIC C7F80390, 0080 (r1 A_M_I_ OEMAPIC 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: OEMB C7F8E040, 0066 (r1 A_M_I_ AMI_OEM 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: HPET C7F893E0, 0038 (r1 A_M_I_ OEMHPET 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: MCFG C7F89420, 003C (r1 A_M_I_ OEMMCFG 12000608 MSFT 97) Mar 18 10:15:04 riri kernel: ACPI: SSDT C7F8E0B0, 01C6 (r1AMI CPU1PM 1 INTL 20060113) Mar 18 10:15:04 riri kernel: ACPI: SSDT C7F8E280, 013A (r1AMI CPU2PM 1 INTL 20060113) Mar 18 10:15:04 riri kernel: Zone PFN ranges: Mar 18 10:15:04 riri kernel: DMA 0 -> 4096 Mar 18 10:15:04 riri kernel: DMA324096 -> 1048576 Mar 18 10:15:04 riri kernel: Normal1048576 -> 1048576 Mar 18 10:15:04 riri kernel: early_node_map[2] active PFN ranges Mar 18 10:15:04 riri kernel: 0:0 -> 159 Mar 18 10:15:04 riri kernel: 0: 256 -> 819072 Mar 18 10:15:04 riri kernel: ACPI: PM-Timer IO Port: 0x808 Mar 18 10:15:04 riri kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Mar 18 10:15:04 riri kernel: Processor #0 (Bootup-CPU) Mar 18 10:15:04 riri kernel: ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Mar 18 10:15:04 riri kernel: Processor #1 Mar 18 10:15:04 riri kernel: ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) Mar 18 10:15:04 riri kernel: ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) Mar 18 10:15:04 riri kernel: ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) Mar 18 10:15:04 riri kernel: IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 Mar 18 10:15:04 riri kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) Mar 18 10:15:04 riri kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Mar 18 10:15:04 riri kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) Mar 18 10:15:04 riri kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Mar 18 10:15:04 riri kernel: Setting APIC routing to flat Mar 18 10:15:04 riri kernel: ACPI: HPET id: 0x8086a201 base: 0xfed0 Mar 18 10:15:04 riri kernel: Using ACPI (MADT) for SMP configuration information Mar 18 10:15:04 riri kernel: Nosave address range: 0009f000 - 000a Mar 18 10:15:04 riri kernel: Nosave address range: 000a - 000e4000 Mar 18 10:15:04 riri kernel: Nosave address range: 000e4000 - 0010 Mar 18 10:15:04 riri kernel: Allocating PCI resources starting at cc00 (gap: c800:37b0) Mar 18 10:15:04 riri k
Re: [git patches] libata fixes
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 harddisk under high load and see what happens? How often do those errors occur? Care to post full dmesg? -- 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
RE: [git patches] libata fixes
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... Paul - 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
Re: [git patches] libata fixes
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 I can check for that would indicate NCQ being turned > off ? The kernel says that NCQ is turned off due to excessive errors. If your HSM violation is intermittent, it might not trigger tho. -- 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
Re: [git patches] libata fixes
> > >
> > >
> > > Signed-off-by: Paul Rolland <[EMAIL PROTECTED]>
> >
> > NAK - but add the firmware to the match and you can have an Ack 8)
>
> Second try, compiled _and_ boot tested, of course.
>
> dmesg says :
> 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 NCQ (not used)
> ata1.00: configured for UDMA/133
>
> --- linux-2.6.21-rc4/drivers/ata/libata-core.c 2007-03-17 19:47:49.0
> +0100
> +++ linux-2.6.21-rc4-Maxtor/drivers/ata/libata-core.c 2007-03-17
> 20:24:01.0 +0100
> @@ -3359,6 +3359,8 @@
> { "WDC WD740ADFD-00", NULL, ATA_HORKAGE_NONCQ },
> /* http://thread.gmane.org/gmane.linux.ide/14907 */
> { "FUJITSU MHT2060BH", NULL, ATA_HORKAGE_NONCQ },
> + /* NCQ is broken */
> + { "Maxtor 6L250S0", "BANC1G10", ATA_HORKAGE_NONCQ },
>
> /* Devices with NCQ limits */
>
> Signed-off-by: Paul Rolland <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
--
'YKYHBRTFDriverSTLW: you catch yourself saying "enough horrors for today"
and picking Lovecraft to relax...' -- Al Viro
-
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
RE: [git patches] libata fixes
> 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 I can check for that would indicate NCQ being turned off ? Regards, Paul - 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
Re: [git patches] libata fixes
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 NCQ (depth 31/32) > ata1.00: configured for UDMA/133 > ... > Adding 2096436k swap on /dev/sde5. Priority:-1 extents:1 across:2096436k > Adding 4192956k swap on /dev/sda3. Priority:-2 extents:1 across:4192956k > ata1.00: exception Emask 0x2 SAct 0x7fc3 SErr 0x0 action 0x2 frozen > ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x7fc3 > FIS=004040a1:0020) > ata1.00: cmd 60/01:00:52:eb:ff/00:00:09:00:00/40 tag 0 cdb 0x0 data 512 in > res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2 (HSM violation) If you leave it alone, does libata turn off NCQ and boot continues? -- 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
RE: [git patches] libata fixes
Hello,
> Please match the firmware version as well for the Maxtor drives
Ok.
> > --- linux-2.6.21-rc4/drivers/ata/libata-core.c 2007-03-17
> 19:29:45.0
> > +0100
> > +++ linux-2.6.21-rc4-Maxtor/drivers/ata/libata-core.c 2007-03-17
> > 19:37:28.0 +0100
> > @@ -3359,6 +3359,8 @@
> > { "WDC WD740ADFD-00", NULL, ATA_HORKAGE_NONCQ },
> > /* http://thread.gmane.org/gmane.linux.ide/14907 */
> > { "FUJITSU MHT2060BH", NULL, ATA_HORKAGE_NONCQ },
> > + /* NCQ is broken */
> > + { "Maxtor 6L250S0", NULL,
> ATA_HORKAGE_NONCQ },
> >
> > /* Devices with NCQ limits */
> >
> >
> > Signed-off-by: Paul Rolland <[EMAIL PROTECTED]>
>
> NAK - but add the firmware to the match and you can have an Ack 8)
Second try, compiled _and_ boot tested, of course.
dmesg says :
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 NCQ (not used)
ata1.00: configured for UDMA/133
--- linux-2.6.21-rc4/drivers/ata/libata-core.c 2007-03-17 19:47:49.0
+0100
+++ linux-2.6.21-rc4-Maxtor/drivers/ata/libata-core.c 2007-03-17
20:24:01.0 +0100
@@ -3359,6 +3359,8 @@
{ "WDC WD740ADFD-00", NULL, ATA_HORKAGE_NONCQ },
/* http://thread.gmane.org/gmane.linux.ide/14907 */
{ "FUJITSU MHT2060BH", NULL, ATA_HORKAGE_NONCQ },
+ /* NCQ is broken */
+ { "Maxtor 6L250S0", "BANC1G10", ATA_HORKAGE_NONCQ },
/* Devices with NCQ limits */
Signed-off-by: Paul Rolland <[EMAIL PROTECTED]>
Regards,
Paul
-
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
Re: [git patches] libata fixes
On Sat, Mar 17, 2007 at 07:47:01PM +0100, Paul Rolland wrote:
> Hello,
>
> Here is a patch to avoid these pesky messages for the Maxtor disk :
>
Please match the firmware version as well for the Maxtor drives
> --- linux-2.6.21-rc4/drivers/ata/libata-core.c 2007-03-17 19:29:45.0
> +0100
> +++ linux-2.6.21-rc4-Maxtor/drivers/ata/libata-core.c 2007-03-17
> 19:37:28.0 +0100
> @@ -3359,6 +3359,8 @@
> { "WDC WD740ADFD-00", NULL, ATA_HORKAGE_NONCQ },
> /* http://thread.gmane.org/gmane.linux.ide/14907 */
> { "FUJITSU MHT2060BH", NULL, ATA_HORKAGE_NONCQ },
> + /* NCQ is broken */
> + { "Maxtor 6L250S0", NULL, ATA_HORKAGE_NONCQ },
>
> /* Devices with NCQ limits */
>
>
> Signed-off-by: Paul Rolland <[EMAIL PROTECTED]>
NAK - but add the firmware to the match and you can have an Ack 8)
-
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
RE: [git patches] libata fixes
Hello,
Here is a patch to avoid these pesky messages for the Maxtor disk :
--- linux-2.6.21-rc4/drivers/ata/libata-core.c 2007-03-17 19:29:45.0
+0100
+++ linux-2.6.21-rc4-Maxtor/drivers/ata/libata-core.c 2007-03-17
19:37:28.0 +0100
@@ -3359,6 +3359,8 @@
{ "WDC WD740ADFD-00", NULL, ATA_HORKAGE_NONCQ },
/* http://thread.gmane.org/gmane.linux.ide/14907 */
{ "FUJITSU MHT2060BH", NULL, ATA_HORKAGE_NONCQ },
+ /* NCQ is broken */
+ { "Maxtor 6L250S0", NULL, ATA_HORKAGE_NONCQ },
/* Devices with NCQ limits */
Signed-off-by: Paul Rolland <[EMAIL PROTECTED]>
With this applied, my machine has stopped all those painful messages.
dmesg now says :
[EMAIL PROTECTED]:/Kernels# dmesg | grep LBA
ata1.00: 490234752 sectors, multi 0: LBA48 NCQ (not used)
ata2.00: 640 sectors, multi 1: LBA
ata3.00: 490234752 sectors, multi 0: LBA48 NCQ (not used)
instead of NCQ (depth 31/32), but there doesn't seem to be any adverse
effects.
Regards,
Paul
Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator
--
Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur
"Some people dream of success... while others wake up and work hard at it"
"I worry about my child and the Internet all the time, even though she's too
young to have logged on yet. Here's what I worry about. I worry that 10 or 15
years from now, she will come to me and say 'Daddy, where were you when they
took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul Rolland
> Sent: Saturday, March 17, 2007 6:59 PM
> To: 'Tejun Heo'
> Cc: 'Linus Torvalds'; 'Jeff Garzik'; 'Alan Cox'; 'Andrew
> Morton'; [email protected]; 'LKML'; 'Eric D. Mudama'
> Subject: RE: [git patches] libata fixes
>
> 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 NCQ (depth 31/32)
> ata1.00: configured for UDMA/133
> ...
> Adding 2096436k swap on /dev/sde5. Priority:-1 extents:1
> across:2096436k
> Adding 4192956k swap on /dev/sda3. Priority:-2 extents:1
> across:4192956k
> ata1.00: exception Emask 0x2 SAct 0x7fc3 SErr 0x0 action
> 0x2 frozen
> ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x7fc3
> FIS=004040a1:0020)
> ata1.00: cmd 60/01:00:52:eb:ff/00:00:09:00:00/40 tag 0 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/40:08:53:eb:ff/00:00:09:00:00/40 tag 1 cdb
> 0x0 data 32768 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:30:39:eb:ff/00:00:09:00:00/40 tag 6 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:38:3a:eb:ff/00:00:09:00:00/40 tag 7 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:40:3b:eb:ff/00:00:09:00:00/40 tag 8 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:48:3c:eb:ff/00:00:09:00:00/40 tag 9 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:50:3d:eb:ff/00:00:09:00:00/40 tag 10 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:58:3e:eb:ff/00:00:09:00:00/40 tag 11 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:60:3f:eb:ff/00:00:09:00:00/40 tag 12 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:68:40:eb:ff/00:00:09:00:00/40 tag 13 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:70:41:eb:ff/00:00:09:00:00/40 tag 14 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:78:42:eb:ff/00:00:09:00:00/40 tag 15 cdb
> 0x0 data 512 in
> res 40/00:08:53:eb:ff/00:00:09:00:00/40 Emask 0x2
> (HSM violation)
> ata1.00: cmd 60/01:
Re: [git patches] libata fixes
On Sat, Mar 17, 2007 at 06:59:12PM +0100, Paul Rolland wrote: > ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > ata1.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 That drive isn't in our current block list for NCQ but some close relatives are in the one I've compiled so far (7B250S0). If you add it to the blacklist it behave ? Also what controller ? - 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
RE: [git patches] libata fixes
ministrator and Peering Coordinator -- Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tejun Heo > Sent: Monday, March 12, 2007 9:05 AM > To: [EMAIL PROTECTED] > Cc: 'Linus Torvalds'; 'Jeff Garzik'; 'Alan Cox'; 'Andrew > Morton'; [email protected]; 'LKML'; 'Eric D. Mudama' > Subject: Re: [git patches] libata fixes > > 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 report whether that works. > > -- > tejun > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - 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
RE: [git patches] libata fixes
> > PS : I'd like to try 2.6.21-rc3, but it seems that this is > breaking my > > config : disk naming is no more the same, and I end up with a panic > > Warning: unable to open an initial console > > though i've been compiling with the same .config I was > using for 2.6.21-rc2 > > Gaah. Can you get a log through serial console or netconsole > to see what changed? > Sorry, I've had no time this week for that. I've just switch to 2.6.21-rc4, and carefully restored config from 2.6.21-rc2, and boot is Ok... So, I must have done something bad when building 2.6.21-rc3, sorry for the noise. Regards, Paul - 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
RE: [git patches] libata fixes
Hello, > > That sounds a quite expensive solution ;) > > You should be able to just move the drive attached at ata1 to ata2. > Please report whether that works. I'll try to find an unused disk... As I said, these ports are part of Asus EZRaid solution, and i'd prefer this piece of code not to try to write anything on the disk ;) ... but I should find a disk without too much problem. Paul - 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
Re: [git patches] libata fixes
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 report whether that works. -- 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
RE: [git patches] libata fixes
Hello, > It involves a long timeout, so it's bothersome. This is caused by > Silicon Image 4726/3726 storage processor (SATA Port Multiplier with > extra features) attached to one of the ICH ports. Yes, I think this is the part Asus is using for it's EZ-Raid feature on this motherboard, and they seem to like their EZ-Raid, so it's likely to become more and more common. > If the first downstream port in the PMP is empty and it gets reset in I confirm it is empty in my config. > work very well with the current ATA reset sequence and gets identified > only after a few failures thus causing long timeout. 30s to 1min ;( > 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 ;) Paul - 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
RE: [git patches] libata fixes
Hello, > Ok, so that's just a message irritation, not actually bothersome > otherwise? It is somewhat painful, because delays involved are quite long, and it is not possible to explain the machine to "ignore" the port, and skip to the next one... > > The second problem is a Jmicron363 controler that is > failing to detect > > the DVD-RW that is connected, unless I use the irqpoll > option as Tejun has > > suggested. > > .. and this one has never worked without irqpoll? Exactly. > So it's the irq16 one that is the Jmicron controller and just isn't > getting any interrupts? It's IRQ 16 that is reported as affected to the Jmicron from the dmesg output, yes. > Since all the other interrupts work (and MSI worked for other > controllers), I don't think it's interrupt-routing related. > Especially as MSI shouldn't even care about things like that. > > And since it all works when "irqpoll" is used, that implies that the > *only* thing that is broken is literally irq delivery. Surely, also if you add the using pci=nomsi doesn't change anything. > Gaah. Can you get a log through serial console or netconsole > to see what changed? I'll try to do that Regards, Paul - 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
Re: [git patches] libata fixes
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 of the ICH7 >>> (at least, it seems to), and probing it goes timeout, but nothing is >>> connected on it. >> Ok, so that's just a message irritation, not actually bothersome >> otherwise? > > It involves a long timeout, so it's bothersome. This is caused by > Silicon Image 4726/3726 storage processor (SATA Port Multiplier with > extra features) attached to one of the ICH ports. > > If the first downstream port in the PMP is empty and it gets reset in > non-PMP way, it identifies itself as "Config Disk" of quite small size. > It's probably used to configure the extra features using standard ATA > RW commands. Anyways, this "Config Disk" is a bit peculiar and doesn't > work very well with the current ATA reset sequence and gets identified > only after a few failures thus causing long timeout. > > 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. > >>> The second problem is a Jmicron363 controler that is failing to detect >>> the DVD-RW that is connected, unless I use the irqpoll option as Tejun has >>> suggested. >> .. and this one has never worked without irqpoll? >> >>> But, as you suggest it, I'm adding pci=nomsi to the command line >>> rebooting... no change for this part of the problem. >>> >>> OK, the /proc/interrupt for this config, and the dmesg attached. >>> >>> 3 [23:22] [EMAIL PROTECTED]:~> cat /proc/interrupts >>>CPU0 CPU1 >>> 0: 297549 0 IO-APIC-edge timer >>> 1: 7 0 IO-APIC-edge i8042 >>> 4: 13 0 IO-APIC-edge serial >>> 6: 5 0 IO-APIC-edge floppy >>> 8: 1 0 IO-APIC-edge rtc >>> 9: 0 0 IO-APIC-fasteoi acpi >>> 12:126 0 IO-APIC-edge i8042 >>> 14: 8313 0 IO-APIC-edge libata >>> 15: 0 0 IO-APIC-edge libata >>> 16: 0 0 IO-APIC-fasteoi eth1, libata >> So it's the irq16 one that is the Jmicron controller and just isn't >> getting any interrupts? >> >> Since all the other interrupts work (and MSI worked for other >> controllers), I don't think it's interrupt-routing related. Especially as >> MSI shouldn't even care about things like that. >> >> And since it all works when "irqpoll" is used, that implies that the >> *only* thing that is broken is literally irq delivery. >> >> Is there possibly some jmicron-specific "enable interrupts" bit? > > (cc'ing Justin of JMicron. Hello, please correct me if I'm wrong.) > > Not that I know of. The PATA portion of JMB controllers is bog standard > PCI BMDMA ATA device where ATA_NIEN is the way to turn IRQ on and off. > > Thanks. > -- 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
Re: [git patches] libata fixes
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 >> connected on it. > > Ok, so that's just a message irritation, not actually bothersome > otherwise? It involves a long timeout, so it's bothersome. This is caused by Silicon Image 4726/3726 storage processor (SATA Port Multiplier with extra features) attached to one of the ICH ports. If the first downstream port in the PMP is empty and it gets reset in non-PMP way, it identifies itself as "Config Disk" of quite small size. It's probably used to configure the extra features using standard ATA RW commands. Anyways, this "Config Disk" is a bit peculiar and doesn't work very well with the current ATA reset sequence and gets identified only after a few failures thus causing long timeout. 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. >> The second problem is a Jmicron363 controler that is failing to detect >> the DVD-RW that is connected, unless I use the irqpoll option as Tejun has >> suggested. > > .. and this one has never worked without irqpoll? > >> But, as you suggest it, I'm adding pci=nomsi to the command line >> rebooting... no change for this part of the problem. >> >> OK, the /proc/interrupt for this config, and the dmesg attached. >> >> 3 [23:22] [EMAIL PROTECTED]:~> cat /proc/interrupts >>CPU0 CPU1 >> 0: 297549 0 IO-APIC-edge timer >> 1: 7 0 IO-APIC-edge i8042 >> 4: 13 0 IO-APIC-edge serial >> 6: 5 0 IO-APIC-edge floppy >> 8: 1 0 IO-APIC-edge rtc >> 9: 0 0 IO-APIC-fasteoi acpi >> 12:126 0 IO-APIC-edge i8042 >> 14: 8313 0 IO-APIC-edge libata >> 15: 0 0 IO-APIC-edge libata >> 16: 0 0 IO-APIC-fasteoi eth1, libata > > So it's the irq16 one that is the Jmicron controller and just isn't > getting any interrupts? > > Since all the other interrupts work (and MSI worked for other > controllers), I don't think it's interrupt-routing related. Especially as > MSI shouldn't even care about things like that. > > And since it all works when "irqpoll" is used, that implies that the > *only* thing that is broken is literally irq delivery. > > Is there possibly some jmicron-specific "enable interrupts" bit? (cc'ing Justin of JMicron. Hello, please correct me if I'm wrong.) Not that I know of. The PATA portion of JMB controllers is bog standard PCI BMDMA ATA device where ATA_NIEN is the way to turn IRQ on and off. Thanks. -- 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
RE: [git patches] libata fixes
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 > connected on it. Ok, so that's just a message irritation, not actually bothersome otherwise? > The second problem is a Jmicron363 controler that is failing to detect > the DVD-RW that is connected, unless I use the irqpoll option as Tejun has > suggested. .. and this one has never worked without irqpoll? > But, as you suggest it, I'm adding pci=nomsi to the command line > rebooting... no change for this part of the problem. > > OK, the /proc/interrupt for this config, and the dmesg attached. > > 3 [23:22] [EMAIL PROTECTED]:~> cat /proc/interrupts >CPU0 CPU1 > 0: 297549 0 IO-APIC-edge timer > 1: 7 0 IO-APIC-edge i8042 > 4: 13 0 IO-APIC-edge serial > 6: 5 0 IO-APIC-edge floppy > 8: 1 0 IO-APIC-edge rtc > 9: 0 0 IO-APIC-fasteoi acpi > 12:126 0 IO-APIC-edge i8042 > 14: 8313 0 IO-APIC-edge libata > 15: 0 0 IO-APIC-edge libata > 16: 0 0 IO-APIC-fasteoi eth1, libata So it's the irq16 one that is the Jmicron controller and just isn't getting any interrupts? Since all the other interrupts work (and MSI worked for other controllers), I don't think it's interrupt-routing related. Especially as MSI shouldn't even care about things like that. And since it all works when "irqpoll" is used, that implies that the *only* thing that is broken is literally irq delivery. Is there possibly some jmicron-specific "enable interrupts" bit? > PS : I'd like to try 2.6.21-rc3, but it seems that this is breaking my > config : disk naming is no more the same, and I end up with a panic > Warning: unable to open an initial console > though i've been compiling with the same .config I was using for 2.6.21-rc2 Gaah. Can you get a log through serial console or netconsole to see what changed? Linus - 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
RE: [git patches] libata fixes
Hello, > > Nope... I tried several patches from Tejun, and also some > that Jeff posted > > to linux-ide, but no luck. The only way to have this DVD-RW > working is to > > use irqpoll on the command line... > > So it has *never* worked? That's what I'm trying to see - you had a > "before" and "after" dmesg in one of your posts, and the "before" one > looked fine (as if it was working) because it didn't have the error > messages. > > So I'm just trying to figure out where the regression started... > > > To complete, here are some more output from the machine : > > What happens if you disable MSI entirely? Use "pci=nomsi" on > the command > line. > > The > > ata2.00: qc timeout (cmd 0xec) > ata2.00: failed to IDENTIFY (I/O error, err_mask=0x104) > > messages happen for you on the controller that claims MSI: > > ata2: SATA max UDMA/133 cmd 0xc208a980 ctl > 0x bmdma 0x irq 504 > > and quite frankly, we've had lots of bugs with MSI, both in > hardware and > in software. OK, I see, we are talking about two different problems... 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 connected on it. The second problem is a Jmicron363 controler that is failing to detect the DVD-RW that is connected, unless I use the irqpoll option as Tejun has suggested. >From what I remember, except my initial description of the problem, no attempt has been made yet to workaround/understand the first problem, and all the mails I've exchanged were focused on the second one. But, as you suggest it, I'm adding pci=nomsi to the command line rebooting... no change for this part of the problem. OK, the /proc/interrupt for this config, and the dmesg attached. 3 [23:22] [EMAIL PROTECTED]:~> cat /proc/interrupts CPU0 CPU1 0: 297549 0 IO-APIC-edge timer 1: 7 0 IO-APIC-edge i8042 4: 13 0 IO-APIC-edge serial 6: 5 0 IO-APIC-edge floppy 8: 1 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12:126 0 IO-APIC-edge i8042 14: 8313 0 IO-APIC-edge libata 15: 0 0 IO-APIC-edge libata 16: 0 0 IO-APIC-fasteoi eth1, libata 17: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 18: 6894 0 IO-APIC-fasteoi uhci_hcd:usb4 19:579 0 IO-APIC-fasteoi eth0, uhci_hcd:usb5, HDA Intel 20:104 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2 21: 3 0 IO-APIC-fasteoi ohci1394 23: 7205 0 IO-APIC-fasteoi libata NMI:783540 LOC: 291823 290536 PS : I'd like to try 2.6.21-rc3, but it seems that this is breaking my config : disk naming is no more the same, and I end up with a panic Warning: unable to open an initial console though i've been compiling with the same .config I was using for 2.6.21-rc2 Regards, Paul dmesg-2.6.21-rc2-irqpoll-nomsi Description: Binary data
RE: [git patches] libata fixes
On Sun, 11 Mar 2007, Paul Rolland wrote: > > Nope... I tried several patches from Tejun, and also some that Jeff posted > to linux-ide, but no luck. The only way to have this DVD-RW working is to > use irqpoll on the command line... So it has *never* worked? That's what I'm trying to see - you had a "before" and "after" dmesg in one of your posts, and the "before" one looked fine (as if it was working) because it didn't have the error messages. So I'm just trying to figure out where the regression started... > To complete, here are some more output from the machine : What happens if you disable MSI entirely? Use "pci=nomsi" on the command line. The ata2.00: qc timeout (cmd 0xec) ata2.00: failed to IDENTIFY (I/O error, err_mask=0x104) messages happen for you on the controller that claims MSI: ata2: SATA max UDMA/133 cmd 0xc208a980 ctl 0x bmdma 0x irq 504 and quite frankly, we've had lots of bugs with MSI, both in hardware and in software. Linus - 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
RE: [git patches] libata fixes
Just one point that may be interesting, as it seems that this is IRQ related : at the beginning of the dmesg, it seems that IRQ16 is used for sky2/Yukon , but when reading /proc/interrupts, it has been remapped to IRQ 505... Could this also affect libata ? Regards, Paul Paul Rolland, rol(at)as2917.net ex-AS2917 Network administrator and Peering Coordinator -- Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Paul Rolland > Sent: Sunday, March 11, 2007 7:35 PM > To: 'Linus Torvalds' > Cc: 'Tejun Heo'; 'Jeff Garzik'; 'Andrew Morton'; > [email protected]; 'LKML'; 'Eric D. Mudama' > Subject: RE: [git patches] libata fixes > > Hello, > > > do I understand correctly that the *only* difference between > > the working > > setup is that you applied (by hand) the libata patch that > > Jeff sent out? > > > > So plain 2.6.21-rc2 works fine, but with the patch applied, > > you get no > > interrupts on the DVD drive? > > Nope... I tried several patches from Tejun, and also some > that Jeff posted > to linux-ide, but no luck. The only way to have this DVD-RW > working is to > use irqpoll on the command line... > > Sorry to have been unclear > > To complete, here are some more output from the machine : > - a dmesg without irqpoll, > - a dmesg with irqpoll, > - a copy of /proc/interrupts > 6 [19:33] [EMAIL PROTECTED]:~> cat /proc/interrupts >CPU0 CPU1 > 0: 357022 0 IO-APIC-edge timer > 1: 8 0 IO-APIC-edge i8042 > 4: 14 0 IO-APIC-edge serial > 6: 5 0 IO-APIC-edge floppy > 8: 1 0 IO-APIC-edge rtc > 9: 0 0 IO-APIC-fasteoi acpi > 12:129 0 IO-APIC-edge i8042 > 14: 7639 0 IO-APIC-edge libata > 15: 0 0 IO-APIC-edge libata > 16: 0 0 IO-APIC-fasteoi libata > 17: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 > 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 > 19:204 0 IO-APIC-fasteoi uhci_hcd:usb5, > HDA Intel > 20:107 0 IO-APIC-fasteoi ehci_hcd:usb1, > uhci_hcd:usb2 > 21: 3 0 IO-APIC-fasteoi ohci1394 > 504: 8243 0 PCI-MSI-edge libata > 505: 1 0 PCI-MSI-edge eth1 > 506:386 0 PCI-MSI-edge eth0 > NMI:771531 > LOC: 569318 578684 > ERR: 0 > > Regards, > Paul > - 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
RE: [git patches] libata fixes
Paul, do I understand correctly that the *only* difference between the working setup is that you applied (by hand) the libata patch that Jeff sent out? So plain 2.6.21-rc2 works fine, but with the patch applied, you get no interrupts on the DVD drive? On Sun, 11 Mar 2007, Paul Rolland wrote: > > > It seems like IRQ is not getting through. The first IRQ > > driven command is failing for you. > > H > > Extract is : > > ata7: PATA max UDMA/100 cmd 0x00019c00 ctl 0x00019882 bmdma > > 0x00019400 irq 16 > > ata8: PATA max UDMA/100 cmd 0x00019800 ctl 0x00019482 bmdma > > 0x00019408 irq 16 > > IRQ 16 is IO-APIC-fasteoi for libata, and is not shared... but all the > others libata IRQ are IO-APIC-edge. Ok, that's interesting, although IO-APIC-fasteoi certainly works for others (eg me), but it's still useful. > > * Does giving 'acpi=off' or 'irqpoll' make any difference? > > > > * Can you connect a harddisk to the channel and see whether > > that works? > > Tried that.. Disk is identified as ATA-7: Mastor 6Y080L0, YAR41BW0, max > UDMA/13 and then timeout again... > > Tried then with acpi=off, same result (identify is OK, but then timeout), > and irqpoll and then it was OK Whee... There were no changes that looked interrupt-related there.. Linus - 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
RE: [git patches] libata fixes
Hello, > It seems like IRQ is not getting through. The first IRQ > driven command is failing for you. H > Extract is : > ata7: PATA max UDMA/100 cmd 0x00019c00 ctl 0x00019882 bmdma > 0x00019400 irq 16 > ata8: PATA max UDMA/100 cmd 0x00019800 ctl 0x00019482 bmdma > 0x00019408 irq 16 IRQ 16 is IO-APIC-fasteoi for libata, and is not shared... but all the others libata IRQ are IO-APIC-edge. > * Does giving 'acpi=off' or 'irqpoll' make any difference? > > * Can you connect a harddisk to the channel and see whether > that works? Tried that.. Disk is identified as ATA-7: Mastor 6Y080L0, YAR41BW0, max UDMA/13 and then timeout again... Tried then with acpi=off, same result (identify is OK, but then timeout), and irqpoll and then it was OK Let's then go back to my DVD-RW and test irqpoll... and ... Yes Got it ! It is identified, it can be mounted, and read as /dev/sr1 ! /proc/interrupts show a count of 0 for IRQ 16, so yes, it goes somewhere else... Doing some diffs on copy of /proc/interrupts while accessing the DVD gives two possibilities : IRQ14 or IRQ18, but both are also counting when not accessing the DVD... Question : does running with irqpoll affects performance ? Paul - 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
Re: [git patches] libata 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 > 019400 irq 16 > ata8: PATA max UDMA/100 cmd 0x00019800 ctl 0x00019482 bmdma > 0x00 > 019408 irq 16 > scsi6 : pata_jmicron > ata7.00: ATAPI, max UDMA/66 > ata7.00: configured for UDMA/66 > scsi7 : pata_jmicron > ATA: abnormal status 0x7F on port 0x00019807 > ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > ata7.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) It seems like IRQ is not getting through. The first IRQ driven command is failing for you. * Does giving 'acpi=off' or 'irqpoll' make any difference? * Can you connect a harddisk to the channel and see whether that works? Thanks. -- 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
RE: [git patches] libata fixes
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 019400 irq 16 ata8: PATA max UDMA/100 cmd 0x00019800 ctl 0x00019482 bmdma 0x00 019408 irq 16 scsi6 : pata_jmicron ata7.00: ATAPI, max UDMA/66 ata7.00: configured for UDMA/66 scsi7 : pata_jmicron ATA: abnormal status 0x7F on port 0x00019807 ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata7.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata7: soft resetting port ata7.00: configured for UDMA/66 ata7: EH complete ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata7.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata7: soft resetting port ata7.00: configured for UDMA/66 ata7: EH complete ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata7.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata7: soft resetting port ata7.00: configured for UDMA/66 ata7: EH complete ata7.00: limiting speed to UDMA/44:PIO4 ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata7.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata7: soft resetting port ata7.00: configured for UDMA/44 ata7: EH complete Hope this helps... Regards, Paul Paul Rolland, rol(at)as2917.net ex-AS2917 Network administrator and Peering Coordinator -- Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tejun Heo > Sent: Monday, March 05, 2007 4:45 PM > To: [EMAIL PROTECTED] > Cc: 'Jeff Garzik'; 'Andrew Morton'; 'Linus Torvalds'; > [email protected]; 'LKML'; 'Eric D. Mudama' > Subject: Re: [git patches] libata fixes > > Paul Rolland wrote: > > Hello, > > > >> Your drive has some issues with NCQ and is scheduled to be > blacklisted > >> such that it isn't enabled. libata used to ignore the > >> condition but now > >> considers it NCQ protocol violation and fails all pending commands. > > > > OK, do you need an hdparm report to fully identify the disk ? > > Nope, we already know. > > >> libata EH should turn NCQ off automatically after a few of > the above > >> errors. I'd love to see how that actually works in the field (full > >> dmesg please). If it doesn't, it needs fixing. > > > > I'll get you one tonite, I don't have access to the machine > right now. > > Great. Thanks. > > -- > 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 > dmesg-2.6.21-rc2.before.bz2 Description: Binary data dmesg-2.6.21-rc2.after.bz2 Description: Binary data
Re: [git patches] libata fixes
Paul Rolland wrote: > Hello, > >> Your drive has some issues with NCQ and is scheduled to be blacklisted >> such that it isn't enabled. libata used to ignore the >> condition but now >> considers it NCQ protocol violation and fails all pending commands. > > OK, do you need an hdparm report to fully identify the disk ? Nope, we already know. >> libata EH should turn NCQ off automatically after a few of the above >> errors. I'd love to see how that actually works in the field (full >> dmesg please). If it doesn't, it needs fixing. > > I'll get you one tonite, I don't have access to the machine right now. Great. Thanks. -- 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
RE: [git patches] libata fixes
Hello, > Your drive has some issues with NCQ and is scheduled to be blacklisted > such that it isn't enabled. libata used to ignore the > condition but now > considers it NCQ protocol violation and fails all pending commands. OK, do you need an hdparm report to fully identify the disk ? > libata EH should turn NCQ off automatically after a few of the above > errors. I'd love to see how that actually works in the field (full > dmesg please). If it doesn't, it needs fixing. I'll get you one tonite, I don't have access to the machine right now. Regards, Paul - 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
RE: [git patches] libata fixes
Hello, > 1. Has it ever worked with the previous kernels? I can't tell, this machine is new, and it never booted something that was not a 2.6.20 or 2.6.21. > 2. If you connect a harddisk to pata_jmicron, does it work? > > 3. Does applying the attached patch fix your problem? Will do these two tonite when back home. Thanks, Paul - 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
Re: [git patches] libata fixes
Hello,
Paul Rolland wrote:
> Hello,
>
> Applied this on top of 2.6.21-rc1 and your previous patch (see my previous
> mail).
> Still booting, no more the weird error I've reported minutes ago.
>
> pata_jmicron still unable to detect my DVD-RW :
> scsi8 : pata_jmicron
> ata9.00: ATAPI, max UDMA/66
> ata9.00: qc timeout (cmd 0xef)
> ata9.00: failed to set xfermode (err_mask=0x4)
> ata9.00: limiting speed to UDMA/44
> ata9: failed to recover some devices, retrying in 5 secs
> ata9.00: qc timeout (cmd 0xef)
> ata9.00: failed to set xfermode (err_mask=0x4)
> ata9.00: limiting speed to PIO0
> ata9: failed to recover some devices, retrying in 5 secs
> ata9.00: qc timeout (cmd 0xef)
> ata9.00: failed to set xfermode (err_mask=0x4)
> ata9.00: disabled
> scsi9 : pata_jmicron
> ATA: abnormal status 0x7F on port 0x00019807
1. Has it ever worked with the previous kernels?
2. If you connect a harddisk to pata_jmicron, does it work?
3. Does applying the attached patch fix your problem?
--
tejun
diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c
index 43763c9..8a95a56 100644
--- a/drivers/ata/pata_jmicron.c
+++ b/drivers/ata/pata_jmicron.c
@@ -196,7 +196,8 @@ static int jmicron_init_one (struct pci_dev *pdev, const struct pci_device_id *i
{
static struct ata_port_info info = {
.sht = &jmicron_sht,
- .flags = ATA_FLAG_SLAVE_POSS | ATA_FLAG_SRST,
+ .flags = ATA_FLAG_SLAVE_POSS | ATA_FLAG_SRST |
+ ATA_FLAG_SETXFER_POLLING,
.pio_mask = 0x1f,
.mwdma_mask = 0x07,
Re: [git patches] libata fixes
[cc'ing Eric D. Mudama. Hi!] Paul Rolland wrote: > ata1.00: exception Emask 0x2 SAct 0xffe0 SErr 0x0 action 0x2 frozen > ata1.00: (spurious completions during NCQ issue=0x0 SAct=0xffe0 > FIS=004040a1:0010) > ata1.00: cmd 60/02:28:52:ec:c4/00:00:0e:00:00/40 tag 5 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:30:54:ec:c4/00:00:0e:00:00/40 tag 6 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:38:56:ec:c4/00:00:0e:00:00/40 tag 7 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:40:58:ec:c4/00:00:0e:00:00/40 tag 8 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:48:5a:ec:c4/00:00:0e:00:00/40 tag 9 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:50:5c:ec:c4/00:00:0e:00:00/40 tag 10 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:58:5e:ec:c4/00:00:0e:00:00/40 tag 11 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:60:60:ec:c4/00:00:0e:00:00/40 tag 12 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:68:62:ec:c4/00:00:0e:00:00/40 tag 13 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:70:64:ec:c4/00:00:0e:00:00/40 tag 14 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:78:66:ec:c4/00:00:0e:00:00/40 tag 15 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1: soft resetting port > ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > ata1.00: configured for UDMA/133 > ata1: EH complete > SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) > sda: Write Protect is off > sda: Mode Sense: 00 3a 00 00 > SCSI device sda: write cache: enabled, read cache: enabled, doesn't support > DPO or FUA > > This last part was not present when booting stock 2.6.21-rc1 Your drive has some issues with NCQ and is scheduled to be blacklisted such that it isn't enabled. libata used to ignore the condition but now considers it NCQ protocol violation and fails all pending commands. libata EH should turn NCQ off automatically after a few of the above errors. I'd love to see how that actually works in the field (full dmesg please). If it doesn't, it needs fixing. Thanks. -- 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
RE: [git patches] libata fixes
Hello, Applied this on top of 2.6.21-rc1, and I now have the following in my logs : ahci :00:1f.2: version 2.0 ACPI: PCI Interrupt :00:1f.2[B] -> GSI 23 (level, low) -> IRQ 23 PCI: Setting latency timer of device :00:1f.2 to 64 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 0xc20b2900 ctl 0x bmdma 0x irq 504 ata2: SATA max UDMA/133 cmd 0xc20b2980 ctl 0x bmdma 0x irq 504 ata3: SATA max UDMA/133 cmd 0xc20b2a00 ctl 0x bmdma 0x irq 504 ata4: SATA max UDMA/133 cmd 0xc20b2a80 ctl 0x bmdma 0x irq 504 scsi0 : ahci 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 NCQ (depth 31/32) ata1.00: configured for UDMA/133 scsi1 : ahci ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: qc timeout (cmd 0xec) ata2.00: failed to IDENTIFY (I/O error, err_mask=0x104) ata2: port is slow to respond, please be patient (Status 0x80) ata2: port failed to respond (30 secs, Status 0x80) ata2: COMRESET failed (device not ready) ata2: hardreset failed, retrying in 5 secs ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: ATA-6: Config Disk, RGL10364, max UDMA/133 ata2.00: 640 sectors, multi 1: LBA ata2.00: configured for UDMA/133 scsi2 : ahci ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: ATA-7: Maxtor 6L250S0, BANC1G10, max UDMA/133 ata3.00: 490234752 sectors, multi 0: LBA48 NCQ (depth 31/32) ata3.00: configured for UDMA/133 scsi3 : ahci ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata4.00: ATA-7: ST3500641AS, 3.AAB, max UDMA/133 ata4.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32) ata4.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sd 0:0:0:0: Attached scsi disk sda sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: Direct-Access ATA Config Disk RGL1 PQ: 0 ANSI: 5 SCSI device sdb: 640 512-byte hdwr sectors (0 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: disabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdb: 640 512-byte hdwr sectors (0 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: disabled, read cache: enabled, doesn't support DPO or FUA sdb: unknown partition table sd 1:0:0:0: Attached scsi disk sdb sd 1:0:0:0: Attached scsi generic sg1 type 0 scsi 2:0:0:0: Direct-Access ATA Maxtor 6L250S0 BANC PQ: 0 ANSI: 5 SCSI device sdc: 490234752 512-byte hdwr sectors (251000 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdc: 490234752 512-byte hdwr sectors (251000 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sdc2 sd 2:0:0:0: Attached scsi disk sdc sd 2:0:0:0: Attached scsi generic sg2 type 0 scsi 3:0:0:0: Direct-Access ATA ST3500641AS 3.AA PQ: 0 ANSI: 5 SCSI device sdd: 976773168 512-byte hdwr sectors (500108 MB) sdd: Write Protect is off sdd: Mode Sense: 00 3a 00 00 SCSI device sdd: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdd: 976773168 512-byte hdwr sectors (500108 MB) sdd: Write Protect is off sdd: Mode Sense: 00 3a 00 00 SCSI device sdd: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdd: sdd1 sdd2 sdd3 sd 3:0:0:0: Attached scsi disk sdd sd 3:0:0:0: Attached scsi generic sg3 type 0 ACPI: PCI Interrupt :02:00.0[A] -> GSI 17 (level, low) -> IRQ 17 PCI: Setting latency timer of device :02:00.0 to 64 ahci :02:00.0: AHCI 0001. 32 slots 2 ports 3 Gbps 0x3 impl SATA mode ahci :02:00.0: flags: 64bit ncq pm led clo pmp pio slum part ata5: SATA max UDMA/133 cmd 0xc20bc100 ctl 0x bmdma 0x irq 17 ata6: SATA max UDMA/133 cmd 0xc20bc180 ctl 0x bmdma 0x irq 17 scsi4 : ahci ata5: SATA link down (SStatus 0 SControl 300) scsi5 : ahci ata6: SATA link down (SStatus 0 SControl 300) ata_piix :00:1f.1: version 2.00ac7 ACPI: PCI Interrupt :00:1f.1[A] -> GSI 22 (level, low) -> IRQ 22 PCI: Setting l
Re: [git patches] libata fixes
On Fri, 2007-02-02 at 11:58 -0500, Jeff Garzik wrote:
> 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 +
> drivers/ata/pata_atiixp.c | 11 +--
> drivers/ata/pata_jmicron.c | 18 +-
> drivers/ata/pata_via.c |3 ++-
> drivers/pci/quirks.c |4 ++--
> include/linux/libata.h |2 ++
> 6 files changed, 21 insertions(+), 18 deletions(-)
>
> Alan (3):
> pata_atiixp: propogate cable detection hack from drivers/ide to the new
> driver
> pata_via: Correct missing comments
> libata: Fix ata_busy_wait() kernel docs
>
> Brian King (1):
> libata: Initialize nbytes for internal sg commands
>
> Tejun Heo (1):
> ahci/pata_jmicron: fix JMicron quirk
>
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index cf70702..667acd2 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -1250,6 +1250,7 @@ unsigned ata_exec_internal_sg(struct ata_device *dev,
>
> ata_sg_init(qc, sg, n_elem);
> qc->nsect = buflen / ATA_SECT_SIZE;
> + qc->nbytes = buflen;
> }
>
> qc->private_data = &wait;
> diff --git a/drivers/ata/pata_atiixp.c b/drivers/ata/pata_atiixp.c
> index 6f6672c..504e1db 100644
> --- a/drivers/ata/pata_atiixp.c
> +++ b/drivers/ata/pata_atiixp.c
> @@ -36,15 +36,22 @@ enum {
> static int atiixp_pre_reset(struct ata_port *ap)
> {
> struct pci_dev *pdev = to_pci_dev(ap->host->dev);
> - static struct pci_bits atiixp_enable_bits[] = {
> + static const struct pci_bits atiixp_enable_bits[] = {
> { 0x48, 1, 0x01, 0x00 },
> { 0x48, 1, 0x08, 0x00 }
> };
> + u8 udma;
>
> if (!pci_test_config_bits(pdev, &atiixp_enable_bits[ap->port_no]))
> return -ENOENT;
>
> - ap->cbl = ATA_CBL_PATA80;
> + /* Hack from drivers/ide/pci. Really we want to know how to do the
> +raw detection not play follow the bios mode guess */
> + pci_read_config_byte(pdev, ATIIXP_IDE_UDMA_MODE + ap->port_no, &udma);
> + if ((udma & 0x07) >= 0x04 || (udma & 0x70) >= 0x40)
> + ap->cbl = ATA_CBL_PATA80;
> + else
> + ap->cbl = ATA_CBL_PATA40;
> return ata_std_prereset(ap);
> }
> (snip)
>
Alan's patch is also important. Thank you :)
Without the patch, OS on 40-pin cable maybe get IDE DMA error (CRC
error, system hang, or even data crash).
Conke
-
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
Re: [git patches] libata fixes
On Fri, 2 Feb 2007, alan wrote: > > I just thought you meant a scenario involving schedenfreud. That would be sch*a*denfreud*e* Linus "I win!" Torvalds - 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
Re: [git patches] libata fixes
On Fri, 2 Feb 2007, Linus Torvalds wrote: On Fri, 2 Feb 2007, Andrew Morton wrote: http://www.google.com/search?hl=en&q=torvalds+schenario&btnG=Google+Search I know. But since people pointed it out, I've actually tried to mend my broken ways. And the fact that people always point out that _same_ misspelled word actually makes me happy. I can't be spelling too many words badly if they all just react to the same one. I just thought you meant a scenario involving schedenfreud. -- "Invoking the supernatural can explain anything, and hence explains nothing." - University of Utah bioengineering professor Gregory Clark - 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
Re: [git patches] libata fixes
On Fri, 2 Feb 2007, Andrew Morton wrote: > > http://www.google.com/search?hl=en&q=torvalds+schenario&btnG=Google+Search I know. But since people pointed it out, I've actually tried to mend my broken ways. And the fact that people always point out that _same_ misspelled word actually makes me happy. I can't be spelling too many words badly if they all just react to the same one. Linus - 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
Re: [git patches] libata fixes
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 drive me wild" Torvalds http://www.google.com/search?hl=en&q=torvalds+schenario&btnG=Google+Search - 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
Re: [git patches] libata fixes
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. So add git-commit auto spelling fixes for them Alan, taking leave henceforth reptant unto his box. - 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
Re: [git patches] libata fixes
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 words, that's just one more for the list. /me runs... - 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
Re: [git patches] libata fixes
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 - 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
Re: [git patches] libata fixes
Jeff Garzik wrote: > All fixes for ugly bugs and/or regressions. > > Brian King (2): > libata: Fixup n_elem initialization > libata: Initialize qc->pad_len Thanks for pulling this in. There is one patch outstanding preventing ipr SATA from working: http://marc.theaimsgroup.com/?l=linux-ide&m=116905877706906&w=2 Tejun proposed an alternate patch: http://article.gmane.org/gmane.linux.ide/14792 Which you merged into #upstream for 2.6.21. Any chance one of these patches could make its way in 2.6.20 so ipr SATA support works? Thanks, Brian -- Brian King eServer Storage I/O IBM Linux Technology Center - 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
Re: [git patches] libata fixes
* Jeff Garzik ([EMAIL PROTECTED]) wrote: > FWIW the Tejun cleanups are a fix, split into three reviewable pieces. > > Also, my local iomap branch has advanced sufficiently enough that I > think it's high time to kill those libata warnings that spew on every > build. (I hear the crowds roar) Perhaps I missed it, but, when is PMP support going to be included in main-stream? Seems like it's been around for a while now and I doubt I'm the only one extremely frustrated with having to hunt down an external patch to get a new toy supported. I'll probably bug the Debian kernel folks next but it'd be nicer if it was in upstream. Thanks! Stephen - 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
