headers
John D. Baker | 5 Jul 2012 16:53

original iMac problems

I've finally been able to turn some attention to the problems with trying
to run NetBSD on my original iMac (MPC750, 233MHz).

Recent changes in -current related to machfb have had no noticable
effect.  If machfb attaches, the display is illegible.  One can type
blind at the keyboard and it responds, however.  As part of the test
procedure, I booted an up-to-date netbsd-4 build and the same problem
has been there at least since then.

For kernels with "genfb" available, it Just Works(tm).  The QVSS8x15
font is nice (in -current).  How does it decide which font to use when
multiple fonts are compiled in?  Is there a way to make it use a particular
font in spite of what it's own selection criteria indicated?

The other problem is that at some point between netbsd-4 and netbsd-5,
probing atabus* for devices hangs the system hard.  I've completed the
first two iterations of bisection as follows:

21-Sep-2007 0000Z (4.99.31) works
21-Apr-2008 0000Z (4.99.60) hangs

Currently rolling sources back to 27-Jan-2008 0000Z and will try again.

--

-- 
|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645
(Continue reading)

Permalink | Reply |
headers
Michael | 5 Jul 2012 20:49
Picon

Re: original iMac problems


Hello,

On Jul 5, 2012, at 10:53 AM, John D. Baker wrote:

> I've finally been able to turn some attention to the problems with  
> trying
> to run NetBSD on my original iMac (MPC750, 233MHz).
>
> Recent changes in -current related to machfb have had no noticable
> effect.  If machfb attaches, the display is illegible.  One can type
> blind at the keyboard and it responds, however.  As part of the test
> procedure, I booted an up-to-date netbsd-4 build and the same problem
> has been there at least since then.

Black, garbled, out of sync or something completely different?
It either picks the wrong mode, fails to set it up properly, or  
something completely different. Would be nice to nail down which one  
it is first.

> For kernels with "genfb" available, it Just Works(tm).

Yeah, it just uses whatever mode the firmware set up

> The QVSS8x15 font is nice (in -current).  How does it decide which  
> font to use when
> multiple fonts are compiled in?  Is there a way to make it use a  
> particular
> font in spite of what it's own selection criteria indicated?
(Continue reading)

Permalink | Reply |
headers
John D. Baker | 5 Jul 2012 22:29

Re: original iMac problems

On Thu, 5 Jul 2012, Michael wrote:

> Black, garbled, out of sync or something completely different?

In-sync.
Bottom 3/4:  black.
Top 1/4: left 1/4: garbled white/grey/(green?) scintilating pixels
Top 1/2: rigght 3/4: alternately white/grey vertical stripes, solid white
or solid black.

Similar to what's shown here:

   http://mail-index.netbsd.org/port-macppc/2010/10/02/msg001160.html

From my machine's "/var/run/dmesg.boot" when machfb is allowed to attach
(from a 6.99.8 kernel):

   machfb0 at pci0 dev 18 function 0: ATI Technologies 3D Rage Pro (rev. 0x5c)
   machfb0: 16 MB aperture at 0x81000000, 4 KB registers at 0x80881000
   machfb0: 128 KB ROM at 0x00000000
   max_dotclock according to supported modes: 78750
   machfb0: 6144 KB SGRAM 98.924 MHz, maximum RAMDAC clock 230 MHz
   machfb0: initial resolution 1024x768 at 8 bpp
   wsdisplay0 at machfb0 kbdmux 1: console (default, vt100 emulation)
   wsmux1: connecting to wsdisplay0
   direct rendering for machfb0 unsupported

See my thread here:

   http://mail-index.netbsd.org/port-macppc/2010/03/11/msg001042.html
(Continue reading)

Permalink | Reply |
headers
Mouse | 5 Jul 2012 23:20

Re: original iMac problems

> In-sync.
> Bottom 3/4:  black.
> Top 1/4: left 1/4: garbled white/grey/(green?) scintilating pixels
> Top 1/2: rigght 3/4: alternately white/grey vertical stripes, solid white
> or solid black.

