Re: BFS issues and linux 3.3 (Con Kolivas)

[AS]

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
 

bingo!  

minor come from:

Code: [Select]

minor=`uname -r |  cut -d . -f 3 | cut -d - -f 1`,follow a test:

Code: [Select]

if [ $minor -ge 29 ]; then
                        gprintf "Loading AMD microcode update module\n"

which is a bad test looking for a kernel >= 2.6.29 ... that's why now it is failing on kernel 3.2.14

I will fix the package, right now you could comment out the bad test.  

AS

[Almost-retired]

I have to admit it looked mighty weird to me too.  I already fixed my copy, but TBT, I fail to grok the reasoning behind that, in the context one logically derives from looking at that code, it makes about an F grade.  When I was still in school in 1947-48, that would have caused me to repeat that grade.  OTOH, I would not have bothered because by then I was about half on my own, fixing radios & tv's for a living.  By '51, I was quite well established.

Thanks & Cheers, Gene

[Almost-retired]

This thread has 'drifted' from bfs to microcode.

I posted a PS about this on another post to the lkml crowd, and just got this reply:
----------
> >Just a note: the intel microcode is loaded by a kernel-initiated
> >firmware request these days. There is no (broken) init script on
> >recent systems, to (rather mindlessly) fiddle around in userspace with
> >kernel internals.
> >
> >Kay
>
> That has to be a good deal in general, but it leaves us AMD users swinging
> in a strong breeze. That microcode loading was in the kernel until sometime
> in the 2.6.20ish time frame, I can recall scanning dmesg's where it was
> loaded by about line 75 in past history.  Now its just an afterthought.

Well, I don't know what your script does but it should simply

$ modprobe microcode

and the module should figure it out itself which microcode to load,
AFAICT.
-----------

So, since it doesn't hurt to do it all over again, I tried that, and got this in dmsg:
---------------
microcode: CPU0: patch_level=0x01000083
microcode: CPU1: patch_level=0x01000083
microcode: CPU2: patch_level=0x01000083
microcode: CPU3: patch_level=0x01000083
microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
---------

So that whole /etc/init.d/microcode_ctl script can be blown away and replaced with:
--------------
#!/bin/bash
/sbin/modprobe microcode
-------------
and it should Just Work(TM) on all x86 like architectures.

I see that the mods to my own script were blown away, and replaced with what looked like the original code just in the last 24 hours by synaptic but I haven't rebooted to see if it worked.  Dubious since the cause of the failure, the check for kernel minor version >29, has been reinstated.  I nuked it all in favor of the above 2 liner.

I seems to me that this 'microcode_ctl' is some sort of an attempt to reinvent the wheel that has already been better invented.

Why?

Cheers, Gene.

[AS]

I see that the mods to my own script were blown away, and replaced with what looked like the original code just in the last 24 hours by synaptic but I haven't rebooted to see if it worked.  Dubious since the cause of the failure, the check for kernel minor version >29, has been reinstated.  I nuked it all in favor of the above 2 liner.

Yes, I have fixed that package, the bad test for kernel > 2.6.29 has been removed.

I seems to me that this 'microcode_ctl' is some sort of an attempt to reinvent the wheel that has already been better invented.

Why?

Cheers, Gene.

The init script as deployed from microcode_ctl package do some additional test about CPU (i.e. different from AMD and/or Intel) ... not all world is using an AMD CPU like you, or an Intel CPU like me. 

Among Intel and AMD CPUs, the script check for minimal CPU families ... apparently early CPUs doesn't support microcode upload.

Cheers

AS

[Almost-retired]

I don't imagine the early ones do, I think the pentium fp bug got everybody on board on patchable cpus.

But I just looked at both files as they came out of the rpm, and don't see any diff, and they are both 2332 bytes long, in fact none of the files in that archive are even one byte different from their predecessor.

So I copied the /etc/rc.d/init.d/microcode_ctl file out of the rpm and put it in /tmp and ran it.  It is not fixed:
=============
[root@coyote tmp]# ./microcode_ctl start
CPU microcode data file not present (/usr/share/misc/intel-microcode.dat)                                                    [FAILED]
=============

