Date: Mon, 15 Mar 2010 15:27:09 +0100 From: "Thomas Schmitt" <scdbackup@gmx.net> To: freebsd-hackers@freebsd.org Subject: Re: How to slow down SATA to 1.5 GBit/s ? Message-ID: <106085798526913@192.168.2.69> In-Reply-To: <201003141600.o2EG0F2M005027@triton8.kn-bremen.de> References: <201003141600.o2EG0F2M005027@triton8.kn-bremen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, the switch to ahci was successful and it looks quite good, overall. But probably i found a bug. I could need advise where and how to submit it. A particular sequence of SCSI commands leads to an elsewise harmless stall of the dialog between libburn and drive. To close and re-open the libcam connection before this sequence is enough to circumvent the problem. But this remedy is not desirable. Long story: ------------------------------------------------ I did the switch to ahci. Now my disk is ada and my eSATA attached burner is not acd1|cd1 but only cd0. The IDE ROM works fine with the vanilla configuration. It obviously staid under ata control as acd0|cd1. With the poor eSATA connection at 3000 GBit/s i still get the stalls. But after killing the writing process and about 4 minutes of waiting i get my drive back in most cases. Sometimes i have to do a power cycle on the drive to get it back as /dev/cd0. Still no reboot or panic. I begin to like ahci. (I find no trace of power cycle or re-plugging in dmesg.) The speed setter in camcontrol seems not to work. Writing still gets stuck after a few MB. So i used the boot time option. dmesg tells: cd0 at ahcich4 bus 0 target 0 lun 0 cd0: <TSSTcorp CDDVDW SH-S223B SB02> Removable CD-ROM SCSI-0 device cd0: 300.000MB/s transfers I added to /boot/device.hints : hint.ahcich.4.sata_rev="1" After reboot, i see in dmesg: cd0 at ahcich4 bus 0 target 0 lun 0 cd0: <TSSTcorp CDDVDW SH-S223B SB02> Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers Now everything seems to work - except libburn. Grrr. Writing looks good. But it does not end. It is stuck in READ DISC INFORMATION 51 00 00 00 00 00 00 00 22 00 and waits for the reply of the drive. This happens when the new media state shall be inquired after burning was completed. If i do cam_close_device() and re-open the drive, then the same command sequence succeeds. (But this is a very undesirable gesture at that point of processing.) The problem does not appear with USB (and did not while the drive was built-in at SATA). The drive is surely not to blame. So now i could need advise about filing a bug report. ------------------------------------------------ Have a nice day :) Thomas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?106085798526913>