headers
kaminski | 7 Oct 2010 12:50

Building XServer

Hello List,

finally i built a xserver for my VAXStation 4000/90. But it causes the 
kernel to dump core (well, on vax it actually doesn't...).
After this, i rebuilt everything with DEBUG, got a headcrash, moved to 
another town, rebuilt everything again and finally got a debug output of 
the crash.

i applied the patches, which Michael sent to the list.

my mk.conf contains the following lines:
X11FLAVOUR=Xorg
MKX11=yes

my kernel config file and dmesg output is attached.

debug output:
-------------

root <at> vs4090:/root# ./Xorg2

X.Org X Server 1.6.3
Release Date: 2009-7-7
X Protocol Version 11, Revision 0
Build Operating System: NetBSD/vax  -
Current Operating System: NetBSD vs4090 5.1_RC4 NetBSD 5.1_RC4 
(VS4090_DEBUG) #2: Thu Oct  7 04:53:34 UTC 2010 
root <at> vs4090:/usr/src/sys/arch/vax/compile/VS4090_DEBUG vax
Build Date: 09 July 2009  12:14:03AM
(Continue reading)

Permalink | Reply | 7 comments |
headers
Johnny Billquist | 7 Oct 2010 13:55
Picon

Re: Building XServer

Hi.
I wouldn't think the Xorg Xserver would work on a VAX, so I'm not surprised.
You probably need to find some DEC based X server to have any hopes, I 
think. But I could remember things very wrong, as usual... :-)

     Johnny

