It appears that the problem was caused by a faulty power supply. Thanks
anyway!
On Tuesday 15 January 2008 11:54:35 Andrew Morton wrote:
> On Mon, 14 Jan 2008 00:19:20 +0200 Georgi Chulkov
<[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > During heavy disk load on my laptop, sometimes the IDE disk
It appears that the problem was caused by a faulty power supply. Thanks
anyway!
On Tuesday 15 January 2008 11:54:35 Andrew Morton wrote:
On Mon, 14 Jan 2008 00:19:20 +0200 Georgi Chulkov
[EMAIL PROTECTED] wrote:
Hello,
During heavy disk load on my laptop, sometimes the IDE disk will
Tejun Heo wrote:
> Bartlomiej Zolnierkiewicz wrote:
>> On Monday 21 January 2008, Tejun Heo wrote:
>>
>> [...]
>>
Old IDE says it works for PATA. For SATA I can see it might need more
care and you might simply not be able to get the info.
>>> Old IDE often locks up the machine hard after
> Could you point me to some bugreports?
>
> I would like to know more about hosts/conditions for which it happens.
The timer reset path races the I/O path races the interrupt path. That
was the vomitously foul race that persuaded me to go libata instead. I
seem to remember explaining this all
Bartlomiej Zolnierkiewicz wrote:
> On Monday 21 January 2008, Tejun Heo wrote:
>
> [...]
>
>>> Old IDE says it works for PATA. For SATA I can see it might need more
>>> care and you might simply not be able to get the info.
>> Old IDE often locks up the machine hard after timeouts. I'm all for
On Monday 21 January 2008, Tejun Heo wrote:
[...]
> > Old IDE says it works for PATA. For SATA I can see it might need more
> > care and you might simply not be able to get the info.
>
> Old IDE often locks up the machine hard after timeouts. I'm all for
Could you point me to some bugreports?
Hello,
Alan Cox wrote:
>> I still don't think it's worth the trouble. There's currently only one
>> reported device which forgets to raise IRQ on media error. The behavior
>
> Most people wouldn't realise what is going on.
Yeap, true but I don't think we have many timeouts due to media
> I still don't think it's worth the trouble. There's currently only one
> reported device which forgets to raise IRQ on media error. The behavior
Most people wouldn't realise what is going on.
> > Old IDE says it works for PATA. For SATA I can see it might need more
> > care and you might
Alan Cox wrote:
>> Can you elaborate a bit? I don't really think completing a command
>> after 30sec timeout contributes a lot to driver stability.
>
> Timeout, timeout, timeout, reset, timeout.. (repeat), failed I/O
>
> This gives the end user no information about the fault, nor does it let
>
> Can you elaborate a bit? I don't really think completing a command
> after 30sec timeout contributes a lot to driver stability.
Timeout, timeout, timeout, reset, timeout.. (repeat), failed I/O
This gives the end user no information about the fault, nor does it let
the upper layers of SCSI and
> Just a data point, even ICHs lock up after PHY event if the wrong TF
> register is accessed. I just don't think tempting with TF regs after
> timeout is worth the cost.
For SATA maybe, for PATA I don't have any controllers with your bug so
its wrong for libata to cripple the PATA support or
Tejun Heo wrote:
> IMHO, losing media error information is much better than locking up a
> machine hard. We can start white listing known good controllers but I'm
> skeptical how much benefit it will bring.
Just a data point, even ICHs lock up after PHY event if the wrong TF
register is
Alan Cox wrote:
>> while IDE thinks that IRQ might be lost and complete the command if the
>> TF status register says so.
>
> For PATA at least that makes a lot of sense. It would probably make the
> Promise driver a lot more stable too.
Can you elaborate a bit? I don't really think completing
> while IDE thinks that IRQ might be lost and complete the command if the
> TF status register says so.
For PATA at least that makes a lot of sense. It would probably make the
Promise driver a lot more stable too.
> It could be that the particular device doesn't raise IRQ on certain
> error
Alan Cox wrote:
>> transmission failure as timeouts. Of course, if we're ticking the timer
>> while the command is not in flight, that's a bug. If there are cases
>> where 30 secs isn't enough, can you please point me to those reports?
>
> I have been, in bugzilla - the raid failure example
> transmission failure as timeouts. Of course, if we're ticking the timer
> while the command is not in flight, that's a bug. If there are cases
> where 30 secs isn't enough, can you please point me to those reports?
I have been, in bugzilla - the raid failure example where old IDE
eventually
transmission failure as timeouts. Of course, if we're ticking the timer
while the command is not in flight, that's a bug. If there are cases
where 30 secs isn't enough, can you please point me to those reports?
I have been, in bugzilla - the raid failure example where old IDE
eventually
Alan Cox wrote:
transmission failure as timeouts. Of course, if we're ticking the timer
while the command is not in flight, that's a bug. If there are cases
where 30 secs isn't enough, can you please point me to those reports?
I have been, in bugzilla - the raid failure example where old
while IDE thinks that IRQ might be lost and complete the command if the
TF status register says so.
For PATA at least that makes a lot of sense. It would probably make the
Promise driver a lot more stable too.
It could be that the particular device doesn't raise IRQ on certain
error
Alan Cox wrote:
while IDE thinks that IRQ might be lost and complete the command if the
TF status register says so.
For PATA at least that makes a lot of sense. It would probably make the
Promise driver a lot more stable too.
Can you elaborate a bit? I don't really think completing a
Tejun Heo wrote:
IMHO, losing media error information is much better than locking up a
machine hard. We can start white listing known good controllers but I'm
skeptical how much benefit it will bring.
Just a data point, even ICHs lock up after PHY event if the wrong TF
register is accessed.
Alan Cox wrote:
Can you elaborate a bit? I don't really think completing a command
after 30sec timeout contributes a lot to driver stability.
Timeout, timeout, timeout, reset, timeout.. (repeat), failed I/O
This gives the end user no information about the fault, nor does it let
the upper
I still don't think it's worth the trouble. There's currently only one
reported device which forgets to raise IRQ on media error. The behavior
Most people wouldn't realise what is going on.
Old IDE says it works for PATA. For SATA I can see it might need more
care and you might simply
Hello,
Alan Cox wrote:
I still don't think it's worth the trouble. There's currently only one
reported device which forgets to raise IRQ on media error. The behavior
Most people wouldn't realise what is going on.
Yeap, true but I don't think we have many timeouts due to media errors.
On Monday 21 January 2008, Tejun Heo wrote:
[...]
Old IDE says it works for PATA. For SATA I can see it might need more
care and you might simply not be able to get the info.
Old IDE often locks up the machine hard after timeouts. I'm all for
Could you point me to some bugreports?
I
Bartlomiej Zolnierkiewicz wrote:
On Monday 21 January 2008, Tejun Heo wrote:
[...]
Old IDE says it works for PATA. For SATA I can see it might need more
care and you might simply not be able to get the info.
Old IDE often locks up the machine hard after timeouts. I'm all for
Could you
Could you point me to some bugreports?
I would like to know more about hosts/conditions for which it happens.
The timer reset path races the I/O path races the interrupt path. That
was the vomitously foul race that persuaded me to go libata instead. I
seem to remember explaining this all some
Tejun Heo wrote:
Bartlomiej Zolnierkiewicz wrote:
On Monday 21 January 2008, Tejun Heo wrote:
[...]
Old IDE says it works for PATA. For SATA I can see it might need more
care and you might simply not be able to get the info.
Old IDE often locks up the machine hard after timeouts. I'm all
Alan Cox wrote:
>>> [ 9031.028000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
>>> frozen
>>> [ 9031.028000] ata1.00: cmd c8/00:08:90:ca:ce/00:00:00:00:00/e0 tag 0 cdb
>>> 0x0
>>> data 4096 in
>>> [ 9031.028000] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
>>>
Alan Cox wrote:
[ 9031.028000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
frozen
[ 9031.028000] ata1.00: cmd c8/00:08:90:ca:ce/00:00:00:00:00/e0 tag 0 cdb
0x0
data 4096 in
[ 9031.028000] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
We got bored
> > [ 9031.028000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> > frozen
> > [ 9031.028000] ata1.00: cmd c8/00:08:90:ca:ce/00:00:00:00:00/e0 tag 0 cdb
> > 0x0
> > data 4096 in
> > [ 9031.028000] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
> > (timeout)
We got
On Mon, 14 Jan 2008 00:19:20 +0200 Georgi Chulkov <[EMAIL PROTECTED]> wrote:
> Hello,
>
> During heavy disk load on my laptop, sometimes the IDE disk will pause for a
> second and then continue. I get this in my kernel log:
>
> [ 9031.028000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0
On Mon, 14 Jan 2008 00:19:20 +0200 Georgi Chulkov [EMAIL PROTECTED] wrote:
Hello,
During heavy disk load on my laptop, sometimes the IDE disk will pause for a
second and then continue. I get this in my kernel log:
[ 9031.028000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
[ 9031.028000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
frozen
[ 9031.028000] ata1.00: cmd c8/00:08:90:ca:ce/00:00:00:00:00/e0 tag 0 cdb
0x0
data 4096 in
[ 9031.028000] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
We got bored of waiting
Hello,
During heavy disk load on my laptop, sometimes the IDE disk will pause for a
second and then continue. I get this in my kernel log:
[ 9031.028000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
frozen
[ 9031.028000] ata1.00: cmd c8/00:08:90:ca:ce/00:00:00:00:00/e0 tag 0 cdb
Hello,
During heavy disk load on my laptop, sometimes the IDE disk will pause for a
second and then continue. I get this in my kernel log:
[ 9031.028000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
frozen
[ 9031.028000] ata1.00: cmd c8/00:08:90:ca:ce/00:00:00:00:00/e0 tag 0 cdb
36 matches
Mail list logo
