Re: BFS issues and linux 3.3 (Con Kolivas)

[Almost-retired]

>Alternatively, the microcode firmware file will be updated automatically from a script in cron.montly.

>I'm unable to test the amd part, as the script refuse to run on Intel CPU: is there  a kind soul who could test it on AMD >CPU ? Yes  Grin

>once installed, please run:
>Code:

>/etc/init.d/microcode_ctl restart

Nominal in dmesg

>then retry with:
>Code:

>/usr/sbin/update-amd-microcode
>/etc/init.d/microcode_ctl restart

Nominal again.

>after running update-amd-microcode, the firmware file should be in /lib/firmware/amd-ucode

Where it has been for something like 4 years. 

But I note there is a v83 version there that is a few days newer than the rest:

[root@coyote ~]# ls -l /lib/firmware/amd-ucode/
total 76
-rw-r--r-- 1 root root   642 Jan 17 11:50 INSTALL
-rw-r--r-- 1 root root  9987 Jan 17 11:50 LICENSE
-rw-r--r-- 1 root root 12404 Jan 17 11:50 microcode_amd.bin
-rw-r--r-- 1 root root  1526 Jan 17 11:50 microcode_amd.bin.README
-rw-r--r-- 1 root root  2644 Jan 17 11:50 microcode_amd_fam15h.bin
-rw-r--r-- 1 root root   510 Jan 17 11:50 microcode_amd_fam15h.bin.README
-rw-r--r-- 1 root root  2012 Jan 20  2009 microcode_amd.phenom-V83
-rw-r--r-- 1 root root 15020 Jan 17 11:50 microcode_amd_solaris.bin
-rw-r--r-- 1 root root  1685 Jan 17 11:50 microcode_amd_solaris.bin.README
-rw-r--r-- 1 root root  6227 Jan 17 11:50 README

and other than the 83, no clue as to which is actually being loaded and used, but I would assume its the V83 since that is the one with the "phenom" in its name.

>finally:
>Code:

>dmesg | grep microcode

which, on this 2.6.38.8-pclos3-pae-bfs kernel works as expected.

Now, the missus came about 2 hours back & asked if she was losing weight, or if I was going to feed her, so I took care of that and now I'm ready to reboot again.  So we'll see in a bit.

Thanks & Cheers, Gene

[AS]

But I note there is a v83 version there that is a few days newer than the rest:

No, it is the oldest one 

[root@coyote ~]# ls -l /lib/firmware/amd-ucode/
total 76
-rw-r--r-- 1 root root   642 Jan 17 11:50 INSTALL
-rw-r--r-- 1 root root  9987 Jan 17 11:50 LICENSE
-rw-r--r-- 1 root root 12404 Jan 17 11:50 microcode_amd.bin
-rw-r--r-- 1 root root  1526 Jan 17 11:50 microcode_amd.bin.README
-rw-r--r-- 1 root root  2644 Jan 17 11:50 microcode_amd_fam15h.bin
-rw-r--r-- 1 root root   510 Jan 17 11:50 microcode_amd_fam15h.bin.README
-rw-r--r-- 1 root root  2012 Jan 20  2009 microcode_amd.phenom-V83
-rw-r--r-- 1 root root 15020 Jan 17 11:50 microcode_amd_solaris.bin
-rw-r--r-- 1 root root  1685 Jan 17 11:50 microcode_amd_solaris.bin.README
-rw-r--r-- 1 root root  6227 Jan 17 11:50 README

man page of update-amd-microcode refers to microcode_amd.bin ...

[Almost-retired]

I've looked at /etc/init.d/microcode_ctl, and stuck a couple of echo's in it to see if I could find enlightenment, but didn't get any clues out of it, and it works normally on a home-brewed 2.6.38.8 kernel.  But that same code calls for the intel code in /usr/share when booted to 3.2.14, so I'd have to say something in the /proc filesystem seems to have changed.

Since posting last I have built & installed 2 more kernels, but while dkms goes through all the motions, it does not place an nvidia.ko file in the /lib/modules/3.2.14-pclos1-gene-pae-bfs/kernel/driver/video directory.  In fact, the only such module that exists on this system are the 2 in this kernels /lib/modules tree.
[root@coyote linux-3.2.14-pclos7-gene-pae-bfs]# locate nvidia.ko
/lib/modules/2.6.38.8-pclos3.pae.bfs/kernel/drivers/video/nvidia.ko
/lib/modules/2.6.38.8-pclos3.pae.bfs.old/kernel/drivers/video/nvidia.ko