This sounds to me like the video output hardware running at a different
configuration from whatever's driving the data in the framebuffer.
I've seen similar things when, for example, switching a SPARC
cgfourteen from 8bpp console to 32bpp X, or when starting X on a peecee
console.  In my experience they usually make sense when looked at as
two things treating the same memory differently....

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
Permalink | Reply |
headers
Michael | 6 Jul 2012 03:13
Picon

Re: original iMac problems


Hello,

On Jul 5, 2012, at 4:29 PM, John D. Baker wrote:

> On Thu, 5 Jul 2012, Michael wrote:
>
>> Black, garbled, out of sync or something completely different?
>
> In-sync.
> Bottom 3/4:  black.
> Top 1/4: left 1/4: garbled white/grey/(green?) scintilating pixels
> Top 1/2: rigght 3/4: alternately white/grey vertical stripes, solid  
> white
> or solid black.
>
> Similar to what's shown here:
>
>  http://mail-index.netbsd.org/port-macppc/2010/10/02/msg001160.html

Weird, on first glance it looks like the framebuffer is in 24bit mode  
while the rest is in 8 bit. Probably missing some drawing engine  
initialization.

> From my machine's "/var/run/dmesg.boot" when machfb is allowed to  
> attach
> (from a 6.99.8 kernel):
>
>  machfb0 at pci0 dev 18 function 0: ATI Technologies 3D Rage Pro  
> (rev. 0x5c)
(Continue reading)

Permalink | Reply |
headers
John D. Baker | 6 Jul 2012 07:14

Re: original iMac problems

On Thu, 5 Jul 2012, Michael wrote:

> On Jul 5, 2012, at 4:29 PM, John D. Baker wrote:
>> Similar to what's shown here:
>> 
>> http://mail-index.netbsd.org/port-macppc/2010/10/02/msg001160.html

Update:  On a -current system, instead of black, the bottom 3/4 of the
screen turns blue, such that the OF and early kernel messages are still
visible.  The top 1/4 of the screen is mostly alternating blue/white
vertical stripes with some phase changes as it approaches the lower
boundary.  The left-most 1/4 of this strip has more/wider white area
than blue and exhibits scintilating hash that presumably represent
the remaining output during boot.

> What happens if you start X and exit immediately? Does that result in
> a readable console with machfb? I bet it's something fairly trivial
> which would be easy to fix if I could just reproduce it.

From cold start, dropping into userconf to disable atabus, logging
in blind and typing 'startx'.

There's a flash of white at the right edge of the top 1/16 of the screen.
The screen goes completely black for a few seconds, then displays an
in-sync pattern of hash like art-deco fabric--very purple.  There's a
black band across the screen about 1/8 the way down about 3/8 screen
height.  There's a rectangle of grey hash almost 1/4 screen high and
1/2 screen wide located 1/8 screen from the left.

The X cursor never appears.  The keyboard is unresponsive at this
(Continue reading)

Permalink | Reply |
headers
Michael | 7 Jul 2012 03:25
Picon

Re: original iMac problems


Hello,

On Jul 6, 2012, at 1:14 AM, John D. Baker wrote:

>> What happens if you start X and exit immediately? Does that result in
>> a readable console with machfb? I bet it's something fairly trivial
>> which would be easy to fix if I could just reproduce it.
>
> From cold start, dropping into userconf to disable atabus, logging
> in blind and typing 'startx'.
>
> There's a flash of white at the right edge of the top 1/16 of the  
> screen.
> The screen goes completely black for a few seconds, then displays an
> in-sync pattern of hash like art-deco fabric--very purple.  There's a
> black band across the screen about 1/8 the way down about 3/8 screen
> height.  There's a rectangle of grey hash almost 1/4 screen high and
> 1/2 screen wide located 1/8 screen from the left.

