xl driver proplem.
John Baldwin
jhb at FreeBSD.org
Wed Aug 24 20:40:47 GMT 2005
On Monday 22 August 2005 01:07 pm, Thordur I. Bjornsson wrote:
> *snip*
>
> > Hello list.
> >
> > I had this proplem with the xl driver:
>
> *snip*
>
> Hello list (again). I'm sorry for the noize last night.
> I was way to sleepy ;)
>
> Now I had this proplem with a non-sleepable lock in if_xl.c (As
> explained in the previous post.
>
> Now, I did not provide alot of info in my last mail so here goes:
>
> FreeBSD caulfield.bitcode.eu.org 6.0-BETA2 FreeBSD 6.0-BETA2 #0: Sun Aug
> 21 22:21:18 UTC 2005
> thib at caulfield.bitcode.eu.org:/usr/obj/usr/src.inuse/sys/caulfield i386
>
> This is built from sources from around noon on Sunday.
>
> This proplem exist in -HEAD since there have been no changes in if_xl.c
Actually, HEAD does have changes that should fix the warning you are seeing.
They aren't merged to 6 yet however:
jhb 2005-08-18 19:24:30 UTC
FreeBSD src repository
Modified files:
sys/pci if_xl.c if_xlreg.h
Log:
Various fixups to locking:
- Remove a lot of superfluous locking during attach. There is no need
to lock access to the driver until some other thread has a way of getting
to it. For ethernet drivers the other ways include registering an
interrupt handler via bus_setup_intr(), calling ether_ifattach() to hook
into the network stack, and kicking off a callout-driven timer via
callout_reset().
- Use callout_* rather than timeout/untimeout.
- Break out of xl_rxeof() if IFF_DRV_RUNNING is clear after ifp->if_input
returns to handle the case where the interface was stopped while we were
passing a packet up the stack. Don't call xl_rxeof() in xl_rxeof_task()
unless IFF_DRV_RUNNING is set. With these fixes in place, any
outstanding task will gracefully terminate as soon as it gets a chance to
run after the interface has been stopped via xl_stop(). As a result,
taskqueue_drain() is no longer required in xl_stop(). The task is still
drained in detach() however to make sure that detach() can safely destroy
the driver mutex at the end of the function.
- Lock the driver lock in the ifmedia callouts and don't lock across
ifmedia_ioctl() in xl_ioctl().
Note: glebius came up with most of (3) as well independently. I took a
rather roundabout way of arriving at the same conclusion.
MFC after: 3 days
Revision Changes Path
1.195 +32 -48 src/sys/pci/if_xl.c
1.56 +1 -1 src/sys/pci/if_xlreg.h
--
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the freebsd-hackers
mailing list