CAM/INVARIANTS fix committed

[Kenneth D. Merry]

I have committed a fix for the panic that happened with the da(4) or cd(4)
drivers configured and INVARIANTS turned on.

Let me know if there are any problems/comments/questions.

Ken

----- Forwarded message from "Kenneth D. Merry" <ken at FreeBSD.org> -----

From: "Kenneth D. Merry" <ken at FreeBSD.org>
Date: Tue, 9 Sep 2003 17:40:40 -0700 (PDT)
To: src-committers at FreeBSD.org, cvs-src at FreeBSD.org, cvs-all at FreeBSD.org
Subject: cvs commit: src/sys/cam/scsi scsi_cd.c scsi_da.c src/sys/kern
         subr_taskqueue.c src/sys/sys taskqueue.h src/share/man/man4 cd.4
         da.4 src/share/man/man9 cd.9

ken         2003/09/09 17:40:40 PDT

  FreeBSD src repository

  Modified files:        (Branch: RELENG_4)
    sys/cam/scsi         scsi_cd.c scsi_da.c 
    sys/kern             subr_taskqueue.c 
    sys/sys              taskqueue.h 
    share/man/man4       cd.4 da.4 
    share/man/man9       cd.9 
  Log:
  MFC:  Move dynamic sysctl(8) variable creation for the cd(4) and da(4)
  drivers out of cdregister() and daregister(), which are run from interrupt
  context.
  
  Files/revisions merged:
  
  scsi_da.c:              1.157, 1.158
  scsi_cd.c:              1.81
  subr_taskqueue.c:       1.17
  taskqueue.h:            1.8
  cd.4:                   1.33
  da.4:                   1.42
  cd.9:                   1.18
  not merged:             taskqueue.9 rev 1.7, 1.8 (not in RELENG_4)
  
  This code is necessarily a little bit different than the version committed
  to -current, mainly in the area of mutexes.  (Which become splfoo() in
  -stable.)
  
  The sysctl code does blocking mallocs (M_WAITOK), which causes problems
  if malloc(9) actually needs to sleep.  (And causes a panic for people
  running with INVARIANTS turned on.)
  
  The eventual fix for this issue will involve moving the CAM probe process
  inside a kernel thread.  For now, though, I have fixed the issue by moving
  dynamic sysctl variable creation for these two drivers to a task queue
  running in a kernel thread.
  
  The existing task queue in -stable (taskqueue_swi) runs in software interrupt
  handlers, which wouldn't fix the problem at hand.  So I have created a new
  task queue, taskqueue_thread, that runs inside a kernel thread.
  
  scsi_cd.c:      Remove sysctl variable creation code from cdregister(), and
                  move it to a new function, cdsysctlinit().  Queue
                  cdsysctlinit() to the taskqueue_thread taskqueue once we
                  have fully registered the cd(4) driver instance.
  
  scsi_da.c:      Remove sysctl variable creation code from daregister(), and
                  move it to move it to a new function, dasysctlinit().
                  Queue dasysctlinit() to the taskqueue_thread taskqueue once
                  we have fully registered the da(4) instance.
  
  taskqueue.h:    Declare the new taskqueue_thread taskqueue, update some
                  comments.
  
  subr_taskqueue.c:
                  Create the new kernel thread taskqueue.
  
  cd.4:           Update the cd(4) man page to talk about the minimum command
                  size sysctl/loader tunable.  Also note that the changer
                  variables are available as loader tunables as well.
  
  da.4:           Update the da(4) man page to cover the retry_count,
                  default_timeout and minimum_cmd_size sysctl variables/loader
                  tunables.  Remove references to /dev/r???, they aren't used
                  any longer.
  
  cd.9:           Update the cd(9) man page to describe the CD_Q_10_BYTE_ONLY
                  quirk.
  
  Approved by:    re (scottl, murray)
  
  Revision   Changes    Path
  1.17.2.9   +34 -3     src/share/man/man4/cd.4
  1.22.2.8   +54 -42    src/share/man/man4/da.4
  1.11.2.4   +17 -1     src/share/man/man9/cd.9
  1.31.2.15  +42 -21    src/sys/cam/scsi/scsi_cd.c
  1.42.2.45  +44 -22    src/sys/cam/scsi/scsi_da.c
  1.1.2.3    +27 -1     src/sys/kern/subr_taskqueue.c
  1.3.2.2    +6 -0      src/sys/sys/taskqueue.h

----- End forwarded message -----

-- 
Kenneth Merry
ken at kdm.org