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

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

[Little, Chris]

I don't know what the warning is, but a recompile and install of your kernel
with SMP enabled should work fine.  The warning sounds as if the kernel that
you build may not necessarily work or advisably be used on other non-pro
systems (ie. III, IV, etc)

-----Original Message-----
From: chuck gelm [mailto:chuck@gelm.net]
Sent: Monday, October 25, 2004 12:44 PM
To: linux-newbie@vger.kernel.org
Subject: What distributions support dual processors 'out of the box' ?


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
-
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' ?

[chuck gelm]

Little, Chris wrote:

>I don't know what the warning is, but a recompile and install of your kernel
>with SMP enabled should work fine.  The warning sounds as if the kernel that
>you build may not necessarily work or advisably be used on other non-pro
>systems (ie. III, IV, etc)
>
>-----Original Message-----
>From: chuck gelm [mailto:chuck@gelm.net]
>Sent: Monday, October 25, 2004 12:44 PM
>To: linux-newbie@vger.kernel.org
>Subject: What distributions support dual processors 'out of the box' ?
>
>
>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
>  
>
Howdy, Chris and Owen:

 I have twice re-compiled the kernel and yet
cat /proc/cpuinfo
displays only 'cpu0'.  :-(

(edit .config to enable SMP, make bzImage modules modules_install install)

 Elsewhere, someone suggested that I look to see if a
VRM (voltage regulator module) is installed on the motherboard.
I'll be returning to configure the system on Wednesday and I
will check to see if there seems to be any missing items.

Thanks, 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

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

[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]

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

[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

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]

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?

[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 --]