linuxconsole-dev

Re: Successful ruby setup and a problem

[<Aiv...@un...>]

>This configuration is so good, even DRI works on both videocards!
>Two kids can play tuxracer at once. :-)

You are pioneer. Previously all users disable DRI.
Do You use open source "ati" driver?

>I use the Option "PciOsConfig" "1" tweak but I don't use the
>echo "1" >/proc/bus/pci/hackvideo because it stalled one of
>the cards, gdm could not start it until I logged in and out
>on the other at first but then this card was stalled... Strange.
>So I stayed with the -prefbusid XFree86 option.

That -prefbusid is unofficial , unsupported and so on. I realy do
not know how to works xf86 PCI handling :(

>There are few things that bugs me still. Some devices
>(like /dev/mixer) can only be used by the first login,
>no matter which display. Changes to /etc/security/console.perms
>is needed, users should be put into groups to be able to access
>devices but I can handle these kinds of problems.
>
>My main problem is that localhost:1.0 is destroyed by logging
>out on localhost:0.0.

Try this line in the gdm.conf
AllwaysRestarServer=false

To make sure X server restart lead trouble try to kill it.
Typicaly X servers are non-restartable with echo "1"
>/proc/bus/pci/hackvideo
Without restart X may work very long period.

Aivils Stoss

Re: Successful ruby setup and a problem

[Wayne W. <wh...@Ma...>]

On Tue, 9 Mar 2004 Boszormenyi Zoltan <zb...@fr...> wrote:

> Yesterday I compiled 4.3.0-62 from FC2 test and that fixed the keyboard
> controller hardware access the kernel complained constantly but it also
> "destroys" the :1.0 when I logout on :0.0.
>
> Sorry, I did not described what it means in the first post. The screen
> goes black on :1.0. It looks like it goes into powersave mode. I think
> the X that drives :0.0 does some register settings in the hardware of
> :1.0 and the X that drives :1.0 looses track of what's going on. I
> pressed Ctrl-Alt-BkSpace on :1.0 after the monitor went black and the
> gdm login screen came back.

I have the exact same problem.  My setup is two Radeon RV100 QY [Radeon
7000/VE], one AGP and one PCI.  When I log out of the AGP console :0, it
"destroys" the PCI console :1.  I have found that I can restore the :1
console by getting X to reinitialize the display, e.g. with
Ctrl-Alt-KeyPadMinus (followed by Ctrl-Alt-KeyPadPlus to get back to the
previous resolution).  When the display comes back, the top few lines of
the screen have been scribbled on.  To restore the display, it is enough
to have X execute xf86Screens[0]->LeaveVT(0, 0) followed by
xf86Screens[0]->EnterVT(0, 0), so as a hack I bound Ctrl-Alt-KeyPadDivide
to this sequence in programs/Xserver/hw/xfree86/common/xf86Events.c.

Anyway, my understanding of the problem is this, which may be completely
nonsensical:  There is still some (legacy VGA?) resource each card has
which X expects to be mapped at a particular address, so that only one
card can have this resource mapped at a time.  Since :1 is started up
second, it has the resource mapped to the :1 card most of the time.  When
:0 exits, its X process expects that resource to be mapped to the :0 card
and goes ahead and writes to that address.  But the address is mapped to
the :1 card, so the :1 card is screwed up.

Cheers, Wayne

Re: Successful ruby setup and a problem

[Svetoslav S. <sv...@gm...>]

> > and more importantly the cpu is not 32bit, but 64 :-)
> > !!! you are the first non i386 ruby user !!!!
> 
> This is not true, yet. :-) The system is i386 version of Fedora Core 1.
> I am downloading the ISOs of FC1/x86_64 now...

sorry for the late reply,
and hope you are already 64bit :-)

> > isn't it great that ruby also works on other archs :-)
> > 
> 
> > which remainds me,
> > have you applied the x86_64 ruby changes ?
> 
> Where are they? The CVS contains arch/i386 but no other archs.

you might check the bk tree http://linuxconsole.bkbits.net/

