Re: kernel trap 12 with interrupts disabled

[Chris H]

On Sun, 5 Mar 2017 04:10:26 -0800 David Wolfskill  wrote

> On Sat, Mar 04, 2017 at 10:08:45PM -0800, Chris H wrote:
> > Thanks for the reply.
> > I rebooted to kernel.old, so I could get the exact
> > src revision I built this on. It's r314640
> > 
> > Any news as to whether it's safe to update src, and
> > build a usable kernel?
> > 
> 
> I (try to -- and usually succeed in doing so) build & smoke test
> stable/11 and head daily, on both a dedicated "build machine and the
> laptop I use for day-to-day use.
> 
> Details are posted at
> , including links to
> pages with logs of the (daily) output of "uname -vp", so folks can see
> what worked for me (along with a fair bit of other stuff that may be
> useful for reality checks).
> 
> The last few lines of "uname" output for my laptop for head are:
> 
> ...
> FreeBSD 12.0-CURRENT #272  r314549M/314552:1200022: Thu Mar  2 05:52:54 PST
> 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
> FreeBSD 12.0-CURRENT #273  r314592M/314592:1200023: Fri Mar  3 07:12:34 PST
> 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
> FreeBSD 12.0-CURRENT #274  r314653M/314653:1200023: Sat Mar  4 06:46:18 PST
> 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
> 
> (but I just started another cycle, so I expect to be augmenting the list
> fairly soon).
> 
> I didn't happen to build at r314640; I did so at r314592 and r314653 --
> successfully -- though. 
Thank you *very* much, David, for sharing this. It's an
*invaluable* resource.

GREATLY appreciated!

Now. If I could only figure out when (u)efi will be supported again.
But that's another topic, in another thread. :-)

Thanks again, David.

--Chris
>
> Peace,
> david


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel trap 12 with interrupts disabled

[David Wolfskill]

On Sat, Mar 04, 2017 at 10:08:45PM -0800, Chris H wrote:
> Thanks for the reply.
> I rebooted to kernel.old, so I could get the exact
> src revision I built this on. It's r314640
> 
> Any news as to whether it's safe to update src, and
> build a usable kernel?
> 

I (try to -- and usually succeed in doing so) build & smoke test
stable/11 and head daily, on both a dedicated "build machine and the
laptop I use for day-to-day use.

Details are posted at
, including links to
pages with logs of the (daily) output of "uname -vp", so folks can see
what worked for me (along with a fair bit of other stuff that may be
useful for reality checks).

The last few lines of "uname" output for my laptop for head are:

...
FreeBSD 12.0-CURRENT #272  r314549M/314552:1200022: Thu Mar  2 05:52:54 PST 
2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
FreeBSD 12.0-CURRENT #273  r314592M/314592:1200023: Fri Mar  3 07:12:34 PST 
2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
FreeBSD 12.0-CURRENT #274  r314653M/314653:1200023: Sat Mar  4 06:46:18 PST 
2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

(but I just started another cycle, so I expect to be augmenting the list
fairly soon).

I didn't happen to build at r314640; I did so at r314592 and r314653 -- 
successfully -- though.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: kernel trap 12 with interrupts disabled

[Alastair Hogge]

On Sun, 5 Mar 2017 09:50:49 AM Andriy Gapon wrote:
> On 05/03/2017 08:08, Chris H wrote:
> > Thanks for the reply.
> > I rebooted to kernel.old, so I could get the exact
> > src revision I built this on. It's r314640
> > 
> > Any news as to whether it's safe to update src, and
> > build a usable kernel?
> 
> Sorry about the breakage.
> The fix is in r314700.

Thanks :-)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel trap 12 with interrupts disabled

[Chris H]

On Sun, 5 Mar 2017 09:50:49 +0200 Andriy Gapon <a...@freebsd.org> wrote

> On 05/03/2017 08:08, Chris H wrote:
> > Thanks for the reply.
> > I rebooted to kernel.old, so I could get the exact
> > src revision I built this on. It's r314640
> > 
> > Any news as to whether it's safe to update src, and
> > build a usable kernel?
> 
> Sorry about the breakage.
> The fix is in r314700.

Thank YOU, for the fast response! :-)

--Chris

> 
> > 
> > On Sun, 05 Mar 2017 12:01:29 +0800 Alastair Hogge <a...@fastmail.fm> wrote
> > 
> >> Hi *,
> >>
> >> On Sat, 4 Mar 2017 07:38:55 PM Chris H wrote:
> >>
> >> [remove 12-CURRENT history & hardware summary]
> >>
> >>> I finished the
> >>> buildworld, and finished the build/install kernel, and
> >>> (attempted) to boot to single user. But got a trap
> >>> shortly into booting the new kernel;
> >>>
> >>> kernel trap 12 with interrupts disabled
> >>>
> >>> Fatal trap 12: page fault in kernel mode
> >>
> >> I am also experiencing a similar problem.  I believe the error is caused
> >> by  r314636[0]; committer CC'd.
> >>
> >> Verbose boot (r314640):
> >>
> >> /boot/kernel/kernel text=0x8e13d0 data=0xac880+0x3cd6e8 
> >> syms=[0x8+0xd6350+0x8+0xd2864]
> >>   
> >>   
> >>   
   >>  
>>   
> >>   
> >>   
   >>  
>>   
> >>   
> >>   
   >>  
>>   
> >>   
> >>   
   >>  
>>   
> >>   
   >>   
[77/1834] >> /boot/entropy size=0x1000 >> Booting... >> [dcons disconnected
> >>   
> >>   
   >>  
>>   
> >>   
> >>   
   >>  
>>   
> >>   
   >>   
(wrong magic 0x)] >> [dcons connected] >> GDB: debug ports: dcons
> >> GDB: current port: dcons
> >> KDB: debugger backends: ddb gdb
> >> KDB: current backend: ddb
> >> Table 'FACP' at 0xbfdd1080
> >> Table 'MSDM' at 0xbfdd8800
> >> Table 'HPET' at 0xbfdd8880
> >> Table 'MCFG' at 0xbfdd88c0
> >> Table 'EUDS' at 0xbfdd8940
> >> Table 'MATS' at 0xbfdd91a0
> >> Table 'TAMG' at 0xbfdd9210
> >> Table 'APIC' at 0xbfdd8740
> >> APIC: Found table at 0xbfdd8740
> >> APIC: Using the MADT enumerator.
> >> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
> >> SMP: Added CPU 0 (AP)
> >> MADT: Found CPU APIC ID 1 ACPI ID 1: enabled
> >> SMP: Added CPU 1 (AP)
> >> MADT: Foun

Re: kernel trap 12 with interrupts disabled

[Andriy Gapon]

On 05/03/2017 08:08, Chris H wrote:
> Thanks for the reply.
> I rebooted to kernel.old, so I could get the exact
> src revision I built this on. It's r314640
> 
> Any news as to whether it's safe to update src, and
> build a usable kernel?

Sorry about the breakage.
The fix is in r314700.

> 
> On Sun, 05 Mar 2017 12:01:29 +0800 Alastair Hogge <a...@fastmail.fm> wrote
> 
>> Hi *,
>>
>> On Sat, 4 Mar 2017 07:38:55 PM Chris H wrote:
>>
>> [remove 12-CURRENT history & hardware summary]
>>
>>> I finished the
>>> buildworld, and finished the build/install kernel, and
>>> (attempted) to boot to single user. But got a trap
>>> shortly into booting the new kernel;
>>>
>>> kernel trap 12 with interrupts disabled
>>>
>>> Fatal trap 12: page fault in kernel mode
>>
>> I am also experiencing a similar problem.  I believe the error is caused by 
>> r314636[0]; committer CC'd.
>>
>> Verbose boot (r314640):
>>
>> /boot/kernel/kernel text=0x8e13d0 data=0xac880+0x3cd6e8 
>> syms=[0x8+0xd6350+0x8+0xd2864]   
>>  
>>[77/1834]
>> /boot/entropy size=0x1000
>> Booting...
>> [dcons disconnected (wrong magic 0x)]
>> [dcons connected]
>> GDB: debug ports: dcons
>> GDB: current port: dcons
>> KDB: debugger backends: ddb gdb
>> KDB: current backend: ddb
>> Table 'FACP' at 0xbfdd1080
>> Table 'MSDM' at 0xbfdd8800
>> Table 'HPET' at 0xbfdd8880
>> Table 'MCFG' at 0xbfdd88c0
>> Table 'EUDS' at 0xbfdd8940
>> Table 'MATS' at 0xbfdd91a0
>> Table 'TAMG' at 0xbfdd9210
>> Table 'APIC' at 0xbfdd8740
>> APIC: Found table at 0xbfdd8740
>> APIC: Using the MADT enumerator.
>> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
>> SMP: Added CPU 0 (AP)
>> MADT: Found CPU APIC ID 1 ACPI ID 1: enabled
>> SMP: Added CPU 1 (AP)
>> MADT: Found CPU APIC ID 2 ACPI ID 2: enabled
>> SMP: Added CPU 2 (AP)
>> MADT: Found CPU APIC ID 3 ACPI ID 3: enabled
>> SMP: Added CPU 3 (AP)
>> MADT: Found CPU APIC ID 4 ACPI ID 4: enabled
>> SMP: Added CPU 4 (AP)
>> MADT: Found CPU APIC ID 5 ACPI ID 5: enabled
>> SMP: Added CPU 5 (AP)
>> MADT: Found CPU APIC ID 6 ACPI ID 6: enabled
>> SMP: Added CPU 6 (AP)
>> MADT: Found CPU APIC ID 7 ACPI ID 7: enabled
>> SMP: Added CPU 7 (AP)
>> Copyright (c) 1992-2017 The FreeBSD Project.
>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>> The Regents of the University of California. All rights reserved.
>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>> FreeBSD 12.0-CURRENT #0 r314640: Sat Mar  4 13:10:08 AWST 2017
>> root@direwolf:/tmp/direwolf/usr/src/sys/DIREWOLF amd64
>> FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
>> 4.0.0) WARNING: WITNESS option enabled, expect reduced performance.
>> Table 'FACP' at 0xbfdd1080
>> Table 'MSDM' at 0xbfdd8800
>> Table 'HPET' at 0xbfdd8880
>> Table 'MCFG' at 0xbfdd88c0
>> Table 'EUDS' at 0xbfdd8940
>> Table 'MATS' at 0xbfdd91a0
>> Table 'TAMG' at 0xbfdd9210
>> Table 'APIC' at 0xbfdd8740
>> Table 'MATS' at 0xbfdd93c0
>> Table 'SSDT' at 0xbfddfaf0
>> Table 'IVRS' at 0xbfde1280
>> ACPI: No SRAT table found
>> PPIM 0: PA=0xa, VA=0x8141, size=0x1, mode=0
>> VT(vga): resolution 640x480
>> Preloaded elf kernel "/boot/kernel/kernel" at 0x81306000.
>> Preloaded /boot/entropy "/boot/entropy" at 0x81306ae8.
>> Calibrating TSC clock ... TSC clock: 4018024582 Hz
>> CPU: AMD FX(tm)-8350 Eight-Core Processor(4018.02-MHz K8-class 
>> CPU)
>>   Origin="AuthenticAMD"  Id=0x600f20  Family=0x15  Model=0x2  Stepping=0
>>  
>> Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,
>> CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>  
>> Features2=0x3e98320b<SSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,POPCNT,A
>> ESNI,XSAVE,OSXSAVE,AVX,F16C>   AMD
>> Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM>   AMD 
>> Features2=0x1ebbfff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,
>> XOP,SKINIT,WDT,LWP,FMA4,TCE,NodeId,TBM,Topology,PCXC,PNXC>   Structured
>> Extended Features=0x8   SVM: 
>> Features=0x1cff<NP,LbrVirt,SVML,NRIPS,TscRateMsr,VmcbClean,FlushByAsid,Decode
>> Assist,PauseFilt

Re: kernel trap 12 with interrupts disabled

[Alastair Hogge]

On Sat, 4 Mar 2017 10:34:39 PM Chris H wrote:
> On Sun, 05 Mar 2017 14:26:31 +0800 Alastair Hogge  wrote
> 
> > On Sat, 4 Mar 2017 10:08:45 PM Chris H wrote:
> > > Thanks for the reply.
> > > I rebooted to kernel.old, so I could get the exact
> > > src revision I built this on. It's r314640
> > > 
> > > Any news as to whether it's safe to update src, and
> > > build a usable kernel?
> > 
> > I am not able to boot a kernel > r314627.  I currently have a r314627
> > kernel running with a r314687 world.
> 
> Looking at the output in my trap; I got the impression that
> the commit: r314636, might be to blame --

[removed commit log]

Thanks for the correct.

> I'm thinking to back that commit out, and giving world/kernel
> another shot.

I changed ${src}/sys/x86/x86/mca.c to return immediately:

--- sys/x86/x86/mca.c   (revision 314698)
+++ sys/x86/x86/mca.c   (working copy)
@@ -1016,6 +1016,7 @@
 static void
 _mca_init(int boot)
 {
+return;
uint64_t mcg_cap;
uint64_t ctl, mask;
int i, skip;

I have a working & sync'd kernel + world.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel trap 12 with interrupts disabled

[Chris H]

On Sun, 05 Mar 2017 14:26:31 +0800 Alastair Hogge  wrote

> On Sat, 4 Mar 2017 10:08:45 PM Chris H wrote:
> > Thanks for the reply.
> > I rebooted to kernel.old, so I could get the exact
> > src revision I built this on. It's r314640
> > 
> > Any news as to whether it's safe to update src, and
> > build a usable kernel?
> 
> I am not able to boot a kernel > r314627.  I currently have a r314627 kernel 
> running with a r314687 world.

Looking at the output in my trap; I got the impression that
the commit: r314636, might be to blame --

MCA: add AMD Error Thresholding support

Currently the feature is implemented only for a subset of errors
reported via Bank 4.  The subset includes only DRAM-related errors.

The new code builds upon and reuses the Intel CMC (Correctable MCE
Counters) support code.  However, the AMD feature is quite different
and, unfortunately, much less regular.

Just a guess, tho.

I'm thinking to back that commit out, and giving world/kernel
another shot.

--Chris

> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel trap 12 with interrupts disabled

[Alastair Hogge]

On Sat, 4 Mar 2017 10:08:45 PM Chris H wrote:
> Thanks for the reply.
> I rebooted to kernel.old, so I could get the exact
> src revision I built this on. It's r314640
> 
> Any news as to whether it's safe to update src, and
> build a usable kernel?

I am not able to boot a kernel > r314627.  I currently have a r314627 kernel 
running with a r314687 world.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel trap 12 with interrupts disabled

[Chris H]

Thanks for the reply.
I rebooted to kernel.old, so I could get the exact
src revision I built this on. It's r314640

Any news as to whether it's safe to update src, and
build a usable kernel?

Thanks.

--Chris

On Sun, 05 Mar 2017 12:01:29 +0800 Alastair Hogge <a...@fastmail.fm> wrote

> Hi *,
> 
> On Sat, 4 Mar 2017 07:38:55 PM Chris H wrote:
> 
> [remove 12-CURRENT history & hardware summary]
> 
> > I finished the
> > buildworld, and finished the build/install kernel, and
> > (attempted) to boot to single user. But got a trap
> > shortly into booting the new kernel;
> > 
> > kernel trap 12 with interrupts disabled
> > 
> > Fatal trap 12: page fault in kernel mode
> 
> I am also experiencing a similar problem.  I believe the error is caused by 
> r314636[0]; committer CC'd.
> 
> Verbose boot (r314640):
> 
> /boot/kernel/kernel text=0x8e13d0 data=0xac880+0x3cd6e8 
> syms=[0x8+0xd6350+0x8+0xd2864]   
>  
>[77/1834]
> /boot/entropy size=0x1000
> Booting...
> [dcons disconnected (wrong magic 0x)]
> [dcons connected]
> GDB: debug ports: dcons
> GDB: current port: dcons
> KDB: debugger backends: ddb gdb
> KDB: current backend: ddb
> Table 'FACP' at 0xbfdd1080
> Table 'MSDM' at 0xbfdd8800
> Table 'HPET' at 0xbfdd8880
> Table 'MCFG' at 0xbfdd88c0
> Table 'EUDS' at 0xbfdd8940
> Table 'MATS' at 0xbfdd91a0
> Table 'TAMG' at 0xbfdd9210
> Table 'APIC' at 0xbfdd8740
> APIC: Found table at 0xbfdd8740
> APIC: Using the MADT enumerator.
> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
> SMP: Added CPU 0 (AP)
> MADT: Found CPU APIC ID 1 ACPI ID 1: enabled
> SMP: Added CPU 1 (AP)
> MADT: Found CPU APIC ID 2 ACPI ID 2: enabled
> SMP: Added CPU 2 (AP)
> MADT: Found CPU APIC ID 3 ACPI ID 3: enabled
> SMP: Added CPU 3 (AP)
> MADT: Found CPU APIC ID 4 ACPI ID 4: enabled
> SMP: Added CPU 4 (AP)
> MADT: Found CPU APIC ID 5 ACPI ID 5: enabled
> SMP: Added CPU 5 (AP)
> MADT: Found CPU APIC ID 6 ACPI ID 6: enabled
> SMP: Added CPU 6 (AP)
> MADT: Found CPU APIC ID 7 ACPI ID 7: enabled
> SMP: Added CPU 7 (AP)
> Copyright (c) 1992-2017 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 12.0-CURRENT #0 r314640: Sat Mar  4 13:10:08 AWST 2017
> root@direwolf:/tmp/direwolf/usr/src/sys/DIREWOLF amd64
> FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
> 4.0.0) WARNING: WITNESS option enabled, expect reduced performance.
> Table 'FACP' at 0xbfdd1080
> Table 'MSDM' at 0xbfdd8800
> Table 'HPET' at 0xbfdd8880
> Table 'MCFG' at 0xbfdd88c0
> Table 'EUDS' at 0xbfdd8940
> Table 'MATS' at 0xbfdd91a0
> Table 'TAMG' at 0xbfdd9210
> Table 'APIC' at 0xbfdd8740
> Table 'MATS' at 0xbfdd93c0
> Table 'SSDT' at 0xbfddfaf0
> Table 'IVRS' at 0xbfde1280
> ACPI: No SRAT table found
> PPIM 0: PA=0xa, VA=0x8141, size=0x1, mode=0
> VT(vga): resolution 640x480
> Preloaded elf kernel "/boot/kernel/kernel" at 0x81306000.
> Preloaded /boot/entropy "/boot/entropy" at 0x81306ae8.
> Calibrating TSC clock ... TSC clock: 4018024582 Hz
> CPU: AMD FX(tm)-8350 Eight-Core Processor(4018.02-MHz K8-class 
> CPU)
>   Origin="AuthenticAMD"  Id=0x600f20  Family=0x15  Model=0x2  Stepping=0
>  
> Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,
> CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>  
> Features2=0x3e98320b<SSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,POPCNT,A
> ESNI,XSAVE,OSXSAVE,AVX,F16C>   AMD
> Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM>   AMD 
> Features2=0x1ebbfff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,
> XOP,SKINIT,WDT,LWP,FMA4,TCE,NodeId,TBM,Topology,PCXC,PNXC>   Structured
> Extended Features=0x8   SVM: 
> Features=0x1cff<NP,LbrVirt,SVML,NRIPS,TscRateMsr,VmcbClean,FlushByAsid,Decode
> Assist,PauseFilter,,PauseFilterThreshold> Revision=1, ASIDs=65536
>   TSC: P-state invariant, performance statistics
> L1 2MB data TLB: 64 entries, fully associative
> L1 2MB instruction TLB: 24 entries, fully associative
> L1 4KB data TLB: 64 entries, fully associative
> L1 4KB instruction TLB: 48 entries, fully associative
> L1 data cache: 16 kbytes, 64 bytes/line, 1 lines/tag, 4-way associative
> L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way
&

Re: kernel trap 12 with interrupts disabled

[Alastair Hogge]

Hi *,

On Sat, 4 Mar 2017 07:38:55 PM Chris H wrote:

[remove 12-CURRENT history & hardware summary]

> I finished the
> buildworld, and finished the build/install kernel, and
> (attempted) to boot to single user. But got a trap
> shortly into booting the new kernel;
> 
> kernel trap 12 with interrupts disabled
> 
> Fatal trap 12: page fault in kernel mode

I am also experiencing a similar problem.  I believe the error is caused by 
r314636[0]; committer CC'd.

Verbose boot (r314640):

/boot/kernel/kernel text=0x8e13d0 data=0xac880+0x3cd6e8 
syms=[0x8+0xd6350+0x8+0xd2864]  

  
[77/1834]
/boot/entropy size=0x1000
Booting...
[dcons disconnected (wrong magic 0x)]
[dcons connected]
GDB: debug ports: dcons
GDB: current port: dcons
KDB: debugger backends: ddb gdb
KDB: current backend: ddb
Table 'FACP' at 0xbfdd1080
Table 'MSDM' at 0xbfdd8800
Table 'HPET' at 0xbfdd8880
Table 'MCFG' at 0xbfdd88c0
Table 'EUDS' at 0xbfdd8940
Table 'MATS' at 0xbfdd91a0
Table 'TAMG' at 0xbfdd9210
Table 'APIC' at 0xbfdd8740
APIC: Found table at 0xbfdd8740
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 1: enabled
SMP: Added CPU 1 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 2: enabled
SMP: Added CPU 2 (AP)
MADT: Found CPU APIC ID 3 ACPI ID 3: enabled
SMP: Added CPU 3 (AP)
MADT: Found CPU APIC ID 4 ACPI ID 4: enabled
SMP: Added CPU 4 (AP)
MADT: Found CPU APIC ID 5 ACPI ID 5: enabled
SMP: Added CPU 5 (AP)
MADT: Found CPU APIC ID 6 ACPI ID 6: enabled
SMP: Added CPU 6 (AP)
MADT: Found CPU APIC ID 7 ACPI ID 7: enabled
SMP: Added CPU 7 (AP)
Copyright (c) 1992-2017 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #0 r314640: Sat Mar  4 13:10:08 AWST 2017
root@direwolf:/tmp/direwolf/usr/src/sys/DIREWOLF amd64
FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM 4.0.0)
WARNING: WITNESS option enabled, expect reduced performance.
Table 'FACP' at 0xbfdd1080
Table 'MSDM' at 0xbfdd8800
Table 'HPET' at 0xbfdd8880
Table 'MCFG' at 0xbfdd88c0
Table 'EUDS' at 0xbfdd8940
Table 'MATS' at 0xbfdd91a0
Table 'TAMG' at 0xbfdd9210
Table 'APIC' at 0xbfdd8740
Table 'MATS' at 0xbfdd93c0
Table 'SSDT' at 0xbfddfaf0
Table 'IVRS' at 0xbfde1280
ACPI: No SRAT table found
PPIM 0: PA=0xa, VA=0x8141, size=0x1, mode=0
VT(vga): resolution 640x480
Preloaded elf kernel "/boot/kernel/kernel" at 0x81306000.
Preloaded /boot/entropy "/boot/entropy" at 0x81306ae8.
Calibrating TSC clock ... TSC clock: 4018024582 Hz
CPU: AMD FX(tm)-8350 Eight-Core Processor(4018.02-MHz K8-class 
CPU)
  Origin="AuthenticAMD"  Id=0x600f20  Family=0x15  Model=0x2  Stepping=0
  
Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  
Features2=0x3e98320b<SSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C>
  AMD Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM>
  AMD 
Features2=0x1ebbfff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,XOP,SKINIT,WDT,LWP,FMA4,TCE,NodeId,TBM,Topology,PCXC,PNXC>
  Structured Extended Features=0x8
  SVM: 
Features=0x1cff<NP,LbrVirt,SVML,NRIPS,TscRateMsr,VmcbClean,FlushByAsid,DecodeAssist,PauseFilter,,PauseFilterThreshold>
Revision=1, ASIDs=65536
  TSC: P-state invariant, performance statistics
