LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Slackware64 13.1 Nvidia framebuffer woes - blank screen after lilo (http://www.linuxquestions.org/questions/slackware-14/slackware64-13-1-nvidia-framebuffer-woes-blank-screen-after-lilo-813232/)

ahmadj 06-09-2010 06:42 PM

Slackware64 13.1 Nvidia framebuffer woes - blank screen after lilo
 
preamble
Just upgraded my system from 13.0 to 13.1

Most things went pretty smoothly, but I tried 'startx' before the post-upgrade/config reboot and the system hung - "time to upgrade my video drivers", I thought. Upgraded to Nvidia 195.36.15*. X works perfectly, and a modprobe shows the 'nvidia' module loaded. So far so good.

the problem itself
However, when I try to use any vesa modes in lilo, I get a blank screen after the BIOS check and the system hangs - even toggling numlock on or off won't work... So I can only boot up in text mode. This makes me unhappy, partially because I like penguins, but also because it is an absolute insult to my new (old) monitor.

I thought this could be to do with the nouveau conflicts reported by -current users some days ago, but the respective blacklist file is present so I'm stuck as to what to do...

*I've tried 195.36.15, 195.36.24 and the latest 2xx beta drivers. All exhibit the same behaviour.

EDIT - forgot to post my video card specs. It's an 8500gt w/ 256mb, 128-bit DDR3.

damgar 06-09-2010 10:15 PM

I had some weirdness with my Nvidia gt220 and the huge kernel, but I don't recall at this point what they were. Something about rivafb if I remember correctly. A generic kernel (with initrd of course) ended the wierdness.

ahmadj 06-10-2010 05:33 AM

Ah, initrd... I've never (knowingly) used one before, since slack 11.0... I've always read about it in the docs but never seemed to need it?

Do I need one? I'm using the stock generic kernel.

ahmadj 06-10-2010 06:57 AM

Ah - I'm an idiot..

Turns out I was using huge after all. Updated the symlink to generic (vmlinuz) and now I can get a VESA console :)

However, I get kernel panic shortly after that.. guess I need an initrd?

EDIT: I've noticed there are no smp kernels anymore.. I'd assume the the generic kernel is smp on slack64?

Lufbery 06-10-2010 08:12 AM

Quote:

Originally Posted by ahmadj (Post 3998786)
Ah - I'm an idiot..

Turns out I has using huge after all. Updated the symlink to generic (vmlinuz) and now I can get a VESA console :)

However, I get kernel panic shortly after that.. guess I need an initrd?

Yeah. I'm not at my Slackware computer, but IIRC there are instructions in the /boot directory called readme.initrd (or something like that). Follow those and you're good to go.

Quote:

EDIT: I've noticed there are no smp kernels anymore.. I'd assume the the generic kernel is smp on slack64?
Yes. The 64-bit kernels are smp. :)

damgar 06-10-2010 08:31 AM

There is a script, /usr/share/mkinitrd/mkinitrd_command_generator.sh that has never failed to generate the correct initrd for me. I personally just do
Code:

echo `sh /usr/share/mkinitrd/mkinitrd_command_generator.sh`
### NOTE: Those are backticks. ###

ahmadj 06-10-2010 08:56 AM

Quote:

Originally Posted by damgar (Post 3998893)
There is a script, /usr/share/mkinitrd/mkinitrd_command_generator.sh that has never failed to generate the correct initrd for me. I personally just do
Code:

echo `sh /usr/share/mkinitrd/mkinitrd_command_generator.sh`
### NOTE: Those are backticks. ###

Yeah, found that after a quick google. Trying it out now. Thanks!

EDIT: Well, it failed for me ;] Fails to mount the root partition on boot (/dev/sda2). I think it's to do with my RAID controller, will try adding the respective module to the generated command...

ahmadj 06-10-2010 10:32 AM

This is annoying... Still doesn't work.

Here is the command that mkinitrd_command_generator.sh gave me:

Code:

mkinitrd -c -k 2.6.33.4 -f ext4 -r /dev/sda2 -m usbhid:ehci-hcd:jbd2:mbcache:ext4 -o /boot/initrd.gz
It compiles the initrd without a hitch and Lilo installs with only the usual (incosequential) warnings.

However, boot halts with this:
Code:

mount: mounting /dev/sda2 on /mnt failed: Invalid argument
Then some subsequent errors about the rootfs not being mounted and the system hangs.

My RAID controller is the Intel equivalent of an LSI SCSI320-2e. I tried adding the 'megaraid' driver to the mkinitrd command so it reads
Code:

mkinitrd -c -k 2.6.33.4 -f ext4 -r /dev/sda2 -m usbhid:megaraid:ehci-hcd:jbd2:mbcache:ext4 -o /boot/initrd.gz
but still no luck, same things happens..

Richard Cranium 06-10-2010 10:48 AM

Did you go look in /boot/initrd-tree/lib/modules/2.6.33.4/kernel/ directory tree to see if your modules were actually placed in there? When you cat /boot/initrd-tree/rootdev, does it have the correct value? Does that device exist in /boot/initrd-tree/dev?

(BTW, the default for mkinitrd's "-o" option is /boot/initrd.gz)

ponce 06-10-2010 10:49 AM

nvidia proprietary drivers never played well with framebuffer console for me...

ahmadj 06-10-2010 03:32 PM

Quote:

Originally Posted by Richard Cranium (Post 3999052)
Did you go look in /boot/initrd-tree/lib/modules/2.6.33.4/kernel/ directory tree to see if your modules were actually placed in there? When you cat /boot/initrd-tree/rootdev, does it have the correct value? Does that device exist in /boot/initrd-tree/dev?

(BTW, the default for mkinitrd's "-o" option is /boot/initrd.gz)

Thanks for that, just checked. All seems to be in place.

I'm thinking now that it's not really to do with the RAID controller - wouldn't mount complain about not being able to find the device in that case? Instead it says 'invalid argument'...

Bit of a head-scratcher, this...

ahmadj 06-11-2010 07:14 AM

Well, almost solved now!

It turns out the correct driver was 'megaraid_mm', not 'megaraid'. even with adding this to my initrd, though, I had the same problem. It turns out that the generic kernel + initrd recognizes drives in a different order to the huge kernel!

Here was my drive setup under 13.0 -
sda1 - swap on megaraid
sda2 - / on megaraid
sdb1 - home on megaraid
hda1/2 - windows on ide

under 13.1 huge, that changed to -
sda1 - swap on megaraid
sda2 - / on megaraid
sdb1 - home on megaraid
sdc1/2 - windows on ide

but under 13.1 generic, that becomes -
sda1/2 - windows on ide
and tohers numbered accordingly

So I disabled the IDE drive in BIOS and the system booted all the way to login!

So, is there any way to force the IDE drive to be mounted as sdc instead of sda, even though IDE is compiled in and RAID is a module?

ahmadj 06-11-2010 01:22 PM

The problem was solved by ripping out the Windows HDD. Typical =D

Thanks for all your help guys, I'm marking this solved.

ponce 06-11-2010 01:46 PM

Quote:

Originally Posted by ahmadj (Post 3998343)
the problem itself
However, when I try to use any vesa modes in lilo, I get a blank screen after the BIOS check and the system hangs - even toggling numlock on or off won't work... So I can only boot up in text mode. This makes me unhappy, partially because I like penguins, but also because it is an absolute insult to my new (old) monitor.

I thought this could be to do with the nouveau conflicts reported by -current users some days ago, but the respective blacklist file is present so I'm stuck as to what to do...

*I've tried 195.36.15, 195.36.24 and the latest 2xx beta drivers. All exhibit the same behaviour.

EDIT - forgot to post my video card specs. It's an 8500gt w/ 256mb, 128-bit DDR3.

sorry, i am very curious how you solved this with proprietary drivers.

could be useful to others (me too)...

can you boot with vesa on, startx, and then, exiting x, go back to a fully working fb console?

ahmadj 06-11-2010 03:10 PM

Quote:

Originally Posted by ponce (Post 4000470)
sorry, i am very curious how you solved this with proprietary drivers.

could be useful to others (me too)...

can you boot with vesa on, startx, and then, exiting x, go back to a fully working fb console?

yep...

To be honest it has always 'just worked' for me. It was 13.1 that broke it.

I did encounter some weirdness when trying to figure it out. Here's what made it finally work -
  • Make sure the rivafb, nv etc. drivers are not compiled into your kernel. Stock 13.1 generic kernel is fine.
  • DO NOT add the ehci_hcd or usbhid modules to your initrd. They will result in the behaviour described in OP, for some reason which completely eludes me.

And I am using Nvidia's 195.36.15 drivers, they seem to work best for me on this kernel.


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