Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Mar 2004 11:47:56 -0800
From:      John-Mark Gurney <gurney_j@efn.org>
To:        jitendra pande <jpande_techinfo@yahoo.com>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: How to use Kernel level mutex in FreeBSD 4.8
Message-ID:  <20040313194756.GE56805@funkthat.com>
In-Reply-To: <20040312155151.38206.qmail@web42003.mail.yahoo.com>
References:  <xzpy8q7wle7.fsf@dwp.des.no> <20040312155151.38206.qmail@web42003.mail.yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
jitendra pande wrote this message on Fri, Mar 12, 2004 at 07:51 -0800:
> I tried using the splimp(..) and splx(..) within my driver and it works 
> for the fisrt go.....
>  
> But when i tried to do any other activity like pinging another machine/ starting a application then my client application using the driver crashes. The behavior is very 
> erratic...in some cases it works even when doing any other operation/ but 
> in another situataion it just crashes......
>  
>  
> can u help me why this is happening......is there anything else i need 
> to do.. any other way for mutual exclusion.... or some kernel level semaphore and so.....
>  
> also any idea that in FreeBSD how does one determine the spl level at 
> which a device's interrupt routines execute

if you read the spl(9) man page, you can see:
     The traditional assignment of the various device drivers to the interrupt
     priority groups can be roughly classified as:

     splnet()          All network interface drivers.

and they list a couple others, and there are more like splcam (for scsi
drivers)...

since you're pinging and stuff, I assume you're writing a network driver..
The spl levels are a way to block interrupts from a set from occuring..
When you are in splnet, no network associated interrupts will occure..
This is how to make sure that you're interrupt handler doesn't touch
data that you are currently modifing..  Also under 4.x SMP, there is
only one kernel thread of execution, so you don't have to worry about
locking till you call malloc with M_WAITOK, or tsleep (there might be
a few more), there the kernel may stop execution of your code and switch
to another process...

Hope this helps.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."


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