Strange behavior of kernel module (output terminated)

[Dag-Erling Smørgrav]

John Baldwin <jhb at freebsd.org> writes:
> Dag-Erling Smørgrav <des at des.no> writes:
> > I'm not sure it's such a good idea to use uprintf() here.  The event
> > handler can be called in non-process context.
> If you are doing a kldload post-boot it is actually done from some sort of 
> process context.  We run module handlers synchronously from the kldload(2) 
> syscall.

Sure, but not when the module is loaded by the boot loader (note "can",
not "will")

> > You filled up a buffer somewhere...
> Does uprintf() require the caller to flush the output to the tty somehow?  If 
> so, that seems to be a bug.  Nothing in the uprintf(9) manpage suggests that 
> the output should be manually flushed.

I tried to read through the uprinf() code paths (into the tty layer
etc).  I didn't get very far, but I discovered two things:

1) The printf() code uses uninitialized or partially-initialized
   variables (grep pca)

2) There may be conditions in which tty_putchar() fails due to a buffer
   filling up, though I'm not sure they apply in this particular
   situation.  Since uprintf() returns the number of characters actually
   written, this is easy to test.

DES
-- 
Dag-Erling Smørgrav - des at des.no