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
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.
Coul
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 inser
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
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
> pcc
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. A
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 handl
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 mig
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 some
> 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
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_asser
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
>> > an
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
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/ithr
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. Newc
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
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
>
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
> > 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 da
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, INVARI
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
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,
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 (
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
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 li
> > 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
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,
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+0x4
> 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
> Debu
> > 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
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:
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: mall
> 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
> 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 g
>
> 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 t
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
>>
>
> 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 cra
> 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 th
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 he
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, how
> > 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 y
> 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
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.
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,c6623f
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 no
> 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
>
> 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
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
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.
--
Jo
> > 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 [E
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
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
> : 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'
53 matches
Mail list logo
