[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] issues getting more than 16M ram to be used without oopsing. 1.2 and 1.3-unstable
Ok, I have done two things so far as recomended. #1 I compiled a custom 2.6.4 with HIGHMEN4G and booted it up. It works just fine on all 1GB of ram. I kicked off 3 parallel kernel compiles and compared the resulting bzImage files. All 3 are identical and boot just fine. This SHOULD have beat any bad memory usage out of the machine if it existed. Memory usage went to all but 4MB used for cache and apps. No swapping occurred. #2 The initial 4 memtest86+ 3.0 tests passed. I am installing a copy of memtest86+ 3.0 that I just finished building in order to allow an overnight run happen, and be able to capture the serial output of memtest86+ for review later. btw, I placed the memtest deb I created for this test at http://www.terrabox.com/debs/memtest86+serial_3.0-1_i386.deb if anyone wants a deb that uses serial console. It won't overwrite the official memtest86+ deb files. At this point i'm still %99.999 certain that the hardware is good. What is the next step after I have run all of the memtest86+ tests on the system overnight? -- Brian Wolfe | Phone 1-(214)-764-1204 President, | Email brianw@xxxxxxxxxxxx TerraBox.com Inc. | pub 1024D/73C5A2DF 2003-03-18 Brian Wolfe <brianw@xxxxxxxxxxxx> Key fingerprint = 050E 5E3C CF65 4C1E A183 F48F E3E3 5B22 73C5 A2DF sub 1024g/BB87A3DD 2003-03-18 Keir Fraser said: > >> Now, this machine has been used for aprox 5 months now without any >> glitches or oopses. So i'm 99.9999% certain that the hardware is good. >> >> I'm using an NFS root since the ide is only in pio mode (and to >> eliminate >> it's use toher than to boot the kernels). >> >> Any insights? >> >> If necessary for debuging, I can provide access to the hardware via >> serial >> console. :) >> >> Thanks for any help yall can give! > > The crashes look quite random -- I don't think this is a bug in the > core of Xen. The two most likely possibilities are that you have duff > memory or that a misconfigured device is trashing memory. I definitely > wouldn't discount the former, even though native x86 Linux has been > running okay -- crashes can be very sensitive to memory layout. > > It might be worth running a few rounds of memtest on the machine, or > swapping the memory, or trying to boot Xen on another identical box. > > If that doesn't cure it then try swapping out or disabling > hardware. For example, boot off local disc and disable networking > ('ifname=dummy'). Since the cause is most likely hardware-related, the > best approach is to isolate the problem hardware. > > -- Keir > > PS. If you build your own Xen/Xenolinux then keep the build trees > around (or at least, for Xenolinux, the 'vmlinux' file). I can't find > suitable image files for the tarballs on the Xen website, and without > them it is very difficult to determine anything from crash dumps. > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.sourceforge.net/lists/listinfo/xen-devel > ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |