"Linux" issue highlights

Original, please specify when reproduced, thank you. E-mail:[email protected], address:HTTP://WWW.CNBLOGS.COM/EMBEDDED-TZP

After the kernel download runs, there will be a variety of problems, problems and solutions will be posted.

• No filesystem could mount Root, tried:ext3 Cramfs vfat msdos Romfs (no file system)

Problem Analysis:

There is no configuration file system type when make menuconfig.

Solution:

: Make Menuconfig: Change m to Yes, see

• Failed to EXECUTE/LINUXRC. Attempting defaults ...

Problem Analysis:

If the program is not executable or does not have permission to execute, modify the LINUXRC group in the root file system to root.

Solution:

# chown-r Root:root '/home/tang/work/fs/ramdisk_fs ', or make file system as root

• LS output garbled

Problem Analysis:

LS is a busybox command, and its output adds some format output.

Solution:.

Either reconfigure the BusyBox and compile it, or use the SECURECRT tool instead

See http://blog.chinaunix.net/uid-26404477-id-3459315.html

Problem Description:

When the board executes ifconfig eth0 192.168.1.3, the error occurs as follows:

IRQ 57:nobody cared (try booting with the "irqpoll" option) (__REPORT_BAD_IRQ:SPURIOUS.C (SRC\KERNEL\IRQ) )

cpu:0 pid:770 comm:ifconfig not tainted 3.10.53 #28

[<c000d8ec>] (Unwind_backtrace+0x0/0xf4) from [<c000bea4>] (show_stack+0x10/0x14)

[<c000bea4>] (show_stack+0x10/0x14) from [<c005305c>] (__REPORT_BAD_IRQ+0X20/0XB4)

[<c005305c>] (__report_bad_irq+0x20/0xb4) from [<c0053314>] (note_interrupt+0x224/0x288)

[<c0053314>] (note_interrupt+0x224/0x288) from [<c00514d8>] (HANDLE_IRQ_EVENT_PERCPU+0XA8/0X1C0)

[<c00514d8>] (handle_irq_event_percpu+0xa8/0x1c0) from [<c0051618>] (handle_irq_event+0x28/0x38)

[<c0051618>] (handle_irq_event+0x28/0x38) from [<c0053aec>] (handle_edge_irq+0x7c/0x130)

[<c0053aec>] (handle_edge_irq+0x7c/0x130) from [<c005107c>] (generic_handle_irq+0x34/0x40)

[<c005107c>] (generic_handle_irq+0x34/0x40) from [<c019b528>] (s3c_irq_demux+0xb4/0x120)

[<c019b528>] (s3c_irq_demux+0xb4/0x120) from [<c005107c>] (generic_handle_irq+0x34/0x40)

[<c005107c>] (generic_handle_irq+0x34/0x40) from [<c00099fc>] (handle_irq+0x30/0x84)

[<c00099fc>] (handle_irq+0x30/0x84) from [<c000855c>] (s3c24xx_handle_irq+0x90/0x140)

[<c000855c>] (s3c24xx_handle_irq+0x90/0x140) from [<c0008e74>] (__irq_svc+0x34/0x40)

Exception Stack (0xc2f67ce8 to 0XC2F67D30)

7ce0:00000001 0000000a 00000000 20000013 00000002 00000002

7d00:c04e4160 c2f66000 c04a4f5c c04e4140 c201d90c c04e4160 00400100 c2f67d30

7D20:C001CF4C c001cfc0 20000013 ffffffff

[<c0008e74>] (__irq_svc+0x34/0x40) from [<c001cfc0>] (__do_softirq+0x84/0x1cc)

[<c001cfc0>] (__do_softirq+0x84/0x1cc) from [<c001d1b8>] (do_softirq+0x4c/0x58)

[<c001d1b8>] (do_softirq+0x4c/0x58) from [<c001d218>] (irq_exit+0x54/0x90)

[<c001d218>] (irq_exit+0x54/0x90) from [<c0009a00>] (handle_irq+0x34/0x84)

[<c0009a00>] (handle_irq+0x34/0x84) from [<c000855c>] (s3c24xx_handle_irq+0x90/0x140)

[<c000855c>] (s3c24xx_handle_irq+0x90/0x140) from [<c0008e74>] (__irq_svc+0x34/0x40)

Exception Stack (0xc2f67da0 to 0xc2f67de8)

7da0:00000000 00000039 C04aeab8 00000000 c04a7194 c2054d40 00000039 60000013

7dc0:c04a71c4 00000000 c201d90c c2046cc0 235e5c8f c2f67de8 c0053ff8 C00523DC

7de0:40000013 FFFFFFFF

[<c0008e74>] (__irq_svc+0x34/0x40) from [<c00523dc>] (__setup_irq+0x194/0x428)

[<c00523dc>] (__setup_irq+0x194/0x428) from [<c00528a8>] (request_threaded_irq+0xd8/0x158)

[<c00528a8>] (request_threaded_irq+0xd8/0x158) from [<c02168c0>] (net_open+0x88/0x488)

[<c02168c0>] (net_open+0x88/0x488) from [<c02bfa4c>] (__dev_open+0xb8/0x114)

