Is it possible to implement interrupt time printk's reliably?

Is it possible to implement interrupt time printk's reliably?

[Jon Smirl]

Problem:
1) Some operations on graphics cards cannot be stopped once they are started.
It's not reasonable to turn interrupts off around these operations.
2) Kernel developers want console printk's to work from interrupt routines.

How do you fix this situation?

1) Grpahics driver has started non-restartable operation. For example
transferring a bitmap. This is not an automatic DMA operation, CPU involvement
is needed.
2) Interrupt happens
3) Printk happens from interrupt.

Now we're stuck. The graphics chip is in a non-interruptible state and printk
wants to use it.

We need some mechanism to get back to the driver code and finish the
non-restartable operation before the printk can be allowed to proceed.

Another solution also comes to mind. Mark the appropriate sections in the video
driver with BEGIN/END_INT_PRINTK. Then add a kernel build option to convert
these macros to en/disable interrupts if interrupt time printk's are allowed.
Would it be acceptable to disable interrupts for signifcant time on a
development kernel where the developer is printk'ing from interrupts?


=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

Re: Is it possible to implement interrupt time printk's reliably?

[Andrew Morton]

Jon Smirl <jonsmirl@yahoo.com> wrote:
>
> Problem:
>  1) Some operations on graphics cards cannot be stopped once they are started.
>  It's not reasonable to turn interrupts off around these operations.
>  2) Kernel developers want console printk's to work from interrupt routines.
> 
>  How do you fix this situation?

Really you should use spin_lock_irqsave() on some driver-private lock
around the operation.  Why is it not reasonable to disable irq's? 
Duration, presumably?

If you're in process context you can use acquire_console_sem(), which will
serialise against printk.

Re: Is it possible to implement interrupt time printk's reliably?

[Jon Smirl]

--- Andrew Morton <akpm@osdl.org> wrote:
> Jon Smirl <jonsmirl@yahoo.com> wrote:
> >
> > Problem:
> >  1) Some operations on graphics cards cannot be stopped once they are
> started.
> >  It's not reasonable to turn interrupts off around these operations.
> >  2) Kernel developers want console printk's to work from interrupt routines.
> > 
> >  How do you fix this situation?
> 
> Really you should use spin_lock_irqsave() on some driver-private lock
> around the operation.  Why is it not reasonable to disable irq's? 
> Duration, presumably?

The operations take a while and would ruin latency. You might be copying 8MB of
data.

> If you're in process context you can use acquire_console_sem(), which will
> serialise against printk.
> 

Won't I deadlock if I have acquire_console_sem(), take an interrupt, and then a
printk is issued from the interrupt handelr?


=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

Re: Is it possible to implement interrupt time printk's reliably?

[Andrew Morton]

Jon Smirl <jonsmirl@yahoo.com> wrote:
>
> > If you're in process context you can use acquire_console_sem(), which will
> > serialise against printk.
> > 
> 
> Won't I deadlock if I have acquire_console_sem(), take an interrupt, and then a
> printk is issued from the interrupt handelr?
> 

Nope.  If printk finds the semaphore to be held it queues up the characters
and returns without printing them.  The console_sem-holding process will
print the newly buffered characters before releasing the semaphore.

Re: Is it possible to implement interrupt time printk's reliably?

[Jon Smirl]

--- Andrew Morton <akpm@osdl.org> wrote:
> Jon Smirl <jonsmirl@yahoo.com> wrote:
> >
> > > If you're in process context you can use acquire_console_sem(), which will
> > > serialise against printk.
> > > 
> > 
> > Won't I deadlock if I have acquire_console_sem(), take an interrupt, and
> then a
> > printk is issued from the interrupt handelr?
> > 
> 
> Nope.  If printk finds the semaphore to be held it queues up the characters
> and returns without printing them.  The console_sem-holding process will
> print the newly buffered characters before releasing the semaphore.

Is this solution sufficient for kernel developers wanting to use printk from
interrupt handlers? I've gotten negative feedback from Linus when I suggested
queuing them before.

