Bug#550562: Blob firmware loader corrupts filesystem

2010-01-13 Thread Davide Bologna
On Wed, 2010-01-13 at 02:30 -0800, Ben Wong wrote:
  When you say it 'only affect systems that use the radeon/R200_cp.bin
  firmware' do you mean that you tested systems with other Radeon GPU
  versions and they were not affected, or that this problem appeared after
  the firmware was separated out (Debian package version 2.6.29-1)?
 
 My apologies for the poorly worded sentence.  While it happens to be
 the case that all the reports of this corruption that I've seen on the
 Net concern the R200 firmware, I have not tested other Radeon GPUs.

Testing another GPU would prove that the problem is related to the
Radeon 200 firmware. Just my 2 cents.

Davide




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#531488: Kernel panic booting Oracle Linux in kvm

2009-10-05 Thread Davide Bologna
I installed RHEL 5.4 on Squeeze with no problems at all. I do not
stressed kvm but it seems to work fine.

The kernel I am using is linux-image-2.6.30-1-amd64 (2.6.30-6).

For me the problem is solved and the bug can by closed.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#531488: Kernel panic booting Oracle Linux in kvm

2009-06-06 Thread Davide Bologna
No luck. The patch I've previously described is already merged in
lenny's kvm-72. Then something must have changed in kvm-85 to make
things work; I will try to find out what in mailing list and changelog.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#531488: Kernel panic booting Oracle Linux in kvm

2009-06-06 Thread Davide Bologna
I have found out something interesting. The attached patch, which I
think should fix the bug, is present in kvm-72 Debian sources but not in
the 2.6.26-2 kernel source. So maybe rebuilding kvm from source cures
the problem; I will test this.

m...@fujiko:/tmp$
diff /home/mud/src/debian-bug-531488/linux-source-2.6.26/arch/x86/kvm/svm.c 
/tmp/linux-source-2.6.26/arch/x86/kvm/svm.c
1316,1319d1315
   case MSR_K7_PERFCTR0:
   case MSR_K7_PERFCTR1:
   case MSR_K7_PERFCTR2:
   case MSR_K7_PERFCTR3:
1321,1323c1317,1319
* Just discard all writes to the performance counters; this
* should keep both older linux and windows 64-bit guests
* happy
---
* only support writing 0 to the performance counters for now
* to make Windows happy. Should be replaced by a real
* performance counter emulation later.
1325,1326c1321,1322
   pr_unimpl(vcpu, unimplemented perfctr wrmsr: 0x%x data 
0x%llx\n,
ecx, data);
 
---
   if (data != 0)
   goto unhandled;
1328a1325
   unhandled:
m...@fujiko:/tmp$ 


diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 5528121..dc91b09 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1312,16 +1312,19 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, unsigned ecx, u64 data)
 	case MSR_K7_EVNTSEL1:
 	case MSR_K7_EVNTSEL2:
 	case MSR_K7_EVNTSEL3:
+	case MSR_K7_PERFCTR0:
+	case MSR_K7_PERFCTR1:
+	case MSR_K7_PERFCTR2:
+	case MSR_K7_PERFCTR3:
 		/*
-		 * only support writing 0 to the performance counters for now
-		 * to make Windows happy. Should be replaced by a real
-		 * performance counter emulation later.
+		 * Just discard all writes to the performance counters; this
+		 * should keep both older linux and windows 64-bit guests
+		 * happy
 		 */
-		if (data != 0)
-			goto unhandled;
+		pr_unimpl(vcpu, unimplemented perfctr wrmsr: 0x%x data 0x%llx\n, ecx, data);
+
 		break;
 	default:
-	unhandled:
 		return kvm_set_msr_common(vcpu, ecx, data);
 	}
 	return 0;


Bug#531488: Kernel panic booting Oracle Linux in kvm

2009-06-06 Thread Davide Bologna
Finally I've find out. The problem is kvm source of package
linux-source-2.6.26 does not include the kvm-66-fix-k7-msr2.patch.

kvm source in package kvm-source 72+dfsg-5 seems to be more up to date;
it includes the k7 patch and more, it seems. Look diffs in the
attachment.

I do not know if this is an error on is intended to be this way.

Anyway, rebuilding kvm modules from source packages solve the problem.
Now long term support kernel 2.6.18 boots fine.
m...@fujiko:/tmp$ dpkg -l linux-source* kvm*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name  Version   
Description
+++-=-=-==
ii  kvm   72+dfsg-5 Full 
virtualization on x86 hardware
un  kvm-data  none(no 
description available)
un  kvm-modules   none(no 
description available)
ii  kvm-modules-2.6.26-1-amd6472+dfsg-3+2.6.26-11   kvm 
modules for Linux (kernel 2.6.26-1-amd64).
ii  kvm-modules-2.6.26-2-amd6472+dfsg-5+2.6.26-15   kvm 
modules for Linux (kernel 2.6.26-2-amd64).
ii  kvm-source72+dfsg-5 Source 
for the KVM driver
un  linux-source  none(no 
description available)
un  linux-source-2.6  none(no 
description available)
pn  linux-source-2.6.22   none(no 
description available)
ii  linux-source-2.6.26   2.6.26-15 Linux 
kernel source for version 2.6.26 with Debian patches
m...@fujiko:/tmp$ tar -xjf /usr/src/linux-source-2.6.26.tar.bz2 
m...@fujiko:/tmp$ tar -xjf /usr/src/kvm.tar.bz2
m...@fujiko:/tmp$ diff linux-source-2.6.26/arch/x86/kvm/svm.c modules/kvm/svm.c
20a21
 #include kvm_cache_regs.h
29a31,33
 #define __ex(x) __kvm_handle_fault_on_reboot(x)
 
 MODULE_INFO(version, kvm-72);
36,39d39
 #define DB_VECTOR 1
 #define UD_VECTOR 6
 #define GP_VECTOR 13
 
63d62
 static void svm_flush_tlb(struct kvm_vcpu *vcpu);
133c132
   asm volatile (SVM_CLGI);
---
   asm volatile (__ex(SVM_CLGI));
138c137
   asm volatile (SVM_STGI);
---
   asm volatile (__ex(SVM_STGI));
143c142
   asm volatile (SVM_INVLPGA :: a(addr), c(asid));
---
   asm volatile (__ex(SVM_INVLPGA) :: a(addr), c(asid));
237,241c236,238
   if (svm-next_rip - svm-vmcb-save.rip  MAX_INST_SIZE)
   printk(KERN_ERR %s: ip 0x%llx next 0x%llx\n,
  __func__,
  svm-vmcb-save.rip,
  svm-next_rip);
---
   if (svm-next_rip - kvm_rip_read(vcpu)  MAX_INST_SIZE)
   printk(KERN_ERR %s: ip 0x%lx next 0x%llx\n,
  __func__, kvm_rip_read(vcpu), svm-next_rip);
243c240
   vcpu-arch.rip = svm-vmcb-save.rip = svm-next_rip;
---
   kvm_rip_write(vcpu, svm-next_rip);
286,287c283,284
   struct desc_ptr gdt_descr;
   struct desc_struct *gdt;
---
   struct kvm_desc_ptr gdt_descr;
   struct kvm_desc_struct *gdt;
307c304
   gdt = (struct desc_struct *)gdt_descr.address;
---
   gdt = (struct kvm_desc_struct *)gdt_descr.address;
455c452,453
   }
---
   } else
   kvm_disable_tdp();
580a579
   svm-vcpu.arch.regs[VCPU_REGS_RIP] = save-rip;
615c614
   svm-vmcb-save.rip = 0;
---
   kvm_rip_write(vcpu, 0);
618a618,619
   vcpu-arch.regs_avail = ~0;
   vcpu-arch.regs_dirty = ~0;
721,741d721
 static void svm_vcpu_decache(struct kvm_vcpu *vcpu)
 {
 }
 
 static void svm_cache_regs(struct kvm_vcpu *vcpu)
 {
   struct vcpu_svm *svm = to_svm(vcpu);
 
   vcpu-arch.regs[VCPU_REGS_RAX] = svm-vmcb-save.rax;
   vcpu-arch.regs[VCPU_REGS_RSP] = svm-vmcb-save.rsp;
   vcpu-arch.rip = svm-vmcb-save.rip;
 }
 
 static void svm_decache_regs(struct kvm_vcpu *vcpu)
 {
   struct vcpu_svm *svm = to_svm(vcpu);
   svm-vmcb-save.rax = vcpu-arch.regs[VCPU_REGS_RAX];
   svm-vmcb-save.rsp = vcpu-arch.regs[VCPU_REGS_RSP];
   svm-vmcb-save.rip = vcpu-arch.rip;
 }
 
883,886d862
   unsigned long old_cr4 = to_svm(vcpu)-vmcb-save.cr4;
 
   if (npt_enabled  ((old_cr4 ^ cr4)  X86_CR4_PGE))
   force_new_asid(vcpu);
967c943,945
   return to_svm(vcpu)-db_regs[dr];
---
   unsigned long val = to_svm(vcpu)-db_regs[dr];
   KVMTRACE_2D(DR_READ, vcpu, (u32)dr, (u32)val, handler);
   return val;
1026,1032c1004,1011
   /*
* FIXME: Tis shouldn't be necessary here, but there is a flush
* missing in the MMU code. Until we find