From owner-freebsd-current@FreeBSD.ORG Sun Aug 14 20:44:25 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9BB516A41F; Sun, 14 Aug 2005 20:44:25 +0000 (GMT) (envelope-from Chris@LainOS.org) Received: from mail.neovanglist.net (blackacid.neovanglist.net [69.16.150.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6196643D45; Sun, 14 Aug 2005 20:44:25 +0000 (GMT) (envelope-from Chris@LainOS.org) Received: from localhost (localhost.neovanglist.net [127.0.0.1]) by mail.neovanglist.net (Postfix) with ESMTP id E270D6D440; Sun, 14 Aug 2005 13:42:56 -0700 (MST) Received: from mail.neovanglist.net ([127.0.0.1]) by localhost (blackacid.neovanglist.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71446-02; Sun, 14 Aug 2005 13:42:50 -0700 (MST) Received: from melchior.neovanglist.net (cpe.atm2-0-1081027.0x50c4e512.bynxx14.customer.tele.dk [80.196.229.18]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.neovanglist.net (Postfix) with ESMTP id E13676D432; Sun, 14 Aug 2005 13:42:49 -0700 (MST) From: Chris Gilbert To: =?iso-8859-1?q?S=F8ren_Schmidt?= Date: Sun, 14 Aug 2005 21:47:41 +0200 User-Agent: KMail/1.8 References: <200508132321.37654.Chris@LainOS.org> <200508142016.17769.Chris@LainOS.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200508142147.42045.Chris@LainOS.org> X-Virus-Scanned: amavisd-new at neovanglist.net Cc: freebsd-current@FreeBSD.org Subject: Re: Panic during install on Sparc64 - Only with large HDD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Chris@LainOS.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2005 20:44:25 -0000 Hi S=F8ren, Thanks a bunch for your reply! Yea, I thought it may have been a 137GB limitation, I wasn't positive thoug= h. Thanks for clearing it up. Also, shouldn't we modify the output with a dev_printf or something of the= =20 like on device init to note this if the drive attached is > 137GB? It would seem a shame for this tread to be brought up over and over because= =20 people like myself didn't know any better. :) Also, some users had reported success by removing the CDROM drive, putting = in=20 an 40 pin cable, etc. I tried all of these and while they did seem to fix other unrelated issues,= =20 they did not effect the problem at hand. Perhaps also a proper solution would be to report attached drives on it in = DMA=20 mode which are > 137GB as 137GB.=20 At least this way it would be less likely to generate PRs and would=20 successfully install FreeBSD. Thanks again for the feedback. OT: Also, judging by your name/domain it would appear you are here in Denma= rk.=20 If/when you get the chance to implement that PIO override let me know, and= =20 next time you are in the Copenhagen area I'll buy you a beer. :) =2D-=20 Thanks, Chris (Lance) Gilbert Ph: +45 33 73 29 31 (UTC +0100) On Sunday 14 August 2005 21:41, S=F8ren Schmidt wrote: > On 14/08/2005, at 20:16, Chris Gilbert wrote: > > Also, it seems that setting hw.ata.ata_dma=3D0 (forcing it into PIO > > mode) fixes > > the issue. > > > > # sysctl -a hw.ata.ata_dma > > hw.ata.ata_dma: 0 > > > > # dd count=3D1 obs=3D1024 seek=3D93321656 if=3D/dev/urandom of=3D/dev/a= d0g > > 1+0 records in > > 0+1 records out > > 512 bytes transferred in 0.001390 secs (368351 bytes/sec) > > > > Also, seems there is a bug summitted on this, and a posting to the > > freebsd-sparc64 mailing list. > > > > http://lists.freebsd.org/pipermail/freebsd-sparc64/2005-June/ > > 003212.html > > > > Will continue looking into the chipset docs and FreeBSD driver... > > but thought > > I should point this out. > > Actually the problem is in the Acer chip, it cant handle 48bit > addressing in DMA mode, unless the version is above 0xc4 IIRC. > > Either you should use disks with a size less137GB, or you need to > engage PIO mode. > > A workaround in ATA could be to use PIO mode when crossing the > boundary, but there is no framework for quirks like that present yet, > could be pretty easily done though so give a me few days (I'm busy as > usual) > > -S=F8ren >