L1 2MB data TLB: 64 entries, fully associative
L1 2MB instruction TLB: 24 entries, fully associative
L1 4KB data TLB: 64 entries, fully associative
L1 4KB instruction TLB: 48 entries, fully associative
L1 data cache: 16 kbytes, 64 bytes/line, 1 lines/tag, 4-way associative
L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
L2 2MB data TLB: 1024 entries, 8-way associative
L2 4KB data TLB: 1024 entries, 8-way associative
L2 4KB instruction TLB: 1024 entries, 8-way associative
L2 unified cache: 2048 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative
real memory  = 34359738368 (32768 MB)
Physical memory chunk(s):
0x0001 - 0x0005, 327680 bytes (80 pages)
0x0007 - 0x00098fff, 167936 bytes (41 pages)
0x0010 - 0x001f, 1048576 bytes (256 pages)
0x0134 - 0xbfd9, 3198550016 bytes (780896 pages)
0x0001 - 0x00080a849fff, 30241234944 bytes (7383114 pages)
avail memory = 33272029184 (31730 MB)
Event timer "LAPIC" quality 100
LAPIC: ipi_wait() us multiplier 29 (r 13818693 tsc 4018024582)
ACPI APIC Table: 
Packag

kernel trap 12 with interrupts disabled

[Chris H]

OK. This is my second world/kernel on 12.
The last, ~3 mos. ago, worked great. But, unfortunately,
the graphics on the APU (AMD/ATI A6 7470K)  aren't
(yet) supported on FreeBSD. So I picked up an nVidia
Geforce GT 730, and performed a fresh install from the
r314495 AMD Disk1 CD. Then checked out a fresh copy
of src && ports, last night (PST) to begin a fresh
buildworld/kernel installworld/kernel. I finished the
buildworld, and finished the build/install kernel, and
(attempted) to boot to single user. But got a trap
shortly into booting the new kernel;

kernel trap 12 with interrupts disabled

Fatal trap 12: page fault in kernel mode

I've placed a screen shot here:
bsdforge.com/12-CURRENT-2017-03-04.jpeg

for better context, and what follows what I've mentioned
above.
I've left it at this point with the db> prompt. In case
I/we can better determine what cause it.

Please advise.

Thanks!

--Chris


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Panic (kernel trap 12 with interrupts disabled) in propagate_priority()

[David Wolfskill]

OK; I managed to build yesterday's -CURRENT (I update my local FreeBSD
CVS repository mirror from 0347 - 0354 hrs. US/Pacific, daily) on my
SMP build machine, and the resulting system appeared fairly normal:
it booted to multi-user mode, and I could login via the serial console.
(I wasn't expecting the issue with non-recognition of the Realtek 8129
NIC to be resolved yet.)

So I ran cvs update against /usr/src, booted to -CURRENT, fired up
screen, then script, and started a make buildworld -- then
detached the screen and headed in to work.

When I reconnected after getting in to work, I saw that the $SUBJECT
panic had occurred (cut/paste from serial console):

kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0xe5
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0545d69
stack pointer   = 0x10:0xd9cd4ba0
frame pointer   = 0x10:0xd9cd4bc8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 92287 (make)
timeout stopping cpus
kernel: type 12 trap, code=0
Stopped at  propagate_priority+0x219:   movzbl  0xe5(%edx),%eax
db tr
propagate_priority(c4958c80,0,c06fb9a2,1dc,c075dc38) at propagate_priority+0x219
turnstile_wait(c48e9540,c075a300,c585a140,1cc,605) at turnstile_wait+0x33d
_mtx_lock_sleep(c075a300,0,c06f66f8,241,605) at _mtx_lock_sleep+0x125
_mtx_lock_flags(c075a300,0,c06f66f8,241,14b) at _mtx_lock_flags+0x98
wait1(c4958c80,d9cd4d10,0,d9cd4d40,c06c10c0) at wait1+0xa5
wait4(c4958c80,d9cd4d10,c071729f,3ee,4) at wait4+0x20
syscall(2f,2f,2f,0,8095500) at syscall+0x300
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (7, FreeBSD ELF32, wait4), eip = 0x8061a38, esp = 0xbfbfda34, ebp = 
0xbfbfda50 ---
db show pcpu 0
cpuid= 0
curthread= 0xc4958c80: pid 92287 make
curpcb   = 0xd9cd4da0
fpcurthread  = none
idlethread   = 0xc1d00780: pid 12 idle: cpu0
APIC ID  = 0
currentldt   = 0x28
spin locks held:
db show pcpu 1
cpuid= 1
curthread= 0xc4d8ca00: pid 93010 cc1
curpcb   = 0xd9db4da0
fpcurthread  = 0xc4d8ca00: pid 93010 cc1
idlethread   = 0xc1d00640: pid 11 idle: cpu1
APIC ID  = 1
currentldt   = 0x28
spin locks held:
db

I'm not in a super rush to get the machine back up (if it had completed
normally, I would have powered it off until tonight), so if I can supply
additional information that would help resolve this, please let me know.

Serial console is the only access to it while it's running -CURRENT, but
I have that access.

Thanks,
david
-- 
David H. Wolfskill  [EMAIL PROTECTED]
If you want true virus-protection for your PC, install a non-Microsoft OS
on it.  Plausible candidates include FreeBSD, Linux, NetBSD, OpenBSD, and
Solaris (in alphabetical order).
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

kernel trap 12 with interrupts disabled

[Don Lewis]

I just got one of these shortly after I rebooted my November 7th
-CURRENT box. DDB doesn't show much interesting.

 kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0xbc04d753
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0685ddf
stack pointer   = 0x10:0xe5f3bca8
frame pointer   = 0x10:0xe5f3bcfc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 519 (setiathome)
kernel: type 12 trap, code=0
Stopped at  mi_switch+0xcf: cmpl0x8(%esi),%ebx
db tr
mi_switch(c6bbc500,df,c08a3da3,f8,0) at mi_switch+0xcf
ast(e5f3bd48) at ast+0x3f2
doreti_ast() at doreti_ast+0x17

Alas, I didn't have enough free space to capture a core file B-(
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: kernel trap 12 with interrupts disabled

[Don Lewis]

On  9 Nov, I wrote:
 I just got one of these shortly after I rebooted my November 7th
 -CURRENT box. DDB doesn't show much interesting.
 
  kernel trap 12 with interrupts disabled
 
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 0; apic id = 00
 fault virtual address   = 0xbc04d753
 fault code  = supervisor read, page not present
 instruction pointer = 0x8:0xc0685ddf
 stack pointer   = 0x10:0xe5f3bca8
 frame pointer   = 0x10:0xe5f3bcfc
 code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, def32 1, gran 1
 processor eflags= resume, IOPL = 0
 current process = 519 (setiathome)
 kernel: type 12 trap, code=0
 Stopped at  mi_switch+0xcf: cmpl0x8(%esi),%ebx
 db tr
 mi_switch(c6bbc500,df,c08a3da3,f8,0) at mi_switch+0xcf
 ast(e5f3bd48) at ast+0x3f2
 doreti_ast() at doreti_ast+0x17
 
 Alas, I didn't have enough free space to capture a core file B-(

This problem doesn't appear to be reproduceable and doesn't seem to be
load dependent.  I had portupgrade cranking for many hours yesterday
without a hiccup.  I cleaned up a bunch of old distfiles and packages,
so I should have sufficient space to get a core dump in case this
problem happens again.

I forgot to include the vital statistics.  BTW, the RAM is ECC.

Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-CURRENT #35: Fri Nov  7 14:50:18 PST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERICSMB
Preloaded elf kernel /boot/kernel/kernel at 0xc0a9e000.
Preloaded elf module /boot/kernel/aout.ko at 0xc0a9e244.
ACPI APIC Table: GBTAWRDACPI
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) XP 1900+ (1608.23-MHz 686-class CPU)
  Origin = AuthenticAMD  Id = 0x662  Stepping = 2
  
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
  AMD Features=0xc048MP,AMIE,DSP,3DNow!
