Re: SMP problems with Thinkpad X60s

Jan Stoess <[email protected]> writes:

>> The latter seems to be the case, the failed assertion is in
>> kernel/kdb/glue/v4-x86/prepost.cc, line 410, if I read the output
> correctly.
>
> Which is: 
>     ASSERT(kdb_current_cpu == CONFIG_SMP_MAX_CPUS);
>
> If that's correct, it may be a race condition that comes into my mind when
> looking at that assertion: kdb_current_cpu stores the current CPU executing
> within the KDB; all other CPUs are sleeping uninterruptibly waiting for a
> broadcast NMI to either go on or try to enter KDB themselves (see
> kdb_t::pre()). There might actually occur a race condition, because the CPU
> leaving KDB first resets kdb_current_cpu, then uses an NMI broadcast to
> inform other CPUs that they may go on or enter KDB, and finally verifies the
> value of kdb_current_cpu. But meanwhile the value may have changed because
> of another CPU instantly entering KDB again.
>
> So Julian, can you please try to just comment out that assertion and tell us
> if that helps? 

Here we go again:

--- "KD# System started (press 'g' to continue)" ---
--------------------------------- (eip=00176001, esp=f011e4b0) ---
> go
Idle thread started on CPU 0
Pistachio::Platform::Platform(): [33m> setup_basics[0m
void Pistachio::Platform::_setup_basics(): [33mLet's chec--- KD# unknown reason 2 ip f011e4eb ---

f011e4eb is at a CLI instruction? See:

/**
 * @return the current scheduler 
 * the default implementation features exactly one scheduler at a time.
 */
INLINE scheduler_t * get_current_scheduler()
{
f011e4d0:       c7 04 24 00 50 14 f0    movl   $0xf0145000,(%esp)
f011e4d7:       b8 00 58 14 f0          mov    $0xf0145800,%eax
f011e4dc:       89 44 24 04             mov    %eax,0x4(%esp)
f011e4e0:       e8 2b f9 ff ff          call   f011de10 <_ZN11scheduler_t8scheduleEP5tcb_t>
f011e4e5:       84 c0                   test   %al,%al
f011e4e7:       75 e7                   jne    f011e4d0 <_Z11idle_threadv+0x20>
{
    __asm__ __volatile__(
            "sti   \n"
            "hlt   \n"
            "cli   \n"
            :);
f011e4e9:       fb                      sti    
f011e4ea:       f4                      hlt    
f011e4eb:       fa                      cli    
f011e4ec:       b8 00 58 14 f0          mov    $0xf0145800,%eax
f011e4f1:       89 44 24 04             mov    %eax,0x4(%esp)
f011e4f5:       c7 04 24 00 50 14 f0    movl   $0xf0145000,(%esp)
f011e4fc:       e8 0f f9 ff ff          call   f011de10 <_ZN11scheduler_t8scheduleEP5tcb_t>
f011e501:       84 c0                   test   %al,%al
f011e503:       75 cb                   jne    f011e4d0 <_Z11idle_threadv+0x20>
f011e505:       eb e2                   jmp    f011e4e9 <_Z11idle_threadv+0x39>
f011e507:       90                      nop    
f011e508:       90                      nop    
f011e509:       8d b4 26 00 00 00 00    lea    0x0(%esi),%esi


So disabling the assertion doesn't seem to do any good (except not
printing the warning). I uploaded relevant files at
http://os.inf.tu-dresden.de/~jsteckli/pistachio-smp/

 x86-kernel          - the kernel used
 core                - the roottask
 pistachio-trace.log - script of the session with tracebuffer output
 boot.iso.gz         - gzipped bootable iso image

Judging from the tracebuffer output, everything seems to be fine, until
the (first) timeslice of the roottask expires. 

Regards,
-- 
Julian Stecklina

Well, take it from an old hand: the only reason it would be easier to
program in C is that you can't easily express complex problems in C,
so you don't. - Erik Naggum (in comp.lang.lisp)

(Spam-Experiment: http://cthulhu.c3d2.de/~astro/badpit.html )