All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pedro Pla <pedropla@holidaymarketing.com>
To: Doug Ledford <dledford@redhat.com>
Cc: linux-scsi@vger.kernel.org, linux-smp@vger.kernel.org
Subject: Re: Problem with Gdt driver under smp?
Date: Wed, 06 Nov 2002 09:27:53 +0800	[thread overview]
Message-ID: <3DC87019.3000504@holidaymarketing.com> (raw)
In-Reply-To: 20021105164106.GG16634@redhat.com

Doug Ledford wrote:

>On Tue, Nov 05, 2002 at 06:01:37PM +0800, Pedro Pla wrote:
>  
>
>>Been running the script all day and still no errors yet, and yes, it 
>>seems to have used up all the memory or so says a cat /proc/meminfo with 
>>only a few megs free and no swap activated. This is under a no smp 
>>compiled kernel, under an smp compiled kernel I think it could die while 
>>ungzipping the first source directory.. yeah it's that bad, no "subtle" 
>>problem, just an asap kernel oops or segmentation fault.. can't switch 
>>to mp 1.1 from mp 1.4 on this motherboard either, or at least I haven't 
>>found out how yet, it's an intel scb2, intel says nothing about how to 
>>do so on their sites, and the bios has no such option... at least the 
>>machine runs flawlessly all tests in non-smp mode which makes me think 
>>it isn't hardware..
>>    
>>
>
>Why would you think that?  You don't really think that the linux kernel 
>SMP support is so flaky that it can't survive the first round of 
>ungizzipping on an SMP machine do you?  I mean, after all, millions of SMP 
>boxes are out there running the linux kernel every day without a glitch.  
>If the kernel were that bad, they would *all* be dying.
>
Of course not :) I have been running linux smp machines for nearly 4 
years, since I had to compile the smp support in by putting the smp = 1 
manually ;) and it has been a breeze, that's why initially I did think 
it was definately a hardware issue, however these are "branded" machines 
and I have tried two different setups with the same kind of peices 
(identical cpu's, ram, motherboard, raid controller, etc) and both have 
failed. Yes it could be a fundamental flaw in the design or build of 
both of these machines, although that is a little out of the ordinary, 
that is why I suspected it might be some flaw somewhere in the kernel 
that gave it a hard time running on this particular setup. Or maybe a 
design flaw in the hardware that makes it not run correctly under linux? 
However all this hardware is certified to run under Redhat by both the 
manufacturer intel, and Redhat...

>  OTOH, several 
>things on the motherboard change when running SMP mode.  Power consumption 
>goes up (so a bad power supply can cause these problems), you start using 
>a CPU that isn't being used now (so a totally busted CPU could cause this, 
>swapping CPU sockets might make it start failing in UP mode as well), 
>amount of data your are pumping to RAM from CPU goes up (because you have 
>two CPUs pumping data instead of one, and if the memory controller or 
>cache coherency controller or RAM itself can't handle the increased speed 
>of data throughput you get all sorts of errors), etc.  There are *tons* of 
>things that change going from UP to SMP in the hardware and all sorts of 
>things that used to work fine can start breaking.  The fact that your 
>machine works OK in UP mode means absolutley nothing about how it will 
>work in SMP mode or whether or not the hardware is up to running SMP.
>
>  
>
Point taken, I will wait till I receive the other 4 machines with 
identical configurations, and if each and every one fails under smp mode 
must I still think it is hardware? that would be 6 seperate machines 
with identical configurations failing in smp? These are all pure intel 
except ram and hard disks. Although I did read on the intel site that 
the raid controller scrmr had problems with the scb2 motherboard, and I 
did apply the bios upgrade, but it still fails... sigh... maybe I should 
find a less stressful profession ;) after being on comps for 12 years 
you wonder just what more can fail when you are pressed for time and 
bosses are looking over your shoulder ;)




  parent reply	other threads:[~2002-11-06  1:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-31  8:37 Problem with Gdt driver under smp? Pedro Pla
2002-10-31 12:02 ` Doug Ledford
2002-11-05  1:17   ` Pedro Pla
     [not found]   ` <3DC71BF8.80100@holidaymarketing.com>
2002-11-05  3:34     ` Doug Ledford
2002-11-06  0:50       ` Pedro Pla
     [not found]       ` <3DC79701.8070802@holidaymarketing.com>
     [not found]         ` <20021105164106.GG16634@redhat.com>
2002-11-06  1:27           ` Pedro Pla [this message]
2002-11-06  3:34             ` Pedro Pla
2002-11-06  3:34               ` Pedro Pla
2002-11-06 14:33               ` Bill Davidsen
2002-11-07  2:08                 ` Pedro Pla
2002-11-07  5:10               ` Ishikawa
2002-11-07  7:34                 ` Pedro Pla
2002-11-05  3:35     ` Doug Ledford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3DC87019.3000504@holidaymarketing.com \
    --to=pedropla@holidaymarketing.com \
    --cc=dledford@redhat.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-smp@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.