Hi there,

I'm currently trying to get the 2008.11 release up and running on a new system 
and am having problems with getting the newly-installed OS to boot.

The motherboard is a Gigabyte GA-MA74GM-S2, which has an AMD 740G chipset and 
which is 'reported to work' on the OpenSolaris HCL - 
http://www.sun.com/bigadmin/hcl/data/systems/details/23318.html . I'm using the 
same processor described in the HCL submission, an Athlon X2 4850e. No other 
OSes are installed.

After enabling the VESA driver as described in the last post here: 
http://forums.opensolaris.com/thread.jspa?threadID=610&tstart=0&messageID=1510 
(the default 'radeon' driver causes X to bug out), I can boot from the Live CD 
and run the installer with no problems. However, after rebooting, the system 
does not boot successfully. If I select a text-mode boot, it hangs after the 
three-line kernel copyright notice.

On a verbose boot (adding -v to the kernel line in GRUB), the system hangs 
after the lines "applying workaround for CPU issue 6336786" and "applying 
workaround for CPU erratum 122". I'm running on the assumption that the problem 
lies here somewhere, although it's entirely possible I'm barking up the wrong 
tree.

CR 6336786 describes an issue with clock timing on single-socket, dual core 
systems with AMD processors: 
http://bugs.opensolaris.org/view_bug.do?bug_id=6336786 . It's listed as having 
been fixed a long time ago (snv_28). The 4850e is an old K8-core (i.e. 
pre-Barcelona) design, so I believe it will be affected by the problem 
described.

Things I have tried in BIOS:
- disabling the AMD Cool'n'Quiet function (no effect that I can see)
- locking the CPU clockspeed to the minimum, 1000MHz (bizarrely, this seems to 
speed up initial boot times, but the boot still hangs in the same place)
- disabling the HPET (no effect that I can see)

I've also tried booting with acpi-user-options set to 0x8, 0x4 and 0x2 as 
described in this thread: 
https://www.opensolaris.org/jive/message.jspa?messageID=313030#313030 with no 
effect. The kmdb commands described in the same thread don't seem to yield any 
more useful information.

Has anyone else ever seen anything like this? Does anyone have any ideas as to 
how I can go about troubleshooting the problem? I'd be happy to live with a 
nasty hack (like disabling one of the CPU cores) if it gets the system up and 
running.

Thanks in advance,
Liam McBrien
-- 
This message posted from opensolaris.org

Reply via email to