system lock-up - RTFM?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

system lock-up - RTFM?

Ian Watts-2
My 3.9 workstation has started locking up on me several times a day.
The box itself has been in use for months.  It may be a coincidence that
the problem started shortly after upgrading from 3.8.

I've set ddb.panic=1 and ddb.log=1, but each lock-up just freezes the
system and leaves no clues in dmesg or /var/crash.  It almost always
happens under somewhat heavy load.  Other than swapping out various bits
of hardware, which would involve buying new bits, are there any other
man pages or useful documents that might help me figure out what the
problem is?  Is this a typical bad RAM scenario?  I don't expect someone
to solve this problem for me, but any pointers to useful information
would be appreciated.

Thanks,

-- Ian

Reply | Threaded
Open this post in threaded view
|

Re: system lock-up - RTFM?

Sam Chill
On 6/6/06, Ian Watts <[hidden email]> wrote:
> Other than swapping out various bits
> of hardware, which would involve buying new bits, are there any other
> man pages or useful documents that might help me figure out what the
> problem is?

There is a very handy program called memtest86 which can test your
memory to see if it is bad.

http://www.memtest86.com/

Reply | Threaded
Open this post in threaded view
|

Re: system lock-up - RTFM?

Stuart Henderson
> On 6/6/06, Ian Watts <[hidden email]> wrote:
> >Other than swapping out various bits
> >of hardware, which would involve buying new bits, are there any other
> >man pages or useful documents that might help me figure out what the
> >problem is?

Try running GENERIC.MP kernel, on the box I had with a hardware
failure (bad cpu) MP usually panicked where GENERIC usually froze.

On 2006/06/06 13:11, Sam Chill wrote:
> There is a very handy program called memtest86 which can test your
> memory to see if it is bad.

It tells you if it's bad, but it doesn't tell you if it's good.

Reply | Threaded
Open this post in threaded view
|

Re: system lock-up - RTFM?

Federico Giannici
In reply to this post by Ian Watts-2
Ian Watts wrote:

> My 3.9 workstation has started locking up on me several times a day. The
> box itself has been in use for months.  It may be a coincidence that the
> problem started shortly after upgrading from 3.8.
>
> I've set ddb.panic=1 and ddb.log=1, but each lock-up just freezes the
> system and leaves no clues in dmesg or /var/crash.  It almost always
> happens under somewhat heavy load.  Other than swapping out various bits
> of hardware, which would involve buying new bits, are there any other
> man pages or useful documents that might help me figure out what the
> problem is?  Is this a typical bad RAM scenario?  I don't expect someone
> to solve this problem for me, but any pointers to useful information
> would be appreciated.

We have exactly the same problem with an OpenBSD 3.9-stable AMD64. But
the problem occurred even with 3.8.

The PC freezes (with no error message) usually (but not always and not
only) during a large dump.

We changed the CPU, the RAM and the RAID controller (an Intel SRCU42L,
gdt driver) and upgraded the BIOS and the operating system, but the
problem remains.

The dmesg is at the end of this email.

Bye.



