So: I changed line 186 in sys/dev/ata/ata-disk.c from
adp-num_tags = atadev-param-queuelen;
to
adp-num_tags = 0x10;
which is roughly the half of the reported queuelenght (which is 0x1F).
And, Terry, I can't avoid to disappoint you... there's absolutely *no*
change in
It seems Terry Lambert wrote:
My other hunch is that there will need to be a channel reserved
for reset commands to be queued to the disk, so that you can
queue more commands to it later (e.g. can't connect to send the
reset because of the already disconnected commands in progress).
Terry,
Søren Schmidt wrote:
It seems Terry Lambert wrote:
My other hunch is that there will need to be a channel reserved
for reset commands to be queued to the disk, so that you can
queue more commands to it later (e.g. can't connect to send the
reset because of the already disconnected
It seems Terry Lambert wrote:
Søren Schmidt wrote:
It seems Terry Lambert wrote:
My other hunch is that there will need to be a channel reserved
for reset commands to be queued to the disk, so that you can
queue more commands to it later (e.g. can't connect to send the
reset
Am Donnerstag, 18. April 2002 16:44 schrieb Søren Schmidt:
It seems Terry Lambert wrote:
Søren Schmidt wrote:
It seems Terry Lambert wrote:
My other hunch is that there will need to be a channel reserved
for reset commands to be queued to the disk, so that you can
queue more
It seems Matthias Schuendehuette wrote:
I didn't mean for the reset itself, I meant for the process. You
can't take back writes that are in progress and not acknowledged,
in order to retry them after the reset, so as to not lose data.
Oh yes you can, the ATA driver does just that in
Søren Schmidt wrote:
I didn't mean for the reset itself, I meant for the process. You
can't take back writes that are in progress and not acknowledged,
in order to retry them after the reset, so as to not lose data.
Oh yes you can, the ATA driver does just that in case of the drive
Matthias Schuendehuette wrote:
...ahh, I mean, the driver *does* take an action (it/he(?) switches
back to PIO4), but why is any UDMA-Mode no longer usable afterwards?
This is the $64 question.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the
It seems Terry Lambert wrote:
Søren Schmidt wrote:
I didn't mean for the reset itself, I meant for the process. You
can't take back writes that are in progress and not acknowledged,
in order to retry them after the reset, so as to not lose data.
Oh yes you can, the ATA driver does
Søren Schmidt wrote:
Oh yes you can, the ATA driver does just that in case of the drive
loosing its marbels.
If it worked, people wouldn't be having this problem.
Hmm, since I havn't been able to get my hands on the problem
(I've been running 3 systems here with tags all over since
It seems Terry Lambert wrote:
Hmm, since I havn't been able to get my hands on the problem
(I've been running 3 systems here with tags all over since the
first report, not a single hickup yet :( ) I can't tell whats
going on, it might be that the drive somehow gets really confused
I
PROTECTED]
Sent: Thursday, April 18, 2002 4:54 PM
Subject: Re: ATA errors on recent -current
Søren Schmidt wrote:
Oh yes you can, the ATA driver does just that in case of the drive
loosing its marbels.
If it worked, people wouldn't be having this problem.
Hmm, since I havn't been able to get
On 18 Apr, Søren Schmidt wrote:
What's your theory on it?
None so far, I've instrumented the code here, and I simply cannot
see what should go wrong (yet).
Does it make sense to give this instrumentation to someone who can
reproduce it?
Bye,
Alexander.
--
It's not a
It seems Alexander Leidinger wrote:
On 18 Apr, Søren Schmidt wrote:
What's your theory on it?
None so far, I've instrumented the code here, and I simply cannot
see what should go wrong (yet).
Does it make sense to give this instrumentation to someone who can
reproduce it?
Not
Am Donnerstag, 18. April 2002 17:54 schrieb Terry Lambert:
I wish someone who is having the problem would try the three
hacks I suggested, and report back. I personally can't reproduce
the problem here, either.
Ok, ok... ;-) I start *now*. I just compiled a new -current world
(...puhh)
Am Donnerstag, 18. April 2002 17:54 schrieb Terry Lambert:
I wish someone who is having the problem would try the three
hacks I suggested, and report back. I personally can't reproduce
the problem here, either.
So: I changed line 186 in sys/dev/ata/ata-disk.c from
adp-num_tags =
Matthias Schuendehuette wrote:
Am Donnerstag, 18. April 2002 17:54 schrieb Terry Lambert:
I wish someone who is having the problem would try the three
hacks I suggested, and report back. I personally can't reproduce
the problem here, either.
So: I changed line 186 in
On 16 Apr, Matthias Schuendehuette wrote:
Then I tried various combinations of UDMA100/66/33 and wc=0/1 - it
nearly doesn't change anything. If WC was enabled, I saw errors
concerning tags 0 *and* 1, whereas without write caching only tag=0 was
mentioned. I should say that my simple test
Alexander Leidinger wrote:
device model IC35L060AVER07-0
** **
These match the test in ad_tagsupported(); I have to wonder about:
device model IC35L060AVER07-0
**
firmware revision ER6OA44A
I also have to
On 17 Apr, Terry Lambert wrote:
device model IC35L060AVER07-0
** **
These match the test in ad_tagsupported(); I have to wonder about:
device model IC35L060AVER07-0
**
Can you be more specific?
firmware
Hello,
Am Mittwoch, 17. April 2002 03:14 schrieben Sie:
Matthias Schuendehuette wrote:
I used 'atacontrol' to read the number of tags allowed: it is 31
(0x1F). Perhaps Soren could tell me how to force it to, say, 0x10?
You have to modify the source code in ~line 180 of
Matthias Schuendehuette wrote:
My hunch, which is why I suggested decreasing the number of
tags seen by the driver, is that the tagged queues are over
used, and this locks the disk up. [...]
Yes, I understand this (I for myself had already your
'off-by-one'-suspicion - it's obvious if
[...]
Since you have one of these beasts, could you maybe try changing
the number of tagged command queue entries you permit to be used
at one time?
Of course, I'll do it as soon as...
1) I'm at home again... ;-)
2) Someone tells me how to achive that. I looked at 'man 8 atacontrol'
as
Hi Terry and you all,
On Tuesday, 16. April 2002 01:48 you wrote:
[...]
As I said: it could be drive settings unrelated to the code
itself being correct. I've given three suggestions to verify
this, one way or the other:
1)Control the drive DMA speed down
2)Pretend the maximum
[EMAIL PROTECTED] wrote:
As I said: it could be drive settings unrelated to the code
itself being correct. I've given three suggestions to verify
this, one way or the other:
1)Control the drive DMA speed down
I *did* test with UDMA66 instead of UDMA100 and it was even worse...
Matthias Schuendehuette wrote:
On Tuesday, 16. April 2002 01:48 you wrote:
[...]
As I said: it could be drive settings unrelated to the code
itself being correct. I've given three suggestions to verify
this, one way or the other:
1)Control the drive DMA speed down
2)
On 17-Apr-2002 Terry Lambert wrote:
What was consistent thru all test was, that the disk operates quite
some time until the error occures the first time. After that, it is not
possible to access the disk in UDMA-Mode any more, regardeless *which*
UDMA-Mode it is. 'Quite some time' means
John Baldwin wrote:
My hunch, which is why I suggested decreasing the number of
tags seen by the driver, is that the tagged queues are over
used, and this locks the disk up. My best guess is an off-by-one
or an exceptional condition handler that was not an issue until
recently, because
Giorgos Keramidas wrote:
ad0: READ command timeout tag=1 serv=1 - resetting
ata0: resetting devices .. ad0: invalidating queued requests
done
Turn off tagged queing. S?ren knows about this error and tries to
reproduce it (but fails as far as I know).
I've seen this quite a few
It seems Terry Lambert wrote:
Giorgos Keramidas wrote:
ad0: READ command timeout tag=1 serv=1 - resetting
ata0: resetting devices .. ad0: invalidating queued requests
done
Turn off tagged queing. S?ren knows about this error and tries to
reproduce it (but fails as far as I
On 15 Apr, Giorgos Keramidas wrote:
I updated to -current today and am now getting these errors
ad0: READ command timeout tag=1 serv=1 - resetting
ata0: resetting devices .. ad0: invalidating queued requests
done
Turn off tagged queing. S?ren knows about this error and tries to
It seems Alexander Leidinger wrote:
I've seen this quite a few times, but I can't reliably reproduce it
yet. It seems to hit me a lot when the ad0 drive spins like crazy
doing stuff that is heavy on disk I/O. Disabling tag queueing now to
see if this fixes things. But even if it does,
On 14 Apr, Terry Lambert wrote:
Turn off tagged queing. S?ren knows about this error and tries to
reproduce it (but fails as far as I know).
I've seen this quite a few times, but I can't reliably reproduce it
yet. It seems to hit me a lot when the ad0 drive spins like crazy
doing stuff
On 15 Apr, =?x-unknown?Q?S=F8ren?= Schmidt wrote:
Some people see this after the mega MFC on -stable too.
Could I have you guys try this simple patch ?
It failed to apply, applied it by hand. Compiling a new kernel now.
Bye,
Alexander.
--
Where do you think you're going
It seems Alexander Leidinger wrote:
On 15 Apr, Søren Schmidt wrote:
Some people see this after the mega MFC on -stable too.
Could I have you guys try this simple patch ?
Does not work.
As in:
No change or breaks completely (if so how)...
-Søren
To Unsubscribe: send mail to
On 15 Apr, =?x-unknown?Q?S=F8ren?= Schmidt wrote:
Some people see this after the mega MFC on -stable too.
Could I have you guys try this simple patch ?
Does not work.
As in:
No change or breaks completely (if so how)...
Sorry: No change.
Bye,
Alexander.
--
The
Alexander Leidinger wrote:
On 14 Apr, Terry Lambert wrote:
Is your drive perchance an IBM DTLA?
It's known to have these problems.
Does this also apply to other IBM drives?
Potentially. IBM renamed the part number when the drives got
known to be dogs. I thought they also defaulted
Alexander Leidinger wrote:
Some people see this after the mega MFC on -stable too.
Could I have you guys try this simple patch ?
Does not work.
No change or breaks completely (if so how)...
Sorry: No change.
Download the Windows executable I pointed to in a previous posting.
Run it.
It seems Terry Lambert wrote:
Søren Schmidt wrote:
Is your drive perchance an IBM DTLA?
It's known to have these problems.
Cool! would you like to share where that information is available so
I can possibly work around the problem ??
IBM DTLA drives are known to be
Søren Schmidt wrote:
Is your drive perchance an IBM DTLA?
It's known to have these problems.
Cool! would you like to share where that information is available so
I can possibly work around the problem ??
IBM DTLA drives are known to be problematic. If you use that
in a search engine,
It seems Terry Lambert wrote:
IBM DTLA drives are known to be problematic. If you use that
in a search engine, it will find numerous references to the
drive electronics being too slow for sustained access to the
sectors closes to the spindle.
This thread is about tagged queueing
Søren Schmidt wrote:
For a more scientific test, downloading the firmware tool and
setting the DMA transfer rate down, and checking for problems,
would be pretty overwhelming evidence. Personally, I don't have
any of the buggers lying around to test with any more.
Why on earth would
It seems Terry Lambert wrote:
Søren Schmidt wrote:
For a more scientific test, downloading the firmware tool and
setting the DMA transfer rate down, and checking for problems,
would be pretty overwhelming evidence. Personally, I don't have
any of the buggers lying around to test
On 15 Apr, Terry Lambert wrote:
Obviously, turning off tagged commands works, according to at least
one person who is reporting the problem.
It helps every one I know of.
[...]
Limiting the outstanding tagged commands to less than the advertised
amount would actually be my first choice of
On 15 Apr, Søren Schmidt wrote:
Again that has *nothing* to do with the DTLA drives and DMA speed
and the phase of the moon...
But perhaps it depends on the distance between the drive and the
nordpole... the ones with the problems are all more far away from it
than you... ;-)
But it shows
On 15 Apr, Giorgos Keramidas wrote:
Is your drive perchance an IBM DTLA?
It's known to have these problems.
Nay. A Western Digital disk I bought about 2.5 years ago.
And it does tagged queing? I thought IBM is the only manufacturer of
such IDE drives...
Bye,
Alexander.
--
It seems Giorgos Keramidas wrote:
On 2002-04-14 23:46, Terry Lambert wrote:
Is your drive perchance an IBM DTLA?
It's known to have these problems.
Nay. A Western Digital disk I bought about 2.5 years ago.
Hmm, AFAIK WD newer had a disk that worked right with tags,
and I've newer been
On 2002-04-15 15:56, Sren Schmidt wrote:
It seems Giorgos Keramidas wrote:
On 2002-04-14 23:46, Terry Lambert wrote:
Is your drive perchance an IBM DTLA?
It's known to have these problems.
Nay. A Western Digital disk I bought about 2.5 years ago.
Hmm, AFAIK WD newer had a disk
I'm very sorry if I will be a bit unpolite, but I have to mail the
following statement concerning the DTLA-Disks and FreeBSD:
It may be all true and horrible, but -
I still have an old FreeBSD Test-Installation (45GB are big enough :-)
with a 4.4-STABLE as of Okt 23, 2001...
It boots off the
Matthias Schuendehuette wrote:
I still have an old FreeBSD Test-Installation (45GB are big enough :-)
with a 4.4-STABLE as of Okt 23, 2001...
It boots off the DTLA, uses tagged-queuing and connects using UDMA100...
... and doesn't have any problems!!
So, to bring some of you down to
On 14 Apr, David W. Chapman Jr. wrote:
I updated to -current today and am now getting these errors
ad0: READ command timeout tag=1 serv=1 - resetting
ata0: resetting devices .. ad0: invalidating queued requests
done
Turn off tagged queing. Søren knows about this error and tries to
Hello,
just as an additional datapoint. My 5.0-current system panics
during boot when I enable tagged queing.
This did not happen with a system built on March 16th, but there
have been numerous changes on the ata-subsystem inbetween and I was
not able to trace this down to a specific change.
-On [20020414 17:00], Michael Class ([EMAIL PROTECTED]) wrote:
Quoting the real panic message would have been nice.
ad_service (e5217c00,1,12788100,0,0) +0x36
ad_transfer (e51fcdc0)
ata_start
adstrategy
ar_rw
ar_promise_read_conf
ata_raiddisk_attach
ad_attach
This looks a lot like the panic on
On 2002-04-14 10:34, Alexander Leidinger wrote:
On 14 Apr, David W. Chapman Jr. wrote:
I updated to -current today and am now getting these errors
ad0: READ command timeout tag=1 serv=1 - resetting
ata0: resetting devices .. ad0: invalidating queued requests
done
Turn off tagged
54 matches
Mail list logo