real memory  = 1073676288 (1023 MB)
avail memory = 1033592832 (985 MB)
ioapic0 Version 1.1 irqs 0-23 on motherboard
Pentium Pro MTRR support enabled
acpi0: GBTAWRDACPI on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 11 entries at 0xc00fdc30
acpi0: Power Button (fixed)
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0
acpi_cpu0: CPU on acpi0
acpi_button0: Power Button on acpi0
acpi_button1: Sleep Button on acpi0
pcib0: ACPI Host-PCI bridge port 
0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib0: slot 7 INTD is routed to irq 10
pcib0: slot 7 INTD is routed to irq 10
agp0: AMD 761 host to AGP bridge port 0xc000-0xc003 mem 
0xef02-0xef020fff,0xe800-0xebff at device 0.0 on pci0
pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pci_cfgintr: 1:5 INTA BIOS irq 15
pci1: display, VGA at device 5.0 (no driver attached)
isab0: PCI-ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: VIA 82C686B UDMA100 controller port 0xc400-0xc40f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
uhci0: VIA 83C572 USB controller port 0xc800-0xc81f irq 10 at device 7.2 on pci0
usb0: VIA 83C572 USB controller on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub0: port error, restarting port 1
uhub0: port error, giving up port 1
uhub0: port error, restarting port 2
uhub0: port error, giving up port 2
uhci1: VIA 83C572 USB controller port 0xcc00-0xcc1f irq 10 at device 7.3 on pci0
usb1: VIA 83C572 USB controller on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhub1: port error, restarting port 1
uhub1: port error, giving up port 1
uhub1: port error, restarting port 2
uhub1: port error, giving up port 2
viapropm0: SMBus I/O base at 0x5000
viapropm0: VIA VT82C686A Power Management Unit port 0x5000-0x500f at device 7.4 on 
pci0
viapropm0: SMBus revision code 0x40
smbus0: System Management Bus on viapropm0
smb0: SMBus generic I/O on smbus0
fxp0: Intel 82550 Pro/100 Ethernet port 0xe000-0xe03f mem 
0xef00-0xef01,0xef021000-0xef021fff irq 18 at device 10.0 on pci0
fxp0: Ethernet address 00:02:b3:5c:8c:e0
miibus0: MII bus on fxp0
inphy0: i82555 10/100 media interface on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ahc0: Adaptec 19160B Ultra160 SCSI adapter port 0xe400-0xe4ff mem 
0xef022000-0xef022fff irq 16 at device 12.0 on pci0
aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f0-0x3f5 
irq 6 drq 2 on acpi0
fdc0: FIFO enabled, 8 bytes

panic for today: kernel trap 12 with interrupts disabled

[David Wolfskill]

CVSup started at 0347 hrs. Pacfic Daylight (7 hrs. west of GMT/UTC)
from cvsup14.freebsd.org.  Build/install/mergemaster was uneventful.
Reboot after mergemaster proceeded as if nothing strange was about
to happen, then (cut/pasted from serial console):

...
SMP: enabled INTs: 2, 3, 4, 6, 7, 9, 10, 14, 15, apic_imen: 0x3923
BIOS Geometries:
 0:03fffe3f 0..1023=1024 cylinders, 0..254=255 heads, 1..63=63 sectors
 0 accounted for
Device configuration finished.
procfs registered
Timecounters tick every 10.000 msec
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: routing 8254 via IOAPIC #0 intpin 2
bpf: lo0 attached
bpf: ppp0 attached
acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0%
ata1-slave: timeout waiting for interrupt
ata1-slave: ATA identify failed
ad0: success setting UDMA5 on VIA chip
Creating DISK ad0
ar: FreeBSD check1 failed
ad0: QUANTUM FIREBALLP AS40.0/A1Y.1500 ATA-5 disk at ata0-master
ad0: 39203MB (80288480 sectors), 79651 C, 16 H, 63 S, 512 B
ad0: 16 secs/int, 1 depth queue, UDMA100
ad0: piomode=4 dmamode=2 udmamode=5 cblid=1
ata1-master: piomode=4 dmamode=2 udmamode=-1 dmaflag=1
ata1-master: success setting PIO4 on generic chip
acd0: Compaq CRD-8322B/1.06 CDROM drive at ata1 as master
acd0: read 5500KB/s (21KB/s), 128KB buffer, PIO4
acd0: Reads: CD-R, CD-RW, CD-DA stream, packet
acd0: Writes:
acd0: Audio: play, 255 volume levels
acd0: Mechanism: ejectable tray, unlocked, lock protected
acd0: Medium: no/blank disc
aMMoPu:n tCiPnUg1  raopoitc _firnoimt iuaflsi:z/ed(e)v:/
l 0 s 4 a 
int0: 0x00010700 lint1: 0x0kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 
fault virtual address   = 0x18
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc01c7c12
stack pointer   = 0x10:0xd69eb9d4
frame pointer   = 0x10:0xd69eb9f8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 4 (pagezero)
kernel: type 12 trap, code=0
Stopped at  witness_lock+0x1a6: movl0x18(%eax),%eax
db tr
witness_lock(c03b1600,8,c0320323,c7e,3f8) at witness_lock+0x1a6
_mtx_lock_spin_flags(c03b1600,0,c0320323,c7e,0) at _mtx_lock_spin_flags+0x89
siocnputc(c037ed00,6b) at siocnputc+0x6f
cnputc(6b) at cnputc+0x43
putchar(6b,d69ebb54) at putchar+0xae
kvprintf(c0327f40,c01c3da4,d69ebb54,a,d69ebb74) at kvprintf+0x77
printf(c0327f40,c) at printf+0x43
trap(c0380018,10,c0300010,c0341100,c03aa36c) at trap+0xb5
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc01c7c12, esp = 0xd69ebbe0, ebp = 0xd69ebc04 ---
witness_lock(c0341100,a,c02fd100,1d1,d69ebc5c) at witness_lock+0x1a6
_mtx_lock_spin_flags(c0341100,2,c02fd100,1d1,d69ebc5c) at _mtx_lock_spin_flags+0x89
statclock(d69ebc5c,c1585f00,d69ebcb4,c02c26d4,0) at statclock+0x1d
rtcintr(0) at rtcintr+0x12
Xfastintr8() at Xfastintr8+0xc4
--- interrupt, eip = 0xc01c83a8, esp = 0xd69ebca0, ebp = 0xd69ebcb4 ---
witness_unlock(c03581c0,8,c031e175,55,c03581c0,1,c02ffb60,153) at witness_unlock+0x16c
_mtx_unlock_flags(c03581c0,0,c031e175,55,ff) at _mtx_unlock_flags+0x55
vm_page_zero_idle(1f0004,c02a1d24,c419d000,0,d69ebd34) at vm_page_zero_idle+0xb0
vm_pagezero(0,d69ebd48,c1585f00,c02a1d24,0) at vm_pagezero+0x6e
fork_exit(c02a1d24,0,d69ebd48) at fork_exit+0xa8
fork_trampoline() at fork_trampoline+0x37
db show pcpu 0
cpuid= 0
curthread= 0xc1585f00: pid 4 pagezero
curpcb   = 0xd69ebda0
fpcurthread  = none
idlethread   = 0xc1584d80: pid 12 idle: cpu0
currentldt   = 0x28
spin locks held:
db show pcpu 1
cpuid= 1
curthread= 0xc1584e40: pid 11 idle: cpu1
curpcb   = 0
fpcurthread  = none
idlethread   = 0xc1584e40: pid 11 idle: cpu1
currentldt   = 0x28
spin locks held:
exclusive spin mutex clk r = 0 (0xc0362a40) locked @ /usr/src/sys/i386/isa/clock.c:409
db ps
  pid   proc addruid  ppid  pgrp  flag  stat wmesg   wchan   cmd
   35 c41b5558 d7c30 0 0 204  Normal  nfsidl c035256c nfsiod 3
   34 c41b5804 d7c310000 0 0 204  Normal  nfsidl c0352568 nfsiod 2
   33 c41b5ab0 d7c320000 0 0 204  Normal  nfsidl c0352564 nfsiod 1
   32 c40762ac d7be10000 0 0 204  Normal  nfsidl c0352560 nfsiod 0
7 c4076558 d7be20000 0 0 204  Normal  syncer c034246c syncer
6 c4076804 d7be30000 0 0 204  Normal  vlruwt c4076804 vnlru
5 c4076ab0 d7be40000 0 0 204  Normal  psleep c03aa720 bufdaemon
4 c419d000 d7be50000 0 0 204  Normal  pagezero
3 c419d2ac d7be60000 0 0 204  Normal  psleep c03af77c vmdaemon
2 c419d558 d7be70000 0 0 204  Normal  psleep c0358798 pagedaemon
   31 c419d804 d7be80000 0 0 204  New  irq8: rtc
   30 c419dab0 d7be90000 0 0 204  New  irq0: clk
  

