Re: [Xen-devel] Latest Arndale Xen, dom0 kernel stuck on ASIX mac.

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 06/07/2013 07:09 PM, Sander Bogaert wrote:

> On 7 June 2013 17:03, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
>> On 06/07/2013 03:40 PM, Sander Bogaert wrote:
>>
>>> On 6 June 2013 12:37, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
>>>> On 06/06/2013 09:52 AM, Sander Bogaert wrote:
>>>>
>>>>
>>>>>> No luck... I attached the crashing dom0 log.
>>>>>> Please note I used the  arndale_xen_dom0_defconfig make target
>>>>>> guessing that's the one you intended to write :-)
>>>>>>
>>>>>> This is a different crash however so it did change things...
>>>>>>
>>>>>> It seems like the sda drive isn't detected at all? Maybe the driver is
>>>>>> broke? In the dts I just change root=mmc... into root=/dev/sda1 which
>>>>>> works for my older kernel/xen versions.
>>>>
>>>>
>>>> [    5.366313] exynos-sata 122f0000.sata: failed to get sata phy for port 0
>>>>
>>>> ...
>>>> [    6.084555] exynos-sata 122f0000.sata: forcing PORTS_IMPL to 0x1
>>>> [    6.084606] platform 122f0000.sata: Driver exynos-sata requests probe 
>>>> deferral
>>>> [    6.085869] input: gpio_keys.5 as /devices/gpio_keys.5/input/input0
>>>> [    6.086535] exynos-sata 122f0000.sata: forcing PORTS_IMPL to 0x1
>>>> [    6.086584] platform 122f0000.sata: Driver exynos-sata requests probe 
>>>> deferral
>>>>
>>>> Could you try the same kernel on bare metal and see what happens?
>>>>
>>>
>>> all seems to be fine for native Linux, the partitions on the ssd get
>>> detected so I'm guessing it must be a Xen issue. It's an issue I
>>> didn't have with older versions... ( end of April ).
>>>
>>> I attached the a log of booting the kernel native. It does have a
>>> fault at the end but that's because sda5 doesn't exist. I didn't want
>>> to possibly mess up my working sda1 partition.
>>
>>
>> Thanks, I think I have found this issue. The i2c tries to register
>> cpufreq callback. I disabled both cpufreq and cpuidle to avoid specific
>> board callback.
>>
>> Could you try this small patch?
>>
>> ===================================================================
>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> index bcf4e76..3a8cee3 100644
>> --- a/arch/arm/xen/enlighten.c
>> +++ b/arch/arm/xen/enlighten.c
>> @@ -299,7 +299,6 @@ static int __init xen_pm_init(void)
>>          * cpu idle and cpu freq
>>          */
>>         disable_cpuidle();
>> -       disable_cpufreq();
>>
>>         return 0;
>>  }
>> ===============================================================
>>
> 
> Applying these changes allow me to boot but I end up with a read-only
> filesystem so something must still be wrong.
> 
> I first removed both disable_* calls the way you described and not the
> way you showed in the patch. After that I only removed cpufreq as the
> patch shows. Both tries have the same result, I attached a log.
> 


Is rw on the linux command line change something? Otherwise, you can try
to boot up to login shell on bare metal and see if it's still read-only.

Cheers,

-- 
Julien

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel