> > Try removing all the files in /etc/X11/xorg.conf.d/ and adding: > > $ cat /etc/X11/xorg.conf.d/nvidia.conf > Section "Device" > Identifier "nvidia" > Driver "nouveau" > Option "AccelMethod" "glamor" > EndSection > > -- Bruce
IIANM, that's what's given in the book. What's in the book is in my build script. I do add a screen stanza because I really prefer 800x600 for reading, so it has modes. --- > As far as the kernel panics go, you can try two things. First, try > slowing down your memory speed settings in the BIOS. Errm, but this seems strictly related to trying to use the Nouveau driver. It has been reliable with the VESA-fb driver. > Also, I found this: > > https://www.spinics.net/lists/stable/msg172825.html The description looked real good, so I got, and tried to apply, that patch to nv04.c to this LTS 4.9.30, and it was rejected as already applied. So perhaps I'll need to go for 4.11, (News at 11!). > It seems there have been a lot of race/timing issues fixed in the > kernel drm-nouveau driver for the 4.11 version. I would try the > latest 4.12-rc3 version (to make sure all those changes made it in > there) and see if that helps any: > https://www.kernel.org/ Pending... > > As far as startx goes, there might be something here that might > help: > > https://bbs.archlinux.org/viewtopic.php?id=208251 > > In particular, theNerd247 wrote: > > ---- > Ok. So weirdest thing happened. I went into the UEFI settings > and there is a setting called "3D Graphic Acceleration" and I > disabled it. I'm not sure if this disabled the GPU or not however. > After rebooting I ran startx and everything worked. Could it have > been the GPU? > --- N/A > > Lastly, in your kernel log messages > > dmesg | less > > what does it say with regard to "[drm]", "kernel modesetting" > and "Loading ..... Microcode"? [10:50 ~]# dmesg|grep "\[drm\]" [ 0.645345] [drm] Initialized WRT modesetting, sorry, I didn't get that on one of the few times it didn't panic, and I've since purged that kernel as "unhelpful". [10:52 ~]# dmesg|grep "icrocode" [ 0.700168] microcode: sig=0x106a4, pf=0x2, revision=0x11 [ 0.700349] microcode: Microcode Update Driver: v2.01 <[email protected]>, Peter Oruba However, this CPU is a "Bloomfield" i7-940, the first generation socket 1366 processors. A few months back I checked iNTEL's website and found no microcode updates for this one. There was one for the "Lynnfield" i7-870 socket 1156 in the other box, that I retrieved. Actually, I really don't mind using the VESA driver on this box. I'm not a gamer, all it needs to do is a little web browsing. With the "eight" cores, this is my compiling engine for building new systems and big packages. It needs to be able to test & demonstrate this new 7.10 system really works, so X has to be shown to run, but as for kernel bugs for this video card (which isn't new, GTS 450), I think that is "out of scope". I make an initial "general purpose" kernel heavy on hard drive drivers, just so it will boot on whatever x86-64 class box I clone it to--no sound, NIC, DRM--adaptation comes later once it boots. So strictly speaking, getting this to run with Nouveau now isn't relevant. Proving the X build works is what I need right now--so I can continue build the remaining ~220 packages in the pipeline. I think I really need to try to make the VESA driver work now, I suppose with frame-buffering. I'm going to back up a bit, Nouveau's kernel panics were a distraction. > > > Cheers, > > Mike Shell Thanks, Mike. Ideas about the VESA-fb? -- Paul Rogers [email protected] Rogers' Second Law: "Everything you do communicates." (I do not personally endorse any additions after this line. TANSTAAFL :-) -- http://www.fastmail.com - Send your email first class -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
