From owner-freebsd-stable@FreeBSD.ORG Fri Apr 17 20:08:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04E1F10656D1 for ; Fri, 17 Apr 2009 20:08:18 +0000 (UTC) (envelope-from freebsd.stable@virtualhost.nl) Received: from mail.virtualhost.nl (mail.virtualhost.nl [89.200.201.133]) by mx1.freebsd.org (Postfix) with ESMTP id 528F58FC1B for ; Fri, 17 Apr 2009 20:08:16 +0000 (UTC) (envelope-from freebsd.stable@virtualhost.nl) Received: (qmail 10583 invoked from network); 17 Apr 2009 21:41:21 +0200 Received: from ip120-12-208-87.adsl2.static.versatel.nl (HELO ?192.168.1.6?) (87.208.12.120) by mail.virtualhost.nl with SMTP; 17 Apr 2009 21:41:21 +0200 Message-ID: <49E8DB60.4080202@virtualhost.nl> Date: Fri, 17 Apr 2009 21:41:20 +0200 From: Jeroen Hofstee User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: poweredge 1850 won't boot 7.1? maybe LSI-related : amr0: adapter is busy X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 20:08:19 -0000 Hello All, I encountered the same problem as reported to this list earlier, http://lists.freebsd.org/pipermail/freebsd-stable/2009-February/048305.html, but then with 7.1-RELEASE-p4. Interestingly enough, FreeBSD booted fine on the machine installed (updated from 7.0 to 7.1-RELEASE-p4). This machine is a PowerEdge 1850 bios A04 with Perc 43/Si bios H430 / fwVer 521S. When booting a drive from this machine in another PowerEdge 1850, bios A07 Perc 4e/Si bios H435 FwVer 5B2D it drops to the can mount root prompt, similar as reported originally, see http://omx.ch/om/stuff/pe1850bsd71error.jpg. By specifying the kern.cam.scsi_delay, as suggested in this thread, the problem is solved. So there is a workaround, but I would prefer to see this fixed instead. I can't find a problem report regarding this topic though so can't find the current status. Does anybody know the current status? I can test if this issue has been solved if needed. I need to know then what to test of course... 7.1-STABLE or 7.2 BETA1 etc... Regards, Jeroen