From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Subject: Re: [ANNOUNCE] Xen 3.0.4 release candidate 2 Date: Tue, 02 Jan 2007 13:50:59 -0600 Message-ID: <1167767459.5616.35.camel@basalt> References: <1166459497.3005.27.camel@localhost.localdomain> Reply-To: Hollis Blanchard Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1166459497.3005.27.camel@localhost.localdomain> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: Jimi Xenidis , Keir Fraser , xen-devel , Magnus Damm , Horms List-Id: xen-devel@lists.xenproject.org I didn't pay much attention to the lengthy "packed" discussions of the past. From a quick Google, it looks like the issues are that packed doesn't work on Plan 9, and compounds an already bad situation on PowerPC when Xen requires us to fake 16-bit atomic accesses. -- Hollis Blanchard IBM Linux Technology Center On Mon, 2006-12-18 at 16:31 +0000, Ian Campbell wrote: > On Mon, 2006-12-18 at 21:48 +0900, Magnus Damm wrote: > > The ELF notes for kexec / kdump are screwed up on x86_64. > > That was due to 12977:af39d20b2b728941421ef18e5c5b1012852eec80[0] which > I have now reverted. The reversion will be > 13080:4ef0dbe95eac33033abeee36a8f13eaaeb9d5639 once it comes through > regression testing. > > Hollis, what was the warning the change was introduced to avoid? If you > have any ideas for another workaround for them in the 3.0.4 release we'd > be grateful to hear it ASAP -- Keir plans to roll the final RC in the > next 24 hours. > > Cheers, > Ian. > > [0] http://xenbits2.xensource.com/xen-unstable.hg?cs=12977 > > > $ readelf -a vmcore-3.0.4-rc2-x86_64 > > [snip] > > Notes at offset 0x00000120 with length 0x000002c8: > > Owner Data size Description > > CORE 0x00000150 NT_PRSTATUS (prstatus structure) > > CORE 0x00000150 NT_PRSTATUS (prstatus structure) > > > > $ readelf -a vmcore-3.0.4-rc1-x86_64 > > [snip] > > Notes at offset 0x00000120 with length 0x00000380: > > Owner Data size Description > > CORE 0x00000150 NT_PRSTATUS (prstatus structure) > > Xen 0x00000020 Unknown note type: (0x01000002) > > CORE 0x00000150 NT_PRSTATUS (prstatus structure) > > Xen 0x00000020 Unknown note type: (0x01000002) > > Xen 0x00000048 Unknown note type: (0x01000001) > > > > x86_32 seems to work as expected though. > > > > / magnus