From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: dmidecode doesn't work under xen 4.1.1 on certain hardware Date: Mon, 10 Oct 2011 12:15:22 -0400 Message-ID: <20111010161522.GD28646@phenom.oracle.com> References: <20110926193732.GA10007@phenom.oracle.com> <4E82E429.2080600@overnetdata.com> <20110928132815.GE10270@phenom.oracle.com> <4E83462B.9080002@overnetdata.com> <4E835324.30902@citrix.com> <4E8AF9BA.3000906@overnetdata.com> <20111005151601.GA5223@phenom.oracle.com> <4E8DA4D1.2040904@overnetdata.com> <20111006160717.GA31310@phenom.oracle.com> <4E930E71.7000306@overnetdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4E930E71.7000306@overnetdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Anthony Wright Cc: "xen-devel@lists.xensource.com" , David Vrabel List-Id: xen-devel@lists.xenproject.org On Mon, Oct 10, 2011 at 04:25:37PM +0100, Anthony Wright wrote: > On 06/10/2011 17:07, Konrad Rzeszutek Wilk wrote: > >>> If you feel adventours you could use the oss.oracle.com/git/kwilk/xen.git > >>> tree. Mainly the #linux-next or #testing branch. They both have David's new > >>> e820 code. > >>> > >>> The way to get it is: > >>> > >>> git clone oss.oracle.com/git/kwilk/xen.git > >>> cd xen > >>> git checkout origin/linux-next > >>> make -j90 > >> Sorry it panicked :-( > >> I've attached two photos of the two flavours of panic & a copy of the > >> config. > > No serial console? Did it panic when you booted as baremetal? > Sorry - no serial console - I hadn't really intended to become part > kernel hacker!! We're looking for leads to see if we can set it up, but > I'm going to have to look through the attic into some old dusty boxes... Heheh. > > It runs through fine on bare metal. Ok, this was the #linux-next branch right? If you did: git checkout v3.1-rc8 and built that kernel does it work? (Trying to figure out if the patches in #linux-next are the cause of your failure). > > >> It seems to get through the initial kernel boot and hands over to my > >> init script, but panics early on in that process, probably at the point > >> that udev is loading modules. > > Looks completly unrelated to the dmidecode issue. Lets attack one thing > > at a time. > > > > Can you move the ioatdma.ko as .bak so it wont load and try again. > I moved the ioatdma.ko module out of the way, but I'm still getting the > panics in my init script as udev registers the devices. It's the same > panic as I attached a photo of in the previous email (the one with > xen_force_evtchk_callback & do_coprocessor_segment_overrun in the call > stack). Oh, I somehow missed the do_coprocessor_segment_overrun. That looks to be something entirely new or perhaps: http://bugs.debian.org/642154 Hm, let me take a look at the photos once more.