attached is a bit older diff, it should be pretty trivial to merge

 
> >>>I've noticed that tuxracer doesn't like a compile going on at
> >>>the same time, but that's on a 333MHz processor. A dual cpu
> >>>setup fixed that for me.
> >>
> >>Playing a movie in Xine while rpmbuild --rebuild XFree86
> >>causes sound dropouts (very rare) and frame drops (even less)
> >>That's with the onboard AC97 sound card.
> > 
> 
> > 
> 
> > are all the apps compiled for 64bit?
> > i would expect no problems with such a beast CPU,
> > have you tried updating alsa ?
> > another soundcard?
> > i don't see such problems with 
> 
> > amd XP2700 
> 
> > 1024 MB DDR333 RAM
> 
> I only have 512M, but DDR400.
> 
> > sb audigy
> 
> I also have an SB Live! 1024.
> 
> > radeon AIW 7500 AGP 
> 
> > geforce4 440 PCI 

do you have the drops with the sb card ?
on-board sound tend to be problematic sometimes

> >>>>My main problem is that localhost:1.0 is destroyed by logging
> >>>>out on localhost:0.0.
> >>>
> >>>Destroyed how - logging out kills the other xserver too?
> >>
> >>The monitor goes black, looks powersave mode but it's not.
> >>Pressing Ctrl-Alt-BkSpace brings back the gdm login.
> > 
> 
> > have you tried disabling all DPMS stuff in XFree and kernel ?
> 
> That should not be a problem, as I said I can login/logout on
> display :1.0 any time I want, it does not bother display :0.0.
> It's logging out on :0.0 that confuses :1.0, its monitor goes blank.
> On :0.0 the gdm login screen comes back as it should on logout.

it might be some DRI bug :(
have you tried disabling DRI ?
 
> > some time ago my monitor used to go in power saving even as i type
> > and i think Andreas Schuldei had the same problem
> > i think disabling :
> > power managment --> APM ... --> enable console blanking ... 
> 
> > fixed it
> 
> I use ACPI on this machine.
and ?
you have totaly disabled APM ?

best,

svetljo

-- 
+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

Re: Successful ruby setup and a problem

[Boszormenyi Z. <zb...@fr...>]

Svetoslav Slavtchev =EDrta:
>>>and more importantly the cpu is not 32bit, but 64 :-)
>>>!!! you are the first non i386 ruby user !!!!
>>
>>This is not true, yet. :-) The system is i386 version of Fedora Core 1.=

>>I am downloading the ISOs of FC1/x86_64 now...
> =

> =

> sorry for the late reply,
> and hope you are already 64bit :-)

I burned the 3 CD five minutes ago, they will be installed
today evening. :-)

>>>isn't it great that ruby also works on other archs :-)
>>>
>>
>>>which remainds me,
>>>have you applied the x86_64 ruby changes ?
>>
>>Where are they? The CVS contains arch/i386 but no other archs.
> =

> =

> you might check the bk tree http://linuxconsole.bkbits.net/
> =

> attached is a bit older diff, it should be pretty trivial to merge

Yes, this is the exact difference between ruby-2.6 and the mainline
i386 setup.c, too.

> do you have the drops with the sb card ?
> on-board sound tend to be problematic sometimes

I haven't tried it yet. But as I remember from the emu10k1
sources, this chip can DMA only under 256MB, so the kernel
has to double-copy if the user buffer is above that. It can
cause dropouts, too. I will try to get an old Vortex2 card,
it does not have PCI addressign problems and it just got a
shiny new ALSa driver... Hmm, I will ask on the kernel list
if the Athlon64 IOMMU can address this in 64bit mode.

>>>>>>My main problem is that localhost:1.0 is destroyed by logging
>>>>>>out on localhost:0.0.
>>>>>
>>>>>Destroyed how - logging out kills the other xserver too?
>>>>
>>>>The monitor goes black, looks powersave mode but it's not.
>>>>Pressing Ctrl-Alt-BkSpace brings back the gdm login.
>>>
>>>have you tried disabling all DPMS stuff in XFree and kernel ?
>>
>>That should not be a problem, as I said I can login/logout on
>>display :1.0 any time I want, it does not bother display :0.0.
>>It's logging out on :0.0 that confuses :1.0, its monitor goes blank.
>>On :0.0 the gdm login screen comes back as it should on logout.
> =

