Re: SB Live (or RAM parity?) crash on today's -CURRENT
On Thu, Jul 06, 2000 at 06:32:49PM -0700, Doug Barton wrote: On Thu, 6 Jul 2000, Thomas Stromberg wrote: 'panic: RAM parity error, likely hardware failure.' This one had me confused at first, because it blamed a RAM parity error. As this is a brand new machine (Gateway GP-800), so I first thought I got a bad batch. Then I realized this only happens with apps that try to do sound stuff. This is a known problem with all PCI sound cards. It happens most often with ECC ram, but it also happens without. What kind of NIC do you have, and specifically, is it a PCI card or ISA? We're trying to track that bit down too. I see it with: mike@gurgle:~$ dmesg | grep vr0 vr0: VIA VT3043 Rhine I 10/100BaseTX port 0xb000-0xb07f mem 0xdf80-0xdf80007f irq 10 at device 10.0 on pci0 The machine does have ECC ram. If you need more, let me know and I'll give you what you need... -- Mike Bristow, seebitwopie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SB Live (or RAM parity?) crash on today's -CURRENT
On 07-Jul-00 Doug Barton wrote: This is a known problem with all PCI sound cards. It happens most often with ECC ram, but it also happens without. What kind of NIC do you have, and specifically, is it a PCI card or ISA? We're trying to track that bit down too. Could it be related to the way my SB128 causes glitches on my SiS530 AGP video when playing PCM (I've never worried much about it, the way the video shares system memory seems a little iffy to me) ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SB Live (or RAM parity?) crash on today's -CURRENT
'panic: RAM parity error, likely hardware failure.'
This one had me confused at first, because it blamed a RAM parity
error. As this is a brand new machine (Gateway GP-800), so I first thought
I got a bad batch. Then I realized this only happens with apps that try to
do sound stuff. It's also doubtful that it's a RAM parity error due to the
severe compiling workout I've given it in the last 24 hours (134 ports, a
few kernels and several attempts make world).
Unfortunatly, since this machine was installed with
yesterdays build to begin with, I cannot confirm whether or sound works on
older builds (if needed for testing, I can rollback to an earlier kern
revision..). I can get it to crash just by playing mpg123 or restarting
esd.
machine:
FreeBSD aesthetic.detachment.org 5.0-CURRENT FreeBSD 5.0-CURRENT
#0: Thu Jul 6 12:55:50 EDT 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/AESTHETIX i386
gdb -k backtrace:
=
IdlePTD 3555328
initial pcb at 2dd180
panicstr: RAM parity error, likely hardware failure.
panic messages:
---
panic: RAM parity error, likely hardware failure.
syncing disks... 14 11
done
Uptime: 10m21s
dumping to dev #ad/0x20001, offset 786432
dump ata0: resetting devices .. done
128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111
110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90
89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40
39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15
14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
303 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
#1 0xc0151320 in poweroff_wait (junk=0xc0291e80, howto=-903562160)
at ../../kern/kern_shutdown.c:553
#2 0xc0260341 in isa_nmi (cd=0) at ../../i386/isa/intr_machdep.c:254
#3 0xc025a652 in trap (frame={tf_fs = -1058078704, tf_es = 16,
tf_ds = -903610352, tf_edi = -1058025472, tf_esi = 49151,
tf_ebp = -903562084, tf_isp = -903562108, tf_ebx = 4, tf_edx = 4260,
tf_ecx = 49151, tf_eax = 49151, tf_trapno = 19, tf_err = 0,
tf_eip = -1072503013, tf_cs = 8, tf_eflags = 582, tf_esp = 16,
tf_ss = -903562048}) at ../../i386/i386/trap.c:583
#4 0xc012e71b in emu_wr (sc=0xc0efd000, regno=4, data=49151, size=4)
at machine/cpufunc.h:331
#5 0xc012e807 in emu_wrptr (sc=0xc0efd000, chn=0, reg=16, data=49151)
at ../../dev/sound/pci/emu10k1.c:258
#6 0xc012ef82 in emu_vwrite (sc=0xc0efd000, v=0xc0efd088)
at ../../dev/sound/pci/emu10k1.c:585
#7 0xc012f21b in emupchan_trigger (data=0xc0efda88, go=1)
at ../../dev/sound/pci/emu10k1.c:719
#8 0xc0135a58 in chn_trigger (c=0xc0ef9800, go=1)
at ../../dev/sound/pcm/channel.c:1251
#9 0xc0134a06 in chn_wrintr (c=0xc0ef9800)
at ../../dev/sound/pcm/channel.c:385
#10 0xc013503f in chn_intr (c=0xc0ef9800) at
../../dev/sound/pcm/channel.c:785
#11 0xc01350b7 in chn_start (c=0xc0ef9800) at
../../dev/sound/pcm/channel.c:811
#12 0xc0134b33 in chn_write (c=0xc0ef9800, buf=0xca24bedc)
at ../../dev/sound/pcm/channel.c:476
#13 0xc0135e70 in dsp_write (d=0xc0ef7c00, chan=0, buf=0xca24bedc,
flag=131089)
at ../../dev/sound/pcm/dsp.c:194
#14 0xc0137e21 in sndwrite (i_dev=0xc0efa800, buf=0xca24bedc, flag=131089)
at ../../dev/sound/pcm/sound.c:359
#15 0xc018bffd in spec_write (ap=0xca24be70)
at ../../miscfs/specfs/spec_vnops.c:291
#16 0xc0221c38 in ufsspec_write (ap=0xca24be70)
at ../../ufs/ufs/ufs_vnops.c:1857
#17 0xc02220ed in ufs_vnoperatespec (ap=0xca24be70)
at ../../ufs/ufs/ufs_vnops.c:2305
#18 0xc01874e4 in vn_write (fp=0xc105ae00, uio=0xca24bedc,
cred=0xc102f200,
flags=0, p=0xca212100) at vnode_if.h:363
#19 0xc0161ca6 in dofilewrite (p=0xca212100, fp=0xc105ae00, fd=4,
buf=0x8056000, nbyte=4096, offset=-1, flags=0) at ../../sys/file.h:157
#20 0xc0161b9b in write (p=0xca212100, uap=0xca24bf80)
at ../../kern/sys_generic.c:308
#21 0xc025af01 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134569984, tf_esi = 55, tf_ebp = -1077937444,
tf_isp = -903561260, tf_ebx = 671725864, tf_edx = 671686271,
tf_ecx = 7807, tf_eax = 4, tf_trapno = 22, tf_err = 2,
tf_eip = 672214240, tf_cs = 31, tf_eflags = 663, tf_esp =
-1077937488,
tf_ss = 47}) at ../../i386/i386/trap.c:1126
#22 0xc0250205 in Xint0x80_syscall ()
#23 0x804a0d9 in ?? ()
#24 0x804901d in ?? ()
dmesg:
==
CPU: Pentium III/Pentium III Xeon/Celeron (796.54-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x683 Stepping = 3
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM
real memory = 134217728 (131072K bytes)
avail memory = 127098880 (124120K bytes)
Preloaded elf kernel "kernel" at 0xc0352000.
Pentium Pro MTRR support enabled
md0: Malloc disk
npx0: math processor on
Re: SB Live (or RAM parity?) crash on today's -CURRENT
I filed a PR on this a little while ago. i386/19410.It happens on 4.0-STABLE (as
of
Tue Jun 20 19:40:01 PDT 2000), too. I have a revision 5 SBLive card. An interesting
commonality (possible connection) is that I have a Gateway system; This is a GP6-450.
Tim
On Thu, Jul 06, 2000 at 02:26:01PM -0400, Thomas Stromberg wrote:
'panic: RAM parity error, likely hardware failure.'
This one had me confused at first, because it blamed a RAM parity
error. As this is a brand new machine (Gateway GP-800), so I first thought
I got a bad batch. Then I realized this only happens with apps that try to
do sound stuff. It's also doubtful that it's a RAM parity error due to the
severe compiling workout I've given it in the last 24 hours (134 ports, a
few kernels and several attempts make world).
Unfortunatly, since this machine was installed with
yesterdays build to begin with, I cannot confirm whether or sound works on
older builds (if needed for testing, I can rollback to an earlier kern
revision..). I can get it to crash just by playing mpg123 or restarting
esd.
machine:
FreeBSD aesthetic.detachment.org 5.0-CURRENT FreeBSD 5.0-CURRENT
#0: Thu Jul 6 12:55:50 EDT 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/AESTHETIX i386
gdb -k backtrace:
=
IdlePTD 3555328
initial pcb at 2dd180
panicstr: RAM parity error, likely hardware failure.
panic messages:
---
panic: RAM parity error, likely hardware failure.
syncing disks... 14 11
done
Uptime: 10m21s
dumping to dev #ad/0x20001, offset 786432
dump ata0: resetting devices .. done
128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111
110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90
89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40
39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15
14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
303 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
#1 0xc0151320 in poweroff_wait (junk=0xc0291e80, howto=-903562160)
at ../../kern/kern_shutdown.c:553
#2 0xc0260341 in isa_nmi (cd=0) at ../../i386/isa/intr_machdep.c:254
#3 0xc025a652 in trap (frame={tf_fs = -1058078704, tf_es = 16,
tf_ds = -903610352, tf_edi = -1058025472, tf_esi = 49151,
tf_ebp = -903562084, tf_isp = -903562108, tf_ebx = 4, tf_edx = 4260,
tf_ecx = 49151, tf_eax = 49151, tf_trapno = 19, tf_err = 0,
tf_eip = -1072503013, tf_cs = 8, tf_eflags = 582, tf_esp = 16,
tf_ss = -903562048}) at ../../i386/i386/trap.c:583
#4 0xc012e71b in emu_wr (sc=0xc0efd000, regno=4, data=49151, size=4)
at machine/cpufunc.h:331
#5 0xc012e807 in emu_wrptr (sc=0xc0efd000, chn=0, reg=16, data=49151)
at ../../dev/sound/pci/emu10k1.c:258
#6 0xc012ef82 in emu_vwrite (sc=0xc0efd000, v=0xc0efd088)
at ../../dev/sound/pci/emu10k1.c:585
#7 0xc012f21b in emupchan_trigger (data=0xc0efda88, go=1)
at ../../dev/sound/pci/emu10k1.c:719
#8 0xc0135a58 in chn_trigger (c=0xc0ef9800, go=1)
at ../../dev/sound/pcm/channel.c:1251
#9 0xc0134a06 in chn_wrintr (c=0xc0ef9800)
at ../../dev/sound/pcm/channel.c:385
#10 0xc013503f in chn_intr (c=0xc0ef9800) at
../../dev/sound/pcm/channel.c:785
#11 0xc01350b7 in chn_start (c=0xc0ef9800) at
../../dev/sound/pcm/channel.c:811
#12 0xc0134b33 in chn_write (c=0xc0ef9800, buf=0xca24bedc)
at ../../dev/sound/pcm/channel.c:476
#13 0xc0135e70 in dsp_write (d=0xc0ef7c00, chan=0, buf=0xca24bedc,
flag=131089)
at ../../dev/sound/pcm/dsp.c:194
#14 0xc0137e21 in sndwrite (i_dev=0xc0efa800, buf=0xca24bedc, flag=131089)
at ../../dev/sound/pcm/sound.c:359
#15 0xc018bffd in spec_write (ap=0xca24be70)
at ../../miscfs/specfs/spec_vnops.c:291
#16 0xc0221c38 in ufsspec_write (ap=0xca24be70)
at ../../ufs/ufs/ufs_vnops.c:1857
#17 0xc02220ed in ufs_vnoperatespec (ap=0xca24be70)
at ../../ufs/ufs/ufs_vnops.c:2305
#18 0xc01874e4 in vn_write (fp=0xc105ae00, uio=0xca24bedc,
cred=0xc102f200,
flags=0, p=0xca212100) at vnode_if.h:363
#19 0xc0161ca6 in dofilewrite (p=0xca212100, fp=0xc105ae00, fd=4,
buf=0x8056000, nbyte=4096, offset=-1, flags=0) at ../../sys/file.h:157
#20 0xc0161b9b in write (p=0xca212100, uap=0xca24bf80)
at ../../kern/sys_generic.c:308
#21 0xc025af01 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134569984, tf_esi = 55, tf_ebp = -1077937444,
tf_isp = -903561260, tf_ebx = 671725864, tf_edx = 671686271,
tf_ecx = 7807, tf_eax = 4, tf_trapno = 22, tf_err = 2,
tf_eip = 672214240, tf_cs = 31, tf_eflags = 663, tf_esp =
-1077937488,
tf_ss = 47}) at ../../i386/i386/trap.c:1126
#22 0xc0250205 in Xint0x80_syscall ()
#23 0x804a0d9 in ?? ()
#24 0x804901d in ?? ()
Re: SB Live (or RAM parity?) crash on today's -CURRENT
On Thu, 6 Jul 2000, Thomas Stromberg wrote: 'panic: RAM parity error, likely hardware failure.' This one had me confused at first, because it blamed a RAM parity error. As this is a brand new machine (Gateway GP-800), so I first thought I got a bad batch. Then I realized this only happens with apps that try to do sound stuff. This is a known problem with all PCI sound cards. It happens most often with ECC ram, but it also happens without. What kind of NIC do you have, and specifically, is it a PCI card or ISA? We're trying to track that bit down too. Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SB Live (or RAM parity?) crash on today's -CURRENT
Its in the dmesg from my post, but: CPU: Pentium III/Pentium III Xeon/Celeron (796.54-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM real memory = 134217728 (131072K bytes) avail memory = 127098880 (124120K bytes) .. pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 pci0: Intel 82443BX (440 BX) host to PCI bridge at 0.0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: NVidia Riva Ultra Vanta TNT2 graphics accelerator at 0.0 irq 11 .. pci0: Intel 82371AB/EB (PIIX4) USB controller at 7.2 irq 9 pci0: Intel 82371AB Power management controller at 7.3 pcm0: Creative EMU10K1 port 0x10a0-0x10bf irq 11 at device 14.0 on pci0 xl0: 3Com 3c905C-TX Fast Etherlink XL port 0x1000-0x107f mem 0xf400-0xf47f irq 10 at device 15.0 on pci0 Good luck.. happy to test patches. thomas r. stromberg [EMAIL PROTECTED] senior systems administratorhttp://www.afterthought.org/ research triangle commerce, inc. 1.919.657.1317 bless(\$Perl++);# the power to hack. http://www.perl.com/ #include freebsd.h /* the power to serve. http://www.freebsd.org/ */ On Thu, 6 Jul 2000, Doug Barton wrote: On Thu, 6 Jul 2000, Thomas Stromberg wrote: 'panic: RAM parity error, likely hardware failure.' This one had me confused at first, because it blamed a RAM parity error. As this is a brand new machine (Gateway GP-800), so I first thought I got a bad batch. Then I realized this only happens with apps that try to do sound stuff. This is a known problem with all PCI sound cards. It happens most often with ECC ram, but it also happens without. What kind of NIC do you have, and specifically, is it a PCI card or ISA? We're trying to track that bit down too. Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
