Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 03-22-05, 07:20 AM   #181
olio06
Registered User
 
Join Date: Mar 2005
Posts: 1
Default Re: 1.0-7167 for Linux x86 released

Since 6119 driver, i can't use my laptop with ge4 420go 32Mo , rev a3.
I'm forced to use 2.6.10 kernel with NVIDIA-Linux-X86-1.0.6111-jp3 modified driver.
Please FIX that!!!
olio06 is offline   Reply With Quote
Old 03-22-05, 07:50 AM   #182
michael.bauer
Registered User
 
Join Date: Sep 2004
Posts: 62
Default Re: 1.0-7167 for Linux x86 released

Hello,

I tried to install the 7167 linux driver with the Mandrake 10.1 standard
kernel (2.6.8.1-12mdk) and failed. I cannot switch to older drivers since 6200 Go is only supported in 7167. (The same hardware was running with Mandrake 10.0 with minor problems (Xid errors)).

See attached nvidia-bug-report-log for details.

The log tells something about "unable to load kernel module nvidia.ko" and
about "unknown symbol in module" called agp_enable etc.

(The agp thing seems to be the problem (?) since my machine uses pci-express)

// sony vaio FS115M w. 6200 Go TC
Attached Files
File Type: txt nvidia-bug-report-mandrake-10.1.log.txt (53.2 KB, 136 views)
michael.bauer is offline   Reply With Quote
Old 03-22-05, 12:40 PM   #183
LubosD
Registered User
 
Join Date: Jan 2005
Location: Czech Republic
Posts: 451
Send a message via ICQ to LubosD
Default Re: 1.0-7167 for Linux x86 released

