1

today I changed from an image with initramfs to an image with separate kernel and rootfs. Theses images are used for an Embedded System (ARM9 SAM9G25), that is runnging with an Linux 2.6.39. During boot I got the following warning, that didn't show up with the initramfs:

WARNING: at kernel/irq/handle.c:130 handle_irq_event_percpu+0x70/0x198()
irq 12 handler atmci_interrupt+0x0/0x6b0 enabled interrupts
Modules linked in:
Backtrace: 
[<c0024918>] (dump_backtrace+0x0/0x10c) from [<c01f5664>] (dump_stack+0x18/0x1c)
 r6:c005d558 r5:00000009 r4:c028fea8 r3:c02956bc
[<c01f564c>] (dump_stack+0x0/0x1c) from [<c0030f74>] (warn_slowpath_common+0x54/0x6c)
[<c0030f20>] (warn_slowpath_common+0x0/0x6c) from [<c0031030>] (warn_slowpath_fmt+0x38/0x40)
 r8:00000000 r7:00000000 r6:0000000c r5:00000001 r4:c7969f60
r3:00000009
[<c0030ff8>] (warn_slowpath_fmt+0x0/0x40) from [<c005d558>] (handle_irq_event_percpu+0x70/0x198)
 r3:0000000c r2:c025b447
[<c005d4e8>] (handle_irq_event_percpu+0x0/0x198) from [<c005d6b0>] (handle_irq_event+0x30/0x40)
[<c005d680>] (handle_irq_event+0x0/0x40) from [<c005f274>] (handle_level_irq+0xbc/0xe4)
 r4:c02976a8 r3:00020000
[<c005f1b8>] (handle_level_irq+0x0/0xe4) from [<c0021078>] (asm_do_IRQ+0x78/0xa8)
 r4:0000000c r3:c005f1b8
[<c0021000>] (asm_do_IRQ+0x0/0xa8) from [<c0021a74>] (__irq_svc+0x34/0x60)
Exception stack(0xc028ff48 to 0xc028ff90)
ff40:                   00000000 0005317f 0005217f 60000013 c028e000 c02ab1a4
ff60: c03b9480 c0291f0c 20000000 41069265 2001c2a8 c028ff9c 600000d3 c028ff90
ff80: c0022748 c0022754 60000013 ffffffff
 r5:fefff000 r4:ffffffff
[<c0022714>] (default_idle+0x0/0x44) from [<c0022908>] (cpu_idle+0x70/0xc8)
[<c0022898>] (cpu_idle+0x0/0xc8) from [<c01f37f4>] (rest_init+0x60/0x78) r5:c001d5c4 r4:c0290094
[<c01f3794>] (rest_init+0x0/0x78) from [<c00088c0> (start_kernel+0x23c/0x284)
[<c0008684>] (start_kernel+0x0/0x284) from [<20008038>] (0x20008038)
---[ end trace 45f8d0076fc9ced3 ]---

I have to say, the system doesn't crash here and boots on as the usual way and is usable in the end (I end up in Busybox - the distro).

What I did: I created an SD card with 2 FAT32 partitions of ~1 GB each. On the first there are the bootloaders and the kernel and on the second I extracted the rootfs.tar, that was generated with the help of Buildroot 2013.11.

The Linux command line looks like this:

console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait rw

(I'm not sure if this belongs to here, but first i couldn't even boot the rootfs at all, since he wasn't able to initialize the mmcblk. Now with the rootwait it works just fine).

My question is: does anyone know where this error comes from? I couldn't find any useful threads anywhere about this. I'd like to remove this error, because I guess it's wasting a bit of time during boot and that's my actual aim: keeping the boot time at the lowest time it could get.

user3085931
  • 906
  • 1
    That sounds like you've found a kernel bug. 2.6.39 is pretty old, not sure if you can test with something newer. You'll probably want to report the bug to wherever you got that kernel from, too. – derobert Apr 22 '14 at 13:49

1 Answers1

1

This is a bug somewhere in the kernel. It is not directly related to rootfs/initramfs changes. It may be due to some other change you made (did you use the same sources, the same configuration, the same compiler?), or it may be related to some timing issue that revealed a latent bug.

This warning comes from handle_irq_event_percpu and the interrupt handler is for the Atmel MMC controller. There is probably a bug in that code.

Even if you don't observe any consequences other than the trace, this kind of warning tends to indicate serious problems, which could lead to corrupted data or at least to a lock-up. Debugging is nontrivial. Given that this is a fairly old kernel, check if more recent versions of this driver have had fixes that could be related, and consider using a more recent kernel if possible.

Gilles 'SO- stop being evil'
  • 829,060
  • I guess you're right, since I've seen the word "bug" in combination with this error far often. On the other hand, 2.6.39 isn't the oldest kernel and having an own partition for the rootfs is something basic that actually works since years. are you sure it is not because of the way I manage the rootfs ? – user3085931 Apr 23 '14 at 06:44
  • @user3085931 Nothing in what you posted points to your doing something wrong, but then you didn't describe much of what you did (for example, what you put in your new initramfs, if anything). It's quite likely that what you did revealed the bug. Note that “rootfs” and the device you pass to root= are different things — the rootfs is always a ramfs. – Gilles 'SO- stop being evil' Apr 23 '14 at 08:43
  • But maybe that's the Problem, I didn't any do more than what I've described in "What I did". But what isn't mentioned there: I disabled the Initramfs options in the menuconfig of Buildroot and Linux, that's because I thought this is not in use anymore - I guess it's a whole different way to use the rootfs. – user3085931 Apr 23 '14 at 08:56
  • @user3085931 You're using a root filesystem which is not a rootfs (yes, the terminology is subtle). (Technically the rootfs is still there, but it's empty and never used.) – Gilles 'SO- stop being evil' Apr 23 '14 at 09:01
  • Ok that I didn't know, thanks for telling. Somehow this confuses me if the system is still able to boot without the initramfs. Can you give me some kind of hints to look for in the internet about this ? I can't think of any matching catchwords. – user3085931 Apr 23 '14 at 09:11
  • @user3085931 In a nutshell, the kernel always has a rootfs; if it can't execute /init on it, it tries mounting the root=XXX parameter. http://unix.stackexchange.com/questions/122100/why-do-i-need-initramfs/122200#122200 and http://unix.stackexchange.com/questions/118377/when-does-a-shell-get-executed-during-the-linux-startup-process/118382#118382 have more information. – Gilles 'SO- stop being evil' Apr 23 '14 at 09:31