Date: Sat, 24 Oct 1998 02:02:02 -0400 (EDT) From: "Matthew N. Dodd" <winter@jurai.net> To: Kenneth Merry <ken@FreeBSD.ORG> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam cam_periph.c cam_periph.h cam_xpt.c src/sys/cam/scsi scsi_cd.c scsi_ch.c scsi_da.c scsi_pass.c scsi_pt.c scsi_sa.c scsi_target.c Message-ID: <Pine.BSF.4.02.9810240159400.17054-100000@sasami.jurai.net> In-Reply-To: <199810222216.PAA06253@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Well, I was of little help in debuging this but it appears that these fixes address the errors I was seeing on my system when using broken devices. (What? The rest of you aren't using deviously broken devices as a way of stress testing the scsi system?:) Thanks Kenneth! On Thu, 22 Oct 1998, Kenneth Merry wrote: > There were several possible problems: > - In the da driver, we didn't remove the peripheral's softc from the da > driver's linked list of softcs. Once the peripheral and softc got > removed, we'd get a kernel panic the next time the timeout routine > called dasendorderedtag(). > - In the da, cd and possibly ch drivers, we didn't remove the > peripheral's devstat structure from the devstat queue. Once the > peripheral and softc were removed, this could cause a panic if anyone > tried to access device statistics. (one component of the linked list > wouldn't exist anymore) > - In the cd driver, we didn't take the peripheral off the changer run > queue if it was scheduled to run. In practice, it's highly unlikely, > and maybe impossible that the peripheral would have been on the > changer run queue at that stage of the probe process. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.02.9810240159400.17054-100000>