threads/136345: Recursive read rwlocks in thread A cause
deadlock with write lock in thread B
attilio at freebsd.org
Thu Jul 16 12:48:13 UTC 2009
2009/7/16 Attilio Rao <attilio at freebsd.org>:
> 2009/7/15 Nick Esborn <nick at desert.net>:
>> The following reply was made to PR threads/136345; it has been noted by GNATS.
>> From: Nick Esborn <nick at desert.net>
>> To: bug-followup at FreeBSD.org,
>> rink at FreeBSD.org
>> Subject: Re: threads/136345: Recursive read rwlocks in thread A cause deadlock with write lock in thread B
>> Date: Wed, 15 Jul 2009 14:32:38 -0700
>> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>> Content-Transfer-Encoding: 7bit
>> Even after the above patch, I still run into occasional MySQL thread
>> deadlocks, which I originally described in what is now threads/135673.
>> I also posted on freebsd-current a few days ago:
>> I'd be happy to collect whatever data would be helpful in tracking
>> down this deadlock. This only seems to happen under our production
>> workload, so that might make it harder to capture meaningful debug
>> data, but I'm certainly willing to try. I can also arrange for
>> developer access to the system in question, if that would help
> So did you backport this to 7 and still experience deadlocks?
> I just committed the fix to HEAD not to STABLE branch.
Ok, I got, you just upgraded.
Can you try the following things?:
- Upgrade to the -CURRENT of today
- Recompile the kernel with the following options:
KDB, DDB, SCHED_ULE, PREEMPTION, FULL_PREEMPTION, INVARIANT_SUPPORT,
- When the deadlock takes place break into DDB and please retrieve the
db> show allpcpu
db> show alllock
- Save them with a serial console output or using the textdump(4) format.
(if necessary read the ddb(4) and textdump(4) before to set up the
This would shade a light if the problem lives within the kernel or not.
Peace can only be achieved by understanding - A. Einstein
More information about the freebsd-threads