The very low phisical address 0x10134 indicates that this code is either in the console, or in the PAL. The reason you're hitting the fencepost is probably because gdb can't make any sense out of what the stack should be because the console and the PAL don't exactly follow normal ABIs. What stage of the system are you in? I can imagine you being in the console code if either your CPUs haven't spun up yet because you're still booting, or if they're idle. You can nm the console and PAL binaries to figure out what's up. You can also load the symbols for those into GDB in addition to (or instead of) the linux kernel. If this error is only on CPUs > the fourth, then it's probably because you're using the wrong PAL.
Nate > (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
