Re: Pack of CAM improvements

In article <4B55D9D4.1000008_at_FreeBSD.org> you write:
>Hi.
Hi!
>
>I've made a patch, that should solve set of problems of CAM ATA and CAM
>generally. I would like to ask for testing and feedback.
>
>What patch does:
>- It unifies bus reset/probe sequence. Whenever bus attached at boot or
>later, CAM will automatically reset and scan it. It allows to remove
>duplicate code from many drivers.
>- Any bus, attached before CAM completed it's boot-time initialization,
>will equally join to the process, delaying boot if needed.
>- New kern.cam.boot_delay loader tunable should help controllers that
>are still unable to register their buses in time (such as slow USB/
>PCCard/ CardBus devices).
>- To allow synchronization between different CAM levels, concept of
>requests priorities was extended. Priorities now split between several
>"run levels". Device can be freezed at specified level, allowing higher
>priority requests to pass. For example, no payload requests allowed,
>until PMP driver enable port. ATA XPT negotiate transfer parameters,
>periph driver configure caching and so on.
>- Frozen requests are no more counted by request allocation scheduler.
>It fixes deadlocks, when frozen low priority payload requests occupying
>slots, required by higher levels to manage theit execution.
>- Two last changes were holding proper ATA reinitialization and error
>recovery implementation. Now it is done: SATA controllers and Port
>Multipliers now implement automatic hot-plug and should correctly
>recover from timeouts and bus resets.
>
>Patch can be found here:
>http://people.freebsd.org/~mav/cam-ata.20100119.patch
>
>Feedback as always welcome.

Ok, applied this to stable/8, and the good news is the box still seems to
run (using ahci(4) on an sb700 controller and siis(4) on a SiI3132 pcie
card, altho atm there's only an optical drive on that one.)  But what
this still doesn't fix is the broken `test unit ready' command on ada
devices, which also makes things like `cdrecord -scanbus' hang the bus. :(
(A few days ago I also got a hang after wanting to try out xfburn,
I suspect for the same reason...)

 Here is my earlier report:
	http://docs.freebsd.org/cgi/mid.cgi?20090817163144.GA2991

 Oh and I also still use this patch to scsi_cd.c to be able to read
discs that fail the `read toc' command, like bluray (data) discs.
PR s here:
	http://www.freebsd.org/cgi/query-pr.cgi?pr=138789

Index: src/sys/cam/scsi/scsi_cd.c
===================================================================
RCS file: /home/scvs/src/sys/cam/scsi/scsi_cd.c,v
retrieving revision 1.107.2.6
diff -u -p -u -r1.107.2.6 scsi_cd.c
--- src/sys/cam/scsi/scsi_cd.c	25 Dec 2009 08:06:35 -0000	1.107.2.6
+++ src/sys/cam/scsi/scsi_cd.c	23 Jan 2010 13:29:19 -0000
_at__at_ -2874,11 +2874,17 _at__at_ cdcheckmedia(struct cam_periph *periph)
 	}
 
 	softc->flags |= CD_FLAG_VALID_TOC;
+
+bailout:
 	softc->disk->d_sectorsize = softc->params.blksize;
 	softc->disk->d_mediasize =
 	    (off_t)softc->params.blksize * softc->params.disksize;
 
+/* if
 bailout:
+ * is here read requests will fail when the toc cant be read although
+ * CD_FLAG_VALID_MEDIA is set.
+ */
 
 	/*
 	 * We unconditionally (re)set the blocksize each time the