WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] dmidecode doesn't work under xen 4.1.1 on certain hardwa

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel