Tejun: thanks for pointing out this patch.
Kai, Klaus: thanks for testing the patch!
Petr: thanks for fixing the SMART 2.6.22 problems!
Jeff: two user (Kai, Klaus) both saw the SMART STATUS problem disappear
when they tested this libata patch. I hope you stick it into your own
source tree.
Kai Makisara said the following on 16.07.2007 13:58:
>> Please try the patch in the following message.
>> http://article.gmane.org/gmane.linux.ide/20799/raw
> This solves the 'smartctl -H' problem both of my systems (one with Nvidia
> CK804 and one with MCP51).
This patch also solved the proble
On Mon, 16 Jul 2007, Tejun Heo wrote:
> Please try the patch in the following message.
>
> http://article.gmane.org/gmane.linux.ide/20799/raw
>
This solves the 'smartctl -H' problem both of my systems (one with Nvidia
CK804 and one with MCP51).
Tested-by: Kai Makisara <[EMAIL PROTECTED]>
Than
Please try the patch in the following message.
http://article.gmane.org/gmane.linux.ide/20799/raw
--
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
Pl
On Tue, 10 Jul 2007, Kai Makisara wrote:
> On Sun, 8 Jul 2007, Bruce Allen wrote:
>
> > Mark, David, Doug, Tejin, Alan, Jeff, LKML,
> >
> > I'm afraid that there may be some problem with SMART + libata in the 2.6.22
> > kernel. An hour ago I discovered that I missed a month of correspondence
>
On Tue, 10 Jul 2007, Douglas Gilbert wrote:
Kai Makisara wrote:
I have done some more debugging on this one. An easy way to reproduce
the
The log shows that the sense data returned by the commands differ: with
2.6.22 the bytes 4f and 2c (tf.lbam and tf.lbah) are not returned. Both
of th
Adam Spiers wrote:
On Sun, Jul 08, 2007 at 08:14:10PM -0500, Bruce Allen wrote:
On Sun, 8 Jul 2007, Bruce Allen wrote:
..
http://article.gmane.org/gmane.linux.utilities.smartmontools/4704/match=diamondmax
Again, this indicates that SMART is enabled. But it's not clear what the
kernel version
Kai Makisara wrote:
> On Sun, 8 Jul 2007, Bruce Allen wrote:
>
>> Mark, David, Doug, Tejin, Alan, Jeff, LKML,
>>
>> I'm afraid that there may be some problem with SMART + libata in the 2.6.22
>> kernel. An hour ago I discovered that I missed a month of correspondence
>> (some LKML, some private)
On Sun, Jul 08, 2007 at 08:14:10PM -0500, Bruce Allen wrote:
> On Sun, 8 Jul 2007, Bruce Allen wrote:
> > I'm afraid that there may be some problem with SMART + libata in the 2.6.22
> > kernel. An hour ago I discovered that I missed a month of correspondence
> > (some LKML, some private) about t
On Sun, 8 Jul 2007, Bruce Allen wrote:
> Mark, David, Doug, Tejin, Alan, Jeff, LKML,
>
> I'm afraid that there may be some problem with SMART + libata in the 2.6.22
> kernel. An hour ago I discovered that I missed a month of correspondence
> (some LKML, some private) about this problem which Ala
Bruce Allen wrote:
http://article.gmane.org/gmane.linux.utilities.smartmontools/4712
reported by Jan Dvorak?
Relevant lspci and dmesg output would be useful... that gives enhanced
error diagnostics.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Hi Jeff,
It's possible that the recent addition of ACPI support will cause disks to
be in different modes than previously expected. ACPI supplies ATA
taskfiles to be pushed to the disk, and who knows what's in there...
Is there a simple way I can have affected users test this? Is there a
k
Bruce Allen wrote:
Hi David,
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg164863.html
This is mine and although it's a 'real' problem, it is something
that's easy to hack around by having the suspend script turn on smart
after it is resumed. (Of course I can't use resume unti
Hi David,
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg164863.html
This is mine and although it's a 'real' problem, it is something that's easy
to hack around by having the suspend script turn on smart after it is
resumed. (Of course I can't use resume until a skge wol bug is
Bruce Allen wrote:
On Sun, 8 Jul 2007, Jeff Garzik wrote:
Jeff, thanks for the quick feedback.
On the base point, libata has never enabled SMART on its own. That's
always up to the BIOS, etc.
OK, clear.
It's possible that the recent addition of ACPI support will cause
disks to be in diffe
On Sun, 8 Jul 2007, Jeff Garzik wrote:
Jeff, thanks for the quick feedback.
On the base point, libata has never enabled SMART on its own. That's
always up to the BIOS, etc.
OK, clear.
It's possible that the recent addition of ACPI support will cause disks
to be in different modes than prev
Hi Bruce
From some of the earlier threads that I missed (below) I have the
impression that the problem may be a very simple one, namely that
starting with 2.6.22 one needs to run a command to enable SMART when a
box is first booted -- the kernel no longer does this as part of the
init/setup of
On the base point, libata has never enabled SMART on its own. That's
always up to the BIOS, etc.
It's possible that the recent addition of ACPI support will cause disks
to be in different modes than previously expected. ACPI supplies ATA
taskfiles to be pushed to the disk, and who knows what
Here is another similar report:
http://article.gmane.org/gmane.linux.utilities.smartmontools/4704/match=diamondmax
Again, this indicates that SMART is enabled. But it's not clear what the
kernel version here is. The report indicates that the problem started
with an FC7 kernel upgrade
Bruce
Mark, David, Doug, Tejin, Alan, Jeff, LKML,
I'm afraid that there may be some problem with SMART + libata in the
2.6.22 kernel. An hour ago I discovered that I missed a month of
correspondence (some LKML, some private) about this problem which Alan,
Tejun, Jeff, Mark and others copied to me -
20 matches
Mail list logo
