Linmodems Mailing list Archives

Google
 
Web archives.linmodems.org

Return-Path: <stodolsk@rcn.com>
Mailing-List: contact discuss-help@linmodems.org; run by ezmlm
Delivered-To: mailing list discuss@linmodems.org
Received: (qmail 11924 invoked from network); 26 Sep 2002 23:48:11 -0000
Received: from smtp03.mrf.mail.rcn.net (207.172.4.62)
  by www.linmodems.org with SMTP; 26 Sep 2002 23:48:11 -0000
Received: from 66-44-22-96.s604.apx3.lnh.md.dialup.rcn.com ([66.44.22.96] helo=rcn.com)
	by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.35 #7)
	id 17uiMa-0007AF-00; Thu, 26 Sep 2002 19:48:09 -0400
Sender: marv
Message-ID: <3D939CB7.7F61C789@rcn.com>
Date: Thu, 26 Sep 2002 18:48:07 -0500
From: Marvin Stodolsky <stodolsk@rcn.com>
Organization: HomeBase
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.19-solo i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: discuss@linmodems.org, mingo@redhat.com
Subject: Re: Multiprocessor machine  solved!!!?
References: <Pine.LNX.4.33.0209241245120.877-100000@defiant.hebyhome> <200209251935.35780.muzh@ihug.co.nz>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit

To:  Ingo Molnar
     mingo@redhat.com
Maintainer: INTEL APIC/IOAPIC, LOWLEVEL X86 SMP SUPPORT

Ingo,
   Could you please elucidate an issue. Under Linux
modems with Lucent/Agere DSP chipsets CONNECT but abort sometime later
on SMP motherboard PCs. 
Igor V. Kovalenko <garrison@mail.ru> has taught us that booting with the
noapic option circumvents this problem. But as Cll Muzh
<muzh@ihug.co.nz> asks below, the  lack of interrupts on the CPU1
requires clarification.  Is the 2nd processor effectively
unctioning/useful under the "noapic" configuration?

The ltmodem compiler packages are at www.heby.de/ltmodem/

MarvS



>cll muzh wrote:
> 
> Further to my previous letters on this subject, here is the contents of
> /proc/interrupts when noapic is NOT passed at boot-time compared to when
> napic IS passed:
> noapic NOT passed at bootime
>            CPU0       CPU1
>   0:      15488      15155    IO-APIC-edge  timer
>   1:        406        292    IO-APIC-edge  keyboard
>   2:          0          0          XT-PIC  cascade
>   8:          1          0    IO-APIC-edge  rtc
>  12:       1274       1251    IO-APIC-edge  PS/2 Mouse
>  14:       6561       7021    IO-APIC-edge  ide0
>  15:          1          1    IO-APIC-edge  ide1
>  16:      10722      11462   IO-APIC-level  nvidia
>  17:       4507       4375   IO-APIC-level  cmpci
> NMI:          0          0
> LOC:      30533      30532
> ERR:          0
> MIS:          0
> 
> noapic passed at boottime
>            CPU0       CPU1
>   0:      79226          0          XT-PIC  timer
>   1:        802          0          XT-PIC  keyboard
>   2:          0          0          XT-PIC  cascade
>   5:     275008          0          XT-PIC  ltserial
>   8:          1          0          XT-PIC  rtc
>  10:       3024          0          XT-PIC  cmpci
>  11:      60070          0          XT-PIC  nvidia
>  12:      61985          0          XT-PIC  PS/2 Mouse
>  14:      20809          0          XT-PIC  ide0
>  15:          1          0          XT-PIC  ide1
> NMI:          0          0
> LOC:      79166      79165
> ERR:        207
> MIS:          0
> 
> Does the row of zeros under CPU1 mean that the processor is non-functional, or
> merely that it is not processing interrupts?
> 
> On Wed, 25 Sep 2002 04:48, christoph hebeisen wrote:
> > uh, oh... are you sure both cpus are still working with apic switched off?
> > i'm not a multicpu expert (i don't even have a multicpu machine) but for
> > all i know smp REQUIRES apic. therefore i would assume that if the kernel
> > allows this boot option and actually switches off apic it will deactivate
> > the second cpu. not sure but i'd verify if both cpus are really _active_
> > and not only recognized when you run without apic.
> >
> 
> > --------------------------------------------------------------------------
> 
> --
> This mail is certified Virus-free as no Microsoft products were used in its
> preparation or propagation

Webmaster: Russell Nelson
Last modified: Wed Jul 30 11:02:43 EDT 2003