xl driver proplem.

[Thordur I. Bjornsson]

Hello list.

I had this proplem with the xl driver:

Aug 21 22:45:38 caulfield kernel: taskqueue_drain with the following
non-sleepable locks held: Aug 21 22:45:38 caulfield kernel: exclusive
sleep mutex xl0 (network driver) r = 0 (0xc23c00a4) locked @
/usr/src/sys/pci/if_xl.c:2796 Aug 21 22:45:38 caulfield kernel: KDB:
stack backtrace: Aug 21 22:45:38 caulfield kernel:
witness_warn(2,0,c071f440,c23aa600,ed0baa80) at witness_warn+0x5d6 Aug
21 22:45:38 caulfield kernel:
taskqueue_drain(c2287800,c23c00c8,c072a962,cc7,c23ac400) at
taskqueue_drain+0x2e Aug 21 22:45:38 caulfield kernel:
xl_stop(c23c00a4,1,c072a962,af9,c07c50d0) at xl_stop+0x56 Aug 21
22:45:38 caulfield kernel:
xl_init_locked(c23c00a4,8,c072a962,aec,c23ac400) at xl_init_locked+0x47
Aug 21 22:45:38 caulfield kernel:
xl_init(c23be000,740,c072eec1,8020690c,c23be000) at xl_init+0x3c Aug 21
22:45:38 caulfield kernel:
ether_ioctl(c23ac400,8020690c,c2577e00,c055b96a,c0779dc0) at
ether_ioctl+0xa4 Aug 21 22:45:38 caulfield kernel:
xl_ioctl(c23ac400,8020690c,c2577e00,504,c2577e7c) at xl_ioctl+0xc8 Aug
21 22:45:38 caulfield kernel: in_ifinit(c2560350,0,0,0,ed0bab98) at
in_ifinit+0xa6 Aug 21 22:45:38 caulfield kernel:
in_control(c25e2de8,8040691a,c2560340,c23ac400,c23aa600) at
in_control+0xe84 Aug 21 22:45:38 caulfield kernel:
ifioctl(c25e2de8,8040691a,c2560340,c23aa600,2) at ifioctl+0x12d Aug 21
22:45:38 caulfield kernel:
soo_ioctl(c2570438,8040691a,c2560340,c2286d00,c23aa600) at
soo_ioctl+0x2c9 Aug 21 22:45:38 caulfield kernel:
ioctl(c23aa600,ed0bad04,c,422,3) at ioctl+0x118 Aug 21 22:45:38
caulfield kernel: syscall(3b,3b,3b,8058900,0) at syscall+0x13b Aug 21
22:45:38 caulfield kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f
Aug 21 22:45:38 caulfield kernel: --- syscall (54, FreeBSD ELF32,
ioctl), eip = 0x280d9593, esp = 0xbfbfe5fc, ebp = 0xbfbfee68 ---

According to
http://lists.freebsd.org/pipermail/freebsd-current/2005-May/050526.html

taskqueue_drain() can not be called while holding a lock.

I made a simple change to pull taskqueue_drain() out of xl_stop()
and call it before the lock is taken in xl_init()

This made the "proplem go away (TM)" and I have not noticed any proplems
e.g. performance,uptime (on the NIC) &c.

Still, when I reboot/shutdown the machine I see some funkyness but it
scrolls by too fast, I'm currently on my why to the garage to make
myself a null-modem cable and to some debugging ;)

Attached is the diff.

-- 
Thordur I.	<bzthib at gmail.com>
Humppa!
-------------- next part --------------
*** if_xl.c.ORIG	Sun Aug 21 21:56:20 2005
--- if_xl.c	Sun Aug 21 23:05:33 2005
***************
*** 2792,2798 ****
  xl_init(void *xsc)
  {
  	struct xl_softc		*sc = xsc;
! 
  	XL_LOCK(sc);
  	xl_init_locked(sc);
  	XL_UNLOCK(sc);
--- 2792,2804 ----
  xl_init(void *xsc)
  {
  	struct xl_softc		*sc = xsc;
! 	
! 	/* XXX 
! 	* taskqueue_drain() can not be called while holding a lock.
!  	* Appers to be working fine. Is this the right thing todo (TM) ?	 
! 	*/
! 	taskqueue_drain(taskqueue_swi, &sc->xl_task);
! 		
  	XL_LOCK(sc);
  	xl_init_locked(sc);
  	XL_UNLOCK(sc);
***************
*** 3274,3281 ****
  #ifdef DEVICE_POLLING
  	ether_poll_deregister(ifp);
  #endif /* DEVICE_POLLING */
- 
- 	taskqueue_drain(taskqueue_swi, &sc->xl_task);
  
  	CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_DISABLE);
  	CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_STATS_DISABLE);
--- 3280,3285 ----