Hi,
I'm testing 4.0-rc1 kernel on my board(ARM Cortex-a15 single core).
The UART is 8250_dw uart.
I found if writes to the LCR failed the kernel will hung up.
If serial is busy and writes to the LCR failed after tried 1000 times.
The kernel will hung up.
You can reproduce it easily by add printk as follows.
95 static void dw8250_serial_out(struct uart_port *p, int offset, int value)
96 {
97 struct dw8250_data *d = p->private_data;
98
99 if (offset == UART_MCR)
100 d->last_mcr = value;
101
102 writeb(value, p->membase + (offset << p->regshift));
103
104 /* Make sure LCR write wasn't ignored */
105 if (offset == UART_LCR) {
106 int tries = 1000;
107 printk(KERN_ERR "printk test!\n");
108 while (tries--) {
109 unsigned int lcr = p->serial_in(p, UART_LCR);
110 if ((value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR))
111 return;
112 dw8250_force_idle(p);
113 writeb(value, p->membase + (UART_LCR << p->regshift));
114 }
115 dev_err(p->dev, "Couldn't set LCR to %d\n", value);
116 }
117 }
The log is as follows:
--------------------------------
Starting the kernel:
Uart base = 0xF0407000
watchdog reg = 0xF0400000
dtb addr = 0x00642AB0
Uncompressing Linux... done, booting the kernel.
[ 24.979844] printk test!
[ 24.979852] printk test!
[ 25.059774] Hisilicon GMAC net controler(Ver Mar 4 2015 22:32:23).
[ 25.134912] ----------> debug <----------
[ 25.182958] - print_err addr 0x4fa560 -
[ 25.228916] ----------> debug <----------
[ 25.277099] gmac compile time is:Mar 4 2015--22:32:23
[ 25.338731] interrupt num 200
[ 25.374282] ulCmp = 0, unPpeCfgRxCtrl.u32 = 100[ 25.427613] now the net phy is connected
[ 25.478893] printk test!
-----------------------------------
I have tried to change #printk(KERN_ERR "printk test!\n")# to #printk(KERN_INFO "printk test!\n")#
The system boot success.
It looks like we can't write to serial line here. Why?
If so, why the first and second printk success?
Best regards!
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
