Thanks for the info
Dave – maybe this belongs in the appropriate Xen list, but this code
seems fundamentally broken to me for a couple of reasons:
Time for a Xen bug I
think!
Simon
From:
crash-utility-bounces@redhat.com [mailto:crash-utility-bounces@redhat.com] On Behalf Of Dave Anderson
Sent: Monday, May 08, 2006 10:36
AM
To: Discussion list for crash
utility usage, maintenance and development
Subject: Re: [Crash-utility]
Problems debugging live system with 4.0-2.24 crash
"Graham, Simon" wrote:
I've been
experimenting with the latest crash version on a system running Xen (3.0.2-2
with kernel 2.6.16) and am experiencing problems when attempting to debug the
system live; debugging of saved guest files and guest crash dumps
works well, it's just live debugging of dom0 that is problematical.
The symptom is that I get the error:
WARNING: cannot read linux_banner string
When I debug crash, I can see that it is finding the
correct
unstripped
kernel from which it finds the address of the linux_banner variable _but_ when it attempts to read the string
from /dev/mem it gets all zeroes back. I have confirmed that the address is
correct by using gdb against /proc/kcore - gdb reads the
string quite nicely from the virtual address (happens to be 0xc0450000,
I can see that crash translates this to physical address 450000 and gets all
zeroes when it reads this location from /dev/mem).
Hi
Graham,
The xen /dev/mem driver read_mem() function does this:
if ((v = ioremap(p, sz)) == NULL) {
/*
* Some programs (e.g., dmidecode) groove off into weird RAM
* areas where no tables can possibly exist (because Xen will
* have stomped on them!). These programs get rather upset if
* we let them know that Xen failed their access, so we fake
* out a read of all zeroes. :-)
*/
if (clear_user(buf, count))
return -EFAULT;
read += count;
break;
}
when ioremap() returns NULL. Here's the
NULL-returner in __ioremap():
/*
* Don't allow anybody to remap normal RAM that we're using..
*/
if (is_local_lowmem(phys_addr)) {
char *t_addr, *t_end;
struct page *page;
t_addr = bus_to_virt(phys_addr);
t_end = t_addr + (size - 1);
for(page = virt_to_page(t_addr); page <= virt_to_page(t_end); page++)
if(!PageReserved(page))
return NULL;
domid = DOMID_SELF;
}
So /dev/mem cannot be used. So to get crash to
work on a live
x86 xen0
system (FC5), I've had to use the RHEL4 crash.c module
(/dev/crash)
to make an end-run around /dev/mem. RHEL4's x86 and
x86_64
/dev/mem driver only allows reads of the first 256 pages of
physical
memory. And now Xen has the restriction above.
FC5 has a CONFIG_CRASH configurable:
$ diff kernel-2.6.15-i686-guest.config.orig
kernel-2.6.15-i686-guest.config
2526c2526
< #
CONFIG_CRASH is not set
---
>
CONFIG_CRASH=m
2965d2964
< #
CONFIG_CRASH is not set
$
If you're building from an upstream source, you could
build the
crash.c
module from FC5/RHEL4 into that kernel, or perhaps
patch the
xen /dev/mem driver above to remove the local_lowmem()
restriction,
or something like that...
Dave