=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

Re: Is it possible to implement interrupt time printk's reliably?

[Andrew Morton]

Jon Smirl <jonsmirl@yahoo.com> wrote:
>
> 
> --- Andrew Morton <akpm@osdl.org> wrote:
> > Jon Smirl <jonsmirl@yahoo.com> wrote:
> > >
> > > > If you're in process context you can use acquire_console_sem(), which will
> > > > serialise against printk.
> > > > 
> > > 
> > > Won't I deadlock if I have acquire_console_sem(), take an interrupt, and
> > then a
> > > printk is issued from the interrupt handelr?
> > > 
> > 
> > Nope.  If printk finds the semaphore to be held it queues up the characters
> > and returns without printing them.  The console_sem-holding process will
> > print the newly buffered characters before releasing the semaphore.
> 
> Is this solution sufficient for kernel developers wanting to use printk from
> interrupt handlers? I've gotten negative feedback from Linus when I suggested
> queuing them before.
> 

It has been this way for several years.

Re: Is it possible to implement interrupt time printk's reliably?

[Jon Smirl]

So how do printk's work in the very early boot? Is the video card active before
the kernel probes it's module, or are these very early printk's being queued
until the video driver is probed?

--- Andrew Morton <akpm@osdl.org> wrote:
> Jon Smirl <jonsmirl@yahoo.com> wrote:
> >
> > 
> > --- Andrew Morton <akpm@osdl.org> wrote:
> > > Jon Smirl <jonsmirl@yahoo.com> wrote:
> > > >
> > > > > If you're in process context you can use acquire_console_sem(), which
> will
> > > > > serialise against printk.
> > > > > 
> > > > 
> > > > Won't I deadlock if I have acquire_console_sem(), take an interrupt, and
> > > then a
> > > > printk is issued from the interrupt handelr?
> > > > 
> > > 
> > > Nope.  If printk finds the semaphore to be held it queues up the
> characters
> > > and returns without printing them.  The console_sem-holding process will
> > > print the newly buffered characters before releasing the semaphore.
> > 
> > Is this solution sufficient for kernel developers wanting to use printk from
> > interrupt handlers? I've gotten negative feedback from Linus when I
> suggested
> > queuing them before.
> > 
> 
> It has been this way for several years.


=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

Re: Is it possible to implement interrupt time printk's reliably?

[James Simmons]

> So how do printk's work in the very early boot? Is the video card active before
> the kernel probes it's module, or are these very early printk's being queued
> until the video driver is probed?

printk messages are stored in log_buf in printk.c. The console driver just 
reads the buffer and displays what is in the buffer. Look at printk.c 
carefully.

 

Re: Is it possible to implement interrupt time printk's reliably?

[Jon Smirl]

So how long is the delay between PCI probe time (when the framebuffer goes
active) and when early user space is up with initrd? Or is initrd up first? If
initrd is up first then early user space mode setting will occur at the same
time that it does currently.

--- James Simmons <jsimmons@infradead.org> wrote:
> 
> > So how do printk's work in the very early boot? Is the video card active
> before
> > the kernel probes it's module, or are these very early printk's being queued
> > until the video driver is probed?
> 
> printk messages are stored in log_buf in printk.c. The console driver just 
> reads the buffer and displays what is in the buffer. Look at printk.c 
> carefully.
> 
>  
> 


=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

Re: Is it possible to implement interrupt time printk's reliably?

[James Simmons]

> So how long is the delay between PCI probe time (when the framebuffer goes
> active) and when early user space is up with initrd? Or is initrd up first? If
> initrd is up first then early user space mode setting will occur at the same
> time that it does currently.

Why do we even need a fbdev layer then!!! We might as well remove it 
completly!!!!

Its totally destroy's my dream of a real multidesktop OS :-( This is why 
I'm so upset. Using userland libraries to do multidesktop OS is a really 
limited retarded way of doing it. I worked on this for 3 years. Testing 
different systems with different configurations. Now I realize it will die 
a painful death.