<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
> >> pseudo-device: fcp0<br>> >> fcp0 is /pseudo/fcp@0<br>> >> NOTICE: Couldn't set value<br>> >> (../../sun/io/audio/sada/drv/audiocs/audio_4231.c, Line #1759 0x00 0x88)<br>> >> audio may not work correctly until it is stopped and restarted<br>> >> audiocs0 at sbus0: SBus slot 4 0xc000000 SBus level 5 sparc ipl 9<br>> >> audiocs0 is /iommu@0,10000000/sbus@0,10001000/SUNW,CS4231@4,c000000<br>> >><br>> >> Not having anything to compare to, are the tcx0 and sbusmem entries<br>> >> correct?<br>> ><br>> > Oh that's interesting - I always thought that the hangs were being caused by<br>> > OpenBIOS reporting 4 CPUs by default whilst QEMU only provides 1.<br>> <br>> Where does it report 4 CPUs? I see only one in the device tree.<br>> <br>> > But this<br>> > trace strongly points towards the audio driver being the culprit instead.<br>> <br>> To be honest I doubt it. I'd rather suspect networking problem with le<br>> (aka pcnet), which might be improperly initialized either in qemu or<br>> in OpenBIOS. OBP under qemu tries netboot first, so it initializes the<br>> le card before Solaris gets it. So the fact that the card is properly<br>> initialised under OBP may be just a co-incidence.<br>> <br>> Anyway it should be easy to check - just kick the audio out of the<br>> device tree. No recompilation of OpenBIOS should be necessary,<br>> something like<br>> <br>> cd /iommu@0,10000000/sbus@0,10001000/SUNW,CS4231@4,c000000<br>> " name" delete-property<br>> device-end<br>> boot cdrom:d -vs<br>> <br>> should do it.<br>> Nathan, can you check?<br>> <br>I regret to report that disabling as above neither the audio, nor the ledma and le, nor both, allow me to finish the boot. <br><br> </body>
</html>