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. -- Alexander Motin
On Jan 19, 2010, at 9:12 AM, Alexander Motin wrote:> 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).I've fought many times against delay values like this. They never work well enough. Drivers that have delayed scans should set up their own intrhook to delay the boot until their scan is done. To help this out, CAM should move to its own hook that is guaranteed to run after the normal intrhooks. However, this isn't required. Here's my alternate proposal: - move xpt_config() execution to a new config hook that runs after the normal intrhooks. - For self identifying buses (i.e. anything where device presence is known to the controller), have the SIM notify CAM of each target device, instead of assuming that CAM will scan for it. - Teach USB and whatnot to use a confighook to drive their discovery, instead of estimated timeouts. I'm doing exactly this for the new MPT2SAS driver. Scott
On 01/19/2010 17:12, Alexander Motin wrote:> 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).With kern.cam.boot_delay=15000 (I suppose that it was in ms) I can now boot from my sim card reader. Thanks Henri> - 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. >
Alexander Motin schrieb am 19.01.2010 17:12 (localtime): ...> Patch can be found here: > http://people.freebsd.org/~mav/cam-ata.20100119.patch > > Feedback as always welcome.Again, thanks a lot for your ongoing great work! The patch doesn't cleanly apply with vpo, but I don't use vpo so I didn't care. Otherwise I couldn't find any problems. The system detects reinserted SATA drives on ICH9 fine. This was tested on a zfs backup server which went to the backbone yesterday, so I can't physically remove any devices any more for testing... But I had some questions about zfs raidz states. I think that isn't a matter of atacam but if I removed one disk, zpool status still showed me the ada3 device "online". After reinserting (and proper detection/initialisazion with cam, ada3 was present again) and zpool clean, it set the devicea as UNAVAIL sinve I/O errors. I coudn't get the device into the pool again, no matter what I tried. Only rebooting the machine helped. Then I could clean and scrub. What are the needed steps to provide a reinsterted hard disk to geom? With the latest patches I don't need to issue any reset/rescan comman, right? So it's a zfs problem, right? My mistake in understanding? Thanks, -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100122/8c6f0809/signature.pgp
In article <4B55D9D4.1000008@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 @@ -2874,11 +2874,17 @@ 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
On Tue, 19 Jan 2010, Alexander Motin wrote:> 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.[snip] Hello, applied this patch to 8-stable recompiled the kernel and rebooted. The kernel did not boot it hangs while probing the ahci-controller. The error message is: ahcich0: Timeout on slot 0 ahcich0: is 00000002 cs 00000000 ss 000000000 rs 00000001 tfs 50 serr 00000000 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config After that the kernel hangs forever. A 8-stable without the patch shows ahcich0: Timeout on slot 0 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config and boots but doesn't find any hard disks. It's an Asus M3A-H/HDMI motherboard with AMD SB710 southbridge. The harddisk is an Western Digital WD10EAVS. Both are working with the old ata implementation in AHCI mode. pciconf output of the controller is atapci0@pci0:0:17:0: class=0x010601 card=0x43911002 chip=0x43911002 rev=0x00 hdr=0x00 Thanks, Yamagi -- Homepage: www.yamagi.org Jabber: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB