framebuffer console problems

framebuffer console problems

[James Miller]

I'm having some problems with the console display under a new Debian
variant (Ubuntu) I'm trying out and would like to ask for advice on
troubleshooting and maybe fixing the problem.  The problem is that I
cannot seem to get the console to display at a high enough resolution.  I
understand that the framebuffer is typically used under Linux to get a
finer console display, which is why I mention framebuffer in the subject
line.  That said, I do not claim to have a very clear understanding of any
of the finer technicalities involved.  Feel free to offer any corrections.

I use a 17" LCD monitor, and under X it looks terrible at anything less
than 1280x1024 resolution.  That's actually the resolution it is
manufactured to operate at, as I understand it.  Using Debian Sid with
this same monitor though using another computer, I entered vga=791 at the
appropriate place in lilo.conf, and this gives me a 1024x768 console.  I'd
like to do the same using another machine with this monitor (MAG monitor,
btw).

On the other machine on which I've loaded Ubuntu, the vga=791 doesn't
really work.  Ubuntu uses Grub as its bootloader, I should mention, but I
don't think that figures into this problem.  Here's what I mean by "it
doesn't really work:" when the booting process reaches the point where
it's supposed to switch to this framebuffer console, the screen goes black
and I get an "out of sync" message (comes from the monitor itself, rather
than the OS) on the screen.  I can see nothing else until gdm comes up to
let me log into X.  Hitting ctrl-alt-Fx after fully booting into X to get
to the virtual terminal produces the same black screen.  I get the same
results trying vga=773, vga=790 and vga=792.  If I enter vga=789 though, I
get the framebuffer display--though at a lower resolution than I'd like
(800x600): all the boot messages appear fine during the boot process using
vga=789 and I can switch between (and see) virtual consoles once booted
into X.  It would seem that maybe my video hardware has a problem
displaying the console at 1024x768, doesn't it?  This is an integrated
Rage ATI pro with either 8 or 12 MB video RAM, btw.

I should mention in closing that, when I tried booting this machine using
Knoppix I got the same result during boot: i.e., where I would expect to
see Knoppix outputting boot messages to a color framebuffer console, I get
a black screen with the out of sync message in the middle.

My aim is not so much to see the boot messages, but just to be able to use
console programs at an acceptable resolution once booted into X.  I found
fbset among Debian packages, which seemed like it might offer further
assistance in accomplishing this aim.  However upon installing and trying
to run it I get a message saying "/dev/fb0: no such file or directory."
Looking at things listed under /dev, I do see an entry for fb0.  So, I got
stuck on that front as well.  Sort of a side issue, but if you have
anything to say on this please do so.

Finally, I append here some /var/log/messages output relevant to the
framebuffer at boot time.  The output seems to me to indicate that all is
well, operating system-wise with the framebuffer:

Oct 16 14:01:02 localhost kernel: VFS: Mounted root (cramfs filesystem) readonly.
Oct 16 14:01:02 localhost kernel: Freeing unused kernel memory: 204k freed
Oct 16 14:01:02 localhost kernel: vesafb: framebuffer at 0xfd000000, mapped to 0xf0821000, size 1536k
Oct 16 14:01:02 localhost kernel: vesafb: mode is 1024x768x8, linelength=1024, pages=9
Oct 16 14:01:02 localhost kernel: vesafb: protected mode interface info at c000:4ac6
Oct 16 14:01:02 localhost kernel: vesafb: scrolling: redraw
Oct 16 14:01:02 localhost kernel: fb0: VESA VGA frame buffer device
Oct 16 14:01:02 localhost kernel: Console: switching to colour frame buffer device 128x48
. . . Goes on to the next step in the boot process . . .

Despite the success I see this output as representing, I nonetheless get
the blank black screen with the out of sync message, and nothing else
appears until the gdm login window comes up.  Is there maybe a way of
specifying sync rate to the framebuffer?  This monitor does work within a
rather limited sync range (hsync 48.38-60.02, vsync 60-75) at 1024x768.

Any advice/input would be appreciated.  That includes pointing me to other
fora where I might ask about this.

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: framebuffer console problems

[James Miller]

Looking over the framebuffer how to again (fairly dated document by now)
I'm beginning to wonder if maybe my video card doesn't require a special
framebuffer module.  There, under section 5.6 "Got an ATI card?" they
mention a particular module--atyfb.  In my initrd, on the other hand, I
appear to have only the generic vesafb module available.  To test this, I
suppose my options are: 1) recompile the kernel with built in atyfb
module; 2) create a new initrd with atyfb in place of vesafb [and 2a)
enter the correct command for loading that module into menu.lst].  Before
going to the trouble of either of those (a big distraction considering my
level of ignorance and the amount of study and experimentation I'd need to
do for either), I'd just like to ask for an opinion about whether anyone
thinks I might be on the right track to resolving my problem with not
being able to get a 1024x768 console by trying one or other of these?
Feedback, please?

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: framebuffer console problems

[Ray Olszewski]

At 02:00 PM 10/22/2004 -0500, James Miller wrote:
>Looking over the framebuffer how to again (fairly dated document by now)
>I'm beginning to wonder if maybe my video card doesn't require a special
>framebuffer module.  There, under section 5.6 "Got an ATI card?" they
>mention a particular module--atyfb.  In my initrd, on the other hand, I
>appear to have only the generic vesafb module available.  To test this, I
>suppose my options are: 1) recompile the kernel with built in atyfb
>module; 2) create a new initrd with atyfb in place of vesafb [and 2a)
>enter the correct command for loading that module into menu.lst].  Before
>going to the trouble of either of those (a big distraction considering my
>level of ignorance and the amount of study and experimentation I'd need to
>do for either), I'd just like to ask for an opinion about whether anyone
>thinks I might be on the right track to resolving my problem with not
>being able to get a 1024x768 console by trying one or other of these?
>Feedback, please?


The vesa framebuffer is pretty generic; almost any *modern* video card 
should be able to drop back to its standards. But I do have older cards, 
like the ancient S3 I use in one of my test systems, that does not support 
the vesa framebuffer. If you have an older ATI card, you might have the 
same problem. I can't find a list of cards that work with vesa, at least 
not one that is less than 4 years old, so I can't check about your card for 
sure. I think that as a general matter, folks in the i86 world don't worry 
much about kernel framebuffers; they are a LOT more important on some other 
srchitectures.

If you have kernel source installed, look there in 
./Documentation/fb/vesafb.txt for some technical discussion of how vesa works.

You said, in your other message, that the display works with Debian-Sid. 
What exactly do you mean? That is, what kernel and version are we talking 
about here? Since one installs Sid (usually) by first installing Woody, 
then doing a dist-upgrade, it is possible that you are actually running 
some Woody kernel ... conceivably even the old 2.2.something that 
theinstaller uses ... unless you've explicitly switched to a Sid kernel.

The Debian installer kernel doesn't use the vesa framebuffer. It uses the 
even more primitive, but as a result more general, vga framebuffer, one 
that does NOT work with X. It is *possible* that you are seeing a situation 
where the vga framebuffer works ... it's hard to imagine a video card on 
which this wouldn't work ... but the card is not vesa comparible.

