ART@ACC.ARPA (Art Berggreen) (10/01/85)
> I can't say that this is the absolute truth but the word that I've > heard is that DEC is suspending shipments of Ultrix for the uVAX II > due to some memory problem that affects low-memory. As most UNIX > hacks know, this is where the kernal resides. This will also > affect the uVMesS users as well but the "kernal" for VMesS is in > high-memory while the user's code is in low. Nicely enough, this is > where the user code gets loaded and DEC figures that this is > acceptable (to have the user code bomb due to h/w problems). NOT TRUE!!! Due to VAX hardware architecture, in both VMS and UNIX the kernel VIRTUAL addresses start at 0x80000000 and user processes start at 0x00000000 with process data below 0x7fffffff (VMS and some UNIXs make page 0 noaccess). In both VMS and UNIX the kernel is loaded into low PHYSICAL memory while user processes tend to run in higher PHYSICAL pages. The uVAX-II problem was apparently an obscure memory timing problem which caused one manufacturer's parts to fail only with UNIX. It appears DEC has solved this and Ultrix shipments are resuming. "Art Berggreen"<Art@ACC.ARPA> ------
chris@umcp-cs.UUCP (Chris Torek) (10/02/85)
> .... In both VMS and UNIX the kernel is loaded into low PHYSICAL > memory while user processes tend to run in higher PHYSICAL pages. I admit that I am no expert on VMS, but I believe that this is not true: the VMS kernel is booted into the highest available physical addresses. (Physical location matters little once memory mapping has been enabled.) Were this not so, the problem might well have struck VMS also: The fault was traced to a RAM problem that was masked by frequent writes, and it seems unlikely that VMS would write on its code space. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu