Re: x86 instability with 2.6.1{8,9}

[Ken Moffat <zarniwhoop@ntlworld.com>]

On Sat, Jan 06, 2007 at 02:04:59PM -0800, Randy Dunlap wrote:
> On Tue, 2 Jan 2007 19:34:59 +0000 Ken Moffat wrote:
> 
> > On Tue, Jan 02, 2007 at 01:42:32PM -0500, Len Brown wrote:
> > > 
> > > You might remove and re-insert the DIMMS.
> > > Sometimes there are poor contacts if the DIMMS are not fully seated and clicked in.
> > > 
> > > The real mystery is the 32 vs 64-bit thing.
> > > Are the devices configured the same way -- ie are they both in IOAPIC mode
> > > and /proc/interrupts looks the same for both modes?
> > > 
> > > -Len
> > 
> >  Too late, I've started memtest-86+.  If it seems ok after an
> > overnight run, I'll take a look at /proc/interrupts.  How can I tell
> > it is in IOAPIC mode, please ?  Google was not helpful for this, but
> > if it's an override, the only things on my command lines are root=
> > and video= settings.
> 
> (did anyone ever answer this?)
> 
> In IO-APIC mode, /proc/interrupts contains entries like these:
> 
>            CPU0       CPU1       
>   0:  121218123          0    IO-APIC-edge  timer
>   1:     715259          0    IO-APIC-edge  i8042
>   6:          5          0    IO-APIC-edge  floppy
>   7:          0          0    IO-APIC-edge  parport0
>   9:          0          0   IO-APIC-level  acpi
>  12:   10011272          0    IO-APIC-edge  i8042
>  14:   11561548          0    IO-APIC-edge  ide0
>  66:    4525183          0         PCI-MSI  libata
>  74:       1711          0   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb6
>  82:          4          0   IO-APIC-level  ohci_hcd:usb2, ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5
>  98:     101326          0         PCI-MSI  HDA Intel
> 106:   17747181          0         PCI-MSI  eth0
> 169:          0          0   IO-APIC-level  uhci_hcd:usb9
> 177:          3          0   IO-APIC-level  ohci1394
> 185:         15          0   IO-APIC-level  uhci_hcd:usb8, aic79xx
> 193:     427962          0   IO-APIC-level  uhci_hcd:usb7, aic79xx
> 
> If not in IO-APIC mode, lots of those will say "XT-PIC" instead
> of IO-APIC.
> 
> >  Certainly, it seems likely that the configs could be fairly
> > different in their detail.
> 
> 
 I eventually found it ("Local APIC support on uniprocessors") in
menuconfig.  In the meantime, I'd moved my 32-bit activity to a
different box (also athlon64, but a bit faster) and I had one oops
on that.  At least, I assume it was an oops - the caps and scroll
LEDs flashed, but I couldn't do anything with MagicSysrq, not even
force a reboot.  Ran diff on the various configs, changed to IO-APIC
plus an unrelated change to use libata for the cdrom.  The faster box
_seems_ stable (used for a couple of hours, and then for a whole day)
so I'm back on the original problem machine.

 Last night I reconfigured the kernel (select X86_UP_APIC, deselect
ACPI_VIDEO [ had been a module ], select ACPI_DEBUG, select PCI_MSI
(had been on in my 64-bit configs), removed some ATA/ATAPI drivers I
didn't need).  I was running on the 'old' 2.6.19.1 while I built it,
and again got the flashing LEDs after the build, but nothing logged
although I was able to force a reboot with SysRq b.

 I guess that when it does have problems, it is mostly within 30
minutes of booting - otherwise, it can be up all day.  So, for the
moment I'm hopeful that changing the config will help, but it will
be several days before I feel at all confident.

Ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce