Re: 3.2-STABLE not stable but panicy?

1999-07-13 Thread Wilko Bulte
As Mike Smith wrote ...

> This is typically symptomatic of poor CPU cooling; all of a sudden you 

Well, it wasn't the cooler, that was just fine. The CPU was quite cool
(it has a big, good heatsink & fan)

> are running the CPU at full power 100% of the time, rather than sitting 
> in an HLT instruction.  It can be further exacerbated if you're 
> overclocking.

But you are right all the same: after spending some time eyeballing the
mainboard I remembered I was running at 75Mc bus speed. Have been doing
so for > 1 year now. Another temperature probe, but this time of the
VRM regulators sort of toasted one of my fingers. So my current theory
is that the VRM regulator sort of lost it and the CPU did not like that
too much. I thought of grabbing the old oscilloscope and measure the
powerrails but took the easy route to 66Mc bus speed. Seems to run
fine now.

(this really is Murphy: it is close to 30 degr C here which "never"
happens in Holland && this RC5DES thingy && 75 Mc setting. Burp).

Thanks,
Wilko

> > Is it just me/my machine or has 3.2-STABLE become rather unstable and
> > panic stricken (sp)?
> > 
> > Whether it has any correlation I don't know, but it seems to have started
> > when I got in the the RC5DES project a couple of days ago.
> > 
> > Yesterday I got a panic like:
> > 
> > (no debugging symbols found)...
> > IdlePTD 3174400
> > initial pcb at 28e864
> > panicstr: lockmgr: unknown locktype request 0
> > panic messages:
> > ---
> > panic: lockmgr: unknown locktype request 0

-- 
|   / o / /  _   Arnhem, The Netherlands- Powered by FreeBSD -
|/|/ / / /( (_) BulteWWW  : http://www.tcja.nl  http://www.freebsd.org


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message



Re: 3.2-STABLE not stable but panicy?

1999-07-13 Thread Wilko Bulte

As Mike Smith wrote ...

> This is typically symptomatic of poor CPU cooling; all of a sudden you 

Well, it wasn't the cooler, that was just fine. The CPU was quite cool
(it has a big, good heatsink & fan)

> are running the CPU at full power 100% of the time, rather than sitting 
> in an HLT instruction.  It can be further exacerbated if you're 
> overclocking.

But you are right all the same: after spending some time eyeballing the
mainboard I remembered I was running at 75Mc bus speed. Have been doing
so for > 1 year now. Another temperature probe, but this time of the
VRM regulators sort of toasted one of my fingers. So my current theory
is that the VRM regulator sort of lost it and the CPU did not like that
too much. I thought of grabbing the old oscilloscope and measure the
powerrails but took the easy route to 66Mc bus speed. Seems to run
fine now.

(this really is Murphy: it is close to 30 degr C here which "never"
happens in Holland && this RC5DES thingy && 75 Mc setting. Burp).

Thanks,
Wilko

> > Is it just me/my machine or has 3.2-STABLE become rather unstable and
> > panic stricken (sp)?
> > 
> > Whether it has any correlation I don't know, but it seems to have started
> > when I got in the the RC5DES project a couple of days ago.
> > 
> > Yesterday I got a panic like:
> > 
> > (no debugging symbols found)...
> > IdlePTD 3174400
> > initial pcb at 28e864
> > panicstr: lockmgr: unknown locktype request 0
> > panic messages:
> > ---
> > panic: lockmgr: unknown locktype request 0

-- 
|   / o / /  _   Arnhem, The Netherlands- Powered by FreeBSD -
|/|/ / / /( (_) BulteWWW  : http://www.tcja.nl  http://www.freebsd.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: 3.2-STABLE not stable but panicy?

1999-07-12 Thread Mike Smith

This is typically symptomatic of poor CPU cooling; all of a sudden you 
are running the CPU at full power 100% of the time, rather than sitting 
in an HLT instruction.  It can be further exacerbated if you're 
overclocking.

> Is it just me/my machine or has 3.2-STABLE become rather unstable and
> panic stricken (sp)?
> 
> Whether it has any correlation I don't know, but it seems to have started
> when I got in the the RC5DES project a couple of days ago.
> 
> Yesterday I got a panic like:
> 
> (no debugging symbols found)...
> IdlePTD 3174400
> initial pcb at 28e864
> panicstr: lockmgr: unknown locktype request 0
> panic messages:
> ---
> panic: lockmgr: unknown locktype request 0
> 
> syncing disks... 160 159 139 113 80 32 done
> 
> dumping to dev 30401, offset 327680
> dump 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  0xc01594ff in boot ()
> (kgdb) bt
> #0  0xc01594ff in boot ()
> #1  0xc0159784 in at_shutdown ()
> #2  0xc01555c4 in lockmgr ()
> #3  0xc017ba88 in vop_stdlock ()
> #4  0xc01f7e19 in ufs_vnoperate ()
> #5  0xc0184863 in vn_lock ()
> #6  0xc017e40b in vget ()
> #7  0xc017a55b in vfs_cache_lookup ()
> #8  0xc01f7e19 in ufs_vnoperate ()
> #9  0xc017cb45 in lookup ()
> #10 0xc017c618 in namei ()
> #11 0xc0180969 in change_dir ()
> #12 0xc01808c7 in chdir ()
> #13 0xc021cf63 in syscall ()
> #14 0xc0213cec in Xint0x80_syscall ()
> #15 0x804919f in ?? ()
> #16 0x804af96 in ?? ()
> #17 0x804904d in ?? ()
> (kgdb) 
> 
> 
> I decided to cvsup the latest -STABLE sources and with a kernel based on
> yesterdays -STABLE I just got (again during a RC5DES run, approx
> 15 minutes after starting it):
> 
> (no debugging symbols found)...
> IdlePTD 3239936
> initial pcb at 29e914
> panicstr: page fault
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x3ff02585
> fault code  = supervisor write, page not present
> instruction pointer = 0x8:0xc02078b4
> stack pointer   = 0x10:0xc6a158b4
> frame pointer   = 0x10:0xc6a158c0
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 973 (cron)
> interrupt mask  = net tty bio cam 
> trap number = 12
> panic: page fault
> 
> syncing disks... done
> 
> dumping to dev 30401, offset 327680
> dump 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 1
> 8 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 
> ---
> #0  0xc0159e07 in boot ()
> (kgdb) bt
> #0  0xc0159e07 in boot ()
> #1  0xc015a08c in at_shutdown ()
> #2  0xc021e089 in trap_fatal ()
> #3  0xc021dd67 in trap_pfault ()
> #4  0xc021da0a in trap ()
> #5  0xc02078b4 in zalloci ()
> #6  0xc021ac12 in get_pv_entry ()
> #7  0xc021ada7 in pmap_insert_entry ()
> #8  0xc021b589 in pmap_enter_quick ()
> #9  0xc021b7aa in pmap_object_init_pt ()
> #10 0xc0149c77 in elf_load_section ()
> #11 0xc014a2ae in exec_elf_imgact ()
> #12 0xc01534ff in execve ()
> #13 0xc021e2cb in syscall ()
> #14 0xc0214ecc in Xint0x80_syscall ()
> Cannot access memory at address 0xbfbfd7d8.
> (kgdb) 
> 
> Before someone asks: yes, I checked the CPU fan..
> 
> dmesg:
> 
> 
> Copyright (c) 1992-1999 FreeBSD Inc.
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>   The Regents of the University of California. All rights reserved.
> FreeBSD 3.2-STABLE #0: Sat Jul 10 10:49:28 CEST 1999
> wi...@yedi.iaf.nl:/usr/freebsd-3.1-stable-src/src/sys/compile/YEDI
> Timecounter "i8254"  frequency 1193182 Hz
> Timecounter "TSC"  frequency 261958495 Hz
> CPU: AMD-K6tm w/ multimedia extensions (261.96-MHz 586-class CPU)
>   Origin = "AuthenticAMD"  Id = 0x562  Stepping = 2
>   Features=0x8001bf
>   AMD Features=0x400<>
> real memory  = 100663296 (98304K bytes)
> avail memory = 94621696 (92404K bytes)
> Preloaded elf kernel "kernel" at 0xc0305000.
> Probing for devices on PCI bus 0:
> chip0:  rev 0x03 on pci0.0.0
> chip1:  rev 0x01 on pci0.7.0
> xl0: <3Com 3c905-TX Fast Etherlink XL> rev 0x00 int a irq 14 on pci0.9.0
> xl0: Ethernet address: 00:60:08:09:b8:f1
> xl0: autoneg not complete, no carrier (forcing half-duplex, 10Mbps)
> vga0:  rev 0x00 int a irq 14 on 
> pci0.10.0
> Qlogic ISP Driver, FreeBSD CAM Version 0.992, Core Version 1.9
> isp0:  rev 0x05 int a irq 9 on 
> pci0.11.0
> isp0: set PCI line size to 16
> isp0: set PCI latency to 64
> isp0: Ultra Mode Capable
> isp0: Board Revision 1040B, loaded F/W Revision 7.63.0
> isp0: Last F/W revision was 4.53.0
> ncr0:  rev

Re: 3.2-STABLE not stable but panicy?

1999-07-12 Thread Mike Smith


This is typically symptomatic of poor CPU cooling; all of a sudden you 
are running the CPU at full power 100% of the time, rather than sitting 
in an HLT instruction.  It can be further exacerbated if you're 
overclocking.

> Is it just me/my machine or has 3.2-STABLE become rather unstable and
> panic stricken (sp)?
> 
> Whether it has any correlation I don't know, but it seems to have started
> when I got in the the RC5DES project a couple of days ago.
> 
> Yesterday I got a panic like:
> 
> (no debugging symbols found)...
> IdlePTD 3174400
> initial pcb at 28e864
> panicstr: lockmgr: unknown locktype request 0
> panic messages:
> ---
> panic: lockmgr: unknown locktype request 0
> 
> syncing disks... 160 159 139 113 80 32 done
> 
> dumping to dev 30401, offset 327680
> dump 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  0xc01594ff in boot ()
> (kgdb) bt
> #0  0xc01594ff in boot ()
> #1  0xc0159784 in at_shutdown ()
> #2  0xc01555c4 in lockmgr ()
> #3  0xc017ba88 in vop_stdlock ()
> #4  0xc01f7e19 in ufs_vnoperate ()
> #5  0xc0184863 in vn_lock ()
> #6  0xc017e40b in vget ()
> #7  0xc017a55b in vfs_cache_lookup ()
> #8  0xc01f7e19 in ufs_vnoperate ()
> #9  0xc017cb45 in lookup ()
> #10 0xc017c618 in namei ()
> #11 0xc0180969 in change_dir ()
> #12 0xc01808c7 in chdir ()
> #13 0xc021cf63 in syscall ()
> #14 0xc0213cec in Xint0x80_syscall ()
> #15 0x804919f in ?? ()
> #16 0x804af96 in ?? ()
> #17 0x804904d in ?? ()
> (kgdb) 
> 
> 
> I decided to cvsup the latest -STABLE sources and with a kernel based on
> yesterdays -STABLE I just got (again during a RC5DES run, approx
> 15 minutes after starting it):
> 
> (no debugging symbols found)...
> IdlePTD 3239936
> initial pcb at 29e914
> panicstr: page fault
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x3ff02585
> fault code  = supervisor write, page not present
> instruction pointer = 0x8:0xc02078b4
> stack pointer   = 0x10:0xc6a158b4
> frame pointer   = 0x10:0xc6a158c0
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 973 (cron)
> interrupt mask  = net tty bio cam 
> trap number = 12
> panic: page fault
> 
> syncing disks... done
> 
> dumping to dev 30401, offset 327680
> dump 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 1
> 8 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 
> ---
> #0  0xc0159e07 in boot ()
> (kgdb) bt
> #0  0xc0159e07 in boot ()
> #1  0xc015a08c in at_shutdown ()
> #2  0xc021e089 in trap_fatal ()
> #3  0xc021dd67 in trap_pfault ()
> #4  0xc021da0a in trap ()
> #5  0xc02078b4 in zalloci ()
> #6  0xc021ac12 in get_pv_entry ()
> #7  0xc021ada7 in pmap_insert_entry ()
> #8  0xc021b589 in pmap_enter_quick ()
> #9  0xc021b7aa in pmap_object_init_pt ()
> #10 0xc0149c77 in elf_load_section ()
> #11 0xc014a2ae in exec_elf_imgact ()
> #12 0xc01534ff in execve ()
> #13 0xc021e2cb in syscall ()
> #14 0xc0214ecc in Xint0x80_syscall ()
> Cannot access memory at address 0xbfbfd7d8.
> (kgdb) 
> 
> Before someone asks: yes, I checked the CPU fan..
> 
> dmesg:
> 
> 
> Copyright (c) 1992-1999 FreeBSD Inc.
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>   The Regents of the University of California. All rights reserved.
> FreeBSD 3.2-STABLE #0: Sat Jul 10 10:49:28 CEST 1999
> [EMAIL PROTECTED]:/usr/freebsd-3.1-stable-src/src/sys/compile/YEDI
> Timecounter "i8254"  frequency 1193182 Hz
> Timecounter "TSC"  frequency 261958495 Hz
> CPU: AMD-K6tm w/ multimedia extensions (261.96-MHz 586-class CPU)
>   Origin = "AuthenticAMD"  Id = 0x562  Stepping = 2
>   Features=0x8001bf
>   AMD Features=0x400<>
> real memory  = 100663296 (98304K bytes)
> avail memory = 94621696 (92404K bytes)
> Preloaded elf kernel "kernel" at 0xc0305000.
> Probing for devices on PCI bus 0:
> chip0:  rev 0x03 on pci0.0.0
> chip1:  rev 0x01 on pci0.7.0
> xl0: <3Com 3c905-TX Fast Etherlink XL> rev 0x00 int a irq 14 on pci0.9.0
> xl0: Ethernet address: 00:60:08:09:b8:f1
> xl0: autoneg not complete, no carrier (forcing half-duplex, 10Mbps)
> vga0:  rev 0x00 int a irq 14 on pci0.10.0
> Qlogic ISP Driver, FreeBSD CAM Version 0.992, Core Version 1.9
> isp0:  rev 0x05 int a irq 9 on pci0.11.0
> isp0: set PCI line size to 16
> isp0: set PCI latency to 64
> isp0: Ultra Mode Capable
> isp0: Board Revision 1040B, loaded F/W Revision 7.63.0
> isp0: Last F/W revision was 4.53.0
> ncr0:  rev 0x02