options RND_COM considered dangeous

[Rafal Boni <rafal%pobox.com@localhost>]

I just got a locking-against-myself panic on an XScale pxa250 (ARM)
system running a -current from shortly before the creation of the
netbsd-5 branch while doing a build of some stuff from pkgsrc.  The
trace (partially copied by hand because I over-wrote the log :() is
the following:

panic: lock error
Stopped in pid 12381.1 (ftp) at netbsd:cpu_Debugger+0x4:        bx      r14
db> tr
panic+0x10
lockdebug_abort+0xc
callout_reset+0xc
rnd_add_uint32+0xc
comintr+0xc
pxa2x0_irq_handler+0xc
callout_reset+0xc
dosetitimer+0xc
sys_setitimer+0xc
syscall+0xc
swi_handler+0xc

(The lock error in this case was a locking-against-myself panic; this is
 a LOCKDEBUG/DIAGNOSTIC kernel).

It looks like the problem is that the callout data is protected by locks
at IPL_SCHED whereas com(4) interrupts at IPL_HIGH; the lock that is being
locked recursively is the callout lock.

I don't know if there are serial drivers that run at-or-below-IPL_SCHED,
but if not, it might make sense to remove the RND_COM option.

--rafal

-- 
  Time is an illusion; lunchtime, doubly so.     |/\/\|           Rafal Boni
                   -- Ford Prefect               |\/\/|      
rafal%pobox.com@localhost