RE: Powernow-k8 support

RE: Powernow-k8 support

[Langsdorf, Mark]

> On 11 Jun 2006, at 20:48, Christian Roessner wrote:
> 
> > I have activated debugging. The output is attached.
> >
> > dmesg.gz is the native kernel with debug enabled both 
> others are self 
> > explaining ;-) ; also debug enabled
> 
> Edit source file arch/i386/kernel/cpu/cpufreq/powernow-k8.c 
> and change use of phys_to_virt() to isa_bus_to_virt().

Is this a change that needs to made in the mainstream
driver?  It's only called in the legacy PSB code, and
AMD is deprecating support for PSB on newer processors.

-Mark Langsdorf
AMD, Inc.

Re: Powernow-k8 support

[Keir Fraser]

On 12 Jun 2006, at 17:00, Langsdorf, Mark wrote:

>> Edit source file arch/i386/kernel/cpu/cpufreq/powernow-k8.c
>> and change use of phys_to_virt() to isa_bus_to_virt().
>
> Is this a change that needs to made in the mainstream
> driver?  It's only called in the legacy PSB code, and
> AMD is deprecating support for PSB on newer processors.

It can be assessed when we actually support Powernow in Xen. As you say 
this is legacy code anyway, so we may not care so much (depends when it 
became legacy?).

  -- Keir

Re: Powernow-k8 support

[Christian Roessner]

