RE: [Xen-devel] Re: system freeze when processor.ko is loaded during boot

["Liu, Jinsong" <jinsong.liu@xxxxxxxxx>]

Martin,

Any update? I need reproduce the bug so your environment/config is really 
needed.
BTW, have you tried at some other platform beside Samsung XS50 laptop? is it a 
machine specific issue?

Thanks,
Jinsong


Liu, Jinsong wrote:
> Martin,
> 
> I'd like to reproduce the bug at my desktop and have a look at it.
> I'm setting up debug environment now, and need some
> environment/config info at your side: 
> 
> 1. xen-upstable changeset
> 2. Jeremy pvops kernel version/ git commit/ .config file
> 3. ioemu git commit
> 4. grub.conf file
> 5. processor.ko related config to load the modules at booting time
> (of Jeremy pvops kernel, not SUSE) 
> 6. xen/kernel booting serial log
> 
> BTW, is xen still alive when dom0 kernel freeze?
> If yes, some dump log like key '0'/ 'c'/ 'd'/ 'q' is highly welcomed.
> 
> Thanks,
> Jinsong
> 
> 
> Jan Beulich wrote:
>> (Stub reply, to make the mail visible to the list - apparently the
>> original is still sitting in the to-be-approved queue.)
>> 
>>>>> On 08.10.10 at 22:04, Martin Wilck <mwilck@xxxxxxxx> wrote: Hello,
>>> 
>>> I see a system freeze with xen-unstable and jeremy/xen/2.6.32-next
>>> kernel when the processor ACPI mocule is loaded during boot on my
>>> Samsung X50 notebook. I first saw this problem with Xen under
>>> OpenSUSE 
>>> 11.3 (https://bugzilla.novell.com/show_bug.cgi?id=623680) with the
>>> OpenSUSE hypervisor and kernel.
>>> 
>>> So far, I have found out the following:
>>> 
>>>  - no problem with OpenSUSE default kernel
>>>  - no problem with Xen if I don't load processor.ko
>>>  - no problem with "max_cstate=1" hypervisor parameter (but
>>> max_cstate=2 freezes) 
>>> 
>>>  - when the freeze happens, I am usually seeing some unreleated
>>> messages about USB or SATA device initialization. No keys at all are
>>> working, sometimes the disk LED stays on without the disk making
>>> noises. I haven't been able to see any hypervisor messages (even
>>> with "vga=keep"; unfortunately the system has no serial port). The
>>> Xen "watchdog" parameter causes the machine to reboot without any
>>> messages. 
>>> 
>>>  - The weirdest thing is that once the system has booted, I seem to
>>> be able to load processor.ko without problems (at least the system
>>> doesn't freeze, even if I let it idle for a long time or if I do
>>> normal work under X). With the SUSE hypervisor + kernel I was even
>>> able to verify that cpuidle was working and C3 was being used (with
>>> xen-unstable, I couldn't get xenpm to work so far).
>>> 
>>> - However if processor.ko is loaded during boot, the system always
>>> freezes (100% reproducable). I tried loading it in the initrd (SUSE
>>> default) and early after mounting the root FS (autoloaded by udev I
>>> think), and even compiling it into the kernel proper (tried that
>>> only with the jeremy kernel). In all cases, the system freezes hard.
>>> 
>>> Probably the freeze occurs when the CPU enters a deep C-state while
>>> some HW initialization is going on at boot time.
>>> 
>>> I am a little out of clues how to debug this further, any hints
>>> would be welcome. 
>>> 
>>> The info below was taken with the normal OpenSUSE kernel.
>>> 
>>> Thanks for any hints
>>> Martin
>>> 
>>> martin@athene:~$ cat /proc/cpuinfo
>>> processor       : 0
>>> vendor_id       : GenuineIntel
>>> cpu family      : 6
>>> model           : 13
>>> model name      : Intel(R) Pentium(R) M processor 2.13GHz
>>> stepping        : 8
>>> cpu MHz         : 800.000
>>> cache size      : 2048 KB
>>> fdiv_bug        : no
>>> hlt_bug         : no
>>> f00f_bug        : no
>>> coma_bug        : no
>>> fpu             : yes
>>> fpu_exception   : yes
>>> cpuid level     : 2
>>> wp              : yes
>>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
>>> pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe up bts est
>>> tm2 bogomips        : 1596.03 clflush size    : 64
>>> cache_alignment : 64
>>> address sizes   : 32 bits physical, 32 bits virtual
>>> power management:
>>> 
>>> martin@athene:~$ cat /proc/acpi/processor/CPU0/info
>>> processor id:            0
>>> acpi id:                 0
>>> bus mastering control:   yes
>>> power management:        yes
>>> throttling control:      yes
>>> limit interface:         yes
>>> 
>>> martin@athene:~$ cat /proc/acpi/processor/CPU0/power
>>> active state:            C0
>>> max_cstate:              C8
>>> maximum allowed latency: 2000000000 usec
>>> states:
>>>     C1:                  type[C1] promotion[--] demotion[--]
>>> latency[001] usage[00001563] duration[00000000000000000000]
>>>     C2:                  type[C2] promotion[--] demotion[--]
>>> latency[001] usage[00308057] duration[00000000002512350868]
>>>     C3:                  type[C3] promotion[--] demotion[--]
>>> latency[085] usage[00126109] duration[00000000000772728489]
>>>     C4:                  type[C3] promotion[--] demotion[--]
>>> latency[185] usage[00537539] duration[00000000008753288513]
>>> m
>>> 
>>> [    3.345147] processor_driver-0392 [00] processor_get_info    :
>>> Bus mastering arbitration control present
>>> [    3.345187] processor_driver-0474 [00] processor_get_info    :
>>> Processor [0:0] [    3.345215] processor_throttling-1141 [00]
>>> processor_get_throttli: pblk_address[0x00001010] duty_offset[3]
>>> duty_width[1] [    3.345233] processor_throttling-1187 [00]
>>> processor_get_throttli: Found 2 throttling states [    3.345246]
>>> processor_throttling-0657 [00] processor_get_throttli: Throttling
>>> state is T0 (1000% throttling applied) [    3.345585]
>>> processor_idle-0526 [00] processor_get_power_in: Found 4 power
>>> states [    3.345931] processor_throttling-0218 [00]
>>> processor_throttling_i: Assume no T-state coordination [
>>> 82.129875] processor_perflib-0349 [00] processor_get_performa: Found
>>> 6 performance states [   82.129889] processor_perflib-0367 [00]
>>> processor_get_performa: Extracting state 0 [   82.129901]
>>> processor_perflib-0385 [00] processor_get_performa: State [0]:
>>> core_frequency[2133] power[27000] transition_latency[10]
>>> bus_master_latency[10] control[0x1029] status[0x1029] [   82.129918]
>>> processor_perflib-0367 [00] processor_get_performa: Extracting state
>>> 1 [   82.129928] processor_perflib-0385 [00] processor_get_performa:
>>> State [1]: core_frequency[1867] power[24000] transition_latency[10]
>>> bus_master_latency[10] control[0xe25] status[0xe25] [   82.129945]
>>> processor_perflib-0367 [00] processor_get_performa: Extracting state
>>> 2 [   82.129955] processor_perflib-0385 [00] processor_get_performa:
>>> State [2]: core_frequency[1600] power[21000] transition_latency[10]
>>> bus_master_latency[10] control[0xc20] status[0xc20] [   82.129972]
>>> processor_perflib-0367 [00] processor_get_performa: Extracting state
>>> 3 [   82.129982] processor_perflib-0385 [00] processor_get_performa:
>>> State [3]: core_frequency[1333] power[19000] transition_latency[10]
>>> bus_master_latency[10] control[0xa1c] status[0xa1c] [   82.129998]
>>> processor_perflib-0367 [00] processor_get_performa: Extracting state
>>> 4 [   82.130009] processor_perflib-0385 [00] processor_get_performa:
>>> State [4]: core_frequency[1067] power[16000] transition_latency[10]
>>> bus_master_latency[10] control[0x817] status[0x817] [   82.130025]
>>> processor_perflib-0367 [00] processor_get_performa: Extracting state
>>> 5 [   82.130035] processor_perflib-0385 [00] processor_get_performa:
>>> State [5]: core_frequency[800] power[13000] transition_latency[10]
>>> bus_master_latency[10] control[0x612] status[0x612] [   82.130173]
>>> processor_perflib-0486 [00] processor_notify_smm  : No SMI port or
>>> pstate_control
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel