Garrett D'Amore wrote: > [EMAIL PROTECTED] wrote: >> Well, after messing about with it a bit, the best I can figure is the >> thing is not deterministic. I was trying to see if between the PnP >> and Vzn settings in the BIOS, I could get it to hang. It's booting >> every time now. I did select HW defaults at one point from the BIOS, >> so maybe that changed something else I didn't spot. > > The switching back and forth in PnP is *meaningless*. Because, there > is some bug in the Toshiba BIOS were changing the value doesn't really > take effect unless a full power down is done. This includes removing > the battery physically from the system. The Toshiba M9 BIOS is kinda > funky here, and I've had a heard time qualifying this properly, but > lets just say that after switching to All, then back to PnP OS, the > problem I had with my particular device's BIOS settings went away.
Well, this may explain what I'm seeing then. I initially had hangs during xVM dom0 boot, but ever since messing with the BIOS it boots. One other Sun colleague, George Asaad, still has one in a hanging state. His is hanging like mine was, loading that ether_mac module. Now that I know xVM doesn't support MSI (thanks to Stuart's email), it's probably trying to initialize the device and never hearing back. Why it should go further after messing with the BIOS, I don't know. Maybe the device is further initialized to some point? We're at the edges of my understanding of how such things work... > Until I allowed the battery to drain fully. Then mysteriously it > reappeared, causing me about 3 days of painful debugging trying to > find a problem I thought was in my driver (SDcard), but which > ultimately boiled down to this weird BIOS thing. Setting the value > back to "All" cleared my problems up. Had you raised this issue with Toshiba? I think I know some folks who might be able to do so if you've not yet, but I don't want to cause any unnecessary noise (unless you think that's warranted as well). - Matt p.s.: I couldn't get my SDCard to work in either case, but I didn't mess with it that much. I probably missed something simple. > > -- Garrett >> >> virt-install prompts for HVM if Vzn is turned on -OR- off in the >> BIOS. I don't know what's going on there. >> >> More below... >> >> Juergen Keil wrote: >>> Matt Ingenthron wrote: >>> >>>> Garrett D'Amore wrote: >>>> >>>>> Matt Ingenthron wrote: >>>>> >>>>>> I'll do a live upgrade to 82, and hopefully that'll "just work" >>>>>> for me too. Thanks for looking into it Garrett. >>>>>> >>>>>> If you happen to think of any modifications you've made to the >>>>>> BIOS or anything like that, please let me know. I assume there >>>>>> are none and it's just bugs that have been squashed post build 79b. >>>>>> >>>>> The one thing that I've done is change the BIOS PnP OS setting so >>>>> that BIOS configures all devices. That is necessary for the >>>>> SDcard stuff. I don't think it makes a difference otherwise, but >>>>> maybe its something that Xen^WxVM is sensitive to. >>>>> >>>> Is that the "Device Configuration", where the choices are "Setup by >>>> OS" or "All"? Why can't they just call it PnP? >>>> >>>> I just changed that, and sure enough, I've booted under xVM. >>>> >>> >>> Hmm, is there any other driver sharing the interrupt vector with >>> the e1000g device? Run mdb -k and have a look at the ::interrupts >>> output, when not booted under xVM and with the BIOS PnP setting >>> reverted: >>> >>> echo ::interrupts | mdb -k >>> echo ::interrupts -d | mdb -k >>> >> >> I get "NOTICE: IRQ xxx shared" during boot under xVM, even though I'm >> not booting verbose so there are some buggy things going on there. >>> >>> Maybe e1000g is sharing the interrupt vector with another piece of >>> hardware, >>> and that other hardware has a pending interrupt during xVM dom0 >>> boot. e1000g driver is the first driver that is loaded, installs >>> it's interrupt handler, the vector is unmasked, and we immediatelly get >>> interrupts on that vector, but they are not from e1000g. There's >>> no driver to clear the interrupt condition => the system hangs. >>> >> >> Hmm, this could be. >> >> For those I remember the name of above, the interrupts under xVM show >> hci1394 and uhci/ehci. >> >> Does xVM handle such things well? How many of these get passed >> through to Solaris. If there are any pointers to a better technical >> doc on how xVM works with dom0's, I'd appreciate it. Most of the >> docs I see are pretty high level-- it's hard to see how much xVM does >> and how much is left for the dom0 to do. >> >> At this point, I'm tempted to leave it alone since it's working, but >> I'm happy to investigate interrupts if the data is valuable to someone. >> >>> My Tecra S1 had such an issue with the ehci and ipw drivers >>> 6353812 "ipw driver must disable interrupts at shutdown; tecra s1 >>> hangs on reboot" >>> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6353812 >>> >>> >>>> I also changed a Virtualization enabled/disabled setting which I >>>> did not see before. That would seem to be important for xVM. :) >>>> >>> >>> Yes, probable helps with HVM domUs... >>> >>> >>>> The NVidia driver is working just fine as well. >>>> >>>> Let me go through the matrix to see what we can figure out. >>>> There's either a bug or a release note to be created here I think. >>>> >>> >>> >>> >> >> >> > -- Matt Ingenthron - Web Infrastructure Solutions Architect Sun Microsystems, Inc. - Global Systems Practice http://blogs.sun.com/mingenthron/ email: [EMAIL PROTECTED] Phone: 310-242-6439 _______________________________________________ xen-discuss mailing list [email protected]
