[gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

2011-07-13 Thread Nikos Chantziaras

On 07/13/2011 08:23 PM, Grant wrote:

[...]
I've eselected to gallium but is there any benefit if I don't use 3D at all?


You don't know what uses OpenGL and what not (OpenGL is uses for much 
more than just "3D").  Also, you're not paying for it so why not use it? 
 ;-)





Re: [gentoo-user] Re: Firefox and kernel panics.

2011-07-13 Thread Dale
I'm baakk.  Anybody want to guess why?  Come on, guess.  
First one doesn't count.


OK.  This thing ran for a while with no problems.  I'm downloading a 
video while I am watching TV.  I use Firefox for that because it has 
that download helper tool and I like it.  I couldn't find it for 
Seamonkey.  Anyway, I'm watching TV when I here my puter beep like it 
does when it is booting up the BIOS.  I look over and sure enough, it 
was rebooting.  This is what I am using at the moment:


root@fireball / # equery list *xorg* firefox nvidia*
 * Searching for *xorg* ...
[IP-] [  ] x11-base/xorg-drivers-1.10:0
[IP-] [  ] x11-base/xorg-server-1.10.3:0

 * Searching for firefox ...
[IP-] [  ] www-client/firefox-3.6.17:0

 * Searching for nvidia* ...
[IP-] [  ] media-video/nvidia-settings-260.19.29:0
[IP-] [  ] x11-drivers/nvidia-drivers-275.09.07:0
root@fireball / #


There was a bump in xorg-server so I let it upgrade.  I also noticed the 
nvidia and updated it as well.  I don't recall seeing that the last time 
I looked.  Anyway, Could this be xorg, Nvidia, Firefox or something else 
or a combination of a couple of them?  I'm on the latest of everything 
that is in the tree.  I'm thinking about going back to the older xorg, 
just to test.


While I am at it, it ran fine before I let it upgrade xorg.  Maybe I 
didn't let it run long enough or something but it never crashed on me.


Any more thoughts on this mess?

Dale

:-)  :-)



Re: [gentoo-user] {OT} 802.11n PCI-E 300Mbps with AP mode?

2011-07-13 Thread Paul Hartman
On Wed, Jul 13, 2011 at 7:03 PM, Adam Carter  wrote:
>> Thank you.  It looks like you are using it in AP mode but in 802.11g
>> mode.  Is that the case?  I'm also curious if it can operate in both
>> the 2.4 and 5Ghz bands?
>
> Sorry - dont know how to tell if can use 2.4 and 5.

It supports 2.4GHz only.



Re: [gentoo-user] {OT} 802.11n PCI-E 300Mbps with AP mode?

2011-07-13 Thread Adam Carter
> Thank you.  It looks like you are using it in AP mode but in 802.11g
> mode.  Is that the case?  I'm also curious if it can operate in both
> the 2.4 and 5Ghz bands?

Sorry - dont know how to tell if can use 2.4 and 5.



Re: [gentoo-user] {OT} 802.11n PCI-E 300Mbps with AP mode?

2011-07-13 Thread Adam Carter
> Thank you.  It looks like you are using it in AP mode but in 802.11g
> mode.  Is that the case?  I'm also curious if it can operate in both
> the 2.4 and 5Ghz bands?

Its certainly counter-intuitive, but that's what I found when I
searched N configuration. I have had better than 54M bit rates
reported, so despite the G its working as N. I think



Re: [gentoo-user] {OT} 802.11n PCI-E 300Mbps with AP mode?

2011-07-13 Thread Grant
>> Got it, thanks Paul.  That's good news because it means I can use any
>> 802.11n PCIe 300Mbps card with Linux drivers instead of worrying about
>> AP mode.  I'll just use a 802.11g card in AP mode until there is
>> better support for 802.11n.  The router uses most of the bandwidth
>> from the WAN.
>
> Hi Grant,
>
> I bought the TPLink WN951N (atheros AR5008, ath9k) card after it being
> recommended by a gentoo-user list member. I concur with the
> recommendation. Its cheap and seems to work well in linux. I have, at
> times, had scp report 3.5M/s, but its quite variable. There are a
> bunch of APs in my area though. Here's some details - I dont know if
> the AP configuration is optimal - I didnt find the documentation very
> clear.
>
> Here's what's reported as the
> Wiphy phy0
>       Band 1:
>               HT capabilities: 0x104e
>                       * 20/40 MHz operation
>                       * SM PS disabled
>                       * 40 MHz short GI
>                       * max A-MSDU len 3839
>                       * DSSS/CCK 40 MHz
>               HT A-MPDU factor: 0x0003 (65535 bytes)
>               HT A-MPDU density: 0x0006 (8 usec)
>
> And i've configured my hostapd.conf;
> hw_mode=g
> wme_enabled=1
> ieee80211n=1
> ht_capab=[SHORT-GI-40][DSSS_CCK-40]
>
> HTH

Thank you.  It looks like you are using it in AP mode but in 802.11g
mode.  Is that the case?  I'm also curious if it can operate in both
the 2.4 and 5Ghz bands?

- Grant



Re: [gentoo-user] {OT} 802.11n PCI-E 300Mbps with AP mode?

2011-07-13 Thread Adam Carter
> Got it, thanks Paul.  That's good news because it means I can use any
> 802.11n PCIe 300Mbps card with Linux drivers instead of worrying about
> AP mode.  I'll just use a 802.11g card in AP mode until there is
> better support for 802.11n.  The router uses most of the bandwidth
> from the WAN.

Hi Grant,

I bought the TPLink WN951N (atheros AR5008, ath9k) card after it being
recommended by a gentoo-user list member. I concur with the
recommendation. Its cheap and seems to work well in linux. I have, at
times, had scp report 3.5M/s, but its quite variable. There are a
bunch of APs in my area though. Here's some details - I dont know if
the AP configuration is optimal - I didnt find the documentation very
clear.

Here's what's reported as the
Wiphy phy0
   Band 1:
   HT capabilities: 0x104e
   * 20/40 MHz operation
   * SM PS disabled
   * 40 MHz short GI
   * max A-MSDU len 3839
   * DSSS/CCK 40 MHz
   HT A-MPDU factor: 0x0003 (65535 bytes)
   HT A-MPDU density: 0x0006 (8 usec)

And i've configured my hostapd.conf;
hw_mode=g
wme_enabled=1
ieee80211n=1
ht_capab=[SHORT-GI-40][DSSS_CCK-40]

HTH



Re: [gentoo-user] Re: Managing multiple Gentoo systems

2011-07-13 Thread Bill Longman
On 07/13/2011 12:38 PM, Grant wrote:

> I suppose I could also do without the PXE layer and all of its
> requirements if I install some sort of minimal storage device (flash
> drive, SD card, USB key, etc.) into each workstation for the boot
> image.  I could still push updates to the boot image over the network
> almost as easily as updating the single boot image on the server.

> It sounds like I should stick with ethernet for simplicity's sake.

Yeah, PXE on the wire is the place to start if you want to boot across
the network. Start simple. Just get a handful of similar NICs and you
should be set.

>> There's also the option of pre-made hardware thin clients that
>> typically boot from internal flash and simply provide a remote
>> interface to a central server (though most are geared towards RDP or
>> Citrix), and some are even WiFi capable.
> 
> A pre-made thin client could be the way to go.  Do you know of any
> that are geared toward open protocols?

Quick query of "the oracle" yields:

http://www.thinlabs.com/products/thin-clients/aden

I have used AXEL thin client terminals and those require a VNC server
instance on your server per thin client, for the scenario that it sounds
like you're envisioning. It does RDP/VNC but you can get it to do
ssh/telnet on a green screen, with several sessions per seat.



Re: [gentoo-user] Re: Managing multiple Gentoo systems

2011-07-13 Thread Grant
> Have you considered using PXE to network boot your systems? you can
> have various configurations set up based on mac addresses to address
> different hardware issues. I recommend trying out SystemRescueCD to
> experiment with PXE booting for the client and server.

 That sounds like exactly what I need.  So, I could set up a Gentoo
 server and a bunch of completely diskless clients which would all PXE
 boot from the server?  Would the clients basically each control a
 different virtual terminal on the server?