[<c02bfa4c>] (__dev_open+0xb8/0x114) from [<c02bc8e4>] (__dev_change_flags+0x8c/0x134)

[<c02bc8e4>] (__dev_change_flags+0x8c/0x134) from [<c02bf95c>] (dev_change_flags+0x10/0x48)

[<c02bf95c>] (dev_change_flags+0x10/0x48) from [<c0310cfc>] (devinet_ioctl+0x674/0x784)

[<c0310cfc>] (devinet_ioctl+0x674/0x784) from [<c02abfdc>] (SOCK_IOCTL+0X74/0X2A4)

[<c02abfdc>] (SOCK_IOCTL+0X74/0X2A4) from [<c009fab4>] (DO_VFS_IOCTL+0X80/0X5F4)

[<c009fab4>] (DO_VFS_IOCTL+0X80/0X5F4) from [<c00a0064>] (sys_ioctl+0x3c/0x60)

[<c00a0064>] (sys_ioctl+0x3c/0x60) from [<c00091c0>] (ret_fast_syscall+0x0/0x2c)

Handlers:

[<c0216cc0>] Net_interrupt

disabling IRQ #57 (SPURIOUS.C (SRC\KERNEL\IRQ), this condition occurs when the number of interrupts is 99000 excessive and is not processed)

Cs89x0:eth0:using Half-duplex 10base-t (RJ-45)

Cs89x0:net_open () succeeded

Problem Analysis:

This is related to the network driver, my is the CS8900A network card, the code is the kernel comes with, with this explanation.

Network card driver related files for cs89x0.c,cs89x0.h, Cs89x0.txt.

From the net_interrupt at the bottom of the stack, you can see that the kernel crashes at [<c0216cc0>] Net_interrupt. In Net_open () there is ret = REQUEST_IRQ (DEV->IRQ, net_interrupt, 0, Dev->name, Dev); Visible Net_interrupt is the NIC interrupt handler function.

From the above print stack can be seen when the problem occurs in the sequence of function calls, the call order is interrupted processing flow, you can see my other article, where there is a very detailed description of the interruption.

S3c24xx_handle_irq→ handle_irq → Generic_handle_irq→ S3c_irq_demux→ generic_ Handle_irq→

Handle_edge_irq→ handle_irq_event → handle_irq_event_percpu→ Note_interrupt→ __ Report_bad_irq→show_stack→unwind_backtrace;

In the Note_interrupt function, there are:

if (Unlikely (Desc->irqs_unhandled > 99900)) {

/*

* The interrupt is stuck

*/

__REPORT_BAD_IRQ (IRQ, DESC, Action_ret);

.......

}

Desc is an element of the interrupt array, its irqs_unhandled > 99900, which means 99,900 interrupts are not processed?

In note_interrupt→if (unlikely (Action_ret = = Irq_none)) {... desc->irqs_unhandled++; ...} description nic interrupt return value is Irq_none , they will irqs_unhandled++. The NIC interrupt return value is obtained by handle_irq_event_percpu→res = Action->handler (IRQ, action->dev_id) that is net_interrupt, see the function, It is known that while (status = Ioread16 (Lp->virt_addr + isq_port)) The loop must have a false condition, otherwise the return value will not be irq_none.

Analysis to here basically understand, cs8900a interrupt is hardware and s3c2440 connection, cs8900a only actually produced interrupt, will cause the CPU to enter the interrupt function, but the network card is actually not possible to produce so frequent interruption, then conjecture may be the interrupt trigger type is set incorrectly.

With the schematic diagram:

See S3C2440 Handbook:

The EXTINT1 register's [6:4] controls the LAN port interrupt trigger type.

Add code to the kernel, print the value of the EXTINT1 register, and find it configured to be low-level triggering interrupts, while in CS8900A's datasheet, it is clear that the high level indicates an interrupt.

Here the problem causes the location.

Solution:

. Mini2440_map_io Modify in Mach_start, add interrupt support

S3c24xx_init_io (Mini2440_iodesc, Array_size (MINI2440_IODESC));

Add external interrupt control EINT9, high level trigger, cs8900 interrupt

unsigned long tmp = IOREAD32 (S3c24xx_va_gpio + 0x8c); EXTINT1 Register

TMP &= ~0xf0;

TMP |= 0x90;

IOWRITE32 (tmp, S3c24xx_va_gpio + 0x8c); Set to high-level trigger interrupt

Then Ifconfig, Ping, and other commands are executed normally at the application level.

Feelings:

When driving the transplant, the last code to change is a few words, but to understand the entire Linux implementation system, including the device bus driver model, platform driver, because the cs89x0 driver is the use of this architecture, including the complete interrupt processing process, including the s3c2440 chip itself, CS8900A chip itself data, cs8900a Drive source code, Linux virtual address and Physical address mapping background knowledge, really frustrating ah, fortunately bring a sense of accomplishment, development from then on Can use NFS file system, convenient a lot, also worthwhile.

Problem Description:

EEPROM is configured for unavailable media

Problem Analysis:

Solution:.

"Linux" issue highlights