Your problem description, though, makes me think that your monitor won't 
sync at 1024x768, and that xdm "fixes" the problem simply because it 
switches to a supported 1280x1024 mode. (That *sort* of problem is not 
rare; I've had several monitors that supported 640x480 and 1024x768 in X, 
but made a mess of 800x600.)

You might want to try 1280x1024 in vesa to see if it works 
there.  Depending on color depth, the values for that are:

          8 bit          0x307   =       775
         16 bit          0x31A   =       794
         24 bit          0x31B   =       795

Finally, I'm at a loss as to why fbset is not working for you. But I don't 
have the only system with fbset installed here running at the moment. If 
none of the rest of this helps, post again and I'll try to look at that 
part of it.



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: framebuffer console problems

[Jim Nelson]

James Miller wrote:
> Looking over the framebuffer how to again (fairly dated document by now)
> I'm beginning to wonder if maybe my video card doesn't require a special
> framebuffer module.  There, under section 5.6 "Got an ATI card?" they
> mention a particular module--atyfb.  In my initrd, on the other hand, I
> appear to have only the generic vesafb module available.  To test this, I
> suppose my options are: 1) recompile the kernel with built in atyfb
> module; 2) create a new initrd with atyfb in place of vesafb [and 2a)
> enter the correct command for loading that module into menu.lst].  Before
> going to the trouble of either of those (a big distraction considering my
> level of ignorance and the amount of study and experimentation I'd need to
> do for either), I'd just like to ask for an opinion about whether anyone
> thinks I might be on the right track to resolving my problem with not
> being able to get a 1024x768 console by trying one or other of these?
> Feedback, please?
> 
> James
> 

If you are using a 2.6 kernel (and maybe the 2.4), the kernel module for 
the ATI Rage series of graphics systems is aty128fb, not atyfb.  I've 
had problems with vesafb myself, but with really old hardware (Trident 
TGUI 9660 on an old Thinkpad).  With the 2.6 kernel sources, you can use 
"make deb-pkg" to create a .deb of the custom-compiled kernel.  I'm a 
Red Hat/Slackware man myself, so I really can't help you on the Debian side.

If you are always going to use the framebuffer, go ahead and compile it 
into the kernel.  Saves a bit of trouble, and if you don't need modules 
to load for accessing any of the devices necessary for reaching the init 
scripts, you can probably dump the initrd altogether.  It's crucial on 
distro-provided kernels, since they have to support a broad array of 
equipment, but if this is a one-off kernel for your own personal 
equipment, and you don't need modules (i. e. nforce drivers from Nvidia, 
etc.) to access the boot disk, an initrd is not necessary.  None of my 
systems use them.

Jim
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: framebuffer console problems

[James Miller]

Hello Ray:

On Fri, 22 Oct 2004, Ray Olszewski wrote:

> The vesa framebuffer is pretty generic; almost any *modern* video card
> should be able to drop back to its standards. But I do have older cards,
> like the ancient S3 I use in one of my test systems, that does not support
> the vesa framebuffer. If you have an older ATI card, you might have the
> same problem. I can't find a list of cards that work with vesa, at least
> not one that is less than 4 years old, so I can't check about your card for

Mine should be older than 4 years.  This was originally a P2 350 system
that I've been upgrading.  So the (again, onboard) integrated ati rage pro
in this was probably manufactured right around the 4 year limit.
Originally had 4MB video RAM which I upgraded to 8-12.

> If you have kernel source installed, look there in
> ./Documentation/fb/vesafb.txt for some technical discussion of how vesa works.

No source here, but I might try and take a look at that document somehow
anyway.  Thanks.

> You said, in your other message, that the display works with Debian-Sid.
> What exactly do you mean? That is, what kernel and version are we talking
> about here? Since one installs Sid (usually) by first installing Woody,
> then doing a dist-upgrade, it is possible that you are actually running
> some Woody kernel ... conceivably even the old 2.2.something that
> theinstaller uses ... unless you've explicitly switched to a Sid kernel.

2.6.5 kernel.  I upgraded a few times, but have been with the 2.6.5 kernel
for a couple months now.

> Your problem description, though, makes me think that your monitor won't
> sync at 1024x768, and that xdm "fixes" the problem simply because it
> switches to a supported 1280x1024 mode. (That *sort* of problem is not
> rare; I've had several monitors that supported 640x480 and 1024x768 in X,
> but made a mess of 800x600.)

1024x768 is listed in the manual as one possible resolution, though they
recommend 1280x1024.  I actually had a bit of trouble getting a 1280x1024
display on this a little while back (insufficient video memory) and could
only get it to do 1024x768.  So I know it will do 1024x768 under X, though
the crispness of the display leaves things to be desired--to say the
least.

> You might want to try 1280x1024 in vesa to see if it works
> there.  Depending on color depth, the values for that are:
>
>           8 bit          0x307   =       775
>          16 bit          0x31A   =       794
>          24 bit          0x31B   =       795

Ok.  I figured if it would do 800x600 framebuffer but not 1024x768, it
would be pointless to try anything yet finer.  But what do I know?  The
imps that inhabit these things often have totally unexpected tricks up
their sleeves, I've learned :)

> Finally, I'm at a loss as to why fbset is not working for you. But I don't
> have the only system with fbset installed here running at the moment. If
> none of the rest of this helps, post again and I'll try to look at that
> part of it.

I'm at a loss, too.  Meantime, I'll do some more fiddling and spare
you the bulk of the gory details, hopefully.

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: framebuffer console problems

[James Miller]

On Fri, 22 Oct 2004, Jim Nelson wrote:

> If you are using a 2.6 kernel (and maybe the 2.4), the kernel module for
> the ATI Rage series of graphics systems is aty128fb, not atyfb.  I've
> had problems with vesafb myself, but with really old hardware (Trident
> TGUI 9660 on an old Thinkpad).

Thanks for your response, Jim.  Not sure if you recall what sort of card I
mentioned, but it's an older, onboard one with low memory.  According to
an infomrational page I found at
www.sharplabs.com:8668/space/video+boot+arguments , I should be using the
atyfb module (and they do list the aty128fb there for other ATI Rage
models).  So, do you still think I"m using the wrong module?  I really
don't know.  I consider myself a total neophyte at this

> If you are always going to use the framebuffer, go ahead and compile it
> into the kernel.  Saves a bit of trouble, and if you don't need modules
> to load for accessing any of the devices necessary for reaching the init
> scripts, you can probably dump the initrd altogether.  It's crucial on
> distro-provided kernels, since they have to support a broad array of
> equipment, but if this is a one-off kernel for your own personal
> equipment, and you don't need modules (i. e. nforce drivers from Nvidia,
> etc.) to access the boot disk, an initrd is not necessary.  None of my
> systems use them.

Yes, I have in mind to compile myself a kernel at some point.  Just trying
to defer it until I have some more basic problems solved.  But they seem
to appear at least as fast as I can solve them :).

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: framebuffer console problems

[James Miller]

On Fri, 22 Oct 2004, Ray Olszewski wrote:

> You might want to try 1280x1024 in vesa to see if it works
> there.  Depending on color depth, the values for that are:
>
>           8 bit          0x307   =       775
>          16 bit          0x31A   =       794
>          24 bit          0x31B   =       795

vga=775 results in the same blank black screen with "vga mode not
support(ed)" in the middle (I made a mistake earlier and said the message
said "out of sync"--sorry).  Similar results when I try ctrl-alt-Fx to go
to a virtual terminal.  Seems not worth trying the others.

> Finally, I'm at a loss as to why fbset is not working for you. But I don't
> have the only system with fbset installed here running at the moment. If
> none of the rest of this helps, post again and I'll try to look at that
> part of it.

I decided to take some additinal time out of my writing schedule and read
the mkinitrd manpage.  Decided it wouldn't be so hard to make an initrd
with this atyfb module in it, so I did.  Pointed the initrd.img symlink
under / to it.  But it seemed to make no difference using the vga=xxx
arguments in menu.lst.  Still the same blank black screen with "vga mode
not support(ed)."  Then I tried entering atyfb into /etc/modules.  While
this didn't help the boot screen display--it remained the same as with
other settings I've tried apart from vga=789 (the one that actually works,
though not giving a fine enough resolution)--it did cause fbset to work.
Or at least it doesn't return error messages about /dev/fb0: no such file
or directory.  Rather, it gives the resolution setting, sync rates and so
forth.  I don't really feel any closer to a solution as a result, though.

I should probably mention that the "video mode not support(ed)" message
has a red strip across the bottom in which are some numerical values and
letters.  I think it's horizontal and vertical sync.  For example, when I
try vga=773, that red strip has H 35.4 V 86.5.  If those are sync values
the video is trying to use, then the display is, indeed, outside the sync
range of the monitor.  At 1024x768 the manual says the sync values can be
H 48.36 V 60; H 56.48 V 70.1; and H 60.02 V 75.

Puzzled, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: framebuffer console problems

[Jim Nelson]

James Miller wrote:
> On Fri, 22 Oct 2004, Jim Nelson wrote:
> 
> 
>>If you are using a 2.6 kernel (and maybe the 2.4), the kernel module for
>>the ATI Rage series of graphics systems is aty128fb, not atyfb.  I've
>>had problems with vesafb myself, but with really old hardware (Trident
>>TGUI 9660 on an old Thinkpad).
> 
> 
> Thanks for your response, Jim.  Not sure if you recall what sort of card I
> mentioned, but it's an older, onboard one with low memory.  According to
> an infomrational page I found at
> www.sharplabs.com:8668/space/video+boot+arguments , I should be using the
> atyfb module (and they do list the aty128fb there for other ATI Rage
> models).  So, do you still think I"m using the wrong module?  I really
> don't know.  I consider myself a total neophyte at this
> 
> 

Heh, my bad.  In the kernel configuration, atyfb is listed as belonging 
to the Mach64 family, and a quick peruse of 
drivers/video/aty/atyfb_base.c listed the early Rage cards.  Didn't 
realize the Rage and Rage 128 were that different.




-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: framebuffer console problems

[James Miller]

The framebuffer how to documentation actually gives two lilo arguments for
the ati cards: vga=791 ("to make the display sane" as they say) and
video=atyfb:1024x768@75 after the "append" argument.  They presume you've
compiled the atyfb module into your kernel (which I haven't, though I made
an initrd with that module in it).  I haven't quite understood a couple of
things--one being how to adapt the lilo stuff to grub.  I see no "append"
argument in my grub file, nor can I find much on the web about how lilo
arguments translate to grub ones.  Overall the Grub documentation stinks:
I've managed to turn up nearly nothing on the various possible video= vga=
arguments and variants, how to use them and what they do.  The man page is
kind of worthless.  Plenty of folks mention in passing such lines from
their menu.lst files, but there's not alot of consistency.  The other
thing that's confusing me is what the relation between vga= and video= is:
are they two separate commands that don't interfere with one another or
are they mututally exclusive?  The lilo.conf example given in the
framebuffer how to seems to indicate that they are separate and do
different things, not being mutually exclusive.  When I've tried vga=791
and video=atyfb:1024x768 together in my menu.lst (vga= first) though, I
see in /var/log/messages that the atyfb module doesn't load and get
connected with my video hardware.  When I leave out vga= though, the
module does load and get assigned to the hardware.  But an error appears
there about not being able to initialize vesafb0.  So, can anyone help me
figure out the relation between these two?  Do I need them both, and in
some particular order?  Or is one or the other going to work for me?

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

framebuffer console problems: not enough video RAM?

[James Miller]

Latest on this problem is that I'm using only the video=atyfb:102x768-8@75
argument (no vga=xxx argument) in menu.lst.  During the boot process the
screen goes black for a time--with just a cursor at the very bottom, which
starts scooting back and forth horizontally--then comes back just as it
was at a 640x480 resolution.  Boot process continues and gdm fires up.  In
all this fiddling around, I've somehow gotten fbset to work--maybe by
adding atyfb to /etc/modules.  When I run fbset (no options) it tells me
the console is set to 640x480-60.  Trying to reset it to 1024x768-75--or
any other of the 1024x768 or 1280x1024 settings I've tried--makes the
console go black and the "vga mode not support(ed)" message appear on it.
Reading some further info on the web, I decided to try issuing some
resolution setting options separately with fbset--i.e., specifying just
the V or H resolutions.  yres at 768 "works" although the screen goes
blank.  When I try to set xres at 1024, I get an IOCTL error though.  When
I check dmesg output afterwards, I see "kernel: not enough video memory."
Is my problem therefore--with atyfb just as with vesafb--not enough video
memory to do 1024x768?  I would have guessed 8MB would suffice, but that's
just a layman's conjecture.  I actually have 12MB--added an 8MB SGRAM
module where a 4MB one was supposed to go--but BIOS seems only to see 8
and that's what dmesg reports too.  So, is this the inglorious end of all
this researching and tweaking?  Feedback appreciated.

James

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: framebuffer console problems: not enough video RAM?

[Ray Olszewski]

At 03:06 PM 10/23/2004 -0500, James Miller wrote:
>Latest on this problem is that I'm using only the video=atyfb:102x768-8@75
>argument (no vga=xxx argument) in menu.lst.  During the boot process the
>screen goes black for a time--with just a cursor at the very bottom, which
>starts scooting back and forth horizontally--then comes back just as it
>was at a 640x480 resolution.  Boot process continues and gdm fires up.  In
>all this fiddling around, I've somehow gotten fbset to work--maybe by
>adding atyfb to /etc/modules.  When I run fbset (no options) it tells me
>the console is set to 640x480-60.  Trying to reset it to 1024x768-75--or
>any other of the 1024x768 or 1280x1024 settings I've tried--makes the
>console go black and the "vga mode not support(ed)" message appear on it.
>Reading some further info on the web, I decided to try issuing some
>resolution setting options separately with fbset--i.e., specifying just
>the V or H resolutions.  yres at 768 "works" although the screen goes
>blank.  When I try to set xres at 1024, I get an IOCTL error though.  When
>I check dmesg output afterwards, I see "kernel: not enough video memory."
>Is my problem therefore--with atyfb just as with vesafb--not enough video
>memory to do 1024x768?  I would have guessed 8MB would suffice, but that's
>just a layman's conjecture.  I actually have 12MB--added an 8MB SGRAM
>module where a 4MB one was supposed to go--but BIOS seems only to see 8
>and that's what dmesg reports too.  So, is this the inglorious end of all
>this researching and tweaking?  Feedback appreciated.

First question: do you KNOW that your LCD display will support a refresh 
rate of 75? I'm not that familiar with LCDs myself, but the ones I am 
familiar with have fixed refresh rates ... if it works at 60, it will not 
work at 75. Not a driver issue, a hardware issue. So check this. See if 
1024x768x8@60, for example, wll work for you.

To a close approximation, figuring out the video RAM needed for a 
particular resolution is just math. (At least for 2D stuff -- the 3D stuff 
used mostly for games it trickier.)  1024x768 = 789,504 . Multiply that by 
the bit depth of the color setting, divided by 8 to do it in bytes, and you 
get ... for 24-bit color, say ... 2,368,512 bytes. This is why even 
ancient, 4 MB video cards can usually support X displays of 1024x768 at 
24-bit color.

Even 1280x1024x24 bits comes out to only 3,932,160 bytes ... easy for a 
card with "8-12MB" on it.

But i'm starting to wonder if we are both using the same terms for bits and 
bytes. I (and most people, I think)  use b=bit, B=byte. So when you write 
"8-12 MB" I read it as megabytes. If I'm wrong, that would explain a lot.

When you were trying vesafb, it was reporting:

>Oct 16 14:01:02 localhost kernel: vesafb: framebuffer at 0xfd000000, 
>mapped to 0xf0821000, size 1536k
>Oct 16 14:01:02 localhost kernel: vesafb: mode is 1024x768x8, 
>linelength=1024, pages=9

now multiplying 1536k by 8 gets 12,280, which is about 12 MB 
(inconsistencies between use of 1000 and 1024 for "1K", which always seem 
to turn up in these calculations, easily explain any discrepancy).

But all of this is, in the end, just rambling on. Please follow up to clear 
up the bits/bytes issue, and post whatever dmesg is reporting about the ati 
framebuffer.

Also please be more specific about:

1. What is issuing the "vga mode not support(ed)" message? The Linux kernel 
or the LCD panel's own BIOS?

2. Exactly what mode are you trying to set? "video=atyfb:102x768-8@75" 
obviously contains a typo (probably it should read 1024 instead of 102)?

3. Does "video=atyfb:1024x768-8@60" work as a setting? If not, how does it 
fail?

4. What is the context (the complete line, and any related nearby lines) of 
the dmesg report "kernel: not enough video memory." that you refer to?

5. Please be complete and exact about the modes you are trying. When you 
write "Trying to reset it to 1024x768-75--or any other of the 1024x768 or 
1280x1024 settings I've tried", you aren't using standard mode terminology 
... that would be something like "1024x768-8@75" ... either you are trying 
to specify invalid color depths by using the color-depth portion of the 
setting to specify the refresh rate, or you are leaving the color depth out 
of what you are telling us. Probably the second, but since the color depth 
is relevant to video memory, you have to report it in this context.

6. Finally ... you probably have mentioned this before, but could you 
identify as exactly as you can the video card that's involved here?



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: framebuffer console problems: not enough video RAM?

[Ray Olszewski]

At 03:06 PM 10/23/2004 -0500, James Miller wrote:
>Latest on this problem is that I'm using only the video=atyfb:102x768-8@75
>argument (no vga=xxx argument) in menu.lst.  During the boot process the
>screen goes black for a time--with just a cursor at the very bottom, which
>starts scooting back and forth horizontally--then comes back just as it
>was at a 640x480 resolution.  Boot process continues and gdm fires up.  In
>all this fiddling around, I've somehow gotten fbset to work--maybe by
>adding atyfb to /etc/modules.  When I run fbset (no options) it tells me
>the console is set to 640x480-60.  Trying to reset it to 1024x768-75--or
>any other of the 1024x768 or 1280x1024 settings I've tried--makes the
>console go black and the "vga mode not support(ed)" message appear on it.
>Reading some further info on the web, I decided to try issuing some
>resolution setting options separately with fbset--i.e., specifying just
>the V or H resolutions.  yres at 768 "works" although the screen goes
>blank.  When I try to set xres at 1024, I get an IOCTL error though.  When
>I check dmesg output afterwards, I see "kernel: not enough video memory."
>Is my problem therefore--with atyfb just as with vesafb--not enough video
>memory to do 1024x768?  I would have guessed 8MB would suffice, but that's
>just a layman's conjecture.  I actually have 12MB--added an 8MB SGRAM
>module where a 4MB one was supposed to go--but BIOS seems only to see 8
>and that's what dmesg reports too.  So, is this the inglorious end of all
>this researching and tweaking?  Feedback appreciated.


One more thought: although the spec for setting video mode looks like you 
can put in any old values, in fact you have to use a mode that the kernel 
source understands. I don't have a 2.6.x source tree handy, but 2.4.21 
doesn't include any 1024x758-b@75 choices. The only entries I can find for 
1024x768 in that source are:

         /* 1024x768 @ 87 Hz interlaced, 35.5 kHz hsync *
         /* 1024x768 @ 60 Hz, 48.4 kHz hsync */
         /* 1024x768 @ 70 Hz, 56.5 kHz hsync */
         /* 1024x768 @ 76 Hz, 62.5 kHz hsync */
         /* 1024x768 @ 85 Hz, 70.24 kHz hsync */
         /* 1024x768 @ 100Hz, 80.21 kHz hsync */

So if your LCD panel will support multiple refresh rates, try picking from 
the choices listed above. Or get the kernel source and look in 
./drivers/video/modedb.c to see what is available in your 2.6.x kernel.



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: framebuffer console problems: not enough video RAM?

[James Miller]

Hello Ray:

Good to see you're still with me.  I was beginning if I were the only one
on this list manic enough to spend their weekend trying to work out
framebuffer display issues.  Looks like I'm in good company, though :)

> First question: do you KNOW that your LCD display will support a refresh
> rate of 75? I'm not that familiar with LCDs myself, but the ones I am
> familiar with have fixed refresh rates ... if it works at 60, it will not
> work at 75. Not a driver issue, a hardware issue. So check this. See if
> 1024x768x8@60, for example, wll work for you.

Here's what my LCD (17" MAG 765) manual says about its capabilities at
1024x768:  H 48.36KHz V 60Mz; H 56.48KHz V 70.1Hz; V 60.02KHz V 75Hz.
Those three settings--at the least--are possible for 1024x768 from what I
gather.  I have been understanding that this means that anything between
48.36 and 60.02 will work for horizontal at that resolution and anything
between 60 and 75 for vertical.  But that's just a supposition.  If you
know more about LCD's and what they can and can't do regarding these
figures, please feel free to offer corrections.  I took these from a table
in the manual.

> To a close approximation, figuring out the video RAM needed for a
> particular resolution is just math.

Not one of my strong suits.  Anyway . . .

> used mostly for games it trickier.)  1024x768 = 789,504 . Multiply that by
> the bit depth of the color setting, divided by 8 to do it in bytes, and you
> get ... for 24-bit color, say ... 2,368,512 bytes. This is why even
> ancient, 4 MB video cards can usually support X displays of 1024x768 at
> 24-bit color.
>
> Even 1280x1024x24 bits comes out to only 3,932,160 bytes ... easy for a
> card with "8-12MB" on it.
>
> But i'm starting to wonder if we are both using the same terms for bits and
> bytes. I (and most people, I think)  use b=bit, B=byte. So when you write
> "8-12 MB" I read it as megabytes. If I'm wrong, that would explain a lot.

Megabytes, yes.  The machine came with 4 megabytes of dedicated memory on
this integrated ati rage pro, and I added another 8 megabytes in a slot on
the mobo meant for that prupose.  BIOS does not recognize the full 8
megabytes though, reporting "8MB VIDEO SGRAM" in the relevant section of
the BIOS setup screen (it sees the 4 that were already there and 4 of the
8 I added).  Linux seems to observe the limitation, too.

> >Oct 16 14:01:02 localhost kernel: vesafb: framebuffer at 0xfd000000,
> >mapped to 0xf0821000, size 1536k
> >Oct 16 14:01:02 localhost kernel: vesafb: mode is 1024x768x8,
> >linelength=1024, pages=9
>
> now multiplying 1536k by 8 gets 12,280, which is about 12 MB
> (inconsistencies between use of 1000 and 1024 for "1K", which always seem
> to turn up in these calculations, easily explain any discrepancy).

I'm sorry but you've lost me.  Weren't you just saying that even 24-bit
color at this resolution should be supported by 4 MB video cards? Why is
8-bit color taking almost 3 times more memory here?  Sorry, but I can be a
bit dense sometimes.


> But all of this is, in the end, just rambling on. Please follow up to clear
> up the bits/bytes issue, and post whatever dmesg is reporting about the ati
> framebuffer.

Here's a selection of stuff from /var/log/messages--with a bit of
surrounding context to help in orientation--that seems relevant to me.
Sorry about the reformatting.  I've inserted breaks where sections of
dmesg output have been skipped, as should be apparent.

------------------------------------
Oct 23 14:49:44 localhost kernel: Built 1 zonelists
Oct 23 14:49:44 localhost kernel: Kernel command line:
root=/dev/hda2 video=atyfb:1024x768-8@60 ro quiet splash
Oct 23 14:49:44 localhost kernel: Local APIC disabled by
BIOS -- reenabling.
-------------------------------------
Oct 23 14:49:44 localhost kernel: Freeing unused kernel
memory: 140k freed
Oct 23 14:49:44 localhost kernel: vesafb: probe of vesafb0
failed with error -6
Oct 23 14:49:44 localhost kernel: thermal: Unknown symbol
acpi_processor_set_thermal_limit
--------------------------------------
Oct 23 14:49:44 localhost kernel: lp0: using parport0
(interrupt-driven).
Oct 23 14:49:44 localhost kernel: pnp: Device 01:01.00
activated.
Oct 23 14:49:44 localhost kernel: pnp: Device 01:01.02
activated.
Oct 23 14:49:44 localhost kernel: pnp: Device 01:01.03
activated.
Oct 23 14:49:44 localhost kernel: atyfb: 3D RAGE PRO (BGA,
AGP) [0x4742 rev 0x7c] 8M SGRAM, 14.31818 MHz XTAL, 230 MHz
PLL, 100 Mhz MCLK
Oct 23 14:49:44 localhost kernel: fb0: ATY Mach64 frame
buffer device on PCI
Oct 23 14:49:44 localhost kernel: Capability LSM
initialized
Oct 23 14:49:44 localhost kernel: device-mapper:
4.1.0-ioctl (2003-12-10) initialised: dm@uk.sistina.com
----------------------------------------------------

> 1. What is issuing the "vga mode not support(ed)" message? The Linux kernel
> or the LCD panel's own BIOS?

From the LCD panel's BIOS.

> 2. Exactly what mode are you trying to set? "video=atyfb:102x768-8@75"
> obviously contains a typo (probably it should read 1024 instead of 102)?

Yes, I made a mistake, typing 102 for 1024.

> 3. Does "video=atyfb:1024x768-8@60" work as a setting? If not, how does it
> fail?

No, it does not work.  Here is a description of the failure: the boot
messages start up in something like 640x480 resolution, and at a certain
point the screen goes black.  Only a cursor is visible at the bottom of
the screen, and it starts skipping horizontally rapidly.  There is no
"video mode not support(ed)" displayed on the screen, though.  After a bit
of that, the 640x480 text screen comes back and boot text continues to
scroll by til gdm comes up.  I switch to a virtual console and there see a
640x480 text console.  I log in and type "fbset" and it tells me the
console is set at 640x480-60.  There are other figures there as well, but
I don't know how relevant those are.

> 4. What is the context (the complete line, and any related nearby lines) of
> the dmesg report "kernel: not enough video memory." that you refer to?

Here's a bit of output that spans a reboot, as I think you'll see.  Those
showed up in /var/log/messages in response to my trying to set the
resolution by issuing "fbset -xres 1024."

------------------------------------------
Oct 23 14:18:42 localhost kernel: bridge-eth0: already up
Oct 23 14:19:12 localhost gconfd (user-6650): starting
(version 2.8.1), pid 6650 user 'user'
Oct 23 14:19:12 localhost gconfd (user-6650): Resolved
address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a
read-only configuration source at position 0
Oct 23 14:19:12 localhost gconfd (user-6650): Resolved
address "xml:readwrite:/home/user/.gconf" to a writable
configuration source at position 1
Oct 23 14:19:12 localhost gconfd (user-6650): Resolved
address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a
read-only configuration source at position 2
Oct 23 14:19:25 localhost gconfd (user-6650): Resolved
address "xml:readwrite:/home/user/.gconf" to a writable
configuration source at position 0
Oct 23 14:38:25 localhost -- MARK --
Oct 23 14:39:48 localhost kernel: not enough video RAM
Oct 23 14:43:04 localhost kernel: not enough video RAM
Oct 23 14:44:15 localhost kernel: not enough video RAM
Oct 23 14:47:56 localhost gconfd (user-6650): Exiting
Oct 23 14:47:56 localhost gconfd (user-7375): starting
(version 2.8.1), pid 7375 user 'user'
---------------------------------------------------

> 5. Please be complete and exact about the modes you are trying. When you
> write "Trying to reset it to 1024x768-75--or any other of the 1024x768 or
> 1280x1024 settings I've tried", you aren't using standard mode terminology
> ... that would be something like "1024x768-8@75" ... either you are trying
> to specify invalid color depths by using the color-depth portion of the
> setting to specify the refresh rate, or you are leaving the color depth out
> of what you are telling us. Probably the second, but since the color depth
> is relevant to video memory, you have to report it in this context.

Yes, good point.  I've been inconsistent in how I use terminology, as well
as in entering modes into menu.lst.  I have not yet found out where the
form these resolution arguments should take is documented.  Do you know?
I've consulted the web, and the things people list as arguments for video=
vary somewhat.  I wish I could find the definitive source that tells this,
but so far I've concluded there is not one.  Feel free to disprove my
working hypothesis.  Here is a selection of the various 1024x768 arguments
I've given to video= :

video=atyfb:vmode:1024x768@75,cmode:8
video=atyfb:1024x768
video=atyfb:1024x768-70
video=atyfb:1024x768-75
video=atyfb:1024x768-8@75
video=atyfb:1024x768-8@60

I also tried some 800x600 ones that I'll leave out for now.

> 6. Finally ... you probably have mentioned this before, but could you
> identify as exactly as you can the video card that's involved here?

From the manual: video type - integrated ATI Rage Pro (AGP 2X) graphics;
video memory - 4 MB standard (upgradable to 8 MB) SGRAM.

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: framebuffer console problems: not enough video RAM?

[James Miller]

Hello Ray:

On Sat, 23 Oct 2004, Ray Olszewski wrote:

> One more thought: although the spec for setting video mode looks like you
> can put in any old values, in fact you have to use a mode that the kernel
> source understands. I don't have a 2.6.x source tree handy, but 2.4.21
> doesn't include any 1024x758-b@75 choices. The only entries I can find for
> 1024x768 in that source are:
>
>          /* 1024x768 @ 87 Hz interlaced, 35.5 kHz hsync *
>          /* 1024x768 @ 60 Hz, 48.4 kHz hsync */
>          /* 1024x768 @ 70 Hz, 56.5 kHz hsync */
>          /* 1024x768 @ 76 Hz, 62.5 kHz hsync */
>          /* 1024x768 @ 85 Hz, 70.24 kHz hsync */
>          /* 1024x768 @ 100Hz, 80.21 kHz hsync */
>
> So if your LCD panel will support multiple refresh rates, try picking from
> the choices listed above. Or get the kernel source and look in
> ./drivers/video/modedb.c to see what is available in your 2.6.x kernel.

I think I already tried 1024x768 @ 60 Hz and 1024x768 @ 70 Hz--unless I
entered the video= argument wrong.  That remains a possibility, but until
I find out how to list them right, I can't say for sure.

On whether my monitor supports multiple refresh rates.  This excerpt from
the manual seems relevant, doesn't it? "1.2 Features a. Multi-scanning at
horizontal frequencies of 31KHz to 64KHz and vertical frequencies of 60Hz
to 75Hz."

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: framebuffer console problems: not enough video RAM?

[Ray Olszewski]

Editing quite a bit, since I'm responding only to a few specifics.

At 10:16 PM 10/23/2004 -0500, James Miller wrote:
>Hello Ray:
>
>Good to see you're still with me.  I was beginning if I were the only one
>on this list manic enough to spend their weekend trying to work out
>framebuffer display issues.  Looks like I'm in good company, though :)

It's a side effect of working from a home office. Weekday and weekend are 
not as distinct this way.

Anyway, you got me hooked. I'm curious now how this will come out ... sorta 
like reading a murder mystery or doing a crossword.

>Megabytes, yes.  The machine came with 4 megabytes of dedicated memory on
>this integrated ati rage pro, and I added another 8 megabytes in a slot on
>the mobo meant for that prupose.  BIOS does not recognize the full 8
>megabytes though, reporting "8MB VIDEO SGRAM" in the relevant section of
>the BIOS setup screen (it sees the 4 that were already there and 4 of the
>8 I added).  Linux seems to observe the limitation, too.

The card description you list at the end of this message says the card 
*itself* supports only up to 8 MB. The docs I found on the Web are 
consistent with this. That explains your result here, I think.

On that score ... just a wild, blue-sky thought here ... maybe your trying 
to use an 8 MB SGRAM on a card that only supports 4 MB is introducing a 
problem. Does anything improve if you remove this module and use only the 
onboard 4 MB?

> > 3. Does "video=atyfb:1024x768-8@60" work as a setting? If not, how does it
> > fail?
>
>No, it does not work.  Here is a description of the failure: the boot
>messages start up in something like 640x480 resolution, and at a certain
>point the screen goes black.  Only a cursor is visible at the bottom of
>the screen, and it starts skipping horizontally rapidly.  There is no
>"video mode not support(ed)" displayed on the screen, though.

This probably means the framebuffer is searching for a workable mode.

>  After a bit
>of that, the 640x480 text screen comes back and boot text continues to
>scroll by til gdm comes up.  I switch to a virtual console and there see a
>640x480 text console.  I log in and type "fbset" and it tells me the
>console is set at 640x480-60.  There are other figures there as well, but
>I don't know how relevant those are.

Neither do I if I don't see them. Inconvenienrly, I don't have a 
framebuffer system runnign here at the moment (and the only one I even have 
on site is not an i86 platform, limiting its usefulness to this exercise).


> > 4. What is the context (the complete line, and any related nearby lines) of
> > the dmesg report "kernel: not enough video memory." that you refer to?
>
>Here's a bit of output that spans a reboot, as I think you'll see.  Those
>showed up in /var/log/messages in response to my trying to set the
>resolution by issuing "fbset -xres 1024."
>
>------------------------------------------
>Oct 23 14:18:42 localhost kernel: bridge-eth0: already up
>Oct 23 14:19:12 localhost gconfd (user-6650): starting
>(version 2.8.1), pid 6650 user 'user'
>Oct 23 14:19:12 localhost gconfd (user-6650): Resolved
>address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a
>read-only configuration source at position 0
>Oct 23 14:19:12 localhost gconfd (user-6650): Resolved
>address "xml:readwrite:/home/user/.gconf" to a writable
>configuration source at position 1
>Oct 23 14:19:12 localhost gconfd (user-6650): Resolved
>address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a
>read-only configuration source at position 2
>Oct 23 14:19:25 localhost gconfd (user-6650): Resolved
>address "xml:readwrite:/home/user/.gconf" to a writable
>configuration source at position 0
>Oct 23 14:38:25 localhost -- MARK --
>Oct 23 14:39:48 localhost kernel: not enough video RAM
>Oct 23 14:43:04 localhost kernel: not enough video RAM
>Oct 23 14:44:15 localhost kernel: not enough video RAM
>Oct 23 14:47:56 localhost gconfd (user-6650): Exiting
>Oct 23 14:47:56 localhost gconfd (user-7375): starting
>(version 2.8.1), pid 7375 user 'user'
>---------------------------------------------------
>
> > 5. Please be complete and exact about the modes you are trying. When you
> > write "Trying to reset it to 1024x768-75--or any other of the 1024x768 or
> > 1280x1024 settings I've tried", you aren't using standard mode terminology
> > ... that would be something like "1024x768-8@75" ... either you are trying
> > to specify invalid color depths by using the color-depth portion of the
> > setting to specify the refresh rate, or you are leaving the color depth out
> > of what you are telling us. Probably the second, but since the color depth
> > is relevant to video memory, you have to report it in this context.
>
>Yes, good point.  I've been inconsistent in how I use terminology, as well
>as in entering modes into menu.lst.  I have not yet found out where the
>form these resolution arguments should take is documented.  Do you know?
>I've consulted the web, and the things people list as arguments for video=
>vary somewhat.  I wish I could find the definitive source that tells this,
>but so far I've concluded there is not one.  Feel free to disprove my
>working hypothesis.

