Could you send me the config file that works?
Thanks,
Ali
On Jun 3, 2008, at 8:53 PM, Beckmann, Brad wrote:
I was hoping I could put this thread to rest, but I'm encountered one
more issue with the combination of kernel debugging and the new config
file for 2.6.22 that I think everyone would like to know. In
particular, I'm had a problem viewing the kernel's call stack using
after using the .config file that Ali sent me. The specific error is
below. I noticed this error only existed with my new build of 2.6.22
and realized that the CONFIG_PRINTK_TIME=y and
CONFIG_ENABLE_MUST_CHECK=y should be set in .config to enable kernel
call stack traces. You may want to update your .config file
accordingly.
Brad
(gdb) c
Continuing.
Program received signal SIGILL, Illegal instruction.
0xfffffc0000010134 in ?? ()
(gdb) bt
#0 0xfffffc0000010134 in ?? ()
warning: Hit heuristic-fence-post without finding
warning: enclosing function for address 0xfffffc0000010134
This warning occurs if you are debugging a function without any
symbols
(for example, in a stripped executable). In that case, you may wish
to
increase the size of the search with the `set heuristic-fence-post'
command.
Otherwise, you told GDB there was a function where there isn't one, or
(more likely) you have encountered a bug in GDB.
#1 0xfffffc0000013780 in ?? ()
warning: Hit heuristic-fence-post without finding
warning: enclosing function for address 0xfffffc0000013780
Previous frame identical to this frame (corrupt stack?)
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
Behalf Of Ali Saidi
Sent: Tuesday, June 03, 2008 3:25 PM
To: M5 users mailing list
Subject: Re: [m5-users] Config File for Linux 2.6.22
We encourage editing... please add anything that you think is missing
or needs clarification.
Thanks,
Ali
On Jun 3, 2008, at 6:20 PM, Beckmann, Brad wrote:
Thanks Nate!
I noticed someone just updated the wiki. I added a bit more detail
concerning multiple processor kernel debugging. I hope you don't
mind.
Brad
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
Behalf Of nathan binkert
Sent: Tuesday, June 03, 2008 11:46 AM
To: M5 users mailing list
Subject: Re: [m5-users] Config File for Linux 2.6.22
You should set the current_debugger variable from gdb manually. This
is so the correct CPU gets stopped. We should probably add a method
to the cpu object called debugger so this can be done a bit more
easily, but currently, you need to figure out the cpu, set
current_debugger, then call debugger()
Nate
On Tue, Jun 3, 2008 at 11:17 AM, Beckmann, Brad
<[EMAIL PROTECTED]>
wrote:
Thanks Ali, that was it!
As I suspected, my .config file attempts where way off from what
they
should have been. The .config file you sent me appears to be
working
great so far.
Also, thanks for letting me know that the debugger function is
'debugger()' not 'Debugger()'. Unfortunately, I'm still
encountering
problems when calling the kernel debugger from the user-level
debugger
on M5. So the calls to 'debugger()' don't encounter a symbol not
found
error, but they don't break into the kernel debugger either.
Instead,
nothing seems to happen. Actually after examining the function
debugger() in src/base/remote_gdb.cc, I'm not sure how the gdb is
ever
called. It appears the current_debugger static int is set to -1 and
there is no possibility to set the current_debugger variable to a
different value. Thus the debugger loop is not executed and the
kernel
gdb session is never called. Is my understanding correct, or does
some
external object change the value of current_debugger? Below is the
specific code I'm referring to.
Thanks again for all your help. I really appreciate it.
Brad
void
debugger()
{
static int current_debugger = -1;
if (current_debugger >= 0 && current_debugger < debuggers.size()) {
BaseRemoteGDB *gdb = debuggers[current_debugger];
if (!gdb->isattached()) {
gdb->listener->accept();
}
if (gdb->isattached()) {
gdb->trap(SIGILL);
}
}
}
-----Original Message-----
From: Ali Saidi [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 6:29 PM
To: Beckmann, Brad
Subject: Re: [m5-users] Config File for Linux 2.6.22
On Jun 2, 2008, at 8:16 PM, Beckmann, Brad wrote:
Hi Ali,
I've been having problems creating a build of Linux 2.6.22 that
matches with the supported Tsunami platform in M5. I think the
source
of problems is incorrectly configuring the VGA device and I want to
go
back to the configuration question (see below) that I asked a few
weeks ago.
I noticed that the M5 patches make changes to the following files:
arch/alpha/Kconfig, arch/alpha/kernel/console.c, and
arch/alpha/kernel/proto.h. In particular, these changes appear to
allow the DUMMY_CONSOLE to be built without the VGA_HOSE being
defined. To avoid the define dependencies on VGA_HOSE, the changes
also switch some "#ifdef CONFIG_VGA_HOSE" lines to "#ifdef
CONFIG_VGA_HOSE1". Is my understanding correct?
Yea, some dependence was introduced in the 2.6.22 kernel that I
really
haven't looked at, but that required a VGA adapter to be added to
configuration. Since we don't even support probing of the VGA
device,
that had to be removed.
The problem with these changes is they appear incomplete without
the
necessary changes to the config files. Specifically, I assume one
needs to remove the dependency between VGA_HOSE and ALPHA_GENERIC
in
Kconfig.
Therefore, CONFIG_DUMMY_CONSOLE, CONFIG_ALPHA_GENERIC, and
CONFIG_ALPHA_LEGACY_START_ADDRESS are defined, while
CONFIG_VGA_CONSOLE, CONFIG_VGA_HOSE, and CONFIG_VGA_HOSE1 are not
defined. The result is the kernel builds with empty
implementations
of the
find_console_vga_hose() and locate_and_init_vga() functions. Is my
configuration assumption correct?
Well, all you need to do is not enable any VGA adapters in your
kernel
configuration file and there isn't a problem.
So with the above configuration, I encounter a M5 assertion check
that
appears to be caused by an incorrectly "faked" device. In
particular,
the following trace indicates the faulting address is 0x801fc0001ef
which maps in between the fake_ata0 and fake_ata1 devices. I
have a
sucpicion that this error is caused by the vga device not really
being
removed, but I'm not sure. What is your opinion?
1942464295500: testsys.membus: recvAtomic: packet src 3 dest -1
addr
0x801fc0001ef cmd ReadReq
1942464295500: testsys.membus: Unable to find destination for addr:
0x801fc0001ef, will use default port
1942464295500: testsys.membus.responder: Device
testsys.membus.responder
read to bad address va=0x801fc0001ef size=1
The VGA device has a BadDevice where it is, I don't know why you're
seeing that.
Finally, I wanted to get a stack trace of the kernel when this
error
occurs, but I'm having a problem calling the Linux kernel debugger
from
the user-level debugger on M5. The website
(http://www.m5sim.org/wiki/index.php/Debugging_M5) indicates the
kernel
debugger can be called by a 'call Debugger()' command, but I think
that
is assuming the Debugger() function is defined? Who defines the
Debugger function, because I receive a 'No symbol "Debugger" in
current
context.' Error when I try to call the Debugger function from the
M5
debugger.
The case on the webpage is wrong, it should be debugger(). The
function is defined in remote_gdb.cc although you would need to
schedule a break cycle (schedBreakCycle() from within the gdb
instance
that is debugging m5 would work), before you hit that error.
I've attached a linux 2.6.22 config file I just created. It builds
and
successfully boots to the bash prompt.
Ali
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
