VIA 686B/Data Corruption FAQ
http://www.viahardware.com/686bfaq.shtm Couldn't find a mention of this in the archives, but those interested in the VIA chipset issues should check this out. The page contains the following officail statement from VIA: The data corruption error, which some web sites and people have reported with the 686b Southbridge, is caused by incorrect bios registry setting to the Northbridge. These bios settings were made by motherboard manufacturers, in an attempt to fix a conflict with the Sound Blaster Live Value cards. Information has been provided to all motherboard manufacturers on how to correctly resolve both the data corruption error and the Sound Blaster Live conflict. The patch released by VIA in the 4in1 4.31 drivers replicates the correct bios settings. We provided this patch to make sure as many people got a fix to their Sound Blaster Live problems as soon as possible. Most motherboard manufacturers have now corrected their bios and the patch is not necessarily needed although it will not harm any VIA based system if installed. -- Gareth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VIA 686B/Data Corruption FAQ
http://www.viahardware.com/686bfaq.shtm Couldn't find a mention of this in the archives, but those interested in the VIA chipset issues should check this out. The page contains the following officail statement from VIA: The data corruption error, which some web sites and people have reported with the 686b Southbridge, is caused by incorrect bios registry setting to the Northbridge. These bios settings were made by motherboard manufacturers, in an attempt to fix a conflict with the Sound Blaster Live Value cards. Information has been provided to all motherboard manufacturers on how to correctly resolve both the data corruption error and the Sound Blaster Live conflict. The patch released by VIA in the 4in1 4.31 drivers replicates the correct bios settings. We provided this patch to make sure as many people got a fix to their Sound Blaster Live problems as soon as possible. Most motherboard manufacturers have now corrected their bios and the patch is not necessarily needed although it will not harm any VIA based system if installed. -- Gareth - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] CREDITS update
My association with VA Linux Systems (and Precision Insight before that) ended last month. At this stage, it is unclear whether I will continue working on the various open source 3D graphics projects (DRI, Mesa etc) or not. My work is being transitioned to the remaining members of the PI group or, unfortunately, abandoned for the time being. I hope to be able to continue working on the kernel, perhaps in slightly different areas though :-) -- Gareth --- linux/CREDITS Thu May 17 23:34:54 2001 +++ linux.gh/CREDITSWed Jun 27 04:06:50 2001 @@ -1256,12 +1256,11 @@ S: USA N: Gareth Hughes -E: [EMAIL PROTECTED] -E: [EMAIL PROTECTED] +E: [EMAIL PROTECTED] D: Pentium III FXSR, SSE support -S: 11/187 West Street -S: Crows Nest NSW 2065 -S: Australia +D: Author/maintainer of most DRM drivers (especially ATI, MGA) +D: Core DRM templates, general DRM and 3D-related hacking +S: No fixed address N: Kenn Humborg E: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] CREDITS update
My association with VA Linux Systems (and Precision Insight before that) ended last month. At this stage, it is unclear whether I will continue working on the various open source 3D graphics projects (DRI, Mesa etc) or not. My work is being transitioned to the remaining members of the PI group or, unfortunately, abandoned for the time being. I hope to be able to continue working on the kernel, perhaps in slightly different areas though :-) -- Gareth --- linux/CREDITS Thu May 17 23:34:54 2001 +++ linux.gh/CREDITSWed Jun 27 04:06:50 2001 @@ -1256,12 +1256,11 @@ S: USA N: Gareth Hughes -E: [EMAIL PROTECTED] -E: [EMAIL PROTECTED] +E: [EMAIL PROTECTED] D: Pentium III FXSR, SSE support -S: 11/187 West Street -S: Crows Nest NSW 2065 -S: Australia +D: Author/maintainer of most DRM drivers (especially ATI, MGA) +D: Core DRM templates, general DRM and 3D-related hacking +S: No fixed address N: Kenn Humborg E: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] r128 DRM module -- hardware bug
The following patch addresses a serious problem with older Rage 128
chipsets, up to and including at least the Rage 128 RF chipset found on
the Xpert 2000. The workaround should be classed as a critical fix, as
without it such cards will lock almost immediately.
-- Gareth
--- linux/drivers/char/drm/r128_drv.h Fri Jan 5 08:03:20 2001
+++ linux.gh/drivers/char/drm/r128_drv.hThu Mar 1 00:03:35 2001
@@ -447,6 +447,11 @@
DRM_INFO( "ADVANCE_RING() tail=0x%06x wr=0x%06x\n", \
write, dev_priv->ring.tail ); \
} \
+ if ( write < 32 ) { \
+ memcpy( dev_priv->ring.end, \
+ dev_priv->ring.start, \
+ write * sizeof(u32) ); \
+ } \
r128_flush_write_combine(); \
dev_priv->ring.tail = write;\
R128_WRITE( R128_PM4_BUFFER_DL_WPTR, write ); \
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] r128 DRM module -- hardware bug
The following patch addresses a serious problem with older Rage 128
chipsets, up to and including at least the Rage 128 RF chipset found on
the Xpert 2000. The workaround should be classed as a critical fix, as
without it such cards will lock almost immediately.
-- Gareth
--- linux/drivers/char/drm/r128_drv.h Fri Jan 5 08:03:20 2001
+++ linux.gh/drivers/char/drm/r128_drv.hThu Mar 1 00:03:35 2001
@@ -447,6 +447,11 @@
DRM_INFO( "ADVANCE_RING() tail=0x%06x wr=0x%06x\n", \
write, dev_priv-ring.tail ); \
} \
+ if ( write 32 ) { \
+ memcpy( dev_priv-ring.end, \
+ dev_priv-ring.start, \
+ write * sizeof(u32) ); \
+ } \
r128_flush_write_combine(); \
dev_priv-ring.tail = write;\
R128_WRITE( R128_PM4_BUFFER_DL_WPTR, write ); \
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5
Michael D. Crawford wrote: > > glxinfo says dri is not available if I remove the library as I did. So I > rebuilt Mesa and reinstalled it. The full output of glxinfo on my machine > follows. Note that it says "direct rendering: Yes" but the version strings > don't match. Does that indicate the problem? > > Server: 1.3 Mesa 3.4 > Client: 1.2 Mesa 3.4 > OpenGL: 1.2 Mesa 3.4 > > display: :0.0 screen:0 > direct rendering: Yes > server glx vendor string: Brian Paul > server glx version string: 1.3 Mesa 3.4 > server glx extensions: > GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, > GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, > GLX_ARB_get_proc_address > client glx vendor string: Brian Paul > client glx version string: 1.2 Mesa 3.4 > client glx extensions: > GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, > GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, > GLX_ARB_get_proc_address > GLX extensions: > GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, > GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, > GLX_ARB_get_proc_address > OpenGL vendor string: Brian Paul > OpenGL renderer string: Mesa X11 > OpenGL version string: 1.2 Mesa 3.4 > OpenGL extensions: > ... You are still using software Mesa. It's not using the DRI libGL.so, simple as that. You should see something like this: demos> glxinfo display: :0.0 screen:0 ... OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa DRI Radeon 20010105 AGP 2x x86/3DNow! ^^ OpenGL version string: 1.2 Mesa 3.4 OpenGL extensions: GL_ARB_multitexture, GL_ARB_tranpose_matrix, GL_EXT_abgr, GL_EXT_blend_func_separate, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_MESA_window_pos, GL_MESA_resize_buffers, GL_NV_texgen_reflection, GL_PGI_misc_hints, GL_SGIS_pixel_texture, GL_SGIS_texture_edge_clamp ... Try running with LIBGL_DEBUG=verbose set. If you don't see the following messages, you know for sure the DRI is not being used. demos> LIBGL_DEBUG=verbose glxinfo libGL: trying /usr/XF86/lib/modules/dri/radeon_dri.so libGL: trying /usr/XF86/lib/modules/dri/radeon_dri.so display: :0.0 screen:0 ... Try reading the DRI User's Guide at http://dri.sourceforge.net, or post to [EMAIL PROTECTED] for help. It just sounds like a config problem, not a bug in the kernel, Mesa or the DRI. -- Gareth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5
Michael D. Crawford wrote: glxinfo says dri is not available if I remove the library as I did. So I rebuilt Mesa and reinstalled it. The full output of glxinfo on my machine follows. Note that it says "direct rendering: Yes" but the version strings don't match. Does that indicate the problem? Server: 1.3 Mesa 3.4 Client: 1.2 Mesa 3.4 OpenGL: 1.2 Mesa 3.4 display: :0.0 screen:0 direct rendering: Yes server glx vendor string: Brian Paul server glx version string: 1.3 Mesa 3.4 server glx extensions: GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, GLX_ARB_get_proc_address client glx vendor string: Brian Paul client glx version string: 1.2 Mesa 3.4 client glx extensions: GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, GLX_ARB_get_proc_address GLX extensions: GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, GLX_ARB_get_proc_address OpenGL vendor string: Brian Paul OpenGL renderer string: Mesa X11 OpenGL version string: 1.2 Mesa 3.4 OpenGL extensions: ... You are still using software Mesa. It's not using the DRI libGL.so, simple as that. You should see something like this: demos glxinfo display: :0.0 screen:0 ... OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa DRI Radeon 20010105 AGP 2x x86/3DNow! ^^ OpenGL version string: 1.2 Mesa 3.4 OpenGL extensions: GL_ARB_multitexture, GL_ARB_tranpose_matrix, GL_EXT_abgr, GL_EXT_blend_func_separate, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_MESA_window_pos, GL_MESA_resize_buffers, GL_NV_texgen_reflection, GL_PGI_misc_hints, GL_SGIS_pixel_texture, GL_SGIS_texture_edge_clamp ... Try running with LIBGL_DEBUG=verbose set. If you don't see the following messages, you know for sure the DRI is not being used. demos LIBGL_DEBUG=verbose glxinfo libGL: trying /usr/XF86/lib/modules/dri/radeon_dri.so libGL: trying /usr/XF86/lib/modules/dri/radeon_dri.so display: :0.0 screen:0 ... Try reading the DRI User's Guide at http://dri.sourceforge.net, or post to [EMAIL PROTECTED] for help. It just sounds like a config problem, not a bug in the kernel, Mesa or the DRI. -- Gareth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Patch: Fix for r128 DRM compilation problem
The 2.4.0 kernel will fail to compile if the r128 DRM module is enabled but AGP support (agpgart) is not. The following patch fixes this error: --- linux/drivers/char/drm/Config.inWed Aug 9 02:27:33 2000 +++ linux.gth/drivers/char/drm/Config.inFri Jan 5 18:11:53 2001 @@ -9,7 +9,7 @@ if [ "$CONFIG_DRM" != "n" ]; then tristate ' 3dfx Banshee/Voodoo3+' CONFIG_DRM_TDFX tristate ' 3dlabs GMX 2000' CONFIG_DRM_GAMMA -tristate ' ATI Rage 128' CONFIG_DRM_R128 +dep_tristate ' ATI Rage 128' CONFIG_DRM_R128 $CONFIG_AGP dep_tristate ' Intel I810' CONFIG_DRM_I810 $CONFIG_AGP dep_tristate ' Matrox g200/g400' CONFIG_DRM_MGA $CONFIG_AGP fi I will apply this to DRI CVS now. Apologies for letting this slip through. -- Gareth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Patch: Fix for r128 DRM compilation problem
The 2.4.0 kernel will fail to compile if the r128 DRM module is enabled but AGP support (agpgart) is not. The following patch fixes this error: --- linux/drivers/char/drm/Config.inWed Aug 9 02:27:33 2000 +++ linux.gth/drivers/char/drm/Config.inFri Jan 5 18:11:53 2001 @@ -9,7 +9,7 @@ if [ "$CONFIG_DRM" != "n" ]; then tristate ' 3dfx Banshee/Voodoo3+' CONFIG_DRM_TDFX tristate ' 3dlabs GMX 2000' CONFIG_DRM_GAMMA -tristate ' ATI Rage 128' CONFIG_DRM_R128 +dep_tristate ' ATI Rage 128' CONFIG_DRM_R128 $CONFIG_AGP dep_tristate ' Intel I810' CONFIG_DRM_I810 $CONFIG_AGP dep_tristate ' Matrox g200/g400' CONFIG_DRM_MGA $CONFIG_AGP fi I will apply this to DRI CVS now. Apologies for letting this slip through. -- Gareth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SETFPXREGS fix
Andrea Arcangeli wrote:
>
> On Sat, Nov 04, 2000 at 10:50:00AM +1100, Gareth Hughes wrote:
> > if ( HAVE_FXSR ) {
> > if ( __copy_from_user( >thread.i387.fxsave, (void *)buf,
> > sizeof(struct user_fxsr_struct) ) )
> > return -EFAULT;
> > /* bit 6 and 31-16 must be zero for security reasons */
> > tsk->thread.i387.fxsave.mxcsr &= 0xffbf;
> > return 0;
> > }
>
> The above doesn't fix the security problem. Put the last byte of the userspace
> structure on an unmapped page and it will return -EFAULT lefting the invalid
> mxcsr value that will corrupt the FPU again.
>
> The right version of the above is just in linux mailbox.
>
> The reason I did it more complex at first is because I wanted to go safe,
> I wasn't sure if somebody could SIGCONT the traced task while we was copying
> the data so introducing a race where it was still possible to exploit
> the bug; but as Linus pointed out to me the loop in do_signal prevents that, so
> we can do only one large copy and then fixup (fixing up also in the -EFAULT
> case of course).
Yes, we can certainly mask out the mxcsr value in both cases. I just
think this makes the code a lot simpler and cleaner as a result - three
partial copies seems over the top.
-- Gareth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: SETFPXREGS fix
Andrea Arcangeli wrote:
>
> --- 2.4.0-test10/arch/i386/kernel/i387.cThu Nov 2 20:58:58 2000
> +++ PIII/arch/i386/kernel/i387.cThu Nov 2 18:44:36 2000
> @@ -440,8 +436,25 @@
> int set_fpxregs( struct task_struct *tsk, struct user_fxsr_struct *buf )
> {
> if ( HAVE_FXSR ) {
> - __copy_from_user( >thread.i387.fxsave, (void *)buf,
> - sizeof(struct user_fxsr_struct) );
> + long mxcsr;
> +
> + if (__copy_from_user(>thread.i387.fxsave, (void *)buf,
> +(long) &((struct user_fxsr_struct *)
> + 0)->mxcsr))
> + return -EFAULT;
> + if (__get_user(mxcsr,
> + &((struct user_fxsr_struct *) buf)->mxcsr))
> + return -EFAULT;
> + /* bit 6 and 31-16 must be zero for security reasons */
> + mxcsr &= 0xffbf;
> + tsk->thread.i387.fxsave.mxcsr = mxcsr;
> + if (__copy_from_user(>thread.i387.fxsave.reserved,
> +&((struct user_fxsr_struct *)
> + buf)->reserved,
> +sizeof(struct user_fxsr_struct)-
> +(long) &((struct user_fxsr_struct *)
> + 0)->reserved))
> + return -EFAULT;
> return 0;
> } else {
> return -EIO;
Why do all three copies? Why not copy it once and mask out the mxcsr
value when it's in tsk->thread.i387.fxsave.mxcsr? Seems to be an overly
complex fix.
if ( HAVE_FXSR ) {
if ( __copy_from_user( >thread.i387.fxsave, (void *)buf,
sizeof(struct user_fxsr_struct) ) )
return -EFAULT;
/* bit 6 and 31-16 must be zero for security reasons */
tsk->thread.i387.fxsave.mxcsr &= 0xffbf;
return 0;
}
-- Gareth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: SETFPXREGS fix
Andrea Arcangeli wrote:
--- 2.4.0-test10/arch/i386/kernel/i387.cThu Nov 2 20:58:58 2000
+++ PIII/arch/i386/kernel/i387.cThu Nov 2 18:44:36 2000
@@ -440,8 +436,25 @@
int set_fpxregs( struct task_struct *tsk, struct user_fxsr_struct *buf )
{
if ( HAVE_FXSR ) {
- __copy_from_user( tsk-thread.i387.fxsave, (void *)buf,
- sizeof(struct user_fxsr_struct) );
+ long mxcsr;
+
+ if (__copy_from_user(tsk-thread.i387.fxsave, (void *)buf,
+(long) ((struct user_fxsr_struct *)
+ 0)-mxcsr))
+ return -EFAULT;
+ if (__get_user(mxcsr,
+ ((struct user_fxsr_struct *) buf)-mxcsr))
+ return -EFAULT;
+ /* bit 6 and 31-16 must be zero for security reasons */
+ mxcsr = 0xffbf;
+ tsk-thread.i387.fxsave.mxcsr = mxcsr;
+ if (__copy_from_user(tsk-thread.i387.fxsave.reserved,
+((struct user_fxsr_struct *)
+ buf)-reserved,
+sizeof(struct user_fxsr_struct)-
+(long) ((struct user_fxsr_struct *)
+ 0)-reserved))
+ return -EFAULT;
return 0;
} else {
return -EIO;
Why do all three copies? Why not copy it once and mask out the mxcsr
value when it's in tsk-thread.i387.fxsave.mxcsr? Seems to be an overly
complex fix.
if ( HAVE_FXSR ) {
if ( __copy_from_user( tsk-thread.i387.fxsave, (void *)buf,
sizeof(struct user_fxsr_struct) ) )
return -EFAULT;
/* bit 6 and 31-16 must be zero for security reasons */
tsk-thread.i387.fxsave.mxcsr = 0xffbf;
return 0;
}
-- Gareth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: SETFPXREGS fix
Andrea Arcangeli wrote:
On Sat, Nov 04, 2000 at 10:50:00AM +1100, Gareth Hughes wrote:
if ( HAVE_FXSR ) {
if ( __copy_from_user( tsk-thread.i387.fxsave, (void *)buf,
sizeof(struct user_fxsr_struct) ) )
return -EFAULT;
/* bit 6 and 31-16 must be zero for security reasons */
tsk-thread.i387.fxsave.mxcsr = 0xffbf;
return 0;
}
The above doesn't fix the security problem. Put the last byte of the userspace
structure on an unmapped page and it will return -EFAULT lefting the invalid
mxcsr value that will corrupt the FPU again.
The right version of the above is just in linux mailbox.
The reason I did it more complex at first is because I wanted to go safe,
I wasn't sure if somebody could SIGCONT the traced task while we was copying
the data so introducing a race where it was still possible to exploit
the bug; but as Linus pointed out to me the loop in do_signal prevents that, so
we can do only one large copy and then fixup (fixing up also in the -EFAULT
case of course).
Yes, we can certainly mask out the mxcsr value in both cases. I just
think this makes the code a lot simpler and cleaner as a result - three
partial copies seems over the top.
-- Gareth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
