Mailing List Archive

I disagree with this change; it should rather be done similarly to the merge for x86-64's xor.h. I wonder why there was
no Xen-specific version of that file in the first place for i386, while there was one for x86-64 (which is why I didn't
notice the need to change anything there)... Jan

>>> Chris Wright <chrisw@sous-sol.org> 12.01.06 00:54:34 >>>
This reverts BUG() to WARN_ON() plus actual write which will be trapped
and emulated. I actually think the emulation is fine, since the
read/write pairs in XMMS_SAVE/RESTORE can't see TS, and there's proper
clts() call. This allows my machine to boot rather than BUG() during
raid5 checksum tests:

kernel BUG at include2/asm/xor.h:633!
invalid opcode: 0000 [#1]
SMP
Modules linked in:
CPU: 0
EIP: 0061:[<c030be81>] Not tainted VLI
EFLAGS: 00010246 (2.6.15)
EIP is at xor_sse_2+0x1ff/0x20d

Signed-off-by: Chris Wright <chrisw@sous-sol.org>

--- a/include/asm-i386/mach-xen/mach_system.h Mon Jan 9 19:28:35 2006
+++ b/include/asm-i386/mach-xen/mach_system.h Wed Jan 11 14:24:55 2006
@@ -12,7 +12,9 @@
:"=r" (__dummy)); \
__dummy; \
})
-#define write_cr0(x) BUG()
+#define write_cr0(x) \
+ WARN_ON(1); \
+ __asm__ __volatile__("movl %0,%%cr0": :"r" (x));

#define read_cr2() ({ \
unsigned int __dummy; \
@@ -38,8 +40,9 @@
:"=r" (__dummy)); \
__dummy; \
})
-#define write_cr4(x) BUG()
-
+#define write_cr4(x) \
+ WARN_ON(1); \
+ __asm__ __volatile__("movl %0,%%cr4": :"r" (x));
/*
* Clear and set 'TS' bit respectively
*/

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

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

Hi,

On Thu, 2006-01-12 at 08:55 +0100, Jan Beulich wrote:

> I disagree with this change; it should rather be done similarly to the
> merge for x86-64's xor.h.

Whichever way it's done, we definitely don't want to preserve the
WARN_ON():

> -#define write_cr0(x) BUG()
> +#define write_cr0(x) \
> + WARN_ON(1); \
> + __asm__ __volatile__("movl %0,%%cr0": :"r" (x));

That will let the boot xor tests pass, but will result in massive
console spam if anybody actually uses raid5. Better to fix it for good
right away, either by relying on the hypervisor %cr0 virtualisation or
just by doing a conditional stts() in the XMMS_RESTORE (the latter is
probably more efficient.)

--Stephen



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

* Stephen C. Tweedie (sct@redhat.com) wrote:
> On Thu, 2006-01-12 at 08:55 +0100, Jan Beulich wrote:
>
> > I disagree with this change; it should rather be done similarly to the
> > merge for x86-64's xor.h.
>
> Whichever way it's done, we definitely don't want to preserve the
> WARN_ON():

Agreed, I just left it there to actually look for other issues when
booting. I'll re-grep for those writes, consider Jan's objections and
repsin.

thanks,
-chris

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