I create a kernel thread in my driver using kthread_create. When the thread routine executes, it tries to print out a debug message using 'printf'. When this executes, I trap in a panic with the following trace: panic() at panic+0x174 trap() at trap+0x3b4 -- fast data access mmu miss tar=0 %o7=0xf000d784 _end() at 0xf0008fd0 openfirmware() at openfirmware+0x18 OF_write() at OF_write+0x14 ofw_cons_putc() at ofw_cons_putc+0x3c cnputc() at cnputc+0x7c putchar() at putchar+0x5c kvprintf() at kvprintf+0x648 printf() at printf+0x4C Same code works fine on i386 machines. How-To-Repeat: Create a driver that creates a thread and do a printf in the thread routine.
This problem only occurs on SMP machines after the second processor is started. It is not a problem on UP machines or on SMP machines that 'printf' in a kernel thread before the second CPU is started. Is "openfirmware" SMP capable? Can "openfirmware" be executed on CPUs other than CPU #0? This kills any SMP debugging for me because I use printf's frequently in a multi-threaded environment. cd -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm
This problem only occurs if the SPARC system is running in SMP mode. You must try this in a driver that gets loaded AFTER the second CPU has started and the printf must occur when the code is running on the second CPU. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
I'm sorry that this bug didn't get any attention. In general printf() is indeed SMP safe when using an ofw backend, at least in recent versions of FreeBSD. Since FreeBSD no longer supports a sparc64 platform, I'm going ahead and closing the bug.