Greg,
I have another report of this problem, and I have a patch for you to try
out, will
be sending it out a bit later today.
Jack
On Sun, Apr 26, 2009 at 5:50 AM, Greg Byshenk wrote:
> I have one machine that is seeing watchdog timeouts on em0, running
> 7-STABLE
> amd64 as of 2009.04.19, an
I have one machine that is seeing watchdog timeouts on em0, running 7-STABLE
amd64 as of 2009.04.19, and also some other more perverse errors.
Twice now in the last 48 hours, this machine has become unreachable via the
network, and connecting to the console shows an endless string of
[...]
Mike> Er. This is bad; tr_status == 2 means that the command has been
Mike> completed; it shouldn't still be on the busy queue. Can you
Mike> check to make sure you have the right queue here?
Well, it looks like I had the wrong queue before. Blush.
At least this time tr_status is 1. Not sure i
At 05:20 PM 3/21/2001 -0800, Mike Smith wrote:
>This is obviously a really weird case; possibly either an extremely
>narrow race, or some very borderline PCI issue. One question I should
>have asked, but don't recall whether you answered; are you using an AMD
>K7 system by any chance? We've seen
Mike> Sorry, the above code is totally bogus; I'm kinda delirious
Mike> (feverish) right now.
Mike> Try
Mike> TAILQ_FOREACH(tr, &sc->twe_busy, tr_link)
Yup, that is what I half figured out half guessed at. (Helps to have
other code to look through!)
Mike> [...] there's a pattern of some sor
Mike> If you can add another function like twe_printstate that invokes
Mike> twe_print_request on each of the requests on the busy queue and
Mike> let me know what they look like, that might give me some clues.
Doug> OK, I haven't written the twe_printstate function yet, but I
Doug> think I have
Doug> Mike, thanks for all your help and the time you've invested in
Doug> this! What we can do to assist?
Mike> Do you have any coding experience? I can't reproduce this here,
Mike> but what I want to do is see what the command that's stuck on
Mike> the busy queue looks like.
Sure, sounds like
> The first time I did this I thought something was broken when I
> watched the newfs output those duplicate super block locations. It was
> about 10 seconds between each block! After a search of the FreeBSD
> lists I found a reference to initializing the array, and just waited.
>
> On ttyv1 the
Doug> It takes a surprisingly long time to initialize the array.
Mike> The delay is normal. When you setup anything other than a RAID0
Mike> array, the card is actually doing work to your drives in the
Mike> background. Grab the array manager from
Mike> http://people.freebsd.org/~msmith/RAID/3wa
At 11:54 AM 3/18/2001 -0600, [EMAIL PROTECTED] wrote:
>When we bound the array this last time, we took all the defaults: A
>64KB stripe size, disk write cache enabled. It takes a surprisingly
>long time to initialize the array. What I did is to boot off the
>4.3 floppies (no cdrom
** Mike Tancsa <[EMAIL PROTECTED]> on Thu, 15 Mar 2001 14:33:29 -0500
** in [Re: 3ware problems ] writes:
Mike> I tried yesterday to stress the machine with 25 simultaneous
Mike> bonnie -s 500 &
Mike> Although the machine was sluggish, it still worked. Similarly,
Mike>
> Drat. There it is; you've got a command that looks like it's stuck in
> the adapter.
>
> try changing the value of TWE_Q_LENGTH in /sys/dev/twe/twereg.h to 100 and
> see if you can reproduce it.
Well, I just woke up and mysqd was stuck again in getblk, this time with a
TWE_Q_LENGTH of 100:
db
> Drat. There it is; you've got a command that looks like it's stuck in
> the adapter.
I'll go grab the can of WD-40. :)
> I didn't see you respond to Mike T - are you using 64k or 128k stripes?
I didn't get his query until I had already started the mysqd trying to break
things. And now I'm
13 matches
Mail list logo
