nathan binkert wrote: > Should we just update the console binary that we distribute with this > one? I see no reason not to (though someone will have to regenerate > all regressions. Would you be willing to do this Rick?) > Sure. Is there any documentation on how to update the regressions? > Nate > > On Wed, Jul 29, 2009 at 3:16 PM, Rick Strong<[email protected]> wrote: > >> The console code was indeed the problem. I posted an updated console binary >> for the ALPHA for anyone interested @ http://rickshin.ucsd.edu/console >> >> Best, >> -Rick >> >> nathan binkert wrote: >> >>>> System.terminal:* >>>> Memory cluster 1 [392 - -262536] >>>> Initalizing mdt_bitmap addr 0xFFFFFC0000038000 mem_pages FFFFFFFFFFFC0000 >>>> ConsoleDispatch at virt 100008D8 phys 188D8 val FFFFFC00000100A8 >>>> Bootstraping CPU 1 with sp=0xFFFFFC0000076000 >>>> unix_boot_mem ends at FFFFFC0000078000 >>>> k_argc = 0 >>>> jumping to kernel at 0xFFFFFC0000310000, (PCBB 0xFFFFFC0000018180 pfn >>>> 1004) >>>> CallbackFixup 0 18000, t7=FFFFFC00006CC000 >>>> Entering slaveloop for cpu 1 my_rpb=FFFFFC0000018400 >>>> [4194001.852669] Linux version 2.6.18.8 (bink...@blue) (gcc version >>>> 4.0.2) #9 SMP Wed Feb 27 11:50:35 PST 2008 >>>> [4194001.852669] Booting GENERIC on Tsunami variation DP264 using >>>> machine vector DP264 from SRM >>>> [4194001.852669] Major Options: SMP LEGACY_START VERBOSE_MCHECK >>>> [4194001.852669] Command line: root=/dev/hda1 console=ttyS0,9600 >>>> init=/m5/bin/init.sh >>>> [4194001.852669] memcluster 0, usage 1, start 0, end 392 >>>> [4194001.852669] memcluster 1, usage 0, start 392, end >>>> 18446744073709289472 >>>> >>>> >>> The first line of the terminal output is pretty suspect. As is the >>> last line I've copied here. My guess is that nobody ever tested the >>> console code with more than 2GB of memory and that there's some sort >>> of 32 bit signed integer in there. The console code is actually not >>> too hard to change, but the real question is, how does linux get the >>> value? >>> >>> Actually, looking at the console code, it looks like Geoff Blake fixed >>> a bug in the console code when using >2GB of memory. That fix was >>> dated Oct 19th 2007, though it's easily believable that you have a >>> console binary older than that. >>> >>> Nate >>> >>> >>> Nate >>> >>> >>> >> > >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
