Re: Strange behavior of kernel module (output terminated)

John Baldwin <jhb@freebsd.org> writes:
> Dag-Erling Sm=C3=B8rgrav <des@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 o=
f=20
> process context.  We run module handlers synchronously from the kldload(2=
)=20
> 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=20
> so, that seems to be a bug.  Nothing in the uprintf(9) manpage suggests t=
hat=20
> 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
--=20
Dag-Erling Sm=C3=B8rgrav - des@des.no
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"