On Fri, Feb 27, 2004 at 02:44:33PM -0800, George Anzinger wrote:Well, that too, but the notion is to take care of an interrupt on cpu 1 while doing console output on cpu 0. If cpu 0 doesn't grab the '+' fast enough to prevent the interrupt cpu 1 may get an interrupt with no characters in the fifo. This code just ignores that.
Couple of comments below...
Tom Rini wrote:
[snip]
- spin_unlock(&uart_interrupt_lock);
- local_irq_restore(flags);
-
I think you need at least this (especially in SMP, but works in all):
char iir = serial_inb(kgdb8250_port + (UART_IIR << reg_shift));
if(iir & UART_IIR_RDI){
+ kgdb_schedule_breakpoint();
}
return IRQ_HANDLED;
Would this be to ensure that we only schedule one breakpoint not 2?
[snip]
+ /* If we get the start of another packet, this means
+ * that GDB is attempting to reconnect. We will NAK
+ * the packet being sent, and stop trying to send this
+ * packet. */
+ if (ch == '$') {
+ kgdb_serial->write_char('-');
if (kgdb_serial->flush)
kgdb_serial->flush();
- breakpoint();
Flags go up in my mind here about recursion... What if we are already handling a breakpoint??? This may all be cool, but, as I said, alarms are ringing.
There's two cases here, IMHO. If GDB is connected, the only time we'll
get a '$' when we're sending a packet is if we're out-of-sync (in
regular gdb/kgdb communication) or we're prempting a console message
(i.e. we're trying to send something while gdb wants to break in).
the latter case, it's OK to give up on the console packet (it's not
critical) and trying to send a console message during a breakpoint is
asking for trouble.
communication, what will happen w/o this change is that we get stuck in
a "Packet instead of ACK" loop on gdb, and we get stuck trying to
transmit that same packet on the kgdb side. I think that if we call
breakpoint() here we can try and start over...
The other case is what the comment describes, and in that case we quite
quickly get to the ponit of acting like gdb is connected again.