Re: Best device for use with OpenWRT/DD-WRT/etc?
On Wed, Jul 9, 2008 at 2:26 PM, H. Kurth Bemis <[EMAIL PROTECTED]> wrote: > Can anyone recommend a system, preferably small in size, as a > replacement for a Cisco router or firewall? As Jarod says, the consumer bitty-boxes generally don't have the CPU horsepower to do the crypto at reasonable speeds. They're optimized for lower-power and low-cost, not high performance. According to their website, Soekris (http://www.soekris.com/) has bitty-boxes which have mini-PCI slots, and they sell mini-PCI crypto coprocessor cards to go in them. I've never touched that stuff, though, and have no idea if that stuff is supported by anything, though. But that's generally how Cisco, et. al., get decent throughput on their bitty-boxes: Low-power CPU plus a dedicated crypto ASIC. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Adding a new drive / fstab
On Wed, Jul 9, 2008 at 11:50 AM, Labitt, Bruce <[EMAIL PROTECTED]> wrote: > ... I would like the drive to be the "home" for my linux image for > my blade server. Use what works for you. Me, I use /mnt for "temporary" mount points. Things like floppies and CDs, flash drives, network filesystems I'm temporarily mounting for whatever reason, that sort of thing. In organizations (companies), I try to build an org-wide directory structure under a top-level name. For example, if I work for Acme Products, I'd have off the root, and structure things under there. If I was in the materials lab at Acme, and I was building a blade server called "darkstar", I might use . If I was hosting multiple system images, or thought I might do so, I might use or something like that. This has the advantage in that the corporate IT resource server can be mounted under , centralized home directories under , the software lab's source code under , or whatever. You get a consistent structure everywhere. That may be total gigantic overkill for what you're doing. Maybe you just want , or . The FHS that V. Alex Brennen references actually states that is for temporary mounts; the location for stuff you're serving out would be under . So maybe or whatever. I would recommend against just , because then when you get your second blade server, confusion occurs. Use unique names. But use what works for you. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: General Procedure to get ATI/DRI card running?
Believe me, I'm almost there. I will give the AMD/ATI binary driver a try next. I would really not want to rebuild my applications all over again. If that fails, well, THEN I'll give the card to someone and buy an nvidia. It would be kind of fun to dabble in gentoo. In my copious spare time. :) -Bruce Ben Scott wrote: > On Wed, Jul 9, 2008 at 4:58 PM, Labitt, Bruce > <[EMAIL PROTECTED]> wrote: > >> Any other solutions available? Second opinion? Anyone? >> > > Return the AMD card, buy an NVidia card, and use the proprietary, > binary-only drivers NVidia provides. They work with CentOS 5.x. > > I'm sure some people won't like this answer, but I call 'em as I see > 'em. NVidia's stuff works, even on the "ancient" (i.e., 18-month-old) > software so many of us are still using. > > -- Ben > ___ > gnhlug-discuss mailing list > gnhlug-discuss@mail.gnhlug.org > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ > > ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: General Procedure to get ATI/DRI card running?
On Wed, Jul 9, 2008 at 4:58 PM, Labitt, Bruce <[EMAIL PROTECTED]> wrote: > Any other solutions available? Second opinion? Anyone? Return the AMD card, buy an NVidia card, and use the proprietary, binary-only drivers NVidia provides. They work with CentOS 5.x. I'm sure some people won't like this answer, but I call 'em as I see 'em. NVidia's stuff works, even on the "ancient" (i.e., 18-month-old) software so many of us are still using. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Please trim quoted text (was: General Procedure)
On Wed, Jul 9, 2008 at 1:30 PM, Labitt, Bruce <[EMAIL PROTECTED]> wrote: > How does one change that? Sorry to be such a noob. [followed by tons of quoted text] People: When sending replies -- especially one-line replies -- please trim the hundreds or thousands of lines of quoted text which add nothing to the context of the message. The server actually started rejecting messages in this thread because they had exceeded the 40 kilobyte message size limit. Thanks. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
RE: General Procedure to get ATI/DRI card running?
My approach is to maintain two types of systems. For applications that I want to keep 'stable", I put them on a headless server that uses robust hardware. For my X display, I use a couple client machines that I wipe and reinstall twice a year with the latest Fedora release. Basically, I reinstalled client A with Fedora 6 when it was released, then reinstalled client B with Fedora 7 when that was released, then client A with Fedora 8, then client B with Fedora 9, etc. If I want newer hardware, I'll buy a new machine, to replace the aging client that's scheduled to be upgraded, a few days before the Fedora release. On Wed, July 9, 2008 5:16 pm, Coleman Kane said: > On Wed, 2008-07-09 at 16:58 -0400, Labitt, Bruce wrote: >> Umm, thanks for your frank assessment. >> >> So which is the lesser of evils - using the AMD/ATI proprietary drivers >> for 3D, or totally rebuilding my system from the ground up? I presume >> that I will still have to mess around to get things going. I've fooled >> around with this a few days now, I don't like wasting my time - I have >> plenty to do. > > Have you tried their proprietary drivers on your current system yet? Do > they work on such an old server? > > You could always move to a Linux distro that has much newer components > to it, and start from there. The reason I posted "slackware" was just > that I've already done that route and felt it would actually be faster > to do than to shoehorn the development-class X server components into > your current system. It will be much cleaner. > > If you were to just go and download all the development code for the > X.org modules and start building them, you would start to run into > compiler problems where some of the X.org headers that you have in > your /usr/include/* need to actually be removed so that they don't > override package-local versions of those headers. I don't have a > verified list of which ones they were but there are a bunch of them. So, > by trial and error you would waste immense time trying to get these > packages built for your system. > > Starting from a fresh, empty base, you are more likely to have a full > working product much quicker. > >> >> If I were to do this from the ground up, which distro to choose? Why >> slackware? Why not Gentoo? I suppose I can have a daily overnight >> update and recompile everything for the morning. >> >> I had originally wanted a relatively stable system. It appears I can't >> get any work done with a stable system :( >> > > If you want to keep a stable system, you won't be able to easily do that > with cutting-edge hardware AND get all the cutting-edge features. This > is even beginning to be the case with Windows nowadays too (and they > have no excuse). > > From my experience, your options are: > - Cutting edge system > - Stable system > > Choose one. :-) > > In my case, I chose the first and use FreeBSD. The "cutting edge" is > "stable enough" for me, but I would never deploy a system like this onto > a bunch of office workstations. I would probably use hardware that is at > least a whole year old, and install FreeBSD 6.2 on them, after verifying > that all of the hardware has an existing track record of working well > under FreeBSD (either by buying a test system first, or researching it > online from someone else who's already bought the hardware). > >> Any other solutions available? Second opinion? Anyone? >> >> Bruce > > Maybe it would be worth your time to investigate using the most recent > development snapshot of the xf86-video-ati driver, from its git repo? It > *might* be more compatible with older X servers, as it is at least that > old. The build/install procedure is pretty similar to what you've > already done with the radeonhd driver from what I can tell. You'll just > want to change the "radeonhd" into "radeon" in your conf file after you > build and install the driver. > >> >> -Original Message- >> From: Coleman Kane [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, July 09, 2008 4:37 PM >> To: Labitt, Bruce >> Cc: Arc Riley; gnhlug-discuss@mail.gnhlug.org >> Subject: RE: General Procedure to get ATI/DRI card running? >> >> On Wed, 2008-07-09 at 16:19 -0400, Labitt, Bruce wrote: >> > Arc led me to believe that I did not have to do that yet. He said >> that >> > the drm did not support radeonhd yet. >> > >> > Believe me, this is more complicated than I had anticipated... :) >> > >> > Here is the logfile >> > >> >> First of all, I can tell just by looking at this log output that you are >> in for a long headache. Your X server is over 2 years old, and won't be >> able to support DRI on the radeonhd. Your X server might not even >> support AIGLX on many of the drivers that will work with its older DRI >> implementation today. >> >> The latest X server is v1.4.1, and you are using v1.1.1. The oldest one >> that will support DRI using radeonhd is v1.4.99.something, from the v1.5 >> snapshots branch in the xorg-server git repository. >> >> Basica
RE: General Procedure to get ATI/DRI card running?
On Wed, 2008-07-09 at 17:16 -0400, Coleman Kane wrote: > On Wed, 2008-07-09 at 16:58 -0400, Labitt, Bruce wrote: > > Umm, thanks for your frank assessment. > > > > So which is the lesser of evils - using the AMD/ATI proprietary drivers > > for 3D, or totally rebuilding my system from the ground up? I presume > > that I will still have to mess around to get things going. I've fooled > > around with this a few days now, I don't like wasting my time - I have > > plenty to do. > > Have you tried their proprietary drivers on your current system yet? Do > they work on such an old server? Uhm, pretty sure nVidia and ATI tend to write their binary drivers with support for the latest Red Hat Enterprise Linux release in mind *before* they worry about it working with the latest upstream kernel. Remember, the ATI proprietary driver is called 'fglrx', as in "FireGL X driver", and FireGL is their high-end workstation line. -- Jarod Wilson [EMAIL PROTECTED] ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
RE: General Procedure to get ATI/DRI card running?
On Wed, 2008-07-09 at 17:29 -0400, Labitt, Bruce wrote: > Hmm, not sure I’m scared of Gentoo – I don’t know enough to be > scared! I’ve used SuSE in the past, it is ok. > > > > How hard is it to set up Gentoo? > > Visit: * http://www.gentoo.org/doc/en/handbook/index.xml Pick your architecture from the first row of the first table, with the description labeled "Latest version, one page per chapter, perfect for online viewing". Go read Chapter 1. If it makes sense to you then that is how easy it will be. > > > __ > From: Arc Riley [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 09, 2008 5:27 PM > To: Labitt, Bruce > Cc: Coleman Kane; gnhlug-discuss@mail.gnhlug.org > Subject: Re: General Procedure to get ATI/DRI card running? > > > > > Everyone I work with who uses the radeonhd drivers uses Gentoo. > > I agree with Coleman's assessment - it was said earlier in this thread > that you'd likely need to upgrade your X server, it really is ancient, > and likely Mesa too. > > The output shows that the radeonhd driver does support your card and > is detecting it, but something else is going wrong down the chain. > Since newer Mesa's have expanded OpenGL support (ie, OpenGL 2.0) some > apps may not even work unless you're running a semi-recent version of > it. > > If Gentoo scares you, the newest OpenSUSE may be your best bet. > > -- Coleman Kane signature.asc Description: This is a digitally signed message part ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: General Procedure to get ATI/DRI card running?
These days it's not hard at all. It has a nice installer. Because Portage is more active than other package systems, people generally hit more blockers/etc and need to resolve conflicts. There's a fairly complete set of instructions on this through the Gentoo Docs project (a wiki), but it takes more grey matter than other distros as you continue to use it, and is why many people are afraid of it. I don't recommend it to people who don't know or are afraid of editing config files. Unlike other distros, we don't really have "versions". My system here was installed 3-4 years ago, and I've got the same set of packages and support as anyone installing fresh. The releases, such as 2008.0, are just up-to-date install releases so you can start out with a mostly updated system. Updating the whole system is as easy as "emerge -auv world", which shows you (v) what it'll upgrade (u) and ask you (a) for confirmation before doing anything else. Unlike other distros you also have MUCH more control over how things are compiled. You can select to turn on features you need, disable things you don't want, etc via USE flags. For some math/sci apps that can be pretty important, where other distros just try to compile for most users. On Wed, Jul 9, 2008 at 5:29 PM, Labitt, Bruce <[EMAIL PROTECTED]> wrote: > Hmm, not sure I'm scared of Gentoo – I don't know enough to be scared! > I've used SuSE in the past, it is ok. > > > > How hard is it to set up Gentoo? > > > -- > > *From:* Arc Riley [mailto:[EMAIL PROTECTED] > *Sent:* Wednesday, July 09, 2008 5:27 PM > *To:* Labitt, Bruce > *Cc:* Coleman Kane; gnhlug-discuss@mail.gnhlug.org > *Subject:* Re: General Procedure to get ATI/DRI card running? > > > > Everyone I work with who uses the radeonhd drivers uses Gentoo. > > I agree with Coleman's assessment - it was said earlier in this thread that > you'd likely need to upgrade your X server, it really is ancient, and likely > Mesa too. > > The output shows that the radeonhd driver does support your card and is > detecting it, but something else is going wrong down the chain. Since newer > Mesa's have expanded OpenGL support (ie, OpenGL 2.0) some apps may not even > work unless you're running a semi-recent version of it. > > If Gentoo scares you, the newest OpenSUSE may be your best bet. > ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
RE: General Procedure to get ATI/DRI card running?
Hmm, not sure I'm scared of Gentoo - I don't know enough to be scared! I've used SuSE in the past, it is ok. How hard is it to set up Gentoo? From: Arc Riley [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2008 5:27 PM To: Labitt, Bruce Cc: Coleman Kane; gnhlug-discuss@mail.gnhlug.org Subject: Re: General Procedure to get ATI/DRI card running? Everyone I work with who uses the radeonhd drivers uses Gentoo. I agree with Coleman's assessment - it was said earlier in this thread that you'd likely need to upgrade your X server, it really is ancient, and likely Mesa too. The output shows that the radeonhd driver does support your card and is detecting it, but something else is going wrong down the chain. Since newer Mesa's have expanded OpenGL support (ie, OpenGL 2.0) some apps may not even work unless you're running a semi-recent version of it. If Gentoo scares you, the newest OpenSUSE may be your best bet. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: General Procedure to get ATI/DRI card running?
Everyone I work with who uses the radeonhd drivers uses Gentoo. I agree with Coleman's assessment - it was said earlier in this thread that you'd likely need to upgrade your X server, it really is ancient, and likely Mesa too. The output shows that the radeonhd driver does support your card and is detecting it, but something else is going wrong down the chain. Since newer Mesa's have expanded OpenGL support (ie, OpenGL 2.0) some apps may not even work unless you're running a semi-recent version of it. If Gentoo scares you, the newest OpenSUSE may be your best bet. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
RE: General Procedure to get ATI/DRI card running?
On Wed, 2008-07-09 at 16:58 -0400, Labitt, Bruce wrote: > Umm, thanks for your frank assessment. > > So which is the lesser of evils - using the AMD/ATI proprietary drivers > for 3D, or totally rebuilding my system from the ground up? I presume > that I will still have to mess around to get things going. I've fooled > around with this a few days now, I don't like wasting my time - I have > plenty to do. Have you tried their proprietary drivers on your current system yet? Do they work on such an old server? You could always move to a Linux distro that has much newer components to it, and start from there. The reason I posted "slackware" was just that I've already done that route and felt it would actually be faster to do than to shoehorn the development-class X server components into your current system. It will be much cleaner. If you were to just go and download all the development code for the X.org modules and start building them, you would start to run into compiler problems where some of the X.org headers that you have in your /usr/include/* need to actually be removed so that they don't override package-local versions of those headers. I don't have a verified list of which ones they were but there are a bunch of them. So, by trial and error you would waste immense time trying to get these packages built for your system. Starting from a fresh, empty base, you are more likely to have a full working product much quicker. > > If I were to do this from the ground up, which distro to choose? Why > slackware? Why not Gentoo? I suppose I can have a daily overnight > update and recompile everything for the morning. > > I had originally wanted a relatively stable system. It appears I can't > get any work done with a stable system :( > If you want to keep a stable system, you won't be able to easily do that with cutting-edge hardware AND get all the cutting-edge features. This is even beginning to be the case with Windows nowadays too (and they have no excuse). From my experience, your options are: - Cutting edge system - Stable system Choose one. :-) In my case, I chose the first and use FreeBSD. The "cutting edge" is "stable enough" for me, but I would never deploy a system like this onto a bunch of office workstations. I would probably use hardware that is at least a whole year old, and install FreeBSD 6.2 on them, after verifying that all of the hardware has an existing track record of working well under FreeBSD (either by buying a test system first, or researching it online from someone else who's already bought the hardware). > Any other solutions available? Second opinion? Anyone? > > Bruce Maybe it would be worth your time to investigate using the most recent development snapshot of the xf86-video-ati driver, from its git repo? It *might* be more compatible with older X servers, as it is at least that old. The build/install procedure is pretty similar to what you've already done with the radeonhd driver from what I can tell. You'll just want to change the "radeonhd" into "radeon" in your conf file after you build and install the driver. > > -Original Message- > From: Coleman Kane [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 09, 2008 4:37 PM > To: Labitt, Bruce > Cc: Arc Riley; gnhlug-discuss@mail.gnhlug.org > Subject: RE: General Procedure to get ATI/DRI card running? > > On Wed, 2008-07-09 at 16:19 -0400, Labitt, Bruce wrote: > > Arc led me to believe that I did not have to do that yet. He said > that > > the drm did not support radeonhd yet. > > > > Believe me, this is more complicated than I had anticipated... :) > > > > Here is the logfile > > > > First of all, I can tell just by looking at this log output that you are > in for a long headache. Your X server is over 2 years old, and won't be > able to support DRI on the radeonhd. Your X server might not even > support AIGLX on many of the drivers that will work with its older DRI > implementation today. > > The latest X server is v1.4.1, and you are using v1.1.1. The oldest one > that will support DRI using radeonhd is v1.4.99.something, from the v1.5 > snapshots branch in the xorg-server git repository. > > Basically, you are trying to use a brand new driver for a brand new > piece of hardware with an ancient installation of X-Windows. If your > distro at least had a v1.4+ X-server, you might be able to get by just > by rebuilding about five modules. > > Likely, you will need to rebuild almost all of X from scratch, and try > to make sure that it doesn't accidentally bring in headers from the old > X installation. > > IOW, to get it working on your system, you are in for a wild ride. It is > probably easier to just install Slackware and start from scratch. > > Furthermore, if you do get all of the latest X stuff, you'll need to > disable 2D acceleration in order to allow 3D acceleration to work on the > latest driver IIRC. > > I strongly suggest you get in touch with the radeonhd mailing
RE: General Procedure to get ATI/DRI card running?
On Wed, 2008-07-09 at 16:58 -0400, Labitt, Bruce wrote: > Umm, thanks for your frank assessment. > > So which is the lesser of evils - using the AMD/ATI proprietary > drivers > for 3D, or totally rebuilding my system from the ground up? I presume > that I will still have to mess around to get things going. I've > fooled > around with this a few days now, I don't like wasting my time - I have > plenty to do. > > If I were to do this from the ground up, which distro to choose? Why > slackware? Why not Gentoo? I suppose I can have a daily overnight > update and recompile everything for the morning. > > I had originally wanted a relatively stable system. It appears I > can't > get any work done with a stable system :( > > Any other solutions available? Second opinion? Anyone? Given that Novell was contracted by AMD to work on the radeonhd driver, you might want to go with the latest openSUSE development code. If you want to go bleeding edge, but stick to something as close to RHEL as possible, Fedora also tracks upstream reasonably closely, and Fedora's development branch does have some radeonhd goodness in it too (currently a 6/30 snap of the radeonhd driver). I'd be surprised if the Ubuntu development branch for 8.10 doesn't have radeonhd support too. -- Jarod Wilson [EMAIL PROTECTED] ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
RE: General Procedure to get ATI/DRI card running?
Umm, thanks for your frank assessment. So which is the lesser of evils - using the AMD/ATI proprietary drivers for 3D, or totally rebuilding my system from the ground up? I presume that I will still have to mess around to get things going. I've fooled around with this a few days now, I don't like wasting my time - I have plenty to do. If I were to do this from the ground up, which distro to choose? Why slackware? Why not Gentoo? I suppose I can have a daily overnight update and recompile everything for the morning. I had originally wanted a relatively stable system. It appears I can't get any work done with a stable system :( Any other solutions available? Second opinion? Anyone? Bruce -Original Message- From: Coleman Kane [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2008 4:37 PM To: Labitt, Bruce Cc: Arc Riley; gnhlug-discuss@mail.gnhlug.org Subject: RE: General Procedure to get ATI/DRI card running? On Wed, 2008-07-09 at 16:19 -0400, Labitt, Bruce wrote: > Arc led me to believe that I did not have to do that yet. He said that > the drm did not support radeonhd yet. > > Believe me, this is more complicated than I had anticipated... :) > > Here is the logfile > First of all, I can tell just by looking at this log output that you are in for a long headache. Your X server is over 2 years old, and won't be able to support DRI on the radeonhd. Your X server might not even support AIGLX on many of the drivers that will work with its older DRI implementation today. The latest X server is v1.4.1, and you are using v1.1.1. The oldest one that will support DRI using radeonhd is v1.4.99.something, from the v1.5 snapshots branch in the xorg-server git repository. Basically, you are trying to use a brand new driver for a brand new piece of hardware with an ancient installation of X-Windows. If your distro at least had a v1.4+ X-server, you might be able to get by just by rebuilding about five modules. Likely, you will need to rebuild almost all of X from scratch, and try to make sure that it doesn't accidentally bring in headers from the old X installation. IOW, to get it working on your system, you are in for a wild ride. It is probably easier to just install Slackware and start from scratch. Furthermore, if you do get all of the latest X stuff, you'll need to disable 2D acceleration in order to allow 3D acceleration to work on the latest driver IIRC. I strongly suggest you get in touch with the radeonhd mailing list as well. > X Window System Version 7.1.1 > Release Date: 12 May 2006 > X Protocol Version 11, Revision 0, Release 7.1.1 > Build Operating System: Linux 2.6.18-8.1.8.el5 x86_64 Red Hat, Inc. > Current Operating System: Linux xxx..xxx 2.6.18-92.1.6.el5xen #1 SMP > Wed Jun 25 12:56:52 EDT 2008 x86_64 > Build Date: 12 June 2008 > Build ID: xorg-x11-server 1.1.1-48.41.el5_2.1 > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Module Loader present > Markers: (--) probed, (**) from config file, (==) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jul 9 15:02:06 2008 ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
RE: General Procedure to get ATI/DRI card running?
On Wed, 2008-07-09 at 16:19 -0400, Labitt, Bruce wrote: > Arc led me to believe that I did not have to do that yet. He said that > the drm did not support radeonhd yet. > > Believe me, this is more complicated than I had anticipated... :) > > Here is the logfile > First of all, I can tell just by looking at this log output that you are in for a long headache. Your X server is over 2 years old, and won't be able to support DRI on the radeonhd. Your X server might not even support AIGLX on many of the drivers that will work with its older DRI implementation today. The latest X server is v1.4.1, and you are using v1.1.1. The oldest one that will support DRI using radeonhd is v1.4.99.something, from the v1.5 snapshots branch in the xorg-server git repository. Basically, you are trying to use a brand new driver for a brand new piece of hardware with an ancient installation of X-Windows. If your distro at least had a v1.4+ X-server, you might be able to get by just by rebuilding about five modules. Likely, you will need to rebuild almost all of X from scratch, and try to make sure that it doesn't accidentally bring in headers from the old X installation. IOW, to get it working on your system, you are in for a wild ride. It is probably easier to just install Slackware and start from scratch. Furthermore, if you do get all of the latest X stuff, you'll need to disable 2D acceleration in order to allow 3D acceleration to work on the latest driver IIRC. I strongly suggest you get in touch with the radeonhd mailing list as well. > X Window System Version 7.1.1 > Release Date: 12 May 2006 > X Protocol Version 11, Revision 0, Release 7.1.1 > Build Operating System: Linux 2.6.18-8.1.8.el5 x86_64 Red Hat, Inc. > Current Operating System: Linux xxx..xxx 2.6.18-92.1.6.el5xen #1 SMP > Wed Jun 25 12:56:52 EDT 2008 x86_64 > Build Date: 12 June 2008 > Build ID: xorg-x11-server 1.1.1-48.41.el5_2.1 > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Module Loader present > Markers: (--) probed, (**) from config file, (==) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jul 9 15:02:06 2008 > (==) Using config file: "/etc/X11/xorg.conf" > (==) ServerLayout "single head configuration" > (**) |-->Screen "Screen0" (0) > (**) | |-->Monitor "" > (**) | |-->Device "Videocard0" > (==) No monitor specified for screen "Screen0". > Using a default monitor configuration. > (**) |-->Input Device "Keyboard0" > (==) |-->Input Device "" > (==) The core pointer device wasn't specified explicitly in the layout. > Using the default mouse configuration. > (==) No FontPath specified. Using compiled-in default. > (==) FontPath set to: > unix/:7100, > built-ins > (==) RgbPath set to "/usr/share/X11/rgb" > (==) ModulePath set to "/usr/lib64/xorg/modules" > (II) Open ACPI successful (/var/run/acpid.socket) > (II) Module ABI versions: > X.Org ANSI C Emulation: 0.3 > X.Org Video Driver: 1.0 > X.Org XInput driver : 0.6 > X.Org Server Extension : 0.3 > X.Org Font Renderer : 0.5 > (II) Loader running on linux > (II) LoadModule: "bitmap" > (II) Loading /usr/lib64/xorg/modules/fonts/libbitmap.so > (II) Module bitmap: vendor="X.Org Foundation" > compiled for 7.1.1, module version = 1.0.0 > Module class: X.Org Font Renderer > ABI class: X.Org Font Renderer, version 0.5 > (II) Loading font Bitmap > (II) LoadModule: "pcidata" > (II) Loading /usr/lib64/xorg/modules/libpcidata.so > (II) Module pcidata: vendor="X.Org Foundation" > compiled for 7.1.1, module version = 1.0.0 > ABI class: X.Org Video Driver, version 1.0 > (++) using VT number 7 > > (II) PCI: PCI scan (all values are in hex) > (II) PCI: 00:00:0: chip 8086,2990 card 1028,01da rev 02 class 06,00,00 > hdr 00 > (II) PCI: 00:01:0: chip 8086,2991 card , rev 02 class 06,04,00 > hdr 01 > (II) PCI: 00:1a:0: chip 8086,2834 card 1028,01da rev 02 class 0c,03,00 > hdr 80 > (II) PCI: 00:1a:1: chip 8086,2835 card 1028,01da rev 02 class 0c,03,00 > hdr 00 > (II) PCI: 00:1a:7: chip 8086,283a card 1028,01da rev 02 class 0c,03,20 > hdr 00 > (II) PCI: 00:1b:0: chip 8086,284b card 1028,01da rev 02 class 04,03,00 > hdr 00 > (II) PCI: 00:1c:0: chip 8086,283f card , rev 02 class 06,04,00 > hdr 81 > (II) PCI: 00:1c:4: chip 8086,2847 card , rev 02 class 06,04,00 > hdr 81 > (II) PCI: 00:1d:0: chip 8086,2830 card 1028,01da rev 02 class 0c,03,00 > hdr 80 > (II) PCI: 00:1d:1: chip 8086,2831 card 1028,01da rev 02 class 0c,03,00 > hdr 00 > (II) PCI: 00:1d:2: chip 8086,2832 card 1028,01da rev 02 class 0c,03,00 > hdr 00 > (II) PCI: 00:1d:7: chip 8086,2836 card 1028,01da rev 02 class 0c,03,20 > hdr 00 > (II) PCI: 00:1e:0: chip 8086,244e card , rev f2 class 06,04,01 > hdr 01 > (II) PCI: 00:
RE: General Procedure to get ATI/DRI card running?
Arc led me to believe that I did not have to do that yet. He said that the drm did not support radeonhd yet. Believe me, this is more complicated than I had anticipated... :) Here is the logfile X Window System Version 7.1.1 Release Date: 12 May 2006 X Protocol Version 11, Revision 0, Release 7.1.1 Build Operating System: Linux 2.6.18-8.1.8.el5 x86_64 Red Hat, Inc. Current Operating System: Linux xxx..xxx 2.6.18-92.1.6.el5xen #1 SMP Wed Jun 25 12:56:52 EDT 2008 x86_64 Build Date: 12 June 2008 Build ID: xorg-x11-server 1.1.1-48.41.el5_2.1 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jul 9 15:02:06 2008 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "single head configuration" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "" (**) | |-->Device "Videocard0" (==) No monitor specified for screen "Screen0". Using a default monitor configuration. (**) |-->Input Device "Keyboard0" (==) |-->Input Device "" (==) The core pointer device wasn't specified explicitly in the layout. Using the default mouse configuration. (==) No FontPath specified. Using compiled-in default. (==) FontPath set to: unix/:7100, built-ins (==) RgbPath set to "/usr/share/X11/rgb" (==) ModulePath set to "/usr/lib64/xorg/modules" (II) Open ACPI successful (/var/run/acpid.socket) (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 1.0 X.Org XInput driver : 0.6 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/lib64/xorg/modules/fonts/libbitmap.so (II) Module bitmap: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/lib64/xorg/modules/libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.0 (++) using VT number 7 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,2990 card 1028,01da rev 02 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,2991 card , rev 02 class 06,04,00 hdr 01 (II) PCI: 00:1a:0: chip 8086,2834 card 1028,01da rev 02 class 0c,03,00 hdr 80 (II) PCI: 00:1a:1: chip 8086,2835 card 1028,01da rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1a:7: chip 8086,283a card 1028,01da rev 02 class 0c,03,20 hdr 00 (II) PCI: 00:1b:0: chip 8086,284b card 1028,01da rev 02 class 04,03,00 hdr 00 (II) PCI: 00:1c:0: chip 8086,283f card , rev 02 class 06,04,00 hdr 81 (II) PCI: 00:1c:4: chip 8086,2847 card , rev 02 class 06,04,00 hdr 81 (II) PCI: 00:1d:0: chip 8086,2830 card 1028,01da rev 02 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2831 card 1028,01da rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,2832 card 1028,01da rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,2836 card 1028,01da rev 02 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,244e card , rev f2 class 06,04,01 hdr 01 (II) PCI: 00:1f:0: chip 8086,2810 card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:1f:2: chip 8086,2820 card 1028,01da rev 02 class 01,01,8f hdr 00 (II) PCI: 00:1f:3: chip 8086,283e card 1028,01da rev 02 class 0c,05,00 hdr 00 (II) PCI: 00:1f:5: chip 8086,2825 card 1028,01da rev 02 class 01,01,85 hdr 00 (II) PCI: 01:00:0: chip 1002,71c1 card 174b,0840 rev 9e class 03,00,00 hdr 80 (II) PCI: 01:00:1: chip 1002,71e1 card 174b,0841 rev 9e class 03,80,00 hdr 00 (II) PCI: 03:00:0: chip 14e4,167a card 1028,01da rev 02 class 02,00,00 hdr 00 (II) PCI: 04:02:0: chip 10ec,8169 card 10ec,8169 rev 10 class 02,00,00 hdr 00 (II) PCI: End of PCI scan (II) Intel Bridge workaround enabled (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,4), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x1) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x1) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000a (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0xd000 - 0xdfff (0x1000) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xdfd0 - 0xdfef (0x20) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xc000 - 0xcfff (0x1000) MX[B] (II) PCI-to-PCI b
RE: General Procedure to get ATI/DRI card running?
On Wed, 2008-07-09 at 15:13 -0400, Labitt, Bruce wrote: > No joy so far. Still getting Mesa GLX Indirect. Any other ideas? > > Does the order in the file matter? Did you update to the latest development versions of mesa, drm, dri2proto, xorg-server, and friends? Also, you need to enable AIGLX in your xserver. If you post your /var/log/Xorg.0.log after running an unsuccessful X session, it will be easier to diagnose the problem. > > > From: Arc Riley [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 09, 2008 2:06 PM > To: Labitt, Bruce > Cc: Greater NH Linux User Group > Subject: Re: General Procedure to get ATI/DRI card running? > > Looks like you're missing the glx module, based on your paste not including > it. > > Section "Module" > Load "glx" > > In the future I'll be sure to ask what distro you're running before > recommending hardware. Apparently everyone that isn't running Gentoo or > another up-to-date distro is a second-class citizen left to toil in the > fields if they want anything even remotely new. > > # emerge -av xf86-video-radeonhd > On Wed, Jul 9, 2008 at 1:53 PM, Labitt, Bruce <[EMAIL PROTECTED]> wrote: > Arc, > > My kernel is 2.6.18-92.1.6.el5 > > in /etc/X11/xorg.conf I have > > Section "Device" > Identifier "Videocard0" > Driver "radeonhd" > EndSection > > Section "Screen" > Identifier "Screen0" > Device "Videocard0" > DefaultDepth 24 > SubSection "Display" > Viewport 0 0 > Depth24 > EndSubSection > EndSubSection > > Regards, > Bruce > > ___ > gnhlug-discuss mailing list > gnhlug-discuss@mail.gnhlug.org > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ > -- Coleman Kane signature.asc Description: This is a digitally signed message part ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
RE: General Procedure to get ATI/DRI card running?
No joy so far. Still getting Mesa GLX Indirect. Any other ideas? Does the order in the file matter? From: Arc Riley [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2008 2:06 PM To: Labitt, Bruce Cc: Greater NH Linux User Group Subject: Re: General Procedure to get ATI/DRI card running? Looks like you're missing the glx module, based on your paste not including it. Section "Module" Load "glx" In the future I'll be sure to ask what distro you're running before recommending hardware. Apparently everyone that isn't running Gentoo or another up-to-date distro is a second-class citizen left to toil in the fields if they want anything even remotely new. # emerge -av xf86-video-radeonhd On Wed, Jul 9, 2008 at 1:53 PM, Labitt, Bruce <[EMAIL PROTECTED]> wrote: Arc, My kernel is 2.6.18-92.1.6.el5 in /etc/X11/xorg.conf I have Section "Device" Identifier "Videocard0" Driver "radeonhd" EndSection Section "Screen" Identifier "Screen0" Device "Videocard0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSubSection Regards, Bruce ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Best device for use with OpenWRT/DD-WRT/etc?
On Wed, 2008-07-09 at 14:26 -0400, H. Kurth Bemis wrote: > Greetings to the list - > > First, a little background; I'm evaluating the replacement of several > point-to-point and frame ports and replacing the frame port in each > location with Business grade broadband (DSL and cable), and using > OpenVPN to connect each remote location back to company headquarters. > The offices are generally located within range of Verizon DSL G4 > Communications DSL or Comcast cable. > > Each location currently has several Cisco devices, an edge router, VPN > concentrator, and PIX. I'm looking to replace these devices with a > single Linux-based device running OpenWRT, or a derived project, at each > location, utilizing OpenVPN and iptables. > > I have plenty of experience with OpenWRT and DD-WRT, unfortunately the > only hardware I have worked with in depth is the Linksys WRT54GL, and > having worked with Linksys gear of all types, I'm not sure I would tote > them as a replacement for a Cisco router. My primary concern here is > reliability of hardware, not software. > > Can anyone recommend a system, preferably small in size, as a > replacement for a Cisco router or firewall? It should run OpenWRT, or a > derived work. > > So far I've been looking at the Asus WL-500G, but I'm always open to > suggestions. I'd not recommend such a thing for VPN usage if you care about throughput at all. I played around with hooking a WRT54GS (~200MHz MIPS, iirc) to our office ipsec vpn using both vpnc and openswan, and the performance was *terrible*. Like, 400kbps with vpnc, 1.2Mbps with openswan. Given enough cpu, I can usually get more like 12Mbps throughput. Not sure what crypto openvpn uses offhand, but any crypto that has to be done in software by the router is going to slaughter throughput. -- Jarod Wilson [EMAIL PROTECTED] ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: General Procedure to get ATI/DRI card running?
On Wed, 2008-07-09 at 14:05 -0400, Arc Riley wrote: > In the future I'll be sure to ask what distro you're running before > recommending hardware. Apparently everyone that isn't running Gentoo > or another up-to-date distro is a second-class citizen left to toil in > the fields if they want anything even remotely new. How can Gentoo claim to be up-to-date when 2008.0 released just last week comes with kernel 2.6.24, while Fedora 9 released about a month ago with 2.6.25... /me ducks and runs... ;) -- Jarod Wilson [EMAIL PROTECTED] ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Best device for use with OpenWRT/DD-WRT/etc?
Greetings to the list - First, a little background; I'm evaluating the replacement of several point-to-point and frame ports and replacing the frame port in each location with Business grade broadband (DSL and cable), and using OpenVPN to connect each remote location back to company headquarters. The offices are generally located within range of Verizon DSL G4 Communications DSL or Comcast cable. Each location currently has several Cisco devices, an edge router, VPN concentrator, and PIX. I'm looking to replace these devices with a single Linux-based device running OpenWRT, or a derived project, at each location, utilizing OpenVPN and iptables. I have plenty of experience with OpenWRT and DD-WRT, unfortunately the only hardware I have worked with in depth is the Linksys WRT54GL, and having worked with Linksys gear of all types, I'm not sure I would tote them as a replacement for a Cisco router. My primary concern here is reliability of hardware, not software. Can anyone recommend a system, preferably small in size, as a replacement for a Cisco router or firewall? It should run OpenWRT, or a derived work. So far I've been looking at the Asus WL-500G, but I'm always open to suggestions. Thanks ~kurth ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: General Procedure to get ATI/DRI card running?
Looks like you're missing the glx module, based on your paste not including it. Section "Module" Load "glx" In the future I'll be sure to ask what distro you're running before recommending hardware. Apparently everyone that isn't running Gentoo or another up-to-date distro is a second-class citizen left to toil in the fields if they want anything even remotely new. # emerge -av xf86-video-radeonhd On Wed, Jul 9, 2008 at 1:53 PM, Labitt, Bruce <[EMAIL PROTECTED]> wrote: > Arc, > > > > My kernel is 2.6.18-92.1.6.el5 > > > > in /etc/X11/xorg.conf I have > > > > Section "Device" > > Identifier "Videocard0" > > Driver "radeonhd" > > EndSection > > > > Section "Screen" > > Identifier "Screen0" > > Device "Videocard0" > > DefaultDepth 24 > > SubSection "Display" > > Viewport 0 0 > > Depth24 > > EndSubSection > > EndSubSection > > > > Regards, > > Bruce > > > -- > > *From:* Arc Riley [mailto:[EMAIL PROTECTED] > *Sent:* Wednesday, July 09, 2008 1:36 PM > > *To:* Labitt, Bruce > *Cc:* Greater NH Linux User Group > *Subject:* Re: General Procedure to get ATI/DRI card running? > > > > It could be any number of things, from the glx module being turned off in > your xorg.conf, or the radeonhd driver not being loaded, or something else > entirely. > > I know nothing about the tool you used to generate your xorg.conf and thus > don't know what it tends to do. Have you looked at the xorg.conf and > verified that it's set to use "radeonhd"? > > BTW, I just was told that if you have an updated kernel, your card may > already be supported by the stock Linux "radeon" DRM driver. Easier to wait > on that for your distro to catch up and focus on getting GLX for now. > > On Wed, Jul 9, 2008 at 1:30 PM, Labitt, Bruce < > [EMAIL PROTECTED]> wrote: > > Arc, > > > > How does one change that? Sorry to be such a noob. > > > > Regards, > > Bruce > > > -- > > *From:* Arc Riley [mailto:[EMAIL PROTECTED] > *Sent:* Wednesday, July 09, 2008 1:22 PM > *To:* Labitt, Bruce > > > *Cc:* Greater NH Linux User Group > *Subject:* Re: General Procedure to get ATI/DRI card running? > > > > This is the part you need to fix: > > OpenGL renderer string: Mesa GLX Indirect > > If you can get it to use the radeonhd driver, even over standard GLX, it'll > be accelerated. DRM speeds things up a bit by allowing the application to > render directly through the kerner rather than sending rendering through the > X server. > > On Wed, Jul 9, 2008 at 10:24 AM, Labitt, Bruce < > [EMAIL PROTECTED]> wrote: > > $ glxinfo > > name of display: :0.0 > > display: :0 screen: 0 > > direct rendering: No > > server glx vendor string: SGI > > server glx version string: 1.2 > > server glx extensions: > > GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, > > GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, > GLX_OML_swap_method, > > GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, > > GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer > > client glx vendor string: SGI > > client glx version string: 1.4 > > client glx extensions: > > GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, > > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, > > GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, > > GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, > > GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, > > GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, > > GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap > > GLX version: 1.2 > > GLX extensions: > > GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, > > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, > > GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, > > GLX_SGIX_fbconfig, GLX_EXT_texture_from_pixmap > > OpenGL vendor string: Mesa project: www.mesa3d.org > > OpenGL renderer string: Mesa GLX Indirect > > OpenGL version string: 1.2 (1.5 Mesa 6.5.1) > > OpenGL extensions: > > GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture, > > GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, > > GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, > > GL_ARB_texture_cube_map, GL_ARB_texture_env_add, > > GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, > > GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, > > GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, > > GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, > > GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, > > GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, > > GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, > > GL_EXT_framebuffer_object, GL_EXT_multi_d
Re: General Procedure to get ATI/DRI card running?
It could be any number of things, from the glx module being turned off in your xorg.conf, or the radeonhd driver not being loaded, or something else entirely. I know nothing about the tool you used to generate your xorg.conf and thus don't know what it tends to do. Have you looked at the xorg.conf and verified that it's set to use "radeonhd"? BTW, I just was told that if you have an updated kernel, your card may already be supported by the stock Linux "radeon" DRM driver. Easier to wait on that for your distro to catch up and focus on getting GLX for now. On Wed, Jul 9, 2008 at 1:30 PM, Labitt, Bruce <[EMAIL PROTECTED]> wrote: > Arc, > > > > How does one change that? Sorry to be such a noob. > > > > Regards, > > Bruce > > > -- > > *From:* Arc Riley [mailto:[EMAIL PROTECTED] > *Sent:* Wednesday, July 09, 2008 1:22 PM > *To:* Labitt, Bruce > > *Cc:* Greater NH Linux User Group > *Subject:* Re: General Procedure to get ATI/DRI card running? > > > > This is the part you need to fix: > > OpenGL renderer string: Mesa GLX Indirect > > If you can get it to use the radeonhd driver, even over standard GLX, it'll > be accelerated. DRM speeds things up a bit by allowing the application to > render directly through the kerner rather than sending rendering through the > X server. > > On Wed, Jul 9, 2008 at 10:24 AM, Labitt, Bruce < > [EMAIL PROTECTED]> wrote: > > $ glxinfo > > name of display: :0.0 > > display: :0 screen: 0 > > direct rendering: No > > server glx vendor string: SGI > > server glx version string: 1.2 > > server glx extensions: > > GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, > > GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, > GLX_OML_swap_method, > > GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, > > GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer > > client glx vendor string: SGI > > client glx version string: 1.4 > > client glx extensions: > > GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, > > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, > > GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, > > GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, > > GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, > > GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, > > GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap > > GLX version: 1.2 > > GLX extensions: > > GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, > > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, > > GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, > > GLX_SGIX_fbconfig, GLX_EXT_texture_from_pixmap > > OpenGL vendor string: Mesa project: www.mesa3d.org > > OpenGL renderer string: Mesa GLX Indirect > > OpenGL version string: 1.2 (1.5 Mesa 6.5.1) > > OpenGL extensions: > > GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture, > > GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, > > GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, > > GL_ARB_texture_cube_map, GL_ARB_texture_env_add, > > GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, > > GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, > > GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, > > GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, > > GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, > > GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, > > GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, > > GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays, > GL_EXT_packed_pixels, > > GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, > > GL_EXT_secondary_color, GL_EXT_separate_specular_color, > > GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_EXT_subtexture, > > GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, > > GL_EXT_texture_env_add, GL_EXT_texture_env_combine, > > GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias, > GL_EXT_texture_object, > > GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, > > GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, > > GL_ATIX_texture_env_combine3, GL_IBM_texture_mirrored_repeat, > > GL_INGR_blend_func_separate, GL_MESA_pack_invert, > GL_MESA_ycbcr_texture, > > GL_NV_blend_square, GL_NV_point_sprite, GL_NV_texgen_reflection, > > GL_NV_texture_rectangle, GL_SGIS_generate_mipmap, > > GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, > > GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, > > GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays > > > >visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav > > id dep cl sp sz l ci b
RE: General Procedure to get ATI/DRI card running?
Arc, How does one change that? Sorry to be such a noob. Regards, Bruce From: Arc Riley [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2008 1:22 PM To: Labitt, Bruce Cc: Greater NH Linux User Group Subject: Re: General Procedure to get ATI/DRI card running? This is the part you need to fix: OpenGL renderer string: Mesa GLX Indirect If you can get it to use the radeonhd driver, even over standard GLX, it'll be accelerated. DRM speeds things up a bit by allowing the application to render directly through the kerner rather than sending rendering through the X server. On Wed, Jul 9, 2008 at 10:24 AM, Labitt, Bruce <[EMAIL PROTECTED]> wrote: $ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_EXT_texture_from_pixmap OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.2 (1.5 Mesa 6.5.1) OpenGL extensions: GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_ATIX_texture_env_combine3, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_blend_square, GL_NV_point_sprite, GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None 0x25 24 tc 0 32 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x27 24 dc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x28 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None 0x29 24 dc 0 32 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x2a 24 dc 0 32 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x42 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 Ncon A few more months!!! -Bruce From: [EMAI
Re: General Procedure to get ATI/DRI card running?
This is the part you need to fix: OpenGL renderer string: Mesa GLX Indirect If you can get it to use the radeonhd driver, even over standard GLX, it'll be accelerated. DRM speeds things up a bit by allowing the application to render directly through the kerner rather than sending rendering through the X server. On Wed, Jul 9, 2008 at 10:24 AM, Labitt, Bruce <[EMAIL PROTECTED]> wrote: > $ glxinfo > > name of display: :0.0 > > display: :0 screen: 0 > > direct rendering: No > > server glx vendor string: SGI > > server glx version string: 1.2 > > server glx extensions: > > GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, > > GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, > GLX_OML_swap_method, > > GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, > > GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer > > client glx vendor string: SGI > > client glx version string: 1.4 > > client glx extensions: > > GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, > > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, > > GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, > > GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, > > GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, > > GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, > > GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap > > GLX version: 1.2 > > GLX extensions: > > GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, > > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, > > GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, > > GLX_SGIX_fbconfig, GLX_EXT_texture_from_pixmap > > OpenGL vendor string: Mesa project: www.mesa3d.org > > OpenGL renderer string: Mesa GLX Indirect > > OpenGL version string: 1.2 (1.5 Mesa 6.5.1) > > OpenGL extensions: > > GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture, > > GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, > > GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, > > GL_ARB_texture_cube_map, GL_ARB_texture_env_add, > > GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, > > GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, > > GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, > > GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, > > GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, > > GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, > > GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, > > GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays, > GL_EXT_packed_pixels, > > GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, > > GL_EXT_secondary_color, GL_EXT_separate_specular_color, > > GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_EXT_subtexture, > > GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, > > GL_EXT_texture_env_add, GL_EXT_texture_env_combine, > > GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias, > GL_EXT_texture_object, > > GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, > > GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, > > GL_ATIX_texture_env_combine3, GL_IBM_texture_mirrored_repeat, > > GL_INGR_blend_func_separate, GL_MESA_pack_invert, > GL_MESA_ycbcr_texture, > > GL_NV_blend_square, GL_NV_point_sprite, GL_NV_texgen_reflection, > > GL_NV_texture_rectangle, GL_SGIS_generate_mipmap, > > GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, > > GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, > > GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays > > > >visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav > > id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat > > -- > > 0x23 24 tc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None > > 0x24 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None > > 0x25 24 tc 0 32 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None > > 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None > > 0x27 24 dc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None > > 0x28 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None > > 0x29 24 dc 0 32 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None > > 0x2a 24 dc 0 32 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None > > 0x42 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 Ncon > > > > > > A few more months!!! > > -Bruce > > > -- > > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Arc Riley > *Sent:* Tuesday, July 08, 2008 10:56 PM > *To:* Bruc
Re: Adding a new drive / fstab
On Wed, Jul 9, 2008 at 12:28 PM, Drew Van Zandt <[EMAIL PROTECTED]> wrote: > On 7/9/08, Labitt, Bruce <[EMAIL PROTECTED]> wrote: >> > Anyone got any >> > suggestions? Pitfalls on how I am thinking about things? >> > > > It seems to me that using any of the "traditional" mount points in this > situation is somewhat inappropriate; the new drive is intended primarily as > a resource for another machine. Given that, Thomas' suggestion of > /bladeimages is a pretty sensible one. I tend to mount shared net drives on > mountpoints like "/share", or mount a RAID on /raid, make a directory called > "share" on it, and share that directory. It makes it obvious what physical > resource is associated with the mountpoint, and you can use symlinks to > organize things in a logical sense. > > I dislike the /mnt suggestion because to me, /mnt is for a foreign > filesystem, e.g. something that might be removed. On the blade server, > however, I'd probably mount the shared net filesystem under /mnt, for > reasons mentioned in VAB's reply. > Just to throw a few more wrenches... Solaris uses /export for file systems that will be exported on NFS. /export/home is for home directories. /opt is for 3rd part packages. /mnt and /home are used by automount to mount NFS file systems from servers I'm using /misc on my Linux boxes where Solaris has /mnt /media on Fedora linux is for CDs, USB drives. I think Ubuntu uses it too. Solaris uses /cdrom, /floppy and probably /usb. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Adding a new drive / fstab
> > On 7/9/08, Labitt, Bruce <[EMAIL PROTECTED]> wrote: > > Anyone got any > > suggestions? Pitfalls on how I am thinking about things? > It seems to me that using any of the "traditional" mount points in this situation is somewhat inappropriate; the new drive is intended primarily as a resource for another machine. Given that, Thomas' suggestion of /bladeimages is a pretty sensible one. I tend to mount shared net drives on mountpoints like "/share", or mount a RAID on /raid, make a directory called "share" on it, and share that directory. It makes it obvious what physical resource is associated with the mountpoint, and you can use symlinks to organize things in a logical sense. I dislike the /mnt suggestion because to me, /mnt is for a foreign filesystem, e.g. something that might be removed. On the blade server, however, I'd probably mount the shared net filesystem under /mnt, for reasons mentioned in VAB's reply. --DTVZ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Adding a new drive / fstab
On Wed, 2008-07-09 at 11:50 -0400, Labitt, Bruce wrote: > In the endless pursuit of upgrading this machine I have added a hard > drive to my computer. I have used fdisk to create a linux partition to > the whole disk. I made the disk use the ext3 file system. > > So now for fstab. What is the philosophy for creating an entry? At > this point I'm not sure what the mount point should be. /home sounds > ok, but I would like the drive to be the "home" for my linux image for > my blade server. I think the best thing to do may be to create a mount point for the drive under the '/mnt' directory. Perhaps, given the usage plan you described for this disk '/mnt/sys_imgs' (or something similar) is appropriate. A very long explanation why: Many years ago, when new *nix systems were open popping up rather frequently, there was an attempt to create a unified standard (which eventually became the POSIX standard). One of the core components of that standard was the file system (layout) structure. The file system layout structure standardization was undertaken in order to make it easier for people who found themselves working on many very different flavors. Those people included developers who were creating applications, for companies training users, and also system administrators. The portion of the standard consisted of many points including the following: - /tmp used by users for temporary user data - /var/tmp used by applications for temporary data - /bin, /sbin, /lib used for programs necessary for boot - /usr/bin, /usr/sbin, /usr/lib used for OS programs not necessary for boot and user installed software - /var variable data - /mnt used to mount remote file systems and directories that were not part of the standard. The idea was that if you had to perform an operating system upgrade, you knew you would not step on the 3rd party vendor program you just installed at some user's request. Likewise, while installing a program for that user you know you didn't have to worry about it installing over a program in '/bin' that you need to boot your system. This was extremely useful because vendor apps often required different versions of the same libraries and programs than the system required to boot. The idea behind using '/mnt' was that it would be easy for an admin to avoid backing up a number of file systems twice if they ware remotely mounted under a single directory by excluding that directory with the tar argument for doing just that. A sysadmin would also know that a disk error was with a secondary disk and not one of the primary OS disks that could render the system unbootable. So, that's why I suggest using a directory under '/mnt'. Although, a directory under '/usr/share' or '/usr/local/share' may also be appropriate. Here is the wikipedia page on that portion of the POSIX Standard (the FHS: Filesystem Hierarchy Standard): http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard - VAB - V. Alex Brennen [EMAIL PROTECTED] Senior UNIX Systems Administrator MIT Libraries E25-131 x3-9327 http://vab.mit.edu/ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Adding a new drive / fstab
On 7/9/08, Labitt, Bruce <[EMAIL PROTECTED]> wrote: > So now for fstab. What is the philosophy for creating an entry? At > this point I'm not sure what the mount point should be. /home sounds > ok, but I would like the drive to be the "home" for my linux image for > my blade server. The idea is that this box is the file server for my > blade. The blade will boot from my file server. The blade is > effectively a compute engine running linux. The big datafiles that > result from computation will reside on my file server. Anyone got any > suggestions? Pitfalls on how I am thinking about things? /bladeimages ? :-D Thomas -- -- Thomas ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Adding a new drive / fstab
In the endless pursuit of upgrading this machine I have added a hard drive to my computer. I have used fdisk to create a linux partition to the whole disk. I made the disk use the ext3 file system. So now for fstab. What is the philosophy for creating an entry? At this point I'm not sure what the mount point should be. /home sounds ok, but I would like the drive to be the "home" for my linux image for my blade server. The idea is that this box is the file server for my blade. The blade will boot from my file server. The blade is effectively a compute engine running linux. The big datafiles that result from computation will reside on my file server. Anyone got any suggestions? Pitfalls on how I am thinking about things? Thanks -Bruce ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
RE: General Procedure to get ATI/DRI card running?
$ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_EXT_texture_from_pixmap OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.2 (1.5 Mesa 6.5.1) OpenGL extensions: GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_ATIX_texture_env_combine3, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_blend_square, GL_NV_point_sprite, GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None 0x25 24 tc 0 32 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x27 24 dc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x28 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None 0x29 24 dc 0 32 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x2a 24 dc 0 32 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None 0x42 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 Ncon A few more months!!! -Bruce From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arc Riley Sent: Tuesday, July 08, 2008 10:56 PM To: Bruce Labitt Cc: Greater NH Linux User Group Subject: Re: General Procedure to get ATI/DRI card running? ah sorry looks like radeonhd DRM isn't ready yet. a few more months. indirect rendering (using GLX instead of DRI) is usually good enough, you should compile the DRM kernel module when it's ready though. so what does your glxinfo output look like? On Tue, Jul 8, 2008 at 10:33 PM, Bruce Labitt <[EMAIL PROTECTED]> wrote: So how is the DRM kernel module made active? Arc Riley wrote: Since you're no longer under the warm and fuzzy management of your distro, it's possible something related
