Xen devel - Jan 2008 - [PATCH] force HPET support on buggy NVidia-based machines

While playing around with some cpufreq issues, I found out that Xen unstable 
is currently unable to use the HPET timer of my NVidia Nforce Pro-based 
machine.

Some research on the net revealed that quite a lot dual socket machines (i.e. 
workstations and small servers from Dell and HP) don''t provide correct
ACPI
information about this timer, even though the HPET is present and functional. 
Very recent Linux kernels (starting from 2.6.23(?)) as well as LinuxBIOS 
therefore provide a workaround to enable the HPET anyway by scanning the PCI 
bus for suspicious devices and querying them directly. 

I''ve ported a part of this workaround to Xen. To enable it, apply the
patch
below and pass the cmd line arg "clocksource=hpet_nv" to Xen. This
patch
currently only covers some NVidia chipsets with the PCI ids shown in the 
patch.Other chipsets may need a similar procedure. The original Linux source 
even covers Intel (ICH4) and VIA chipsets. The patch below has been tested on 
my Tyan K8SE mainboard using a NForce Pro 2200 chipset and does it''s
job
without woes so far.

I''m not sure if patches like this one are really a good idea for Xen,
but
maybe it helps some other people to run Xen more smoothly on their 
development machines.

Regards,
  Holger	

Signed-off-by: Holger Steinhaus <hsteinhaus@gmx.de>


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

>I''m not sure if patches like this one are really a good idea for
Xen, but
>maybe it helps some other people to run Xen more smoothly on their 
>development machines.
Besides having reservations about this kind of change in general, your
workaround looks functionally quite different from the Linux one,
despite you having said that you cloned it from that code. Any reason
for this?

Jan


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

> Besides having reservations about this kind of change in general, your
> workaround looks functionally quite different from the Linux one,
> despite you having said that you cloned it from that code. Any reason
> for this?
My patch is based on this one: http://lkml.org/lkml/2007/4/17/354
Some minor changes were necessary to resolve some dependencies from the Linux 
kernel. Finally, I did not include any Intel or VIA related stuff, as
I''m not
able to test it due to the lack of appropriate hardware. 

Regards,
  Holger


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

>>> Holger Steinhaus <hsteinhaus@gmx.de> 25.01.08 12:53
>>>
>> Besides having reservations about this kind of change in general, your
>> workaround looks functionally quite different from the Linux one,
>> despite you having said that you cloned it from that code. Any reason
>> for this?
>My patch is based on this one: http://lkml.org/lkml/2007/4/17/354 
>Some minor changes were necessary to resolve some dependencies from the
Linux
>kernel. Finally, I did not include any Intel or VIA related stuff, as
I''m not
>able to test it due to the lack of appropriate hardware. 
But this afaict never made it into any Linux version; I checked 2.6.24
and the workaround there looks different (and without knowing any
chipset details it seems to me that both approaches have some
weaknesses).

Jan


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