Hello all,
A bit of update to this issue.
Switching the cabling of the most problematic drive with a new one
didn't fix the issue.
I couldn't yet switch the power supply with a more powerful one.
However I temporarily added a pci-e SATA host and another drive, the
situation was just as bad
Guillaume Laurès wrote:
Le 8 janv. 08 à 01:29, Robert Hancock a écrit :
From your report:
ata5: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl
0x1501000 status 0x400
ata5: CPB 0: ctl_flags 0x1f, resp_flags 0x1
ata5: CPB 1: ctl_flags 0x1f, resp_flags 0x2
ata5: CPB 2: ctl_flags 0x
On 01/07/2008 03:22 PM, Guillaume Laurès wrote:
> However even with CFQ/NOOP I keep getting soft resets, only the sata_nv
> SATA ports, when under load. Any thoughs ?
Try the adma=0 option for the driver?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
On Tue, 8 Jan 2008 15:52:35 +0100, Guillaume Laurès <[EMAIL PROTECTED]> wrote:
> > ata5.00: exception Emask 0x0 SAct 0x1f02 SErr 0x0 action 0x2 frozen
> > ata5.00: cmd 60/40:08:8f:eb:67/00:00:03:00:00/40 tag 1 cdb 0x0 data
> > 32768 in
> > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
Laurès wrote:
Hello,
Dear kernel developers, my dmesg asked me to report this, so here I go ;)
Here is what I found in my dmesg: "anticipatory: forced dispatching is
broken (nr_sorted=1), please report this".
- First, let's talk about the machine: it's quite pushed so maybe the
cause is me d
Well, I should have tried to answer my own question earlier... but
there is still a problem.
A quick reading of Wikipedia later, I can tell the following.
First, the anticipatory scheduler seems to be the worse choice when
dealing with raid arrays.
Now, a better choice in my case could be:
-
6 matches
Mail list logo