Re: panic for today: kernel trap 12 with interrupts disabled

[David Wolfskill]

OK; implementing rev. 1.12 of src/sys/vm/vm_zeroidle.c allowed me to
boot my (SMP) build machine  login:

freebeast(5.0-C)[1] uname -a
FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #9: Mon Jul  8 
16:28:30 PDT 2002 
[EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST  i386
freebeast(5.0-C)[2] 


That doesn't (quite) explain why I got a similar-looking panic on my
(UP) laptop, but I'm about to give it a try anyhow.

Cheers,
david
-- 
David H. Wolfskill  [EMAIL PROTECTED]
Trying to support or use Microsoft products makes about as much sense
as painting the outside of a house with watercolors.

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

Re: panic for today: kernel trap 12 with interrupts disabled

[David Wolfskill]

Date: Mon, 8 Jul 2002 16:44:20 -0700 (PDT)
From: David Wolfskill [EMAIL PROTECTED]

OK; implementing rev. 1.12 of src/sys/vm/vm_zeroidle.c allowed me to
boot my (SMP) build machine  login:

freebeast(5.0-C)[1] uname -a
FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #9: Mon Jul  8 
16:28:30 PDT 2002 
[EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST  i386
freebeast(5.0-C)[2] 


That doesn't (quite) explain why I got a similar-looking panic on my
(UP) laptop, but I'm about to give it a try anyhow.

g1-9(5.0-C)[1] uname -a
FreeBSD g1-9.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #8: Mon Jul  8 17:28:37 
PDT 2002 [EMAIL PROTECTED]:/common/S3/obj/usr/src/sys/LAPTOP_30W  i386
g1-9(5.0-C)[2] 

Who am I to argue with (apparent) success?  :-)

Thanks -- especially to Tor-Egge  Peter.

Cheers,
david   (links to my resume at http://www.catwhisker.org/~david)
-- 
David H. Wolfskill  [EMAIL PROTECTED]
Trying to support or use Microsoft products makes about as much sense
as painting the outside of a house with watercolors.

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

Re: gcc -pg causes 'kernel trap 12 with interrupts disabled' panic

[David Taylor]

On Thu, 31 May 2001, Bruce Evans wrote:
 On Wed, 30 May 2001, David Taylor wrote:
 
  When trying to profile ircd-hybrid-7 on -CURRENT (I tried using a pre-vm
  madness version first, then tried a version cvsuped today), I reliably get
  lots of:
  
  kernel trap 12 with interrupts disabled
  
  messages on the console (one every 5-10 seconds, when the ircd is reasonably
  loaded).
 
 This is because ast() calls addupc_task() with sched_lock held.
 addupc_task() calls copyin() and copyin() sometimes traps to fault in the
 profiling buffer.
 
 This seems to be just a bug in ast().  userret() is missing the bug.
 Untested fix:
 
 ---
 Index: trap.c
 ===
 RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v
 retrieving revision 1.189
 diff -u -1 -r1.189 trap.c
 --- trap.c2001/05/23 22:58:09 1.189
 +++ trap.c2001/05/31 13:09:02
 @@ -1285,5 +1341,6 @@
   mtx_lock(Giant);
 - mtx_lock_spin(sched_lock);
   addupc_task(p, p-p_stats-p_prof.pr_addr,
   p-p_stats-p_prof.pr_ticks);
 + mtx_lock_spin(sched_lock);
 + /* XXX why not unlock Giant? */
   }
 ---

I tested this, and it works!

No more `kernel trap 12 with interrupts disabled' messages, and also,
thankfully, no more panics.  (Related to this anyway, I'm still getting
freelist corruption related things).
 
 I think this is caused by the same bug.
 
 kernel trap almost any with interrupts disabled
 
 should be fatal (the case of trap 12 (only) _is_ fatal in my version),
 but the kernel attempts to fix the problem and continue.  This sort
 of worked when things were locked by disabling interrupts.  Now, things
 may be locked by a spinlock as well as by disabling interrupts, and
 the corresponding fixup would be to release the spinlock.  But this
 is more obviously wrong.
 
 Bruce
 

Yeah, just trying to cover up the problem and march on usually doesn't work
out very well in computing.. or anywhere else, really..

-- 
David Taylor
[EMAIL PROTECTED]

 PGP signature

Re: gcc -pg causes 'kernel trap 12 with interrupts disabled' panic

[Bruce Evans]

On Wed, 30 May 2001, David Taylor wrote:

 When trying to profile ircd-hybrid-7 on -CURRENT (I tried using a pre-vm
 madness version first, then tried a version cvsuped today), I reliably get
 lots of:
 
   kernel trap 12 with interrupts disabled
 
 messages on the console (one every 5-10 seconds, when the ircd is reasonably
 loaded).

This is because ast() calls addupc_task() with sched_lock held.
addupc_task() calls copyin() and copyin() sometimes traps to fault in the
profiling buffer.

This seems to be just a bug in ast().  userret() is missing the bug.
Untested fix:

---
Index: trap.c
===
RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v
retrieving revision 1.189
diff -u -1 -r1.189 trap.c
--- trap.c  2001/05/23 22:58:09 1.189
+++ trap.c  2001/05/31 13:09:02
@@ -1285,5 +1341,6 @@
mtx_lock(Giant);
-   mtx_lock_spin(sched_lock);
addupc_task(p, p-p_stats-p_prof.pr_addr,
p-p_stats-p_prof.pr_ticks);
+   mtx_lock_spin(sched_lock);
+   /* XXX why not unlock Giant? */
}
---

 One thing I got with ircd-hybrid-7 (when very heavily loaded with lots of
 clones), which I _couldnt_ replicate with the test program (probably because
 it wasn't very heavily loaded) was a panic:
 ...
 kernel trap 12 with interrupts disabled
 panic: mutex sched lock recursed at /usr/src/sys/kern/kern_sync.c:858
 Debugger(panic)
 Stopped atDebugger+0x45:  pushl   %ebx
 db t
 Debugger(c02fa51b) at Debugger+0x45
 panic(c02f9684,c031d2a9,c02fad20,35a,282) at panic+0x70
 _mtx_assert(c03a7120,9,c02fad20,35a,282) at _mtx_assert+0x6c
 mi_switch(d1748420,38,d1748420,e,d17c9e90) at mi_switch+0x25
 ithread_schedule(c26e3180,1) at ithread_schedule+0x165
 sched_ithd(e) at sched_ithd+0x3d
 Xresume14() at Xresume14+0x7
 -- interrupt, eip = 0xc02c8a18, esp = 0xd17c9ed8, ebp = 0xd17c9f04 --
 trap(d1740018,d1740010,8080010,d17c9f72,85d02ec) at trap+0x94
 calltrap() at calltrap+0x5
 -- trap 0xc, eip = 0xc02c71f5, esp = 0xd17c9f4c, ebp = 0xd17c9f74 --
 generic_copyin(d1748420,809073d,1) at generic_copyin+0x39
 ast(d17c9fa8) at ast+0x318
 doreti_ast() at doreti_ast+0x6

I think this is caused by the same bug.

kernel trap almost any with interrupts disabled

should be fatal (the case of trap 12 (only) _is_ fatal in my version),
but the kernel attempts to fix the problem and continue.  This sort
of worked when things were locked by disabling interrupts.  Now, things
may be locked by a spinlock as well as by disabling interrupts, and
the corresponding fixup would be to release the spinlock.  But this
is more obviously wrong.

Bruce


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

Re: gcc -pg causes 'kernel trap 12 with interrupts disabled' p

[John Baldwin]

On 31-May-01 Bruce Evans wrote:
 On Wed, 30 May 2001, David Taylor wrote:
 
 When trying to profile ircd-hybrid-7 on -CURRENT (I tried using a pre-vm
 madness version first, then tried a version cvsuped today), I reliably get
 lots of:
 
  kernel trap 12 with interrupts disabled
 
 messages on the console (one every 5-10 seconds, when the ircd is reasonably
 loaded).
 
 This is because ast() calls addupc_task() with sched_lock held.
 addupc_task() calls copyin() and copyin() sometimes traps to fault in the
 profiling buffer.
 
 This seems to be just a bug in ast().  userret() is missing the bug.
 Untested fix:

I think I have some comments in my local code about that sched_lock being
bogus. :-/  I'll commit a fix for all platforms today.

 ---
 Index: trap.c
 ===
 RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v
 retrieving revision 1.189
 diff -u -1 -r1.189 trap.c
 --- trap.c2001/05/23 22:58:09 1.189
 +++ trap.c2001/05/31 13:09:02
 @@ -1285,5 +1341,6 @@
   mtx_lock(Giant);
 - mtx_lock_spin(sched_lock);
   addupc_task(p, p-p_stats-p_prof.pr_addr,
   p-p_stats-p_prof.pr_ticks);
 + mtx_lock_spin(sched_lock);
 + /* XXX why not unlock Giant? */

To avoid releasing it just to possibly grab it again afterwards I think, but
I'll have to look at this again.

-- 

John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/

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

Re: rpc.lockd: kernel trap 12 with interrupts disabled

[Thomas Quinot]

Le 2001-05-29, Andrew Gallatin écrivait :

 In order for a bug report like this to be useful, you need to supply a
 backtrace from ddb or gdb.  See the Kernel Debugging section of the
 FreeBSD handbook for instructions on how to obtain such information.

ddb did not help much: after the two 'kernel trap 12 with interrupts
disabled' messages, the hot key does not work anymore.

Using gdb on rpc.lockd and some ddb single-stepping, I was able to
see that the freeze occurs somewhere during the first call to
callrpc().

I'll try a remote GDB session and see if it helps to at least find out
where precisely the error occurs. Or maybe I could add a call to panic()
when the faulty trap occurs, which would drop me into DDB?

Thomas.

-- 
Thomas Quinot ** Département Informatique  Réseaux ** [EMAIL PROTECTED]
  ENST   //   46 rue Barrault   //   75634 PARIS CEDEX 13 

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

rpc.lockd: kernel trap 12 with interrupts disabled

[Thomas Quinot]

In the hope to check for any recent improvements with lockd,
I cvsupped this morning and remade world. I now have a very
strange behaviour of lockd:
  * rc.conf has nfs_server_enable, rpc_lockd_enable and rpc_statd_enable
set to YES.
  * the system seems to boot correclty; rpc.lockd and rpc.statd are
mentioned in the 'Starting final network daemons' phase.

BUT:
  * ps ax shows no trace of rpc.lockd
  * an attempt to manually launch rpc.lockd immediately results in
a hard freeze with message 'Kernel trap 12 with interrupts
disabled (repeated twice).
  * launching rpc.lockd with truss shows that the crash occurs (shortly)
after it has forked.

Thomas.

-- 
Thomas Quinot ** Département Informatique  Réseaux ** [EMAIL PROTECTED]
  ENST   //   46 rue Barrault   //   75634 PARIS CEDEX 13 

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

Re: rpc.lockd: kernel trap 12 with interrupts disabled

[Andrew Gallatin]

Thomas Quinot [[EMAIL PROTECTED]] wrote:
 In the hope to check for any recent improvements with lockd,
 I cvsupped this morning and remade world. I now have a very

Did you also rebuild your kernel?

In order for a bug report like this to be useful, you need to supply a
backtrace from ddb or gdb.  See the Kernel Debugging section of the
FreeBSD handbook for instructions on how to obtain such information.

-- 
--
Andrew Gallatin, Sr Systems Programmer  http://www.cs.duke.edu/~gallatin
Duke University Email: [EMAIL PROTECTED]
Department of Computer Science  Phone: (919) 660-6590

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

Re: rpc.lockd: kernel trap 12 with interrupts disabled

[Thomas Quinot]

Le 2001-05-29, Andrew Gallatin écrivait :

 Did you also rebuild your kernel?

Yep, I did buildworld buildkenrnel installkernel installworld,
then mergemaster and reboot.

 In order for a bug report like this to be useful, you need to supply a
 backtrace from ddb or gdb.  See the Kernel Debugging section of the
 FreeBSD handbook for instructions on how to obtain such information.

Will try that, thanks.
Thomas.

-- 
Thomas Quinot ** Département Informatique  Réseaux ** [EMAIL PROTECTED]
  ENST   //   46 rue Barrault   //   75634 PARIS CEDEX 13 

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

Re: kernel trap 12 with interrupts disabled

[Michael Harnois]

On Sat, 19 May 2001 22:48:51 -0400, Alfred Perlstein [EMAIL PROTECTED] said:

 You'll have to provide more info before anyone can help you.

Well, that would require the kernel offering me more information.

 Can you at least get a DDB traceback?

I have never succeeded in getting that to work, but I'll try once
again ...

-- 
Michael D. Harnois[EMAIL PROTECTED]
Redeemer Lutheran Church  Washburn, Iowa 
 No man knows how bad he is 
 till he has tried very hard to be good. -- C.S. Lewis

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

Re: kernel trap 12 with interrupts disabled

[Edwin Culp]

This may not help much unless there is some common ground to be found.
I have been having problems with my old K6-2 300Mhz laptop hanging in X with
linux-communicator.  From there I have not been able to get any debugging info.
Last night I did a power off/on reset and went to bed.  This morning I had 
a login with a nice bold kernel trap 12 with interrupts disabled that 
happened a couple of hours later after cvsuping and initiating a make world.

I'm going to see if I can get it to do it again although I was able to do a
make world and kernel yesterday with no problem.  The only problem that I was
able to see before was with X and netscape.

ed

Quoting Michael Harnois [EMAIL PROTECTED]:

 On Sat, 19 May 2001 22:48:51 -0400, Alfred Perlstein [EMAIL PROTECTED]
 said:
 
  You'll have to provide more info before anyone can help you.
 
 Well, that would require the kernel offering me more information.
 
  Can you at least get a DDB traceback?
 
 I have never succeeded in getting that to work, but I'll try once
 again ...
 
 -- 
 Michael D. Harnois[EMAIL PROTECTED]
 Redeemer Lutheran Church  Washburn, Iowa 
  No man knows how bad he is 
  till he has tried very hard to be good. -- C.S. Lewis
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 


---
   The illiterate of the 21st century will not be
 those who cannot read and write, 
   but those who cannot learn, unlearn and relearn. 
--Alvin Toffler

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

Re: kernel trap 12 with interrupts disabled

[Edwin Culp]

I forgot to add that I'm not seeing any of this with the PIII's that I have
running current and usually updated daily.

This may not help much unless there is some common ground to be found.
I have been having problems with my old K6-2 300Mhz laptop hanging in X with
linux-communicator.  From there I have not been able to get any debugging info.
Last night I did a power off/on reset and went to bed.  This morning I had 
a login with a nice bold kernel trap 12 with interrupts disabled that 
happened a couple of hours later after cvsuping and initiating a make world.

I'm going to see if I can get it to do it again although I was able to do a
make world and kernel yesterday with no problem.  The only problem that I was
able to see before was with X and netscape.

ed

Quoting Michael Harnois [EMAIL PROTECTED]:

 On Sat, 19 May 2001 22:48:51 -0400, Alfred Perlstein [EMAIL PROTECTED]
 said:
 
  You'll have to provide more info before anyone can help you.
 
 Well, that would require the kernel offering me more information.
 
  Can you at least get a DDB traceback?
 
 I have never succeeded in getting that to work, but I'll try once
 again ...
 
 -- 
 Michael D. Harnois[EMAIL PROTECTED]
 Redeemer Lutheran Church  Washburn, Iowa 
  No man knows how bad he is 
  till he has tried very hard to be good. -- C.S. Lewis
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 


---
   The illiterate of the 21st century will not be
 those who cannot read and write, 
   but those who cannot learn, unlearn and relearn. 
--Alvin Toffler

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


---
   The illiterate of the 21st century will not be
 those who cannot read and write, 
   but those who cannot learn, unlearn and relearn. 
--Alvin Toffler

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

kernel trap 12 with interrupts disabled

[Michael Harnois]

is the message I get as soon as I'm done booting with a kernel build
from this evening's cvsup. No other messages ... sorry, no serial
console ...

-- 
Michael D. Harnois[EMAIL PROTECTED]
Redeemer Lutheran Church  Washburn, Iowa 
 Censorship is the strongest drive in human nature; 
 sex is a weak second. -- Phil Kerby

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

Re: kernel trap 12 with interrupts disabled

[Alfred Perlstein]

* Michael Harnois [EMAIL PROTECTED] [010519 22:44] wrote:
 is the message I get as soon as I'm done booting with a kernel build
 from this evening's cvsup. No other messages ... sorry, no serial
 console ...

You'll have to provide more info before anyone can help you.

Can you at least get a DDB traceback?

-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
Instead of asking why a piece of software is using 1970s technology,
start asking why software is ignoring 30 years of accumulated wisdom.

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

Re: kernel trap 12 with interrupts disabled

[Alexander Leidinger]

On  9 Feb, Bruce Evans wrote:

 Pagefaults occur in copyin() (called from addupc_task() which is called
 from ast()) while sched_lock is held.  This is not good.  Incrementing
 the profiling counters is supposed to be pushed to ordinary process
 context so that things like copyin() can work (they have to be able
 to fault in pages, so they have to be able to sleep...), so using
 sched_lock to lock things here is wrong.

Are we talking about /sys/kern/kern_clock.c: statclock()? I'm not
familiar with the kernel and that's the only place I find something
related to profiling if I grep for "profil" and look at the results. If
yes, what is to to?

 If I run it withhin X11, the machine deadlocks hard (no response from
 the numlock led on the keyboard), withhin a virtual console I get a lot
 of "kernel trap ..." and the program runs fine.
 
 It's surprising that it doesn't always deadlock.

First I thought I have a hardware problem, I was able to profile the
program 4-5 times withhin X11 at a day before. Without changing anything
except the options to the program I wasn't able to profile it later.

Bye,
Alexander.

-- 
  Loose bits sink chips.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7



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

Re: kernel trap 12 with interrupts disabled

[Bruce Evans]

On Fri, 9 Feb 2001, Alexander Leidinger wrote:

 On  9 Feb, Bruce Evans wrote:
 
  Pagefaults occur in copyin() (called from addupc_task() which is called
  from ast()) while sched_lock is held.  This is not good.  Incrementing
  the profiling counters is supposed to be pushed to ordinary process
  context so that things like copyin() can work (they have to be able
  to fault in pages, so they have to be able to sleep...), so using
  sched_lock to lock things here is wrong.
 
 Are we talking about /sys/kern/kern_clock.c: statclock()? I'm not

No :-).  ast() is in /sys/${MACHINE}/${MACHINE}/trap.c.  Incrementing
the profiling counters is much too hard to do in statclock(), since
statclock() is a fast interrupt handler, so statclock() only schedules
an AST to do the increment.  The scheduling of the AST is rather tangled
and pessimized to support optimizations that aren't possible while
statclock() is a fast interrupt handler.  See addupc_intr(), fuswintr(),
suswintr() and need_proftick().

Bruce



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

kernel trap 12 with interrupts disabled

[Alexander Leidinger]

Hi,

if I run a program compiled with gcc's function profiling option I get
"kernel trap 12 with interrupts disabled".
If I run it withhin X11, the machine deadlocks hard (no response from
the numlock led on the keyboard), withhin a virtual console I get a lot
of "kernel trap ..." and the program runs fine.

-current as of Feb. 6, ~2pm UTC.

Bye,
Alexander.

-- 
   I believe the technical term is "Oops!"

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7



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

Re: kernel trap 12 with interrupts disabled

[Maxim Sobolev]

Alexander Leidinger wrote:

 Hi,

 if I run a program compiled with gcc's function profiling option I get
 "kernel trap 12 with interrupts disabled".

The same is here.

-Maxim




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

Re: kernel trap 12 with interrupts disabled

[Bruce Evans]

On Thu, 8 Feb 2001, Alexander Leidinger wrote:

 if I run a program compiled with gcc's function profiling option I get
 "kernel trap 12 with interrupts disabled".

This happens with the standard profiling option -pg.

Pagefaults occur in copyin() (called from addupc_task() which is called
from ast()) while sched_lock is held.  This is not good.  Incrementing
the profiling counters is supposed to be pushed to ordinary process
context so that things like copyin() can work (they have to be able
to fault in pages, so they have to be able to sleep...), so using
sched_lock to lock things here is wrong.

 If I run it withhin X11, the machine deadlocks hard (no response from
 the numlock led on the keyboard), withhin a virtual console I get a lot
 of "kernel trap ..." and the program runs fine.

It's surprising that it doesn't always deadlock.

Bruce



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

kernel trap 12 with interrupts disabled?

[The Hermit Hacker]

kernel of today, during a make world, generates:

Oct 23 18:32:18 thelab /boot/kernel/kernel: kernel trap 12 with interrupts disabled
Oct 23 18:32:32 thelab /boot/kernel/kernel: kernel trap 12 with interrupts disabled
Oct 23 18:32:39 thelab /boot/kernel/kernel: kernel trap 12 with interrupts disabled

and then hangs solid ...

I'm running the ahc driver for the following card:

ahc0: Adaptec 2940 Ultra SCSI adapter port 0xc800-0xc8ff mem 0xef00-0xef000fff 
irq 17 at device 13.0 on pci0
aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs

known problem, or new one?

thanks ...

Marc G. Fournier   ICQ#7615664   IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: [EMAIL PROTECTED]   secondary: scrappy@{freebsd|postgresql}.org 



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

RE: kernel trap 12 with interrupts disabled?

[Daniel O'Connor]

On 23-Oct-00 The Hermit Hacker wrote:
  kernel of today, during a make world, generates:
  
  Oct 23 18:32:18 thelab /boot/kernel/kernel: kernel trap 12 with interrupts
  disabled
  Oct 23 18:32:32 thelab /boot/kernel/kernel: kernel trap 12 with interrupts
  disabled
  Oct 23 18:32:39 thelab /boot/kernel/kernel: kernel trap 12 with interrupts
  disabled
  
  and then hangs solid ...
  
  I'm running the ahc driver for the following card:
  
  ahc0: Adaptec 2940 Ultra SCSI adapter port 0xc800-0xc8ff mem
  0xef00-0xef000fff irq 17 at device 13.0 on pci0
  aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs
  
  known problem, or new one?

I get the kernel trap messages 5 times on a boot, but my system seems OK,
except occasionally it hangs bad (no DDB).

I don't have any SCSI adapters however.
(Dual PII350 BX chipset, IDE)

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum


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

Re: kernel trap 12 with interrupts disabled

[Valentin Chopov]

I got the same with addition that the machine hangs:(

Val

On Wed, 18 Oct 2000, Manfred Antar wrote:

 With current kernel I'm getting alot of :
 kernel trap 12 with interrupts disabled
 kernel trap 12 with interrupts disabled
 kernel trap 12 with interrupts disabled
 kernel trap 12 with interrupts disabled
 kernel trap 12 with interrupts disabled
 
 Kernel from yesterday did not do this.
 Everything seems to work fine although I think it hung on a "shutdown -r now"
 I don't have a monitor hooked up to the machine right now, so I have no further info.
 I'm in process of hooking up a serial console.
 Manfred
 ==
 ||  [EMAIL PROTECTED]   ||
 ||  Ph. (415) 681-6235  ||
 ==
 
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message
 



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

kernel trap 12 with interrupts disabled

[Manfred Antar]

With current kernel I'm getting alot of :
kernel trap 12 with interrupts disabled
kernel trap 12 with interrupts disabled
kernel trap 12 with interrupts disabled
kernel trap 12 with interrupts disabled
kernel trap 12 with interrupts disabled

Kernel from yesterday did not do this.
Everything seems to work fine although I think it hung on a "shutdown -r now"
I don't have a monitor hooked up to the machine right now, so I have no further info.
I'm in process of hooking up a serial console.
Manfred
==
||  [EMAIL PROTECTED]   ||
||  Ph. (415) 681-6235  ||
==



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