Subject: Re: Trouble with xfree86
To: None <port-alpha@NetBSD.org>
From: Eike Dehling <e.e.dehling@student.utwente.nl>
List: port-alpha
Date: 03/29/2005 02:39:45
Lars Nordlund wrote:
> On Tue, 2005-03-22 at 18:11 +0100, Eike Dehling wrote:
>
>>Unfortunately, no. After i reboot the file is empty. The file gets wiped
>>out by the fsck on the next boot i suspect, since fsck says something
>>about removing some unrefenrenced blocks? I tried mounting the
>>file-system with the 'sync' option too, to no effect, except for
>>everything being a lot slower. :(
>
> What you can do is to have an ssh session running from another machine
> and use a shell loop like this:
>
> (zsh syntax, change x-log-file to the actual X log file)
> # rm x-log-file
> # while true ; do tail -f x-log-file ; done
>
> And at the same time run startx locally on the Alpha. Immediately when
> the file is created by XFree86 it will be tailed in your ssh shell. I
> have done exactly this a while back and it worked for me. I was
> debugging the same kind of problem you are seeing now.
Thank you, yes this worked. Though nothing usefull showed up in the
log-file.
> I could not see which graphics card you are using? Currently I think S3
> boards are a no-go on NetBSD/Alpha. I have tried two different S3 boards
> without having any luck. Right now I am using an ATI Radeon 9200 PCI on
> my 164LX. I have also verified that an ATI Rage 128 works like a charm.
It's a g200, it works nicely in debian and after the changes mentioned
below also somewhat on netbsd.
On other notice, i think i might have found (some) light; as mentioned
in an email linked in a message i got privately, i edited alpha's
interrupt.c, and made machine-checks non-fatal, basically i print them
but ignore them for the rest (removed the last line 'panic()' in the
'machine_check()' function). Now i can see the messages on the console,
since the machine won't lock up anymore in a state where xfree has taken
control of the gfx-card.
After this change to interrupt.c XFree86 starts, though the videomode
settings seemed rather broken; but that will probably be a configuration
error on my side.
Any idea what the machine checks actually mean? Code '0x98' doesn't mean
anything to me ... google didn't find anything usefull.
I'll try finding out what causes these machine checks; i added the
"option 'NoInt10'" to XFree86Config already, but it didn't help.
Greetings,
Eike.