> > 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 abs
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 sys/dev/at
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 = atadev->
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)
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
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
;; <[EMAIL 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,
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
"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 a
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, th
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 th
"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
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 doe
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
>
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
"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 disconn
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).
Ter
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 obvi
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
> /sys/dev/at
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?
>> firm
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 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 te
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
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' mea
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
>
[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
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 m
> [...]
> 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'
a
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 t
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
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.
Well that shoots that idea down.
Try hacking the code to limit it to 3/4ths the num
On 2002-04-15 15:56, S&psgr;ren 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
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
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.
--
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.
G.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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, 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
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 ar
"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
ROTECTED]>
To: "Alexander Leidinger" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, April 15, 2002 12:53 PM
Subject: Re: ATA errors on recent -current
> Alexander Leidinger wr
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
"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 searc
"Søren Schmidt" wrote:
> 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 pr
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 know
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
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 defa
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.
-
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 m
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.
Bye,
Alexander.
--
Actually, Microsoft is sort of a mixture between the Borg and the Ferengi.
http://www.Leidinger.net
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
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
>
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
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
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 (bu
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 th
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
-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 p
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.
The
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
repr
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
--
David W. Chapman Jr.
[EMAIL PROTECTED] Raintree Network Services, Inc.
[EMAIL PROTECTED] FreeBSD Committer
> >I cvsupped this morning and I just had a chance to build a new kernel, and
> >now I get a "cannot mount root" and it drops into some kind of commandline
> >where I can enter a root for it to mount. This is the error it gives me
> >now:
> >
> >ata0-slave: WARNING: WAIT_INTR active=ATA_WAIT_READY
On Sat, 19 Feb 2000, Kenneth Wayne Culver wrote:
>I cvsupped this morning and I just had a chance to build a new kernel, and
>now I get a "cannot mount root" and it drops into some kind of commandline
>where I can enter a root for it to mount. This is the error it gives me
>now:
>
>ata0-slave: WA
I cvsupped this morning and I just had a chance to build a new kernel, and
now I get a "cannot mount root" and it drops into some kind of commandline
where I can enter a root for it to mount. This is the error it gives me
now:
ata0-slave: WARNING: WAIT_INTR active=ATA_WAIT_READY
ata0-slave: ata_c
Whilst my -current system has stopped crashing every night, I got some
odd log messages last night. At the time the system should have been
doing a cvs update (or possibly a make world). There was nothing in
the CD-ROM (ata0-slave) at the time. I'm running the latest version
of ata (about 7 day
Today Oliver Fromme wrote:
> The comment in LINT about AUTO_EOI_2 sounds pretty suspicous,
> so I never even tried it: "it works for some clones and some
> integrated versions." That sounds to me like "it works on a
> very limited set of hardware (and if you're lucky)."
I've only got one out o
On Tue, 21 Dec 1999 17:13:20 +0100, D. Rock wrote:
>Oliver Fromme schrieb:
>> Doug White wrote in list.freebsd-current:
>> > On Tue, 21 Dec 1999, Soren Schmidt wrote:
>> > > It seems Dieter Rothacker wrote:
>> > > > The solution for me was to recompile the kernel without AUTO_EOI1 and
>> > >
Oliver Fromme schrieb:
>
> Doug White wrote in list.freebsd-current:
> > On Tue, 21 Dec 1999, Soren Schmidt wrote:
> > > It seems Dieter Rothacker wrote:
> > > > The solution for me was to recompile the kernel without AUTO_EOI1 and
> > > > AUTO_EOI2.
> > >
> > > Those options newer worked (
Doug White wrote in list.freebsd-current:
> On Tue, 21 Dec 1999, Soren Schmidt wrote:
> > It seems Dieter Rothacker wrote:
> > > The solution for me was to recompile the kernel without AUTO_EOI1 and
> > > AUTO_EOI2.
> >
> > Those options newer worked (for me at least) reliably with anything
On Tue, 21 Dec 1999, Soren Schmidt wrote:
> It seems Dieter Rothacker wrote:
> >
> > Using the new board, I get "waiting for interrupt" errors, and the system
> > freezes while trying to mount the disks (with kernel from 12/03) or the
> > system freeezes before being able to detect the drives (w
It seems Dieter Rothacker wrote:
>
> Using the new board, I get "waiting for interrupt" errors, and the system
> freezes while trying to mount the disks (with kernel from 12/03) or the
> system freeezes before being able to detect the drives (with kernel from
> 12/20).
>
> The solution for me wa
Hi,
I do not know if this issue has already been solved, but I cannot remember
having read something about it.
ATA errors directly after booting the kernel seem to be related to the usage
of the fast IRQ tuning parameter "AUTO_EOI".
Last night I migrated from my
GA586DX (Dualbo
71 matches
Mail list logo
