From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 15 19:54:15 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AA19106564A; Mon, 15 Mar 2010 19:54:15 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 199D98FC14; Mon, 15 Mar 2010 19:54:14 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id A41E21E00126; Mon, 15 Mar 2010 20:54:13 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id o2FJonZF003760; Mon, 15 Mar 2010 20:50:49 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id o2FJonYP003759; Mon, 15 Mar 2010 20:50:49 +0100 (CET) (envelope-from nox) Date: Mon, 15 Mar 2010 20:50:49 +0100 (CET) From: Juergen Lock Message-Id: <201003151950.o2FJonYP003759@triton8.kn-bremen.de> To: scdbackup@gmx.net X-Newsgroups: local.list.freebsd.hackers In-Reply-To: <106085798526913@192.168.2.69> References: <201003141600.o2EG0F2M005027@triton8.kn-bremen.de> Organization: home X-Mailman-Approved-At: Mon, 15 Mar 2010 20:12:32 +0000 Cc: freebsd-hackers@freebsd.org, mav@freebsd.org Subject: Re: How to slow down SATA to 1.5 GBit/s ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 19:54:15 -0000 In article <106085798526913@192.168.2.69> you write: >Hi, 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.) > Ah thats good! :) You could try booting with verbose logging (I think thats option 5. in the beastie menu that comes up at boot), maybe then you will see something. > >The speed setter in camcontrol seems not to work. >Writing still gets stuck after a few MB. > Is this on 8.0 release or on stable/8 or head? As I said maybe that part of the code wasn't in 8.0 yet... >So i used the boot time option. >dmesg tells: > cd0 at ahcich4 bus 0 target 0 lun 0 > cd0: 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: 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. > I have Cc'd mav@ who afaik did most of the ahci(4) work, let's see what he has to say and if he wants you to file a PR... >------------------------------------------------ > >Have a nice day :) > >Thomas Ditto! :) Juergen