At 10:40 AM 5/28/99 -0700, you wrote:
>network devices need splimp() to block them
>
>the mbuf calls are splimp() protected.
K, so that goes back to my original questionshouldnt the routines
that would cause drivers to allocate mbufs to fail call splimp instead of
splnet()?
Dennis
>
>juli
network devices need splimp() to block them
the mbuf calls are splimp() protected.
julian
On Fri, 28 May 1999, Dennis wrote:
> > >#10 0xf01cbe1a in l2_int ()
> > >#11 0xf01dd8cd in ethintr_pci ()
> > >#12 0xf01388f6 in rtalloc1 (dst=0xf01e8f18, report=1, ignflags=65536)
> > > at ../../net/r
> >#10 0xf01cbe1a in l2_int ()
> >#11 0xf01dd8cd in ethintr_pci ()
> >#12 0xf01388f6 in rtalloc1 (dst=0xf01e8f18, report=1, ignflags=65536)
> > at ../../net/route.c:132
> >#13 0xf01388ac in rtalloc_ign (ro=0xf01e8f14, ignore=65536)
> > at ../../net/route.c:108
Am I wrong in assuming that this
At 02:57 PM 5/27/99 -0700, you wrote:
>
>
>On Thu, 27 May 1999, Dennis wrote:
>
>> At 12:26 PM 5/27/99 -0700, you wrote:
>> >>
>> >> We've encountered a situation where mbuf allocations inside a device
>> >> interrupt handler fails occasionally...and it always seems to happen
when
>> >> rtalloc()
On Thu, 27 May 1999, Dennis wrote:
> At 12:26 PM 5/27/99 -0700, you wrote:
> >>
> >> We've encountered a situation where mbuf allocations inside a device
> >> interrupt handler fails occasionally...and it always seems to happen when
> >> rtalloc() is interrupted. Is this due to some sort of loc
At 12:26 PM 5/27/99 -0700, you wrote:
>>
>> We've encountered a situation where mbuf allocations inside a device
>> interrupt handler fails occasionally...and it always seems to happen when
>> rtalloc() is interrupted. Is this due to some sort of locking (rtalloc is
>> run at splnet())...should it
>
> We've encountered a situation where mbuf allocations inside a device
> interrupt handler fails occasionally...and it always seems to happen when
> rtalloc() is interrupted. Is this due to some sort of locking (rtalloc is
> run at splnet())...should it perhaps be run at splimp() to avoid this p
> From: Dennis
> Date: 1999-05-27 09:43:09 -0700
> To: hack...@freebsd.org
> Subject: mbuf stuff
>
> We've encountered a situation where mbuf allocations inside a device
> interrupt handler fails occasionally...and it always seems to
happen when
> rtalloc() is int
We've encountered a situation where mbuf allocations inside a device
interrupt handler fails occasionally...and it always seems to happen when
rtalloc() is interrupted. Is this due to some sort of locking (rtalloc is
run at splnet())...should it perhaps be run at splimp() to avoid this problem?
W
9 matches
Mail list logo
