Port-macppc archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: X11 configuration



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Apr 9, 2009, at 10:01 PM, T. M. Pederson wrote:

On Thu, 9 Apr 2009 20:39:39 -0400
Michael <macallan%netbsd.org@localhost> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Apr 9, 2009, at 5:32 PM, T. M. Pederson wrote:

On Fri, 27 Mar 2009 16:23:50 -0400
Michael <macallan%netbsd.org@localhost> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Mar 26, 2009, at 10:31 AM, T. M. Pederson wrote:
[...]
My case is a bit different: Mac Mini (Radeon 9200)

I'd gone at the config with xorgconfig, which, of course, has
the same wskbd issue.

The current state is:
Using startx gets the machine to hang.
Setting xdm=YES and wscons=YES gets the machine to hang.
Setting xdm=YES and wscons=NO gets a login screen, but as soon
as I log in, the system hangs. At least this approach gets
results in the logs.

I suggest you have a look at your Xorg logfile - according to the one
you attached the Xserver is up and running. Apparently it's using a
video mode your monitor doesn't like. Here's the relavant bit:

I don't know what "doesn't like" is supposed to mean in this context.
I'd expect a sync issue of some sort, but what?

Something it can't display.

Except that at the time these logs were generated, it did display (xdm
login window). The mouse and keyboard worked normally, too.

Thanks for finally telling me.

(II) RADEON(0): EDID vendor "PCK", prod id 226
(II) RADEON(0): DDCModeFromDetailedTiming: 1920x1200 Warning: We only
handle seperate sync.
(II) RADEON(0): Output: S-video, Detected Monitor Type: 0
(II) RADEON(0): Output DVI-0 connected
(II) RADEON(0): Output S-video disconnected
(II) RADEON(0): Output DVI-0 using initial mode 1920x1200
Also:
(WW) RADEON(0): Video BIOS not detected, using default clock
settings!
(II) RADEON(0): Probed PLL values: xtal: 27.000000 Mhz, sclk:
249.750000 Mhz, mclk: 190.125000 Mhz
(II) RADEON(0): PLL parameters: rf=2700 rd=12 min=12500 max=35000;
xclk=10514

27MHz reference clock is very common but may or may not be what your
radeon is using. Please check your OpenFirmware device tree, the
radeon's node should have a property with the correct clock. If you
don't know what to look for please run ofctl -p and post the output.

The dev tree lists it as 27MHz.

I don't see how either of these cause the machine to lock up on login. Both look like elements that I'd expect would cause the display to not
work at all.

Exactly what I think happened - there is no lockup, just an unusable
display. Without network plugged in you couldn't really tell the
difference.

What? I had an ssh (and (k)telnet) session open at the time this happened. The whole system locked up. The ssh session froze. The (k)telnet session froze. The machine STOPPED responding to ANY attempts to contact it over
the network; over the CAT5 cable plugged into the machine.

Another thing you never told me.

[...]
wscons doesn't matter, as long as xdm login works, but what *should*
wscons
be on macppc these days?

I'm not sure what exactly you're trying to ask. Macppc has been all
wscons for a long time.

I'm trying to ask, since macppc is now wscons, how do I get xdm to
work with that?

Again, it has nothing to do with wscons.

Huh? X11 only works in any way when wscons=NO. Any and all attempts to
start X when wscons=YES result in a complete lockup. I don't care that
it's not the fault of wscons. How do I get X to work WITH wscons? If
X cannot work with wscons, then I submit that macppc is not all wscons.

Thanks for finally sharing some useful details.
Things crash if you have virtual consoles ( you have wscons with or without them ) - weird, works fine here with virtual consoles. From startx, I never tried xdm.

So, initially xdm manages to start the Xserver but dies when trying to run a session. Also, startx dies when trying to run a session.
Anything else you didn't tell me?

Anyway, when running startx - does the Xserver die right away or do you get the usual default black & white background first? What happens if you just start the Xserver itself, then start an xterm via ssh and close it again? I suspect your session dies and for some reason the Xserver manages to provoke a panic on exit.
Does the mini have a reset button?
Try this before startx:
sysctl -w ddb.commandonenter=reboot
If it's a panic that should reboot the machine and hopefully preserve the panic message in the dmesg buffer.

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBSd+ZlMpnzkX8Yg2nAQLAnAgAo6oR9clJIl+nFUiqtH2DiS8MsL0Btqin
yqxjDEivIy0r3/ZmQs3WM5YXVFw6/8sE/lkUqyG41tMcvhBbjche5k3u3tFsIYvl
iDBHyjV1jxhxxndmF92RxbFBCrHdFYNgj5MqgjeEw9kIbd0O58lv+Y4yW7P0sVSw
KPDgYampGL8rRiFXOk9Uv9XfVGG51mTXowJ8vcafussnHdfyGhO0dAO8wcOBH1/B
VV9Rtgzlnxyb5/0bTxZ7mxJ12cnWwG97wN+Zdpvj7tjpg9WOtnOjYO8n2c2nYg89
gRMG5E0jhvmWNjmmPa6iNc9TiNt8LMzbc87kasoj58U7Zst8rHQS1g==
=Xs21
-----END PGP SIGNATURE-----


Home | Main Index | Thread Index | Old Index