Corey,
Did you mean uartdrv_console_write() (and not uart_console_write())?
If so, I found a call to uart_write_wakeup() at the end of
uartdrv_console_write() and put
if (port->info->flags & UIF_INITIALIZED)
in front of it. That is working. My board will now reboot without getting
an oops. I did some quick ipmi tests (kernel finds IPMI device, query
manufacturer and product id) and those still work as well. I will be doing
more complete testing later.
So it looks good. Thanks very much for the help.
David
On Jan 23, 2008 1:55 PM, Corey Minyard <[EMAIL PROTECTED]> wrote:
> Hmm, I think the problem is the call to uart_write_wakeup() at the end
> of uart_console_write() in serial_core.c. I am not 100% sure why it is
> there, but since the patch makes the console and "normal" users share
> the same output buffer, I think it was required to kick off transmission
> when sharing console output with other output. Thinking about it, I'm
> pretty sure that's why it's there.
>
> I think the right solution is to add "if (port->info->flags &
> UIF_INITIALIZED)" before the call to uart_write_wakeup() in that code.
> Can you try that and see if it fixes the problem?
>
> -corey
>
>
> David Jenkins wrote:
> > Corey,
> >
> > I applied the 2.6.23 IPMI UART system interface patches to my 2.6.23
> > 8641 kernel (serial_core.c & 8250.c).
> >
> > Now when I do a 'reboot' from the command line I get the following
> > kernel oops:
> >
> > Oops: Kernel access of bad area, sig: 11 [#1]
> > SMP NR_CPUS=2 kxx8641
> > Modules linked in:
> > NIP: c01580a4 LR: c016c77c CTR: c016c764
> > REGS: c1a23a50 TRAP: 0300 Not tainted (2.6.23-ksi8641-rel_1_0-rc2)
> > MSR: 00009032 <EE,ME,IR,DR> CR: 42000242 XER: 20000000
> > DAR: 000000b8, DSISR: 40000000
> > TASK = effdac70[281] 'init' THREAD: c1a22000 CPU: 0
> > GPR00: c016c77c c1a23b00 effdac70 00000000 00009032 fffba466 00000100
> > c04a0000
> > GPR08: c1a23b18 c04ca000 0005b000 c016c764 22000244 1008c5ac c04b0000
> > 00000001
> > GPR16: ffffffff 00000000 c1a23c50 00000000 393d66b8 c04a0000 00000000
> > c04bd960
> > GPR24: c04bd960 c04b33a0 c048710c c1a22000 00000000 00000002 c04ca018
> > 00000000
> > NIP [c01580a4] tty_wakeup+0x14/0x9c
> > LR [c016c77c] uart_tasklet_action+0x18/0x28
> > Call Trace:
> > [c1a23b00] [c016861c] ipmi_serial_timeout+0x0/0x78 (unreliable)
> > [c1a23b10] [c016c77c] uart_tasklet_action+0x18/0x28
> > [c1a23b20] [c0029508] tasklet_action+0xbc/0x194
> > [c1a23b50] [c0029814] __do_softirq+0xa0/0x13c
> > [c1a23b90] [c00065b4] do_softirq+0x64/0x68
> > [c1a23ba0] [c0029220] irq_exit+0x54/0x64
> > [c1a23bb0] [c000e260] timer_interrupt+0x2e4/0x6cc
> > [c1a23c40] [c0011374] ret_from_except+0x0/0x14
> > --- Exception: 901 at vprintk+0x25c/0x434
> > LR = vprintk+0x2d4/0x434
> > [c1a23d90] [c0023f7c] printk+0x50/0x60
> > [c1a23e10] [c0032e14] kernel_restart+0x7c/0x98
> > [c1a23e20] [c00354ac] sys_reboot+0x170/0x200
> > [c1a23f40] [c0010cc8] ret_from_syscall+0x0/0x38
> > --- Exception: c01 at 0xff252fc
> > LR = 0x1001c938
> > Instruction dump:
> > 4becbeb9 80010034 387f000c bbc10028 38210030 7c0803a6 4e800020 7c0802a6
> > 9421fff0 bfc10008 7c7f1b78 90010014 <800300b8> 70090020 4082002c
> 387f0128
> > Kernel panic - not syncing: Fatal exception in interrupt
> > Rebooting in 180 seconds..
> >
> > The problem is that state->info->tty is NULL and so NULL is passed
> > into the tty_wakeup() from uart_tasklet_action() and NULL is
> > dereferenced inside tty_wakeup.
> >
> > I can make the problem go away in three ways:
> >
> > a) Remove the printk's in sys.c:kernel_restart()
> > b) stick a if(state->info->tty) above the call to tty_wakeup() in
> > serial_core.c:uart_tasklet_action
> > c) Remove the state->info->tty = NULL in seral_core.c:uart_close()
> >
> > 'c' stops the kernel oops but something is still wrong such that the
> > board locks up instead of oopsing.
> >
> > There appears to be a timing issue between the tty_wakeup (I think
> > caused by the printk's in kernel_restart) and setting state->info->tty
> > = NULL as a part of the kernel shutdown. However, I wasn't getting
> > very far tracking this down any further and so though I would let you
> > know about it.
> >
> > David Jenkins
> > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Openipmi-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
