Re: reinstalling X.Org server

2009-01-31 Thread Robert Isaac
On Fri, Jan 30, 2009 at 6:01 PM, Lennart Sorensen
 wrote:
> On Fri, Jan 30, 2009 at 04:29:24PM -0600, Ron Johnson wrote:
>> On 01/30/2009 04:18 PM, Francesco Pietra wrote:
>> >Is it possible to reinstall X.Org server on a multisocket dual-opteron
>> >computer running amd64 lenny?
>> >
>> >Why? Failure of a DIMM bank did no more allow to launch amd64. Removed
>> >the faulty slots, amd64 could be launched and the system seemed to be
>> >in order. Filled the empty bank with fresh DDR1 ECC, the total memory
>> >increased correspondingly. Again, it was now possible to carry out
>> >sophisticated chemical calculations.
>> >
>> >However, needing now to check 3D molecular structures, I found that
>> >"startx" does not launch X anymore, X only appearing as a flash at the
>> >bottom of the screen.  I checked many X-related files against a i386
>> >lenny, ssh linked, computer (in particular /etc/X11/xorg.conf), don't
>> >detecting damaged lines. I did not carry out a checksum. Command:
>> >
>> >tail --lines 200 /var/log/Xorg.0.log|grep EE
>> >
>> >was not much informative, as shows below between === lines.
>> >
>> >I suspect that one or more X-related files were damaged as a
>> >consequence of the RAM problems above.
>> >
>> >Thanks
>> >francesco pietra.
>> >
>> >
>> >(II) MACH64(0): Not using default mode "1920x1440" (insufficient
>> >memory for mode)
>> >(II) MACH64(0): Not using default mode "960x720" (bad mode
>> [snip]
>> >drmOpenDevice: node name is /dev/dri/card0
>> >drmOpenDevice: open result is -1, (No such device or address)
>> >drmOpenDevice: open result is -1, (No such device or address)
>> >drmOpenDevice: Open failed
>> >
>> >Backtrace:
>> >0: X(xf86SigHandler+0x6a) [0x48dd0a]
>> >1: /lib/libc.so.6 [0x2b1686b4ef60]
>> >
>> >Fatal server error:
>> >Caught signal 11. Server aborting
>> >==
>>
>> I'd reinstall the whole system.
>
> For an ati fglrx driver module missing?
>
> Seems like overkill.
>
> The ATI driver loves to crash/segfault if anything displeases it (like
> running 8bit colour mode, which some versions default to).

Does fglrx support the Mach64 chip?


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: reinstalling X.Org server

2009-01-30 Thread Ron Johnson

On 01/30/2009 05:01 PM, Lennart Sorensen wrote:

On Fri, Jan 30, 2009 at 04:29:24PM -0600, Ron Johnson wrote:

On 01/30/2009 04:18 PM, Francesco Pietra wrote:

Is it possible to reinstall X.Org server on a multisocket dual-opteron
computer running amd64 lenny?

Why? Failure of a DIMM bank did no more allow to launch amd64. Removed
the faulty slots, amd64 could be launched and the system seemed to be
in order. Filled the empty bank with fresh DDR1 ECC, the total memory
increased correspondingly. Again, it was now possible to carry out
sophisticated chemical calculations.


[snip]


Backtrace:
0: X(xf86SigHandler+0x6a) [0x48dd0a]
1: /lib/libc.so.6 [0x2b1686b4ef60]

Fatal server error:
Caught signal 11. Server aborting
==

I'd reinstall the whole system.


For an ati fglrx driver module missing?

Seems like overkill.

The ATI driver loves to crash/segfault if anything displeases it (like
running 8bit colour mode, which some versions default to).


If the problem is just an unloaded module, that's one thing.  But 
one corrupted file is an indication that other files could be 
corrupted, too.


--
Ron Johnson, Jr.
Jefferson LA  USA

"I am not surprised, for we live long and are celebrated poopers."


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: reinstalling X.Org server

2009-01-30 Thread Lennart Sorensen
On Fri, Jan 30, 2009 at 04:29:24PM -0600, Ron Johnson wrote:
> On 01/30/2009 04:18 PM, Francesco Pietra wrote:
> >Is it possible to reinstall X.Org server on a multisocket dual-opteron
> >computer running amd64 lenny?
> >
> >Why? Failure of a DIMM bank did no more allow to launch amd64. Removed
> >the faulty slots, amd64 could be launched and the system seemed to be
> >in order. Filled the empty bank with fresh DDR1 ECC, the total memory
> >increased correspondingly. Again, it was now possible to carry out
> >sophisticated chemical calculations.
> >
> >However, needing now to check 3D molecular structures, I found that
> >"startx" does not launch X anymore, X only appearing as a flash at the
> >bottom of the screen.  I checked many X-related files against a i386
> >lenny, ssh linked, computer (in particular /etc/X11/xorg.conf), don't
> >detecting damaged lines. I did not carry out a checksum. Command:
> >
> >tail --lines 200 /var/log/Xorg.0.log|grep EE
> >
> >was not much informative, as shows below between === lines.
> >
> >I suspect that one or more X-related files were damaged as a
> >consequence of the RAM problems above.
> >
> >Thanks
> >francesco pietra.
> >
> >
> >(II) MACH64(0): Not using default mode "1920x1440" (insufficient
> >memory for mode)
> >(II) MACH64(0): Not using default mode "960x720" (bad mode
> [snip]
> >drmOpenDevice: node name is /dev/dri/card0
> >drmOpenDevice: open result is -1, (No such device or address)
> >drmOpenDevice: open result is -1, (No such device or address)
> >drmOpenDevice: Open failed
> >
> >Backtrace:
> >0: X(xf86SigHandler+0x6a) [0x48dd0a]
> >1: /lib/libc.so.6 [0x2b1686b4ef60]
> >
> >Fatal server error:
> >Caught signal 11. Server aborting
> >==
> 
> I'd reinstall the whole system.

For an ati fglrx driver module missing?

Seems like overkill.

The ATI driver loves to crash/segfault if anything displeases it (like
running 8bit colour mode, which some versions default to).

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: reinstalling X.Org server

2009-01-30 Thread Lennart Sorensen
On Fri, Jan 30, 2009 at 11:18:04PM +0100, Francesco Pietra wrote:
> Is it possible to reinstall X.Org server on a multisocket dual-opteron
> computer running amd64 lenny?
> 
> Why? Failure of a DIMM bank did no more allow to launch amd64. Removed
> the faulty slots, amd64 could be launched and the system seemed to be
> in order. Filled the empty bank with fresh DDR1 ECC, the total memory
> increased correspondingly. Again, it was now possible to carry out
> sophisticated chemical calculations.
> 
> However, needing now to check 3D molecular structures, I found that
> "startx" does not launch X anymore, X only appearing as a flash at the
> bottom of the screen.  I checked many X-related files against a i386
> lenny, ssh linked, computer (in particular /etc/X11/xorg.conf), don't
> detecting damaged lines. I did not carry out a checksum. Command:
> 
> tail --lines 200 /var/log/Xorg.0.log|grep EE
> 
> was not much informative, as shows below between === lines.
> 
> I suspect that one or more X-related files were damaged as a
> consequence of the RAM problems above.
> 
> Thanks
> francesco pietra.
> 
> 
> (II) MACH64(0): Not using default mode "1920x1440" (insufficient
> memory for mode)
> (II) MACH64(0): Not using default mode "960x720" (bad mode
> clock/interlace/doublescan)
> (II) MACH64(0): Not using default mode "1280x768" (width too large for
> virtual size)
> (II) MACH64(0): Not using default mode "1280x800" (width too large for
> virtual size)
> (II) MACH64(0): Not using default mode "1152x768" (width too large for
> virtual size)
> (II) MACH64(0): Not using default mode "1152x864" (width too large for
> virtual size)
> (II) MACH64(0): Not using default mode "576x432" (hsync out of range)
> (II) MACH64(0): Not using default mode "1400x1050" (width too large
> for virtual size)
> (II) MACH64(0): Not using default mode "700x525" (hsync out of range)
> (II) MACH64(0): Not using default mode "1400x1050" (width too large
> for virtual size)
> (II) MACH64(0): Not using default mode "700x525" (hsync out of range)
> (II) MACH64(0): Not using default mode "1400x1050" (width too large
> for virtual size)
> (II) MACH64(0): Not using default mode "700x525" (hsync out of range)
> (II) MACH64(0): Not using default mode "1400x1050" (width too large
> for virtual size)
> (II) MACH64(0): Not using default mode "700x525" (hsync out of range)
> (II) MACH64(0): Not using default mode "1440x900" (width too large for
> virtual size)
> (II) MACH64(0): Not using default mode "1600x1024" (width too large
> for virtual size)
> (II) MACH64(0): Not using default mode "800x512" (hsync out of range)
> (II) MACH64(0): Not using default mode "1680x1050" (width too large
> for virtual size)
> (II) MACH64(0): Not using default mode "840x525" (hsync out of range)
> (II) MACH64(0): Not using default mode "1920x1200" (insufficient
> memory for mode)
> (II) MACH64(0): Not using default mode "960x600" (hsync out of range)
> (II) MACH64(0): Not using default mode "1920x1200" (insufficient
> memory for mode)
> (II) MACH64(0): Not using default mode "960x600" (hsync out of range)
> (II) MACH64(0): Not using default mode "1920x1440" (insufficient
> memory for mode)
> (II) MACH64(0): Not using default mode "960x720" (bad mode
> clock/interlace/doublescan)
> (II) MACH64(0): Not using default mode "2048x1536" (insufficient
> memory for mode)
> (II) MACH64(0): Not using default mode "1024x768" (bad mode
> clock/interlace/doublescan)
> (II) MACH64(0): Not using default mode "2048x1536" (insufficient
> memory for mode)
> (II) MACH64(0): Not using default mode "1024x768" (bad mode
> clock/interlace/doublescan)
> (II) MACH64(0): Not using default mode "2048x1536" (insufficient
> memory for mode)
> (II) MACH64(0): Not using default mode "1024x768" (bad mode
> clock/interlace/doublescan)
> (--) MACH64(0): Virtual size is 1024x768 (pitch 1024)
> (**) MACH64(0): *Driver mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz
> (II) MACH64(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768
> 771 777 806 -hsync -vsync (48.4 kHz)
> (**) MACH64(0): *Driver mode "1024x768": 78.8 MHz, 60.1 kHz, 75.1 Hz
> (II) MACH64(0): Modeline "1024x768"x75.1 78.80 1024 1040 1136 1312 768
> 769 772 800 +hsync +vsync (60.1 kHz)
> (**) MACH64(0): *Driver mode "1024x768": 75.0 MHz, 56.5 kHz, 70.1 Hz
> (II) MACH64(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768
> 771 777 806 -hsync -vsync (56.5 kHz)
> (**) MACH64(0): *Driver mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz
> (II) MACH64(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768
> 771 777 806 -hsync -vsync (48.4 kHz)
> (**) MACH64(0): *Driver mode "1024x768": 63.5 MHz, 47.8 kHz, 59.9 Hz
> (II) MACH64(0): Modeline "1024x768"x59.9 63.50 1024 1072 1176 1328 768
> 771 775 798 -hsync +vsync (47.8 kHz)
> (**) MACH64(0): *Default mode "1024x768": 78.8 MHz, 60.0 kHz, 75.0 Hz
> (II) MACH64(0): Modeline "1024x768"x75.0 78.75 1024 1040 1136 1312 768
> 769 772 800 +hsync +vsync (60.0 kHz)
> (**) MACH

Re: reinstalling X.Org server

2009-01-30 Thread Ron Johnson

On 01/30/2009 04:18 PM, Francesco Pietra wrote:

Is it possible to reinstall X.Org server on a multisocket dual-opteron
computer running amd64 lenny?

Why? Failure of a DIMM bank did no more allow to launch amd64. Removed
the faulty slots, amd64 could be launched and the system seemed to be
in order. Filled the empty bank with fresh DDR1 ECC, the total memory
increased correspondingly. Again, it was now possible to carry out
sophisticated chemical calculations.

However, needing now to check 3D molecular structures, I found that
"startx" does not launch X anymore, X only appearing as a flash at the
bottom of the screen.  I checked many X-related files against a i386
lenny, ssh linked, computer (in particular /etc/X11/xorg.conf), don't
detecting damaged lines. I did not carry out a checksum. Command:

tail --lines 200 /var/log/Xorg.0.log|grep EE

was not much informative, as shows below between === lines.

I suspect that one or more X-related files were damaged as a
consequence of the RAM problems above.

Thanks
francesco pietra.


(II) MACH64(0): Not using default mode "1920x1440" (insufficient
memory for mode)
(II) MACH64(0): Not using default mode "960x720" (bad mode

[snip]

drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: Open failed

Backtrace:
0: X(xf86SigHandler+0x6a) [0x48dd0a]
1: /lib/libc.so.6 [0x2b1686b4ef60]

Fatal server error:
Caught signal 11. Server aborting
==


I'd reinstall the whole system.

--
Ron Johnson, Jr.
Jefferson LA  USA

"I am not surprised, for we live long and are celebrated poopers."


--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



reinstalling X.Org server

2009-01-30 Thread Francesco Pietra
Is it possible to reinstall X.Org server on a multisocket dual-opteron
computer running amd64 lenny?

Why? Failure of a DIMM bank did no more allow to launch amd64. Removed
the faulty slots, amd64 could be launched and the system seemed to be
in order. Filled the empty bank with fresh DDR1 ECC, the total memory
increased correspondingly. Again, it was now possible to carry out
sophisticated chemical calculations.

However, needing now to check 3D molecular structures, I found that
"startx" does not launch X anymore, X only appearing as a flash at the
bottom of the screen.  I checked many X-related files against a i386
lenny, ssh linked, computer (in particular /etc/X11/xorg.conf), don't
detecting damaged lines. I did not carry out a checksum. Command:

tail --lines 200 /var/log/Xorg.0.log|grep EE

was not much informative, as shows below between === lines.

I suspect that one or more X-related files were damaged as a
consequence of the RAM problems above.

Thanks
francesco pietra.


(II) MACH64(0): Not using default mode "1920x1440" (insufficient
memory for mode)
(II) MACH64(0): Not using default mode "960x720" (bad mode
clock/interlace/doublescan)
(II) MACH64(0): Not using default mode "1280x768" (width too large for
virtual size)
(II) MACH64(0): Not using default mode "1280x800" (width too large for
virtual size)
(II) MACH64(0): Not using default mode "1152x768" (width too large for
virtual size)
(II) MACH64(0): Not using default mode "1152x864" (width too large for
virtual size)
(II) MACH64(0): Not using default mode "576x432" (hsync out of range)
(II) MACH64(0): Not using default mode "1400x1050" (width too large
for virtual size)
(II) MACH64(0): Not using default mode "700x525" (hsync out of range)
(II) MACH64(0): Not using default mode "1400x1050" (width too large
for virtual size)
(II) MACH64(0): Not using default mode "700x525" (hsync out of range)
(II) MACH64(0): Not using default mode "1400x1050" (width too large
for virtual size)
(II) MACH64(0): Not using default mode "700x525" (hsync out of range)
(II) MACH64(0): Not using default mode "1400x1050" (width too large
for virtual size)
(II) MACH64(0): Not using default mode "700x525" (hsync out of range)
(II) MACH64(0): Not using default mode "1440x900" (width too large for
virtual size)
(II) MACH64(0): Not using default mode "1600x1024" (width too large
for virtual size)
(II) MACH64(0): Not using default mode "800x512" (hsync out of range)
(II) MACH64(0): Not using default mode "1680x1050" (width too large
for virtual size)
(II) MACH64(0): Not using default mode "840x525" (hsync out of range)
(II) MACH64(0): Not using default mode "1920x1200" (insufficient
memory for mode)
(II) MACH64(0): Not using default mode "960x600" (hsync out of range)
(II) MACH64(0): Not using default mode "1920x1200" (insufficient
memory for mode)
(II) MACH64(0): Not using default mode "960x600" (hsync out of range)
(II) MACH64(0): Not using default mode "1920x1440" (insufficient
memory for mode)
(II) MACH64(0): Not using default mode "960x720" (bad mode
clock/interlace/doublescan)
(II) MACH64(0): Not using default mode "2048x1536" (insufficient
memory for mode)
(II) MACH64(0): Not using default mode "1024x768" (bad mode
clock/interlace/doublescan)
(II) MACH64(0): Not using default mode "2048x1536" (insufficient
memory for mode)
(II) MACH64(0): Not using default mode "1024x768" (bad mode
clock/interlace/doublescan)
(II) MACH64(0): Not using default mode "2048x1536" (insufficient
memory for mode)
(II) MACH64(0): Not using default mode "1024x768" (bad mode
clock/interlace/doublescan)
(--) MACH64(0): Virtual size is 1024x768 (pitch 1024)
(**) MACH64(0): *Driver mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz
(II) MACH64(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768
771 777 806 -hsync -vsync (48.4 kHz)
(**) MACH64(0): *Driver mode "1024x768": 78.8 MHz, 60.1 kHz, 75.1 Hz
(II) MACH64(0): Modeline "1024x768"x75.1 78.80 1024 1040 1136 1312 768
769 772 800 +hsync +vsync (60.1 kHz)
(**) MACH64(0): *Driver mode "1024x768": 75.0 MHz, 56.5 kHz, 70.1 Hz
(II) MACH64(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768
771 777 806 -hsync -vsync (56.5 kHz)
(**) MACH64(0): *Driver mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz
(II) MACH64(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768
771 777 806 -hsync -vsync (48.4 kHz)
(**) MACH64(0): *Driver mode "1024x768": 63.5 MHz, 47.8 kHz, 59.9 Hz
(II) MACH64(0): Modeline "1024x768"x59.9 63.50 1024 1072 1176 1328 768
771 775 798 -hsync +vsync (47.8 kHz)
(**) MACH64(0): *Default mode "1024x768": 78.8 MHz, 60.0 kHz, 75.0 Hz
(II) MACH64(0): Modeline "1024x768"x75.0 78.75 1024 1040 1136 1312 768
769 772 800 +hsync +vsync (60.0 kHz)
(**) MACH64(0): *Default mode "1024x768": 75.0 MHz, 56.5 kHz, 70.1 Hz
(II) MACH64(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768
771 777 806 -hsync -vsync (56.5 kHz)
(**) MACH64(0): *Default mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz
(II) MACH64(0): Modeline "102