Re: SMP kernel hanging at when testing 8254 interrupt delivery

["David P. Reese Jr." <daver@xxxxxxxxxxxx>]

On Tue, Jul 29, 2003 at 07:59:51PM -0700, Matthew Dillon wrote:
> :A UP kernel boots just fine, however when I try to boot an SMP kernel the
> :boot process hangs in a loop in sys/i386/isa/clock.c.
> :
> :$DragonFly: src/sys/i386/isa/clock.c,v 1.4 2003/07/06 21:23:49 dillon Exp $
> :...
> :#ifdef APIC_IO
> :        if (apic_8254_trial) {
> :                
> :                printf("APIC_IO: Testing 8254 interrupt delivery\n");
> :                while (read_intr_count(8) < 6)      <-- hangs here
> :                        ;       /* nothing */
> :
> :What is most bothersome is that the SMP kernel hoses my CMOS checksum,
> :hinting that this is a result of a larger problem.
> :
> :I discovered this problem with a snapshot from just a couple of days ago.
> :I'll go ahead and try a chronological binary search with the source tree
> :to see where the problem was introduced.  This seems to be a DragonFly
> :issue because an SMP FreeBSD 4.8 kernel boots just fine.
> :
> :Has anyone else running DragonFly on SMP hardware encountered this problem?
> 
>     Yes, Jeffrey Hsu reported the same problem, but hadn't tried to backtrace
>     it.  I sure would appreciate whatever work you are able to do to home
>     in on the problem.

But are there reports of SMP hardware that doesnt have the CMOS problem?

>     Please try commenting out the #define CHECK_POINTS line in
>     i386/i386/mp_machdep.c on line 189.  Maybe that is causing the CMOS
>     issues.

With CHECK_POINTS turned off the kernel hangs at same place and CMOS still
gets hosed.

>     I am going to turn it off anyway, right now, because I did not mean
>     to leave it on.
> 
> :If I am reading the source correctly, the routines in
> :
> :   sys/i386/isa/icu_vector.s
> :
> :increment the interrupt counts in the array intr_countp[vec] , so the above
> :loop waits for 6 interrupts from the rtc.    Is there anything I can examine
> :in the debugger to shed some light on the problem?
> :
> :-- 
> :
> :   David P. Reese Jr.                                      daver@xxxxxxxxxxxx
> 
>     Hmm.  All I can think of is to spatter printf()'s around.  First see
>     if removing CHECK_POINTS solves the CMOS checksum problem, though, because
>     if it does it will make debugging a lot easier.
> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>

I'm out of town for two days.  When I get back I'll be able to fool with
this a bit more and try to track down the code that borks the CMOS.  

-- 

   David P. Reese Jr.                                      daver@xxxxxxxxxxxx
   --------------------------------------------------------------------------
   It can be argued that returning a NULL pointer when asked to allocate
   zero bytes is a silly response to a silly question.
                                         -- FreeBSD manual page for malloc(3)