Re: Boot hangs after "Freeing initrd memory" with 2.6.31.11

From: Ozan ÃaÄlayan
Date: Thu Jan 14 2010 - 08:37:23 EST


Ozan ÃaÄlayan wrote On 14-01-2010 15:08:

(CC'ing stable)

>>
>> From 5095f59bda6793a7b8f0856096d6893fe98e0e51 Mon Sep 17 00:00:00 2001
>> From: Jaswinder Singh Rajput <jaswinder@xxxxxxxxxx>
>> Date: Fri, 5 Jun 2009 23:27:17 +0530
>> Subject: [PATCH] x86: cpu_debug: Remove model information to reduce encoding-decoding
>
> Reverting this commit on top of 2.6.31.11 fixes the boot hangs with AMD Athlon XP processors.
> I'll double check with other reporters in a day or two.

OK we've verified on 2 separate systems with Athlon XP that reverting the commit fixes the issue.
Here's proc/cpuinfo and relevant dmesg output for reference:

processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(tm) XP 2600+
stepping : 0
cpu MHz : 1920.500
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up
bogomips : 3842.29
clflush size : 32
power management: ts



[ 0.461404] Freeing initrd memory: 5191k freed
[ 0.467844] initcall populate_rootfs+0x0/0x62 returned 0 after 217975 usecs
[ 0.467947] calling i8259A_init_sysfs+0x0/0x1d @ 1
[ 0.468093] initcall i8259A_init_sysfs+0x0/0x1d returned 0 after 41 usecs
[ 0.468190] calling sbf_init+0x0/0xda @ 1
[ 0.468282] initcall sbf_init+0x0/0xda returned 0 after 0 usecs
[ 0.468378] calling i8237A_init_sysfs+0x0/0x1d @ 1
[ 0.468484] initcall i8237A_init_sysfs+0x0/0x1d returned 0 after 12 usecs
[ 0.468582] calling add_rtc_cmos+0x0/0x94 @ 1
[ 0.468679] initcall add_rtc_cmos+0x0/0x94 returned 0 after 4 usecs
[ 0.468780] calling cache_sysfs_init+0x0/0x55 @ 1
[ 0.468940] initcall cache_sysfs_init+0x0/0x55 returned 0 after 64 usecs
[ 0.469041] calling cpu_debug_init+0x0/0x1f @ 1
[ 0.469190] cpu0(1) debug files 5
[ 0.469282] initcall cpu_debug_init+0x0/0x1f returned 0 after 143 usecs <-- That call wasn't returning at all

I think that the commit should be reverted or a fix should be released for linux-2.6 tree,
as well as .31 and .32 stable trees.


Thanks,
Ozan Caglayan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/