Did you upload the correct file?

Cheers AS, Gene.

[AS]

Code: [Select]

# more /etc/cron.monthly/update-microcode
#!/bin/sh
#
# check if there is a new microcode for your CPU and update it

# Intel 686 and above, AMD family 16 and above
vendor=`grep "^vendor_id" /proc/cpuinfo | head -n1 | awk -F ": " '{ print $2 }'`
family=`grep "^cpu family" /proc/cpuinfo | head -n1 | awk -F ": " '{ print $2 }'`

if [ "$vendor" = "GenuineIntel" ] && [ $family -ge 6 ]; then
        /usr/sbin/update-intel-microcode
elif [ "$vendor" = "AuthenticAMD" ] && [ $family -ge 16 ]; then
#       minor=`uname -r |  cut -d . -f 3 | cut -d - -f 1`
#       if [ $minor -ge 29 ]; then
                /usr/sbin/update-amd-microcode
#       fi
fi


The fix is implemented by commenting out the bad test in /etc/cron.monthly/update-microcode,
/etc/init.d/microcode_ctl contain similar tests, but a test for kernel > 2.6.29 is not included, nor it was previously ...


EDIT: Sorry, my bad I missed to fix the test in the init script, a next update will follow. 

Cheers
AS

[Almost-retired]

Chuckle, happens to the best of us, AS.  Now I'm off for a dinner with the missus, some sort of a retired school employees doings as she is a retired music teacher.  I probably get to take extra sugar pills (I'm diabetic, type 2) & eat tough baked steak & pretend I'm not bored out of my skull.  I guess its one of those "for better or for worse" things. ;-)

Cheers AS, Gene

[Almost-retired]

As an update, I seem to have found a way to get around the broken dkms-nvidia installer.  It is a PIMA, but rename the kernel src tree for each attempted build, dkms cannot deal with rebuilding the same kernel.

So I have been successfully running 3.2.14-pclos7-gene-pae-bfs for the last 10 days.

But it sure would be nice if the install code could grow a --force option to force a fresh install even if it _thinks_ it has installed on this particular `uname -r` version before.

Now I have a firefox plugin problem, but I'll start a fresh thread for that, I've abused this one long enough.  Thanks a bunch for the help & hints AS, much appreciated.

Cheers, Gene

[AS]

How to rebuild a dkms drivers:

1) listing dkms info: (module, version, kernel: status)

# dkms status
nvidia-current, 295.40-1_as_2012, 2.6.38.8-pclos3.pae, i586: installed
nvidia-current, 295.40-1_as_2012, 3.3.3-pclos3.pae, i586: installed
nvidia-current, 295.40-1_as_2012, 3.2.16-pclos5.pae, i586: installed
nvidia-current, 295.40-1_as_2012, 3.2.15-as1, i586: installed
vboxhost, 4.1.12, 3.3.3-pclos3.pae, i586: built
vboxhost, 4.1.12, 3.2.16-pclos5.pae, i586: installed
vboxhost, 4.1.12, 3.2.15-as1, i586: installed

2) remove the dkms module, i.e. vboxhost, version 4.1.12, kernel 3.3.3-pclos3.pae:

# dkms remove -m vboxhost -v 4.1.12 -k 3.3.3-pclos3.pae

-------- Uninstall Beginning --------
Module:  vboxhost
Version: 4.1.12
Kernel:  3.3.3-pclos3.pae (i586)
-------------------------------------

Status: This module version was INACTIVE for this kernel.
depmod....

DKMS: uninstall Completed.

3) rebuilding a module

# dkms build -m vboxhost -v 4.1.12 -k 3.3.3-pclos3.pae
Preparing kernel 3.3.3-pclos3.pae for module build:
(This is not compiling a kernel, just preparing kernel symbols)
Storing current .config to be restored when complete
Running Generic preparation routine
make mrproper....
using /proc/config.gz
make oldconfig....
make prepare.....

Building module:
cleaning build area....
make KERNELRELEASE=3.3.3-pclos3.pae -C /lib/modules/3.3.3-pclos3.pae/build M=/var/lib/dkms/vboxhost/4.1.12/build.....
cleaning build area....
cleaning kernel tree (make mrproper).....

DKMS: build Completed.

Thanks about the --force idea, I will certainly evaluate that.  

Thanks to JohnW too, who pointed me in the right direction: 
http://www.pclinuxos.com/forum/index.php/topic,104278.msg890684.html#msg890684

AS

[Almost-retired]

This looks like it should work, but since the modules themselves live in /lib/modules/`uname -r`/kernel/drivers/etc/etc, there is isolation between builds (at least those built and installed with my scripts) in any event.

So while I can cobble up a script to do this prep work, it seems like nvidia must be paranoid about more than one copy ever being 'installed' at a time.  Is that a consequence of their lawyers paranoia, or just an accident because that is how the nvidia coders are so used to thinking?

So I assume my script to install on a freshly built reconfigured but not renamed kernel would look like this:
======
#!/bin/bash
dkms remove -m nvidia-current-295.40 -k `uname -r`
dkms build -m nvidia-current-295.40 -k `uname -r`
dkms_autoinstall nvidia-295.40 -k `uname -r`
======
Did I miss anything?

Thanks & Cheers, Gene

[AS]

This looks like it should work, but since the modules themselves live in /lib/modules/`uname -r`/kernel/drivers/etc/etc, there is isolation between builds (at least those built and installed with my scripts) in any event.

So while I can cobble up a script to do this prep work, it seems like nvidia must be paranoid about more than one copy ever being 'installed' at a time.  Is that a consequence of their lawyers paranoia, or just an accident because that is how the nvidia coders are so used to thinking?

So I assume my script to install on a freshly built reconfigured but not renamed kernel would look like this:
======
#!/bin/bash
dkms remove -m nvidia-current-295.40 -k `uname -r`
dkms build -m nvidia-current-295.40 -k `uname -r`
dkms_autoinstall nvidia-295.40 -k `uname -r`
======
Did I miss anything?

Thanks & Cheers, Gene

One thing: module name and module version must be provided separately, there is no dkms_autoinstall command:

Code: [Select]

#!/bin/bash
dkms remove   -m  nvidia-current  -v  295.40-1pclos2012  -k `uname -r`
dkms build    -m  nvidia-current  -v  295.40-1pclos2012  -k `uname -r`
dkms install  -m  nvidia-current  -v  295.40-1pclos2012  -k `uname -r`

please look at output from dkms status for exact naming of modules and versions.

AS

[Almost-retired]

One more slight change:
-------------
#!/bin/bash
VER=295.40-1pclos2012
MOD=nvidia-current
dkms remove -m  $MOD  -v  $VER -k `uname -r`
dkms build -m  $MOD  -v  $VER -k `uname -r`
dkms install -m  $MOD  -v  $VER -k `uname -r`
-----------
That way there are only two places to edit when something changes.

Thanks & Cheers AS, Gene

[AS]

Since the latest kernel src I see in the repos is 3.2.14, where might I obtain the x86(amd-K8) 32 bit version of this BFS patch?

I did pull the 3.2 version earlier this evening, but it contains patches for architectures other the 32 bit X86, so it causes patch to bail out creating the help text for powerpc since that path doesn't exist in the 3.2.14 src code tree that synaptic just installed.

I'd like to remake this kernel so it will run on an AMD K8 (phenom) cpu, and the right options to allow dkms to install the latest nvidia driver.  FWIW I had to do that with 2.6.38.8 also, but there the bfs patch Just Worked(TM).

The AMD problem with the default 3.2.14 kernel is that its looking for intel microcode, which of course doesn't exist on my system.  It runs, but there's that, and no Xwindows despite watching dkms install the nvidia driver on the reboot, startx can't find it.

Thanks all.

Cheers, Gene

Adding a note to this thread, because that bug who prevent the dkms module to load properly has been finally fixed, by patching the dkms package.

Thanks to kjpetrie:
http://www.pclinuxos.com/forum/index.php/topic,105342.0.html

AS