[Tfug] mobo troubles

Glenn Shannon tfug@tfug.org
Mon Dec 2 23:03:02 2002


I have several AMD systems around the house, the most recent addition
being my new laptop (Compaq 1210US) which has an AMD Duron 850 under the
hood.

All my AMD systems have Via chipsets.

All my AMD systems gets spurious interrupt requests on IRQ7.

I have a single P3-850 (fileserver) with an intel BX133 chipset, that
does not have this problem..

So my deductive reasoning tells me that one of the following is true:

a) the Via chipset is being twidgy.

b) the AMD lineup is twidgy.

c) a combination of a and b

Anybody out there have an intel chip on a via-based mobo that can
compare notes?



-----Original Message-----
From: tfug-admin@tfug.org [mailto:tfug-admin@tfug.org] On Behalf Of
jbrouse@cox.net
Sent: Monday, December 02, 2002 10:51 PM
To: tfug@tfug.org
Subject: Re: Re: [Tfug] mobo troubles

Hello,

      I have Linux installed on an Intel p4 board no problems.  I also
have Linux installed on a AMD platform and I also have ramdom lockup
problems.  The other thing that is wierd about it is that the same AMD
system that also dual boots to Windows XP professional has no lockups
under Microsoft Windows.  My intel system does not lock under Linux or
Microsoft Windows.



Jim

> 
> From: Harry  McGregor <micros@azstarnet.com>
> Date: 2002/11/24 Sun PM 12:24:41 EST
> To: <tfug@tfug.org>
> Subject: Re: [Tfug] mobo troubles
> 
> I just sshed into a server running a K7S5A, and here are a few key
bits of
> info.  I would be that either the board has memory timing issues, or
does
> not like it's cpu.
> 
> harry@server:~$ uptime
>  10:27:49 up 47 days, 14:38,  1 user,  load average: 0.00, 0.00, 0.00
> 
> harry@server:~$ cat /proc/cpuinfo
> processor : 0
> vendor_id : AuthenticAMD
> cpu family   : 6
> model   : 6
> model name   : AMD Athlon(tm) XP 1600+
> stepping  : 2
> cpu MHz   : 1394.086
> cache size   : 256 KB
> fdiv_bug  : no
> hlt_bug   : no
> f00f_bug  : no
> coma_bug  : no
> fpu     : yes
> fpu_exception : yes
> cpuid level  : 1
> wp      : yes
> flags   : fpu vme de tsc msr pae mce cx8 sep mtrr pge mca cmov pat
pse36
> mmx fxsr sse syscall mmxext 3dnowext 3dnow
> bogomips  : 2785.28
> 
> harry@server:~$ cat /proc/interrupts
>            CPU0
>   0:  411354676          XT-PIC  timer
>   1:         80          XT-PIC  keyboard
>   2:          0          XT-PIC  cascade
>   5:    9853925          XT-PIC  eth2, aic7xxx
>   8:          3          XT-PIC  rtc
>  11:  183471325          XT-PIC  eth1
>  14:    4896231          XT-PIC  ide0
>  15:    4874757          XT-PIC  ide1
> NMI:          0
> ERR:          0
> 
> 
> 			Harry
> 
> On Sun, 24 Nov 2002, Choprboy wrote:
> 
> > On Sunday 24 November 2002 01:14 am, John Gruenenfelder wrote:
> > [snip]
> > > I borrowed a pair of PC2100 256MB DDR sticks from a friend today.
The
> > > system is much more stable with that memory, *but* I still get
some ERR
> > > interrupts. After about one hour of running various burn* tests,
there were
> > > some 26 ERR interrupts.  Quite a bit better than my previous 3500
or
> > > outright lockup.  The system did NOT, however, lockup or behave
oddly in
> > > anyway, even when running the same tests that, with my memory,
would cause
> > > a lockup very quickly.
> > >
> > > But now I'm back with my memory.  After checking on the Net, I've
verified
> > > that my memory (Winbond W981208AH-75) is indeed PC133 CAS3, though
Winbond
> > > unfortunately doesn't seem to keep specs online for their no
longer offered
> > > chips.  So...  it seems to me that it should be working
> > [snip]
> > > Anyhow... based on the evidence thus presented, is the mobo
probably okay
> > > and my memory just flaky at 100MHz and 133MHz bus speeds?
> >
> > Hummm, interesting. I did a little more research on memory. It might
be a
> > combination of slower memory and a flaky memory bus. According to
the kernel
> > documentation, the ERR interrupt is the IO-APIC bus error indication
(APIC is
> > the SMB interconnect bus). But I have it in my laptop and other
single CPU
> > boxes as well, so my guess is it has been expanded to mean an error
on the
> > CPU bus. Unlike memory, CPU busses still have extensive parity
checking, so
> > most errors are detectable/recoverable by a retransmit on the bus.
I've never
> > had mine go above 1 on my laptop that I recall (it always boots with
1) and
> > my quad Xeon hasn't had any in an hour of recursive kernel compiles.
> >
> > This makes me think now (given you still have errors with faster
memory) that
> > you might be having problems more with the CPU<->chipset<->memory
bus. Might
> > actually be slightly flaky motherboard or even CPU.
> >
> > Adrian
> > _______________________________________________
> > tfug mailing list
> > tfug@tfug.org
> > http://www.tfug.org/mailman/listinfo/tfug
> >
> 
> --
> Harry McGregor, CEO, Co-Founder
> Hmcgregor@osef.org, (520) 661-7875 (CELL)
> Open Source Education Foundation, http://www.osef.org
> A non-profit tax exempt charitable organization
> 
> _______________________________________________
> tfug mailing list
> tfug@tfug.org
> http://www.tfug.org/mailman/listinfo/tfug
> 

_______________________________________________
tfug mailing list
tfug@tfug.org
http://www.tfug.org/mailman/listinfo/tfug