Re: Pack of CAM improvements
Gary Jennejohn wrote: I started seeing a problem a few days ago with one of my DVD drives (a burner at cd0) under 9-current, which makes it impossible to use it even to simply read a DVD. Here the (rather strange IMO) output in dmesg: cd0: HL-DT-ST DVD-RAM GSA-H54N 1.00 Removable CD-ROM SCSI-0 device cd0: 66.700MB/s transfers (UDMA4, PIO size 65534bytes) cd0: Attempt to query device size failed: UNIT ATTENTION, Power on, reset, or bus device reset occurred cd1 at ata0 bus 0 scbus6 target 1 lun 0 cd1: TSSTcorp DVD-ROM SH-D162D SB01 Removable CD-ROM SCSI-0 device cd1: 33.300MB/s transfers (UDMA2, PIO size 65534bytes) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed I haven't the foggiest why cd0 behaves diffrently from cd1, which is a vanilla DVD drive and just works. I am not sure yet what triggered these changes. May be just some timing issue. That UNIT ATTENTION seems reasonable, as reset indeed just happened there. The real problem is that CAM had several limitations in SCSI status handling, when working with ATAPI or USB devices. It made request processing stop in some cases, where retries would be expected. New patch version should handle this and some other problems: http://people.freebsd.org/~mav/cam-ata.20100124.patch Try it please. Thanks. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Pack of CAM improvements
On Sun, 24 Jan 2010 18:48:15 +0200 Alexander Motin m...@freebsd.org wrote: Gary Jennejohn wrote: I started seeing a problem a few days ago with one of my DVD drives (a burner at cd0) under 9-current, which makes it impossible to use it even to simply read a DVD. Here the (rather strange IMO) output in dmesg: cd0: HL-DT-ST DVD-RAM GSA-H54N 1.00 Removable CD-ROM SCSI-0 device cd0: 66.700MB/s transfers (UDMA4, PIO size 65534bytes) cd0: Attempt to query device size failed: UNIT ATTENTION, Power on, reset, or bus device reset occurred cd1 at ata0 bus 0 scbus6 target 1 lun 0 cd1: TSSTcorp DVD-ROM SH-D162D SB01 Removable CD-ROM SCSI-0 device cd1: 33.300MB/s transfers (UDMA2, PIO size 65534bytes) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed I haven't the foggiest why cd0 behaves diffrently from cd1, which is a vanilla DVD drive and just works. I am not sure yet what triggered these changes. May be just some timing issue. That UNIT ATTENTION seems reasonable, as reset indeed just happened there. The real problem is that CAM had several limitations in SCSI status handling, when working with ATAPI or USB devices. It made request processing stop in some cases, where retries would be expected. New patch version should handle this and some other problems: http://people.freebsd.org/~mav/cam-ata.20100124.patch Try it please. Thanks. This patch works extremely well! Thanks. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Pack of CAM improvements
In article 4b55d9d4.1000...@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 - 1.107.2.6 +++ src/sys/cam/scsi/scsi_cd.c 23 Jan 2010 13:29:19 - @@ -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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Pack of CAM improvements
On Sat, 23 Jan 2010 15:07:47 +0100 (CET) Juergen Lock n...@jelal.kn-bremen.de wrote: 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 I started seeing a problem a few days ago with one of my DVD drives (a burner at cd0) under 9-current, which makes it impossible to use it even to simply read a DVD. Here the (rather strange IMO) output in dmesg: cd0: HL-DT-ST DVD-RAM GSA-H54N 1.00 Removable CD-ROM SCSI-0 device cd0: 66.700MB/s transfers (UDMA4, PIO size 65534bytes) cd0: Attempt to query device size failed: UNIT ATTENTION, Power on, reset, or bus device reset occurred cd1 at ata0 bus 0 scbus6 target 1 lun 0 cd1: TSSTcorp DVD-ROM SH-D162D SB01 Removable CD-ROM SCSI-0 device cd1: 33.300MB/s transfers (UDMA2, PIO size 65534bytes) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed I haven't the foggiest why cd0 behaves diffrently from cd1, which is a vanilla DVD drive and just works. --- Gary Jennejohn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Pack of CAM improvements
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 0002 cs ss 0 rs 0001 tfs 50 serr 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 atap...@pci0:0:17:0: class=0x010601 card=0x43911002 chip=0x43911002 rev=0x00 hdr=0x00 Thanks, Yamagi -- Homepage: www.yamagi.org Jabber: yam...@yamagi.org GnuPG/GPG:0xEFBCCBCB ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Pack of CAM improvements
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 signature.asc Description: OpenPGP digital signature
Re: Pack of CAM improvements
On Fri, Jan 22, 2010 at 2:23 AM, Harald Schmalzbauer h.schmalzba...@omnilan.de wrote: 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? In my testing of pulling drives at random (using a 3Ware 9550SXU or 9650SE controller), you have to zpool offline pool device while the drive is unplugged, before you can re-insert the same disk or a different disk. Without doing that step, it's very hard to re-insert the same disk, or replace it with a new one, without rebooting. Took me a couple of reboots and drive replacements before I figured that one out. :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Pack of CAM improvements
On Fri, Jan 22, 2010 at 11:23:55AM +0100, Harald Schmalzbauer wrote: 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? I can't speak with regards to the new ATA-via-CAM stuff, but with the classic AHCI (meaning ataahci(4)), the procedure I've used reliably for quite some time on Intel ICHx controllers is this: For SATA disks that are purely UFS/UFS2: - Single-user mode might be required here; it varies - Terminate any processes which rely on filesystems on that disk - umount /filesystem - atacontrol detach ataX (where X = channel associated with disk) - Physically remove bad disk - Physically insert new disk - Wait 15 seconds for stuff to settle - atacontrol attach ataX (where X = previous channel detached) - sade / sysinstall / gpart / whatever you like - Restore data... :-) For SATA disks part of a ZFS mirror or raidz[123] pool: - zpool offline pool disk - atacontrol detach ataX (where X = channel associated with disk) - Physically remove bad disk - Physically insert new disk - Wait 15 seconds for stuff to settle - atacontrol attach ataX (where X = previous channel detached) - zpool replace pool disk - zpool online pool disk -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Pack of CAM improvements
On 01/22/10 11:48, Freddie Cash wrote: On Fri, Jan 22, 2010 at 2:23 AM, Harald Schmalzbauer h.schmalzba...@omnilan.de wrote: 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? In my testing of pulling drives at random (using a 3Ware 9550SXU or 9650SE controller), you have to zpool offlinepool device while the drive is unplugged, before you can re-insert the same disk or a different disk. Without doing that step, it's very hard to re-insert the same disk, or replace it with a new one, without rebooting. Took me a couple of reboots and drive replacements before I figured that one out. :) I think you can do it without the 'zpool offline pool device' command; I may be wrong, but I believe you can use 'zpool replace' to accomplish what you're trying to do. i.e. if you have a bad drive ada3, and take it out, then replace it with a new disk, you can issue a 'zpool replace pool /dev/ada3 /dev/ada3' (yes, the same device is specified twice). ZFS should recognize that its a different disk and/or that it is lacking ZFS metadata and begin to resilver the pool onto the new device. If you watch 'zfs status' in the process you'll see something like: raidz1 DEGRADED 0 0 0 label/ada4ONLINE 0 0 0 12.4M resilvered label/ada5ONLINE 0 0 0 12.4M resilvered label/ada6ONLINE 0 0 0 12.3M resilvered replacing DEGRADED 0 0 0 label/ada3/old UNAVAIL 0 595 0 cannot open label/ada3 ONLINE 0 0 0 9.74G resilvered Try it out and let me know if it works for you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Pack of CAM improvements
On Fri, Jan 22, 2010 at 10:28 AM, Steve Polyack kor...@comcast.net wrote: On 01/22/10 11:48, Freddie Cash wrote: In my testing of pulling drives at random (using a 3Ware 9550SXU or 9650SE controller), you have to zpool offlinepool device while the drive is unplugged, before you can re-insert the same disk or a different disk. Without doing that step, it's very hard to re-insert the same disk, or replace it with a new one, without rebooting. Took me a couple of reboots and drive replacements before I figured that one out. :) I think you can do it without the 'zpool offline pool device' command; I may be wrong, but I believe you can use 'zpool replace' to accomplish what you're trying to do. i.e. if you have a bad drive ada3, and take it out, then replace it with a new disk, you can issue a 'zpool replace pool /dev/ada3 /dev/ada3' (yes, the same device is specified twice). ZFS should recognize that its a different disk and/or that it is lacking ZFS metadata and begin to resilver the pool onto the new device. If you watch 'zfs status' in the process you'll see something like: Yes, that does work ... but it's not nearly as reliable as doing the offline first. If you do things in the right order, drives can be replaced and resilvering started within minutes (our process takes a little less than 5 minutes, but the bulk of that is removing the dead drive from the caddy, and adding the new drive to the caddy). Do things in the wrong order, and it can take 15 minutes or more, and may require rebooting the system (as our manager discovered trying to replace a drive while I was away). :) Just because there are shortcuts available ... doesn't mean you should always take them. :D -- Freddie Cash fjwc...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Pack of CAM improvements
2010/1/22 Harald Schmalzbauer h.schmalzba...@omnilan.de: 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. Since r202799 it applies cleanly to 8-STABLE. 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 -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Pack of CAM improvements
On Wed, 20 Jan 2010 14:34:07 +0100 Henri Hennebert wrote: 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 Thanks! 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. So do I with kern.cam.boot_delay=6000 for my EEEPC-1000: - % uname -a FreeBSD izar 9.0-CURRENT FreeBSD 9.0-CURRENT #3 r202734M: Thu Jan 21 18:13:10 MSK 2010 b...@izar:/obj/usr/src/sys/EEEBB i386 - - 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. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Pack of CAM improvements
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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Pack of CAM improvements
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Pack of CAM improvements
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Pack of CAM improvements
Scott Long wrote: On Jan 19, 2010, at 9:12 AM, Alexander Motin wrote: 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. I am sure that using delay is not a perfect solution, but it nicely fits new scanning procedure and costs just a few lines of code. Nobody denies to add _more_ events to wait there. This is just a band-aid for cases when nothing else helps. May be I am mixing something, but AFAIR there were some USB devices, which doesn't appear on a first bus scan, but register later. Here's my alternate proposal: - move xpt_config() execution to a new config hook that runs after the normal intrhooks. To make scanning work in background, it is better to call xpt_config() same as now, as early as possible, to start scanning for already registered buses, but call xpt_release_boot() on some later event (or even several different events). - 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. Nobody denies your driver to call xpt_rescan on per-known-device basis. In such case CAM will still wait until all of your scan requests will be fulfilled. You may see it is already done by some SIMs and PMP driver. If you need a way to avoid full scan, it also can be done, while it is separate question. - 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. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
