Date: Mon, 3 Aug 2009 10:57:20 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: Ed Schouten <ed@80386.nl>, src-committers@freebsd.org, svn-src-all@freebsd.org, Alfred Perlstein <alfred@freebsd.org>, Navdeep Parhar <nparhar@gmail.com>, svn-src-head@freebsd.org Subject: Re: svn commit: r195960 - in head/sys/dev/usb: . controller input (regression patch) Message-ID: <alpine.BSF.2.00.0908031048001.36693@fledge.watson.org> In-Reply-To: <200908031129.06315.hselasky@c2i.net> References: <200908030923.12867.hselasky@c2i.net> <alpine.BSF.2.00.0908030909220.1507@fledge.watson.org> <20090803082838.GE1292@hoeg.nl> <200908031129.06315.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Aug 2009, Hans Petter Selasky wrote: > On Monday 03 August 2009 10:28:38 Ed Schouten wrote: >> * Robert Watson <rwatson@FreeBSD.org> wrote: >>> I'm a bit surprised the timed key repeat in this patch would work properly >>> in DDB, as microtime(9) relies on interrupts firing for updated >>> timestamps. The availability of interrupts for polled input consumers >>> varies, but in general this is not true (for example) at the DDB command >>> prompt. Does this code work correctly when time stands still? >> >> Apart from that, who gives a *beep* about keyboard repeat while inside the >> debugger. I have to confess it would be irritating to press backspace >> multiple times, instead of holding the key pressed, but still, it's not >> worth it. > > I think getmicrotime relies on interrupts, while microtime doesn't. > > See "man microtime". You're right, but that doesn't make things better :-). Some of the tc_get_timecount() calls are safe in the DDB environment, but several are not. In particular, tick_get_timecount_mp() and i8254_get_timecount() both acquire locks, the former the thread scheduler lock, and the latter a dedicated spinlock. This produces the opportunity for rather nasty deadlocks in DDB, especially tick_get_timecount_mp() on sparc64. This was the bug I was actually looking for in your patch, but then misread microtime() and concluded you had a different one. :-) I would much rather not have DDB rely on, for example, not contending thread_lock(), than have key repeat in DDB. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0908031048001.36693>