Somehow, I have a hunch that the microcode_ctl problem and the apparent storage of the nvidia.ko module in /dev/null, are related, fixing 1 might fix both.

FWIW, after the attempt to build nvidia for 3.2.14-gene-pae-bfs, the /var/lib/dkms-binary directory is empty.

Near the end of the make.log is a stanza that ends with  "-o /var/lib/dkms/nvidia-current/295.40-1pclos2012/build/nvidia.ko", but that file is not there now after rebooting to 2.6.38.8-pclos3-pae-bfs.

It is getting late & sleepy.  If anyone has any ideas to check out I'll see what I can do tomorrow.

Thanks & Cheers, Gene

[AS]

The current module built from nvidia-2xx.xx is nvidia-current.ko  or nvidia-current.ko.gz depending on your settings.

[Almost-retired]

Not so according to the make.log

Its last logged operation is:
  ld -r -m elf_i386 -T /usr/src/linux-3.2.14-pclos7-gene-pae-bfs/scripts/module-common.lds --build-id  -o /var/lib/dkms/nvidia-current/295.40-1pclos2012/build/nvidia.ko /var/lib/dkms/nvidia-current/295.40-1pclos2012/build/nvidia.o /var/lib/dkms/nvidia-current/295.40-1pclos2012/build/nvidia.mod.o

But if as root, I re-exec that line:
ld: cannot find /var/lib/dkms/nvidia-current/295.40-1pclos2012/build/nvidia.o: No such file or directory
ld: cannot find /var/lib/dkms/nvidia-current/295.40-1pclos2012/build/nvidia.mod.o: No such file or directory

And they don't exist.  However, locate says it was built.
[root@coyote module]# locate nvidia-current.ko.gz
/lib/modules/2.6.38.8-pclos3.pae.bfs/kernel/drivers/char/drm/nvidia-current.ko.gz
/lib/modules/3.2.14-pclos7/kernel/drivers/char/drm/nvidia-current.ko.gz
/lib/modules/3.2.14-pclos7-gene-pae-bfs/kernel/drivers/char/drm/nvidia-current.ko.gz
/lib/modules/3.2.14-pclos7.pae.bfs/kernel/drivers/char/drm/nvidia-current.ko.gz
/var/lib/dkms/nvidia-current/295.40-1pclos2012/2.6.38.8-pclos3.pae.bfs/i586/module/nvidia-current.ko.gz
/var/lib/dkms/nvidia-current/295.40-1pclos2012/3.2.14-pclos7/i586/module/nvidia-current.ko.gz
/var/lib/dkms/nvidia-current/295.40-1pclos2012/3.2.14-pclos7-gene-pae-bfs/i586/module/nvidia-current.ko.gz
/var/lib/dkms/nvidia-current/295.40-1pclos2012/3.2.14-pclos7.pae.bfs/i586/module/nvidia-current.ko.gz

Ooookaaayyy.  So where is the linkage between X trying to load the "nvidia" module, and that "nvidia-current.ko.gz"

From that Xorg.0.log:
[   113.024] (II) LoadModule: "nvidia"
[   113.249] (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so
[   113.375] (II) Module nvidia: vendor="NVIDIA Corporation"
[   113.375]    compiled for 4.0.2, module version = 1.0.0
[   113.375]    Module class: X.Org Video Driver
[   113.483] (EE) NVIDIA: Failed to load the NVIDIA kernel module. Please check your
[   113.483] (EE) NVIDIA:     system's kernel log for additional error messages.
[   113.483] (II) UnloadModule: "nvidia"
[   113.483] (II) Unloading nvidia
[   113.483] (EE) Failed to load module "nvidia" (module-specific error, 0)
[   113.483] (EE) No drivers available.

so it found the "nvidia" module, but not the "kernel" module.  And the module nvidia.ko only exists in the /lib/modules/2.6.38.8-pae-bfs tree, aka this kernel.

Another interesting tidbit, there is also a /usr/src/nvidia-current-295.40-1pclos2012] tree, but the date of every file in it is April 11, day before yesterday.  Nothing there was touched despite all my efforts yesterday.

But:
[root@coyote log]# ls -l /lib/modules/`uname -r`/kernel/drivers/char/drm
total 4540
-rw-r--r-- 1 root root 4635550 Apr 12 08:09 nvidia-current.ko.gz

And:
[root@coyote log]# ls -l /lib/modules/3.2.14-pclos7-gene-pae-bfs/kernel/drivers/char/drm
total 4536
-rw-r--r-- 1 root root 4631516 Apr 12 22:48 nvidia-current.ko.gz

