Cardbus, audio irq sharing [Was: Kernel Panic from Yesterday's CVSup]
: And, it's not working for me, i.e. my pccard using cardbus is working on irq : 11, my csa audio card is probed and configured on irq 11, but audio playback : is not. Audio and current is also dicy. Well, the same happened under -stable. I think this will be my last IBM laptop, I don't like the way IRQs are wired, and it also looks like ACPI is tricky. : just wait. On a separate note, I am thinking about adapting rc.pccard to : carbus, or writing a new rc.cardbus; is anybody working on this? /sbin/devd :-) Pointers to this? Does it run dhclient like rc.pccard does? Although one of the nicest things about cardbus is that, having the card in at boot, it probed and configured much earlier during the boot process, making it possible to ifconfig it normally. : Going back to the original thread, removing my card under cardbus simply : hangs my laptop. I have no idea how to debug this. Neither do I. I make guesses until it is working. Ok ;-) Sounds fun :-P -- Press every key to continue. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Here I am again. Didn't get as far as a login prompt, I have a panic when qmail starts up: Turn MUTEX_DEBUG off. It appears to be broken atm. Done, no panic, and performance is bad but not so bad. -- Reboot America. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On Thu, Feb 08, 2001 at 09:56:43AM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Andrea Campi writes: : Will try again with cardbus and report. So are you saying it SHOULD work : (as far as my chipset is behaving, I suppose)? Cardbus works, more or less, on -current right now. Some cards just work, other cards need help. I keep meaning to do a survey, but haven't found the time to do it yet. Of course cardbus per se is working, I meant irq sharing when using cardbus... And, it's not working for me, i.e. my pccard using cardbus is working on irq 11, my csa audio card is probed and configured on irq 11, but audio playback is not. If you or anybody else has time and is willing to debug this I am available, but I understand there are a lot of things which are more urgent so I will just wait. On a separate note, I am thinking about adapting rc.pccard to carbus, or writing a new rc.cardbus; is anybody working on this? Going back to the original thread, removing my card under cardbus simply hangs my laptop. I have no idea how to debug this. Bye, Andrea -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
In message [EMAIL PROTECTED] Andrea Campi writes: : Of course cardbus per se is working, I meant irq sharing when using cardbus... Works great for me. : And, it's not working for me, i.e. my pccard using cardbus is working on irq : 11, my csa audio card is probed and configured on irq 11, but audio playback : is not. Audio and current is also dicy. : just wait. On a separate note, I am thinking about adapting rc.pccard to : carbus, or writing a new rc.cardbus; is anybody working on this? /sbin/devd :-) : Going back to the original thread, removing my card under cardbus simply : hangs my laptop. I have no idea how to debug this. Neither do I. I make guesses until it is working. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Seriously, that's ok, I only want to check if I get the same panic. And give
feedback of course.
Here I am again. Didn't get as far as a login prompt, I have a panic when qmail
starts up:
lock order reversal
1st lockmgr last acquired @ ../../kern/kern_lock.c:239
2nd 0xc02630c0 uidinfo hash @ ../../kern/kern_resource.c:727
3rd 0xc0261080 lockmgr @ ../../kern/kern_lock.c:239
panic: mutex_enter: recursion on non-recursive mutex process lock @
+../../kern/kern_lock.c:260
Debugger("panic")
Stopped at Debugger+0x46: pushl %ebx
db trace
Debugger(c0213d83) at Debugger+0x46
panic(c0212cc0,c029,c021195a,104,c65d6964) at panic+0x70
witness_enter(c65d6964,0,c021195a,104,c65d6964) at witness_enter+0x1b2
_mtx_enter(c65d6964,0,c021195a,104) at _mtx_enter+0x154
lockmgr(c026849c,1,0,c65d6840,c0a6691c) at lockmgr+0xad
kernacc(c027bd40,4,1,c023c500,0c0212497,34d) at kernacc+0x54
mtx_validate(c0a6691c,1) at mtx_validate+0x59
mtx_init(c0a6691c,c02138cc,0,0,57) at mtx_init+0x13
uicreate(57,c65d6964,c0a6d0c0,c65e0f30,c014f13a) at uicreate+0x8a
uifind(57,c65d6964,0,c02135b0,586) at uifind+0x33
change_ruid(c65d6840,57,c65d6840,0,1) at change_ruid+0x46
setuid(c65d6840,c65e0f80,bfbffd80,bfbffd7c,bfbffd90) at setuid+0x3a
syscall2(2f,2f,2f,bfbffd90,bfbffd7c) at syscall2+0x29c
Xint0x80_syscall() at Xint0x80_syscall+0x23
--- syscall 0x17, eip = 0x280a039c, esp 0xbfbffcdc, ebp = 0xbfbffcf8
At least I think it's qmail, looking at the `ps' output...
--
The best things in life are free, but the
expensive ones are still worth a look.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
ISA bus cannot share interrupts at all. Full stop[*]. Most pccard/cardbus bridges operate in a mode where they use ISA interrupts, so cannot share interrupts at all. The hardware just won't work if you try. NEWCARD tries to kick the cardbus bridge into full PCI mode, where you can share interrupts, since all the interrupts are going through the PCI hardware chain which does support interrupt sharing. Thanks for expressing in a proper way what I was trying to say ;-) Will try again with cardbus and report. So are you saying it SHOULD work (as far as my chipset is behaving, I suppose)? Bye, Andrea -- "One world, one web, one program" -- Microsoft promotional ad "Ein Volk, ein Reich, ein Fuehrer" -- Adolf Hitler To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
In message [EMAIL PROTECTED] Andrea Campi writes: : Will try again with cardbus and report. So are you saying it SHOULD work : (as far as my chipset is behaving, I suppose)? Cardbus works, more or less, on -current right now. Some cards just work, other cards need help. I keep meaning to do a survey, but haven't found the time to do it yet. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 08-Feb-01 Andrea Campi wrote: Seriously, that's ok, I only want to check if I get the same panic. And give feedback of course. Here I am again. Didn't get as far as a login prompt, I have a panic when qmail starts up: Turn MUTEX_DEBUG off. It appears to be broken atm. -- 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: Kernel Panic from Yesterday's CVSup
Ok, I will. Can you give me a date I should try going back to, without kernel getting out of sync with my world? A kernel on the 30th or so should work fine with an up to date world. Thought I had tried this... FreeBSD 5.0-CURRENT #0: Wed Jan 10 11:00:55 CET 2001 root@brian:/usr/obj/usr/src/sys/THINKPAD is fine. I am currently doing a cvs co -D"2001-01-30" src/sys I will report on this later. Bye, Andrea -- Tagline generated by 'gensig' mail-client-independent .signature generator. Get your copy at http://www.geeks.com/~robf/gensig/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
I can easily reproduce the panic on my -CURRENT Athlon box by just starting any
print job. Other that that, the system seems to be running OK, i.e. no panics
occur unless some lpr activity is involved. Here is the stack dump:
#9 0xc02a9fbc in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16,
tf_edi = -857849588, tf_esi = 32, tf_ebp = -696148124,
tf_isp = -696148164, tf_ebx = -1069967232, tf_edx = -857849856,
tf_ecx = -868400672, tf_eax = -1070952435, tf_trapno = 9, tf_err = 32,
tf_eip = -1070952316, tf_cs = 8, tf_eflags = 65670,
tf_esp = -1071733991, tf_ss = 0}) at ../../i386/i386/trap.c:656
#10 0xc02a9084 in sw1b ()
#11 0xc02b075b in ithd_loop (dummy=0x0) at ../../i386/isa/ithread.c:216
#12 0xc01dc48d in fork_exit (callout=0xc02b0664 ithd_loop, arg=0x0,
frame=0xd6819fa8) at ../../kern/kern_fork.c:669
and disassembled code at the point of the trap looks like
0xc02a9076 sw1b+105: mov%eax,0x0(%ebx)
0xc02a9079 sw1b+108: mov0x4(%edi),%eax
0xc02a907c sw1b+111: mov%eax,0x4(%ebx)
0xc02a907f sw1b+114: mov$0x20,%esi
0xc02a9084 sw1b+119: ltr%si
..^^
Also, a pretty unpleasant crash occurs on the latest current boxes everytime
vidcontrol is used to change console resolution to the VESA_800x600 mode.
I was able to get the crash dump, but unfortunately it seems like the stack is
becoming corrupt and so there is no useful information to report.
--
E-Mail: Alexander N. Kabaev [EMAIL PROTECTED]
Date: 07-Feb-2001
Time: 00:35:38
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Running a kernel I got with this:
cvs co -D"2001-01-30" src/sys
/ithread.c/1.10/Mon Dec 4 21:15:14 2000//D2001.01.29.23.00.00
I get:
panic: malloc(M_WAITOK) in interrupt context
Debugger("panic")
Stopped at Debugger+0x45: pushl %ebx
db trace
Debugger(c02119a3) at Debugger+0x45
panic()
malloc(48,c0238100,0,c65feb80,0) at malloc+0x2a
exit1(c65feb80,0,0,c6623f78,c01fc852) at exit1+0x1b1
kthread_suspend(0,c0279a40,0,c022d1ec,a2) at kthread_suspend
ithd_loop(0,c6623fa8) at ithd_loop+0x56
fork_exit(c01fc7fc,0,c6623fa8) at fork_exit+0x8
fork_trampoline() at fork_trampoline+0x8
db witness_list
"Giant" (0xc0279a40) locked at ../../i386/isa/ithread.c:162
--
Actually, Microsoft is sort of a mixture between the Borg and the Ferengi.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Running a kernel I got with this:
cvs co -D"2001-01-30" src/sys
/ithread.c/1.10/Mon Dec 4 21:15:14 2000//D2001.01.29.23.00.00
I get:
panic: malloc(M_WAITOK) in interrupt context
Debugger("panic")
Stopped at Debugger+0x45: pushl %ebx
db trace
Debugger(c02119a3) at Debugger+0x45
panic()
malloc(48,c0238100,0,c65feb80,0) at malloc+0x2a
exit1(c65feb80,0,0,c6623f78,c01fc852) at exit1+0x1b1
kthread_suspend(0,c0279a40,0,c022d1ec,a2) at kthread_suspend
ithd_loop(0,c6623fa8) at ithd_loop+0x56
fork_exit(c01fc7fc,0,c6623fa8) at fork_exit+0x8
fork_trampoline() at fork_trampoline+0x8
db witness_list
"Giant" (0xc0279a40) locked at ../../i386/isa/ithread.c:162
Make sure you have intr_machdep.c version 1.47.
revision 1.47
date: 2001/01/28 17:20:11
--
Actually, Microsoft is sort of a mixture between the Borg and the Ferengi.
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
Re: Kernel Panic from Yesterday's CVSup
panic: malloc(M_WAITOK) in interrupt context
Debugger("panic")
Stopped at Debugger+0x45: pushl %ebx
db trace
Debugger(c02119a3) at Debugger+0x45
panic()
malloc(48,c0238100,0,c65feb80,0) at malloc+0x2a
exit1(c65feb80,0,0,c6623f78,c01fc852) at exit1+0x1b1
kthread_suspend(0,c0279a40,0,c022d1ec,a2) at kthread_suspend
ithd_loop(0,c6623fa8) at ithd_loop+0x56
fork_exit(c01fc7fc,0,c6623fa8) at fork_exit+0x8
fork_trampoline() at fork_trampoline+0x8
db witness_list
"Giant" (0xc0279a40) locked at ../../i386/isa/ithread.c:162
Make sure you have intr_machdep.c version 1.47.
revision 1.47
date: 2001/01/28 17:20:11
Actually I have
/intr_machdep.c/1.49/Mon Jan 29 11:57:26 2001/
But the differences shouldn't matter...
Bye,
Andrea
--
Intel: where Quality is job number 0.9998782345!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 07-Feb-01 Andrea Campi wrote:
Running a kernel I got with this:
cvs co -D"2001-01-30" src/sys
/ithread.c/1.10/Mon Dec 4 21:15:14 2000//D2001.01.29.23.00.00
I get:
panic: malloc(M_WAITOK) in interrupt context
Debugger("panic")
Stopped at Debugger+0x45: pushl %ebx
db trace
Debugger(c02119a3) at Debugger+0x45
panic()
malloc(48,c0238100,0,c65feb80,0) at malloc+0x2a
exit1(c65feb80,0,0,c6623f78,c01fc852) at exit1+0x1b1
kthread_suspend(0,c0279a40,0,c022d1ec,a2) at kthread_suspend
ithd_loop(0,c6623fa8) at ithd_loop+0x56
fork_exit(c01fc7fc,0,c6623fa8) at fork_exit+0x8
fork_trampoline() at fork_trampoline+0x8
db witness_list
"Giant" (0xc0279a40) locked at ../../i386/isa/ithread.c:162
Erm, ithd_loop() doesn't call kthread_suspend(). *sigh*. Something
else is rather messed up here I'm afraid.
--
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: Kernel Panic from Yesterday's CVSup
On Wed, Feb 07, 2001 at 02:20:43PM -0800, John Baldwin wrote:
On 07-Feb-01 Andrea Campi wrote:
Running a kernel I got with this:
cvs co -D"2001-01-30" src/sys
/ithread.c/1.10/Mon Dec 4 21:15:14 2000//D2001.01.29.23.00.00
I get:
panic: malloc(M_WAITOK) in interrupt context
Debugger("panic")
Stopped at Debugger+0x45: pushl %ebx
db trace
Debugger(c02119a3) at Debugger+0x45
panic()
malloc(48,c0238100,0,c65feb80,0) at malloc+0x2a
exit1(c65feb80,0,0,c6623f78,c01fc852) at exit1+0x1b1
kthread_suspend(0,c0279a40,0,c022d1ec,a2) at kthread_suspend
ithd_loop(0,c6623fa8) at ithd_loop+0x56
fork_exit(c01fc7fc,0,c6623fa8) at fork_exit+0x8
fork_trampoline() at fork_trampoline+0x8
db witness_list
"Giant" (0xc0279a40) locked at ../../i386/isa/ithread.c:162
Erm, ithd_loop() doesn't call kthread_suspend(). *sigh*. Something
else is rather messed up here I'm afraid.
So I thought... also, kthread_suspend() doesn't call exit1(), does it?
No matter what, ithd_loop() calls kthread_exit() which calls exit1()
which happily MALLOC's with M_WAITOK...
Something is messed up, indeed, but it seems to be a case of WISIWYG instead
of what I mean... ;-)
Also, I think this issue has been there longer but it might have been masked
by me not having INVARIANTS defined at times (am I correct to read the code as
not panicing #ifndef INVARIANTS?). So I am going back before this revision:
revision 1.78
date: 2001/01/21 19:25:07; author: jake; state: Exp; lines: +3 -2
Make intr_nesting_level per-process, rather than per-cpu. Setup
interrupt threads to run with it always = 1, so that malloc can
detect M_WAITOK from "interrupt" context. This is also necessary
in order to context switch from sched_ithd() directly.
Re: the strace db trace above, is it possible that it might be because I have:
CFLAGS ?= -O -pipe -mcpu=i686 -march=i686
COPTFLAGS ?= -O -pipe -mcpu=i686 -march=i686
in make.conf? I put these after somebody mentioned using it here...
Bye,
Andrea
--
Weird enough for government work.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Re: the strace db trace above, is it possible that it might be because I have: CFLAGS ?= -O -pipe -mcpu=i686 -march=i686 COPTFLAGS ?= -O -pipe -mcpu=i686 -march=i686 No, I was getting the same panic with the kernel, compiled with stock flags. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On Wed, Feb 07, 2001 at 02:20:43PM -0800, John Baldwin wrote:
On 07-Feb-01 Andrea Campi wrote:
Running a kernel I got with this:
cvs co -D"2001-01-30" src/sys
/ithread.c/1.10/Mon Dec 4 21:15:14 2000//D2001.01.29.23.00.00
I get:
panic: malloc(M_WAITOK) in interrupt context
Debugger("panic")
Stopped at Debugger+0x45: pushl %ebx
db trace
Debugger(c02119a3) at Debugger+0x45
panic()
malloc(48,c0238100,0,c65feb80,0) at malloc+0x2a
exit1(c65feb80,0,0,c6623f78,c01fc852) at exit1+0x1b1
kthread_suspend(0,c0279a40,0,c022d1ec,a2) at kthread_suspend
ithd_loop(0,c6623fa8) at ithd_loop+0x56
fork_exit(c01fc7fc,0,c6623fa8) at fork_exit+0x8
fork_trampoline() at fork_trampoline+0x8
db witness_list
"Giant" (0xc0279a40) locked at ../../i386/isa/ithread.c:162
Erm, ithd_loop() doesn't call kthread_suspend(). *sigh*. Something
else is rather messed up here I'm afraid.
So I thought... also, kthread_suspend() doesn't call exit1(), does it?
No matter what, ithd_loop() calls kthread_exit() which calls exit1()
which happily MALLOC's with M_WAITOK...
Something is messed up, indeed, but it seems to be a case of WISIWYG instead
of what I mean... ;-)
Also, I think this issue has been there longer but it might have been masked
by me not having INVARIANTS defined at times (am I correct to read the code as
not panicing #ifndef INVARIANTS?). So I am going back before this revision:
revision 1.78
date: 2001/01/21 19:25:07; author: jake; state: Exp; lines: +3 -2
Make intr_nesting_level per-process, rather than per-cpu. Setup
interrupt threads to run with it always = 1, so that malloc can
detect M_WAITOK from "interrupt" context. This is also necessary
in order to context switch from sched_ithd() directly.
This is why you're getting the panic in exit1(), but I thought I fixed
this in intr_machdep.c version 1.47.
revision 1.47
date: 2001/01/28 17:20:11; author: jake; state: Exp; lines: +2 -1
Clear intr_nesting_level when an interrupt thread has no more
handlers and wants to exit, so it doesn't panic in exit1()
which malloc()s with M_WAITOK.
Reported by:Bob Bishop [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Yes, the intr_nesting_level needs to be dropped before calling kthread_exit(). I have this fixed in a different manner locally. You can try that to see if it gets farther. However, your problems with lpr are a known problem and one that is in the process of being fixed. No that was the other guy. My problem is when ejecting a pccard ethernet card, which of course is the only device on that irq, triggering this bug which is probably much less exercised on desktops (another good argument for keeping current on my laptop). This said, I'd love to try your patch to decrement intr_nesting_level and see what happens. Bye, andrea -- To boldly go where I surely don't belong. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 08-Feb-01 Andrea Campi wrote: Yes, the intr_nesting_level needs to be dropped before calling kthread_exit(). I have this fixed in a different manner locally. You can try that to see if it gets farther. However, your problems with lpr are a known problem and one that is in the process of being fixed. No that was the other guy. My problem is when ejecting a pccard ethernet card, which of course is the only device on that irq, triggering this bug which is probably much less exercised on desktops (another good argument for keeping current on my laptop). This said, I'd love to try your patch to decrement intr_nesting_level and see what happens. My patches may help with this, but they are a lot more than just a single change, they are an overhaul of the interrupt threads code. :) If you are really curious, you can find them at http://www.FreeBSD.org/~jhb/patches/sys.patch. Currently, however, they reduce the system to a crawl. Well, at least console I/O feels like a 2400 baud modem. I'm even losing characters on the keyboard. :( -- 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: Kernel Panic from Yesterday's CVSup
My patches may help with this, but they are a lot more than just a single change, they are an overhaul of the interrupt threads code. :) If you are really curious, you can find them at http://www.FreeBSD.org/~jhb/patches/sys.patch. Currently, however, they reduce the system to a crawl. Well, at least console I/O feels like a 2400 baud modem. I'm even losing characters on the keyboard. :( Sort of killing a mosquito with a missile ;-) Seriously, I will try your patch to confirm it works, then I'll go back to a regular -current kernel and live without ejecting the card... While I was reading your patch I was wondering: what's the situation with IRQ sharing between PCCard and other devices? Since you're doing such a massive rework, wouldn't this be a good time to also deal with this if possible (well not now of course, after your patch is confirmed ok and committed)? In case I was not clear: at the moment pccard and cardbus devices can't share IRQ line with any kind of other devices. The best explanation of this mentioned only pccard and said it was handled as ISA so you coulnd't share, but in theory it was possible to handle pccard in a different way. And cardbus shouldn't be a problem at all I think. Bye, Andrea -- Actually, Microsoft is sort of a mixture between the Borg and the Ferengi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
However, your problems with lpr are a known problem and one that is in the process of being fixed. That was me who reported lpr problems in this thread. I just found it curious that Andrea's panics look absolutely identical to ones I am getting here when attempting to use lpr. Do you really think that is a pure coincidence? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 08-Feb-01 Alexander N. Kabaev wrote: However, your problems with lpr are a known problem and one that is in the process of being fixed. That was me who reported lpr problems in this thread. I just found it curious that Andrea's panics look absolutely identical to ones I am getting here when attempting to use lpr. Do you really think that is a pure coincidence? No, I'm hoping they are both related to a race between removing an ithread and adding a new one, in which case my patches will serve to fix this. -- 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: Kernel Panic from Yesterday's CVSup
On 08-Feb-01 Andrea Campi wrote: My patches may help with this, but they are a lot more than just a single change, they are an overhaul of the interrupt threads code. :) If you are really curious, you can find them at http://www.FreeBSD.org/~jhb/patches/sys.patch. Currently, however, they reduce the system to a crawl. Well, at least console I/O feels like a 2400 baud modem. I'm even losing characters on the keyboard. :( Sort of killing a mosquito with a missile ;-) Seriously, I will try your patch to confirm it works, then I'll go back to a regular -current kernel and live without ejecting the card... Keep your kernel.old around. Trust me, the new kernel won't be very usable. :) In case I was not clear: at the moment pccard and cardbus devices can't share IRQ line with any kind of other devices. The best explanation of this mentioned only pccard and said it was handled as ISA so you coulnd't share, but in theory it was possible to handle pccard in a different way. And cardbus shouldn't be a problem at all I think. cardbus already shares. pccard under NEWCARD shares as well. My work is at a lower-level than that though, that is in the pccard/cardbus specific code. -- 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: Kernel Panic from Yesterday's CVSup
Sort of killing a mosquito with a missile ;-) Seriously, I will try your patch to confirm it works, then I'll go back to a regular -current kernel and live without ejecting the card... Keep your kernel.old around. Trust me, the new kernel won't be very usable. :) Better yet, I always keep a /boot/kernel.safe/ for those times when I compile a lot of different kernels so that I don't have to remember to save a working one ;-) Seriously, that's ok, I only want to check if I get the same panic. And give feedback of course. In case I was not clear: at the moment pccard and cardbus devices can't share IRQ line with any kind of other devices. The best explanation of this mentioned only pccard and said it was handled as ISA so you coulnd't share, but in theory it was possible to handle pccard in a different way. And cardbus shouldn't be a problem at all I think. cardbus already shares. pccard under NEWCARD shares as well. My work is at a lower-level than that though, that is in the pccard/cardbus specific code. cardbus gives me some problem I didn't investigate yes in details, but pccard - I tried but got nowhere. Both drivers probe and attach (ep0 on pccard, csa on motherboard), so I have pcic-pci0 and sound card sharing IRQ 11, ep0 on IRQ 3. But if I try playing anything I get no IRQ from the sound card... Ok I will leave this for the future... ;-) Bye, Andrea -- The computer revolution is over. The computers won. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
This is why you're getting the panic in exit1(), but I thought I fixed this in intr_machdep.c version 1.47. revision 1.47 date: 2001/01/28 17:20:11; author: jake; state: Exp; lines: +2 -1 Clear intr_nesting_level when an interrupt thread has no more handlers and wants to exit, so it doesn't panic in exit1() which malloc()s with M_WAITOK. Well, either it fails to deliver, but then somebody else would have seen it, or it's in some way tied to my hw setup. Could there be a race, an interrupt firing at a very bad time? Shouldn't be a problem if locking is correct... Bah... any idea? Andrea -- The dark ages were caused by the Y1K problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 07-Feb-01 Andrea Campi wrote:
On Wed, Feb 07, 2001 at 02:20:43PM -0800, John Baldwin wrote:
On 07-Feb-01 Andrea Campi wrote:
Running a kernel I got with this:
cvs co -D"2001-01-30" src/sys
/ithread.c/1.10/Mon Dec 4 21:15:14 2000//D2001.01.29.23.00.00
I get:
panic: malloc(M_WAITOK) in interrupt context
Debugger("panic")
Stopped at Debugger+0x45: pushl %ebx
db trace
Debugger(c02119a3) at Debugger+0x45
panic()
malloc(48,c0238100,0,c65feb80,0) at malloc+0x2a
exit1(c65feb80,0,0,c6623f78,c01fc852) at exit1+0x1b1
kthread_suspend(0,c0279a40,0,c022d1ec,a2) at kthread_suspend
ithd_loop(0,c6623fa8) at ithd_loop+0x56
fork_exit(c01fc7fc,0,c6623fa8) at fork_exit+0x8
fork_trampoline() at fork_trampoline+0x8
db witness_list
"Giant" (0xc0279a40) locked at ../../i386/isa/ithread.c:162
Erm, ithd_loop() doesn't call kthread_suspend(). *sigh*. Something
else is rather messed up here I'm afraid.
So I thought... also, kthread_suspend() doesn't call exit1(), does it?
No matter what, ithd_loop() calls kthread_exit() which calls exit1()
which happily MALLOC's with M_WAITOK...
Something is messed up, indeed, but it seems to be a case of WISIWYG instead
of what I mean... ;-)
Also, I think this issue has been there longer but it might have been masked
by me not having INVARIANTS defined at times (am I correct to read the code
as
not panicing #ifndef INVARIANTS?). So I am going back before this revision:
revision 1.78
date: 2001/01/21 19:25:07; author: jake; state: Exp; lines: +3 -2
Make intr_nesting_level per-process, rather than per-cpu. Setup
interrupt threads to run with it always = 1, so that malloc can
detect M_WAITOK from "interrupt" context. This is also necessary
in order to context switch from sched_ithd() directly.
Yes, the intr_nesting_level needs to be dropped before calling kthread_exit().
I have this fixed in a different manner locally. You can try that to see if it
gets farther. However, your problems with lpr are a known problem and one that
is in the process of being fixed.
--
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: Kernel Panic from Yesterday's CVSup
In message [EMAIL PROTECTED], John Baldwin writes: malloc(48,c0238100,0,c65feb80,0) at malloc+0x2a exit1(c65feb80,0,0,c6623f78,c01fc852) at exit1+0x1b1 kthread_suspend(0,c0279a40,0,c022d1ec,a2) at kthread_suspend ithd_loop(0,c6623fa8) at ithd_loop+0x56 fork_exit(c01fc7fc,0,c6623fa8) at fork_exit+0x8 fork_trampoline() at fork_trampoline+0x8 db witness_list "Giant" (0xc0279a40) locked at ../../i386/isa/ithread.c:162 Erm, ithd_loop() doesn't call kthread_suspend(). *sigh*. Something else is rather messed up here I'm afraid. Note that the return address into kthread_suspend is kthread_suspend+0x0. Since the call to exit1() in kthread_exit is the very last operation in kthread_exit, you'd expect the return address on the stack to be at the start of the next function... Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
In message [EMAIL PROTECTED] Andrea Campi writes: : While I was reading your patch I was wondering: what's the situation with : IRQ sharing between PCCard and other devices? Since you're doing such a : massive rework, wouldn't this be a good time to also deal with this if : possible (well not now of course, after your patch is confirmed ok and : committed)? Sharing of IRQ between PCCARDs is not possible at the hardware level, unless your bridge supports it. OLDCARD only supports the legacy mode, so it isn't possible to share interrupts. NEWCARD supports cardbus bridges, which support sharing of interrupts in a very limited sense, but good enough for our purposes. : In case I was not clear: at the moment pccard and cardbus devices can't : share IRQ line with any kind of other devices. The best explanation of : this mentioned only pccard and said it was handled as ISA so you coulnd't : share, but in theory it was possible to handle pccard in a different way. : And cardbus shouldn't be a problem at all I think. ISA bus cannot share interrupts at all. Full stop[*]. Most pccard/cardbus bridges operate in a mode where they use ISA interrupts, so cannot share interrupts at all. The hardware just won't work if you try. NEWCARD tries to kick the cardbus bridge into full PCI mode, where you can share interrupts, since all the interrupts are going through the PCI hardware chain which does support interrupt sharing. Warner [*] Special, oddball cards can be made to support sharing. Those aren't relevant here because pcic bridges and the like aren't oddball. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On Mon, Feb 05, 2001 at 02:51:59PM -0800, John Baldwin wrote:
On 05-Feb-01 Crist J. Clark wrote:
I don't recall reports of trouble with recent CURRENT, but my CVSup
from yesterday afternoon is panicing. Before I try too debug this, has
anyone been getting these or knows what I might be missing?
Boot messages and the panic info are attached.
Could you please turn on DDB, WITNESS, and INVARIANTS in your kernel and see if
you can reproduce this? Also, compile the kernel with debug symbols. Then
type 'trace' at the db prompt when it does to get a backtrace of where it blew
up. Thanks.
OK. The boot messages and debug output is attachment one, the kernel
config is second. For the record, I have not made any changes to the
kernel; fresh CVSup.
--
Crist J. Clark [EMAIL PROTECTED]
Copyright (c) 1992-2001 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.0-CURRENT #2: Mon Feb 5 23:59:09 PST 2001
[EMAIL PROTECTED]:/usr/obj/export/current/src/sys/BUBBLES
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium/P54C (132.96-MHz 586-class CPU)
Origin = "GenuineIntel" Id = 0x52b Stepping = 11
Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8
real memory = 33554432 (32768K bytes)
avail memory = 30015488 (29312K bytes)
Preloaded elf kernel "kernel.BUBBLES" at 0xc02c5000.
Intel Pentium detected, installing workaround for F00F bug
apm0: APM BIOS on motherboard
apm0: found APM BIOS v1.1, connected at v1.1
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Host to PCI bridge at pcibus 0 on motherboard
pci0: PCI bus on pcib0
isab0: PCI-ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
pci0: display, VGA at 8.0 (no driver attached)
ep0: 3Com 3C509-TP EtherLink III at port 0x300-0x30f irq 10 on isa0
ep0: Ethernet address 00:20:af:17:a3:e9
ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0
fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5" drive on fdc0 drive 0
ppc0: Parallel port at port 0x3bc-0x3c3 irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
plip0: PLIP network interface on ppbus0
lpt0: Printer on ppbus0
lpt0: Interrupt-driven port
ppi0: Parallel I/O on ppbus0
ppc1: cannot reserve I/O port range
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A, console
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
sio2 at port 0x3e8-0x3ef irq 5 on isa0
sio2: type 16550A
unknown: PNP0700 can't assign resources
unknown: PNP0400 can't assign resources
unknown: PNP0501 can't assign resources
unknown: PNP0501 can't assign resources
unknown: PNP0680 can't assign resources
IP packet filtering initialized, divert enabled, rule-based forwarding disabled,
default to deny, logging limited to 1000 packets/entry by default
ad0: 1222MB QUANTUM FIREBALL1280A [2484/16/63] at ata0-master BIOSPIO
acd0: CDROM CD-532E-A at ata0-slave using BIOSPIO
Mounting root from ufs:/dev/ad0s1a
kernel trap 9 with interrupts disabled
panic: mutex sched lock recursed at /export/current/src/sys/kern/kern_synch.c:918
Debugger("panic")
Stopped at Debugger+0x44: pushl %ebx
db trace
Debugger(c0215a83) at Debugger+0x44
panic(c02148a2,c022fc69,c02160a0,396,c0823f00) at panic+0x70
_mtx_assert(c0278140,9,c02160a0,396,c0823f00) at _mtx_assert+0x63
mi_switch(c3611b80,20,9,c3a29f08,c01f2a6d) at mi_switch+0x25
sched_ithd(e) at sched_ithd+0xd9
Xresume14() at Xresume14+0x8
--- interrupt, eip = 0x8, esp = 0xc3a29ee4, ebp = 0xc3a29ed4 ---
(null)(c01fcd58,8,80286,c02781a0,20) at 0x8
db
# $Id: BUBBLES,v 1.4 2001/02/04 06:49:24 cjc Exp cjc $
#
# BUBBLES - 2000/11/11, cjc
#
# Kernel configuration for IBM Pentium 133
#
# 2000/12/09, cjc - DEVEL became BUBBLES
#
machine i386
cpu I586_CPU
ident BUBBLES
maxusers32
#To statically compile in device wiring instead of /boot/device.hints
#hints "GENERIC.hints" #Default places to look for devices.
#makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols
options WITNESS
options INVARIANTS
options DDB
options INET#InterNETworking
options INET6 #IPv6 communications protocols
options FFS #Berkeley Fast Filesystem
#optionsFFS_ROOT#FFS usable as root device [keep this!]
options SOFTUPDATES #Enable FFS soft updates support
#optionsDEVFS #Device Filesystem
options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!]
options UCONSOLE#Allow users to grab the console
options KTRACE #ktrace(1) support
options SYSVSHM #SYSV-style shared memory
options SYSVMSG
Re: Kernel Panic from Yesterday's CVSup
On Mon, Feb 05, 2001 at 08:46:42PM -0800, John Baldwin wrote:
On 06-Feb-01 Andrea Campi wrote:
Sorry to bother everybody, but did anybody note from my panic trace,
that instruction pointer is 0xdeadc0de? Isn't that bad? :-p
That means it is free'd memory. One cause might be something that is free'ing
its interrupt handler w/o releasing it properly. Alternatively, it might be a
Ok, can't help with the rest of your answer, but I'd like to help debug if the
issue is here.
Problem: I can't do anything at db prompt? Backtrace is doing nothing except
triggering a new register dump (another fault I assume).
Anyway, I'm using:
device card
device pcic
device ep
I started looking around in src/sys/dev/{ep,pccard,pcic}/* for recent changes
that could have caused it, but I soon got lost... :(
What should I try? I can go back to an earlier kernel (via cvs compile, sadly
I don't have any old working kernel anymore), but I'd have to first understand
how far back I can go without getting out of sync between kernel world...
Meanwhile, I'll try the latest kernel, and also cardbus to see if the results
are different in any way...
Bye,
Andrea
--
Intel: where Quality is job number 0.9998782345!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Problem: I can't do anything at db prompt? Backtrace is doing nothing except triggering a new register dump (another fault I assume). New kernel, new panic, new info: db witness_list "Giant" (0xc0279be0) locked at ../../i386/isa/ithread.c:191 db show registers cs 0x8 ds 0x10 es 0x10 fs 0x18 ss 0x10 eax 0xdeadc0de ecx 0xc59eb4b4 edx 0xc0279be0 Giant ebx 0xc0a7a480 _end+0x36f8 esp 0xc65faf68 ebp 0xc65faf78 esi 0xc0a7a4e0 _end+0x3758 edi 0xc01fc998 ithd_loop eax 0xdeadc0de efl 0x10282 Besides the obvious need to fix this one problem, shouldn't we ASSERT ih-ih_handler != NULL before calling it? Bye, Andrea -- Reboot America. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
The line where I was having the trap is still within cpu_switch (line 236 of swtch.s). I added WITNESS and INVARIANTS to my kernel and I get a new panic. This time I see: kernel trap 12 with interrupts disabled panic: mutex sched lock recursed at ../../kern/kern_synch.c:918 panic() _mtx_assert(c031b6c0,9,c0290990,396,c043b100) at _mtx_assert+0x63 mi_switch(c031b6c0,0,c,c24bef08,c02681cd) at mi_switch+0x25 sched_ithd(e) at sched_ithd+0xd9 Xresume14() at Xresume14+0x8 --- interrupt, eip = 0xc02b0008, esp - 0xc2fbeee4, epb = 0xc2feed4 --- __set_sysinit_set_sym_sc_mem_sys_init(c0275020,c02b0008,286,c031b7230,0) at __set_sysinit_set_sym_sc_mem_sys_init+0x644 Jim Bloom [EMAIL PROTECTED] PS: Here is the original message. It was cut and pasted from the logs since your message is sitting in another OS on a dual boot machine. On 06-Feb-01 Jim Bloom wrote: I have seen both a trap 12 and a trap 9 from a Friday Feb. 2 kernel. This is occuring on my laptop (AST Ascentia 810N) which I can't seem to get to create a core dump. Here is a hand transcription of what I see. Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc0270ad8 stack pointer = 0x10:0xc2fb4f50 frame pointer = 0x10:0xc2fb4f64 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 16 (irq14:ata0) kernel: type 9 trap, code=0 Stopped at sw1b+0x77: ltr %si backtrace sw1b(4000) at sw1b+0x77 (note this is actually swtch()) Actually, this is beyond the end of cpu_switch I think. You are effectively off in lala land. ithd_loop(0,c2fb4fa8) at ithd_loop+0xf7 This is either in the mtx_enter of Giant or in the interrupt handler itself. I'm betting an interrupt handler isn't being setup properly one way or another, and that the code is jumping through a bogus pointer and ending up in lala land executing random code. fork_exit(c0275bd0,0,c2fb4fa8_ at fork_exit+0x2d fork_trampoline() at fork_trampoline+0x8 I don't have WITNESS or INVARIANTS at this time and don;t have a serial console so I can't capture the output. These help to capture bugs by doing extra checks though, and especially with current they are highly, highly, highly recommended right now. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 06-Feb-01 Crist J. Clark wrote: On Mon, Feb 05, 2001 at 02:51:59PM -0800, John Baldwin wrote: On 05-Feb-01 Crist J. Clark wrote: I don't recall reports of trouble with recent CURRENT, but my CVSup from yesterday afternoon is panicing. Before I try too debug this, has anyone been getting these or knows what I might be missing? Boot messages and the panic info are attached. Could you please turn on DDB, WITNESS, and INVARIANTS in your kernel and see if you can reproduce this? Also, compile the kernel with debug symbols. Then type 'trace' at the db prompt when it does to get a backtrace of where it blew up. Thanks. OK. The boot messages and debug output is attachment one, the kernel config is second. For the record, I have not made any changes to the kernel; fresh CVSup. ARGH. The trap code is breaking this. We are getting a trap with interrupts disabled because we have hit a bug while holding a spin mutex. The handy-dandy trap code then enables interrupts for us which allows an interrupt to come in and blow up recursing on sched_lock and obscuring the previous trap. That, and it looks like ddb can't follow back through an interrupt trace properly. Can you edit src/sys/i386/i386/trap.c and comment out the 'enable_intr()' with the nasty comment above it about spin mutexes in trap(): /* * We should walk p_heldmtx here and see if any are * spin mutexes, and not do this if so. */ enable_intr(); } Just comment out that enable_intr() and please try again. This should give you a stack trace where the actual bug is. Thanks. -- 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: Kernel Panic from Yesterday's CVSup
On 06-Feb-01 Jim Bloom wrote: The line where I was having the trap is still within cpu_switch (line 236 of swtch.s). I added WITNESS and INVARIANTS to my kernel and I get a new panic. This time I see: kernel trap 12 with interrupts disabled panic: mutex sched lock recursed at ../../kern/kern_synch.c:918 panic() _mtx_assert(c031b6c0,9,c0290990,396,c043b100) at _mtx_assert+0x63 mi_switch(c031b6c0,0,c,c24bef08,c02681cd) at mi_switch+0x25 sched_ithd(e) at sched_ithd+0xd9 Xresume14() at Xresume14+0x8 --- interrupt, eip = 0xc02b0008, esp - 0xc2fbeee4, epb = 0xc2feed4 --- __set_sysinit_set_sym_sc_mem_sys_init(c0275020,c02b0008,286,c031b7230,0) at __set_sysinit_set_sym_sc_mem_sys_init+0x644 Jim Bloom [EMAIL PROTECTED] Hm, can you show the registers? I wonder if we are somehow running a process that isn't fully created yet. Hmm, that shouldn't be a problem looking at fork1().. -- 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: Kernel Panic from Yesterday's CVSup
On 06-Feb-01 Andrea Campi wrote: Problem: I can't do anything at db prompt? Backtrace is doing nothing except triggering a new register dump (another fault I assume). New kernel, new panic, new info: db witness_list "Giant" (0xc0279be0) locked at ../../i386/isa/ithread.c:191 db show registers cs 0x8 ds 0x10 es 0x10 fs 0x18 ss 0x10 eax 0xdeadc0de ecx 0xc59eb4b4 edx 0xc0279be0 Giant ebx 0xc0a7a480 _end+0x36f8 esp 0xc65faf68 ebp 0xc65faf78 esi 0xc0a7a4e0 _end+0x3758 edi 0xc01fc998 ithd_loop eax 0xdeadc0de efl 0x10282 Besides the obvious need to fix this one problem, shouldn't we ASSERT ih-ih_handler != NULL before calling it? It isn't null in this case, it is 0xdeadc0de. Can you try a pre-preemption kernel and see if that fixes it? Bye, Andrea -- 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: Kernel Panic from Yesterday's CVSup
In message [EMAIL PROTECTED] Andrea Campi writes: : Problem: I can't do anything at db prompt? Backtrace is doing nothing except : triggering a new register dump (another fault I assume). I'm having all kinds of issues with -current and pccards. OLDCARD hangs solid when I remove a card. Newcard randomly does weird things. If you want stability, I'd strongly advise running -stable for the next few months on your laptop. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Here are the registers (subject to typing errors): cs 0xc2fb0008 ds 0xa10 es0x10 fs0x18 ss0x10 eax 0x12 ecx 0x20 edx 0xc00b8f00 ebx0x2 esp 0xc2fbee1c ebp 0xc2fbee28 esi 0x100 edi 0xc0290990 __set_sysctl_set_sym_sysctl__kern_fscale+0x4 eip 0xc0266fcc Debugger+44 efl 0x56 Jim Bloom [EMAIL PROTECTED] John Baldwin wrote: On 06-Feb-01 Jim Bloom wrote: The line where I was having the trap is still within cpu_switch (line 236 of swtch.s). I added WITNESS and INVARIANTS to my kernel and I get a new panic. This time I see: kernel trap 12 with interrupts disabled panic: mutex sched lock recursed at ../../kern/kern_synch.c:918 panic() _mtx_assert(c031b6c0,9,c0290990,396,c043b100) at _mtx_assert+0x63 mi_switch(c031b6c0,0,c,c24bef08,c02681cd) at mi_switch+0x25 sched_ithd(e) at sched_ithd+0xd9 Xresume14() at Xresume14+0x8 --- interrupt, eip = 0xc02b0008, esp - 0xc2fbeee4, epb = 0xc2feed4 --- __set_sysinit_set_sym_sc_mem_sys_init(c0275020,c02b0008,286,c031b7230,0) at __set_sysinit_set_sym_sc_mem_sys_init+0x644 Jim Bloom [EMAIL PROTECTED] Hm, can you show the registers? I wonder if we are somehow running a process that isn't fully created yet. Hmm, that shouldn't be a problem looking at fork1().. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 06-Feb-01 Jim Bloom wrote: Here are the registers (subject to typing errors): cs0xc2fb0008 ds 0xa10 es 0x10 fs 0x18 ss 0x10 eax 0x12 ecx 0x20 edx 0xc00b8f00 ebx 0x2 esp 0xc2fbee1c ebp 0xc2fbee28 esi0x100 edi 0xc0290990 __set_sysctl_set_sym_sysctl__kern_fscale+0x4 eip 0xc0266fcc Debugger+44 efl 0x56 Jim Bloom [EMAIL PROTECTED] Erm, this doesn't look good: movl$GPROC0_SEL*8, %esi /* GSEL(entry, SEL_KPL) */ ltr %si #define GPROC0_SEL 4 /* Task state process slot zero and up */ Thus, %esi should be 32 == 0x20, not 0x100. :( I have no clue why that is screwed up, unless something is overwriting your code segment. Can you panic it and do an x/i of sw1b+0x72? It should look something like this: 121: be 20 00 00 00 mov$0x20,%esi 126: 0f 00 deltr%si -- 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: Kernel Panic from Yesterday's CVSup
Which kernel do you want me to try this with? I have tried two different kernels with two different errors. (Both have been sent at different times in the past couple days.) The registers listed here from the second kernel (with WITNESS, INVARIANTS, INVARIANT_SUPPORT, MUTEX_DEBUG). As such the addresses disagree (sw1b has 8 more bytes for invariants), but the text segment was correct. Without debug, I get the trap 9. With debug, I get a trap 12 immediately followed by a panic with mutex shced lock recursion. I rebuilt the kernel with out the debugging and check the state of things. The code is correct and the esi register had the expected value. Jim Bloom [EMAIL PROTECTED] P.S. I am hitting the same problem Robert Watson mentioned. I don't have room for three kernels on the machine. John Baldwin wrote: On 06-Feb-01 Jim Bloom wrote: Here are the registers (subject to typing errors): cs0xc2fb0008 ds 0xa10 es 0x10 fs 0x18 ss 0x10 eax 0x12 ecx 0x20 edx 0xc00b8f00 ebx 0x2 esp 0xc2fbee1c ebp 0xc2fbee28 esi0x100 edi 0xc0290990 __set_sysctl_set_sym_sysctl__kern_fscale+0x4 eip 0xc0266fcc Debugger+44 efl 0x56 Jim Bloom [EMAIL PROTECTED] Erm, this doesn't look good: movl$GPROC0_SEL*8, %esi /* GSEL(entry, SEL_KPL) */ ltr %si #define GPROC0_SEL 4 /* Task state process slot zero and up */ Thus, %esi should be 32 == 0x20, not 0x100. :( I have no clue why that is screwed up, unless something is overwriting your code segment. Can you panic it and do an x/i of sw1b+0x72? It should look something like this: 121: be 20 00 00 00 mov$0x20,%esi 126: 0f 00 deltr%si To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Besides the obvious need to fix this one problem, shouldn't we ASSERT ih-ih_handler != NULL before calling it? It isn't null in this case, it is 0xdeadc0de. Can you try a pre-preemption kernel and see if that fixes it? *BLUSH* Of course ehehe ;-) Ok, I will. Can you give me a date I should try going back to, without kernel getting out of sync with my world? Bye, Andrea -- Yes, I've heard of "decaf." What's your point? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 06-Feb-01 Jim Bloom wrote: Which kernel do you want me to try this with? I have tried two different kernels with two different errors. (Both have been sent at different times in the past couple days.) The registers listed here from the second kernel (with WITNESS, INVARIANTS, INVARIANT_SUPPORT, MUTEX_DEBUG). As such the addresses disagree (sw1b has 8 more bytes for invariants), but the text segment was correct. You'll have to turn off WITNESS to get it to die in cpu_switch(), but you'll want to leave the others on for now. Without debug, I get the trap 9. With debug, I get a trap 12 immediately followed by a panic with mutex shced lock recursion. I rebuilt the kernel with out the debugging and check the state of things. The code is correct and the esi register had the expected value. H. Ok, try with debugging minus WITNESS (and you don't want MUTEX_DEBUG, that slows things down a _lot_). Then see if %esi is still 0x100 instead of 0x20. If so, then check the instructions to make sure they aren't hosed. P.S. I am hitting the same problem Robert Watson mentioned. I don't have room for three kernels on the machine. Yes. :( The default / size for -current is not very good, as development boxes need more room on / than production boxes. -- 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: Kernel Panic from Yesterday's CVSup
On 06-Feb-01 Andrea Campi wrote: Besides the obvious need to fix this one problem, shouldn't we ASSERT ih-ih_handler != NULL before calling it? It isn't null in this case, it is 0xdeadc0de. Can you try a pre-preemption kernel and see if that fixes it? *BLUSH* Of course ehehe ;-) Ok, I will. Can you give me a date I should try going back to, without kernel getting out of sync with my world? Umm, this is the commit you want to be before: jake2001/01/31 19:34:21 PST Modified files: sys/alpha/alpha interrupt.c machdep.c sys/i386/isa ithread.c npx.c Log: Implement preemptive scheduling of hardware interrupt threads. ... A kernel on the 30th or so should work fine with an up to date world. -- 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: Kernel Panic from Yesterday's CVSup
On Tue, Feb 06, 2001 at 11:02:32AM -0800, John Baldwin wrote:
[snip]
ARGH. The trap code is breaking this.
[snip]
Just comment out that enable_intr() and please try again. This should give you
a stack trace where the actual bug is. Thanks.
Done. And the winner is... (see attachment, did not repeat the kernel
config since it has not changed)
--
Crist J. Clark [EMAIL PROTECTED]
Copyright (c) 1992-2001 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.0-CURRENT #3: Tue Feb 6 13:59:53 PST 2001
[EMAIL PROTECTED]:/usr/obj/export/current/src/sys/BUBBLES
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium/P54C (132.96-MHz 586-class CPU)
Origin = "GenuineIntel" Id = 0x52b Stepping = 11
Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8
real memory = 33554432 (32768K bytes)
avail memory = 30015488 (29312K bytes)
Preloaded elf kernel "kernel.BUBBLES" at 0xc02c5000.
Intel Pentium detected, installing workaround for F00F bug
apm0: APM BIOS on motherboard
apm0: found APM BIOS v1.1, connected at v1.1
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Host to PCI bridge at pcibus 0 on motherboard
pci0: PCI bus on pcib0
isab0: PCI-ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
pci0: display, VGA at 8.0 (no driver attached)
ep0: 3Com 3C509-TP EtherLink III at port 0x300-0x30f irq 10 on isa0
ep0: Ethernet address 00:20:af:17:a3:e9
ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0
fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5" drive on fdc0 drive 0
ppc0: Parallel port at port 0x3bc-0x3c3 irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
plip0: PLIP network interface on ppbus0
lpt0: Printer on ppbus0
lpt0: Interrupt-driven port
ppi0: Parallel I/O on ppbus0
ppc1: cannot reserve I/O port range
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A, console
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
sio2 at port 0x3e8-0x3ef irq 5 on isa0
sio2: type 16550A
unknown: PNP0700 can't assign resources
unknown: PNP0400 can't assign resources
unknown: PNP0501 can't assign resources
unknown: PNP0501 can't assign resources
unknown: PNP0680 can't assign resources
IP packet filtering initialized, divert enabled, rule-based forwarding disabled,
default to deny, logging limited to 1000 packets/entry by default
ad0: 1222MB QUANTUM FIREBALL1280A [2484/16/63] at ata0-master BIOSPIO
acd0: CDROM CD-532E-A at ata0-slave using BIOSPIO
Mounting root from ufs:/dev/ad0s1a
kernel trap 9 with interrupts disabled
panic: blockable mtx_enter() of Giant when not legal @
/export/current/src/sys/i386/i386/trap.c:653
Debugger("panic")
Stopped at Debugger+0x44: pushl %ebx
db trace
Debugger(c0215a83) at Debugger+0x44
panic(c0214bc0,c022fc74,c0230820,28d,c02782e0) at panic+0x70
witness_enter(c02782e0,0,c0230820,28d,0) at witness_enter+0x1d9
_mtx_enter(c02782e0,0,c0230820,28d,c02781a0) at _mtx_enter+0x106
trap(18,10,10,c3612a60,20) at trap+0x583
calltrap() at calltrap+0x5
--- trap 0x9, eip = 0xc01fc642, esp = 0xc3a29f50, ebp = 0xc3a29f64 ---
sw1b(4000) at sw1b+0x81
ithd_loop(0,c3a29fa8) at ithd_loop+0x10d
fork_exit(c0200d94,0,c3a29fa8) at fork_exit+0x2d
fork_trampoline() at fork_trampoline+0x8
db
Re: Kernel Panic from Yesterday's CVSup
John Baldwin wrote: On 06-Feb-01 Jim Bloom wrote: Which kernel do you want me to try this with? I have tried two different kernels with two different errors. (Both have been sent at different times in the past couple days.) The registers listed here from the second kernel (with WITNESS, INVARIANTS, INVARIANT_SUPPORT, MUTEX_DEBUG). As such the addresses disagree (sw1b has 8 more bytes for invariants), but the text segment was correct. You'll have to turn off WITNESS to get it to die in cpu_switch(), but you'll want to leave the others on for now. I turned off WITNESS and still received the mutex error. A little reading of the code showed that mutex assertions are inclued with ifdef INVARIANTS. Without debug, I get the trap 9. With debug, I get a trap 12 immediately followed by a panic with mutex shced lock recursion. I rebuilt the kernel with out the debugging and check the state of things. The code is correct and the esi register had the expected value. H. Ok, try with debugging minus WITNESS (and you don't want MUTEX_DEBUG, that slows things down a _lot_). Then see if %esi is still 0x100 instead of 0x20. If so, then check the instructions to make sure they aren't hosed. With INVARIANTS turned off and WITNESS on, I received a trap 27 (stack fault) at sw1b+0x77. The instructions are fine and %esi was 0x20 as it should be. I won't worry about MUTEX_DEBUG being slow just yet. I am only around the start of /etc/rc when the machine dies. Do you have any other ideas on things that I can try to diagnose this problem? Jim Bloom [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 07-Feb-01 Crist J. Clark wrote: On Tue, Feb 06, 2001 at 11:02:32AM -0800, John Baldwin wrote: [snip] ARGH. The trap code is breaking this. [snip] Just comment out that enable_intr() and please try again. This should give you a stack trace where the actual bug is. Thanks. Done. And the winner is... (see attachment, did not repeat the kernel config since it has not changed) Well, can't win with WITNESS here. :) It is still panic'ing on the 'ltr' though. Hmm, oh. ARgh. It's showing the regs from teh most recent panic probably. *sigh* Just turn off WITNESS altogether. It is getting in our way in this particular instance. Sorry for the numerous bounces back and forth. -- 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: Kernel Panic from Yesterday's CVSup
On 07-Feb-01 Jim Bloom wrote: John Baldwin wrote: On 06-Feb-01 Jim Bloom wrote: Which kernel do you want me to try this with? I have tried two different kernels with two different errors. (Both have been sent at different times in the past couple days.) The registers listed here from the second kernel (with WITNESS, INVARIANTS, INVARIANT_SUPPORT, MUTEX_DEBUG). As such the addresses disagree (sw1b has 8 more bytes for invariants), but the text segment was correct. You'll have to turn off WITNESS to get it to die in cpu_switch(), but you'll want to leave the others on for now. I turned off WITNESS and still received the mutex error. A little reading of the code showed that mutex assertions are inclued with ifdef INVARIANTS. Without debug, I get the trap 9. With debug, I get a trap 12 immediately followed by a panic with mutex shced lock recursion. I rebuilt the kernel with out the debugging and check the state of things. The code is correct and the esi register had the expected value. H. Ok, try with debugging minus WITNESS (and you don't want MUTEX_DEBUG, that slows things down a _lot_). Then see if %esi is still 0x100 instead of 0x20. If so, then check the instructions to make sure they aren't hosed. With INVARIANTS turned off and WITNESS on, I received a trap 27 (stack fault) at sw1b+0x77. The instructions are fine and %esi was 0x20 as it should be. I won't worry about MUTEX_DEBUG being slow just yet. I am only around the start of /etc/rc when the machine dies. A stack fault on 'ltr'? Hmm... leeching from teh 386 manual on ltr: Protected Mode Exceptions #GP(0) for an illegal memory operand effective address in the CS, DS, ES, FS, or GS segments; #SS(0) for an illegal address in the SS segment; #GP(0) if the current privilege level is not 0; #GP(selector) if the object named by the source selector is not a TSS or is already busy; #NP(selector) if the TSS is marked "not present"; #PF(fault-code) for a page fault Hmm, so our %ss selector must be invalid in the new TSS. h0h0. Ok, umm. I have no idea how that happened. AFAIK, that shouldn't be touched once the system is up and running. :( So, probably something is trashing it by walking off a dead pointer or some such. :( Do you have any other ideas on things that I can try to diagnose this problem? Right now, no. I know of one potential problem child with preemption: the interrupt thread list handling, and I'm overhauling the ithread code right now so I can try and fix that. Jim Bloom [EMAIL PROTECTED] -- 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: Kernel Panic from Yesterday's CVSup
On 05-Feb-01 Crist J. Clark wrote: I don't recall reports of trouble with recent CURRENT, but my CVSup from yesterday afternoon is panicing. Before I try too debug this, has anyone been getting these or knows what I might be missing? Boot messages and the panic info are attached. Could you please turn on DDB, WITNESS, and INVARIANTS in your kernel and see if you can reproduce this? Also, compile the kernel with debug symbols. Then type 'trace' at the db prompt when it does to get a backtrace of where it blew up. Thanks. -- 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: Kernel Panic from Yesterday's CVSup
I have seen both a trap 12 and a trap 9 from a Friday Feb. 2 kernel. This is occuring on my laptop (AST Ascentia 810N) which I can't seem to get to create a core dump. Here is a hand transcription of what I see. Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc0270ad8 stack pointer = 0x10:0xc2fb4f50 frame pointer = 0x10:0xc2fb4f64 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 16 (irq14:ata0) kernel: type 9 trap, code=0 Stopped at sw1b+0x77: ltr %si backtrace sw1b(4000) at sw1b+0x77 (note this is actually swtch()) ithd_loop(0,c2fb4fa8) at ithd_loop+0xf7 fork_exit(c0275bd0,0,c2fb4fa8_ at fork_exit+0x2d fork_trampoline() at fork_trampoline+0x8 I don't have WITNESS or INVARIANTS at this time and don;t have a serial console so I can't capture the output. I can try adding these to my kernel and transcribe a little bit by hand. I can also send my kernel config and dmesg from a Nov kernel which boots. Jim Bloom [EMAIL PROTECTED] John Baldwin wrote: On 05-Feb-01 Crist J. Clark wrote: I don't recall reports of trouble with recent CURRENT, but my CVSup from yesterday afternoon is panicing. Before I try too debug this, has anyone been getting these or knows what I might be missing? Boot messages and the panic info are attached. Could you please turn on DDB, WITNESS, and INVARIANTS in your kernel and see if you can reproduce this? Also, compile the kernel with debug symbols. Then type 'trace' at the db prompt when it does to get a backtrace of where it blew up. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Sorry to bother everybody, but did anybody note from my panic trace, that instruction pointer is 0xdeadc0de? Isn't that bad? :-p On Mon, Feb 05, 2001 at 08:27:19PM -0500, Jim Bloom wrote: I have seen both a trap 12 and a trap 9 from a Friday Feb. 2 kernel. This is occuring on my laptop (AST Ascentia 810N) which I can't seem to get to create a core dump. Here is a hand transcription of what I see. Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc0270ad8 stack pointer = 0x10:0xc2fb4f50 frame pointer = 0x10:0xc2fb4f64 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 16 (irq14:ata0) kernel: type 9 trap, code=0 Stopped at sw1b+0x77: ltr %si backtrace sw1b(4000) at sw1b+0x77 (note this is actually swtch()) ithd_loop(0,c2fb4fa8) at ithd_loop+0xf7 fork_exit(c0275bd0,0,c2fb4fa8_ at fork_exit+0x2d fork_trampoline() at fork_trampoline+0x8 I don't have WITNESS or INVARIANTS at this time and don;t have a serial console so I can't capture the output. I can try adding these to my kernel and transcribe a little bit by hand. I can also send my kernel config and dmesg from a Nov kernel which boots. Jim Bloom [EMAIL PROTECTED] John Baldwin wrote: On 05-Feb-01 Crist J. Clark wrote: I don't recall reports of trouble with recent CURRENT, but my CVSup from yesterday afternoon is panicing. Before I try too debug this, has anyone been getting these or knows what I might be missing? Boot messages and the panic info are attached. Could you please turn on DDB, WITNESS, and INVARIANTS in your kernel and see if you can reproduce this? Also, compile the kernel with debug symbols. Then type 'trace' at the db prompt when it does to get a backtrace of where it blew up. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Speak softly and carry a cellular phone. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On 06-Feb-01 Jim Bloom wrote: I have seen both a trap 12 and a trap 9 from a Friday Feb. 2 kernel. This is occuring on my laptop (AST Ascentia 810N) which I can't seem to get to create a core dump. Here is a hand transcription of what I see. Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc0270ad8 stack pointer = 0x10:0xc2fb4f50 frame pointer = 0x10:0xc2fb4f64 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 16 (irq14:ata0) kernel: type 9 trap, code=0 Stopped at sw1b+0x77: ltr %si backtrace sw1b(4000) at sw1b+0x77 (note this is actually swtch()) Actually, this is beyond the end of cpu_switch I think. You are effectively off in lala land. ithd_loop(0,c2fb4fa8) at ithd_loop+0xf7 This is either in the mtx_enter of Giant or in the interrupt handler itself. I'm betting an interrupt handler isn't being setup properly one way or another, and that the code is jumping through a bogus pointer and ending up in lala land executing random code. fork_exit(c0275bd0,0,c2fb4fa8_ at fork_exit+0x2d fork_trampoline() at fork_trampoline+0x8 I don't have WITNESS or INVARIANTS at this time and don;t have a serial console so I can't capture the output. These help to capture bugs by doing extra checks though, and especially with current they are highly, highly, highly recommended right now. -- 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: Kernel Panic from Yesterday's CVSup
On 06-Feb-01 Andrea Campi wrote: Sorry to bother everybody, but did anybody note from my panic trace, that instruction pointer is 0xdeadc0de? Isn't that bad? :-p That means it is free'd memory. One cause might be something that is free'ing its interrupt handler w/o releasing it properly. Alternatively, it might be a race in the interrupt list code that was been brought about by preemption. Since locks are rather expensive, we have avoided locking the list of interrupt handlers in the past, but we may have to break down and do that now. :( This will hurt interrupt latency unless I can figure out a slick way of fixing it. Can anyone confirm that a pre-preemption kernel works fine for them? -- 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: Kernel Panic from Yesterday's CVSup
John Baldwin said: On 06-Feb-01 Andrea Campi wrote: Sorry to bother everybody, but did anybody note from my panic trace, that instruction pointer is 0xdeadc0de? Isn't that bad? :-p That means it is free'd memory. One cause might be something that is free'ing its interrupt handler w/o releasing it properly. Alternatively, it might be a race in the interrupt list code that was been brought about by preemption. Since locks are rather expensive, we have avoided locking the list of interrupt handlers in the past, but we may have to break down and do that now. :( This will hurt interrupt latency unless I can figure out a slick way of fixing it. Can anyone confirm that a pre-preemption kernel works fine for them? I have 2 SMP boxes (one with pentium 200MMX's, the other with PPro 233's. There are other differences in peripherals). Both boxes run an identical build of a kernel dating to sun 4th feb. The PPro is rock-stable. The PentiumMMX is very fragile, and will panic easily (often in vm_fault) with a sig9 (IIRC). M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel Panic from Yesterday's CVSup
I don't recall reports of trouble with recent CURRENT, but my CVSup from yesterday afternoon is panicing. Before I try too debug this, has anyone been getting these or knows what I might be missing? Boot messages and the panic info are attached. -- Crist J. Clark [EMAIL PROTECTED] Copyright (c) 1992-2001 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.0-CURRENT #1: Sun Feb 4 20:09:00 PST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BUBBLES Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P54C (132.96-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52b Stepping = 11 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 real memory = 33554432 (32768K bytes) avail memory = 30130176 (29424K bytes) Preloaded elf kernel "kernel" at 0xc02a9000. Intel Pentium detected, installing workaround for F00F bug apm0: APM BIOS on motherboard apm0: found APM BIOS v1.1, connected at v1.1 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 pci0: display, VGA at 8.0 (no driver attached) ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 ppc0: Parallel port at port 0x3bc-0x3c3 irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 ppc1: cannot reserve I/O port range sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2 at port 0x3e8-0x3ef irq 5 on isa0 sio2: type 16550A ep0: 3Com 3C509-TP EtherLink III at port 0x300-0x30f irq 10 on isa0 ep0: Ethernet address 00:20:af:17:a3:e9 unknown: PNP0700 can't assign resources unknown: PNP0400 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0680 can't assign resources IP packet filtering initialized, divert enabled, rule-based forwarding disabled, default to deny, logging limited to 1000 packets/entry by default ad0: 1222MB QUANTUM FIREBALL1280A [2484/16/63] at ata0-master BIOSPIO acd0: CDROM CD-532E-A at ata0-slave using BIOSPIO Mounting root from ufs:/dev/ad0s1a kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0xe fault code = supervisor read, page not present instruction pointer = 0x8:0xc01f2553 stack pointer = 0x10:0xc3a2bf50 frame pointer = 0x10:0xc3a2bf64 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 16 (irq14: ata0) trap number = 12 panic: page fault syncing disks... done Uptime: 0s Automatic reboot in 15 seconds - press a key on the console to abort -- Press a key on the console to reboot -- # $Id: BUBBLES,v 1.4 2001/02/04 06:49:24 cjc Exp cjc $ # # BUBBLES - 2000/11/11, cjc # # Kernel configuration for IBM Pentium 133 # # 2000/12/09, cjc - DEVEL became BUBBLES # machine i386 cpu I586_CPU ident BUBBLES maxusers32 #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" #Default places to look for devices. #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support #optionsDEVFS #Device Filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options UCONSOLE#Allow users to grab the console options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING #optionsKBD_INSTALL_CDEV# install a CDEV entry in /dev device isa device pci #optionsCOMPAT_OLDISA # compatability shims for lnc, le #optionsCOMPAT_OLDPCI # compatability shims for lnc # Floppy drives device fdc