>>>
>>> Each machine can pull a copy of the master boot image to make updates
>>> a lot simpler. The SystemRescueCD PXE boot mechanism just pushes out a
>>> copy of the CD to all the machines to boot them. to update the boot
>>> image just update the files in one location to update all machines.
>>> the machines act as separate fully functioning machine. Check out
>>> http://www.sysresccd.org/Sysresccd-manual-en_PXE_network_booting to
>>> see how to setup the PXE boot environment.
>>
>> I think I get it now and it sounds great, exactly what I'm looking for.
>>
>> Everything can be done in RAM, no disks required?
>>
>> Can PXE boot be done wirelessly?  Maybe only if the wireless is
>> onboard?  I tried to Google this but the info returned is terribly
>> outdated for some reason.
>>
>> Do you think SystemRescueCD is the best boot image for clients that
>> only need a browser?
>>
>> What sort of machine would work well as a client?  Should I just put
>> together a bunch of motherboards with onboard video and ethernet,
>> CPUs, RAM, PSUs, and small cases?  Is there a prebuilt system that
>> works well for this?  Maybe an ARM-15 system as "Tampa Bay" James
>> referenced, although I think that isn't released yet.
>>
>> - Grant
>
> Well, the first thing you need to decide is whether you want each
> client running that browser locally, or whether you want each client
> to merely provide an interface to the server, and every user's browser
> (and every other application) running on the server itself. If your
> clients boot, then run all their own software locally, your server's
> under only under load during boot-time and your clients need to be
> able to handle that work (not much, but it's more than nothing, just
> try running a modern Firefox on 64MB of ram). On the other hand, if
> your clients merely boot into a remote connection to the server, a la
> VNC or NX, the client does *very* little locally, can run on next to
> nothing hardware-wise (a true 'thin client'), and the entirety of the
> workload is offloaded to the server. If you want responsive 'eye
> candy', 3D graphics work/play, or any form of particularly 'smooth'
> animation, you will want that work to be handled on hardware closer to
> the user (requiring a far faster processor, more ram, a capable video
> device, and likely local storage for swap at the least), while serving
> up a simple browser to the user is far more forgiving.

After reading this, my first reaction was to run the browser on the
server and have each client connect via VNC/NX.  Now that I think
about it, I may be better off running the browser locally for
simplicity's sake.  I always try to keep the number of layers I'm
dealing with to a minimum and VNC/NX is one layer I could do without
if I beef up the clients a bit.  How different would the client
hardware requirements be between running the browser locally and
running it via VNC/NX?

I suppose I could also do without the PXE layer and all of its
requirements if I install some sort of minimal storage device (flash
drive, SD card, USB key, etc.) into each workstation for the boot
image.  I could still push updates to the boot image over the network
almost as easily as updating the single boot image on the server.

What is the benefit of loading SystemRescueCD instead of another
monolithic "just work" distro like Ubuntu?

> As for wired vs wireless, true hardware PXE booting is generally
> limited to wired scenarios, but it would be entirely possible (though
> not truly 'diskless') to deploy a minimal kernel+initramfs that
> handles initial booting, joining WiFi, pulling down of the system
> 'image' from your server, and handing control off to that in the same
> way your run of the mill kernel+initramfs loads hardware drivers until
> it can find the harddrive, attaches to the root partition, and hands
> off control to init from there. Changes to the wireless configuration
> would require directly visiting each client, and client-side kernel or
> initramfs updates easily could as well, if things don't go as planned
> (but, since all the user-side software is either run on the server or
> loaded from it at boot-time, changes to the client's "loader"
> shouldn't be frequent).

It sounds like I should stick with ethernet for simplicity's sake.

> There's also the option of pre-made hardware thin clients that
> typically boot from internal flash and simply provide a remote
> interface to a

Re: [gentoo-user] {OT} 802.11n PCI-E 300Mbps with AP mode?

2011-07-13 Thread Grant
>> Should I need only one wireless card in my router to connect to both
>> the clients and a wireless bridge which is connected to the WAN?
>
> I think you need 2 cards in your router (one as host and one as client
> to the wireless WAN bridge), unless you use WDS.

Got it, thanks Paul.  That's good news because it means I can use any
802.11n PCIe 300Mbps card with Linux drivers instead of worrying about
AP mode.  I'll just use a 802.11g card in AP mode until there is
better support for 802.11n.  The router uses most of the bandwidth
from the WAN.

- Grant


> WDS allows your access points to become repeaters while still
> functioning as access points, so you can have multiple APs and only
> one of them needs to be connected to the wired network (as long as
> each AP is within range of at least one other AP).
>
> The cost of WDS this is that your available bandwidth is basically
> halved (and if you have to support 802.11b, it gets even slower).
> Depending on your expected usage, that might or might not be a big
> deal.



Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

2011-07-13 Thread meino . cramer
Grant  [11-07-13 19:20]:
> >> >>> When I was using an Nvidia video card, I noticed a strange sort of
> >> >>> fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
> >> >>> have the same problem.  Now I've switched to an ATI video card and
> >> >>> unfortunately I have the same problem with xf86-video-ati.  I tried to
> >> >>> enable the new modesetting radeon driver in the kernel to see if that
> >> >>> would help but it doesn't work with my HD4250 card yet.  Does anyone
> >> >>> know how to fix this?  Here's a photo of the effect around the mouse
> >> >>> cursor:
> >> >>>
> >> >>> http://imageshack.us/photo/my-images/804/cursor.jpg
> >> >>>
> >> >>> - Grant
> 
> >> >> The image looks to me as thos would be an analog instead of
> >> >> an digital problem.
> 
> >  Put all mains connectors of you PC rig into ONE wall connector
> >  with something like this (ok I miss some words here again and
> >  since a picture says more than even thousands of /missing/ words
> >  here comes an image of what I mean:):
> > http://www.reichelt.de/Steckdosenleisten-ohne-Schalter/6-FACH-DOSE-WS-5/index.html?;ACTION=3;LA=2;ARTICLE=108651;GROUPID=4281;SID=11Thz@On8AAAIAABaBBrE9f5418078c2ea9fe6608e9765d978595
> 
> Thank you for taking the time to explain.  So I'm sure I understand
> what it is I should try, I should connect my computer's power cable
> and monitor's power cable to a power strip and plug that power strip
> into an outlet?
> 
> - Grant
> 

Yepp! 100% correct! :)

Good luck! :))

Best regards,
mcc




Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

2011-07-13 Thread Grant
> When I was using an Nvidia video card, I noticed a strange sort of
> fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
> have the same problem.  Now I've switched to an ATI video card and
> unfortunately I have the same problem with xf86-video-ati.  I tried to
> enable the new modesetting radeon driver in the kernel to see if that
> would help but it doesn't work with my HD4250 card yet.  Does anyone
> know how to fix this?  Here's a photo of the effect around the mouse
> cursor:
>
> http://imageshack.us/photo/my-images/804/cursor.jpg
>
> - Grant
>

 Hi Grant,

 just a shot in the dark:
 The image looks to me as thos would be an analog instead of
 an digital problem.
 May be both propietary drivers switch to the highest possible
 data transfer rate and this triggers the problem.
 To check, whether this may be the problem:
 Instruct the driver to use either low resolution or low refresh
 rates. Check both.
 If the problem changes signifiently: Change the cables.
 May be only a pluf is not inserted correctly.
 Addtionally you can move the cables arround to see whether
 this will change the shadows around the cursor in any way...

 Good luck! :)
 Best regards
 mcc
>>>
>>> Thanks for that.  I'm still working on it but adding radeon.audio=0 to
>>> grub cleaned it up about 75%.
>>>
>>> - Grant
>>
>> It turns out the radeon.audio=0 setting disables HDMI data packets and
>> puts the HDMI port in DVI mode.  mcc, I'm starting to think you had it
>> pretty right on.  I've tried two different cables with the same result
>> but I'm thinking this may be some sort of electrical interference
>> issue.
>
> HDMI is digital, so there can be no interference.  This looks more like a
> driver bug.