> =

> it might be some DRI bug :(
> have you tried disabling DRI ?

No, this happened with DRI disabled, too.
It seems that Wayne Whitney is right:

> Anyway, my understanding of the problem is this, which may be completel=
y
> nonsensical:  There is still some (legacy VGA?) resource each card has
> which X expects to be mapped at a particular address, so that only one
> card can have this resource mapped at a time.  Since :1 is started up
> second, it has the resource mapped to the :1 card most of the time.  Wh=
en
> :0 exits, its X process expects that resource to be mapped to the :0 ca=
rd
> and goes ahead and writes to that address.  But the address is mapped t=
o
> the :1 card, so the :1 card is screwed up.

diff -u XFree86.0.log XFree86.1.log
=2E..
@@ -513,7 +512,7 @@
         compiled for 4.3.0, module version =3D 0.1.0
         ABI class: XFree86 Video Driver, version 0.6
  (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset i=
s 0x0000
-(II) RADEON(0): PCI bus 0 card 6 func 0
+(II) RADEON(0): PCI bus 1 card 0 func 0
  (**) RADEON(0): Depth 24, (--) framebuffer bpp 32
  (II) RADEON(0): Pixel depth =3D 24 bits stored in 4 bytes (32 bpp pixma=
ps)
  (=3D=3D) RADEON(0): Default visual is TrueColor

The "... vgaHWGetIOBase: hwp->IOBase is 0x03d0 ..." line is the same.

>>>i think disabling :
>>>power managment --> APM ... --> enable console blanking ... =

>>
>>>fixed it
>>
>>I use ACPI on this machine.
> =

> and ?
> you have totaly disabled APM ?

The kernel does not use it. I compiled in both and ACPI wins.

-- =

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

---------------------
What did Hussein say about his knife?
One in Bush worth two in the hand.

Re: Successful ruby setup and a problem

[Boszormenyi Z. <zb...@fr...>]

Boszormenyi Zoltan =EDrta:
> Svetoslav Slavtchev =EDrta:
>> sorry for the late reply,
>> and hope you are already 64bit :-)
> =

> =

> I burned the 3 CD five minutes ago, they will be installed
> today evening. :-)

Didn't install. :-( I got a nasty oops about "Attempt to kill swapper
task" on booting the install CD. The md5sums were OK. :-(

-- =

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

---------------------
What did Hussein say about his knife?
One in Bush worth two in the hand.

Re: Successful ruby setup and a problem

[lumarga <lu...@it...>]

C=E9dric,
  I will change the card and do other tests.

Thank's.
Celso.Silva


Assunto: Re: Successful ruby setup and a problem

> lumarga wrote:
> > Hi everyone,
> >    Excuse-me, I don't know where ask this, then I'm asking here.
> >    The problem: 'Successful ruby setup and a problem -- localhost:1.0=

> > is destroyed by logging out on localhost:0.0 ' posted by  Boszormenyi=

> > Zoltan and Wayne Whitney on March was solved in newer patch's?
> 
> No, there is no patch for this issue which was discussed
specifically to 
> ATI radeon cards. Maybe, Wayne could post his Xfree hack used to
restore 
> the display but this should not be relevant to you since you have 
> different hardware.
> Would you suggest that you experience the same behavior because you
have 
> also cards based on an identical graphic chipset ?
> 
> > My video cards are: Trident Microsystems CyberBlade/i1 (onboard 1:0:0=
)
> > and Trident Microsystems TGUI 9440 (rev e3) (0:8:0).
> > My kernel: Linux slac90 2.4.25-backstreet-ruby
> > My XFree86:  Version 4.3.0 - X Protocol Version 11, Revision 0,
> > Release 6.6 - patch xf86-430-prefbusid3.diff (from
> > http://disjunkt.com/dualhead/)
> > My Display Manager: gdm.
> 
> Don't know anything particular about Trident cards. You should post 
> configuration and log files to give a good understanding of your setup.=

> 
> > 
> > I'm a bad English writer.
> 
> You can write me privately in portuguese if it can help.
> 
> Cheers,
> C=E9dric
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle
10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op

Re: Successful ruby setup and a problem

[Boszormenyi Z. <zb...@fr...>]

Aiv...@un... írta:
>>This configuration is so good, even DRI works on both videocards!
>>Two kids can play tuxracer at once. :-)
> 
> 
> You are pioneer. Previously all users disable DRI.

