Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c| 113 -
drivers/ata/pata_ali.c|2 +-
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c| 113 -
drivers/ata/pata_ali.c|2 +-
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
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
> 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.
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
> 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
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
> 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-kernel"
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_generic.c |2 +-
drivers/ata/libata-core.c |6 +++---
drivers/ata/libata-sff.c|5
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_generic.c |2 +-
drivers/ata/libata-core.c |6 +++---
drivers/ata/libata-sff.c|5
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-kernel in
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
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
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
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
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/Kconfig |5
drivers/ata/libata-core.c |3 +-
drivers/ata/pata_pdc2027x.c | 11 -
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/Kconfig |5
drivers/ata/libata-core.c |3 +-
drivers/ata/pata_pdc2027x.c | 11 -
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
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
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
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))
+
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
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 | 56 +++-
drivers/ata/libata-eh.c |7 +
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 | 56 +++-
drivers/ata/libata-eh.c |7 +
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
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;
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
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/ahci.c|2 +-
drivers/ata/libata-core.c |4 +++-
drivers/ata/pata_amd.c|2 ++
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/ahci.c|2 +-
drivers/ata/libata-core.c |4 +++-
drivers/ata/pata_amd.c|2 ++
As mentioned, will push Tejun's updated probe patch when received.
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/ahci.c| 24
As mentioned, will push Tejun's updated probe patch when received.
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/ahci.c| 24
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[] = {
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 */
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 +-
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 +-
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 */
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[] = {
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c |1 +
drivers/ata/libata-core.c |4 +-
drivers/ata/pata_hpt3x2n.c |4 +-
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c |1 +
drivers/ata/libata-core.c |4 +-
drivers/ata/pata_hpt3x2n.c |4 +-
Two fixes; the rest is trivial pre-release administrivia (ie. only bump
versions and chomp whitespace after everything else gets merged up)
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
Two fixes; the rest is trivial pre-release administrivia (ie. only bump
versions and chomp whitespace after everything else gets merged up)
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
Main thing of note: still sorting out the shutdown mess. See the
extended commit texts for more info.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
Main thing of note: still sorting out the shutdown mess. See the
extended commit texts for more info.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
All bug fixes. The two things that do not seem like bugfixes ("separate
out..." and "add ATA_FLAG_ACPI_SATA") are not as they seem. The former
is a prep patch for a fix, and the latter fixes what ACPI considers a
legacy IDE interface.
Please pull from 'upstream-linus' branch of
All bug fixes. The two things that do not seem like bugfixes (separate
out... and add ATA_FLAG_ACPI_SATA) are not as they seem. The former
is a prep patch for a fix, and the latter fixes what ACPI considers a
legacy IDE interface.
Please pull from 'upstream-linus' branch of
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
Documentation/kernel-parameters.txt |8 ---
drivers/ata/libata-acpi.c |3 +-
drivers/ata/libata-core.c |
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
Documentation/kernel-parameters.txt |8 ---
drivers/ata/libata-acpi.c |3 +-
drivers/ata/libata-core.c |
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 | 33 -
drivers/ata/libata-eh.c | 22 +++---
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 | 33 -
drivers/ata/libata-eh.c | 22 +++---
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
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
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
This disables libata ACPI, among other things.
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/ahci.c | 21 +++-
drivers/ata/libata-acpi.c
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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
This disables libata ACPI, among other things.
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/ahci.c | 21 +++-
drivers/ata/libata-acpi.c
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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
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
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 -
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
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/Kconfig |2 +-
drivers/ata/libata-core.c|2 +-
drivers/ata/libata-eh.c |8 +++-
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
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
> 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,
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
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
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
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/Kconfig |2 +-
drivers/ata/libata-core.c|2 +-
drivers/ata/libata-eh.c |8 +++-
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
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
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
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
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
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;
>
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
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
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 .;
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
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
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
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
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
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
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
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
> > >
> > >
> > > 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:
> 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
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
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
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
>
Rolland
> Sent: Saturday, March 17, 2007 6:59 PM
> To: 'Tejun Heo'
> Cc: 'Linus Torvalds'; 'Jeff Garzik'; 'Alan Cox'; 'Andrew
> Morton'; linux-ide@vger.kernel.org; 'LKML'; 'Eric D. Mudama'
> Subject: RE: [git patches] libata fixes
>
> Hello,
>
> I'm preparing to
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
AM
> To: [EMAIL PROTECTED]
> Cc: 'Linus Torvalds'; 'Jeff Garzik'; 'Alan Cox'; 'Andrew
> Morton'; linux-ide@vger.kernel.org; 'LKML'; 'Eric D. Mudama'
> Subject: Re: [git patches] libata fixes
>
> Paul Rolland wrote:
> >> I keep forgetting about this. I'll ask SIMG how to
> > 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
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
'; 'Jeff Garzik'; 'Alan Cox'; 'Andrew
Morton'; linux-ide@vger.kernel.org; '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
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).
Torvalds'; 'Jeff Garzik'; 'Alan Cox'; 'Andrew
Morton'; linux-ide@vger.kernel.org; '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
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
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 @@
101 - 200 of 289 matches
Mail list logo