So X doesn't get things right either? It should at the very least get  
its hash pattern all over the screen, in the right colours, and you  
have enough video memory to do 1024x768 in 24bit. Now we're officially  
entering twilight zone territory.
The reason why I asked this is this - I suspect we're not initializing  
enough of the drawing engine, and on other hardware this is no problem  
because the firmware did it for us. I wanted to see if X initializes  
it so machfb can work right after X exits.
Seriously, I've been using machfb ffor ages on various Sun and Apple  
branded cards and onboard video chips and I've never seen anything
(Continue reading)

Permalink | Reply |
headers
John D. Baker | 8 Jul 2012 07:06

Re: original iMac problems

On Fri, 6 Jul 2012, Michael wrote:

> So X doesn't get things right either? It should at the very least get its 
> hash pattern all over the screen, in the right colours, and you have enough 
> video memory to do 1024x768 in 24bit. Now we're officially entering twilight 
> zone territory.
> The reason why I asked this is this - I suspect we're not initializing enough 
> of the drawing engine, and on other hardware this is no problem because the 
> firmware did it for us. I wanted to see if X initializes it so machfb can 
> work right after X exits.

That machfb works if I first let MacOS X touch the hardware would seem
to support this.

> Any chance to mail me the Xorg.0.log?

Grab it here:

   http://bobdbob.com/~jdbaker/nbsd-debug/bondi-069908-machfb-Xorg.0.log

It is rather unremarkable until the very last line.

--

-- 
|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645
Permalink | Reply |
headers
John D. Baker | 6 Jul 2012 04:44

Re: original iMac problems

On Thu, 5 Jul 2012, John D. Baker wrote:

> The other problem is that at some point between netbsd-4 and netbsd-5,
> attaching atabus* hangs the system hard.  I've completed the first two
> iterations of bisection as follows:
>
> 21-Sep-2007 0000Z (4.99.31) works
> 21-Apr-2008 0000Z (4.99.60) hangs
>
> Currently rolling sources back to 27-Jan-2008 0000Z and will try again.

27-Jan-2008 0000Z (4.99.50) hangs
17-Oct-2007 0000Z (4.99.34) works
ppcoea-renovation branch is merged
18-Oct-2007 0000Z (4.99.34) probes atabus* but panics after probing
                             genfb0:

genfb0 at pci0 dev 10 function 0: ATI Technologies 3D Rage Pro
panic: no width property
Stopped in pid 0,1 (system) at  netbsd:cpu_Debugger+0x10:         lwz      r0, r1, 0x14
db>

At this stage, the keyboard doesn't work, so the only way out is to
poke the reset switch...

(I'm booting a kernel which simply includes GENERIC and turns on various
debugging options and explicitly excludes non-working display devices
(machfb in my case).  As with DDB, userconf lacks a working keyboard,
so devices can't be disabled at runtime in a normal GENERIC kernel.)
(Continue reading)

Permalink | Reply |
headers
John D. Baker | 6 Jul 2012 06:13

Re: original iMac problems

On Thu, 5 Jul 2012, John D. Baker wrote:

> The kernel continues enumerating devices for some time after probing
> atabus[01] at wdc[01], finally hanging after printing:
>
>  scsibus0: waiting 2 seconds for devices to settle.

In prior threads, in kernels with working keyboard in userconf modes,
it was sufficient to issue "disable atabus" and the system wouldn't
hang.  With the kernel sources I'm testing (immediately post-
ppcoea-renovation merge), the keyboard doesn't work in userconf mode.
Therefore, only by excuding "wdc* at obio?" from my kernel config can
I get a kernel that doesn't hang.

In the latter case, anything providing the "ata?" pseudo-parent node
has been eliminated , so there's nothing to which the "atabus*"
(pseudo-?)child node can attach.

In the former case (as with kernels built from -current), the underlying
device with its pseudo-parent ata? node is still there, but with atabus*
disabled, it simply won't attach to the still-available pseudo-parent.

Before plastering printf()s everywhere, just trying to see if the above
behavior suggests files to concentrate on (obviously macppc/wdc_obio.c).

--

-- 
|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645
(Continue reading)

Permalink | Reply |

Gmane