I tried the latest git-sources-3.0 kernel with the same results.

> Btw, why are you connecting to your monitor with HDMI?  For computer
> monitors, you use the DVI port, not HDMI.  HDMI is for TVs.  Unless of
> course your monitor lacks a digital DVI port (DVI-I or DVI-D).  If it only
> has a DVI-A port, only then is HDMI the better solution.

The monitor is actually a 47" LG HDTV.  This is an HTPC.

- Grant



Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

2011-07-13 Thread Grant
>> When I was using an Nvidia video card, I noticed a strange sort of
>> fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
>> have the same problem.  Now I've switched to an ATI video card and
>> unfortunately I have the same problem with xf86-video-ati.  I tried to
>> enable the new modesetting radeon driver in the kernel to see if that
>> would help but it doesn't work with my HD4250 card yet.
>
> It should work.  But you need firmware that is not included in the kernel.
>  You need to install the x11-drivers/radeon-ucode package, and then build a
> kernel that includes the appropriate firmware.  Which firmware file (one of
> the *.bin files in /lib/firmware/radeon) is needed should be printed during
> boot; at the moment the kernel hangs, it should print which firmware file it
> was trying to load.
>
> On my HD4870, I configured it like so:
>
> In "Device Drivers -> Generic Driver Options", I've set:
>
> (radeon/R700_rlc.bin) External firmware blobs to build into the kernel
> binary
> (/lib/firmware) Firmware blobs root directory

You're right.  That fixed the stall during kernel load and now KMS works fine.

> Then rebuild and install the kernel.  Before you reboot, make sure you have
> built media-libs/mesa with the "gallium" USE flag set, and do an "eselect
> mesa set r600 gallium".  Make sure you don't have disabled KMS in the kernel
> command line or module options ("radeon.modeset=0" disables KMS).  After you
> reboot, you should have KMS + Gallium3D working.

I've eselected to gallium but is there any benefit if I don't use 3D at all?

- Grant



Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

2011-07-13 Thread Grant
>> >>> When I was using an Nvidia video card, I noticed a strange sort of
>> >>> fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
>> >>> have the same problem.  Now I've switched to an ATI video card and
>> >>> unfortunately I have the same problem with xf86-video-ati.  I tried to
>> >>> enable the new modesetting radeon driver in the kernel to see if that
>> >>> would help but it doesn't work with my HD4250 card yet.  Does anyone
>> >>> know how to fix this?  Here's a photo of the effect around the mouse
>> >>> cursor:
>> >>>
>> >>> http://imageshack.us/photo/my-images/804/cursor.jpg
>> >>>
>> >>> - Grant

>> >> The image looks to me as thos would be an analog instead of
>> >> an digital problem.

>  Put all mains connectors of you PC rig into ONE wall connector
>  with something like this (ok I miss some words here again and
>  since a picture says more than even thousands of /missing/ words
>  here comes an image of what I mean:):
> http://www.reichelt.de/Steckdosenleisten-ohne-Schalter/6-FACH-DOSE-WS-5/index.html?;ACTION=3;LA=2;ARTICLE=108651;GROUPID=4281;SID=11Thz@On8AAAIAABaBBrE9f5418078c2ea9fe6608e9765d978595

Thank you for taking the time to explain.  So I'm sure I understand
what it is I should try, I should connect my computer's power cable
and monitor's power cable to a power strip and plug that power strip
into an outlet?

- Grant



Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

2011-07-13 Thread Mick
On Wednesday 13 Jul 2011 15:42:02 Nikos Chantziaras wrote:
> On 07/13/2011 03:25 PM, Mick wrote:
> > [...]
> > Is the [r600] gallium stable now?  I found it was locking up a kde
> > desktop with effects enabled and set it back to classic.
> 
> It's been made the default driver in Mesa now.  So I guess that means
> it's considered stable.  But for me, both classic and gallium can hang
> the machine.  At least with Gallium I know how to fix it though:
> 
>Section "Device"
>  Identifier "HD4870"
>  Driver "radeon"
>  Option "EnablePageFlip" "FALSE"
>EndSection
> 
> in an xorg.conf.d file.

