Bug 7919 - Installation not possible when using PGX32/PCI framebuffer as only fb in system
Summary: Installation not possible when using PGX32/PCI framebuffer as only fb in system
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: installer
Version: 6.1
Hardware: sparc
OS: Linux
Target Milestone: ---
Assignee: Jay Turner
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-12-21 02:13 UTC by Bill Bradford
Modified: 2015-01-07 23:40 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-01-27 18:06:49 UTC

Attachments (Terms of Use)

Description Bill Bradford 1999-12-21 02:13:54 UTC
I've got a pretty vanilla Ultra5/270 (192mb RAM, 8.4gig HD, 40x IDE
CD-ROM), with the built-in PGX (8bit) framebuffer and also a TechSource
Raptor (aka Sun PGX32) PCI 24bit framebuffer.  According to the "READ ME"
sheet that came with the Deluxe RedHat 6.1/SPARC boxed set, the PGX32/PCI
framebuffer is supported.

However, I've got my Ultra5 configured (as per Sun's installation
instructions) to use the PGX32 as the primary console / only framebuffer
in the system (it skips over the onboard PGX 8bit framebuffer during a
device-probe).  This appears to be a problem - I can do "boot cdrom" just
fine and get the text screen that tells me to press ENTER or type "text",
etc. - but if I do either of these (press ENTER for the graphical
install, or "text"ENTER for the old-style install), the machine starts to
read off of the CD, the screen goes blank, and the power light on the
monitor (Sun GDM20D10, connected to the Ultra5 via the Composite Video
13W3-HD15 adapter) starts blinking, indicating a loss of signal.  At this
point the only way to recover is to physically turn off the power toggle
switch at the back of the system.  Neither blindly doing STOP-A and then
"reset"<enter>, or hitting <shift>-<power key> on the Type 6 keyboard will
do anything.

I'd consider this pretty serious, as it prevents an install on an Ultra5.


Comment 1 Bill Bradford 2000-01-14 23:13:59 UTC
Are y'all ever gonna even look at this one, or are you just gonna ignore it?
I'd really like to run RH on what is supposedly a suported platform...

Comment 2 Bill Bradford 2000-01-27 18:06:59 UTC
davem solved this one - the way that Sun tells you how to disable the onboard
framebuffer conflicts with the way that RedHat probes the hardware.  Problem

Comment 3 Bill Bradford 2000-02-04 16:35:59 UTC
From Dave Miller
(here's the solution):

How did you "disable" the onboard mach64?
Did you do it by changing pcia-probe-list or pcib-probe-list
firmware environment variables?  If so, don't do that.

Unfortunately this is how Sun's documentation which comes with
the PGX32 states you should make the PGX32 your console.  Revert
pcia-probe-list and pcib-probe-list to their original settings
("1,2,3,4" and "1,2,3" respectively) and instead do this:

1) Find the "TSI,gfxp" device in the firmware device tree,
   there is a fast way to do this, with the "display" command
   or something like this but here is how bozos like me do
   it the hard way.  (neat trick of the day, if you forget some
   firmware command word, but know some substring of it, you
   can do a grep on the entire firmware forth vocabulary with
   the "sifting" command, such as "sifting display")

   Get to the "ok" prompt, and walk around the device tree with
   "cd xxx" and "ls" commands, start at root with "cd /".

   Go into the PCI bus tree, with "cd pci".

   Next go into the PCI bridge where expansion PCI cards
   live, with "cd pci@1"  ("pci@1,1" are where onboard
   devices live fyi)

   Find the "TSI,gfxp" node, cd into it.  Now type "pwd"
   Write this output down.

2) Take the device path obtained in #1 and set your console
   to it like this:  "setenv output-device $TSI_PATH"
   Where $TSI_PATH is replaced with the path to the PGX32

"reset" and you're in buisness.

For the intellectually curious, these pci{a,b}-probe-list environment
variables are Sun's awful way of "hiding" devices from the OS.  It
works for Solaris because they use only the firmware software device
tree for probing, it fails for Linux which actually probes the raw
hardware to find PCI devices.  So if you try to "hide" devices, Linux
will see it but won't have critical information it needs from the
firmware device tree, and the card won't be initialized as it would
be if the firmware had probed it at all.

This issue comes up on CP1400/CP1500 compact-PCI machines from
Sun Microelectronics as well, they do it there to try and hide
the second onboard ethernet interface if you have not purchased
the machine with the I/O expansion board which is where the
twisted-pair jack for the second ethernet is.

Note You need to log in before you can comment on or make changes to this bug.