The problem you have is that the kernel boot parameters and fbset use 
different notations. Your descriptions mix the two.

For the right form for lilo (or in your case grub) arguments, try the 
kernel source. (If you don't have enough room for the source tree, at least 
install the kernel-doc Debian package for your kernel.) I've been 
consulting the various docs in ./Documentation/fb/, and the actual source 
in ./drivers/video/ . From the first, I get (among other things) this:

"To specify a video mode at bootup, use the following boot options:
     video=<driver>:<xres>x<yres>[-<bpp>][@refresh]

where <driver> is a name from the table below." (atyfb is listed in this 
table; so is aty128fb.)

Short of the actual source that parses this sfuff, that's about as 
definitive as you get. Hence my exact suggestion above.

fbset, according to its man page, doesn't let you specify color depth ... 
it wants the format

         <xres>x<yres>-<refresh>

for example

         1024x768-60 .

Specifically, you might see if

         fbset -a 1024x768-60  (or -75)

works any better than what you have been trying.

[...]
> >From the manual: video type - integrated ATI Rage Pro (AGP 2X) graphics;
>video memory - 4 MB standard (upgradable to 8 MB) SGRAM.

This card name does not *quite* match anything in the Hardware 
Compabibility HowTo. What X driver does it use? (Look in 
/etc/X11/XF86Config-4, under "Device", for the Driver entry.) If it uses 
ati, then you are probably treating it correctly. If it uses r128, then you 
should try the ati128fb framebuffer instead of atyfb.



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: framebuffer console problems: not enough video RAM?

[James Miller]

On Sat, 23 Oct 2004, Ray Olszewski wrote:

> On that score ... just a wild, blue-sky thought here ... maybe your trying
> to use an 8 MB SGRAM on a card that only supports 4 MB is introducing a
> problem. Does anything improve if you remove this module and use only the
> onboard 4 MB?

Well, if I do that I won't get my 1280x1024 display under X.  I upgraded
the video memory on this especially because the 4MB that came with it
would not do X at the proper resolution on this monitor.  And it does the
job.  As soon as I put that 8MB chip in there, copied over my XF86Config-4
from the other machine that was using this same monitor, it booted into X
like a champ (instead of that wimpy 1024x768 X display it used to give
with only 4MB).  Much as I'd like to see what effect that would have on
this framebuffer failure, I'm reluctant . . .

> For the right form for lilo (or in your case grub) arguments, try the
> kernel source. (If you don't have enough room for the source tree, at least
> install the kernel-doc Debian package for your kernel.) I've been
> consulting the various docs in ./Documentation/fb/, and the actual source
> in ./drivers/video/ . From the first, I get (among other things) this:
>
> "To specify a video mode at bootup, use the following boot options:
>      video=<driver>:<xres>x<yres>[-<bpp>][@refresh]
>
> where <driver> is a name from the table below." (atyfb is listed in this
> table; so is aty128fb.)
>
> Short of the actual source that parses this sfuff, that's about as
> definitive as you get. Hence my exact suggestion above.

Thanks for that pointer.  I thought it should be somewhere.

> This card name does not *quite* match anything in the Hardware
> Compabibility HowTo. What X driver does it use? (Look in
> /etc/X11/XF86Config-4, under "Device", for the Driver entry.) If it uses
> ati, then you are probably treating it correctly. If it uses r128, then you
> should try the ati128fb framebuffer instead of atyfb.

I have "ati" in that stanza.  Another item I note in XF86Config-4 but
can't tell if it's relevant is that I have; Option "UseFBDev" "true."
Could that have any significance?  I think I've tried it both with
UseFBDev true as well as UseFBDev false and it made no difference.

A final stray thought: don't know if you caught my earlier statement about
entering atyfb in /etc/modules.  I created an initrd that, so far as I can
tell, contains this module.  However when I boot with the video=atyfb:etc,
the module doesn't seem to load.  So I resorted to adding atyfb to
/etc/modules, after which it started loading and showing up in dmesg--such
as in portions I've included in previous messages.  Ideally, I should have
this module compiled into the kernel, I suppose.  But I'm trying to defer
anything like that in hopes that I can see if it even works first (e.g.,
if I have sufficient video RAM to support the resolution I need atyfb
for).

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: framebuffer console problems: not enough video RAM?

[Ray Olszewski]

At 12:45 AM 10/24/2004 -0500, James Miller wrote:
[...]
>A final stray thought: don't know if you caught my earlier statement about
>entering atyfb in /etc/modules.  I created an initrd that, so far as I can
>tell, contains this module.  However when I boot with the video=atyfb:etc,
>the module doesn't seem to load.

No, I missed this before ... or actually, I saw it but didn't follow then 
what you were saying.

initrd doesn't work that way. It loads modules *after* the kernel itself is 
loaded, but *before* the "real" root filesystem is mounted. So it provides 
a way to supply, for example, modules needs to mount disk drives to the 
kernel before the kernel actuallt has to mount the drive. (You could, for 
instance, make the ide stuff modules this way.)

I believe initrd module loading does *not* work with kernel arguments of 
the sort you are using. Instead, those arguments need the relevant drivers 
to be in the kernel itself. As a consequence, and since we (or I, at least) 
don't know what is compiled in tht kernel you are using, it is hard to 
guess how the kernel is trying to deal with the bootline agrument you are 
passing it.

The way to do your approach is to use /etc/modules to load a framebuffer, 
then use fbset (which you can put in an init script) to do the mode 
selection. The way you are actually doing it, from a console, should be an 
acceptable equivalent.

I do wonder, though, if trying to change framebuffer settings *after* X is 
already using the framebuffer is introducing a problem. You might try 
preventing X from loading (remove the symlink to /etc/init.d/xdm from your 
default runlevel directory) and see if you can modify framebuffer settings 
any more readily then.

>So I resorted to adding atyfb to
>/etc/modules,

Which one? The one on the root filesystem, or the one in the initrd image?

Probably the second. In any case, it's being installed too late for 
bootline parameters to affect it. That's why you need to use fbset.

(Now, I wonder if the kernel itself is still trying to use vesafb, or maybe 
even vgafb ... that's the trouble with using precompiled kernels, the need 
to guess about what's in them ... during the init sequence, before xdm 
comes on, do you get the modified display with the pengiun at the top? If 
so, this is a sure indication that it is using *some* framebuffer at that 
point. And if X is set up with Option "UseFBDev" "true.", it is looking for 
a framebuffer when it loads )

>after which it started loading and showing up in dmesg--such
>as in portions I've included in previous messages.  Ideally, I should have
>this module compiled into the kernel, I suppose.  But I'm trying to defer
>anything like that in hopes that I can see if it even works first (e.g.,
>if I have sufficient video RAM to support the resolution I need atyfb
>for).





-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: framebuffer console problems: not enough video RAM?

[James Miller]

Hello Ray:

On Sun, 24 Oct 2004, Ray Olszewski wrote:

