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.