A "pending ops" panic can be induced in fairly short order by running the SMTP performance tests that come with Postfix. Specifically, run smtpstone/smtp-source running many parallel deliveries into a Postfix mail daemon setup running on the same machine. I had always assumed that this meant softupdates was getting too behind (the test delivers hundreds of mails per second with decent disk setups). I wasn't able to mentally parse the code well enough to confirm that.
This is in all 3.x revisions that I've tested, since from back around the time of 3.0-CURRENT's great ELF transition, to 3.3-RELEASE. If somebody's interested, I can create this setup and try to duplicate the problem again.
> -----Original Message-----
> From: Matthew Dillon [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 03, 2000 4:21 PM
> To: George Cox
> Cc: [EMAIL PROTECTED]
> Subject: Re: Repeated softupdates panics in 3.3-STABLE
>
>
> :On 03/01 16:29, Keith Stevenson wrote:
> :
> :> It looks like I may have spoken too soon when I mentioned
> that I had no
> :> problems with softupdates on my postfix based mail server.
> I have now had
> :> two panics in the last month with a panicstr of
> "softdep_lock: locking
> :> against myself". I thought that the first one might have
> been a fluke until
> :> it repeated itself today.
> :
> :I too have seen this "softdep_lock: locking against myself"
> panic on a Postfix
> :server. I was able to trigger it I think maybe twice by
> issuing a 'postfix
> :flush' command. :-/ This _was_ some months ago, when there
> was the odd commit
> :to the softupdates code going in, which suggests it's kind
> of a long standing
> :bug. :-(
>
> Well, in Keith's case the locking-against-myself panic is not the
> cause, but the effect of the 'softdep_fsync: pending ops' panic
> that occured just before it.
>
> I've never seeing a pending ops panic before, this is going to be
> one for Kirk to track down. Be sure to keep your core dump and
> your debug kernel. In fact, if you could gzip them both
> up and make
> them available to me and Kirk via a hidden ftp or hidden URL I
> would appreciate it. NOTE! Kernel core dumps often contain
> sensitive information such as pieces of the password file, do not
> make your core available to the general lists!
>
> -Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
