Hide Forgot
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. Bill
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...
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 solved.
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 card. "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.