@AlxMAX:
1) I know how to flash
2a) I ask for a BIOS because there's no for my card (except the one I've submitted there)
2b) All nVidia's generic BIOSes are older than mine
:-(
LubosD is offline   Reply With Quote
Old 03-22-05, 01:17 PM   #184
sphincter
Registered User
 
sphincter's Avatar
 
Join Date: Mar 2003
Posts: 154
Default Re: 1.0-7167 for Linux x86 released

I've noticed a few people say their laptops are running hotter with this driver. I've noticed that my desktop is running about 8-10 degress hotter as well. I've also noticed an increase in crashes while playing America's Army where the game just suddenly exits to the desktop. Where this used to happen at most 1-2 times a month, it now happens sometimes several times a day.
__________________
It never gets easier, you just go faster. - Greg Lemond
sphincter is offline   Reply With Quote
Old 03-22-05, 04:41 PM   #185
daevid
Registered User
 
Join Date: Nov 2003
Posts: 5
Default Re: 1.0-7167 for Linux x86 released

I couldn't get KDE 3.3 or 3.4 to work with the new 1.0.7167 drivers and kernel 2.6.10-gentoo-r6 on Gentoo. Dell i8200 notebook.

Gnome, Xorg, XFCE and TWM all worked flawlessly. no lockups i experienced. KDE just wouldn't get past the "setting up interprocess communication" screen adn I couldn't even exit out with CTRL+BKSP. ssh in to kill the processes left teh display unuseable forcing me to type "reboot" via ssh.

I switched back to the 6629 drivers and everything works again. *sigh*
daevid is offline   Reply With Quote
Old 03-22-05, 05:47 PM   #186
anoftc
Registered User
 
Join Date: Mar 2005
Posts: 6
Default Re: 1.0-7167 for Linux x86 released

Hoi

Ok, this is so windows-like behaviour.

I had problems with nvidia drivers: It loaded perfectly, but all my OpenGL apps were slow. And then a week ago or so, opengl became fine - Dont expect me to explain, It just became good. No idea why.

But here comes the interesting part:
I played q3 today. It was fine, no flickering, good gameplay. And then I quit q3, and just to test I ran glxgears. And I noticed that its speed suddenly dropped from 1500 (usual performance of my box, gef2 powwa , to 20. I started q3, and gameplay is flickery, unplayable.

So what can be the causes of such performace drop????

Any help is appreciated, thanx
Zs
anoftc is offline   Reply With Quote
Old 03-22-05, 08:05 PM   #187
bradley
Registered User
 
Join Date: Mar 2005
Posts: 2
Default Re: 1.0-7167 for Linux x86 released

The last working combination for me is kernel 2.6.8.1 and 6111 drivers.

Running debian unstable, FX5200 PCI nd FX5700 AGP cards with XFree86 multi-head.

With newer kernels and newer Nvidia drivers the main display hangs at the white screen with Nvidia logo. I've tried 2.6.9, 2.6.10, and 2.6.11.2 as well as 6629 drivers all with no luck.

I just tested kernel 2.6.11.5 and 7167 drivers - same behaviour. This time I left it sitting at the Nvidia logo screen a while and eventually (several minutes later) I got GDM login screen - logged in and it partly set up Gnome desktop and then hung. 2nd screen is still blank.

$ cat /proc/drivers/nvidia/cards/*

Model: GeForce FX 5200
IRQ: 11
Video BIOS: 04.34.20.42.26
Card Type: PCI
Model: GeForce FX 5700
IRQ: 5
Video BIOS: 04.36.20.21.00
Card Type: AGP


$ cat /proc/driver/nvidia/agp/status

Status: Enabled
Driver: NVIDIA
AGP Rate: 8x
Fast Writes: Disabled
SBA: Enabled


dmesg shows:

NVRM: loading NVIDIA Linux x86 NVIDIA Kernel Module 1.0-7167 Fri Feb 25 09:08:22 PST 2005
...
...
NVRM: Xid: 7, Ch 00000000 M 00001df0 D 87ee64fc intr 00010000
NVRM: Xid: 7, Ch 00000001 M 00001df0 D 87ee64fc intr 00010000


XFree86.0.log shows:

XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-12.0.1 20050223080930 joshk@triplehelix.org)
...
...
(II) LoadModule: "nvidia"
(II) Loading /usr/X11R6/lib/modules/drivers/nvidia_drv.o
(II) Module nvidia: vendor="NVIDIA Corporation"
compiled for 4.0.2, module version = 1.0.7167
Module class: XFree86 Video Driver
...
...
(--) Chipset NVIDIA GPU found
(--) Chipset NVIDIA GPU found
...
...
(II) Setting vga for screen 0.
(II) Setting vga for screen 1.
(**) 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 "IgnoreDisplayDevices" "DFP, TV"
(--) NVIDIA(0): Linear framebuffer at 0xC0000000
(--) NVIDIA(0): MMIO registers at 0xE1000000
(II) NVIDIA(0): NVIDIA GPU detected as: GeForce FX 5700
(--) NVIDIA(0): VideoBIOS: 04.36.20.21.00
(--) NVIDIA(0): Interlaced video modes are supported on this GPU
(II) NVIDIA(0): Detected AGP rate: 8X
(--) NVIDIA(0): VideoRAM: 131072 kBytes
(II) NVIDIA(0): Connected display device(s): CRT-1
(--) NVIDIA(0): Display device CRT-1: maximum pixel clock at 8 bpp: 400 MHz
(--) NVIDIA(0): Display device CRT-1: maximum pixel clock at 16 bpp: 400 MHz
(--) NVIDIA(0): Display device CRT-1: maximum pixel clock at 32 bpp: 400 MHz
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Reloading /usr/X11R6/lib/modules/libddc.a
(II) NVIDIA(0): Philips Monitor: Using hsync range of 30.00-95.00 kHz
(II) NVIDIA(0): Philips Monitor: Using vrefresh range of 50.00-160.00 Hz
(II) NVIDIA(0): Clock range: 12.00 to 400.00 MHz
(II) NVIDIA(0): Not using default mode "1600x1200" (hsync out of range)
(II) NVIDIA(0): Not using default mode "800x600" (hsync out of range)
(II) NVIDIA(0): Not using default mode "1792x1344" (hsync out of range)
(II) NVIDIA(0): Not using default mode "896x672" (hsync out of range)
(II) NVIDIA(0): Not using default mode "1856x1392" (hsync out of range)
(II) NVIDIA(0): Not using default mode "928x696" (hsync out of range)
(II) NVIDIA(0): Not using default mode "1920x1440" (hsync out of range)
(II) NVIDIA(0): Not using default mode "960x720" (hsync out of range)
(II) NVIDIA(0): Not using default mode "1920x1440" (hsync out of range)
(II) NVIDIA(0): Not using default mode "960x720" (hsync out of range)
(II) NVIDIA(0): Not using default mode "2048x1536" (hsync out of range)
(II) NVIDIA(0): Not using default mode "1024x768" (hsync out of range)
(II) NVIDIA(0): Not using default mode "2048x1536" (hsync out of range)
(II) NVIDIA(0): Not using default mode "1024x768" (hsync out of range)
(II) NVIDIA(0): Not using default mode "2048x1536" (width too large for virtual size)
(II) NVIDIA(0): Not using default mode "1920x1440" (width too large for virtual
size)
(II) NVIDIA(0): Not using default mode "1856x1392" (width too large for virtual
size)
(II) NVIDIA(0): Not using default mode "1792x1344" (width too large for virtual
size)
(WW) NVIDIA(0): Not using mode "1024x768" (height 1536 is larger than
(WW) NVIDIA(0): EDID-specified maximum 1200)
(WW) NVIDIA(0): Not using mode "960x720" (height 1440 is larger than
(WW) NVIDIA(0): EDID-specified maximum 1200)
(WW) NVIDIA(0): Not using mode "928x696" (height 1392 is larger than
(WW) NVIDIA(0): EDID-specified maximum 1200)
(WW) NVIDIA(0): Not using mode "896x672" (height 1344 is larger than
(WW) NVIDIA(0): EDID-specified maximum 1200)
(WW) NVIDIA(0): Not using mode "1152x768":
(WW) NVIDIA(0): horizontal sync start (1178) not a multiple of 8
(WW) NVIDIA(0): Not using mode "576x384":
(WW) NVIDIA(0): horizontal sync start (589) not a multiple of 8
(WW) NVIDIA(0): Not using mode "360x200":
(WW) NVIDIA(0): horizontal sync start (378) not a multiple of 8
(**) NVIDIA(0): Validated modes for display device CRT-1:
(**) NVIDIA(0): Default mode "1600x1200": 202.5 MHz, 93.8 kHz, 75.0 Hz
(**) NVIDIA(0): Default mode "1280x1024": 157.5 MHz, 91.1 kHz, 85.0 Hz
...
...
(**) NVIDIA(0): Default mode "320x175": 15.8 MHz, 37.9 kHz, 85.3 Hz (D)
(II) NVIDIA(0): Virtual screen size determined to be 1600 x 1200
(--) NVIDIA(0): Display dimensions: (300, 230) mm
(--) NVIDIA(0): DPI set to (135, 132)
...
...
(**) NVIDIA(1): Depth 24, (--) framebuffer bpp 32
(==) NVIDIA(1): RGB weight 888
(==) NVIDIA(1): Default visual is TrueColor
(==) NVIDIA(1): Using gamma correction (1.0, 1.0, 1.0)
(**) NVIDIA(1): Option "IgnoreDisplayDevices" "DFP, TV"
(--) NVIDIA(1): Linear framebuffer at 0xD0000000
(--) NVIDIA(1): MMIO registers at 0xE4000000
(II) NVIDIA(1): NVIDIA GPU detected as: GeForce FX 5200
(--) NVIDIA(1): VideoBIOS: 04.34.20.42.26
(--) NVIDIA(1): Interlaced video modes are supported on this GPU
(--) NVIDIA(1): VideoRAM: 131072 kBytes
(II) NVIDIA(1): Connected display device(s): CRT-0
(--) NVIDIA(1): Display device CRT-0: maximum pixel clock at 8 bpp: 400 MHz
(--) NVIDIA(1): Display device CRT-0: maximum pixel clock at 16 bpp: 400 MHz
(--) NVIDIA(1): Display device CRT-0: maximum pixel clock at 32 bpp: 400 MHz
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Reloading /usr/X11R6/lib/modules/libddc.a
(WW) NVIDIA(1): Failure reading EDID parameters for display device CRT-0
(II) NVIDIA(1): Dell Monitor: Using hsync range of 30.00-92.00 kHz
(II) NVIDIA(1): Dell Monitor: Using vrefresh range of 50.00-150.00 Hz
(II) NVIDIA(1): Clock range: 12.00 to 400.00 MHz
(II) NVIDIA(1): Not using default mode "1600x1200" (hsync out of range)
...
(WW) NVIDIA(1): Not using mode "360x200":
(WW) NVIDIA(1): horizontal sync start (378) not a multiple of 8
(**) NVIDIA(1): Validated modes for display device CRT-0:
(**) NVIDIA(1): Default mode "1600x1200": 189.0 MHz, 87.5 kHz, 70.0 Hz
...
(**) NVIDIA(1): Default mode "320x175": 15.8 MHz, 37.9 kHz, 85.3 Hz (D)
(II) NVIDIA(1): Virtual screen size determined to be 1600 x 1200
(==) NVIDIA(1): DPI set to (75, 75)
...
(II) NVIDIA(0): Setting mode "1600x1200"
(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) Loading extension NV-CONTROL
(==) RandR enabled
(II) NVIDIA(1): Setting mode "1600x1200"
(WW) NVIDIA(1): WAIT (2, 1, 0x8000, 0x00000000, 0x000006f8, 1)
(WW) NVIDIA(1): WAIT (1, 1, 0x8000, 0x00000000, 0x000006f8, 1)
(II) NVIDIA(1): NVIDIA 3D Acceleration Architecture Initialized
(II) NVIDIA(1): Using the NVIDIA 2D acceleration architecture
(==) NVIDIA(1): Backing store disabled
(==) NVIDIA(1): Silken mouse enabled
(**) Option "dpms"
(**) NVIDIA(1): DPMS enabled
(WW) NVIDIA(1): WAIT (2, 6, 0x8000, 0x00000000, 0x00000da8, 1)
(WW) NVIDIA(1): WAIT (1, 6, 0x8000, 0x00000000, 0x00000da8, 1)
(==) RandR enabled
(II) Entity 0 shares no resources
(II) Entity 1 shares no resources
...
...
GetModeLine - scrn: 0 clock: 202500
GetModeLine - hdsp: 1600 hbeg: 1664 hend: 1856 httl: 2160
vdsp: 1200 vbeg: 1201 vend: 1204 vttl: 1250 flags: 5
GetModeLine - scrn: 1 clock: 189000
GetModeLine - hdsp: 1600 hbeg: 1664 hend: 1856 httl: 2160
vdsp: 1200 vbeg: 1201 vend: 1204 vttl: 1250 flags: 5
(WW) NVIDIA(1): WAIT (2, 6, 0x8000, 0x00000000, 0x00000e5c, 1)
(WW) NVIDIA(1): WAIT (1, 6, 0x8000, 0x00000000, 0x00000e5c, 1)
(WW) NVIDIA(1): WAIT (2, 6, 0x8000, 0x00000000, 0x00000ea8, 1)
(WW) NVIDIA(1): WAIT (1, 6, 0x8000, 0x00000000, 0x00000ea8, 1)
(WW) NVIDIA(1): WAIT (2, 6, 0x8000, 0x00000000, 0x00000f08, 1)
(WW) NVIDIA(1): WAIT (1, 6, 0x8000, 0x00000000, 0x00000f08, 1)
(WW) NVIDIA(1): WAIT (2, 6, 0x8000, 0x00000000, 0x00000f40, 1)
(WW) NVIDIA(1): WAIT (1, 6, 0x8000, 0x00000000, 0x00000f40, 1)


File /etc/X11/XF86Config-4 contains:

Section "Device"
Identifier "NVIDIA Corporation NV34 [GeForce FX 5200]"
# Driver "nv"
Driver "nvidia"
# Option "NvAGP" "0"
Option "IgnoreDisplayDevices" "DFP, TV"
BusID "PCI:01:08:00"
EndSection

Section "Device"
Identifier "NVIDIA Corporation NV34 [GeForce FX 5700]"
# Driver "nv"
Driver "nvidia"
# Option "NvAGP" "1"
Option "IgnoreDisplayDevices" "DFP, TV"
BusID "PCI:03:00:00"
EndSection
bradley is offline   Reply With Quote
Old 03-23-05, 06:26 AM   #188
MadOverlord
Registered User
 
Join Date: Aug 2003
Location: Germany
Posts: 1
Default Re: 1.0-7167 for Linux x86 released

@ bradley:

Same problem here. I am using a combination of FX5700/FX5200 AGP/PCI with four monitors connected. Everything worked fine until 6111 driver release and kernel 2.6.8.x (SuSE 9.2).
To get out of the SuSE-swamp I decided to give ArchLinux a try (and I am really impressed) but using kernel 2.6.10.x ... 2.6.11.4 in combination with 7167 driver release I can no longer get my X-configuration to work. I don't know if it's a driver or a kernel or even a problem arising from the newer Xorg-version.
I can get two displays on the AGP-card working nicely, but if I try to use both cards, X hangs badly, with exact same WAITS in the log. I recently managed to put one screen on AGP plus one screen on PCI by adding the line
Option "UseInt10Module" "on"
into the device-section of the PCI-device, but that way I get really strange glx-errors. Other 3-screen-combinations (like two AGP-screens + one PCI or one AGP-screen + two PCI) and the 4-screen combination do not work with that option set, strange.

We are using this setup for a high-speed medical-imaging application and unfortunately we are stuck with the older kernel and driver, so any help on this problem is welcome. Maybe someone out there using the old 6111-release with the ArchLinux 2.6.11.4 system can help us out?
MadOverlord is offline   Reply With Quote

Old 03-23-05, 12:38 PM   #189
zsxdc
Registered User
 
Join Date: Mar 2005
Posts: 1
Default Re: 1.0-7167 for Linux x86 released

Does nVidia plan to fix the widescreen notebook issue any time soon? Being that it's the second consecutive driver that's had broken support for it, I'm hoping my kernel/driver aren't frozen at 2.6.10/6111-jp3.
zsxdc is offline   Reply With Quote
Old 03-23-05, 05:26 PM   #190
glenj
Registered User
 
Join Date: Oct 2004
Posts: 3
Default Re: 1.0-7167 for Linux x86 released

7167 working well with 2.6.11. Noticed about 20% improvement (~1000 fps to ~1200 fps) with glxgears also. Thanks.

AMD K7 2500
Via KT600 motherboard
FX 5200 128M AGP
Slackware 10.0
Dropline Gnome 2.8.3
kernel 2.6.11
Xorg 6.8.2
via_agp module
glenj is offline   Reply With Quote
Old 03-23-05, 08:35 PM   #191
monkeyhead
Registered User
 
Join Date: Mar 2005
Posts: 1
Default Re: 1.0-7167 for Linux x86 released

i cannot use agp with this or the previous set of drivers. the 7167 are a lot snappier with no agp than 6629, but if I use anything other than: option "NvAGP" "0", my box locks up with a blank screen as soon as X begins to draw the screen. it's a shame because with x.org 6.7 and the 6111 series, it was nice and stable and i didn't have to disable anything.

i'm using an athalon 2600 on a biostar nforce2 motherboard with a geforce2 mx/mx 400 card and the 2.6.9-ck1 kernel.

i tried re-compiling my kernel without agpgart support as well as trying a 2.6.10 and 11 ck kernel. no love and the .10 and .11 kernels didn't like my alsa setup, so i got lazy and just went back to 2.6.9-ck1.
monkeyhead is offline   Reply With Quote
Old 03-24-05, 05:00 PM   #192
snaboofypop
Registered User
 
Join Date: Aug 2003
Posts: 29
Default Re: 1.0-7167 for Linux x86 released

<zander>1.0-7167 shouldn't require patching for current -bk kernels.
But it may though. I've tried building 2.6.12-rc1 and 2.6.12-rc1-bk1 with the current (71.67) drivers. It installs and runs ok (so long as you don't reboot). It's when you reboot that the drivers fight with the anticipatory scheduler on startup. I haven't tested exhaustively, but I have tried with Option "NvAgp" "2" (which becomes unstable on reboot), and Option "NvAGP" "0" --which according to my documentation turns off AGP, but unfortunately also becomes unstable after reboot. (some of) the problem can be seen here:
scsi1 : SCSI emulation for IEEE-1394 SBP-2 Devices
SCSI device sda: 268435455 512-byte hdwr sectors (137439 MB)
sda: cache data unavailable
sda: assuming drive cache: write through
SCSI device sda: 268435455 512-byte hdwr sectors (137439 MB)
sda: cache data unavailable
sda: assuming drive cache: write through
sda: sda1
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
ieee1394: sbp2: Logged into SBP-2 device
Unable to handle kernel paging request at virtual address 393831e4
printing eip:
f88c23fd
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
Modules linked in: sd_mod video thermal processor fan button battery ac usblp ohci1394 ohci_hcd usbcore tuner bttv video_buf i2c_algo_bit v4l2_common btcx_risc
tveeprom videodev i2c_sis96x i2c_core snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore sis900 sbp2 scsi_mod ieee1394
CPU: 0
EIP: 0060:[<f88c23fd>] Not tainted VLI
EFLAGS: 00010006 (2.6.12-rc1-bk1)
EIP is at sbp2scsi_queuecommand+0x1e/0x16c [sbp2]
eax: f7416400 ebx: 00000297 ecx: fffbc71c edx: f74a5000
esi: f7416400 edi: f7501b00 ebp: 3938313c esp: f74ddcdc
ds: 007b es: 007b ss: 0068
Process knodemgrd_0 (pid: 3532, threadinfo=f74dc000 task=f792c590)
Stack: 00000000 f7501b68 00000246 c03bc0a0 f7501b68 00000000 00000297 f7416400
f7501b00 00000000 f890b5ad f7501b00 f890b7c5 f890e3d4 f7501b88 f7501b00
f74a5000 f7416400 f74dc000 f8911051 f7501b00 f7540ab0 c021542a f7b75980
Call Trace:
[<f890b5ad>] scsi_dispatch_cmd+0x160/0x224 [scsi_mod]
[<f890b7c5>] scsi_done+0x0/0x26 [scsi_mod]
[<f890e3d4>] scsi_times_out+0x0/0xa0 [scsi_mod]
[<f8911051>] scsi_request_fn+0x1c9/0x3e8 [scsi_mod]
[<c021542a>] __elv_add_request+0x84/0xb4
[<c021813d>] blk_insert_request+0xbf/0xe0
[<f890fc7a>] scsi_insert_special_req+0x3a/0x40 [scsi_mod]
[<f890fe9b>] scsi_wait_req+0x69/0x9b [scsi_mod]
[<f890fdbf>] scsi_wait_done+0x0/0x73 [scsi_mod]
[<f891234d>] scsi_probe_lun+0xd6/0x22a [scsi_mod]
[<c0213a9f>] transport_setup_classdev+0x0/0x2d
[<f890b028>] scsi_allocate_request+0x28/0x62 [scsi_mod]
[<f8912867>] scsi_probe_and_add_lun+0xb2/0x1cd [scsi_mod]
[<f8912e72>] __scsi_add_device+0x6b/0xa2 [scsi_mod]
[<f88c0a74>] sbp2_start_device+0x203/0x3a1 [sbp2]
[<c02108b0>] driver_probe_device+0x29/0x68
[<c0210936>] device_attach+0x47/0x9c
[<c01bd50d>] kobject_get+0x17/0x1e
[<c0210be9>] bus_add_device+0x56/0xb7
[<c0213d93>] device_pm_add+0x56/0x8b
[<c020fbb6>] device_add+0xaf/0x151
[<f88d6a1b>] nodemgr_register_device+0x97/0xe4 [ieee1394]
[<f88d6e3e>] nodemgr_process_unit_directory+0x3d6/0x461 [ieee1394]
[<f88d6fed>] nodemgr_process_root_directory+0x124/0x22c [ieee1394]
[<f88d79af>] nodemgr_probe_ne+0x6e/0x7a [ieee1394]
[<f88d7a0a>] nodemgr_node_probe+0x4f/0x97 [ieee1394]
[<f88d7daf>] nodemgr_host_thread+0x170/0x17d [ieee1394]
[<f88d7c3f>] nodemgr_host_thread+0x0/0x17d [ieee1394]
[<c01012a5>] kernel_thread_helper+0x5/0xb
Code: 8c f8 eb 8d c7 04 24 34 33 8c f8 eb 84 55 57 56 53 83 ec
18 8b 44 24 2c 8b 50 04 8b 02 8b a8 00 02 00 00 85 ed 0f 84 16 01 00 00 <8b> 85 a8 00 00 00 85 c0 0f 84 1e 01 00 00 8b 5a 40 85 db 75 4a
<6>note: knodemgrd_0[3532] exited with preempt_count 1
ieee1394: sbp2: aborting sbp2 command
scsi1 : destination target 0, lun 0
command: Inquiry: 12 00 00 00 24 00
Unable to handle kernel paging request at virtual address 464c4607
printing eip:
f88c02f1
*pde = 00000000
Oops: 0000 [#2]
PREEMPT
Modules linked in: sd_mod video thermal processor fan button battery ac usblp ohci1394 ohci_hcd usbcore tuner bttv video_buf i2c_algo_bit v4l2_common btcx_risc
tveeprom videodev i2c_sis96x i2c_core snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore sis900 sbp2 scsi_mod ieee1394
CPU: 0
EIP: 0060:[<f88c02f1>] Not tainted VLI
EFLAGS: 00010002 (2.6.12-rc1-bk1)
EIP is at sbp2util_find_command_for_SCpnt+0x1f/0x80 [sbp2]
eax: 464c457f ebx: f7501b00 ecx: f742a000 edx: 464c4607
esi: 00000002 edi: f7501b00 ebp: f742bfac esp: f742bf48
ds: 007b es: 007b ss: 0068
Process scsi_eh_1 (pid: 3926, threadinfo=f742a000 task=f7d840a0)
Stack: f7501b00 464c457f f742bfb4 f88c27c6 464c457f f7501b00 f742a000 00000202
f890eaa0 f7501b00 f7501b00 f742bfb4 f742bfb4 f890ebc2 f7501b00 f742a000
f7416438 f742a000 00000286 f742bfac f890f6b8 f742bfb4 f742bfac f7d841c8
Call Trace:
[<f88c27c6>] sbp2scsi_abort+0x38/0x9a [sbp2]
[<f890eaa0>] scsi_try_to_abort_cmd+0x49/0x6c [scsi_mod]
[<f890ebc2>] scsi_eh_abort_cmds+0x35/0x7d [scsi_mod]
[<f890f6b8>] scsi_unjam_host+0xa9/0xd3 [scsi_mod]
[<f890f780>] scsi_error_handler+0x9e/0xc6 [scsi_mod]
[<f890f6e2>] scsi_error_handler+0x0/0xc6 [scsi_mod]
[<c01012a5>] kernel_thread_helper+0x5/0xb
Code: c0 eb e0 e8 48 21 9f c7 89 d8 eb ea 57 56 53 8b 44 24 10
8b 7c 24 14 9c 5e fa b9 00 e0 ff ff 21 e1 83 41 14 01 8d 90 88 00 00 00 <8b> 80 88 00 00 00 39 d0 74 18 89 c3 eb 0a 39 bb 04 01 00 00 74
<6>note: scsi_eh_1[3926] exited with preempt_count 2
...and finally
gdm[6254]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0
gdm[6395]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0
gdm[6462]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0
gdm[5869]: deal_with_x_crashes: Running the XKeepsCrashing script
gdm[5869]: Failed to start X server several times in a short time period; disabling display :0

...sorry ...on the other hand, the 77.67 driver works (very well) with kernels up to and including 2.6.11.4, and as I say, it works with all of the latest kernels so long as you don't reboot (glx apps work fine, tv overscan works fine...). It's on system startup that things go south. These bk kernels work fine without nvidia drivers on their own (through reboot cycles too), and you can install the new drivers once and get the benefits of the new drivers, just don't reboot...........A cheap and dirty hack to maintain your bk kernel builds with the new drivers is to modify /etc/inittab by commenting out the x startup line:
#x:5:respawn:/etc/X11/prefdm -nodaemon
and replacing /etc/X11/xorg.conf with a non-nvidia version of xorg.conf,
then boot the bk kernel, replace xorg.conf(generic) with xorg.conf(nvidia), uncomment the x startup line in /etc/inittab, (save changes to /etc/inittab), and run /sbin/init q (which will restart inittab, the x server will start and run with the previously installed 77.67 drivers). It may be possible to eliminate one of the above steps, but I haven't quite hacked that far yet...

...I also know that bk kernels are works in process. Adrian Bunk ran the coverity checker on video.c and found:
The Coverity checker found the following null pointer dereference in
drivers/acpi/video.c:

<-- snip -->

...
static int
acpi_video_switch_output(
...
{
...
struct acpi_video_device *dev=NULL;
...
list_for_each_safe(node, next, &video->video_device_list) {
struct acpi_video_device * dev = container_of(node, struct acpi_video_device, entry);
...
}
...
switch (event) {
case ACPI_VIDEO_NOTIFY_CYCLE:
case ACPI_VIDEO_NOTIFY_NEXT_OUTPUT:
acpi_video_device_set_state(dev, 0);
acpi_video_device_set_state(dev_next, 0x80000001);
break;
case ACPI_VIDEO_NOTIFY_PREV_OUTPUT:
acpi_video_device_set_state(dev, 0);
acpi_video_device_set_state(dev_prev, 0x80000001);
...

<-- snip -->


Two different variables of the same name within 40 lines of code are a
good indication that something's wrong...


The outer "dev" variable is never assigned any value different from
NULL.

acpi_video_device_set_state dereferences this variable.

...so this could be a sign that there may not be issues with 77.67, but rather with the bk kernels.... oh well, my hack still works!

'boofypop
snaboofypop is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 10:08 AM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.