-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SuSE 10.1, stock plus YOU updates Pentium 4, 1800 Mhz, 1GiB ram GeForce2 MX/MX 400 (supported according to http://www.nvidia.com/object/IO_18897.html) I wanted to check FlightGear, therefore I had to activate 3D and accel. I downloaded the newest nvidia driver, NVIDIA-Linux-x86-1.0-8776-pkg1.run. I modified /etc/X11/xorg.conf in the same way I had done previously in 9.3 where it worked, and rebooted. I try "glxgears", small window: cer@nimrodel:~> glxgears 3596 frames in 5.0 seconds = 719.072 FPS 4023 frames in 5.0 seconds = 804.191 FPS 4011 frames in 5.0 seconds = 802.194 FPS full screen 697 frames in 5.0 seconds = 139.220 FPS 652 frames in 5.0 seconds = 130.221 FPS The gears turn slowly, and the main cpu soars to 100%. This is not normal. 3D games like ppracer (Planet Penguin racer) And Flight Gear (Flight simulator) do work, but slowly, play may stop and jerk for a second now and then. At least ppracer worked fine a year ago with SuSE 9.3. But the fact that they work prove there is 3D, otherwise they would refuse to work. I have switched from a depth of 24 bits to 16, but I don't see much difference: 7878 frames in 5.0 seconds = 1575.520 FPS <-- small window 7657 frames in 5.0 seconds = 1531.376 FPS 6948 frames in 5.0 seconds = 1389.504 FPS 7800 frames in 5.0 seconds = 1559.852 FPS 2162 frames in 5.0 seconds = 432.110 FPS <--- Full window 1394 frames in 5.0 seconds = 278.762 FPS 5008 frames in 5.0 seconds = 1001.516 FPS cpu at 100% (90% for process glxgears). Ideas? /var/log/Xorg.0.log: (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32 (==) NVIDIA(0): RGB weight 888 (==) NVIDIA(0): Default visual is TrueColor (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0) (**) NVIDIA(0): Option "NvAGP" "3" (**) NVIDIA(0): Option "Rotate" "off" (**) NVIDIA(0): Enabling RENDER acceleration (**) NVIDIA(0): Disabling static screen rotation. (II) NVIDIA(0): NVIDIA GPU GeForce2 MX/MX 400 at PCI:1:0:0 (--) NVIDIA(0): VideoRAM: 65536 kBytes (--) NVIDIA(0): VideoBIOS: 03.11.01.24.87 (II) NVIDIA(0): Detected AGP rate: 4X (--) NVIDIA(0): Interlaced video modes are not supported on this GPU (--) NVIDIA(0): Connected display device(s) on GeForce2 MX/MX 400 at (--) NVIDIA(0): PCI:1:0:0: (--) NVIDIA(0): Mag InnoVision (CRT-0) (--) NVIDIA(0): Brooktree 869 TV Encoder (TV-0) (--) NVIDIA(0): Mag InnoVision (CRT-0): 350.0 MHz maximum pixel clock (--) NVIDIA(0): Brooktree 869 TV Encoder (TV-0): 165.0 MHz maximum pixel (--) NVIDIA(0): clock (--) NVIDIA(0): TV encoder: Brooktree 869 (II) NVIDIA(0): Assigned Display Device: CRT-0 (WW) NVIDIA(0): No valid modes for "1280x1024"; removing. (II) NVIDIA(0): Validated modes: (II) NVIDIA(0): "1024x768" (II) NVIDIA(0): "800x600" (II) NVIDIA(0): "640x480" (II) NVIDIA(0): Virtual screen size determined to be 1024 x 768 (WW) NVIDIA(0): No size information available in CRT-0's EDID; cannot compute (WW) NVIDIA(0): DPI from EDID. (==) NVIDIA(0): DPI set to (75, 75); computed from built-in default (--) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 0 0 0xd0000000 - 0xd7fffff0 (0x7fffff1) MX[B] ... (II) NVIDIA(0): Setting mode "1024x768" (II) Loading extension NV-GLX (II) NVIDIA(0): NVIDIA 3D Acceleration Architecture Initialized (II) NVIDIA(0): Using the NVIDIA 2D acceleration architecture (==) NVIDIA(0): Backing store disabled (==) NVIDIA(0): Silken mouse enabled (**) Option "dpms" (**) NVIDIA(0): DPMS enabled (II) NVIDIA(0): v4l[/dev/video0]: using hw video scaling [YUY2]. (II) Loading extension NV-CONTROL (WW) NVIDIA(0): Option "CalcAlgorithm" is not used (**) RandR enabled nimrodel:~ # glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control client glx vendor string: NVIDIA Corporation client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync, GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_NV_float_buffer, GLX_ARB_fbconfig_float GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_ARB_get_proc_address OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce2 MX/AGP/SSE2 OpenGL version string: 1.5.6 NVIDIA 87.76 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, GL_S3_s3tc, GL_EXT_texture_env_add, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_Cg_shader, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_pixel_buffer_object, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shared_texture_palette, GL_EXT_stencil_wrap, GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod, GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_KTX_buffer_region, GL_NV_blend_square, GL_NV_fence, GL_NV_fog_distance, GL_NV_gpu_program_parameters, GL_NV_light_max_exponent, GL_NV_packed_depth_stencil, GL_NV_pixel_data_range, GL_NV_point_sprite, GL_NV_register_combiners, GL_NV_texgen_reflection, GL_NV_texture_env_combine4, GL_NV_texture_rectangle, GL_NV_vertex_array_range, GL_NV_vertex_array_range2, GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_SGIS_generate_mipmap, GL_SGIS_multitexture, GL_SGIS_texture_lod, GL_SUN_slice_accum visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat - ---------------------------------------------------------------------- 0x21 24 tc 0 32 0 r y . 8 8 8 0 4 24 8 16 16 16 16 0 0 None 0x22 24 dc 0 32 0 r y . 8 8 8 0 4 24 8 16 16 16 16 0 0 None 0x23 24 tc 0 32 0 r y . 8 8 8 8 4 24 8 16 16 16 16 0 0 None 0x24 24 tc 0 32 0 r . . 8 8 8 0 4 24 8 16 16 16 16 0 0 None 0x25 24 tc 0 32 0 r . . 8 8 8 8 4 24 8 16 16 16 16 0 0 None 0x26 24 tc 0 32 0 r y . 8 8 8 0 4 24 0 16 16 16 16 0 0 None 0x27 24 tc 0 32 0 r y . 8 8 8 8 4 24 0 16 16 16 16 0 0 None 0x28 24 tc 0 32 0 r . . 8 8 8 0 4 24 0 16 16 16 16 0 0 None 0x29 24 tc 0 32 0 r . . 8 8 8 8 4 24 0 16 16 16 16 0 0 None 0x2a 24 tc 0 32 0 r y . 8 8 8 0 4 16 0 16 16 16 16 0 0 None 0x2b 24 tc 0 32 0 r y . 8 8 8 8 4 16 0 16 16 16 16 0 0 None 0x2c 24 tc 0 32 0 r . . 8 8 8 0 4 16 0 16 16 16 16 0 0 None 0x2d 24 tc 0 32 0 r . . 8 8 8 8 4 16 0 16 16 16 16 0 0 None 0x2e 24 tc 0 32 0 r y . 8 8 8 0 4 0 0 16 16 16 16 0 0 None 0x2f 24 tc 0 32 0 r y . 8 8 8 8 4 0 0 16 16 16 16 0 0 None 0x30 24 tc 0 32 0 r . . 8 8 8 0 4 0 0 16 16 16 16 0 0 None 0x31 24 tc 0 32 0 r . . 8 8 8 8 4 0 0 16 16 16 16 0 0 None 0x32 24 dc 0 32 0 r y . 8 8 8 8 4 24 8 16 16 16 16 0 0 None 0x33 24 dc 0 32 0 r . . 8 8 8 0 4 24 8 16 16 16 16 0 0 None 0x34 24 dc 0 32 0 r . . 8 8 8 8 4 24 8 16 16 16 16 0 0 None 0x35 24 dc 0 32 0 r y . 8 8 8 0 4 24 0 16 16 16 16 0 0 None 0x36 24 dc 0 32 0 r y . 8 8 8 8 4 24 0 16 16 16 16 0 0 None 0x37 24 dc 0 32 0 r . . 8 8 8 0 4 24 0 16 16 16 16 0 0 None 0x38 24 dc 0 32 0 r . . 8 8 8 8 4 24 0 16 16 16 16 0 0 None 0x39 24 dc 0 32 0 r y . 8 8 8 0 4 16 0 16 16 16 16 0 0 None 0x3a 24 dc 0 32 0 r y . 8 8 8 8 4 16 0 16 16 16 16 0 0 None 0x3b 24 dc 0 32 0 r . . 8 8 8 0 4 16 0 16 16 16 16 0 0 None 0x3c 24 dc 0 32 0 r . . 8 8 8 8 4 16 0 16 16 16 16 0 0 None 0x3d 24 dc 0 32 0 r y . 8 8 8 0 4 0 0 16 16 16 16 0 0 None 0x3e 24 dc 0 32 0 r y . 8 8 8 8 4 0 0 16 16 16 16 0 0 None 0x3f 24 dc 0 32 0 r . . 8 8 8 0 4 0 0 16 16 16 16 0 0 None 0x40 24 dc 0 32 0 r . . 8 8 8 8 4 0 0 16 16 16 16 0 0 None - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFOXo9tTMYHG2NR9URAksYAJ93wv9R/1LI4uGnQGgDj+rm7f4UDACeLSKf 7/m/Ft92y86rD5u+muoMMHA= =t1IV -----END PGP SIGNATURE-----
On Oct 21, 06 03:39:07 +0200, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- I wanted to check FlightGear, therefore I had to activate 3D and accel. I downloaded the newest nvidia driver, NVIDIA-Linux-x86-1.0-8776-pkg1.run. I modified /etc/X11/xorg.conf in the same way I had done previously in 9.3 where it worked, and rebooted.
I try "glxgears", small window:
cer@nimrodel:~> glxgears 3596 frames in 5.0 seconds = 719.072 FPS 4023 frames in 5.0 seconds = 804.191 FPS 4011 frames in 5.0 seconds = 802.194 FPS
You probably want to file a bug report. Seems like something's broken in the driver.
(II) NVIDIA(0): NVIDIA GPU GeForce2 MX/MX 400 at PCI:1:0:0
I think that card is still supposed to be supported (accelerated) by
that driver. Though it is close to being removed from the list.
Matthias
--
Matthias Hopf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-10-25 at 16:31 +0200, Matthias Hopf wrote:
cer@nimrodel:~> glxgears 3596 frames in 5.0 seconds = 719.072 FPS 4023 frames in 5.0 seconds = 804.191 FPS 4011 frames in 5.0 seconds = 802.194 FPS
You probably want to file a bug report. Seems like something's broken in the driver.
I still want to do more testings: I'd like to try that driver in an older distro like 9.3, that I still have installed in another partition. I have the impression it will run faster. It's worth checking. The worst thing is not that it is slow: in my system, it crashes too easily. More people are reporting similar problems in this list and elsewhere.
(II) NVIDIA(0): NVIDIA GPU GeForce2 MX/MX 400 at PCI:1:0:0
I think that card is still supposed to be supported (accelerated) by that driver. Though it is close to being removed from the list.
That's my impression, too. I know it is still supported, but I don't know for how long. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFP4Q4tTMYHG2NR9URAhV7AJ9C8W0QaratyUG6PBTxSmSjpoBHlACfZcnW DJWnnQtLuEp+IPfiFhp60GE= =/HyD -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-10-25 at 17:35 +0200, I wrote:
The Wednesday 2006-10-25 at 16:31 +0200, Matthias Hopf wrote:
You probably want to file a bug report. Seems like something's broken in the driver.
I still want to do more testings: I'd like to try that driver in an older distro like 9.3, that I still have installed in another partition. I have the impression it will run faster. It's worth checking.
The worst thing is not that it is slow: in my system, it crashes too easily.
More people are reporting similar problems in this list and elsewhere.
I have tried in that 9.3 in another partition: as I feared, the same driver (NVIDIA-Linux-x86-1.0-8776-pkg1.run) works very fast and it doesn't crash. I played tux race for an hour and it was fast and smooth. The glxgears turned so fast I couldn't count the turns (in 10.1, I could, easily). Some days back I had also tried older drivers in 10.1 and they were slow. It's not a problem only with the newest driver. Therefore, there is something wrong in the 10.1 distro or the kernel or whatever that makes the NVidia drivers work slow. Or there is an incompatibility amongst both. Not only slow, but unstable, which is worst. I seem to remember not seeing 10.1 on the supported distros list for this driver, but I can't remember where did I see this list, unfortunately. 9.3 was listed. I can report all this in bugzilla with all the data you requested - if the report exists already, please tell me the number. But not tonight, it's 2:40 AM. Unfortunately, I don't have the same data for 10.1 and I don't like to try again, because inevitably it crashes: some times hard, I lost some data. I may have partial reports from my previous tests, though. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFQARDtTMYHG2NR9URAtrbAJ9Cur63ASYF5UrHEuKbEBfZvDeD3gCfX84j Abhe5B/PpoLh8NSILRu7RbI= =H46W -----END PGP SIGNATURE-----
Carlos E. R. wrote:
The Wednesday 2006-10-25 at 17:35 +0200, I wrote:
The Wednesday 2006-10-25 at 16:31 +0200, Matthias Hopf wrote:
You probably want to file a bug report. Seems like something's broken in the driver. I still want to do more testings: I'd like to try that driver in an older distro like 9.3, that I still have installed in another partition. I have the impression it will run faster. It's worth checking.
The worst thing is not that it is slow: in my system, it crashes too easily.
More people are reporting similar problems in this list and elsewhere.
I have tried in that 9.3 in another partition: as I feared, the same driver (NVIDIA-Linux-x86-1.0-8776-pkg1.run) works very fast and it doesn't crash. I played tux race for an hour and it was fast and smooth. The glxgears turned so fast I couldn't count the turns (in 10.1, I could, easily).
Some days back I had also tried older drivers in 10.1 and they were slow. It's not a problem only with the newest driver.
Therefore, there is something wrong in the 10.1 distro or the kernel or whatever that makes the NVidia drivers work slow. Or there is an incompatibility amongst both. Not only slow, but unstable, which is worst.
I seem to remember not seeing 10.1 on the supported distros list for this driver, but I can't remember where did I see this list, unfortunately. 9.3 was listed.
I can report all this in bugzilla with all the data you requested - if the report exists already, please tell me the number. But not tonight, it's 2:40 AM.
Unfortunately, I don't have the same data for 10.1 and I don't like to try again, because inevitably it crashes: some times hard, I lost some data. I may have partial reports from my previous tests, though.
In my opinion the problem you are seeing is an incompatibility issue that surfaced with the latest rpm for the x-server talking to the NVIDIA driver. That is I never had problems with the NVIDIA driver until I installed the new X-SERVER. I am hoping that 10.2 will fix it but that is just a wish. The problem for me is a complete hang of the keyboard - mouse and screen when two separate login sessions via F7 and F8 are switching back and forth for 8-20 hrs. I can remotely login and do whatever I want at that point but in the end a reboot is the only solution as init 3 -> init 5 doesn't work nor does and init 1 and back to init 5. For now I have killed the 3D nvidia driver and gone back to the nv driver and I don't see the above problem.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-10-25 at 18:16 -0700, Robert Lewis wrote:
In my opinion the problem you are seeing is an incompatibility issue that surfaced with the latest rpm for the x-server talking to the NVIDIA driver. That is I never had problems with the NVIDIA driver until I installed the new X-SERVER. I am hoping that 10.2 will fix it but that is just a wish.
Perhaps.
The problem for me is a complete hang of the keyboard - mouse and screen when two separate login sessions via F7 and F8 are switching back and forth for 8-20 hrs. I can remotely login and do whatever I want at that point but in the end a reboot is the only solution as init 3 -> init 5 doesn't work nor does and init 1 and back to init 5.
Similar thing, but crashing much sooner, within an hour. I could crash it instantly trying to resize columns in konqueror in a gnome session. The screen and keyboard freezes, the mouse moves. I could log in by ssh, and I had to kill 'X' to restore some live to it, but in the end I had to reboot. I could reproduce the crash twice. Also, trying to start "zapping" (gnome tv application, version zapping-0.10cvs6-1) crashes solid the whole system instantly. This version of zapping can only work in overlay mode. Version cvs4 can work in capture mode, and crashes when switching to overlay. The crashes were reproducible. The solid crash was so bad that I lost data in home and the rpm database :-( On the other hand, in 9.3 it is zapping which crashes; but I remember I had problems with zapping in 9.3 a year ago and I had to compile another version, maybe 0.7 or perhaps cvs4, I don't remember. All this with the proprietary driver, there are no problems with the open driver.
For now I have killed the 3D nvidia driver and gone back to the nv driver and I don't see the above problem.
Yes, in 10.1 that's what I do, certainly. But I wanted to relax a bit playing a game for a while, but it is impossible. Not with the 3D games I like. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFQITjtTMYHG2NR9URAm7kAJ413xEHVzXLYmWlQ7iWMMdfSE1tywCdEnRo QC+tx4+eEkHREwyEELffbUU= =TCWt -----END PGP SIGNATURE-----
On Oct 25, 06 18:16:00 -0700, Robert Lewis wrote:
In my opinion the problem you are seeing is an incompatibility issue that surfaced with the latest rpm for the x-server talking to the NVIDIA driver. That is I never had problems with the NVIDIA driver until I installed the new X-SERVER. I am hoping that 10.2 will fix it but that is just a wish.
Yes it is. In fact 10.2 will have X.org after modularization for the
first time (some release candidate of 7.2 in this case). So the ABI
changes are actually larger than in 10.1.
Matthias
--
Matthias Hopf
Matthias Hopf wrote:
On Oct 25, 06 18:16:00 -0700, Robert Lewis wrote:
In my opinion the problem you are seeing is an incompatibility issue that surfaced with the latest rpm for the x-server talking to the NVIDIA driver. That is I never had problems with the NVIDIA driver until I installed the new X-SERVER. I am hoping that 10.2 will fix it but that is just a wish.
Yes it is. In fact 10.2 will have X.org after modularization for the first time (some release candidate of 7.2 in this case). So the ABI changes are actually larger than in 10.1.
Matthias
Hi Matthias, I appreciate much your participation and feedback in these exchanges. For clarification, are you saying that a chance exists that the problem I am seeing will go away with 10.2 ? Cheers, Bob
On Oct 26, 06 20:00:34 -0700, Robert Lewis wrote:
I appreciate much your participation and feedback in these exchanges. For clarification, are you saying that a chance exists that the problem I am seeing will go away with 10.2 ?
Chances are always there, given the amount of changes in X from 6.9 to
7.2, but I'm not really confident... Only time will tell.
Matthias
--
Matthias Hopf
On Thu, 2006-10-26 at 02:41 +0200, Carlos E. R. wrote:
The worst thing is not that it is slow: in my system, it crashes too easily.
More people are reporting similar problems in this list and elsewhere.
I have tried in that 9.3 in another partition: as I feared, the same driver (NVIDIA-Linux-x86-1.0-8776-pkg1.run) works very fast and it doesn't crash. I played tux race for an hour and it was fast and smooth. The glxgears turned so fast I couldn't count the turns (in 10.1, I could, easily).
Some days back I had also tried older drivers in 10.1 and they were slow. It's not a problem only with the newest driver.
Therefore, there is something wrong in the 10.1 distro or the kernel or whatever that makes the NVidia drivers work slow. Or there is an incompatibility amongst both. Not only slow, but unstable, which is worst.
Carlos, You may find it worthwhile to look at http://www.nvnews.net/vbulletin/showthread.php?t=46678 which mentions what information nvidia would like to see in a bug report and also gives a link to info about stability problems. HTH, Dave
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-10-26 at 08:31 +0100, Dave Howorth wrote:
Carlos,
You may find it worthwhile to look at
http://www.nvnews.net/vbulletin/showthread.php?t=46678
which mentions what information nvidia would like to see in a bug report and also gives a link to info about stability problems.
I saw that yesterday, after I had done my testing, too late. They say: «please start the X server with `startx -- -logverbose 5` and run `nvidia-bug-report.sh` after the problem has occurred.» That is a big problem, as some of the times the PC hard crashed, and the rest it was quite unresponsive. Mmm... I'll see if I can try, I don't like risking my data again. But as I said, there is no problem with SuSE 9.3. The problem is in 10.1 - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFQIUgtTMYHG2NR9URAhK3AJ0Vnrlfq+OpiD+B5F/iGt3ETOIjVQCfTsNc GYOzwU358XZ1KvRxV3qS4nA= =wgit -----END PGP SIGNATURE-----
Carlos E. R. wrote:
The Thursday 2006-10-26 at 08:31 +0100, Dave Howorth wrote:
Carlos,
You may find it worthwhile to look at
which mentions what information nvidia would like to see in a bug report and also gives a link to info about stability problems.
I saw that yesterday, after I had done my testing, too late. They say: «please start the X server with `startx -- -logverbose 5` and run `nvidia-bug-report.sh` after the problem has occurred.» That is a big problem, as some of the times the PC hard crashed, and the rest it was quite unresponsive. Mmm... I'll see if I can try, I don't like risking my data again.
But as I said, there is no problem with SuSE 9.3. The problem is in 10.1
I didn't have any problems with 10.1 with my nvidia card until later on with one of the updates. I think it was the X-server update that has caused the instability. If you had a spare harddrive you could go back to the 10.1 released kernel and software. Don't do updates and see if your problem goes away. Probably an impractical exercise but it sure would be revealing.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-10-28 at 20:15 -0700, Robert Lewis wrote:
I didn't have any problems with 10.1 with my nvidia card until later on with one of the updates. I think it was the X-server update that has caused the instability. If you had a spare harddrive you could go back to the 10.1 released kernel and software. Don't do updates and see if your problem goes away. Probably an impractical exercise but it sure would be revealing.
Actually, I was planing to install the remastered 10.1 in another partition in order to try the update to 10.2 beta, when I feel like it. But I doubt that the remastered version of 10.1 is sufficiently old for the nvdia test you mean. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFRIvJtTMYHG2NR9URAohlAJ4xqMGCd0pWxSjGXqpQTKCsGL1JyQCggSbE 9Dk5aHEeOxMVaubaoevmzno= =6M3+ -----END PGP SIGNATURE-----
Carlos E. R. wrote:
The Saturday 2006-10-28 at 20:15 -0700, Robert Lewis wrote:
I didn't have any problems with 10.1 with my nvidia card until later on with one of the updates. I think it was the X-server update that has caused the instability. If you had a spare harddrive you could go back to the 10.1 released kernel and software. Don't do updates and see if your problem goes away. Probably an impractical exercise but it sure would be revealing.
Actually, I was planing to install the remastered 10.1 in another partition in order to try the update to 10.2 beta, when I feel like it. But I doubt that the remastered version of 10.1 is sufficiently old for the nvdia test you mean.
I was thinking that only the zen stuff got remastered and not all the RPMS that surfaced since the inception of 10.1. One way to appraise your chances would be to mount the remastered iSO image and look for the rpms on it specifically for xorg-x11-server-6.9.0.50.24 which is the one that I think brought on the issuse. I could easily be wrong as it is a guess. Mount both the original and the latest and compare the xorg-x11-server version rpms.
Robert Lewis wrote:
Carlos E. R. wrote:
The Saturday 2006-10-28 at 20:15 -0700, Robert Lewis wrote:
I didn't have any problems with 10.1 with my nvidia card until later on with one of the updates. I think it was the X-server update that has caused the instability. If you had a spare harddrive you could go back to the 10.1 released kernel and software. Don't do updates and see if your problem goes away. Probably an impractical exercise but it sure would be revealing. Actually, I was planing to install the remastered 10.1 in another partition in order to try the update to 10.2 beta, when I feel like it. But I doubt that the remastered version of 10.1 is sufficiently old for the nvdia test you mean.
I was thinking that only the zen stuff got remastered and not all the RPMS that surfaced since the inception of 10.1. One way to appraise your chances would be to mount the remastered iSO image and look for the rpms on it specifically for xorg-x11-server-6.9.0.50.24 which is the one that I think brought on the issuse. I could easily be wrong as it is a guess. Mount both the original and the latest and compare the xorg-x11-server version rpms.
Have a look at this thread in the archives where what exactly was being remastered and where was discussed ~24 October- [SLE] Request: rebuild of Suse 10.1 ISO after revision of online update Cheers. -- I'm dangerous when I know what I'm doing.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-10-29 at 07:22 -0800, Robert Lewis wrote:
I was thinking that only the zen stuff got remastered and not all the RPMS that surfaced since the inception of 10.1.
No, I know for certain that everything was updated. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFRM1NtTMYHG2NR9URArVxAKCEOsFLHYbor8HXyxC6D0wISLTIcwCfUh+x g5+LXKZgNGTzJkAavH9PI2w= =5m5P -----END PGP SIGNATURE-----
On Oct 29, 06 07:22:21 -0800, Robert Lewis wrote:
Carlos E. R. wrote:
The Saturday 2006-10-28 at 20:15 -0700, Robert Lewis wrote:
I didn't have any problems with 10.1 with my nvidia card until later on with one of the updates. I think it was the X-server update that has caused the instability. If you had a spare harddrive you could go back to the 10.1 released kernel and software. Don't do updates and see if your problem goes away. Probably an impractical exercise but it sure would be revealing.
Actually, I was planing to install the remastered 10.1 in another partition in order to try the update to 10.2 beta, when I feel like it. But I doubt that the remastered version of 10.1 is sufficiently old for the nvdia test you mean.
You can reinstall the old xorg packages. That should work without any
hazzles.
Matthias
--
Matthias Hopf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-10-31 at 15:32 +0100, Matthias Hopf wrote:
But I doubt that the remastered version of 10.1 is sufficiently old for the nvdia test you mean.
You can reinstall the old xorg packages. That should work without any hazzles.
Humpfff! One more test to do! I don't feel like doing that one, though... too much in my "todo" list. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFR2n2tTMYHG2NR9URAiVrAJwKV2AkDtSoyJBceftDH5M2RiFN7wCdG6Wn JBeNJLDJDb56mlXT0uqRilQ= =weFB -----END PGP SIGNATURE-----
On Oct 31, 06 16:21:23 +0100, Carlos E. R. wrote:
You can reinstall the old xorg packages. That should work without any hazzles. Humpfff! One more test to do! I don't feel like doing that one, though... too much in my "todo" list.
;-) Sorry :-P
You know, it actually isn't a list. It's a stack. First in, last out.
I don't count the numbers of items in my 'list' any more.
Matthias
--
Matthias Hopf
You know, it actually isn't a list. It's a stack. First in, last out. I don't count the numbers of items in my 'list' any more.
I was actually thinking of mine as a double linked list with numerous null pointers floating around. John -- Registered Linux User 263680, get counted at http://counter.li.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-10-31 at 11:17 -0600, John Pierce wrote:
You know, it actually isn't a list. It's a stack. First in, last out. I don't count the numbers of items in my 'list' any more.
I was actually thinking of mine as a double linked list with numerous null pointers floating around.
You know, it could be worse: pointers pointing nowhere or out of bounds o who knows where. Mine is not a list, but rather a tree with changing priorities and data by external entities, including mixing leafs plus orphaned branchs. Talking of puter geek talk :-P - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFR/MYtTMYHG2NR9URAmkcAJ4lrS2v1FcTFB2VXds9iylvo+sLvACgl0NU SKo129v+0vsN7ZZ/00mgcfY= =4RL0 -----END PGP SIGNATURE-----
On Nov 01, 06 02:06:30 +0100, Carlos E. R. wrote:
You know, it actually isn't a list. It's a stack. First in, last out. I don't count the numbers of items in my 'list' any more.
I was actually thinking of mine as a double linked list with numerous null pointers floating around.
You know, it could be worse: pointers pointing nowhere or out of bounds o who knows where.
Mine is not a list, but rather a tree with changing priorities and data by external entities, including mixing leafs plus orphaned branchs.
In the meantime I'd rather think it is a cyclic directional graph...
You'll never get out of it.
Sigh
Matthias
--
Matthias Hopf
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Wednesday 2006-10-25 at 17:35 +0200, I wrote:
The Wednesday 2006-10-25 at 16:31 +0200, Matthias Hopf wrote:
You probably want to file a bug report. Seems like something's broken in the driver. I still want to do more testings: I'd like to try that driver in an older distro like 9.3, that I still have installed in another partition. I have the impression it will run faster. It's worth checking.
The worst thing is not that it is slow: in my system, it crashes too easily.
More people are reporting similar problems in this list and elsewhere.
I have tried in that 9.3 in another partition: as I feared, the same driver (NVIDIA-Linux-x86-1.0-8776-pkg1.run) works very fast and it doesn't crash. I played tux race for an hour and it was fast and smooth. The glxgears turned so fast I couldn't count the turns (in 10.1, I could, easily).
For whatever it's worth: one of the first things I noticed when I installed 10.1 is that glxgears turned s-l-o-w-l-y with whatever the driver number was from nVidia (not the stock nv driver). The slowness did not appear with the newest driver--it was there long ago. The bottom line is that it is possibly either kernel related or SUSE related. At that time I had the FX 5500 card installed (it's now on the 'testbed' computer where the gears are turning s-l-o-w-l-y and showing 2845 fps at resolution of 1024x768 (small window)). Cheers. -- I'm dangerous when I know what I'm doing.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-10-26 at 19:00 +1000, Basil Chupin wrote:
Carlos E. R. wrote:
I have tried in that 9.3 in another partition: as I feared, the same driver (NVIDIA-Linux-x86-1.0-8776-pkg1.run) works very fast and it doesn't crash. I played tux race for an hour and it was fast and smooth. The glxgears turned so fast I couldn't count the turns (in 10.1, I could, easily).
For whatever it's worth: one of the first things I noticed when I installed 10.1 is that glxgears turned s-l-o-w-l-y with whatever the driver number was from nVidia (not the stock nv driver). The slowness did not appear with the newest driver--it was there long ago. The bottom line is that it is possibly either kernel related or SUSE related. At that time I had the FX 5500 card installed (it's now on the 'testbed' computer where the gears are turning s-l-o-w-l-y and showing 2845 fps at resolution of 1024x768 (small window)).
Then neither it is related to a recent rpm change. You have hit the nail on an interesting point: it is not that the fps is low, but that the gears turn very slowly. In my previous tests in 10.1 I got:
cer@nimrodel:~> glxgears 3596 frames in 5.0 seconds = 719.072 FPS 4023 frames in 5.0 seconds = 804.191 FPS 4011 frames in 5.0 seconds = 802.194 FPS
full screen
697 frames in 5.0 seconds = 139.220 FPS 652 frames in 5.0 seconds = 130.221 FPS
And that is similar to what I got in my recent tests in 9.3: | cer@linux:~> glxgears | 4081 frames in 5.0 seconds = 816.200 FPS windowed | 4421 frames in 5.0 seconds = 884.200 FPS | 4412 frames in 5.0 seconds = 882.400 FPS | 4342 frames in 5.0 seconds = 868.400 FPS | 2366 frames in 5.0 seconds = 473.200 FPS | 611 frames in 5.0 seconds = 122.200 FPS full screen | 608 frames in 5.0 seconds = 121.600 FPS | 607 frames in 5.0 seconds = 121.400 FPS | 3664 frames in 5.0 seconds = 732.800 FPS windowed | 4407 frames in 5.0 seconds = 881.400 FPS | 4372 frames in 5.0 seconds = 874.400 FPS | 4396 frames in 5.0 seconds = 879.200 FPS except that here the wheels turned very fast, the eye can not follow them. It would be interesting to know if the problem exists on another distros using the same kernel. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD4DBQFFQIdNtTMYHG2NR9URAmgrAJ9PMe3q+IbYgbYB9A6YssuVGYYhsQCWJ+JJ mFBrrutSZFnWBgJbJ39R4g== =QDQo -----END PGP SIGNATURE-----
On Oct 26, 06 12:00:44 +0200, Carlos E. R. wrote:
For whatever it's worth: one of the first things I noticed when I installed 10.1 is that glxgears turned s-l-o-w-l-y with whatever the driver number was from nVidia (not the stock nv driver). The slowness did not appear with the
You have hit the nail on an interesting point: it is not that the fps is low, but that the gears turn very slowly. In my previous tests in 10.1 I got: [...] And that is similar to what I got in my recent tests in 9.3: [...] except that here the wheels turned very fast, the eye can not follow them.
This is *not* a problem at all. You're seeing time-based aliasing
effects. Same happens to wheels of cars in movies, which could seemingly
even turn backwards.
Matthias
--
Matthias Hopf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-10-26 at 18:31 +0200, Matthias Hopf wrote:
And that is similar to what I got in my recent tests in 9.3: [...] except that here the wheels turned very fast, the eye can not follow them.
This is *not* a problem at all. You're seeing time-based aliasing effects. Same happens to wheels of cars in movies, which could seemingly even turn backwards.
No, I know, but that is not the case. When they turn very fast you see the intermediate positions as a blur. When the trun slowly in 10.1 you see the edges very clearly defined and sharp moving slowly - and that combined with jerkiness in tux racing (3D game), implies that there is no mistake in saying it is slow. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFQQx+tTMYHG2NR9URAoZNAJ95fl5pHl7Xb7DBA/J9DmpmVUGmlQCeKNoy s0gbbGbuK37m3jdliay7dXA= =Ehsi -----END PGP SIGNATURE-----
On Thu, 2006-10-26 at 21:28 +0200, Carlos E. R. wrote:
No, I know, but that is not the case. When they turn very fast you see the intermediate positions as a blur. When the trun slowly in 10.1 you see the edges very clearly defined and sharp moving slowly - and that combined with jerkiness in tux racing (3D game), implies that there is no mistake in saying it is slow.
Athlon XP 2200+, Nvidia GForce 420 MX, kernel 2.6.13-15.12-default and nvidia driver 1.0-8776. ----------------------------------------------------------------------- glxgears with full screen 1600x1200x16bpp 85Hz: 2460 frames in 5.0 seconds = 492.000 FPS 2952 frames in 5.0 seconds = 590.400 FPS 2953 frames in 5.0 seconds = 590.600 FPS 2952 frames in 5.0 seconds = 590.400 FPS 2954 frames in 5.0 seconds = 590.800 FPS ----------------------------------------------------------------------- glxgears default window: 6566 frames in 5.0 seconds = 1313.200 FPS 7369 frames in 5.0 seconds = 1473.800 FPS 7369 frames in 5.0 seconds = 1473.800 FPS 7369 frames in 5.0 seconds = 1473.800 FPS 7370 frames in 5.0 seconds = 1474.000 FPS ----------------------------------------------------------------------- OBS!!! ------ When I run glxgears with the driver 1.0-8676 I notice: 1) The default window gives VERY slow GRAPHICAL moving wheels but the fps is the same as with driver 1.0-8774. 2) I can get the GRAPHICAL wheels to move faster if I resize the window just a bit (that ofcourse changes the FPS up/down) 3) The speed of the GRAPHICAL wheels also seems to be disturbed by moving the mouse around. ANYWAY. ------- My FPS and overall prestanda is the same as with the driver 1.0.8774. I can play all the games in gnome perfectly and I have no crashes at all. -- /Peo -- Registered Linux User #432116, get counted at http://counter.li.org -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Oct 26, 06 22:04:08 +0200, Peo Nilsson wrote:
Athlon XP 2200+, Nvidia GForce 420 MX, kernel 2.6.13-15.12-default and nvidia driver 1.0-8776. ----------------------------------------------------------------------- glxgears with full screen 1600x1200x16bpp 85Hz:
2460 frames in 5.0 seconds = 492.000 FPS 2952 frames in 5.0 seconds = 590.400 FPS 2953 frames in 5.0 seconds = 590.600 FPS 2952 frames in 5.0 seconds = 590.400 FPS 2954 frames in 5.0 seconds = 590.800 FPS ----------------------------------------------------------------------- glxgears default window:
6566 frames in 5.0 seconds = 1313.200 FPS 7369 frames in 5.0 seconds = 1473.800 FPS 7369 frames in 5.0 seconds = 1473.800 FPS 7369 frames in 5.0 seconds = 1473.800 FPS 7370 frames in 5.0 seconds = 1474.000 FPS
These look higher, indeed. Please add your findings to the bug report,
if not already done.
Matthias
--
Matthias Hopf
On Oct 26, 06 21:28:53 +0200, Carlos E. R. wrote:
This is *not* a problem at all. You're seeing time-based aliasing effects. Same happens to wheels of cars in movies, which could seemingly even turn backwards.
No, I know, but that is not the case. When they turn very fast you see the intermediate positions as a blur. When the trun slowly in 10.1 you see the edges very clearly defined and sharp moving slowly - and that combined
That very much depends on the backbuffer switching type. That might have changed, so it's no real indicator.
with jerkiness in tux racing (3D game), implies that there is no mistake in saying it is slow.
This definitely is an issue NVIDIA should look into.
Tux racing needs as little graphics as possible in a 3d game, so it
should run smooth on *any* graphics hardware.
Matthias
--
Matthias Hopf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2006-10-27 at 14:44 +0200, Matthias Hopf wrote:
intermediate positions as a blur. When the trun slowly in 10.1 you see the edges very clearly defined and sharp moving slowly - and that combined
That very much depends on the backbuffer switching type. That might have changed, so it's no real indicator.
with jerkiness in tux racing (3D game), implies that there is no mistake in saying it is slow.
This definitely is an issue NVIDIA should look into. Tux racing needs as little graphics as possible in a 3d game, so it should run smooth on *any* graphics hardware.
The problem is that the symptoms I got this early morning are different from what I was getting when I reported initially. Something has changed. I'm much more preoccupied with instability than the arguable slowness, of course. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFQgmrtTMYHG2NR9URAlfDAJ4qNDq4UPejxu/nG6bwPy1DQ5HSRACfbNfY GWXWK4E9ZovDd7S0+0wUyQk= =XtWH -----END PGP SIGNATURE-----
On Oct 26, 06 02:41:28 +0200, Carlos E. R. wrote:
I have tried in that 9.3 in another partition: as I feared, the same driver (NVIDIA-Linux-x86-1.0-8776-pkg1.run) works very fast and it doesn't crash. I played tux race for an hour and it was fast and smooth. The
That's bad, that's a regression. We don't see that here, despite having numerous of NVIDIA cards in our offices. I also haven't heard of anything like that elsewhere, even though 10.1 is out for a long time now.
I can report all this in bugzilla with all the data you requested - if the report exists already, please tell me the number. But not tonight, it's 2:40 AM.
Nobody seems to have created one yet. Yes, make it so, please.
Unfortunately, I don't have the same data for 10.1 and I don't like to try again, because inevitably it crashes: some times hard, I lost some data. I may have partial reports from my previous tests, though.
Maybe someone else from the list can provide the needed information.
Matthias
--
Matthias Hopf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-10-26 at 18:08 +0200, Matthias Hopf wrote:
I have tried in that 9.3 in another partition: as I feared, the same driver (NVIDIA-Linux-x86-1.0-8776-pkg1.run) works very fast and it doesn't crash. I played tux race for an hour and it was fast and smooth. The
That's bad, that's a regression. We don't see that here, despite having numerous of NVIDIA cards in our offices. I also haven't heard of anything like that elsewhere, even though 10.1 is out for a long time now.
Some other people have reported inestability problems here, with 10.1, but none has gone the steps to reinstall 9.3 in another partition in the same machine, do all the YOU updates, and run the nvidia tests ;-)
I can report all this in bugzilla with all the data you requested - if the report exists already, please tell me the number. But not tonight, it's 2:40 AM.
Nobody seems to have created one yet. Yes, make it so, please.
Will do.
Unfortunately, I don't have the same data for 10.1 and I don't like to try again, because inevitably it crashes: some times hard, I lost some data. I may have partial reports from my previous tests, though.
Maybe someone else from the list can provide the needed information.
I'm trying to make another test with 10.1 when I find some time, perhaps in a hour or two. I will make sure no important programs are running, and I will open an ssh from another computer before hand. I want to make a log of the style the nvidia folks like. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFQQ16tTMYHG2NR9URAuXrAJ0Ryyfo4Z7Z09HEnNQjn42DEfFO7wCfbew5 5RIBGfJQ6fstUVgPaXeqIic= =CevY -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-10-26 at 21:33 +0200, I wrote:
I'm trying to make another test with 10.1 when I find some time, perhaps in a hour or two. I will make sure no important programs are running, and I will open an ssh from another computer before hand. I want to make a log of the style the nvidia folks like.
Well... Mixed feelings. I'm writing this up lest I forget, and as a RFC, even if it is very late and I'm tired. I started X from a text console, from runlevel 3, with "startx gnome -- - -logverbose 5", as per nvidia recommendations. I also logged in externally via ssh, left top running, as root, as a safety net. I tried to crash the system, and I couldn't. Not exactly. The other day, resizing konq columns would crash it - not today. Perhaps the last YOU patches have something to do. I think there was something about qt, but it is not listed in my rpm database, which crashed the other day, anyway; the last updates listed are: INSTALLTIME BUILDTIME NAME VERSION RELEASE PACKAGER Fri Oct 20 2006 Fri Oct 20 2006 SimGear 0.3.10 1 checkinstall-1.6.0 Sat Oct 21 2006 Sat Oct 21 2006 rte 0.5.6 1 checkinstall-1.6.0 Sat Oct 21 2006 Sat Oct 21 2006 FlightGear 0.9.10 2 checkinstall-1.6.0 Sun Oct 22 2006 Sat Oct 21 2006 zapping 0.10cvs6 1 checkinstall-1.6.0 Wed Oct 25 2006 Thu Sep 21 2006 xorg-x11-driver-video 6.9.0 46.20 http://bugs.opensuse.org Thu Oct 26 2006 Tue Oct 24 2006 screen 4.0.2 62.5 http://bugs.opensuse.org Or I'm confused and the qt thing was in 9.3 - that's what happens with these late night testing and my memory O:-) I wrote my notes on the info you asked about the other day. glxgears turned very slowly, the mouse affected it, but the FPS were similar to what I got in 9.3. I played 3D games like "planet penguin racer" and "FlightGear". The former was more playable than the other day; there were few "jerks", but there were some. FlightGear did have some jerkiness, even if compiled with "-O3", but that is a very demanding program. Finally, after an hour or so, I decided to start zapping (gnome TV app, version 0.10cvs6), which previously crashed instantly the system. This time, what crashed (surprise) was the "/home" XFS partition, which become suddenly unreadable. Other partitions in the same disk seemed unaffected: Oct 27 01:03:53 nimrodel gconfd (cer-6078): Could not open saved state file '/home/cer/.gconfd/saved_state.tmp' for writing: Input/output error /var/log/kernel Oct 27 01:03:27 nimrodel kernel: xfs_iunlink_remove: xfs_itobp() returned an error 990 on hdd8. Returning error. Oct 27 01:03:27 nimrodel kernel: xfs_inactive: xfs_ifree() returned an error = 990 on hdd8 Oct 27 01:03:27 nimrodel kernel: xfs_force_shutdown(hdd8,0x1) called from line 1762 of file fs/xfs/xfs_vnodeops.c. Return address = 0xf92d9bcb Oct 27 01:03:27 nimrodel kernel: Filesystem "hdd8": I/O Error Detected. Shutting down filesystem: hdd8 Oct 27 01:03:27 nimrodel kernel: Please umount the filesystem, and rectify the problem(s) Oct 27 01:09:36 nimrodel kernel: xfs_force_shutdown(hdd8,0x1) called from line 338 of file fs/xfs/xfs_rw.c. Return address = 0xf92d9bcb Oct 27 01:09:43 nimrodel kernel: audit(1161904183.600:7): audit_pid=0 old=4155 by auid=4294967295 Oct 27 01:09:45 nimrodel kernel: pnp: Device 00:0d disabled. Oct 27 01:09:45 nimrodel kernel: gameport: kgameportd exiting Oct 27 01:09:47 nimrodel kernel: device eth0 left promiscuous mode Oct 27 01:09:50 nimrodel kernel: Kernel logging (proc) stopped. Oct 27 01:09:50 nimrodel kernel: Kernel log daemon terminating. I managed to halt and reboot the system, and no data seemed lost. Very weird. But being "zapping" a cvs version, even though it works well with the "nv" driver, I thought it could be something else. So I tried again. This time I went to "init 5", login via "wdm" into gnome. I tried playing again, no crash. Then I decided to try "kdetv", and... I got another weird crash. This time, any command I entered in an xterm would not return the prompt, not even from the external ssh session. In a remaining root xterm I fired "nvidia-bug-report.sh", and later I found the file correctly saved, fortunately. I could not log off the session. ctrl-alt-backspace closed the session, but I didn't get a prompt back. Tried "ctrl-alt-supr", the system reported halting, but it did not. Finally I had to power off the PC, and after reboot, finally disable "nvidia" driver, and start typing this. I have seen a moment ago there was a kernel oops, two minutes before I run nvidia-bug-report.sh, therefore right on the crash: Oct 27 02:31:54 nimrodel kernel: printing eip: Oct 27 02:31:54 nimrodel kernel: c015d0b8 Oct 27 02:31:54 nimrodel kernel: *pde = 00000000 Oct 27 02:31:54 nimrodel kernel: Oops: 0000 [#1] Oct 27 02:31:54 nimrodel kernel: last sysfs file: /block/hda/hda5/stat Oct 27 02:31:54 nimrodel kernel: Modules linked in: xt_pkttype ipt_LOG ipt_recent af_packet adi joydev snd_pcm_oss snd_mixer_oss snd_seq_midi snd_seq_midi_event snd_seq ir_kbd_i2c button battery ac loop_fish2 ohci_hcd ehci_hcd ip6t_REJECT ip6t_LOG xt_limit xt_tcpudp ipt_REJECT xt_state iptable_mangle iptable_nat ip_nat iptable_filter ip6table_mangle ip_conntrack nfnetlink ip_tables ip6table_filter ip6_tables x_tables ipv6 apparmor aamatch_pcre xfs_quota xfs exportfs raid1 dm_mod twofish cryptoloop loop usbhid bt878 shpchp pci_hotplug tuner tvaudio bttv video_buf firmware_class compat_ioctl32 i2c_algo_bit v4l2_common btcx_risc ir_common tveeprom i2c_i801 videodev intel_agp snd_intel8x0 snd_ac97_codec snd_ac97_bus 8139too snd_pcm mii snd_timer uhci_hcd nvidia snd_page_alloc usbcore ns558 gameport agpgart i2c_core ide_cd cdrom snd_mpu401 snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore parport_pc lp parport reiserfs ext3 jbd fan thermal processor piix ide_disk ide_core Oct 27 02:31:54 nimrodel kernel: CPU: 0 Oct 27 02:31:54 nimrodel kernel: EIP: 0060:[<c015d0b8>] Tainted: P U VLI Oct 27 02:31:54 nimrodel kernel: EFLAGS: 00210286 (2.6.16.21-0.25-default #1) Oct 27 02:31:54 nimrodel kernel: EIP is at __d_lookup+0xa1/0xbf Oct 27 02:31:54 nimrodel kernel: eax: 84ef80ee ebx: c3f70114 ecx: 01843b47 edx: c1815180 Oct 27 02:31:54 nimrodel kernel: esi: d9ea0b64 edi: 84ef80ee ebp: d5efbe74 esp: d5efbe08 Oct 27 02:31:54 nimrodel kernel: ds: 007b es: 007b ss: 0068 Oct 27 02:31:54 nimrodel kernel: Process drkonqi (pid: 18556, threadinfo=d5efa000 task=d897aab0) Oct 27 02:31:54 nimrodel kernel: Stack: <0>d9ea3e14 00000004 01843b47 dfcb7027 01843b47 d9ea0b64 dfcb702c d5efbf48 Oct 27 02:31:54 nimrodel kernel: c0155292 d5efbe80 d5efbe74 d5efbf48 dfff4cc0 01843b47 d9ea0b64 dfcb702c Oct 27 02:31:54 nimrodel kernel: d5efbf48 c0156d4f dfcb702c 00000000 00000403 c01606d8 00000000 d5efbf10 Oct 27 02:31:54 nimrodel kernel: Call Trace: Oct 27 02:31:54 nimrodel kernel: [<c0155292>] do_lookup+0x24/0x135 Oct 27 02:31:54 nimrodel kernel: [<c0156d4f>] __link_path_walk+0x6da/0xaec Oct 27 02:31:54 nimrodel kernel: [<c01606d8>] mntput_no_expire+0x11/0x62 Oct 27 02:31:55 nimrodel kernel: [<c0157210>] link_path_walk+0xaf/0xb9 Oct 27 02:31:55 nimrodel kernel: [<c01571a8>] link_path_walk+0x47/0xb9 Oct 27 02:31:55 nimrodel kernel: [<c01522ec>] sys_stat64+0x1e/0x23 Oct 27 02:31:55 nimrodel kernel: [<c01574c9>] do_path_lookup+0x198/0x1e6 Oct 27 02:31:55 nimrodel kernel: [<c0157c0b>] __user_walk_fd+0x29/0x3a Oct 27 02:31:55 nimrodel kernel: [<c0149df4>] sys_faccessat+0x92/0x123 Oct 27 02:31:55 nimrodel kernel: [<c01522ec>] sys_stat64+0x1e/0x23 Oct 27 02:31:55 nimrodel kernel: [<c0149e94>] sys_access+0xf/0x13 Oct 27 02:31:55 nimrodel kernel: [<c010299b>] sysenter_past_esp+0x54/0x79 Oct 27 02:31:55 nimrodel kernel: Code: 39 42 04 75 20 8b 42 08 8b 4c 24 04 8b 54 24 0c e8 29 74 04 00 85 c0 75 0c f6 43 04 10 75 20 ff 03 89 d8 eb 1c 8b 3f 85 ff 74 14 <8b> 07 0f 18 00 90 8d 5f f4 8b 4c 24 08 39 4b 18 75 e8 eb 9b 31 Oct 27 02:32:00 nimrodel kernel: <1>Unable to handle kernel paging request at virtual address 84ef80ee Oct 27 02:32:00 nimrodel kernel: printing eip: Oct 27 02:32:00 nimrodel kernel: c015d0b8 Oct 27 02:32:00 nimrodel kernel: *pde = 00000000 Oct 27 02:32:00 nimrodel kernel: Oops: 0000 [#2] I have logged there 12 Oops in succession, for anyone wanting them, but as the kernel is tainted (nvidia driver) I don't think the kernel guys will even look at it. But I find very suspicious of something very wrong that two TV apps cause the system to crash this way. As a very wild guess, I'd say that something is writing in kernel space out of bounds. I'll fill a bugzilla report tomorrow, time permitting. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFQWletTMYHG2NR9URAv8OAKCAXSCjwh83SuueXRiyqAeIYyGcgACghDXW 47v0JRuIi9dTMx3Tq/esc7E= =fNfG -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Thursday 2006-10-26 at 21:33 +0200, I wrote:
I'm trying to make another test with 10.1 when I find some time, perhaps in a hour or two. I will make sure no important programs are running, and I will open an ssh from another computer before hand. I want to make a log of the style the nvidia folks like.
Well...
[pruned]
I could not log off the session. ctrl-alt-backspace closed the session, but I didn't get a prompt back. Tried "ctrl-alt-supr", the system reported halting, but it did not. Finally I had to power off the PC, and after reboot, finally disable "nvidia" driver, and start typing this.
Again, for what it's worth. One thing which I find annoying is that for some time now (?weeks) I cannot Shutdown or Restart 10.1 normally--not all the time, but 'most' of the time. I go to Shutdown the system and the screen goes black (after I click on Shutodwn) and then everything freezes with ocassionally a little icon in the topmost lefthand corner (a coloured, small TV screen), or sometimes a couple of lines of text at the top. Only way out is to switch the power off to the computer (because keyboard or mouse are inoperative of course). I seem t recall reading a few weeks ago a post from someone who mentioned that he waits for the background colours to fade to black and white after selecting Shutdown before actually selecting the final Shutdown button. From this I gathered that he, too, was having a similar problem--but I didn't follow-up on this. Cheers. -- I'm dangerous when I know what I'm doing.
Basil Chupin wrote:
I seem t recall reading a few weeks ago a post from someone who mentioned that he waits for the background colours to fade to black and white after selecting Shutdown before actually selecting the final Shutdown button. From this I gathered that he, too, was having a similar problem--but I didn't follow-up on this.
Cheers.
This is true. I have had the black screen a couple of times, and waiting for the color to fade stopped that problem. I missed that post though, just found this out by trial and error. Also I am just using integrated video with no 3D support, so it may have nothing to do with the NVidia driver. -- ED --
Ed McCanless wrote:
Basil Chupin wrote:
I seem t recall reading a few weeks ago a post from someone who mentioned that he waits for the background colours to fade to black and white after selecting Shutdown before actually selecting the final Shutdown button. From this I gathered that he, too, was having a similar problem--but I didn't follow-up on this.
Cheers.
This is true. I have had the black screen a couple of times, and waiting for the color to fade stopped that problem. I missed that post though, just found this out by trial and error. Also I am just using integrated video with no 3D support, so it may have nothing to do with the NVidia driver.
I've been waiting for the colour to fade before selecting the final shutdown stage- but it doesn't always help and the system freezes :-( . And I do use the 877x nVidia driver. So what you say about the problem not necessarily being with the nVidia driver is a strong possibility and nobody would have known until you mentioned your own experience :-) . Every bit helps when solving "mysterious" problems :-) . Cheers. -- I'm dangerous when I know what I'm doing.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2006-10-27 at 15:15 +1000, Basil Chupin wrote:
I've been waiting for the colour to fade before selecting the final shutdown stage- but it doesn't always help and the system freezes :-( . And I do use the 877x nVidia driver. So what you say about the problem not necessarily being with the nVidia driver is a strong possibility and nobody would have known until you mentioned your own experience :-) . Every bit helps when solving "mysterious" problems :-) .
I think that is related to kde. I'm using gnome. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFQeKVtTMYHG2NR9URAnJPAJ9GhwUzEUdOg6Pvc7i9+5p3gaZcQQCdGmhp sm2Hm3YSe052WDsx+SJ7yWk= =bTCL -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Friday 2006-10-27 at 15:15 +1000, Basil Chupin wrote:
I've been waiting for the colour to fade before selecting the final shutdown stage- but it doesn't always help and the system freezes :-( . And I do use the 877x nVidia driver. So what you say about the problem not necessarily being with the nVidia driver is a strong possibility and nobody would have known until you mentioned your own experience :-) . Every bit helps when solving "mysterious" problems :-) .
I think that is related to kde. I'm using gnome.
But both use the same kernel. Cheers. -- I'm dangerous when I know what I'm doing.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2006-10-27 at 22:15 +1000, Basil Chupin wrote:
I think that is related to kde. I'm using gnome.
But both use the same kernel.
So what? I don't have any problem halting when using the open nv driver. Unless you configure your boot/halt to text verbose mode, you will not see anything. And you seeing strange graphics looks to me more an X thing than kernel. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFQgiytTMYHG2NR9URAv/PAJ9j7mBd/A2gw8KUQAwUA55empUpzQCfZA4R J1Vlt8/uLLj1cSTnFn1t4UA= =kG/v -----END PGP SIGNATURE-----
I have 'slow' 3D (100 fps) for one user, 'fast' (2000 fps) for another. This is not a big problem for me, but I have at least the hope of diagnosing the problem. I tried recording /var/log/Xorg.0.log for both users. The diff was 14c14 < (==) Log file: "/var/log/Xorg.0.log", Time: Sun Oct 29 11:32:55 2006 ---
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Oct 29 19:52:08 2006 476,482d475 < SetClientVersion: 0 9 < SetGrabKeysState - disabled < SetGrabKeysState - enabled < (II) 3rd Button detected: disabling emulate3Button < SetClientVersion: 0 9 < SetGrabKeysState - disabled < SetGrabKeysState - enabled
That is, some extar entries for 'slow' user. I repeated this starting X for both with startx -- -logverbose 5 and found no differences except in the timestamp on the log, but still one 'slow' and one 'fast' user. Any suggestions for where else I could look for differences? I've checked everything I've seen posted on this thread. -- JDL
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-10-29 at 20:08 -0000, John D Lamb wrote:
Any suggestions for where else I could look for differences? I've checked everything I've seen posted on this thread.
Perhaps the slow user does not belong to group "video"? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFRQ7htTMYHG2NR9URAqhIAKCTgAjksXKMLzWcW3JN+1r0vzVqkQCcCWWR /KZLwHdbu2UjFiLQAyGnlqE= =PH7e -----END PGP SIGNATURE-----
On Sun, 2006-10-29 at 21:28 +0100, Carlos E. R. wrote:
Perhaps the slow user does not belong to group "video"?
No, 'slow user' does belong to video group. I'm looking for some other way of finding what's different between the two users. -- JDL
John D Lamb wrote:
On Sun, 2006-10-29 at 21:28 +0100, Carlos E. R. wrote:
Perhaps the slow user does not belong to group "video"?
No, 'slow user' does belong to video group. I'm looking for some other way of finding what's different between the two users.
It's all in the genes, you know. :-) Cheers. -- I'm dangerous when I know what I'm doing.
On Oct 30, 06 18:16:25 +1100, Basil Chupin wrote:
John D Lamb wrote:
On Sun, 2006-10-29 at 21:28 +0100, Carlos E. R. wrote:
Perhaps the slow user does not belong to group "video"?
No, 'slow user' does belong to video group. I'm looking for some other way of finding what's different between the two users.
It's all in the genes, you know.
Rather 'if (getuid() == xxxx)...'
Seriously, add your findings to the bug report. Currently I don't know
what else to check except for environment variables.
Matthias
--
Matthias Hopf
On Tue, 2006-10-31 at 15:25 +0100, Matthias Hopf wrote:
On Oct 30, 06 18:16:25 +1100, Basil Chupin wrote:
John D Lamb wrote:
On Sun, 2006-10-29 at 21:28 +0100, Carlos E. R. wrote:
Perhaps the slow user does not belong to group "video"?
No, 'slow user' does belong to video group. I'm looking for some other way of finding what's different between the two users.
It's all in the genes, you know.
Rather 'if (getuid() == xxxx)...'
Seriously, add your findings to the bug report. Currently I don't know what else to check except for environment variables.
I've found what was slowing nVidia for me: a file called .nvidia-settings-rc in my home directory. I deleted it, restarted X and glxgears now runs 20 times as fast as it did before. I don't know if this will help anyone else. I believe the file is created by an nVidia program rather than by a SuSE one. -- JDL -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Nov 20, 06 18:51:23 +0000, John D Lamb wrote:
I've found what was slowing nVidia for me: a file called .nvidia-settings-rc in my home directory. I deleted it, restarted X and glxgears now runs 20 times as fast as it did before.
I don't know if this will help anyone else. I believe the file is created by an nVidia program rather than by a SuSE one.
Wow. Thanks!
I'm pretty sure this is not created by a SUSE program...
Matthias
--
Matthias Hopf
* Matthias Hopf
On Nov 20, 06 18:51:23 +0000, John D Lamb wrote:
I've found what was slowing nVidia for me: a file called .nvidia-settings-rc in my home directory. I deleted it, restarted X and glxgears now runs 20 times as fast as it did before.
I don't know if this will help anyone else. I believe the file is created by an nVidia program rather than by a SuSE one.
Wow. Thanks! I'm pretty sure this is not created by a SUSE program...
no, /usr/bin/nvidia-settings from x11-video-nvidia-1.0.8762-1.rpm -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, 2006-11-22 at 19:30 +0100, Matthias Hopf wrote:
On Nov 20, 06 18:51:23 +0000, John D Lamb wrote:
I've found what was slowing nVidia for me: a file called .nvidia-settings-rc in my home directory. I deleted it, restarted X and glxgears now runs 20 times as fast as it did before.
I don't know if this will help anyone else. I believe the file is created by an nVidia program rather than by a SuSE one.
Wow. Thanks! I'm pretty sure this is not created by a SUSE program...
Matthias
I have that file in my own home directory on a multi-user system. Any idea as to the what and how of it? Mike -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-11-22 at 14:02 -0500, Mike McMullin wrote:
I have that file in my own home directory on a multi-user system. Any idea as to the what and how of it?
The settings created by "nvidia-settings". - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFZLn/tTMYHG2NR9URArxgAJwKhX5iGPocLQTURtWs8L2iedyf/QCbBg3y TDlJB/zQPv66BWHfY792FFI= =at+j -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Oct 27, 06 12:39:19 +1000, Basil Chupin wrote:
One thing which I find annoying is that for some time now (?weeks) I cannot Shutdown or Restart 10.1 normally--not all the time, but 'most' of the time. I go to Shutdown the system and the screen goes black (after I click on Shutodwn) and then everything freezes with ocassionally a little icon in the topmost lefthand corner (a coloured, small TV screen), or sometimes a couple of lines of text at the top. Only way out is to switch the power off to the computer (because keyboard or mouse are inoperative of course).
That is probably a different issue. Please file a bug report.
Matthias
--
Matthias Hopf
Matthias Hopf wrote:
On Oct 27, 06 12:39:19 +1000, Basil Chupin wrote:
One thing which I find annoying is that for some time now (?weeks) I cannot Shutdown or Restart 10.1 normally--not all the time, but 'most' of the time. I go to Shutdown the system and the screen goes black (after I click on Shutodwn) and then everything freezes with ocassionally a little icon in the topmost lefthand corner (a coloured, small TV screen), or sometimes a couple of lines of text at the top. Only way out is to switch the power off to the computer (because keyboard or mouse are inoperative of course).
That is probably a different issue. Please file a bug report.
Matthias
Try right clicking on the background within the desktop and shutting down from there instead of the K-Menu and see if you observe any difference.
On Oct 27, 06 06:18:36 -0700, Robert Lewis wrote:
One thing which I find annoying is that for some time now (?weeks) I cannot Shutdown or Restart 10.1 normally--not all the time, but 'most' of the time. I go to Shutdown the system and the screen goes black (after I click on Shutodwn) and then everything freezes with ocassionally a little icon in the topmost lefthand corner (a coloured, small TV screen), or sometimes a couple of lines of text at the top. Only way out is to switch the power off to the computer (because keyboard or mouse are inoperative of course).
That is probably a different issue. Please file a bug report.
Matthias
Try right clicking on the background within the desktop and shutting down from there instead of the K-Menu and see if you observe any difference.
I'm not using KDE (neither Gnome), so I can't reproduce.
That's what bug reports are good for, they get to the right people.
Matthias
--
Matthias Hopf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2006-10-27 at 04:05 +0200, I wrote:
I'll fill a bugzilla report tomorrow, time permitting.
Done: 215937 (crashes; I have no hard proof of slow rendering). I still have to attach later the error logs. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFQmButTMYHG2NR9URAu+lAKCFK/alN3oM94pRQP+c5jWh81XeCACggzp1 qVqgiNjTqNhGNmJ8GIkK0YY= =q9sm -----END PGP SIGNATURE-----
On Oct 25, 06 17:35:18 +0200, Carlos E. R. wrote:
You probably want to file a bug report. Seems like something's broken in the driver.
I still want to do more testings: I'd like to try that driver in an older distro like 9.3, that I still have installed in another partition. I have the impression it will run faster. It's worth checking.
Very well. If you've got the time and will to do more testing, I'll be the last to hold you off ;-)
The worst thing is not that it is slow: in my system, it crashes too easily.
That is bad. It *could* be faulty hardware (we had that too often),
however, as several people are reporting that it could be driver
related.
Thanks
Matthias
--
Matthias Hopf
participants (11)
-
Basil Chupin -
Carlos E. R. -
Dave Howorth -
Ed McCanless -
John D Lamb -
John Pierce -
Matthias Hopf -
Mike McMullin -
Patrick Shanahan -
Peo Nilsson -
Robert Lewis