| Linux Forum Index » Linux Hardware » Kernel: ata1: timeout error/bug |
|
Page 1 of 1 |
|
| Author |
Message |
| root |
 Posted: Thu May 18, 2006 5:32 am |
|
|
|
Guest
|
Every day or so my server grinds down to a very slow crawl, often
mistaken as a stall/freeze. In fact it is so slow that a simple command
takes a long while to execute; say about half hour to an hour. I have
had this exact same error regardless of hard drive regardless whether it
be a Seagate or a Maxtor SATA drive or SATA1 or SATA2.
Also during this timeoout processor usage climbs up. For example the
system uses dual Opteron 242 processors and usual usage is very low
usually running no more than .01%. However during the ata1 timeoout
processor usage steadily climbs to around 4% or higher.
SATA controler is a VIA 8237. OS is Fedora 5 but this was an issue with
Fedora 4 as well. Kernel version is 2.6.16 which was supposed to have
corrected the issue.
This error/bug has been known to exist by the Linux for over 3 years.
During these 3 years has a solution been found for this bug/error? Any
ideas as to what the solution is (if there is one)? |
|
|
| Back to top |
|
|
|
| Vladimir Florinski |
| Posted: Thu May 18, 2006 1:53 pm |
|
|
|
Guest
|
On Thu, 18 May 2006 11:32:21 +0000, root wrote:
Quote: Every day or so my server grinds down to a very slow crawl, often
mistaken as a stall/freeze. In fact it is so slow that a simple command
takes a long while to execute; say about half hour to an hour. I have
had this exact same error regardless of hard drive regardless whether it
be a Seagate or a Maxtor SATA drive or SATA1 or SATA2.
Also during this timeoout processor usage climbs up. For example the
system uses dual Opteron 242 processors and usual usage is very low
usually running no more than .01%. However during the ata1 timeoout
processor usage steadily climbs to around 4% or higher.
SATA controler is a VIA 8237. OS is Fedora 5 but this was an issue with
Fedora 4 as well. Kernel version is 2.6.16 which was supposed to have
corrected the issue.
This error/bug has been known to exist by the Linux for over 3 years.
During these 3 years has a solution been found for this bug/error? Any
ideas as to what the solution is (if there is one)?
Could this be due to a lack of reproducibility of your problem? I have
this same controller and never saw a single error running Fedora 4.
--
Vladimir |
|
|
| Back to top |
|
|
|
| root |
| Posted: Thu May 18, 2006 10:14 pm |
|
|
|
Guest
|
Vladimir Florinski wrote:
Quote: On Thu, 18 May 2006 11:32:21 +0000, root wrote:
Every day or so my server grinds down to a very slow crawl, often
mistaken as a stall/freeze. In fact it is so slow that a simple command
takes a long while to execute; say about half hour to an hour. I have
had this exact same error regardless of hard drive regardless whether it
be a Seagate or a Maxtor SATA drive or SATA1 or SATA2.
Also during this timeoout processor usage climbs up. For example the
system uses dual Opteron 242 processors and usual usage is very low
usually running no more than .01%. However during the ata1 timeoout
processor usage steadily climbs to around 4% or higher.
SATA controler is a VIA 8237. OS is Fedora 5 but this was an issue with
Fedora 4 as well. Kernel version is 2.6.16 which was supposed to have
corrected the issue.
This error/bug has been known to exist by the Linux for over 3 years.
During these 3 years has a solution been found for this bug/error? Any
ideas as to what the solution is (if there is one)?
Could this be due to a lack of reproducibility of your problem? I have
this same controller and never saw a single error running Fedora 4.
This has been a known issue for a long while. I can reproduce this
every day or so on my computer as I have stated before. At issue is the
way the Linux kernel handles SATA resumes.
Lack of reproducibility neither is an answer nor did the lack of
reproducibility ever during our universe's history cause something not
to work. Just because you did not experience the problem does not mean
it does not happen. This is not a Fleischmann-Pons experiment. |
|
|
| Back to top |
|
|
|
| Grant |
| Posted: Thu May 18, 2006 11:16 pm |
|
|
|
Guest
|
On Fri, 19 May 2006 04:14:53 GMT, root <root@quasar.com> wrote:
Quote: Vladimir Florinski wrote:
On Thu, 18 May 2006 11:32:21 +0000, root wrote:
Every day or so my server grinds down to a very slow crawl, often
mistaken as a stall/freeze. In fact it is so slow that a simple command
....
I can reproduce this
every day or so on my computer as I have stated before. At issue is the
way the Linux kernel handles SATA resumes.
How reproduce?
Why the particular diagnosis? What's this SATA resume?
I run dual SATA on same chipset no problems for over a year, dual SATA
on different chipset near 3 years, never a problem.
Unless you provide a test case that others may reproduce, you are
hand-waving.
Every day? Some cron job?
Grant.
--
Memory fault -- brain fried |
|
|
| Back to top |
|
|
|
| Vladimir Florinski |
| Posted: Fri May 19, 2006 2:02 pm |
|
|
|
Guest
|
On Fri, 19 May 2006 04:14:53 +0000, root wrote:
Quote: This has been a known issue for a long while. I can reproduce this
every day or so on my computer as I have stated before. At issue is the
way the Linux kernel handles SATA resumes.
Lack of reproducibility neither is an answer nor did the lack of
reproducibility ever during our universe's history cause something not
to work.
Of course. But then, why develop a driver if it is only going to be used
once? Instead, let us hope that a stable, bug-free driver gets written all
by itself (perhaps as a result of a typewriter jumping exercise by a
large group of primates).
Quote: Just because you did not experience the problem does not mean
it does not happen. This is not a Fleischmann-Pons experiment.
Cold fusion research failed to change nuclear physics theory, and your
experience failed to affect libata/sata_via (or whatever driver name is).
Both because of lack of reproducibility.
--
Vladimir |
|
|
| Back to top |
|
|
|
|