:-) I did it previously, it locked up with the original
XFree86 release of FC1, 4.3.0-42 I think.
Then with the prefbusid3 patch I was unable to set up DRI,
it was with 2.4.0-ruby, official 2.4.0 and no other patches
besides ruby. (Old DRM kernel module.) I experimented with
many configurations including -mm kernels and even compiled
XFree86-4.4.0-RC2 into a different directory and changed every
symlink to point to it but I think the only thing that made
the difference is that the PCI Radeon7000 is :0.0 and the
AGP Radeon9200SE is :1.0 following the minor numbers
(reported by dmesg) of the updated DRM kernel module.
Previously there was only one DRI device (minor 0)
and this have caused problems when using a unified
XF86Config where Load "dri" is present or not in Section "Module".
Using different XF86Config files for different displays
would have solved it before. X has an option to specify which
config file to use.

Now glxgears reports 300+ fps for the PCI card,
510+ for the AGP one. Same numbers if I run it
on either one or on both. Must be hardware accelerated.
:-)

> Do You use open source "ati" driver?

Yes.

>>I use the Option "PciOsConfig" "1" tweak but I don't use the
>>echo "1" >/proc/bus/pci/hackvideo because it stalled one of
>>the cards, gdm could not start it until I logged in and out
>>on the other at first but then this card was stalled... Strange.
>>So I stayed with the -prefbusid XFree86 option.
> 
> 
> That -prefbusid is unofficial , unsupported and so on. I realy do
> not know how to works xf86 PCI handling :(

I think it would be more acceptable for the XFree86 developers
or to the Linux distribution makers if You (or whoever made the
prefbusid patch) fix the already existing BusID option so it does
not touch anything else besides the specified card.

>>There are few things that bugs me still. Some devices
>>(like /dev/mixer) can only be used by the first login,
>>no matter which display. Changes to /etc/security/console.perms
>>is needed, users should be put into groups to be able to access
>>devices but I can handle these kinds of problems.
>>
>>My main problem is that localhost:1.0 is destroyed by logging
>>out on localhost:0.0.
> 
> 
> Try this line in the gdm.conf
> AllwaysRestarServer=false

I tried it explicitely (it is the default BTW) and also tried
KillInitClients=false, where true is the default. Nothing helped.

> To make sure X server restart lead trouble try to kill it.
> Typicaly X servers are non-restartable with echo "1" >/proc/bus/pci/hackvideo
> 
> Without restart X may work very long period.

When there is a user logged in on both displays, they
indeed work for long time, no lockups, I can start OpenGL
games and quit them, xine work with XV on both, etc.
It can handle everything I throw at it but the logout on :0.0.
The fact that both cards are radeons could not be a problem
since I can login/logout on :1.0 any time I want.

Yesterday I compiled 4.3.0-62 from FC2 test and that fixed the
keyboard controller hardware access the kernel complained
constantly but it also "destroys" the :1.0 when I logout on :0.0.

Sorry, I did not described what it means in the first post.
The screen goes black on :1.0. It looks like it goes into
powersave mode. I think the X that drives :0.0 does some register
settings in the hardware of :1.0 and the X that drives :1.0 looses
track of what's going on. I pressed Ctrl-Alt-BkSpace on :1.0 after
the monitor went black and the gdm login screen came back.

-- 
Best regards,
Zoltán Böszörményi

---------------------
What did Hussein say about his knife?
One in Bush worth two in the hand.