How to report bugs (Re: 6.2-STABLE deadlock?)

[Oleg Derevenetz]

Цитирую Kris Kennaway <kris at obsecurity.org>:

> > Oleg Derevenetz wrote:
> > > ??????? LI Xin <delphij at delphij.net>:
> > [...]
> > >> I'm not very sure if this is specific to one disk controller. 
> Actually
> > >> I got some occasional reports about similar hangs on amd64
> 6.2-RELEASE
> > >> (slightly patched version) that most of processes stuck in the
> 'ufs'
> > >> state, under very light load, the box was equipped with amr(4)
> RAID.
> > >>
> > >> I was not able to reproduce the problem at my lab, though, it's
> still
> > >> unknown that how to trigger the livelock :-(  Still need some
> > >> investigate on their production system.
> > > 
> > > I reported simular issue for FreeBSD 6.2 in audit-trail for
> kern/104406:
> > > 
> > > http://www.freebsd.org/cgi/query-pr.cgi?pr=104406&cat=
> > > 
> > > and there should be a thread related to this. Briefly, I suspects
> that this is 
> > > related to nullfs filesystems on my server and when I cvsuped to
> FreeBSD 6.2-
> > > STABLE with Daichi's unionfs-related patches and replaced
> nullfs-mounted fs 
> > > with unionfs-mounted (that was done 10.03.07) problem is gone (seems
> to be so, 
> > > at least).
> > 
> > Hmm...  Seems to be different issues.  The problem I have received was
> a
> > pgsql server (no nullfs/unionfs involved), and the hang always happen
> > when it is not being heavily loaded (usually in the morning, for
> > instance, and there is no special configuration, like scheduled tasks
> > which can generate disk load, etc., only the entropy harvesting), so
> > this is quite confusing.
> 
> Yes, a large part of the confusion is the unfortunate tendency of
> people to do the following:
> 
> <user1> my system hangs/panics/etc
> <user2> my system hangs/panics/etc too; it must be the same problem!
> 
> What we really need is for every FreeBSD user who encounters a
> hang/panic/etc to avoid jumping to conclusions -- no matter how many
> superficial similarities there may seem to you -- and instead go
> through the relevant steps described here:
> 
>  
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-
handbook/kerneldebug.html
> 
> Until you (or a developer) have analyzed the resulting information,
> you cannot definitively determine whether or not your problem is the
> same as a given random other problem, and you may just confuse the
> issue by making claims of similarity when you are really reporting a
> completely separate problem.

Not all people can do deadlock debugging, though. In my case turning on 
INVARIANTS and WITNESS leads to unacceptable performance penalty due to heavily 
loaded server. So I can only describe my case, actions and result without 
providing any debug information.