John Baldwin wrote:
> On 22-Feb-01 Maxim Sobolev wrote:
> > John Baldwin wrote:
> >
> >> On 22-Feb-01 Maxim Sobolev wrote:
> >> > Dag-Erling Smorgrav wrote:
> >> >
> >> >> Maxim Sobolev <[EMAIL PROTECTED]> writes:
> >> >> > It's not an ata specific problem, but rather a problem of all ISA
> >> >> > devices (I have an ISA based ata controller).
> >> >>
> >> >> I don't think it has anything to do with ISA. I've had similar
> >> >> problems on a PCI-only system (actually, PCI+EISA motherboard with no
> >> >> EISA cards) with no ATA devices (disks, CD-ROM and streamer are all
> >> >> SCSI).
> >> >>
> >> >> Considering that backing out rev 1.14 of ithread.c eliminates the
> >> >> panics, and that that revision is supposed to enable interrupt thread
> >> >> preemption, and that the crashed kernels show signs of stack smashing,
> >> >> I'd say the cause is probably a bug in the preemption code.
> >> >
> >> > Update: the bug is still here, as of -current from 22 Feb. Hovewer, this
> >> > time
> >> > it even doesn't let to boot into single-user with following panic message:
> >> > kernel trap 12 with interrupts disabled
> >> > panic: mutex sched lock recursed at ../../kern/kern_synch.c:872
> >>
> >> Errrr. That would be something that is leaking sched_lock. Hmm...
> >>
> >> Got a backtrace? What is really annoying is that preemption has been in the
> >> kernel since Feb 1. I just accidentally turned it off in the ithread code
> >> reorganization and then turned it back on. It was off for a few hours after
> >> only being on for 2 weeks, and now everyone magically has problems.
> >
> > Here it is (from DDB):
> > panic(c027de93,c0297409,c027f878,368,80286)
> > _mtx_assert(c02ea000,9,c027f878,368,80286)
> > mi_switch(c32c5da0,3,c02cea44,c357be98)
> > ithread_schedule(c0747c00,1)
> > sched_ithd(e)
> > Xresume14()
> > --- interrupt, eip = 0xc025b60f, esp = 0x80296, ebp = 0xc357bf08 ---
> > trap(18, 10, 10,c01597b6,20)
> > calltrap()
> > --- trap 0x9, eip = 0xc025a5de, esp = 0xc357bf50, ebp = 0xc357bf64 ---
> > sw1b(c0146cbc,c0146cbc,c32c5da0,c357bf94)
> > ithread_loop(c0747c00,c357bfa8)
> > fork_exit(c0146cbc,c0747c00,c357bfa8)
> > fork_trampoline()
>
> *sigh* This is why enabling interrupts in trap() is such a bad idea. If we
> get a trap in the scheduler, then lots of bad crap starts to happen because we
> can get an interrupt while we are in a trap. :( Can you compile your kernel with
> INVARIANTS on though, as I think the kernel should've panic'd earlier if it is
> doing what I think it is doing.
It's already have INVARIANTS, MUTEX_DEBUG, WITNESS and WITNESS_DDB.
> Also, if you are feeling industrious, edit
> sys/i386/i386/trap.c and comment out the enable_intr() call near the beginning
> of the trap() function right after the printf for 'kernel trap %d with
> interrupts disabled'.
Ok, I'll try so.
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
