The HDIO_DRIVE_* fix is really the biggie.
Please pull 6d3bfc7be6f80d0c6ee6800d58d573343bf6e260 from
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
tags/upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c| 14 +-
drivers/ata/libata-co
On Mon, Jan 21, 2013 at 11:48 AM, Jeff Garzik wrote:
> Please pull 803739d25c2343da6d2f95eebdcbc08bf67097d4 from
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
> tags/upstream-linus
>From the tag message:
" Thought: I wonder if sparse could have caught this, someh
Please pull 803739d25c2343da6d2f95eebdcbc08bf67097d4 from
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
tags/upstream-linus
to receive the following updates:
drivers/ata/ahci.c| 8 +++-
drivers/ata/libahci.c | 6 +++---
drivers/ata/libata-core.c | 22 ++
If you were going to shoot me for not sending these earlier, you would be
right. -rc6 beat me by ~2 hours it seems, and they really should have
gone out to libata-dev.git and you long before that.
These have been in libata-dev.git for a day or so (unfortunately
linux-next is on vacation). The m
On 02.10.2012 23:59, Jeff Garzik wrote:
> On 10/02/2012 03:44 PM, Michael Tokarev wrote:
>> On 02.10.2012 23:40, Jeff Garzik wrote:
>>
>>> Minor libata updates, nothing notable.
>>>
>>> 1) Apply -- and then revert -- the FUA feature. Caused
>>> disk corruption in linux-next, proving it cannot
On 10/02/2012 03:44 PM, Michael Tokarev wrote:
On 02.10.2012 23:40, Jeff Garzik wrote:
Minor libata updates, nothing notable.
1) Apply -- and then revert -- the FUA feature. Caused
disk corruption in linux-next, proving it cannot be turned on by
default.
Any details on that? Disk c
On 02.10.2012 23:40, Jeff Garzik wrote:
> Minor libata updates, nothing notable.
>
> 1) Apply -- and then revert -- the FUA feature. Caused
>disk corruption in linux-next, proving it cannot be turned on by
>default.
Any details on that? Disk corruprion is rather a nasty
side-effect ind
Please pull 13b74085d92feda78bad1045516d332a1e9a3407 from
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
tags/upstream-linus
to receive the following updates:
Minor libata updates, nothing notable.
1) Apply -- and then revert -- the FUA feature. Caused
disk corrupti
Changes:
1) libata-acpi regression fix
2) additional or corrected drive quirks for ata_blacklist
3) Kconfig text tweaking
4) new PCI IDs
5) pata_atiixp: quirk for MSI motherboard
6) export ahci_dev_classify for an ahci_platform driver
Please pull d17d794c63e2dc0a5b1ffc8367c9475880427fc7 fr
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
> 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 fro
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/
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| 23 +--
drivers/ata/libata-core.c | 16 ++--
drivers/ata/libata-pmp.c
Note: Tejun's change is a feature addition, but one that is IMO
important for debugging and serious-bug workarounds. It's
self-contained and should not affect anyone not using the new parm.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-de
Got another couple sata_mv fixes pending too... coming soon.
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 |2 +-
drivers/ata/libata-core.c |1
Please pull from 'upstream-fixes' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-fixes
to receive the following updates:
drivers/ata/libata-core.c | 48 +-
drivers/ata/pata_amd.c |2 +-
drivers/ata/pata_l
Open issues for 2.6.24: sata_nv ADMA, sata_nv 32/64bit DMA
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 |4 +++-
drivers/ata/pata_bf54x.c |3
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| 51 +
drivers/ata/libata-scsi.c |6 ++--
drivers/ata/sat
Still working through the backlog, but this is most of the immediate
libata stuff. I asked DaveM to help out with netdev fixes, so there
shouldn't be much of a 2.6.24-rc backlog at all there (thanks again David).
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel
In 2.6.24, we turned on ACPI support in libata. This is needed in order
to support suspend/resume and BIOS passworded drives, but it inevitably
brought with it a host of new regressions -- which is what happens
anytime you blindly accept ATA commands the BIOS has decided to toss
your way. :)
It
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
Notable: kill spurious NCQ completion detection
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.
Pleas
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 |4
drivers/ata/pata_amd.c |5 +++--
drivers/ata/pata_via.c |4 ++--
drivers/ata/sata_mv.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/ata_piix.c| 28 +++
drivers/ata/libata-core.c |8 +++--
drivers/ata/libata-eh.c | 42 +++
NOTE: This includes 100% of the fixes collected during the week I
was on vacation, by Tejun... rebased. So all the commit ids are
different from his push.
If you have not pulled from Tejun, then pull this.
If you have pulled from Tejun, then do not pull this (I will rebase once
Tejun's pull is
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-l
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
mas
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 |7 +++
drivers/ata/libata-acpi.c | 10 +---
drivers/ata/libata-core.c | 78 ++
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 | 39 ---
drivers/ata/pata_hpt37
Fixes, fixes and more fixes.
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 | 38 ---
drivers/ata/libata-eh.c| 148 ++--
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 li
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 patch
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
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 le
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 *mor
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:
Signe
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
Of particular note is the sata_promise fix, which works around a
nasty hw errata. I need to push that to stable@
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-
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 | 26 +++---
drivers/ata/ata_piix.c | 29 +++---
drivers/ata/libata-acpi.c | 16 ++--
drivers/at
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 |2 +-
drivers/ata/pata_cs5536.c |4 ++--
drivers/ata/sata_sis.c| 15 +--
3 files
Well, the new driver is not a fix.
Anyway -- still plugging away at debugging libata. It seems some
outside changes are causing a bunch of my test boxes to crap themselves.
These need to go up in the meantime, however.
Maybe its the sg-chaining stuff, we'll see. I'm watching that thread
closel
Fix ugly sata_mv bug, that exists due to lack of IOMMU knowledge about
device constraints (FUJITA Tomonori's current work should fix this issue
long term, hopefully).
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
t
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/pata_sis.c |3 ++-
drivers/ata/sata_sil24.c | 16
2 files changed, 14 insertions(+), 5 deletions(
Fixes from Alan, PCI IDs from ATI/AMD.
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| 10 ++
drivers/ata/libata-core.c |4
drivers/at
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_it821x.c |4
drivers/ata/pata_via.c | 14 +++---
driv
Fixes, some new ids, and a version bump that we discovered was missing
from several drivers.
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 +-
Fixes + more laptop IDs
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 |7 ++-
drivers/ata/pata_pdc2027x.c | 18 +-
drivers/at
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 |9 -
drivers/ata/libata-core.c |2 +-
drivers/ata/pata_artop.c | 19 ++---
The only non-fix are two sata_mv PCI ID additions.
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|2 +-
drivers/ata/pata_isapnp.c |2 ++
drivers/
The only notable: GregKH wanted the pci_reenable_device() change
associated with ata_piix to go in before the release, to avoiding
release with an imperfect API.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to rece
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 +-
drivers/ata/pata_
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 i
> 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. A
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 se
> 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
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 wh
> 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
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/Kconfig |5
drivers/ata/libata-core.c |3 +-
drivers/ata/pata_pdc2027x.c | 11 -
drivers/
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
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 appa
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
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 e
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 +
drivers/ata/lib
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 ++
drivers/ata/pata_it82
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
drivers/ata/lib
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 +-
drivers/ata/pat
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c |1 +
drivers/ata/libata-core.c |4 +-
drivers/ata/pata_hpt3x2n.c |4 +-
drivers/ata/pata_sis.
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 upda
Main thing of note: still sorting out the shutdown mess. See the
extended commit texts for more info.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
Documentation/feature-removal-
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
master.kernel.or
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 +++---
drivers/a
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 thr
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 -rc
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.
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 http://vger.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/Kconfig |2 +-
drivers/ata/libata-core.c|2 +-
drivers/ata/libata-eh.c |8 +++-
drivers/
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 res
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
> 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,
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 0xc20
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 b
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 I
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 re
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;
> e
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 seve
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 m
> > >
> > >
> > > 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: Maxto
> 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
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
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
> +010
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'; linux-ide@vger.kernel.org; 'LKML'; 'Eric D
1 - 100 of 145 matches
Mail list logo