OpenBSD 3.9-stable (GENERIC) #0: Mon Jun  5 12:29:16 CEST 2006
     [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 2146758656 (2096444K)
avail mem = 1835651072 (1792628K)
using 22937 buffers containing 214884352 bytes (209848K) of memory
mainbus0 (root)
cpu0 at mainbus0: (uniprocessor)
cpu0: AMD Athlon(tm) 64 Processor 3500+, 2203.23 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
pci0 at mainbus0 bus 0: configuration mode 1
pchb0 at pci0 dev 0 function 0 "VIA K8HTB Host" rev 0x00
pchb1 at pci0 dev 0 function 1 "VIA K8HTB Host" rev 0x00
pchb2 at pci0 dev 0 function 2 "VIA K8HTB Host" rev 0x00
pchb3 at pci0 dev 0 function 3 "VIA K8HTB Host" rev 0x00
pchb4 at pci0 dev 0 function 4 "VIA K8HTB Host" rev 0x00
pchb5 at pci0 dev 0 function 7 "VIA K8HTB Host" rev 0x00
ppb0 at pci0 dev 1 function 0 "VIA K8HTB AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Radeon VE QY" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
skc0 at pci0 dev 10 function 0 "Marvell Yukon 88E8001/8003/8010" rev
0x13, Marvell Yukon Lite (0x9): irq 10
sk0 at skc0 port A, address 00:11:d8:8d:8b:cd
eephy0 at sk0 phy 0: Marvell 88E1011 Gigabit PHY, rev. 5
gdt0 at pci0 dev 13 function 0 "Intel GDT RAID" rev 0x00: irq 5 dpmem
eff00000 2-bus 1 cache device
gdt0: ver 222, cache on, strategy 2, writeback on, blksz 32
gdt0: raw feat 1 cache feat 101
scsibus0 at gdt0: 35 targets
sd0 at scsibus0 targ 0 lun 0: <ICP, Host drive #00, > SCSI2 0/direct fixed
sd0: 105661MB, 105661 cyl, 64 head, 32 sec, 512 bytes/sec, 216395550 sec
total
scsibus1 at gdt0: 16 targets
scsibus2 at gdt0: 16 targets
pciide0 at pci0 dev 15 function 0 "VIA VT6420 SATA" rev 0x80: DMA
pciide0: using irq 10 for native-PCI interrupt
pciide1 at pci0 dev 15 function 1 "VIA VT82C571 IDE" rev 0x06: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
pciide1: channel 0 disabled (no drives)
atapiscsi0 at pciide1 channel 1 drive 0
scsibus3 at atapiscsi0: 2 targets
cd0 at scsibus3 targ 0 lun 0: <HL-DT-ST, DVD-ROM GDR8163B, 0L23> SCSI0
5/cdrom removable
cd0(pciide1:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 16 function 0 "VIA VT83C572 USB" rev 0x81: irq 11
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: VIA UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1 at pci0 dev 16 function 1 "VIA VT83C572 USB" rev 0x81: irq 11
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: VIA UHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2 at pci0 dev 16 function 2 "VIA VT83C572 USB" rev 0x81: irq 10
usb2 at uhci2: USB revision 1.0
uhub2 at usb2
uhub2: VIA UHCI root hub, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhci3 at pci0 dev 16 function 3 "VIA VT83C572 USB" rev 0x81: irq 10
usb3 at uhci3: USB revision 1.0
uhub3 at usb3
uhub3: VIA UHCI root hub, rev 1.00/1.00, addr 1
uhub3: 2 ports with 2 removable, self powered
ehci0 at pci0 dev 16 function 4 "VIA VT6202 USB" rev 0x86: irq 5
usb4 at ehci0: USB revision 2.0
uhub4 at usb4
uhub4: VIA EHCI root hub, rev 2.00/1.00, addr 1
uhub4: 8 ports with 8 removable, self powered
viapm0 at pci0 dev 17 function 0 "VIA VT8237 ISA" rev 0x00
iic0 at viapm0
"unknown" at iic0 addr 0x18 not configured
lm1 at iic0 addr 0x2f: W83791SD
pchb6 at pci0 dev 24 function 0 "AMD AMD64 HyperTransport" rev 0x00
pchb7 at pci0 dev 24 function 1 "AMD AMD64 Address Map" rev 0x00
pchb8 at pci0 dev 24 function 2 "AMD AMD64 DRAM Cfg" rev 0x00
pchb9 at pci0 dev 24 function 3 "AMD AMD64 Misc Cfg" rev 0x00
isa0 at mainbus0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0: <PC speaker>
spkr0 at pcppi0
lm0 at isa0 port 0x290/8: W83627THF
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
dkcsum: sd0 matches BIOS drive 0x80
root on sd0a
rootdev=0x400 rrootdev=0xd00 rawdev=0xd02


--
___________________________________________________
     __
    |-                      [hidden email]
    |ederico Giannici      http://www.neomedia.it
___________________________________________________

Reply | Threaded
Open this post in threaded view
|

Re: system lock-up - RTFM?

Ian Watts-2
In reply to this post by Stuart Henderson
On Tue, 6 Jun 2006, Stuart Henderson wrote:

>> On 6/6/06, Ian Watts <[hidden email]> wrote:
>>> Other than swapping out various bits
>>> of hardware, which would involve buying new bits, are there any other
>>> man pages or useful documents that might help me figure out what the
>>> problem is?
>
> Try running GENERIC.MP kernel, on the box I had with a hardware
> failure (bad cpu) MP usually panicked where GENERIC usually froze.

Thanks for the suggestion.  I rebooted with /bsd.mp and so far have not
been able to lock up the system, despite taxing it as much as possible
for an extended period of time.  I'll continue running MP for the time
being and see if the problem does in fact return.


>> There is a very handy program called memtest86 which can test your
>> memory to see if it is bad.
>
> It tells you if it's bad, but it doesn't tell you if it's good.

Time permitting, I'll give that go, too.  I know the extended test takes
quite some time (512MB RAM on my box).  Maybe tonight.


-- Ian

Reply | Threaded
Open this post in threaded view
|

Re: system lock-up - RTFM?

Breen Ouellette
In reply to this post by Stuart Henderson
Stuart Henderson wrote:
> On 2006/06/06 13:11, Sam Chill wrote:
>  
>> There is a very handy program called memtest86 which can test your
>> memory to see if it is bad.
>>    
>
> It tells you if it's bad, but it doesn't tell you if it's good.
>
>  
Of course not. It doesn't even tell you if your memory is bad. It merely
tells you if there is a problem reading and writing test patterns to
memory. An error detected by memtest86 could just as easily indicate a
CPU, mainboard, or power supply problem. And there simply is no
reasonable method in existence which can tell you if your memory is
good. If there was, no bad memory would ever leave the factory. There
are merely degrees of quality.

This doesn't diminish memtest86's usefulness as a tool for avoiding a
part by part elimination rebuild.

As a former owner of two different custom PC shops, I would like to
point out that memtest86 successfully located memory reads or writes as
the problem on virtually all trouble PCs out of thousands of builds that
I have performed over the years (most of the rest were hard drive
errors, a few were related to faulty optical drives). The only systems
which had memory problems that were not detected by memtest86 were
systems in which low grade parts were used for the build. If you use
second or third tier manufacturers for your mainboard, memory, and power
supply then you deserve your memory errors as far as I'm concerned.
Stick with parts that are high quality, follow the RAM compatibility
list for you mainboard, and you will likely never experience any memory
errors. And if you do, there is a very good chance that memtest86 will
catch them. If you still fall into the minuscule percentage of memory
errors that slip through these actions, then you will likely have to
part out and test the machine piece by piece. Out of three thousand or
so computer builds, I can count the number of machines that fall into
this category on one hand.

Also, be sure to run memtest86 for at least a 12 hour period. I have
seen machines which do not necessarily spit out a memory error on every
pass of memtest86.

If memtest86 passes without error for twelve hours, then download and
run the hard drive diagnostic software provided by the manufacturer.

After that, get ready for several stimulating hours of part by part
elimination by exchanging each suspect part for another of similar type
(not the same type) of equal or greater quality than the suspect part.
After each part exchange you will have to reinstall the OS to ensure
that you are not experiencing errors which were introduced into the OS
during the last install. You will find the problem via this route.

FUN!!

Breeno

Reply | Threaded
Open this post in threaded view
|

Re: system lock-up - RTFM?

Shane J Pearson
Hi Breen,

On 2006.06.07, at 4:39 AM, Breen Ouellette wrote:

> Of course not. It doesn't even tell you if your memory is bad.

It can if you use it to identify a potentially faulty module and then  
move that module to another slot or machine and the problem follows  
the module (as reported by memtest86), instead of following the  
machine or original "problem" slot.

I have a faulty DDR2 SODIMM in my laptop which memtest86 shows to  
fail in the same place every single time. This machine has 2 SODIMMS.  
If I swap their positions in the memory slots in my laptop, memtest86  
shows the errors follow the module to the other slot, while showing  
the original potentially faulty slot to be fine. Same deal if I swap  
the memory between my laptop and my girlfriends. Problem follows module.

I take that as memtest86 being able to tell me that my memory is bad.  
It's the same as with many tools. As you already alluded to, you can  
get more accurate measurements with more thorough testing process.  
But as far as I am concerned, memtest86 can be used to identify bad  
memory.


Shane

Reply | Threaded
Open this post in threaded view
|

Re: system lock-up - RTFM?

Breen Ouellette
Shane J Pearson wrote:
> I have a faulty DDR2 SODIMM in my laptop which memtest86 shows to fail
> in the same place every single time. This machine has 2 SODIMMS. If I
> swap their positions in the memory slots in my laptop, memtest86 shows
> the errors follow the module to the other slot, while showing the
> original potentially faulty slot to be fine. Same deal if I swap the
> memory between my laptop and my girlfriends. Problem follows module.

Yeah, sure, in some cases when memtest86 reports a memory error it is an
indication of faulty memory. But there are many situations where
memtest86 detects a memory error which is related to a faulty CPU,
mainboard, or power supply, or where a memory module is not compatible
with the mainboard but is otherwise fine, or where there is an issue
with heat buildup. An error in memtest86 does not specify which part is
giving you problems, only that the problem is memory related!

At best, you can only expect memtest86 to identify a memory read or
write error. It is up to the thinking being to eliminate the possible
reasons for the memory error. If you blindly believe that your memory is
bad when memtest86 detects an error then you are setting yourself up for
a lot of pain and sorrow if in fact the problem is related to your
northbridge overheating, as an example.

You've basically stated this above. You found an error with memtest86
which alerted you to a problem (or more likely your laptop misbehaving
alerted you to a problem and memtest86 narrowed the scope of the
problem). You then took action and tested your memory in different
configurations and then on a different machine, and by using your brain
you were able to narrow down the problem to the memory stick itself. You
identified the stick, memtest86 only started you on the right path by
pointing out that there was a memory error. If it hadn't been the stick,
then you would have had to consider something else.

Did you actually read and then understand my original post? The
difference between a memory error and a faulty stick of RAM may be
subtle, but there is a difference none the less. Telling someone new to
memtest86 that it detects bad memory sticks is misleading and could give
them a nice headache if their problem is not the stick.

Breeno

Reply | Threaded
Open this post in threaded view
|

Re: system lock-up - RTFM?

Shane J Pearson
On 2006.06.07, at 2:42 PM, Breen Ouellette wrote:

> Did you actually read and then understand my original post?

Yes. I replied because I just wanted to clarify that memtest86 can be  
used to identify bad memory down to a stick, through the use of it  
and a thorough testing process.

> Telling someone new to memtest86 that it detects bad memory sticks  
> is misleading and could give them a nice headache if their problem  
> is not the stick.

If they read the "Troubleshooting Memory Errors" info for memtest86,  
linked to from the old site and the new site, they'll see that to  
isolate the defective stick, they can remove, rotate or replace  
modules to see what device the error follows.

Like anything, memtest86 is a tool which can be used well or misused.  
It is up to the user to put the required effort into getting the most  
of it. Memtest86 can be used to detect bad memory sticks. It just  
does not isolate to a stick on it's own. It should be obvious to  
anyone, that some sort of elimination process will be required, once  
they have run it once.

You seem to think that I disagree with you? I am merely clarifying my  
point of view which seems to be the same as yours.

I can think of a situation which could be quite interesting to  
isolate a stick. Old BX motherboards with 4 SDRAM slots. Many could  
not power all 4 modules if they were particularly power hungry  
modules. Those motherboards typically supported memory modules  
without built in buffering (buffering in the electronic sense to keep  
digital states within required tolerances) and if the chipset was  
close to the maximum power it could deliver to the RAM, then errors  
would be all over the place and mostly non-repeatable. Rotating or  
replacing modules would thus be pointless. Worse still, removing  
modules might give the incorrect impression of finding a faulty  
module, when in fact it was a power delivery problem and removing  
*any* of the modules would have the same effect.


Shane

Reply | Threaded
Open this post in threaded view
|

Re: system lock-up - RTFM?

Federico Giannici
In reply to this post by Federico Giannici
We have changed the mainboard too, but it crashed again during the dump
(at a different time in the dump of the previous crash).

So, having changed the mainboard, the CPU, the RAM and the RAID
controller, I can say that it's not an hardware problem, but a software one.

And probably only with the amd64 architecture, because we have other two
almost identical PCs but with i386 architecture, and they never had this
problem. OK, the three PCs have different applications running, but the
kind of crash (complete freeze of the machine, with no error at all)
seems to me more a kernel crash that a userland one...


Bye.


Federico Giannici wrote:

> Ian Watts wrote:
>> My 3.9 workstation has started locking up on me several times a day.
>> The box itself has been in use for months.  It may be a coincidence
>> that the problem started shortly after upgrading from 3.8.
>>
>> I've set ddb.panic=1 and ddb.log=1, but each lock-up just freezes the
>> system and leaves no clues in dmesg or /var/crash.  It almost always
>> happens under somewhat heavy load.  Other than swapping out various
>> bits of hardware, which would involve buying new bits, are there any
>> other man pages or useful documents that might help me figure out what
>> the problem is?  Is this a typical bad RAM scenario?  I don't expect
>> someone to solve this problem for me, but any pointers to useful
>> information would be appreciated.
>
> We have exactly the same problem with an OpenBSD 3.9-stable AMD64. But
> the problem occurred even with 3.8.
>
> The PC freezes (with no error message) usually (but not always and not
> only) during a large dump.
>
> We changed the CPU, the RAM and the RAID controller (an Intel SRCU42L,
> gdt driver) and upgraded the BIOS and the operating system, but the
> problem remains.
>
> The dmesg is at the end of this email.
>
> Bye.
>
>
>
> OpenBSD 3.9-stable (GENERIC) #0: Mon Jun  5 12:29:16 CEST 2006
>     [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC
> real mem = 2146758656 (2096444K)
> avail mem = 1835651072 (1792628K)
> using 22937 buffers containing 214884352 bytes (209848K) of memory
> mainbus0 (root)
> cpu0 at mainbus0: (uniprocessor)
> cpu0: AMD Athlon(tm) 64 Processor 3500+, 2203.23 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
>
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
> 64b/line 16-way L2 cache
> cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully
> associative
> cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully
> associative
> pci0 at mainbus0 bus 0: configuration mode 1
> pchb0 at pci0 dev 0 function 0 "VIA K8HTB Host" rev 0x00
> pchb1 at pci0 dev 0 function 1 "VIA K8HTB Host" rev 0x00
> pchb2 at pci0 dev 0 function 2 "VIA K8HTB Host" rev 0x00
> pchb3 at pci0 dev 0 function 3 "VIA K8HTB Host" rev 0x00
> pchb4 at pci0 dev 0 function 4 "VIA K8HTB Host" rev 0x00
> pchb5 at pci0 dev 0 function 7 "VIA K8HTB Host" rev 0x00
> ppb0 at pci0 dev 1 function 0 "VIA K8HTB AGP" rev 0x00
> pci1 at ppb0 bus 1
> vga1 at pci1 dev 0 function 0 "ATI Radeon VE QY" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> skc0 at pci0 dev 10 function 0 "Marvell Yukon 88E8001/8003/8010" rev
> 0x13, Marvell Yukon Lite (0x9): irq 10
> sk0 at skc0 port A, address 00:11:d8:8d:8b:cd
> eephy0 at sk0 phy 0: Marvell 88E1011 Gigabit PHY, rev. 5
> gdt0 at pci0 dev 13 function 0 "Intel GDT RAID" rev 0x00: irq 5 dpmem
> eff00000 2-bus 1 cache device
> gdt0: ver 222, cache on, strategy 2, writeback on, blksz 32
> gdt0: raw feat 1 cache feat 101
> scsibus0 at gdt0: 35 targets
> sd0 at scsibus0 targ 0 lun 0: <ICP, Host drive #00, > SCSI2 0/direct fixed
> sd0: 105661MB, 105661 cyl, 64 head, 32 sec, 512 bytes/sec, 216395550 sec
> total
> scsibus1 at gdt0: 16 targets
> scsibus2 at gdt0: 16 targets
> pciide0 at pci0 dev 15 function 0 "VIA VT6420 SATA" rev 0x80: DMA
> pciide0: using irq 10 for native-PCI interrupt
> pciide1 at pci0 dev 15 function 1 "VIA VT82C571 IDE" rev 0x06: DMA,
> channel 0 configured to compatibility, channel 1 configured to
> compatibility
> pciide1: channel 0 disabled (no drives)
> atapiscsi0 at pciide1 channel 1 drive 0
> scsibus3 at atapiscsi0: 2 targets
> cd0 at scsibus3 targ 0 lun 0: <HL-DT-ST, DVD-ROM GDR8163B, 0L23> SCSI0
> 5/cdrom removable
> cd0(pciide1:1:0): using PIO mode 4, DMA mode 2
> uhci0 at pci0 dev 16 function 0 "VIA VT83C572 USB" rev 0x81: irq 11
> usb0 at uhci0: USB revision 1.0
> uhub0 at usb0
> uhub0: VIA UHCI root hub, rev 1.00/1.00, addr 1
> uhub0: 2 ports with 2 removable, self powered
> uhci1 at pci0 dev 16 function 1 "VIA VT83C572 USB" rev 0x81: irq 11
> usb1 at uhci1: USB revision 1.0
> uhub1 at usb1
> uhub1: VIA UHCI root hub, rev 1.00/1.00, addr 1
> uhub1: 2 ports with 2 removable, self powered
> uhci2 at pci0 dev 16 function 2 "VIA VT83C572 USB" rev 0x81: irq 10
> usb2 at uhci2: USB revision 1.0
> uhub2 at usb2
> uhub2: VIA UHCI root hub, rev 1.00/1.00, addr 1
> uhub2: 2 ports with 2 removable, self powered
> uhci3 at pci0 dev 16 function 3 "VIA VT83C572 USB" rev 0x81: irq 10
> usb3 at uhci3: USB revision 1.0
> uhub3 at usb3
> uhub3: VIA UHCI root hub, rev 1.00/1.00, addr 1
> uhub3: 2 ports with 2 removable, self powered
> ehci0 at pci0 dev 16 function 4 "VIA VT6202 USB" rev 0x86: irq 5
> usb4 at ehci0: USB revision 2.0
> uhub4 at usb4
> uhub4: VIA EHCI root hub, rev 2.00/1.00, addr 1
> uhub4: 8 ports with 8 removable, self powered
> viapm0 at pci0 dev 17 function 0 "VIA VT8237 ISA" rev 0x00
> iic0 at viapm0
> "unknown" at iic0 addr 0x18 not configured
> lm1 at iic0 addr 0x2f: W83791SD
> pchb6 at pci0 dev 24 function 0 "AMD AMD64 HyperTransport" rev 0x00
> pchb7 at pci0 dev 24 function 1 "AMD AMD64 Address Map" rev 0x00
> pchb8 at pci0 dev 24 function 2 "AMD AMD64 DRAM Cfg" rev 0x00
> pchb9 at pci0 dev 24 function 3 "AMD AMD64 Misc Cfg" rev 0x00
> isa0 at mainbus0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5
> pckbd0 at pckbc0 (kbd slot)
> pckbc0: using irq 1 for kbd slot
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> pcppi0 at isa0 port 0x61
> midi0 at pcppi0: <PC speaker>
> spkr0 at pcppi0
> lm0 at isa0 port 0x290/8: W83627THF
> fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
> fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
> dkcsum: sd0 matches BIOS drive 0x80
> root on sd0a
> rootdev=0x400 rrootdev=0xd00 rawdev=0xd02
>
>


--
___________________________________________________
     __
    |-                      [hidden email]
    |ederico Giannici      http://www.neomedia.it
___________________________________________________

Reply | Threaded
Open this post in threaded view
|

Re: system lock-up - RTFM?

Ian Watts-2
In reply to this post by Shane J Pearson
On Wed, 7 Jun 2006, Shane J Pearson wrote:

> On 2006.06.07, at 2:42 PM, Breen Ouellette wrote:

<snip>

>> Telling someone new to memtest86 that it detects bad memory sticks is
>> misleading and could give them a nice headache if their problem is
>> not the stick.
>
> If they read the "Troubleshooting Memory Errors" info for memtest86, linked
> to from the old site and the new site, they'll see that to isolate the
> defective stick, they can remove, rotate or replace modules to see what
> device the error follows.

Thanks to you guys and "Troubleshooting Memory Errors", which I had
read, moving the one 512M stick from slot one to slot two has at the
very least made a drastic improvement.

slot 1 - hundreds of errors in memtest which resulted in the box
powering off after ten minutes or so.

slot 2 - eight errors in test 7 of pass 4 of 8 passes.  no lock-ups
since.

I appreciate the discussion.  On a critical box and with a little more
time, I'd do a thorough series of tests as suggested, and will on this
one soon.

And next time I'll make sure to get "quality" components...

Thanks again for the input,


-- Ian