Hi Anselm, It looks like the problem may be with how the Chks microop behaves when it receives an input it does not usually expect (e.g. values found in older kernel versions). Before starting the kernel, gem5 executed microcode as in your trace, and then jumps into the kernel at the appropriate location. Chks requires some initial processor settings to be correct, and may raise a GeneralProtection fault if the SegIntGateCheck finds incorrect CPU register values (see src/arch/x86/isa/microops/regop.isa).
To help us better understand the problem, could you do the following?: 1) Re-run the failing simulation with more debug flags: LocalApic and Faults (i.e. --debug-flag=Exec,LocalApic,Faults). This will help us know if, in fact, Chks is raising a fault, and will give us something to compare against for the following: 2) Re-run the simulation with the kernel that comments out verify_cpu, and use the same debug flags (--debug-flag=Exec,LocalApic,Faults) Then, copy the simulator debug information for the first ~50k simulated ticks into a reply on this thread (note: the numbers at the start of each debug output line are the simulation's ticks). This should help us identify what the simulator is doing differently in each case. Thanks! Joel On Thu, Jun 9, 2016 at 6:41 AM, Busse, Anselm <[email protected]> wrote: > Hi everyone, > > the first thing I have to say is that I am completely new to Gem5, so > please excuse me when I lack some expertise regarding it. > > I have some trouble running the x86_64 Linux kernel v4.4. Apparently with > this version some CPU verification was introduced with > „arch/x86/kernel/verify_cpu.S“. It seems that Gem5 gets stuck, when I > execute the kernel in FS mode. I did some tracing and was able to observe > that it gets stuck in a loop (4 lines repeating forever): > > 1500: system.cpu T0 : @phys_startup_64.32890 : Microcode_ROM : slli > t4, t1, 0x4 : IntAlu : D=0x00000000000000e0 > 2000: system.cpu T0 : @phys_startup_64.32891 : Microcode_ROM : ld > t2, IDTR:[t4 + 0x8] : MemRead : D=0x0000000000000000 A=0xe8 > 2500: system.cpu T0 : @phys_startup_64.32892 : Microcode_ROM : ld > t4, IDTR:[t4] : MemRead : D=0x0000000000000000 A=0xe0 > 3000: system.cpu T0 : @phys_startup_64.32893 : Microcode_ROM : chks > , t4b, 0x3 : IntAlu : > 3500: system.cpu T0 : @phys_startup_64.32890 : Microcode_ROM : slli > t4, t1, 0x4 : IntAlu : D=0x00000000000000d0 > 4000: system.cpu T0 : @phys_startup_64.32891 : Microcode_ROM : ld > t2, IDTR:[t4 + 0x8] : MemRead : D=0x0000000000000000 A=0xd8 > 4500: system.cpu T0 : @phys_startup_64.32892 : Microcode_ROM : ld > t4, IDTR:[t4] : MemRead : D=0x0000000000000000 A=0xd0 > 5000: system.cpu T0 : @phys_startup_64.32893 : Microcode_ROM : chks > , t4b, 0x3 : IntAlu : > > The problem is fixed, when I comment out the verify_cpu code, but I would > really like to fix the problem for real. Unfortunately, like I said, I’m > brand new to Gem5, so I have no idea how to proceed further. Maybe someone > can give me a hint how I can investigate that problem further. > > Thanks and Regards, > Anselm > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > -- Joel Hestness PhD Candidate, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://pages.cs.wisc.edu/~hestness/
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
