Port-macppc archive

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

Re: X11 configuration

Hash: SHA1


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:

Hash: SHA1


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:

Hash: SHA1


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
(WW) RADEON(0): Video BIOS not detected, using default clock
(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;

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

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*
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

Version: GnuPG v1.4.7 (Darwin)


Home | Main Index | Thread Index | Old Index