Re: CVS commit: [newlock2] src/sys/kern

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

> On Thu, Apr 17, 2008 at 11:26:14PM +0900, YAMAMOTO Takashi wrote:
> 
> > > Module Name:      src
> > > Committed By:     ad
> > > Date:             Sat Jan 20 00:19:01 UTC 2007
> > > 
> > > Modified Files:
> > >   src/sys/kern [newlock2]: subr_prf.c
> > > 
> > > Log Message:
> > > Don't take the proclist_mutex for now; wait until tty locking is worked 
> > > out.
> > > 
> > > 
> > > To generate a diff of this commit:
> > > cvs rdiff -r1.103.2.2 -r1.103.2.3 src/sys/kern/subr_prf.c
> > > 
> > > Please note that diffs are not public domain; they are subject to the
> > > copyright notices on the relevant files.
> > 
> > is there any plan to fix this?
> 
> I'd forgotten about that one. It does need to be fixed.
>  
> > while the proclist_mutex re-enter problem seems gone,
> > some drivers seems to call tprintf from interrupt context.
> 
> Do you know of an example?

some of the following tprintf seem to be IPL_BIO.
i haven't checked uprintf.

dev/gpib/ct.c:805:                                      tprintf(sc->sc_tpr,
dev/gpib/ct.c:809:                                      tprintf(sc->sc_tpr,
dev/gpib/ct.c:813:                                      tprintf(sc->sc_tpr,
dev/gpib/mt.c:561:                      tprintf(sc->sc_ttyp,
dev/gpib/mt.c:581:                      tprintf(sc->sc_ttyp,
dev/gpib/mt.c:995:                      tprintf(sc->sc_ttyp,
arch/hp300/dev/ct.c:786:                                        
tprintf(sc->sc_tpr,
arch/hp300/dev/ct.c:790:                                        
tprintf(sc->sc_tpr,
arch/hp300/dev/ct.c:794:                                        
tprintf(sc->sc_tpr,
arch/hp300/dev/mt.c:479:                        tprintf(sc->sc_ttyp,
arch/hp300/dev/mt.c:499:                        tprintf(sc->sc_ttyp,
arch/hp300/dev/mt.c:904:                        tprintf(sc->sc_ttyp,

> I think it would be better to prevent that and
> require thread context for tprintf/uprintf. There should be very little code
> left in the tree that accesses process state from a hardware interrupt
> handler. itimers are one existing problem area that I know of.

sure.

YAMAMOTO Takashi

> 
> Andrew