Nova on a bit old CPU

Paul Dufresne dufresnep at zoho.com
Fri Jul 13 17:07:44 CEST 2018


Le 2018-07-12 à 15:04, Alexander Boettcher a écrit :

    On 12.07.2018 17:41, Paul Dufresne wrote: I have figure out that the
    computer would reboot unless I commented out: In si.cpp constructor,
    the TRACE line have to be commented out.
    This should not happen nor necessary to comment it out, as long as
    you did not enable TRACE_SYSCALL (which is by default off).

No I did not enable it.

Rather than commenting out the call to Mtr::init() in pd.cpp, I have 
found that writing my own hyper
simple in include/mtrr.hpp, also stop the computer from rebooting.
I have added in mtrr.hpp:
in private:         static Quota        paulcache[200];
     public:
         ALWAYS_INLINE
         explicit inline Mtrr (uint64 b, uint64 m) : List<Mtrr> (list), 
base (b), mask (m) {}

         ALWAYS_INLINE
         static inline void *operator new (size_t, Quota &quota) {
           static Quota *paulptr;
           //return cache.alloc(quota);
           *paulptr=quota;
           return(paulptr++);
         }

That stop the computer from rebooting. But it does not make different 
results than before, it will
show up to showing my 2 cores info, then apparently nothing.

Until I apply your trick of adding keyb parameter to the hypervisor 
command parameter in Grub.
In genode/tool/run/boot_dir/nova file for people not knowing where.
 From there, I am indeed able to see a kind of list of the number of 
interrupts done since the
last time I pressed the 'c' character.

Well, there is billions of Timer interrupts done.
After a while almost so much Idle one.
I can see often about 100k or 200k of 0xe exception.
Sometime 2 0x6 exception (bad opcode I think).
Some GSI, often just 2, but there is other number linked to that, I 
still don't know what they are.
Yeah, I will probably read in the Nova paper like you suggested to know 
if they say what they are.

At that stage, the system feeling is that it is stable enough to 
investigate further... but I would have
to know better what to check for.

At first I thought that the problem with the slab allocator would be 
only at Constructor time.
But now, I am beginning to think that maybe this is it that generate the 
numerous 0xe exceptions.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20180713/ec454671/attachment.html>


More information about the users mailing list