[Red Envelope Ask] Linux kernel outputs garbled code after entering the serial console

wiin

[Red Envelope Ask] Linux kernel outputs garbled code after entering the serial console [Copy link]

In the kernel state, printk prints information normally.

After mounting the root file system (tested on other boards, it is a runnable root file system), garbled characters appear.

I wrote a serial port driver myself, but I don't know where the problem lies. I would like to ask the experts to solve this problem:

RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing init memory: 240K
ramdisk_execute_command
execute_command=/linuxrc
execute_command start
)
'
'

e
B
0


B
r
0
f
B

wiin

If you can help me solve this problem, I can forward a 200 red packet via WeChat. Sincerely ask:

Occasionally the following error occurs:

BUG: soft lockup detected on CPU#0!
[<c0048c0c>] (dump_stack+0x0/0x14) from [<c0080284>] (softlockup_tick+0xa0/0xc0)
[<c00801e4>] (softlockup_tick+0x0/0xc0) from [< c0069144>] (run_local_timers+0x18/0x1c)
r7 = 00000001 r6 = 00000001 r5 = 00000000 r4 = C044DC40
[<c006912c>] (run_local_timers+0x0/0x1c) from [<c006918c>] (update_process_time s+0x44/0x6c)
[<c0069148>] (update_process_times+0x0/0x6c) from [<c0048a58>] (timer_tick+0xc8/0xe8)

freebsder

The sleep time is too long and it is detected.

wiin

freebsder posted on 2021-11-5 22:50 It has been dormant for a long time and has been detected.

The test was like an interrupt problem, and it was the same as the bare metal code. As a result, some strange problems occurred when the kernel interrupt was applied: no interrupt pending was reported, the data printed by the send interrupt was garbled, and the system crashed after entering the receive interrupt. I could only debug by lighting the lamp, and I couldn't find any other good debugging methods.

freebsder

Your problem seems to be that you use a kernel function that cannot be used in an interrupt context. Check run_local_timers to see if any locks are requested.

wiin

freebsder posted on 2021-11-9 17:21 Your problem seems to be that you used a kernel function that cannot be used in an interrupt context. Check run_local_timers to see if it is...

The test results are as follows: The timer interrupt runs independently and is always OK. I added a 3s print. But when I input on the keyboard, a serial port reception interrupt is generated, and the kernel will enter the timer interrupt frantically, and the accumulated time is more than 10s in an instant, prompting BUG: soft lockup detected on CPU#0!. No lock is requested in the timer. I feel this phenomenon is too weird.

freebsder

wiin posted on 2021-11-11 11:52 The test results are as follows: The timer interrupt runs independently and is always OK. I added a 3s print. But when I input on the keyboard, a serial port receive interrupt is generated, and the internal...

Don't use printing or anything like that in interrupts, because those things are not meant to be used in interrupts.