4.9-PRE crash with firewire :(

Mike Tancsa mike at sentex.net
Mon Sep 22 19:15:08 PDT 2003


At 09:57 PM 22/09/2003, Daniel O'Connor wrote:

>Hmm, I thought it was newer than September 10th, but I will update again and
>see how it goes.
>
>Can you tell me what file to look for so I can confirm my source update is
>working properly?

I think the following commit is the one you need
----------------------------------
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
_______________________________________________
cvs-all at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe at freebsd.org"
-----------------------------------------------

         ---Mike 



More information about the freebsd-stable mailing list