On 10/07/10 12:50, kaminski <at> SDF-EU.ORG wrote:
> Hello List,
>
> finally i built a xserver for my VAXStation 4000/90. But it causes the 
> kernel to dump core (well, on vax it actually doesn't...).
> After this, i rebuilt everything with DEBUG, got a headcrash, moved to 
> another town, rebuilt everything again and finally got a debug output 
> of the crash.
>
> i applied the patches, which Michael sent to the list.
>
> my mk.conf contains the following lines:
> X11FLAVOUR=Xorg
> MKX11=yes
>
> my kernel config file and dmesg output is attached.
>
> debug output:
> -------------
>
> root <at> vs4090:/root# ./Xorg2
>
> X.Org X Server 1.6.3
(Continue reading)

Permalink | Reply | 6 comments |
headers
der Mouse | 7 Oct 2010 15:02

Re: Building XServer

[top-posting damage repaired manually]

>> finally i built a xserver for my VAXStation 4000/90.  But it causes
>> the kernel to dump core (well, on vax it actually doesn't...).

That probably indicates a kernel bug, I'd say; unless the server is
doing something dodgy like mucking about with /dev/mem, it shouldn't be
capable of panicking the kernel.

Your stack trace makes it look like a bug in the spx driver, at a
five-second glance.  I can't say much more, because both your OS and
your X are versions I've never played with at all, much less on a VAX.

That aside....

> I wouldn't think the Xorg Xserver would work on a VAX, so I'm not
> surprised.

Perhaps not out of the box, but, unless they've broken something or the
framebuffer is unusually funky, it would be fairly easy to make it
work.  While I've worked with MIT X, not x.org (and definitely not the
crawling design horror that is XFree86), I have done, for it, three
custom ddx layers - enough to know that getting a simple one working is
not really that complicated.  (What were the three?  NeXT 2bpp
greyscale, Sun S24, and Sun cg14.)  Given hardware, leisure, and
motivation, I could probably do it within a day or two of having the
system set up and my tools installed, so I'd estimate a week or two for
someone decent but starting from scratch.  (Unless the framebuffer
doesn't have a dumb-array-of-pixels mode, in which case it'd take me
longer.)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Johnny Billquist | 7 Oct 2010 15:48
Picon

Re: Building XServer

On 10/07/10 15:02, der Mouse wrote:
> [top-posting damage repaired manually]
>    

That's ok. I randomly top-post or post inline nowadays, on what I think 
others in the thread might be doing. I'll happily switch, since I don't 
have a strong preference for either, except when discussions become 
complex and intervowen, at which point top posting just don't work. :-)

>>> finally i built a xserver for my VAXStation 4000/90.  But it causes
>>> the kernel to dump core (well, on vax it actually doesn't...).
>>>        
> That probably indicates a kernel bug, I'd say; unless the server is
> doing something dodgy like mucking about with /dev/mem, it shouldn't be
> capable of panicking the kernel.
>
> Your stack trace makes it look like a bug in the spx driver, at a
> five-second glance.  I can't say much more, because both your OS and
> your X are versions I've never played with at all, much less on a VAX.
>
>    

I thought the X server did poke in /dev/mem or similar, since it probes 
and plays with the hardware rather direct. It also tries to find the PCI 
memory mapping (or the fact that there aren't any, as in this case).
Which is also why I wasn't surprised that it didn't work. The last time 
I heard anyone running any X server on a VAX, it was with DECs X server, 
which knew about the specific graphic controllers that exist there.

So I would suspect that the Xserver tries to poke at the spx driver, but
(Continue reading)

Permalink | Reply | 1 comment |
headers
kaminski | 7 Oct 2010 16:26

Re: Building XServer

Hi,

On Thu, 7 Oct 2010, Johnny Billquist wrote:
> Hi.
> I wouldn't think the Xorg Xserver would work on a VAX, so I'm not surprised.
> You probably need to find some DEC based X server to have any hopes, I think. 
> But I could remember things very wrong, as usual... :-)
>
>    Johnny

I'm aware that there are bugs in the spx driver, e.g. it doesn't work as 
the console. But since the SPX-driver implements wsfb, and 
there is a wsfb-XServer (which in fact i am trying to get working), i am 
pretty sure, that there isn't much more work todo.

I suspect a DEC based X server is out of the question. As far i remember 
Ultrix had never a version for the 4000, and OpenVMS... well it works, but 
i don't think anyone has ever dared to think about something like 
COMPAT_VMS ;-)

Hmm, maybe i can provide some additional data, from the debugger?

Bye,

Lukas
Permalink | Reply | 2 comments |
headers
der Mouse | 7 Oct 2010 16:42

Re: Building XServer

> I thought the X server did poke in /dev/mem or similar, since it
> probes and plays with the hardware rather direct.

Only on badly-designed systems.  It should be using mmap() on the
device to map the regions of interest, rather than making stupid
assumptions about the machine's physical memory layout.

And it is, on the systems I use, except for one where the only working
X server I know of is XFree86 - it's architecturally a peecee, and I
mostly don't use X on peecees because it means XFree86, but this one
has enough other benefits to make me overlook it.  Fortunately I'm
lucky enough that it mostly Just Works.

> It also tries to find the PCI memory mapping (or the fact that there
> aren't any, as in this case).

That sounds like XFree86, and is the sort of thing that led me to call
it a crawling design horror.  Even discovering whether there _is_ a PCI
bus is way, way out of scope for userland; the server has no business
doing any kind of bus enumeration - that's what the kernel is for.  An
architecture that requires the server to do muck about with that stuff
is Just Plain Broken.  If X.org has been corrupted enough by XFree86
that it pulls that sort of shenanigans, I would say it's reason to
scrap it and use something with non-insane design.

> Oh, no doubt you *could* make it work.  My thought was only that
> noone have.

Likely.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hans Rosenfeld | 7 Oct 2010 17:08

Re: Building XServer

On Thu, Oct 07, 2010 at 02:26:56PM +0000, kaminski <at> SDF-EU.ORG wrote:
> I'm aware that there are bugs in the spx driver, e.g. it doesn't work as 
> the console.

I'm pretty sure I fixed that problem a few months ago, at least on
-current.

> But since the SPX-driver implements wsfb, and 
> there is a wsfb-XServer (which in fact i am trying to get working), i am 
> pretty sure, that there isn't much more work todo.

Probably not much work, but work anyway. I'm pretty sure you found a new
bug in the SPX driver. In fact I would have been surprised if it would
have just worked :)

Hans

--

-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown
Permalink | Reply | 1 comment |
headers
kaminski | 7 Oct 2010 19:14

Re: Building XServer


On Thu, 7 Oct 2010, Hans Rosenfeld wrote:
> On Thu, Oct 07, 2010 at 02:26:56PM +0000, kaminski <at> SDF-EU.ORG wrote:
>> I'm aware that there are bugs in the spx driver, e.g. it doesn't work as
>> the console.
>
> I'm pretty sure I fixed that problem a few months ago, at least on
> -current.
>

Yes, it works on current, thanks! A backport for netbsd-5 would be great!

>> But since the SPX-driver implements wsfb, and
>> there is a wsfb-XServer (which in fact i am trying to get working), i am
>> pretty sure, that there isn't much more work todo.
>
> Probably not much work, but work anyway. I'm pretty sure you found a new
> bug in the SPX driver. In fact I would have been surprised if it would
> have just worked :)

>
>
> Hans
>
>
> -- 
> %SYSTEM-F-ANARCHISM, The operating system has been overthrown

Lukas
(Continue reading)

Permalink | Reply | 0 comments |
headers
kaminski | 10 Oct 2010 22:39

KGDB_DEVNAME on Vaxstation 4000

Hi,

i'm trying to build a kernel with remote debugger. What is the correct 
KGDB_DEVNAME,KGDB_DEVADDR on a VS4000/90?
Permalink | Reply | 0 comments |
headers
H. Abery | 16 Oct 2010 18:35
Picon
Favicon

I need your help...

Beloved,

My present condition is very unfortunate. I have been trying to contact you about a huge donation to be made
through you. Please reply for more information.

Remain Blessed
Mrs Abery
Permalink | Reply | 0 comments |

Gmane