| Message ID | 1385908770-14131-1-git-send-email-peter@hurleysoftware.com |
|---|---|
| State | RFC |
| Delegated to: | David Miller |
| Headers | show |
> >>>> Does the RED state exception trigger if you manually break to the prom > >>>> command line and issue a boot command? > >>> > >>> It seems I can not break from running kernel to PROM by sending break > >>> from minicom. PROM itself reacts to my break (during memory test for > >>> example) so it's Linux not accepting the break. I seem to remember it > >>> having worked some time ago, although not when the kergel hung. > >> > >> Argghh. > >> > >> There were some changes to sunsab.c a couple of versions ago; maybe we > >> broke it. > >> > >> Can you confirm BRKs are being received with > >> 'sudo cat /proc/tty/driver/serial' > > > > In 3.12: > > > > # cat /proc/tty/driver/sunsab > > serinfo:1.0 driver revision: > > 0: uart:SAB82532 V3.2 mmio:0x1FFF1400000 irq:5 tx:5163 rx:0 CTS|DSR|CD > > 1: uart:SAB82532 V3.2 mmio:0x1FFF1400040 irq:5 tx:0 rx: > > > > cat /proc/sys/kernel/stop-a > > 1 > > > > # cat /proc/sys/kernel/reboot-cmd > > > > (it was empty, so default "boot" should be used AFAIK) > > Meelis, > > Would you please re-test trying to break to the PROM with this debug > patch? As with the bootpromfs debug patch, the output is in > '/sys/kernel/debug/trace'. Should I activate tracing somehow? I enabled some trace options in the kernel and got a bunch of files under /sys/kernel/debug/tracing/ but /sys/kernel/debug/tracing/trace show only the header and /sys/kernel/debug/tracing/enabled_functions is empty. /sys/kernel/debug/tracing/tracing_on is "1" and /sys/kernel/debug/tracing/current_tracer is "nop".
On 12/03/2013 11:11 AM, Meelis Roos wrote: >>>>>> Does the RED state exception trigger if you manually break to the prom >>>>>> command line and issue a boot command? >>>>> >>>>> It seems I can not break from running kernel to PROM by sending break >>>>> from minicom. PROM itself reacts to my break (during memory test for >>>>> example) so it's Linux not accepting the break. I seem to remember it >>>>> having worked some time ago, although not when the kergel hung. >>>> >>>> Argghh. >>>> >>>> There were some changes to sunsab.c a couple of versions ago; maybe we >>>> broke it. >>>> >>>> Can you confirm BRKs are being received with >>>> 'sudo cat /proc/tty/driver/serial' >>> >>> In 3.12: >>> >>> # cat /proc/tty/driver/sunsab >>> serinfo:1.0 driver revision: >>> 0: uart:SAB82532 V3.2 mmio:0x1FFF1400000 irq:5 tx:5163 rx:0 CTS|DSR|CD >>> 1: uart:SAB82532 V3.2 mmio:0x1FFF1400040 irq:5 tx:0 rx: >>> >>> cat /proc/sys/kernel/stop-a >>> 1 >>> >>> # cat /proc/sys/kernel/reboot-cmd >>> >>> (it was empty, so default "boot" should be used AFAIK) >> >> Meelis, >> >> Would you please re-test trying to break to the PROM with this debug >> patch? As with the bootpromfs debug patch, the output is in >> '/sys/kernel/debug/trace'. > > Should I activate tracing somehow? You did activate tracing. The lack of output means at that point there is no BRK detected. Can you trigger any sysrq function from that terminal (assuming CONFIG_SERIAL_SUNSAB_CONSOLE && CONFIG_MAGIC_SYSRQ)? > I enabled some trace options in the > kernel and got a bunch of files under /sys/kernel/debug/tracing/ but > /sys/kernel/debug/tracing/trace show only the header and > /sys/kernel/debug/tracing/enabled_functions is empty. > /sys/kernel/debug/tracing/tracing_on is "1" and > /sys/kernel/debug/tracing/current_tracer is "nop". > -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > > > There were some changes to sunsab.c a couple of versions ago; maybe we > > > > > broke it. > > > > > > > > > > Can you confirm BRKs are being received with > > > > > 'sudo cat /proc/tty/driver/serial' > > > > > > > > In 3.12: > > > > > > > > # cat /proc/tty/driver/sunsab > > > > serinfo:1.0 driver revision: > > > > 0: uart:SAB82532 V3.2 mmio:0x1FFF1400000 irq:5 tx:5163 rx:0 CTS|DSR|CD > > > > 1: uart:SAB82532 V3.2 mmio:0x1FFF1400040 irq:5 tx:0 rx: > > > > > > > > cat /proc/sys/kernel/stop-a > > > > 1 > > > > > > > > # cat /proc/sys/kernel/reboot-cmd > > > > > > > > (it was empty, so default "boot" should be used AFAIK) > > > > > > Meelis, > > > > > > Would you please re-test trying to break to the PROM with this debug > > > patch? As with the bootpromfs debug patch, the output is in > > > '/sys/kernel/debug/trace'. > > > > Should I activate tracing somehow? > > You did activate tracing. The lack of output means at that point > there is no BRK detected. Can you trigger any sysrq function from > that terminal (assuming CONFIG_SERIAL_SUNSAB_CONSOLE && CONFIG_MAGIC_SYSRQ)? I can not trigger SysRq by sending a break and then immediately s (or t also tested). Nothing in trace. Magic SysRq is 0x1 like default in kernel conf. This in on the SUNSAB Ultra5 machine. E3500 with zs serial console has working break but I do now know how to send SysRq there - Break drops me to prom prompt, I can "go" there but anything after that is inteprreted as normal input. How shoyukd SysRq over verial console work - have not used it before?
On 12/04/2013 10:35 AM, Meelis Roos wrote: >>>>>> There were some changes to sunsab.c a couple of versions ago; maybe we >>>>>> broke it. >>>>>> >>>>>> Can you confirm BRKs are being received with >>>>>> 'sudo cat /proc/tty/driver/serial' >>>>> >>>>> In 3.12: >>>>> >>>>> # cat /proc/tty/driver/sunsab >>>>> serinfo:1.0 driver revision: >>>>> 0: uart:SAB82532 V3.2 mmio:0x1FFF1400000 irq:5 tx:5163 rx:0 CTS|DSR|CD >>>>> 1: uart:SAB82532 V3.2 mmio:0x1FFF1400040 irq:5 tx:0 rx: >>>>> >>>>> cat /proc/sys/kernel/stop-a >>>>> 1 >>>>> >>>>> # cat /proc/sys/kernel/reboot-cmd >>>>> >>>>> (it was empty, so default "boot" should be used AFAIK) >>>> >>>> Meelis, >>>> >>>> Would you please re-test trying to break to the PROM with this debug >>>> patch? As with the bootpromfs debug patch, the output is in >>>> '/sys/kernel/debug/trace'. >>> >>> Should I activate tracing somehow? >> >> You did activate tracing. The lack of output means at that point >> there is no BRK detected. Can you trigger any sysrq function from >> that terminal (assuming CONFIG_SERIAL_SUNSAB_CONSOLE && CONFIG_MAGIC_SYSRQ)? > > I can not trigger SysRq by sending a break and then immediately s (or t > also tested). Nothing in trace. Magic SysRq is 0x1 like default in > kernel conf. This in on the SUNSAB Ultra5 machine. That's what I thought: just wanted to validate. Not sure why no BRK is detected (isr1 & ISR1_BRK == 0). Maybe there is an early-out that is ignoring BRK condition. Or the sunsab driver is not reading/interpreting the correct register/bits. You could instrument the irq handler, sunsab_interrupt(), with trace_printk() to see if BRK is ever detected. > E3500 with zs serial console has working break but I do now know how to > send SysRq there - Break drops me to prom prompt, I can "go" there but > anything after that is inteprreted as normal input. I'm not sure how BRK is intended to be used for both the PROM console and SysRq on a serial console. If you temporarily disable the PROM console, the SysRq should work by typing a SysRq command char after sending a break. [ FWIW, Minicom's break function sends a lot of BRKs because it's designed to trigger a modem interrupt. AFAIK there isn't a 'single-char length break' supported by minicom. ] > How shoyukd SysRq > over verial console work - have not used it before? The first input after a BRK is interpreted as a SysRq command (within 5 secs). Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/tty/serial/sunsab.c b/drivers/tty/serial/sunsab.c index 5d6136b..1e7a17e 100644 --- a/drivers/tty/serial/sunsab.c +++ b/drivers/tty/serial/sunsab.c @@ -153,9 +153,12 @@ receive_chars(struct uart_sunsab_port *up, } /* Count may be zero for BRK, so we check for it here */ - if ((stat->sreg.isr1 & SAB82532_ISR1_BRK) && - (up->port.line == up->port.cons->index)) - saw_console_brk = 1; + if (stat->sreg.isr1 & SAB82532_ISR1_BRK) { + if (up->port.line == up->port.cons->index) + saw_console_brk = 1; + trace_printk("%d: console:%d count:%d port:%p\n", + up->port.line, up->port.cons->index, count, port); + } for (i = 0; i < count; i++) { unsigned char ch = buf[i], flag;