Re: Kernel crash w/o reason

From: Jan Engelhardt (jengelh_at_linux01.gwdg.de)
Date: 12/24/04

  • Next message: David Schultz: "Re: Kernel crash w/o reason"
    Date: Fri, 24 Dec 2004 00:03:41 +0100 (MET)
    To: Max Laier <max@love2party.net>
    
    

    >1) In kmi_fops.d_open():
    >| if(!mtx_trylock(&Open_lock)) { return EBUSY; }
    >| return 0;
    >
    >this can not work. You cannot return to userland with a lock acquired.

    So? The full code also contains a uio_read() function. If I release the
    lock in uio_read(), no crash happens. It's just in uio_close().

    Why can't I hold this lock, as it is possible with Linux? A mutex is basically
    just an atomic counter AFAIK, and if nobody releases it in-between, it is
    still held by the time we enter uio_close() - thus it could be unlocked
    without problems. In theory at least.

    What should I use instead? A semaphore?

    >2) If you report a problem, try to provide an error message. In this case a
    >crashdump/panic string. When you do kernel programming you should always run
    >in a debug kernel. To debug this specific problem WITNESS is helpful.

    I've tracked it a little and found out that it is mtx_unlock() which crashes,
    or more precisely, it is line
            td1 = turnstile_head(ts)
    in _mtx_unlock_sleep() -- ts == NULL! I have dug deep into &m->mtx_object and
    it looks like the TC list (in turnstile_lookup) is empty, but I do not know
    why.

    >4) Why on earth do you use gmake? What's wrong with bsd.*.mk? It's a whole lot
    >easier.

    Because non-BSD (read: Linux, MINGW/MSYS and Cygwin) do not ship BSD make. And
    of course, that I got to GNU make first and had few joy to learn another make
    syntax.

    Jan Engelhardt

    -- 
    ENOSPC
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
    

  • Next message: David Schultz: "Re: Kernel crash w/o reason"