Re: BFS issues and linux 3.3 (Con Kolivas)

[Almost-retired]

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

[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

Gene,

here you can find all patched from Con Colivas: http://ck.kolivas.org/patches/bfs/ the patch itself is arch agnostic, and the problem probably exists because several architectures are stripped out from the PCLinuxOS kernel packages, i.e. powerpc and several others ...

About the nvidia-driver, (and all other dkms too), AFAIK they build correctly against the new kernels, if not I would like to know about.

About microcode, PCLinuxOS kernel 3.2.x provide support for both Intel and AMD microcode, so does the utility to load microcode at boot ...

Back to the original problem, that seems to be the nvidia-driver ...: does the nvidia module load properly ?
i.e. modprobe nvidia-current
If yes, did you tried to run XFdrake ?

AS

[Almost-retired]

I just rebooted, after installing your latest nvidia-current package yesterday, to vmlinuz-3.2.14-pclos7.pae.bfs, and watched it install the nvidia driver.  But no X, and this in the 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.
[   113.483]
Fatal server error:
[   113.483] no screens found
[   113.483]
Please consult the The X.Org Foundation support
         at http://pclinuxos.com
 for help.
[   113.483] Please also check the log file at "/var/log/Xorg.0.log" for additional information.
--------
I had this same problem at one point with vmlinuz-2.6.38.8-pclos3.pae.bfs, but was able to make it work eventually by rebuilding that kernel from your src's but setting several of the "module version" commands to on that your original builds apparently defaulted to off.  This apparently destroys the nvidia drivers ability to build a working driver.

I was going to do the same thing with 3.2.14, but the lack of a directly apply able bfs patch was my stopping point.  The fact that your 3.2.14's are apparently built only for Intel processors is something else I would fix at the same time in addition to trimming the modules built of stuff I don't have.  GCC is of course getting slower all the time, I could, 2 years ago, build and install, ready to reboot, a linux kernel in 8 minutes using ccache.  With modern GCC's, its pushing an hour to build the whole Mary Ann.  So I suppose I can edit the bfs patch I have to remove the other arches, but I am disappointed that you don't even build for AMD's anymore.  There are quite a few phenoms out in the wild...

Or I could go back to running kernel.org srcs, my scripts are already quite well fine tuned to do that.

Thanks & Cheers, Gene

[AS]

Hi Gene,

[snip]
...
I was going to do the same thing with 3.2.14, but the lack of a directly apply able bfs patch was my stopping point.  The fact that your 3.2.14's are apparently built only for Intel processors is something else I would fix

 

$ dmesg | head -15
Linux version 3.2.14-pclos7 (andrea@dv1710.as) (gcc version 4.5.2 (GCC) ) #1 SMP Wed Apr 4 05:23:44 CEST 2012
KERNEL supported cpus:
 Intel GenuineIntel
  AMD AuthenticAMD
  NSC Geode by NSC
  Cyrix CyrixInstead
  Centaur CentaurHauls
  Transmeta GenuineTMx86
  Transmeta TransmetaCPU
  UMC UMC UMC UMC
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000005fff0000 (usable)

at the same time in addition to trimming the modules built of stuff I don't have.  GCC is of course getting slower all the time, I could, 2 years ago, build and install, ready to reboot, a linux kernel in 8 minutes using ccache.  With modern GCC's, its pushing an hour to build the whole Mary Ann.  So I suppose I can edit the bfs patch I have to remove the other arches, but I am disappointed that you don't even build for AMD's anymore.  There are quite a few phenoms out in the wild...

   did you refer to .a64 kernel ?

http://distro.ibiblio.org/pclinuxos/pclinuxos/apt/pclinuxos/2010/RPMS.testing/kernel-3.2.14-pclos7.a64-1-1_as_2012.i586.rpm

Or I could go back to running kernel.org srcs, my scripts are already quite well fine tuned to do that.

Thanks & Cheers, Gene

About the nvidia drivers, which I use myself, I don't know what's your problem, because it is loading just fine on my system and on system from others users who reported on the testers mailing list.
The MODULE_VERSION it is turned off exactly because otherwise the nvidia module don't load properly.

About how the devel package is built, I simply followed the previous structure as defined by Texstar in the rpm specfile, although I have to change it a little because of the underlying changes between 2.6.38.8 and 3.2.x kernels and because of different patches.

The choice to remove the foreigner architectures was made directly from Texstar as it appear from the 2.6.38.8 specfile ... so this apply to 3.2.x as apply to 2.6.38.8 ... I understand you can't apply the bfs patch on the stripped package, this is correct as the patch is provided to be applied against the vanilla kernel ... both for 3.2.x and for 2.6.38.8.

The problem about the source package provided without the bfs patch is because only one source package is provided for the  whole series of kernels, (same as 2.6.38.8 )... indeed it this the source that refer to the plain kernel without .bfs/.pae.bfs/...
I will try to see what can I do about that ...

About the compilation time, the new kernels are bigger that two years ago ...

I'm a bit confused from your overall report, but of course if there is something to fix, I will be glad to do it.

AS

[JohnW_57]

Installed the latest Nvidia driver on the 3.2.14 kernel.

Used videocard: Asus ENGTS250

 A Part of the Xorg.0.log:

[    15.020] (II) LoadModule: "nvidia"
[    15.021] (II) Loading /usr/lib64/xorg/extra-modules/nvidia_drv.so
[    15.077] (II) Module nvidia: vendor="NVIDIA Corporation"
[    15.083]    compiled for 4.0.2, module version = 1.0.0
[    15.083]    Module class: X.Org Video Driver
[    15.095] (II) v4l driver for Video4Linux
[    15.095] (II) NVIDIA dlloader X Driver  295.40  Thu Apr  5 21:38:35 PDT 2012
[    15.095] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
[    15.095] (++) using VT number 8

Full log here: http://pastebin.com/hxSu5jJg

JohnW

[Almost-retired]

I take it back, I just checked the 'module versioning' as displayed by a make xconfig, in the 2.6.38.8-per-bfs tree, and it is not enabled.  Neither is src checksumming, but everything else is enabled.  That is the one I'm running ATM since nothing newer will co-habit with nvidia.

also, when it comes time to load the cpu microcode, it looks only for Intel, and of course does not find it, saying so in the boot log.  I did run with the neauvou driver for a couple weeks, but that puppy goes away, forcing a reboot tore-enable it at about 36 hour intervals on average.

The screen image the OS driver gave was excellent, doing a better job on small text rendering than the nvidia driver did, but I was forced back the the dark side by the fact that the neauvou driver doesn't support its being a target for an ssh -Y connection to any of my other machines on this home network.

As for your statement about this kernel supporting amd stuff, if it did, why does the microcode loader go looking only for Intel microcode.  I would have expected, since the microcode loader is in /etc/init.d, to have seen something like this:
Apr  8 22:01:03 coyote klogd: microcode: CPU0: patch_level=0x1000065
Apr  8 22:01:04 coyote ifplugd(eth0)[1589]: client: NETLINK: Packet too small or truncated! 64!=16!=1000
Apr  8 22:01:04 coyote klogd: microcode: CPU0: updated (new patch_level=0x1000083)
Apr  8 22:01:04 coyote klogd: microcode: CPU1: patch_level=0x1000065
Apr  8 22:01:04 coyote klogd: microcode: CPU1: updated (new patch_level=0x1000083)
Apr  8 22:01:04 coyote klogd: microcode: CPU2: patch_level=0x1000065
Apr  8 22:01:04 coyote klogd: microcode: CPU2: updated (new patch_level=0x1000083)
Apr  8 22:01:04 coyote klogd: microcode: CPU3: patch_level=0x1000065
Apr  8 22:01:04 coyote klogd: microcode: CPU3: updated (new patch_level=0x1000083)
Apr  8 22:01:04 coyote klogd: microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
Apr  8 22:01:04 coyote klogd: microcode: Microcode Update Driver: v2.00 removed.
 in the 3.2.14 bootlog, but its failure message in 3.2.14 never made it into the bootlog, I just see it going by since I am not using a graphical boot cover.

However, I just nuked the powerpc stuff from that 416 patch and it applied clean, so I have a 3.2.14 under construction.

If that appears successful, I'll reboot to it and see if the nvidia module will build correctly now as I've set it to build only for AMD stuff.  I will come back and post once it has been boot tested.

But one final question, where does the dkms system store whether or not it has built a module for this kernel?  I ask because my scripts copy the existing kernel stuffs to -old directories and recreate everything in /boot, /lib/modules etc from scratch so there are no left overs to confuse the issue, plus if I screw up, I can nuke the fresh version and undo the renaming of the -old trees and I am perfectly restored.  But from past experience, this does not fix nvidia's installer, who thinks it a has already built it for this kernel, and I haven't found a way to force it to retry the build without renaming the kernel src tree and re-installing from scratch.  That is understandably a PIMA.  But I expect to have to do it again here. ;-)

Thanks & cheers.

[JohnW_57]

But one final question, where does the dkms system store whether or not it has built a module for this kernel?  I ask because my scripts copy the existing kernel stuffs to -old directories and recreate everything in /boot, /lib/modules etc from scratch so there are no left overs to confuse the issue, plus if I screw up, I can nuke the fresh version and undo the renaming of the -old trees and I am perfectly restored.  But from past experience, this does not fix nvidia's installer, who thinks it a has already built it for this kernel, and I haven't found a way to force it to retry the build without renaming the kernel src tree and re-installing from scratch.  That is understandably a PIMA.  But I expect to have to do it again here. ;-)

More info here: http://www.linuxjournal.com/article/6896
                        http://wiki.centos.org/HowTos/BuildingKernelModules#head-d313bd351f90d4f25a2143b7bbcff73f927731f0
                        http://linux.dell.com/dkms/dkms-for-developers.pdf

JohnW

[AS]

I take it back, I just checked the 'module versioning' as displayed by a make xconfig, in the 2.6.38.8-per-bfs tree, and it is not enabled.  Neither is src checksumming, but everything else is enabled.  That is the one I'm running ATM since nothing newer will co-habit with nvidia.

also, when it comes time to load the cpu microcode, it looks only for Intel, and of course does not find it, saying so in the boot log.  I did run with the neauvou driver for a couple weeks, but that puppy goes away, forcing a reboot tore-enable it at about 36 hour intervals on average.

The screen image the OS driver gave was excellent, doing a better job on small text rendering than the nvidia driver did, but I was forced back the the dark side by the fact that the neauvou driver doesn't support its being a target for an ssh -Y connection to any of my other machines on this home network.

As for your statement about this kernel supporting amd stuff, if it did, why does the microcode loader go looking only for Intel microcode.  I would have expected, since the microcode loader is in /etc/init.d, to have seen something like this:
Apr  8 22:01:03 coyote klogd: microcode: CPU0: patch_level=0x1000065
Apr  8 22:01:04 coyote ifplugd(eth0)[1589]: client: NETLINK: Packet too small or truncated! 64!=16!=1000
Apr  8 22:01:04 coyote klogd: microcode: CPU0: updated (new patch_level=0x1000083)
Apr  8 22:01:04 coyote klogd: microcode: CPU1: patch_level=0x1000065
Apr  8 22:01:04 coyote klogd: microcode: CPU1: updated (new patch_level=0x1000083)
Apr  8 22:01:04 coyote klogd: microcode: CPU2: patch_level=0x1000065
Apr  8 22:01:04 coyote klogd: microcode: CPU2: updated (new patch_level=0x1000083)
Apr  8 22:01:04 coyote klogd: microcode: CPU3: patch_level=0x1000065
Apr  8 22:01:04 coyote klogd: microcode: CPU3: updated (new patch_level=0x1000083)
Apr  8 22:01:04 coyote klogd: microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
Apr  8 22:01:04 coyote klogd: microcode: Microcode Update Driver: v2.00 removed.
 in the 3.2.14 bootlog, but its failure message in 3.2.14 never made it into the bootlog, I just see it going by since I am not using a graphical boot cover.

Because that error belong to the microcode_ctl service ... so: kernel is built with microcode support, the service i.e. /etc/init.d/microcode_ctl doesn't load it.  I will take a look at this ASAP.

However, I just nuked the powerpc stuff from that 416 patch and it applied clean, so I have a 3.2.14 under construction.

If that appears successful, I'll reboot to it and see if the nvidia module will build correctly now as I've set it to build only for AMD stuff.  I will come back and post once it has been boot tested.

But one final question, where does the dkms system store whether or not it has built a module for this kernel?  I ask because my scripts copy the existing kernel stuffs to -old directories and recreate everything in /boot, /lib/modules etc from scratch so there are no left overs to confuse the issue, plus if I screw up, I can nuke the fresh version and undo the renaming of the -old trees and I am perfectly restored.  But from past experience, this does not fix nvidia's installer, who thinks it a has already built it for this kernel, and I haven't found a way to force it to retry the build without renaming the kernel src tree and re-installing from scratch.  That is understandably a PIMA.  But I expect to have to do it again here. ;-)

Thanks & cheers.

dkms:

check if the modules are properly built by running (again, because usually it is run upon first boot):

Code: [Select]

dmks_autoinstaller start
the dkms tree is in /var/lib/dkms, there you will find the log files for each build, i.e.:

/var/lib/dkms/nvidia-current/295.40-1_as_2012/3.2.14-pclos7/i586/log/make.log

I also haven't found a way to rebuild the dkms tree, if you get it before me, please let me know about  
EDIT: thanks JonhnW!  

It is my understanding that a kernel.a64.bfs would be desirable.  Correct ?

AS

[djohnston]

It is my understanding that a kernel.a64.bfs would be desirable.  Correct ?

AS

Yes! (my two cents) 

[Almost-retired]

It is my understanding that a kernel.a64.bfs would be desirable.  Correct ?

From the last time I looked at it, the a64 was still causing some of my fav utils, such as mc, to develop a tummy ache.  That was a bit over 2 years ago, so I chose the 32 bit install when I installed pclos originally, based purely on my assumption that the 32 bit version would Just Work(TM).  GCC of course will not allow me to change that now.

Next Q, apparently my copy/paste of all those UUID numbers in menu.lst left something to be desired.  I was under the impression that these numbers were in fact the devices blkid's.  If not, how are these long strings of numbers actually developed?

Anyway I have, on the third clean house of the previous install attempts & rebuild, I believe I should have a bootable kernel.  So I am off to reboot again.  The last reboot back to this 2.6.38.8-pae-bfs took about an hour on a frozen screen with the drive light locked on as it must have thought it had to e2fsck all 4 of my 1T drives.  The users would really appreciate at least a hint of an e2fsck being done...

Thanks & Cheers, Gene.

[Almost-retired]

/var/lib/dkms/nvidia-current/295.40-1_as_2012/3.2.14-pclos7/i586/log/make.log

Wasn't where it was at on my machine, and the last make.log was when it was making it for a pclos kernel, 3.2.14-pclos7.pae.bfs (i586).

As it is a bit lengthy to post here, I have put it on my web page, in an nvidia subdir off the "Genes-os9-stf" link.
Maybe that will illuminate what went south.

My web page: <http://coyoteden.dyndns-free.com:85/gene>

Genes-os9-stf is under a link called "here" a bit down from the top.

Thanks & Cheers, Gene

[AS]

It is my understanding that a kernel.a64.bfs would be desirable.  Correct ?

From the last time I looked at it, the a64 was still causing some of my fav utils, such as mc, to develop a tummy ache.  That was a bit over 2 years ago, so I chose the 32 bit install when I installed pclos originally, based purely on my assumption that the 32 bit version would Just Work(TM).  GCC of course will not allow me to change that now.

I'm assuming the answer is yes, ... if it will Just Work(TM) 

Next Q, apparently my copy/paste of all those UUID numbers in menu.lst left something to be desired.  I was under the impression that these numbers were in fact the devices blkid's.  If not, how are these long strings of numbers actually developed?

randomly from uuidgen.

Anyway I have, on the third clean house of the previous install attempts & rebuild, I believe I should have a bootable kernel.  So I am off to reboot again.  The last reboot back to this 2.6.38.8-pae-bfs took about an hour on a frozen screen with the drive light locked on as it must have thought it had to e2fsck all 4 of my 1T drives.  The users would really appreciate at least a hint of an e2fsck being done...

Thanks & Cheers, Gene.

there are two option in grub menu.lst:  quiet and splash=silent, the latter imply starting plymouth progress screen,
remove quiet and change the other to splash=verbose, of course you will loose plymouth bootsplash but you will get the old style text scrolling boot effects(TM) 

/var/lib/dkms/nvidia-current/295.40-1_as_2012/3.2.14-pclos7/i586/log/make.log
Wasn't where it was at on my machine, and the last make.log was when it was making it for a pclos kernel, 3.2.14-pclos7.pae.bfs (i586).

that was my own nvidia rpm ... check the kernel extension too, as it could be different on your build ...
/var/lib/dkms/nvidia-current/295.40-1pclos2012/3.2.14-pclos7/i586/log/make.log

As it is a bit lengthy to post here, I have put it on my web page, in an nvidia subdir off the "Genes-os9-stf" link.
Maybe that will illuminate what went south.

My web page: <http://coyoteden.dyndns-free.com:85/gene>

Genes-os9-stf is under a link called "here" a bit down from the top.

Thanks & Cheers, Gene

there are a few warnings, (same for me here) but the make.log file look OK, I don't see errors.

AS

[AS]

still about the nvidia module, probably it was the flag MODULE_VERSION turned on ...

[JohnW_57]

http://pastebin.com/9h4QEfic

JohnW

[AS]

microcode_ctl

the is working for me, on intel CPU, however once installed it require to manually run /usr/sbin/update-intel-microcode or update-amd-microcode

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 

once installed, please run:

Code: [Select]

/etc/init.d/microcode_ctl restart
then retry with:

Code: [Select]

/usr/sbin/update-amd-microcode
/etc/init.d/microcode_ctl restart
after running update-amd-microcode, the firmware file should be in /lib/firmware/amd-ucode
finally:

Code: [Select]

dmesg | grep microcode...should confirm or not about success loading ...

Thanks,
AS