Date: Wed, 29 Nov 2006 15:40:38 -0700 From: Scott Long <scottl@samsco.org> To: John Birrell <jb@what-creek.com> Cc: Rene Ladan <r.c.ladan@gmail.com>, jb@freebsd.org, freebsd-current@freebsd.org Subject: Re: calcru-triggered panic? Message-ID: <456E0C66.4060404@samsco.org> In-Reply-To: <20061129223221.GA359@what-creek.com> References: <45622068.2050705@student.tue.nl> <200611291204.03716.jhb@freebsd.org> <20061129223221.GA359@what-creek.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John Birrell wrote: > On Wed, Nov 29, 2006 at 12:04:03PM -0500, John Baldwin wrote: >> On Monday 20 November 2006 16:38, Rene Ladan wrote: >>> Hi, >>> >>> I got the attached panic on CURRENT 2006-11-17. >>> >>> It was preceded by a lot of 'calcru' messages. >> The calcru messages you can ignore. >> >> This is the real problem: >> >> panic: blockable sleep lock (sleep mutex) tty >> @ /usr/src-current/sys/kern/kern_event.c:1670 >> >> This panic is due to the recent changes to printf to try to buffer the printf >> output. It now runs cnputc() under a critical section and syscons(4) tries >> to do a ttwakeup() which invokes KNOTE() and tries to lock a regular mutex >> while inside the critical section. I'm not sure how best to fix this. > > I would like to go back to using a printf buffer on the stack > (like I had in my original implementation). The downside of > doing that is that it places more stress on the stack and for > things like cam, that is an issue, so I am told. > > -- > John Birrell It's probably less of an issue now that it used to be, since I/O is decoupled through GEOM threads. In 4.x, you could have a stack that went from the syscall, through VFS, UFS, the block layer, CAM, and finally the device driver. When I was working on RAIDFrame, adding just a couple hundred bytes of stack usage would cause it to blow out. But as I said, it might not be as much of an issue now. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?456E0C66.4060404>