Great!  Thanks for the hint, I'll try it out.
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

2011-07-13 Thread meino . cramer
Roger Mason  [11-07-13 18:12]:
> meino.cra...@gmx.de writes:
> 
> >
> > Hi Grant,
> >
> > another shot into an even much deeper dark  ;)
> >
> > May be you have a problem here, which it is called "Brummschleife"
> > in german...sorry dont know the English equivalent...may be something
> > like "buzzing loop"...but this looks more like a strange translation 
> > made by google than by any other, human being ;)
> > Anyway
> 
> What you are describing that is, I think, called a "ground loop" in
> English.
> 
> Cheers,
> Roger
> 

Hi Roger,

oh, thanks! One gap filled !!! ;)))

Best regards,
mcc




Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

2011-07-13 Thread Roger Mason
meino.cra...@gmx.de writes:

>
> Hi Grant,
>
> another shot into an even much deeper dark  ;)
>
> May be you have a problem here, which it is called "Brummschleife"
> in german...sorry dont know the English equivalent...may be something
> like "buzzing loop"...but this looks more like a strange translation 
> made by google than by any other, human being ;)
> Anyway

What you are describing that is, I think, called a "ground loop" in
English.

Cheers,
Roger



Re: [gentoo-user] {OT} 802.11n PCI-E 300Mbps with AP mode?

2011-07-13 Thread Paul Hartman
On Tue, Jul 12, 2011 at 8:29 PM, Grant  wrote:
> Should I need only one wireless card in my router to connect to both
> the clients and a wireless bridge which is connected to the WAN?

I think you need 2 cards in your router (one as host and one as client
to the wireless WAN bridge), unless you use WDS.

WDS allows your access points to become repeaters while still
functioning as access points, so you can have multiple APs and only
one of them needs to be connected to the wired network (as long as
each AP is within range of at least one other AP).

The cost of WDS this is that your available bandwidth is basically
halved (and if you have to support 802.11b, it gets even slower).
Depending on your expected usage, that might or might not be a big
deal.



[gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

2011-07-13 Thread Nikos Chantziaras

On 07/13/2011 03:25 PM, Mick wrote:

[...]
Is the [r600] gallium stable now?  I found it was locking up a kde desktop with
effects enabled and set it back to classic.


It's been made the default driver in Mesa now.  So I guess that means 
it's considered stable.  But for me, both classic and gallium can hang 
the machine.  At least with Gallium I know how to fix it though:


  Section "Device"
Identifier "HD4870"
Driver "radeon"
Option "EnablePageFlip" "FALSE"
  EndSection

in an xorg.conf.d file.




Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

2011-07-13 Thread Mick
On Wednesday 13 Jul 2011 08:13:27 Nikos Chantziaras wrote:
> On 07/10/2011 02:21 AM, Grant wrote:
> > When I was using an Nvidia video card, I noticed a strange sort of
> > fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
> > have the same problem.  Now I've switched to an ATI video card and
> > unfortunately I have the same problem with xf86-video-ati.  I tried to
> > enable the new modesetting radeon driver in the kernel to see if that
> > would help but it doesn't work with my HD4250 card yet.
> 
> It should work.  But you need firmware that is not included in the
> kernel.  You need to install the x11-drivers/radeon-ucode package, and
> then build a kernel that includes the appropriate firmware.  Which
> firmware file (one of the *.bin files in /lib/firmware/radeon) is needed
> should be printed during boot; at the moment the kernel hangs, it should
> print which firmware file it was trying to load.
> 
> On my HD4870, I configured it like so:
> 
> In "Device Drivers -> Generic Driver Options", I've set:
> 
> (radeon/R700_rlc.bin) External firmware blobs to build into the kernel
> binary
> (/lib/firmware) Firmware blobs root directory
> 
> Then rebuild and install the kernel.  Before you reboot, make sure you
> have built media-libs/mesa with the "gallium" USE flag set, and do an
> "eselect mesa set r600 gallium".  Make sure you don't have disabled KMS
> in the kernel command line or module options ("radeon.modeset=0"
> disables KMS).  After you reboot, you should have KMS + Gallium3D working.

I think the OP's card needs R600_rcl.bin as I've suggested in a previous 
message.

Is the gallium stable now?  I found it was locking up a kde desktop with 
effects enabled and set it back to classic.
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.


[gentoo-user] Re: Android build error on Gentoo

2011-07-13 Thread randd
On Wednesday 13 Jul 2011 11:25:50 AM randd wrote:
> On Wednesday 13 Jul 2011 11:06:32 AM randd wrote:
> > Hi All,
> > 
> > I am on Gentoo stable and in the past (Jun 9) I have built android
> > (gingerbread)  successfully. Somehow now build fails at random places
> > with the following error.
> > 
> > 
> > /
> > ** */ *** glibc detected *** make: free(): invalid next size (fast):
> > 0x0e14f160 *** === Backtrace: =
> > /lib/libc.so.6(+0x6c3ef)[0xb77ad3ef]
> > /lib/libc.so.6(+0x6dce0)[0xb77aece0]
> > /lib/libc.so.6(cfree+0x6e)[0xb77b1e7e]
> > make[0x8050dbc]
> > === Memory map: 
> > 08048000-0806c000 r-xp  08:02 395421 /usr/bin/gmake
> > 0806c000-0806d000 r--p 00023000 08:02 395421 /usr/bin/gmake
> > 0806d000-0806e000 rw-p 00024000 08:02 395421 /usr/bin/gmake
> > 0806e000-0806f000 rw-p  00:00 0
> > 0921d000-0e2c9000 rw-p  00:00 0  [heap]
> > b720-b7221000 rw-p  00:00 0
> > b7221000-b730 ---p  00:00 0
> > b73fd000-b74d8000 rw-p  00:00 0
> > b7574000-b758f000 r-xp  08:02 398827
> > /usr/lib/gcc/i686-pc-linux- gnu/4.4.5/libgcc_s.so.1
> > b758f000-b759 r--p 0001a000 08:02 398827
> > /usr/lib/gcc/i686-pc-linux- gnu/4.4.5/libgcc_s.so.1
> > b759-b7591000 rw-p 0001b000 08:02 398827
> > /usr/lib/gcc/i686-pc-linux- gnu/4.4.5/libgcc_s.so.1
> > b75b3000-b7727000 rw-p  00:00 0
> > b7727000-b773c000 r-xp  08:02 1726966   
> > /lib/libpthread-2.12.2.so b773c000-b773d000 ---p 00015000 08:02 1726966 
> >   /lib/libpthread-2.12.2.so b773d000-b773e000 r--p 00015000 08:02
> > 1726966/lib/libpthread-2.12.2.so b773e000-b773f000 rw-p 00016000
> > 08:02 1726966/lib/libpthread-2.12.2.so b773f000-b7741000 rw-p
> >  00:00 0
> > b7741000-b7897000 r-xp  08:02 1726984/lib/libc-2.12.2.so
> > b7897000-b7899000 r--p 00156000 08:02 1726984/lib/libc-2.12.2.so
> > b7899000-b789a000 rw-p 00158000 08:02 1726984/lib/libc-2.12.2.so
> > b789a000-b789d000 rw-p  00:00 0
> > b789d000-b78a4000 r-xp  08:02 1726976/lib/librt-2.12.2.so
> > b78a4000-b78a5000 r--p 6000 08:02 1726976/lib/librt-2.12.2.so
> > b78a5000-b78a6000 rw-p 7000 08:02 1726976/lib/librt-2.12.2.so
> > b78c3000-b78c4000 rw-p  00:00 0
> > b78c6000-b78c9000 rw-p  00:00 0
> > b78c9000-b78e5000 r-xp  08:02 1726983/lib/ld-2.12.2.so
> > b78e5000-b78e6000 r-xp  00:00 0  [vdso]
> > b78e6000-b78e7000 r--p 0001c000 08:02 1726983/lib/ld-2.12.2.so
> > b78e7000-b78e8000 rw-p 0001d000 08:02 1726983/lib/ld-2.12.2.so
> > bfc93000-bfcc7000 rw-p  00:00 0  [stack]
> > Aborted
> > /
> > ** ***/
> > 
> > 
> > I am not sure what is causing the error. I might be some use flag or some
> > updated package but I am not able to find any thing. My configuration
> > files are as such:
> > 
> > make.conf
> > http://pastebin.com/6geZzKb4
> > 
> > package.use
> > http://pastebin.com/8V5YgCau
> > 
> > emerge --info
> > http://pastebin.com/ByW40pNp
> > 
> > Please let me know if any more information is required.
> > Any help is appreciated.
> > 
> > thanks,
> > randd
> 
> Just found this
> http://forums.gentoo.org/viewtopic-t-851441-start-0.html
> 
> It seems the problem is seen with make-3.82 and not with make-3.81. I am
> downgrading make and checking the build now.
Yep. That was the problem. Build goes on fine with make-3.81-r2.



[gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

2011-07-13 Thread Nikos Chantziaras

On 07/13/2011 01:33 AM, Grant wrote:

When I was using an Nvidia video card, I noticed a strange sort of
fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
have the same problem.  Now I've switched to an ATI video card and
unfortunately I have the same problem with xf86-video-ati.  I tried to
enable the new modesetting radeon driver in the kernel to see if that
would help but it doesn't work with my HD4250 card yet.  Does anyone
know how to fix this?  Here's a photo of the effect around the mouse
cursor:

http://imageshack.us/photo/my-images/804/cursor.jpg

- Grant



Hi Grant,

just a shot in the dark:
The image looks to me as thos would be an analog instead of
an digital problem.
May be both propietary drivers switch to the highest possible
data transfer rate and this triggers the problem.
To check, whether this may be the problem:
Instruct the driver to use either low resolution or low refresh
rates. Check both.
If the problem changes signifiently: Change the cables.
May be only a pluf is not inserted correctly.
Addtionally you can move the cables arround to see whether
this will change the shadows around the cursor in any way...

Good luck! :)
Best regards
mcc


Thanks for that.  I'm still working on it but adding radeon.audio=0 to
grub cleaned it up about 75%.

- Grant


It turns out the radeon.audio=0 setting disables HDMI data packets and
puts the HDMI port in DVI mode.  mcc, I'm starting to think you had it
pretty right on.  I've tried two different cables with the same result
but I'm thinking this may be some sort of electrical interference
issue.


HDMI is digital, so there can be no interference.  This looks more like 
a driver bug.


Btw, why are you connecting to your monitor with HDMI?  For computer 
monitors, you use the DVI port, not HDMI.  HDMI is for TVs.  Unless of 
course your monitor lacks a digital DVI port (DVI-I or DVI-D).  If it 
only has a DVI-A port, only then is HDMI the better solution.





[gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

2011-07-13 Thread Nikos Chantziaras

On 07/10/2011 02:21 AM, Grant wrote:

When I was using an Nvidia video card, I noticed a strange sort of
fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
have the same problem.  Now I've switched to an ATI video card and
unfortunately I have the same problem with xf86-video-ati.  I tried to
enable the new modesetting radeon driver in the kernel to see if that
would help but it doesn't work with my HD4250 card yet.


It should work.  But you need firmware that is not included in the 
kernel.  You need to install the x11-drivers/radeon-ucode package, and 
then build a kernel that includes the appropriate firmware.  Which 
firmware file (one of the *.bin files in /lib/firmware/radeon) is needed 
should be printed during boot; at the moment the kernel hangs, it should 
print which firmware file it was trying to load.


On my HD4870, I configured it like so:

In "Device Drivers -> Generic Driver Options", I've set:

(radeon/R700_rlc.bin) External firmware blobs to build into the kernel 
binary

(/lib/firmware) Firmware blobs root directory

Then rebuild and install the kernel.  Before you reboot, make sure you 
have built media-libs/mesa with the "gallium" USE flag set, and do an 
"eselect mesa set r600 gallium".  Make sure you don't have disabled KMS 
in the kernel command line or module options ("radeon.modeset=0" 
disables KMS).  After you reboot, you should have KMS + Gallium3D working.