[-- Attachment #1.1: Type: text/plain, Size: 1130 bytes --]

Hi,

Keir Fraser schrieb:
> 
> On 12 Jun 2006, at 17:00, Langsdorf, Mark wrote:
> 
>>> Edit source file arch/i386/kernel/cpu/cpufreq/powernow-k8.c
>>> and change use of phys_to_virt() to isa_bus_to_virt().
>>
>> Is this a change that needs to made in the mainstream
>> driver?  It's only called in the legacy PSB code, and
>> AMD is deprecating support for PSB on newer processors.
> 
> It can be assessed when we actually support Powernow in Xen. As you say
> this is legacy code anyway, so we may not care so much (depends when it
> became legacy?).

Well, I thought there would be outstanding patches which actually fix
the problems. Did I missunderstand this? (I am from Germany. Maybe some
problems in understanding).

If I did -not- missunderstand, can you send me this code, so I may test
this here?

Thanks

Christian

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


-- 
Tel.: 0641-2097252, Mobil: 0171-3611230
PGP: http://www.roessner-net.com/0x6B929997.asc




[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Powernow-k8 support

[Keir Fraser]

On 12 Jun 2006, at 17:58, Christian Roessner wrote:

> Well, I thought there would be outstanding patches which actually fix
> the problems. Did I missunderstand this? (I am from Germany. Maybe some
> problems in understanding).
>
> If I did -not- missunderstand, can you send me this code, so I may test
> this here?

It's back in the xen-devel archives:

http://lists.xensource.com/archives/html/xen-devel/2006-04/msg00484.html

  -- Keir

Re: Powernow-k8 support

[Christian Roessner]

[-- Attachment #1.1.1: Type: text/plain, Size: 1471 bytes --]

> It's back in the xen-devel archives:
> 
> http://lists.xensource.com/archives/html/xen-devel/2006-04/msg00484.html
> 


One question for patch

xen-cpufreq-amd-powernow-k8.diff

What about line number

140 +    __update_vcpu_system_time(current);

This makes trouble while trying to compile (implicit decalaration of
function...). As I could read in the Changelog, this was removed
sometime ago.

changeset:   9644:8821da562fe0
user:        kaf24@firebug.cl.cam.ac.uk
date:        Sat Apr 22 10:29:27 2006 +0100
summary:     Remove update_vcpu_system_time() call from the per-VCPU timer

Do I also need one of these patches:

cpufreq-xen-dom0-func.diff
cpufreq-xen-linux-2.6.16.diff

I tested only the first patch. To get the xen-3.0-3.0.2+hg9681 compiled,
I commented out the line shown above.

The system seems to start and powernow-k8 seems to work. But something
still seems to be wrong, because the nvidia driver crashes and it does
not crash with the same kernel in native linux mode (Not booted in xen).

I attached the nvidia dump. Maybe you could have a look at this :-)

At the moment of this writing, I only can use the nv driver and this one
only supports 1024x768, so this is not really funny on an 19" LCD ;-)

But so far, thanks very much. I hope you still may/want to help me with
this issue.

Christian



-- 
Tel.: 0641-2097252, Mobil: 0171-3611230
PGP: http://www.roessner-net.com/0x6B929997.asc



[-- Attachment #1.1.2: nvidia.dump --]
[-- Type: text/plain, Size: 2765 bytes --]

nvidia: module license 'NVIDIA' taints kernel.
ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 19
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKE] -> GSI 19 (level, low) -> IRQ 16
NVRM: loading NVIDIA Linux x86 Kernel Module  1.0-8762  Mon May 15 13:06:38 PDT
2006
general protection fault: 0000 [#1]
Modules linked in: nvidia parport_pc lp parport capi capifs xt_tcpudp ip6table_filter ip6_tables xt_state xt_pkttype iptable_raw xt_CLASSIFY xt_connmark xt_physdev xt_conntrack iptable_mangle ipt_ULOG ipt_TTL ipt_ttl ipt_TOS ipt_tos ipt_TCPMSS ipt_SAME ipt_REJECT ipt_REDIRECT ipt_recent ipt_policy ipt_owner ipt_NETMAP
ipt_multiport ipt_MASQUERADE ipt_LOG ipt_iprange ipt_hashlimit ipt_esp ipt_ECN ipt_ecn ipt_DSCP ipt_dscp ipt_CLUSTERIP ipt_ah ipt_addrtype ip_nat_irc ip_nat_tftp ip_nat_ftp ip_conntrack_irc ip_conntrack_tftp ip_conntrack_ftp iptable_nat ip_nat ip_conntrack nfnetlink iptable_filter ip_tables x_tables md5 ipv6 zaurus cdc_ether usbnet usbhid it87 hwmon_vid lm90 hwmon eeprom i2c_isa saa7134 video_buf
compat_ioctl32 v4l1_compat ir_kbd_i2c ir_common videodev tuner v4l2_common tda9887 snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq snd_emu10k1 snd_rawmidi snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep ohci1394 ieee1394 b1pci b1 i2c_nforce2 ehci_hcd ohci_hcd snd kernelcapi usbcore soundcore forcedeth i2c_core evdev
CPU:    0
EIP:    0061:[<ecc0ba5a>]    Tainted: P      VLI
EFLAGS: 00010082   (2.6.16.20-4 #1)
EIP is at __nv_setup_pat_entries+0x2c/0x9f [nvidia]
eax: c005003b   ebx: 00000277   ecx: 00000277   edx: 00070406
esi: 00000000   edi: ecde1ec0   ebp: 00000000   esp: d2edbde4
ds: 007b   es: 007b   ss: 0069
Process insmod (pid: 6198, threadinfo=d2eda000 task=d2642030)
Stack: <0>00000277 00000000 ecde1ec0 ecddf680 ecc0bbcc 00000000 ecc514f8 00070406
       00070406 00000001 ecde42d3 ecc52a7a ecc51200 ecc52a6d d2edbe28 00000000
       00000000 ffffffff d9f98b9c ec49e000 ec8ab074 b0133f21 b03e22a4 00000001
Call Trace:
 [<ecc0bbcc>] __nv_enable_pat_support+0x5c/0x92 [nvidia]
 [<ecde42d3>] nvidia_init_module+0x2d3/0x3d3 [nvidia]
 [<b0133f21>] sys_init_module+0x1a1/0x1820
 [<b01554b0>] kmem_cache_destroy+0x0/0x140
 [<b0158a18>] do_sync_read+0xd8/0x140
 [<b012db50>] autoremove_wake_function+0x0/0x60
 [<b0174382>] mntput_no_expire+0x22/0x80
 [<b015a0b7>] __fput+0x147/0x180
 [<b0157082>] filp_close+0x52/0x90
 [<b0104cc9>] syscall_call+0x7/0xb
Code: ec 10 89 1c 24 89 74 24 04 89 7c 24 08 89 6c 24 0c a1 ac 2b 34 b0 0f b6 68 01 c6 40 01 01 0f 20 c0 25 ff ff ff df 0d 00 00 00 40 <0f> 22 c0 0f 09 0f 20 e6 89 f0 c1 e8 07 89 c7 83 e7 01 74 07 89


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Powernow-k8 support

[Keir Fraser]

On 13 Jun 2006, at 09:49, Christian Roessner wrote:

> One question for patch
>
> xen-cpufreq-amd-powernow-k8.diff
>
> What about line number
>
> 140 +    __update_vcpu_system_time(current);
>
> This makes trouble while trying to compile (implicit decalaration of
> function...). As I could read in the Changelog, this was removed
> sometime ago.

You do want that line. Remove 'static inline' modifiers from the 
function definition in arch/x86/time.c.

As for your nvidia driver crashes: where do you get that driver from? 
Is it binary-only?

  -- Keir

Re: Powernow-k8 support

[Christian Roessner]

[-- Attachment #1.1: Type: text/plain, Size: 1312 bytes --]

>> 140 +    __update_vcpu_system_time(current);
>>
>> This makes trouble while trying to compile (implicit decalaration of
>> function...). As I could read in the Changelog, this was removed
>> sometime ago.
> 
> You do want that line. Remove 'static inline' modifiers from the
> function definition in arch/x86/time.c.

The problem is that the line containing
__update_vcpu_system_time(current); is the only one inside the whole
source directory.

desktop xen-3.0-3.0.2+hg9681 # grep -R __update_vcpu_system_time *
xen/arch/x86/time.c:    __update_vcpu_system_time(current);
xen-cpufreq-amd-powernow-k8.diff:+    __update_vcpu_system_time(current);

The function itself does not have modifieres static inline:

999 int handle_k8_fidvid_ctl_msr_write(u32 lo, u32 hi) {

> As for your nvidia driver crashes: where do you get that driver from? Is
> it binary-only?

Some parts of the driver are binary only, some not. Unfortunatley the
source part is licenced under NVIDIA stuff.

If this is _REALLY_ a nvidia problem, I could paste the dump to NView
forum and ask the nvidia developers for help with the nvidia driver (But
I guess, I will not get help there).

>  -- Keir
> 


-- 
Tel.: 0641-2097252, Mobil: 0171-3611230
PGP: http://www.roessner-net.com/0x6B929997.asc




[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Powernow-k8 support

[Keir Fraser]

On 13 Jun 2006, at 10:24, Christian Roessner wrote:

> Some parts of the driver are binary only, some not. Unfortunatley the
> source part is licenced under NVIDIA stuff.
>
> If this is _REALLY_ a nvidia problem, I could paste the dump to NView
> forum and ask the nvidia developers for help with the nvidia driver 
> (But
> I guess, I will not get help there).

It really depends what is hidden inside the binary-only portion. If 
they try to enable/disable interrupts in there, for example, then the 
driver is going to be unreliable. If they provide accessors for that 
kind of operation in their 'open source' wrapper, then that shouldn't 
be a problem as they will link against the versions modified for Xen. 
Looking at the functions exported by the source wrapper might give you 
a clue, or try 'objdump -d' on the binary-only portion and grep for 
things like cli, sti and popf.

  -- Keir

Re: Powernow-k8 support

[Christian Roessner]

[-- Attachment #1.1.1: Type: text/plain, Size: 1281 bytes --]

Hi,

> It really depends what is hidden inside the binary-only portion. If they
> try to enable/disable interrupts in there, for example, then the driver
> is going to be unreliable. If they provide accessors for that kind of
> operation in their 'open source' wrapper, then that shouldn't be a
> problem as they will link against the versions modified for Xen. Looking
> at the functions exported by the source wrapper might give you a clue,
> or try 'objdump -d' on the binary-only portion and grep for things like
> cli, sti and popf.

I searched around inside the NVidia forum and I found 2 patches, which I
applied to the hypervisor and to nv.c. Now, CPUfreq is working fine here
and I successfully use the nvidia driver. I have attached both patches.
Maybe someone else may have the same problem, so in this thread he/she
may find all neccessary info, whatever.

Only one thing left ist the problem with the line

line 1058     /* __update_vcpu_system_time(current); */

But everything is working with this solution. What should this be for?

I have noticed one other interesting thing with Xen: openVPN is nomore
able to initialize any tunnels. Does this have something to do with the
__update_vcpu_system_time function?

Kind regards
Christian

[-- Attachment #1.1.2: patch-2.6-xen-sparse-nv.diff --]
[-- Type: text/plain, Size: 1543 bytes --]

diff -urN linux-2.6-xen-sparse/arch/i386/mm/hypervisor.c linux-2.6-xen-sparse-nv/arch/i386/mm/hypervisor.c
--- linux-2.6-xen-sparse/arch/i386/mm/hypervisor.c	2006-04-13 19:48:37.000000000 +0200
+++ linux-2.6-xen-sparse-nv/arch/i386/mm/hypervisor.c	2006-04-16 15:34:51.000000000 +0200
@@ -133,6 +133,7 @@
 	op.cmd = MMUEXT_TLB_FLUSH_LOCAL;
 	BUG_ON(HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF) < 0);
 }
+EXPORT_SYMBOL(xen_tlb_flush);
 
 void xen_invlpg(unsigned long ptr)
 {
diff -urN linux-2.6-xen-sparse/drivers/xen/core/evtchn.c linux-2.6-xen-sparse-nv/drivers/xen/core/evtchn.c
--- linux-2.6-xen-sparse/drivers/xen/core/evtchn.c	2006-04-13 19:48:37.000000000 +0200
+++ linux-2.6-xen-sparse-nv/drivers/xen/core/evtchn.c	2006-04-16 15:34:04.000000000 +0200
@@ -188,7 +188,7 @@
 {
 	(void)HYPERVISOR_xen_version(0, NULL);
 }
-EXPORT_SYMBOL_GPL(force_evtchn_callback);
+EXPORT_SYMBOL(force_evtchn_callback);
 
 /* NB. Interrupts are disabled on entry. */
 asmlinkage void evtchn_do_upcall(struct pt_regs *regs)
diff -urN linux-2.6-xen-sparse/drivers/xen/core/features.c linux-2.6-xen-sparse-nv/drivers/xen/core/features.c
--- linux-2.6-xen-sparse/drivers/xen/core/features.c	2006-04-13 19:48:37.000000000 +0200
+++ linux-2.6-xen-sparse-nv/drivers/xen/core/features.c	2006-04-16 15:33:03.000000000 +0200
@@ -12,7 +12,7 @@
 #include <xen/features.h>
 
 u8 xen_features[XENFEAT_NR_SUBMAPS * 32] __read_mostly;
-EXPORT_SYMBOL_GPL(xen_features);
+EXPORT_SYMBOL(xen_features);
 
 void setup_xen_features(void)
 {

[-- Attachment #1.1.3: patch-nv-1.0-8756-xen-3.0.2-2.diff --]
[-- Type: text/plain, Size: 5710 bytes --]

diff -urN nv-1.0-8756/nv.c nv-1.0-8756-xen-3.0.2-2/nv.c
--- nv-1.0-8756/nv.c	2006-03-30 01:02:20.000000000 +0200
+++ nv-1.0-8756-xen-3.0.2-2/nv.c	2006-04-18 03:16:11.000000000 +0200
@@ -16,6 +16,9 @@
 #include "os-agp.h"
 #include "nv-vm.h"
 
+#define io_remap_page_range(vma, start, busaddr, size, prot)	\
+	io_remap_pfn_range(vma, start, busaddr>>PAGE_SHIFT, size, prot)
+
 #ifdef MODULE_ALIAS_CHARDEV_MAJOR
 MODULE_ALIAS_CHARDEV_MAJOR(NV_MAJOR_DEVICE_NUMBER);
 #endif
@@ -44,7 +47,11 @@
 
 int nv_pat_enabled = 0;
 
+#ifdef CONFIG_XEN
+static int nv_disable_pat = 1;
+#else
 static int nv_disable_pat = 0;
+#endif
 NV_MODULE_PARAMETER(nv_disable_pat);
 
 #if defined(NVCPU_X86) || defined(NVCPU_X86_64)
@@ -2087,7 +2094,11 @@
             return -ENXIO;
         }
 
+#ifdef CONFIG_XEN
+        if (io_remap_page_range(vma, vma->vm_start,
+#else
         if (NV_REMAP_PAGE_RANGE(vma->vm_start,
+#endif
                              NV_VMA_OFFSET(vma),
                              NV_VMA_SIZE(vma),
                              vma->vm_page_prot))
@@ -2112,7 +2123,11 @@
             }
         }
 
+#ifdef CONFIG_XEN
+        if (io_remap_page_range(vma, vma->vm_start,
+#else
         if (NV_REMAP_PAGE_RANGE(vma->vm_start,
+#endif
                              NV_VMA_OFFSET(vma),
                              NV_VMA_SIZE(vma),
                              vma->vm_page_prot))
@@ -2155,7 +2170,11 @@
         NV_ATOMIC_INC(at->usage_count);
         nv_up(nvl->at_lock);
 
+#ifdef CONFIG_XEN
+        if (io_remap_page_range(vma, vma->vm_start,
+#else
         if (NV_REMAP_PAGE_RANGE(vma->vm_start,
+#endif
                                 NV_VMA_OFFSET(vma),
                                 NV_VMA_SIZE(vma),
                                 vma->vm_page_prot))
diff -urN nv-1.0-8756/nv-linux.h nv-1.0-8756-xen-3.0.2-2/nv-linux.h
--- nv-1.0-8756/nv-linux.h	2006-03-30 01:02:20.000000000 +0200
+++ nv-1.0-8756-xen-3.0.2-2/nv-linux.h	2006-04-17 01:46:37.000000000 +0200
@@ -19,8 +19,8 @@
 #include <linux/utsname.h>
 
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 4, 0)
-#  error This driver does not support pre-2.4 kernels!
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 4, 7)
+#  error This driver does not support 2.4 kernels older than 2.4.7!
 #elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 5, 0)
 #  define KERNEL_2_4
 #elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 0)
@@ -94,6 +94,7 @@
 
 #include <linux/spinlock.h>
 #include <asm/semaphore.h>
+#include <linux/completion.h>
 #include <linux/highmem.h>
 
 #ifdef CONFIG_PROC_FS
@@ -225,9 +226,13 @@
  * tiny, and the kernel panics when it is exhausted. try to warn the user that
  * they need to boost the size of their pool.
  */
+#if defined(CONFIG_XEN)
+#undef CONFIG_SWIOTLB
+#else
 #if defined(CONFIG_SWIOTLB) && !defined(GFP_DMA32)
 #define NV_SWIOTLB 1
 #endif
+#endif
 
 /*
  * early 2.6 kernels changed their swiotlb codepath, running into a
diff -urN nv-1.0-8756/nv-vm.c nv-1.0-8756-xen-3.0.2-2/nv-vm.c
--- nv-1.0-8756/nv-vm.c	2006-03-30 01:02:20.000000000 +0200
+++ nv-1.0-8756-xen-3.0.2-2/nv-vm.c	2006-04-18 02:16:21.000000000 +0200
@@ -497,7 +497,11 @@
         page_ptr->phys_addr = phys_addr;
         page_ptr->page_count = NV_GET_PAGE_COUNT(page_ptr);
         page_ptr->virt_addr = virt_addr;
+#ifdef CONFIG_XEN
+        page_ptr->dma_addr = phys_to_machine(page_ptr->phys_addr);
+#else
         page_ptr->dma_addr = page_ptr->phys_addr;
+#endif
 
         /* lock the page for dma purposes */
         nv_lock_page(page_ptr);
diff -urN nv-1.0-8756/os-agp.c nv-1.0-8756-xen-3.0.2-2/os-agp.c
--- nv-1.0-8756/os-agp.c	2006-03-30 01:02:20.000000000 +0200
+++ nv-1.0-8756-xen-3.0.2-2/os-agp.c	2006-04-17 01:46:37.000000000 +0200
@@ -284,7 +284,11 @@
 
          page_ptr->phys_addr = (ptr->memory[i] & PAGE_MASK);
          page_ptr->virt_addr = (unsigned long) __va(page_ptr->phys_addr);
+#ifdef CONFIG_XEN
+         page_ptr->dma_addr  = phys_to_machine(page_ptr->phys_addr);
+#else
          page_ptr->dma_addr  = page_ptr->phys_addr;
+#endif
     }
 
     return RM_OK;
diff -urN nv-1.0-8756/os-interface.c nv-1.0-8756-xen-3.0.2-2/os-interface.c
--- nv-1.0-8756/os-interface.c	2006-03-30 01:02:20.000000000 +0200
+++ nv-1.0-8756-xen-3.0.2-2/os-interface.c	2006-04-17 01:46:37.000000000 +0200
@@ -58,9 +58,9 @@
 //
 typedef struct os_sema_s
 {
-    struct semaphore wait;
-    spinlock_t       lock;
-    S032             count;
+    struct completion  completion;
+    spinlock_t         lock;
+    S032               count;
 } os_sema_t;
 
 //
@@ -81,7 +81,7 @@
         return rmStatus;
 
     os_sema = (os_sema_t *)*ppSema;
-    sema_init(&os_sema->wait, 0);
+    init_completion(&os_sema->completion);
     spin_lock_init(&os_sema->lock);
     os_sema->count = 1;
 
@@ -126,7 +126,7 @@
     {
         os_sema->count--;
         spin_unlock_irqrestore(&os_sema->lock, old_irq);
-        down(&os_sema->wait);
+        wait_for_completion(&os_sema->completion);
     }
     else
     {
@@ -203,7 +203,7 @@
     spin_unlock_irqrestore(&os_sema->lock, old_irq);
 
     if (doWakeup)
-        up(&os_sema->wait);
+        complete(&os_sema->completion);
 
     return RM_OK;
 }
@@ -554,6 +554,8 @@
     }
 
     MicroSeconds = MilliSeconds * 1000;
+
+#if 0
     tm_end.tv_usec = MicroSeconds;
     tm_end.tv_sec = 0;
     timeradd(&tm_aux, &tm_end, &tm_end);
@@ -593,6 +595,7 @@
                 MicroSeconds = 0;
         } while ((jiffies = NV_USECS_TO_JIFFIES(MicroSeconds)) != 0);
     }
+#endif
 
     if (MicroSeconds > 1000)
     {

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Powernow-k8 support

[Keir Fraser]

On 13 Jun 2006, at 13:20, Christian Roessner wrote:

> I searched around inside the NVidia forum and I found 2 patches, which 
> I
> applied to the hypervisor and to nv.c. Now, CPUfreq is working fine 
> here
> and I successfully use the nvidia driver. I have attached both patches.
> Maybe someone else may have the same problem, so in this thread he/she
> may find all neccessary info, whatever.

I'm surprised the nvidia driver works at all without this patch.

> Only one thing left ist the problem with the line
>
> line 1058     /* __update_vcpu_system_time(current); */
>
> But everything is working with this solution. What should this be for?

Time may temporarily run at the incorrect rate for a short while (less 
than a second). It's not that critical.

> I have noticed one other interesting thing with Xen: openVPN is nomore
> able to initialize any tunnels. Does this have something to do with the
> __update_vcpu_system_time function?

No. That's just weird. I wouldn't expect this to have any effect on 
openVPN.

  -- Keir

Re: Powernow-k8 support

[Christian Roessner]

[-- Attachment #1.1.1: Type: text/plain, Size: 1228 bytes --]

Keir Fraser schrieb:
> 
> On 13 Jun 2006, at 13:20, Christian Roessner wrote:
> 
>> I searched around inside the NVidia forum and I found 2 patches, which I
>> applied to the hypervisor and to nv.c. Now, CPUfreq is working fine here
>> and I successfully use the nvidia driver. I have attached both patches.
>> Maybe someone else may have the same problem, so in this thread he/she
>> may find all neccessary info, whatever.
> 
> I'm surprised the nvidia driver works at all without this patch.

Without which patch?? The nvidia driver is patched.


>> I have noticed one other interesting thing with Xen: openVPN is nomore
>> able to initialize any tunnels. Does this have something to do with the
>> __update_vcpu_system_time function?
> 
> No. That's just weird. I wouldn't expect this to have any effect on
> openVPN.

Well, the tunnel(s) hangs with problems in TLS negotiation. I do
absolutley not know, if this is timeing critical stuff.

I attahced my time.c. Could you have a look at line 1058 and give me a
hint what to change to get this fixed? Would be really nice.

Thanks

Christian

-- 
Tel.: 0641-2097252, Mobil: 0171-3611230
PGP: http://www.roessner-net.com/0x6B929997.asc



[-- Attachment #1.1.2: time.c.gz --]
[-- Type: application/x-gzip, Size: 9018 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Powernow-k8 support

[Keir Fraser]

On 13 Jun 2006, at 15:12, Christian Roessner wrote:

>>> I searched around inside the NVidia forum and I found 2 patches, 
>>> which I
>>> applied to the hypervisor and to nv.c. Now, CPUfreq is working fine 
>>> here
>>> and I successfully use the nvidia driver. I have attached both 
>>> patches.
>>> Maybe someone else may have the same problem, so in this thread 
>>> he/she
>>> may find all neccessary info, whatever.
>>
>> I'm surprised the nvidia driver works at all without this patch.
>
> Without which patch?? The nvidia driver is patched.

I mean, before you fiddled with powernow at all, you claim that the 
nvidia driver worked just fine for you. And presumably you were running 
at that time without the patch. I'm surprised it worked for you at that 
point.

  -- Keir

Re: Powernow-k8 support

[Christian Roessner]

[-- Attachment #1.1: Type: text/plain, Size: 940 bytes --]

> I mean, before you fiddled with powernow at all, you claim that the
> nvidia driver worked just fine for you. And presumably you were running
> at that time without the patch. I'm surprised it worked for you at that
> point.

One big problem I had was that a friend of mine configured my system for
the first use with xen. He is able to hack thousands commands and you
can not follow all of them :-)

Maybe he had patched the nvidia driver once before, but I could not find
any saved patches. Only those for the hypervisor.

I had much work to clean up the machine in /usr/src and /usr/local/src.

Okay, at the end, I needed some patches from you and the CPUfreq stuff
now is working. I thank you very much for your help and your hints.


If you find some time to look for the time.c file, I also would be happy.

Will all these patches (concerning powernow-k8) merge into stable
Xen-source?

Regards
Christian


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Powernow-k8 support

[Keir Fraser]

On 13 Jun 2006, at 15:57, Christian Roessner wrote:

> Will all these patches (concerning powernow-k8) merge into stable
> Xen-source?

It's in my todo list. There's actually not much to be done I think. I 
was happy to take the patch mostly as-is and clean it up later.

  -- Keir

Re: Powernow-k8 support

[Keir Fraser]

On 13 Jun 2006, at 15:12, Christian Roessner wrote:

> I attahced my time.c. Could you have a look at line 1058 and give me a
> hint what to change to get this fixed? Would be really nice.

The function's called __update_dom_time() in that version of the file, 
not __update_vcpu_time().

  -- Keir

Re: Powernow-k8 support

[Christian Roessner]

[-- Attachment #1.1: Type: text/plain, Size: 158 bytes --]

Hi,

The problem with OpenVPN is fixed. It was not a problem with Xen. The
router did not forward a Port. Sorry with this issue.

Thanks

Christian


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

RE: Powernow-k8 support

[Langsdorf, Mark]

> > Well, I thought there would be outstanding patches which 
> actually fix 
> > the problems. Did I missunderstand this? (I am from Germany. Maybe 
> > some problems in understanding).
> >
> > If I did -not- missunderstand, can you send me this code, so I may 
> > test this here?
> 
> It's back in the xen-devel archives:
> 
> http://lists.xensource.com/archives/html/xen-devel/2006-04/msg
00484.html

Should I (as the powernow-k8 maintainer) be modifying this
code as we add new features?  Most of it looks pretty safe,
but the new 2.00.00 driver uses different MSRs, and there
are other things coming up that will confuse things.

-Mark Langsdorf
AMD, Inc.

Re: Powernow-k8 support

[Keir Fraser]

On 14 Jun 2006, at 22:43, Langsdorf, Mark wrote:

> Should I (as the powernow-k8 maintainer) be modifying this
> code as we add new features?  Most of it looks pretty safe,
> but the new 2.00.00 driver uses different MSRs, and there
> are other things coming up that will confuse things.

One thing I'm a bit undecided on is whether MSR emulation is the right 
way to go, or whether we should just pull the low-level cpufreq drivers 
verbatim into Xen and then provide access to them via hypercalls. We 
could then have a paravirtual cpufreq driver added to Linux. This has 
the advantage that we have less new per-cpu-type code to maintain in 
Xen (we can more easily sync with cpufreq changes in Linux) but it does 
mean we change more Linux code and we'd want to be a bit careful not to 
make the hypercall interface too Linux specific (or too x86 specific).

  -- Keir

Re: Powernow-k8 support

[Christian Roessner]

[-- Attachment #1.1: Type: text/plain, Size: 1316 bytes --]

Keir Fraser schrieb:
> 
> On 14 Jun 2006, at 22:43, Langsdorf, Mark wrote:
> 
>> Should I (as the powernow-k8 maintainer) be modifying this
>> code as we add new features?  Most of it looks pretty safe,
>> but the new 2.00.00 driver uses different MSRs, and there
>> are other things coming up that will confuse things.
> 
> One thing I'm a bit undecided on is whether MSR emulation is the right
> way to go, or whether we should just pull the low-level cpufreq drivers
> verbatim into Xen and then provide access to them via hypercalls. We
> could then have a paravirtual cpufreq driver added to Linux. This has
> the advantage that we have less new per-cpu-type code to maintain in Xen
> (we can more easily sync with cpufreq changes in Linux) but it does mean
> we change more Linux code and we'd want to be a bit careful not to make
> the hypercall interface too Linux specific (or too x86 specific).

Has this something to do with the private mail I sent to Keir Fraser?

I told him that the powernow-k8 support in dom0 seems to work, while in
domUs not. Second was that the shown Bogomips under /proc/cpuinfo never
changes from ~4000, even when the CPU was @ 800.

Regards
Christian
-- 
Tel.: 0641-2097252, Mobil: 0171-3611230
PGP: http://www.roessner-net.com/0x6B929997.asc




[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Powernow-k8 support

[Keir Fraser]

On 15 Jun 2006, at 10:58, Christian Roessner wrote:

>> One thing I'm a bit undecided on is whether MSR emulation is the right
>> way to go, or whether we should just pull the low-level cpufreq 
>> drivers
>> verbatim into Xen and then provide access to them via hypercalls. We
>> could then have a paravirtual cpufreq driver added to Linux. This has
>> the advantage that we have less new per-cpu-type code to maintain in 
>> Xen
>> (we can more easily sync with cpufreq changes in Linux) but it does 
>> mean
>> we change more Linux code and we'd want to be a bit careful not to 
>> make
>> the hypercall interface too Linux specific (or too x86 specific).
>
> Has this something to do with the private mail I sent to Keir Fraser?
>
> I told him that the powernow-k8 support in dom0 seems to work, while in
> domUs not. Second was that the shown Bogomips under /proc/cpuinfo never
> changes from ~4000, even when the CPU was @ 800.

That's a quite separate issue. The 'stale' frequency info in domU is 
harmless.

  -- Keir

RE: Powernow-k8 support

[Langsdorf, Mark]

> On 12 Jun 2006, at 17:00, Langsdorf, Mark wrote:
> 
> >> Edit source file arch/i386/kernel/cpu/cpufreq/powernow-k8.c
> >> and change use of phys_to_virt() to isa_bus_to_virt().
> >
> > Is this a change that needs to made in the mainstream driver?  It's 
> > only called in the legacy PSB code, and AMD is deprecating 
> support for 
> > PSB on newer processors.
> 
> It can be assessed when we actually support Powernow in Xen. 
> As you say this is legacy code anyway, so we may not care so 
> much (depends when it became legacy?).

Older laptops support it.  New laptops, sometimes but not
often.  It will not be part of the BIOS/UEFI for processors 
by 2008.  No multiprocessor system has it.

So it's support for some amount of the installed base, but
I don't know how much.

-Mark Langsdorf
AMD, Inc.

Powernow-k8 support

[Christian Roessner]

[-- Attachment #1.1.1: Type: text/plain, Size: 995 bytes --]

Hi,

I recently subscribed to xen-users asking about a powernow-k8 problem,
but in the meantime I am not sure if the users-list was the right place
for it. So I decided to repeat my question here ;-)

My current config is attached.

--- snip ---
Hi,

I recently installed Xen on my AMD64 for my first time and so far,
everything seems to work pretty fine.  :-)

I tried to enable cpu frequency support.

After booting, I get the following message in Dom0-dmesg:

powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.60.0)
powernow-k8: BIOS error - no PSB or ACPI _PSS objects

I tried to find answers in the mailing-list archive and with Google, but
could not find answers.

Is there support in Xen? Are there any patches, I can download anywhere?

Would be really nice to get an answer

Thanks in advance

--- snap ---

Kind regards

Christian
-- 
Tel.: 0641-2097252, Mobil: 0171-3611230
PGP: http://www.roessner-net.com/0x6B929997.asc




[-- Attachment #1.1.2: xm.dmesg.log.gz --]
[-- Type: application/x-gzip, Size: 1647 bytes --]

[-- Attachment #1.1.3: dmesg.log.gz --]
[-- Type: application/x-gzip, Size: 6034 bytes --]

[-- Attachment #1.1.4: config-xen0-2.6.16.20-3.gz --]
[-- Type: application/x-gzip, Size: 9932 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Powernow-k8 support

[Keir Fraser]

On 11 Jun 2006, at 16:49, Christian Roessner wrote:

> After booting, I get the following message in Dom0-dmesg:
>
> powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 
> 1.60.0)
> powernow-k8: BIOS error - no PSB or ACPI _PSS objects
>
> I tried to find answers in the mailing-list archive and with Google, 
> but
> could not find answers.
>
> Is there support in Xen? Are there any patches, I can download 
> anywhere?

Try adding cpufreq.debug=11 to your domain0 Linux kernel command line. 
That should get more debugging about what's going wrong. Also, what 
does boot output look like for native Linux? Perhaps it's possible to 
see where the cpufreq paths diverge for native versus running on Xen.

  -- Keir

Re: Powernow-k8 support

[Christian Roessner]

[-- Attachment #1.1.1: Type: text/plain, Size: 1247 bytes --]

Hi,

I have activated debugging. The output is attached.

dmesg.gz is the native kernel with debug enabled
both others are self explaining ;-) ; also debug enabled

Thanks in advance
Keir Fraser schrieb:
> 
> On 11 Jun 2006, at 16:49, Christian Roessner wrote:
> 
>> After booting, I get the following message in Dom0-dmesg:
>>
>> powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.60.0)
>> powernow-k8: BIOS error - no PSB or ACPI _PSS objects
>>
>> I tried to find answers in the mailing-list archive and with Google, but
>> could not find answers.
>>
>> Is there support in Xen? Are there any patches, I can download anywhere?
> 
> Try adding cpufreq.debug=11 to your domain0 Linux kernel command line.
> That should get more debugging about what's going wrong. Also, what does
> boot output look like for native Linux? Perhaps it's possible to see
> where the cpufreq paths diverge for native versus running on Xen.
> 
>  -- Keir
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


-- 
Tel.: 0641-2097252, Mobil: 0171-3611230
PGP: http://www.roessner-net.com/0x6B929997.asc



[-- Attachment #1.1.2: dmesg.gz --]
[-- Type: application/x-gzip, Size: 6715 bytes --]

[-- Attachment #1.1.3: xen-dmesg.gz --]
[-- Type: application/x-gzip, Size: 6177 bytes --]

[-- Attachment #1.1.4: xm.xen-dmesg.gz --]
[-- Type: application/x-gzip, Size: 1650 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Powernow-k8 support

[Keir Fraser]

On 11 Jun 2006, at 20:48, Christian Roessner wrote:

> I have activated debugging. The output is attached.
>
> dmesg.gz is the native kernel with debug enabled
> both others are self explaining ;-) ; also debug enabled

Edit source file arch/i386/kernel/cpu/cpufreq/powernow-k8.c and change 
use of phys_to_virt() to isa_bus_to_virt().

  -- Keir

Re: Powernow-k8 support

[Christian Roessner]

[-- Attachment #1.1.1: Type: text/plain, Size: 3519 bytes --]

Hi,

it seems that the change did work partially. But the frequency can not
be changed.

The kernel freezes when udev is loading the alsa modules and/or the
nvidia module. After that the machine may reboot automatically.

Here some infos I found in my /var/log/messages file:

==== Example 1 ====
Jun 12 01:54:02 desktop kernel: NVRM: Trying to sleep during raised irql!!
Jun 12 01:54:02 desktop kernel: NVRM:   are we holding a lock?
Jun 12 01:54:02 desktop kernel: NVRM:   skipping os_delay
Jun 12 01:54:02 desktop kernel: NVRM: Trying to sleep during raised irql!!
Jun 12 01:54:02 desktop kernel: NVRM:   are we holding a lock?
Jun 12 01:54:02 desktop kernel: NVRM:   skipping os_delay
Jun 12 01:54:02 desktop kernel: NVRM: Trying to sleep during raised irql!!
Jun 12 01:54:02 desktop kernel: NVRM:   are we holding a lock?
Jun 12 01:54:02 desktop kernel: NVRM:   skipping os_delay

==== Example 2 ====
Jun 12 01:57:48 desktop kernel: NVRM: loading NVIDIA Linux x86 Kernel
Module  1.0-8762  Mon May 15 13:06:38 PDT 2006
Jun 12 01:57:48 desktop kernel: Modules linked in: snd_emu10k1
snd_rawmidi snd_ac97_codec snd_ac97_bus nvidia snd_pcm_oss snd_mixer_oss
ohci1394 snd_pcm snd_seq_device ieee1394 snd_timer snd_page_alloc
snd_util_mem b1pci b1 snd_hwdep kernelcapi snd i2c_nforce2 ehci_hcd
ohci_hcd soundcore usbcore i2c_core forcedeth evdev
Jun 12 01:57:48 desktop kernel: EIP:    0061:[<ec84fa5a>]    Tainted: P
     VLI
Jun 12 01:57:48 desktop kernel: EFLAGS: 00010082   (2.6.16.20-4 #1)

==== Example 3 ====
Jun 12 02:11:21 desktop kernel: NVRM: loading NVIDIA Linux x86 Kernel
Module  1.0-8762  Mon May 15 13:06:38 PDT 2006
Jun 12 02:11:21 desktop kernel: Modules linked in: nvidia parport_pc lp
parport capi capifs xt_tcpudp ip6table_filter ip6_tables xt_state
xt_pkttype iptable_raw xt_CLASSIFY xt_connmark xt_physdev xt_conntrack
iptable_mangle ipt_ULOG ipt_TTL ipt_ttl ipt_TOS ipt_tos ipt_TCPMSS
ipt_SAME ipt_REJECT ipt_REDIRECT ipt_recent ipt_policy ipt_owner
ipt_NETMAP ipt_multiport ipt_MASQUERADE ipt_LOG ipt_iprange
ipt_hashlimit ipt_esp ipt_ECN ipt_ecn ipt_DSCP ipt_dscp ipt_CLUSTERIP
ipt_ah ipt_addrtype ip_nat_irc ip_nat_tftp ip_nat_ftp ip_conntrack_irc
ip_conntrack_tftp ip_conntrack_ftp iptable_nat ip_nat ip_conntrack
nfnetlink iptable_filter ip_tables x_tables zaurus usbhid md5 ipv6
cdc_ether usbnet it87 hwmon_vid lm90 hwmon eeprom i2c_isa saa7134
video_buf compat_ioctl32 v4l1_compat ir_kbd_i2c ir_common videodev tuner
v4l2_common tda9887 b1pci b1 kernelcapi ohci1394 ieee1394 ehci_hcd
ohci_hcd usbcore forcedeth i2c_nforce2 i2c_core evdev
Jun 12 02:11:21 desktop kernel: EIP:    0061:[<ecab9a5a>]    Tainted: P
     VLI
Jun 12 02:11:21 desktop kernel: EFLAGS: 00010082   (2.6.16.20-4 #1)
Jun 12 02:11:55 desktop exiting on signal 15


So it seems that the nvidia driver has some problems with this code
modification??

Attached the last dmesg output. You my look at the end of this file

Thanks in advance

Christian

Keir Fraser schrieb:
> 
> On 11 Jun 2006, at 20:48, Christian Roessner wrote:
> 
>> I have activated debugging. The output is attached.
>>
>> dmesg.gz is the native kernel with debug enabled
>> both others are self explaining ;-) ; also debug enabled
> 
> Edit source file arch/i386/kernel/cpu/cpufreq/powernow-k8.c and change
> use of phys_to_virt() to isa_bus_to_virt().
> 
>  -- Keir
> 


-- 
Tel.: 0641-2097252, Mobil: 0171-3611230
PGP: http://www.roessner-net.com/0x6B929997.asc



[-- Attachment #1.1.2: dmesg.gz --]
[-- Type: application/x-gzip, Size: 6807 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Powernow-k8 support

[Keir Fraser]

On 12 Jun 2006, at 01:26, Christian Roessner wrote:

> it seems that the change did work partially. But the frequency can not
> be changed.

Ah yes, I have some patches for this that are waiting to get merged 
into the tree.

> The kernel freezes when udev is loading the alsa modules and/or the
> nvidia module. After that the machine may reboot automatically.

Has this started since you made my suggested patch?

  -- Keir