So _that_ module does exist, and has been and is working since back in early March when I managed to get it to work for the first time, so I have NDI why its dated yesterday morning.

Oh, wait, that would have been the first reboot after synaptic had installed 295.40, so that explains that.  So the module nvidia-current.ko.gz does exist, but the module nvidia.ko only exists in this kernel's (2.6.38.8-pclos3 etc) lib/modules tree.  I believe that to be the key here, but I need more sleep & some coffee.

Thanks & Cheers, Gene

[AS]

next trials:

Code: [Select]

modprobe nvidia-current
modprobe --show-depends nvidia-current
modinfo nvidia-current


[Almost-retired]

The modprobe nvidia-current generated no output, the other two commands were redirected to a file:
[gene@coyote nvidia]$ cat nvidia-data
insmod /lib/modules/3.2.14-pclos7-gene-pae-bfs/kernel/drivers/i2c/i2c-core.ko.gz
insmod /lib/modules/3.2.14-pclos7-gene-pae-bfs/kernel/drivers/char/drm/nvidia-current.ko.gz
filename:       /lib/modules/3.2.14-pclos7-gene-pae-bfs/kernel/drivers/char/drm/nvidia-current.ko.gz
alias:          char-major-195-*
version:        295.40
supported:      external
license:        NVIDIA
alias:          pci:v000010DEd00000E00sv*sd*bc04sc80i00*
alias:          pci:v000010DEd00000AA3sv*sd*bc0Bsc40i00*
alias:          pci:v000010DEd*sv*sd*bc03sc02i00*
alias:          pci:v000010DEd*sv*sd*bc03sc00i00*
depends:
vermagic:       3.2.14-pclos7-gene-pae-bfs SMP preempt mod_unload K8
parm:           NVreg_EnableVia4x:int
parm:           NVreg_EnableALiAGP:int
parm:           NVreg_ReqAGPRate:int
parm:           NVreg_EnableAGPSBA:int
parm:           NVreg_EnableAGPFW:int
parm:           NVreg_Mobile:int
parm:           NVreg_ResmanDebugLevel:int
parm:           NVreg_RmLogonRC:int
parm:           NVreg_ModifyDeviceFiles:int
parm:           NVreg_DeviceFileUID:int
parm:           NVreg_DeviceFileGID:int
parm:           NVreg_DeviceFileMode:int
parm:           NVreg_RemapLimit:int
parm:           NVreg_UpdateMemoryTypes:int
parm:           NVreg_InitializeSystemMemoryAllocations:int
parm:           NVreg_UseVBios:int
parm:           NVreg_RMEdgeIntrCheck:int
parm:           NVreg_UsePageAttributeTable:int
parm:           NVreg_EnableMSI:int
parm:           NVreg_MapRegistersEarly:int
parm:           NVreg_RegisterForACPIEvents:int
parm:           NVreg_RegistryDwords:charp
parm:           NVreg_RmMsg:charp
parm:           NVreg_NvAGP:int

And this was the output of a uname -r.
3.2.14-pclos7-gene-pae-bfs

I did a startx just for S&G at that point, which apparently cannot be redirected to a file for capture, but it complained:
NVIDIA kernel module is version 295.40
but the driver component is version 295.20

But, from this current Xorg.0.log

[    56.337] (II) LoadModule: "nvidia"
[    56.452] (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so
[    56.727] (II) Module nvidia: vendor="NVIDIA Corporation"
[    56.727]    compiled for 4.0.2, module version = 1.0.0
[    56.727]    Module class: X.Org Video Driver
[    56.789] (II) NVIDIA dlloader X Driver  295.20  Mon Feb  6 20:27:19 PST 2012
[    56.821] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs

That miss-match didn't bother it a bit & X is working fine.

From a modinfo nvidia-current on the module that is loaded and running right now:
filename:       /lib/modules/2.6.38.8-pclos3.pae.bfs/kernel/drivers/char/drm/nvidia-current.ko.gz
alias:          char-major-195-*
version:        295.40
supported:      external
license:        NVIDIA
alias:          pci:v000010DEd00000E00sv*sd*bc04sc80i00*
alias:          pci:v000010DEd00000AA3sv*sd*bc0Bsc40i00*
alias:          pci:v000010DEd*sv*sd*bc03sc02i00*
alias:          pci:v000010DEd*sv*sd*bc03sc00i00*
depends:
vermagic:       2.6.38.8-pclos3.pae.bfs SMP preempt mod_unload K8
parm:           NVreg_EnableVia4x:int
parm:           NVreg_EnableALiAGP:int
parm:           NVreg_ReqAGPRate:int
parm:           NVreg_EnableAGPSBA:int
parm:           NVreg_EnableAGPFW:int
parm:           NVreg_Mobile:int
parm:           NVreg_ResmanDebugLevel:int
parm:           NVreg_RmLogonRC:int
parm:           NVreg_ModifyDeviceFiles:int
parm:           NVreg_DeviceFileUID:int
parm:           NVreg_DeviceFileGID:int
parm:           NVreg_DeviceFileMode:int
parm:           NVreg_RemapLimit:int
parm:           NVreg_UpdateMemoryTypes:int
parm:           NVreg_InitializeSystemMemoryAllocations:int
parm:           NVreg_UseVBios:int
parm:           NVreg_RMEdgeIntrCheck:int
parm:           NVreg_UsePageAttributeTable:int
parm:           NVreg_EnableMSI:int
parm:           NVreg_MapRegistersEarly:int
parm:           NVreg_RegisterForACPIEvents:int
parm:           NVreg_RegistryDwords:charp
parm:           NVreg_RmMsg:charp
parm:           NVreg_NvAGP:int

WTH?  I'm running out of hair here & its already thin enough I could go out bareheaded & sunburn.

On another front, the /etc/init.d/microcode_ctl one, I had left my echo's in it, which echo'd to the screen as it was booting:
AuthenticAMD
16
but it still skipped the amd loader & went looking for the intel code a few lines later.

Your turn, I'm out of mental ammo.  ENOTENOUGHCAFFIENE or something.

Thanks & Cheers, Gene

[AS]

I did a startx just for S&G at that point, which apparently cannot be redirected to a file for capture, but it complained:
NVIDIA kernel module is version 295.40
but the driver component is version 295.20

there are two packages for nvidia:
dkms-nvidia-current-295.40-1_as_2012
x11-driver-video-nvidia-current-295.40-1_as_2012

for some reason, unknown to me, it seems the old x11-driver-video-nvidia-current is installed on your system ...
should not be there ... and there should be the updated version.

But, from this current Xorg.0.log

[    56.337] (II) LoadModule: "nvidia"
[    56.452] (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so
[    56.727] (II) Module nvidia: vendor="NVIDIA Corporation"
[    56.727]    compiled for 4.0.2, module version = 1.0.0
[    56.727]    Module class: X.Org Video Driver
[    56.789] (II) NVIDIA dlloader X Driver  295.20  Mon Feb  6 20:27:19 PST 2012
[    56.821] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs

That miss-match didn't bother it a bit & X is working fine.

the different version are probably compatible to some degree ... I would advise to update the x11-video-driver ...

Now it is my turn for a coffee 

AS

[Almost-retired]

According to synaptic, it is installed.

But, on checking I seem to have 2 trees of this stuff:

[root@coyote xorg]# ls -l `locate nvidia_drv.so`
-rwxr-xr-x 1 root root 7520184 Apr 11 22:35 /usr/lib/nvidia-current/xorg/nvidia_drv.so*
-rwxr-xr-x 1 root root 7511448 Mar  4 10:16 /usr/lib/xorg/modules/drivers/nvidia_drv.so*

and it is using the 2nd one which is the 295.20 version, but that has to be a month older even than March 4th to be the .20 version.   Yes, that package is dated Feb 23 in /var/cache/apt/archives.

How should I proceed?

Overwriting the older one seems like it should work, but this really really needs to be fixed at the packaging stage eventually since it seems to me that is how it got scrambled.

While I have been known to install straight from nvidia, I have not, and have no traces of a local build on the system that I can find since installing this pclos2010 something close to 18 months ago now.

But maybe, just maybe, we've got the perp cornered.

Thanks & Cheers, Gene

[AS]

According to synaptic, it is installed.

But, on checking I seem to have 2 trees of this stuff:

[root@coyote xorg]# ls -l `locate nvidia_drv.so`
-rwxr-xr-x 1 root root 7520184 Apr 11 22:35 /usr/lib/nvidia-current/xorg/nvidia_drv.so*

the above match that one provided from nvidia-295.40

-rwxr-xr-x 1 root root 7511448 Mar  4 10:16 /usr/lib/xorg/modules/drivers/nvidia_drv.so*

about this one, please try:

Code: [Select]

rpm -qf /usr/lib/xorg/modules/drivers/nvidia_drv.so

[Almost-retired]

[root@coyote ~]# rpm -qf /usr/lib/xorg/modules/drivers/nvidia_drv.so
file /usr/lib/xorg/modules/drivers/nvidia_drv.so is not owned by any package

Humm...

Thanks & Cheers, Gene

[AS]

[root@coyote ~]# rpm -qf /usr/lib/xorg/modules/drivers/nvidia_drv.so
file /usr/lib/xorg/modules/drivers/nvidia_drv.so is not owned by any package

Humm...

Thanks & Cheers, Gene

it doesn't belong to any installed package ... it is not present on my system that is using nvidia-295.40 ...
I would say delete it or rename it ...

[Almost-retired]

I copied the nvidia_drv.so-295.40 file to every conceivable place X might look without any luck and probably another 25 or 30 reboots, all of which failed including the one good boot I did have after renaming that file.  Using mc I had started on a search and destroy mission to find ALL the 295.20 crap on the system, but that appeared to be an endless task so I quite that after nuking about 16 files.

Finally, running out of patience and since if I couldn't get it going, I do have about .7 terrabytes of backups handy, I took what could have been a hydrogen bomb to the system by issuing as root, an "rm -f `locate 295.20`.  It killed about 6 more files in /usr/lib, and I double checked all the steps in the instructions to use in place of  XFdrake, all as root, then just for the hell of it typed startx, and a root x session popped right up, with a boatload of strange icons up and down the left edge of the screen.  Since I'd never run x before as root, I opened a konsole session & typed reboot, booting up to 3.2.14-yadda-yadda.  Logged in as me and here I am.

Maybe there might be some help here for others similarly afflicted if you can pick and choose in between the rants.
I have NDI how the packaging system didn't clean up after itself.  But it sure left me with a mess.

Thanks for bearing with me all this thread, now if we can just fix /etc/init.d microcode_ctl.  I am going to go thru mine and nuke anything that looks like Intel, because that error is still there.  Have you found anything?
It, with nothing but the echo's added, reports:
[gene@coyote log]$ sudo /etc/init.d/microcode_ctl start
AuthenticAMD  (vendor)
16 (family)
CPU microcode data file not present (/usr/share/misc/intel-microcode.dat)

So I'm gonna fix mine by nuking the intel stuff.

Cheers, Gene

[AS]

I copied the nvidia_drv.so-295.40 file to every conceivable place X might look without any luck and probably another 25 or 30 reboots, all of which failed including the one good boot I did have after renaming that file.  Using mc I had started on a search and destroy mission to find ALL the 295.20 crap on the system, but that appeared to be an endless task so I quite that after nuking about 16 files.

Finally, running out of patience and since if I couldn't get it going, I do have about .7 terrabytes of backups handy, I took what could have been a hydrogen bomb to the system by issuing as root, an "rm -f `locate 295.20`.  It killed about 6 more files in /usr/lib, and I double checked all the steps in the instructions to use in place of  XFdrake, all as root, then just for the hell of it typed startx, and a root x session popped right up, with a boatload of strange icons up and down the left edge of the screen.  Since I'd never run x before as root, I opened a konsole session & typed reboot, booting up to 3.2.14-yadda-yadda.  Logged in as me and here I am.

So the nvidia driver issue is now fixed ?

Maybe there might be some help here for others similarly afflicted if you can pick and choose in between the rants.
I have NDI how the packaging system didn't clean up after itself.  But it sure left me with a mess.

Thanks for bearing with me all this thread, now if we can just fix /etc/init.d microcode_ctl.  I am going to go thru mine and nuke anything that looks like Intel, because that error is still there.  Have you found anything?
It, with nothing but the echo's added, reports:
[gene@coyote log]$ sudo /etc/init.d/microcode_ctl start
AuthenticAMD  (vendor)
16 (family)
CPU microcode data file not present (/usr/share/misc/intel-microcode.dat)

So I'm gonna fix mine by nuking the intel stuff.

Cheers, Gene

That's a symptom that the script is not quite correct, because for AMD CPUs should not search in /usr/share/misc but in /lib/firmware/amd-ucode ... and more important should not look for intel-microcode.dat.

I suspected something like that ... and you are confirming my suspects ... will look further into the source package.

AS

[Almost-retired]

I put another echo on it, and now get this, while nuking the if stuff that led to the intel stuff.
[root@coyote init.d]# ./microcode_ctl start
AuthenticAMD
16
minor=14
Loading AMD microcode update module

Executing the line that sets minor in a shell returns a null.

Gotta go wash my truck. ;-)

Thanks & Cheers, Gene