linux-kernel - Freezes on AT91SAM9G45-Board

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <540DEA00.90207@biereigel.de>
Date:	Mon, 08 Sep 2014 19:40:16 +0200
From:	Stefan Biereigel <stefan@...reigel.de>
To:	"linux-kernel@...r kernel org" <linux-kernel@...r.kernel.org>
CC:	linux-embedded@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Stefan Biereigel <stefan@...reigel.de>
Subject: Freezes on AT91SAM9G45-Board

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Kernel developers,

today I stumbled across a weird problem with my ARM computer board. It's based on the
Atmel AT91SAM9G45-EKES-Board, with just minor pinout differences.
It boots the kernel just fine, but when it decides that the root FS (contained on an SD
card, ext2) needs to be checked by e2fsck, it checks up to 30..50% and then just freezes.

I tried several kernel versions, namely
3.16.1 (form kernel.org)
3.10.0 (from the at91-linux github branch)
3.4.9 (from the at91-linux github branch)
2.6.39 (from the at91-linux github branch)

All versions seem to exhibit this problem, and I can also trigger it by running e2fsck
from recovery mode (shutdown -F now, login, fsck /dev/mmcblk0p2).
Some versions / reboots gave me long kernel oopses/panics. I could capture one of them,
and will be posting it below. If I interpret it correctly, there seems to be a NULL
pointer dereference in at91_aic_handle_irq at offset 0x0c.
GDB on vmlinux tells me:

Dump of assembler code for function at91_aic_handle_irq:
   0xc00086e4 <+0>:	ldr	r3, [pc, #40]	; 0xc0008714 <at91_aic_handle_irq+48>
   0xc00086e8 <+4>:	mov	r1, r0
   0xc00086ec <+8>:	ldr	r2, [r3]
   0xc00086f0 <+12>:	ldr	r0, [r2, #256]	; 0x100
   0xc00086f4 <+16>:	ldr	r2, [r3]
   0xc00086f8 <+20>:	ldr	r12, [r2, #264]	; 0x108
   0xc00086fc <+24>:	cmp	r12, #0
   0xc0008700 <+28>:	bne	0xc0008710 <at91_aic_handle_irq+44>
   0xc0008704 <+32>:	ldr	r3, [r3]
   0xc0008708 <+36>:	str	r12, [r3, #304]	; 0x130
   0xc000870c <+40>:	bx	lr
   0xc0008710 <+44>:	b	0xc0009de8 <handle_IRQ>
   0xc0008714 <+48>:	eorsgt	r12, pc, r12, asr r4	; <UNPREDICTABLE>
End of assembler dump.

As I'm not that familiar with ARM assembly language, I can not tell where the
dereference comes from (should be ldr r0, [r2, #256]) and how to fix it.

I noticed this patch set from last week: https://lkml.org/lkml/2014/9/5/370
Could it be of any help? Gael only speaks of oopses when loading a new kernel.

As the files are too long to sensibly paste below, I'll attach them. I hope that is okay.

Thank you for any help, please feel free to CC who ever you think could have an idea.
Stefan Biereigel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJUDen/AAoJEKN7O9MWKeKlRsEH/2RIeZEEU53GFh6Yn3RU6Jos
i4k20+Q1jqmDU+6u5ry7LXjlLhUNBVhL6UG/LFNej9uRHroNCX8H28hQHNRYXCC/
1dhCXKJllExwn5rLMFLPJx6Pc/PFLbOsCNUlTQu1JMCqO9m4KfH+zPH5Eud8nw1K
14dV+g6lMTv9/xPglzhtIvXIfu6PyscgVtJjYxSaztAQvvLKMFnYHtne2F3zBoE1
wgDbBVO/Hd1Jhr7CAWIuhwlZf4eUWjexpzRxVTPDdECoeWjcqNRudgkVmu7TUTYI
MWtQz5r5YGFLVjR/UUt5ve0gtLMdi940+cdOzJjJB07HVdrSwTnisvJdyTpO+N8=
=/RNs
-----END PGP SIGNATURE-----

View attachment "at91-oopses.txt" of type "text/plain" (11719 bytes)

View attachment ".config" of type "text/plain" (57928 bytes)

View attachment "board-sam9m10g45ek.c" of type "text/x-csrc" (9848 bytes)