Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Jan 2001 11:29:30 -0800 (PST)
From:      John Baldwin <jhb@FreeBSD.ORG>
To:        Andrew Gallatin <gallatin@cs.duke.edu>
Cc:        freebsd-alpha@FreeBSD.ORG
Subject:   RE: -current failing on PC164
Message-ID:  <XFMail.010124112930.jhb@FreeBSD.org>
In-Reply-To: <14959.10557.921381.576255@grasshopper.cs.duke.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

On 24-Jan-01 Andrew Gallatin wrote:
> 
> OK.. After a re-configure, I get this:
> 
> Mounting root from ufs:/dev/da0a
> da0 at sym0 bus 0 target 0 lun 0
> da0: <SEAGATE ST39140W 1498> Fixed Direct Access SCSI-2 device 
> da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged
> Queueing Enabled
> da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C)
> panic: mutex_enter(sio:1, MTX_SPIN) out of order @
> ../../isa/sio.c:2287 already holding sched lock:2

So we already hold sched_lock and are obtaining sio_lock.

Looks like it is trying to display a printf while holding sched_lock?

At ddb, can you examine sched_lock, find its mtx_debug member:

struct mtx {
        volatile uintptr_t mtx_lock;    /* lock owner/gate/flags */
        volatile u_int  mtx_recurse;    /* number of recursive holds */
        u_int           mtx_saveintr;   /* saved flags (for spin locks)
*/
        int             mtx_flags;      /* flags passed to mtx_init() */
        const char      *mtx_description;
        TAILQ_HEAD(, proc) mtx_blocked;
        LIST_ENTRY(mtx) mtx_contested;
        struct mtx      *mtx_next;      /* all locks in system */
        struct mtx      *mtx_prev;
        struct mtx_debug *mtx_debug;
};

Then examine the memory at mtx_debug to find the mtxd_line and
mtxd_file members:

struct mtx_debug {
        struct witness  *mtxd_witness;
        LIST_ENTRY(mtx) mtxd_held;
        const char      *mtxd_file;
        int             mtxd_line;
};

Which should tell us the file and line of the last time sched_lock was
obtained.  Hopefully from that we can figure out what printf is
triggering this..

> I don't understand the panic message -- why is it talking about sched
> lock when the mtx_enter is on sio_lock??

It is complaining that the mutex enter on sio is invalid because
sched_lock is already held and that this violates the lock order.

> Cheers,
> 
> Drew

-- 

John Baldwin <jhb@FreeBSD.org> -- 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010124112930.jhb>