> initrd doesn't work that way. It loads modules *after* the kernel itself is
> loaded, but *before* the "real" root filesystem is mounted. So it provides
> a way to supply, for example, modules needs to mount disk drives to the
> kernel before the kernel actuallt has to mount the drive. (You could, for
> instance, make the ide stuff modules this way.)

Ok.  Thanks for filling in some detail on that.

> I do wonder, though, if trying to change framebuffer settings *after* X is
> already using the framebuffer is introducing a problem. You might try
> preventing X from loading (remove the symlink to /etc/init.d/xdm from your
> default runlevel directory) and see if you can modify framebuffer settings
> any more readily then.

I actually use gdm, so I think I would just replace xdm with gdm in the
example you've given.  But I don't understand about "X is already using
the framebuffer," though.  I've been thinking of X and framebuffer as 2
different things.  Am I wrong about that?  And are you saying, even if X
doesn't load, I would probably still get the 640x480-60 console I always
get when I use the video=atyfb:etc argument?  But that if X were not
loaded, I might nonetheless be successful in using fbset to set
resolution/frequency subsequently?  That's what I understand.  I'll give
that a shot.

> >So I resorted to adding atyfb to
> >/etc/modules,
>
> Which one? The one on the root filesystem, or the one in the initrd image?

The root filesystem, actually.

> (Now, I wonder if the kernel itself is still trying to use vesafb, or maybe
> even vgafb ... that's the trouble with using precompiled kernels, the need
> to guess about what's in them ... during the init sequence, before xdm
> comes on, do you get the modified display with the pengiun at the top? If

No.  It's always been just a textmode console up until gdm kicks in--no
cute little penguins.  I'll reiterate that when I tried booting this
system with a Knoppix CD, I couldn't get any text mode output (black
screen with "vga mode not support(ed)") with all kinds of nice colors,
fine resolution and little penguin like I usually get when booting with a
Knoppix CD.  On the kernel: I could provide the config, if that would
help.  Here's a selection from it that may be relevant:

# Graphics support
#
CONFIG_FB=y
CONFIG_FB_CIRRUS=m
CONFIG_FB_PM2=m
CONFIG_FB_PM2_FIFO_DISCONNECT=y
CONFIG_FB_CYBER2000=m
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=m
CONFIG_FB_VESA=m
CONFIG_VIDEO_SELECT=y
CONFIG_FB_HGA=m
# CONFIG_FB_HGA_ACCEL is not set
CONFIG_FB_RIVA=m
CONFIG_FB_RIVA_I2C=y
CONFIG_FB_RIVA_DEBUG=y
CONFIG_FB_I810=m
# CONFIG_FB_I810_GTF is not set
CONFIG_FB_MATROX=m
CONFIG_FB_MATROX_MILLENIUM=y
CONFIG_FB_MATROX_MYSTIQUE=y
CONFIG_FB_MATROX_G450=y
CONFIG_FB_MATROX_G100=y
CONFIG_FB_MATROX_I2C=m
CONFIG_FB_MATROX_MAVEN=m
CONFIG_FB_MATROX_MULTIHEAD=y
CONFIG_FB_RADEON_OLD=m
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
# CONFIG_FB_RADEON_DEBUG is not set
CONFIG_FB_ATY128=m
CONFIG_FB_ATY=m
CONFIG_FB_ATY_CT=y
CONFIG_FB_ATY_GX=y
CONFIG_FB_ATY_XL_INIT=y
CONFIG_FB_SIS=m
CONFIG_FB_SIS_300=y
CONFIG_FB_SIS_315=y
CONFIG_FB_NEOMAGIC=m
CONFIG_FB_KYRO=m
CONFIG_FB_3DFX=m
# CONFIG_FB_3DFX_ACCEL is not set
CONFIG_FB_VOODOO1=m
CONFIG_FB_TRIDENT=m
# CONFIG_FB_TRIDENT_ACCEL is not set
# CONFIG_FB_PM3 is not set
CONFIG_FB_VIRTUAL=m

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_MDA_CONSOLE=m
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=m
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

> so, this is a sure indication that it is using *some* framebuffer at that
> point. And if X is set up with Option "UseFBDev" "true.", it is looking for
> a framebuffer when it loads )

So, no potential problem with that?

In general, I just want to confirm with you whether, in your opinion, my
video hardware should be able to support the resolution I'm after
(1024x768 8-bits)?  I presume since we're continuing this discussion it
seems plausible to you that it will.  I was ready to give up on it after
getting the "not enough video RAM" message in /var/log/messages.  But I'm
now under the impression that more expert opinion than mine holds that my
hardware could, in principle, do what I'm trying to do.  If you're of the
opinion that it's plausible, I'll keep trying various things, perhaps even
a kernel recompile.  If you think my hardware is marginal or have doubts
about whether what I'm doing is feasible in this regard, a different
course of action is dictated.

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

What distributions support dual processors 'out of the box' ?

[chuck gelm]

Howdy:

 I am trying to use an old dual pentium-pro motherboard as a file
server for a local government supported student project.

 The system has dual 200 MHz Pentium-Pro processors.
I am currently attempting to enable SMP in a Slackware v9.1 distribution,
but I am having some difficulty.  Instead, I am hoping to find
a distribution with SMP already enabled.  Are there any?

 Please, may I have some explanation or discussion about the warning
from 'make [old]config about the PentiumPro and SMP:

'Similarly, multiprocessor kernels for the "PPro" architecture may not
work on all Pentium based boards.'

 IOW, will my attempt to enable SMP with this PPro system
probably fail or be very difficult?

Regards, Chuck


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: What distributions support dual processors 'out of the box' ?

[Owen Ford]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

On Mon, 2004-10-25 at 13:43 -0400, chuck gelm wrote:
> Howdy:
>  IOW, will my attempt to enable SMP with this PPro system
> probably fail or be very difficult?

The linux kernel handles the SMP bits and all modern distros that I know
of have all the necessary tools for SMP.  The only ones that might not
have that support would be some of the floppy distros but you can easily
compile a kernel with SMP on any modern distro.

-- 
Owen Ford <oford@arghblech.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: framebuffer console problems: not enough video RAM?

[Stephen Samuel]

For knoppix, try booting with 'vga=normal'  That avoids booting
with framebuffer text. (there are other vga=settings, but I haven't
bothered to learn them).

The VGA  text code for knoppix seems to go for the 'best possible' mode
which can overwhelm the monitor.

James Miller wrote:
> Hello Ray:
>
> No.  It's always been just a textmode console up until gdm kicks in--no
> cute little penguins.  I'll reiterate that when I tried booting this
> system with a Knoppix CD, I couldn't get any text mode output (black
> screen with "vga mode not support(ed)") with all kinds of nice colors,
> fine resolution and little penguin like I usually get when booting with a
> Knoppix CD.  On the kernel: I could provide the config, if that would
> help.  Here's a selection from it that may be relevant:


-- 
Stephen Samuel +1(604)876-0426                samuel@bcgreen.com
		   http://www.bcgreen.com/~samuel/
    Powerful committed communication. Transformation touching
      the jewel within each person and bringing it to light.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs