This discussion is archived
11 Replies Latest reply: Aug 24, 2012 7:46 AM by rukbat RSS

Unable to proceed

HuaMin Chen Pro
Currently Being Moderated
Hi,
When I am to set up Oracle Linux Release 5 Update 8 for x86_64 (64 Bit) V31120-01 within Virtualbox 4.1.12, I've got
ACPI: DMAR not present
PCI-GART: No AMD northbridge found.
NET: Registered protocol family 2.

Then the setup can't proceed further.

Many Thanks & Best Regards,
HuaMin
  • 1. Re: Unable to proceed
    BillyVerreynne Oracle ACE
    Currently Being Moderated
    Host o/s?

    BTW, you cannot run a x86_64 VM on a x86 host o/s, even if the underlying hardware is 64bit.
  • 2. Re: Unable to proceed
    Dude! Guru
    Currently Being Moderated
    Sorry your information is incorrect.

    VirtualBox supports 64-bit guest operating systems, even on 32-bit host operating systems.

    http://www.virtualbox.org/manual/ch03.html#intro-64bitguests

    I recommend the OP checks I/O APIC support. Perhaps he used the wrong template for installing the OS or has hardware virtualization disabled in the system BIOS. Anyway, this is the wrong forum.
  • 3. Re: Unable to proceed
    HuaMin Chen Pro
    Currently Being Moderated
    Thanks all.
    The host is Win 7 Pro 64-bit OS.

    Dude,
    What should be adjusted for this?
  • 4. Re: Unable to proceed
    Dude! Guru
    Currently Being Moderated
    It's explained in the link of my previous message.
  • 5. Re: Unable to proceed
    BillyVerreynne Oracle ACE
    Currently Being Moderated
    Dude wrote:
    Sorry your information is incorrect.
    VirtualBox supports 64-bit guest operating systems, even on 32-bit host operating systems.
    Ah.. interesting. Thanks.
  • 6. Re: Unable to proceed
    Dude! Guru
    Currently Being Moderated
    If you run Virtualbox, with VT-x/AMD-d virtualization, a 32-bit host OS can run a x86_64 guest OS. However, restrictions under a 32-bit host such as addressable memory will still apply to the guest OS since it is assigned by the Virtualbox application.

    You can generally not run a 64-bit application using a 32-bit kernel, at least not under Linux or MS Windows as far as I know, but not every OS has these restrictions. Mac OSX for instance can run a 32-bit kernel with 32-bit drivers and use 64-bit application space. If the hardware supports it, you can even switch the kernel from 32-bit to 64-bit mode at system startup.

    Just for the record, Mac OS 10.4 and earlier had a build in "Blue Box", which translated 68k processor instructions for Mac OS Classic. When Apple changed to Intel, they shipped "Rosetta", which allowed PowerPC applications to run on the Intel x86_64 hardware. All of this worked totally transparent and very well providing the same if not better performance than their native counterparts.
  • 7. Re: Unable to proceed
    BillyVerreynne Oracle ACE
    Currently Being Moderated
    Dude wrote:

    You can generally not run a 64-bit application using a 32-bit kernel, at least not under Linux or MS Windows as far as I know, but not every OS has these restrictions.
    Reminds me of the Win32c (Chicago) kernel of Windows 4 (which was renamed Windows '95).

    The kernel ran as 32bit protected mode - but still allowed 16bit real mode drivers to be called from the kernel. Stubs in conventional 640Kb RAM were used to glue everything together. It was an amazing technical feat - and in part responsible for the bad press Win95 got later on as a commercial product, as introducing 16bit code into a 32bit kernel's driver space is not without issues.

    With the Chicago Beta 1, I configured a full blown, and fully integrated, 16bit Novell IPX driver stack (that included TCP/IP LAN Workplace for DOS) - and it worked better than what the s/w did with native MS-DOS, Win 3.1 and WFW 3.11 that were also 16bit.

    This was also not possible using the 16bit VMs supported by the Win32 NT and the O/S 2 kernels.

    Of course, whether this type of thing is actually a sound technical concept is very much open to debate. :-)
  • 8. Re: Unable to proceed
    Dude! Guru
    Currently Being Moderated
    I'm not a Windows developer. Please correct me if I'm wrong, but I think what you described was accomplished by Windows APIs. And if I'm not mistaken, developers will have to use these APIs in their code in order to function.

    I think the solution Apple provided for backward platform compatibility was based on ABI, which works on binary level and does not require software modifications or relinking for compatibility.

    http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/LowLevelABI/000-Introduction/introduction.html
  • 9. Re: Unable to proceed
    BillyVerreynne Oracle ACE
    Currently Being Moderated
    Dude wrote:
    I'm not a Windows developer. Please correct me if I'm wrong, but I think what you described was accomplished by Windows APIs. And if I'm not mistaken, developers will have to use these APIs in their code in order to function.
    All operating systems have some kind of kernel API for application s/w to run on that kernel. APIs for memory management (allocating and using shared memory fore example), APIs for IPC (Inter Process Communication), APIs for I/O and so on.

    The exact same concept of kernel APIs apply to OS/X. There are no major differences between OS/X and Windows NT in this regard.

    MS-DOS software runs on a MS-DOS 16bit kernel - in realmode. This software does not and cannot use the Win32 API. Drivers for MS-DOS worked directly with the hardware via BIOS calls, directly accessing specific locations of physical memory, installing IRQ controllers, and so on.

    This type of functionality is a problem for a 32bit pre-emptive multi-process/multi-threading kernel. It cannot allow direct access to hardware as it needs to be managed and controlled via the kernel.

    However, the Chigaco kernel allowed exactly this. You could load and use a 16bit real-mode driver from within the 32bit kernel - and 32bit s/w could make calls that were serviced by 16bit real mode drivers.

    It would be like using a 32bit OS/X (or Windows 7) kernel today and running sound via a 16bit MS-DOS SoundBlaster driver and a SB compatible sound card. And this is exactly what the Chicago kernel did and allowed.

    I do not believe that this type of integration had every been attempted before, or since.

    This is also the reason for developing the WinNT kernel separately. The Chigaco kernel (used from Win'95 to WinME) was specifically created to bridge the 16bit MS-DOS world with the 32bit pre-emptive multitasking world. But this is not a robust approach as 32bit needs to be pure 32bit - without hacks to allow 16bit real-mode drivers and services.

    But Microsoft had to support the old (MS-DOS) and the new (Windows 32bit). Thus the compromises and 16bit-32bit integration with the Chicago kernel. (also the fundamental reason for the infamous instability complaints by users of Win95/Win98/WinME)

    The Win32 API was compatible between these kernels - allowing source code compatibility. A certain level of binary compatibility was also supported, allowing Chigaco and NT executables to run unchanged on the other kernel - provided that the Win32 API feature set used by that binary was supported by that kernel.

    However, on the NT kernel, 16bit DOS executables were run in proper 16bit Virtual Machines. Which meant that many 16bit drivers failed to work as direct h/w access were not supported from inside that 16bit VM.

    ABI for OS/X fails to compare. The Chicago kernel was a lot more complex and something pretty unique.
  • 10. Re: Unable to proceed
    Dude! Guru
    Currently Being Moderated
    It would be like using a 32bit OS/X (or Windows 7) kernel today and running sound via a 16bit MS-DOS SoundBlaster driver and a SB compatible sound card. And this is exactly what the Chicago kernel did and allowed.
    For one, the ISA bus was 8/16 bit. At the same time, Apple used the NuBus, which was already 32-bit. The 68k Motorola CPU's were 16/32-bit and the Mac OS provided 32-bit virtual memory addressing. So the complexity of Microsoft might be impressive, but not from a technology standpoint, which was already a decade behind at the time. The IBM XT/AT was already a pile of technology junk. One man's trash is another man's treasure ;-)
    I do not believe that this type of integration had every been attempted before, or since
    Such type of solutions were already used many years ago in the 80's by DEC/VMS, which at some point in history was a 32-bit OS running on 16-bit hardware. And Dave Cutler and crew who developed Windows NT for Microsoft, as we all know worked for DEC. Windoes NT was a new OS in 1993 with a new API, but the roots of its core architecture and implementation goes back to the 70's.
    ABI for OS/X fails to compare. The Chicago kernel was a lot more complex and something pretty unique.
    Well, I wonder why you say "fails to compare". ABI is API on the machine level, sort of a compiled API. ABI is a superior solution, certainly more convenient for the user or developer. Isn't the Linux ELF format SysV ABI?

    Edited by: Dude on Aug 24, 2012 7:10 AM
  • 11. Re: Unable to proceed
    rukbat Guru Moderator
    Currently Being Moderated
    Moderator Action:
    This thread has wandered far from the original question.
    The O.P. likely won't ever understand the topic(s) discussed in the wanderings.

    The original question was answered early in the thread, with a link to the non-Oracle site for the non-Oracle software being used by the O.P.

    This thread is locked.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points