From owner-freebsd-sparc64@FreeBSD.ORG Thu Nov 20 00:35:59 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B34516A4CE; Thu, 20 Nov 2003 00:35:59 -0800 (PST) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id A989643FB1; Thu, 20 Nov 2003 00:35:57 -0800 (PST) (envelope-from sos@spider.deepcore.dk) Received: from spider.deepcore.dk (localhost [127.0.0.1]) by spider.deepcore.dk (8.12.10/8.12.10) with ESMTP id hAK8YZEQ057726; Thu, 20 Nov 2003 09:34:35 +0100 (CET) (envelope-from sos@spider.deepcore.dk) Received: (from sos@localhost) by spider.deepcore.dk (8.12.10/8.12.10/Submit) id hAK8YYFh057725; Thu, 20 Nov 2003 09:34:34 +0100 (CET) (envelope-from sos) From: Soren Schmidt Message-Id: <200311200834.hAK8YYFh057725@spider.deepcore.dk> In-Reply-To: <20031120031150.GA759@timesink.dyndns.org> To: Thomas Moestl Date: Thu, 20 Nov 2003 09:34:34 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL99f (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 X-mail-scanned: by DeepCore Virus & Spam killer v1.3 cc: sparc64@FreeBSD.ORG cc: sos@FreeBSD.ORG cc: Kris Kennaway Subject: Re: ultra5/cmd646 hang X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2003 08:35:59 -0000 It seems Thomas Moestl wrote: > The issue is that the chip does not set ATA_BMSTAT_INTERRUPT, even though > it is DMA-capable. My hackaround is to add an interrupt handler for the > CMD646 that does only check this bit if a DMA transfer is in progress, > like it was done in pre-ATAng times. This probably isn't the best solution, > but it works for now. On the problematic boxen, you will also have to > set hw.ata.ata_dma=0 (they fell back to PIO before automatically anyway, > and DMA operations time out even if all interrupts are admitted). > I am not sure whether this is caused by some missing bit of setup that > is required, but that the firmware doesn't do for us, or whether it > applies only to some buggy/crippled chip revision in some machines. Hmm, the only 646 chip I hace sits in an alpha board which -current hasn't been upgraded for quite some time as it broke it (might be fixed in the meantime, I'll try to check.. However if that bit doesn't work the chip has *serious* problems and cannot be used in DMA mode at all. I dont recall seeing this problem on the one in my alpha though, so it might be specific to certain silicon (rev number cannot be trusted in old CMD chips either, they are so crappy its unbeliveable)... > Additionally, this patch should fix the panic that were reported on > request timeouts - the ata_request structure used to print the timeout > warning could already be freed at that point, causing references to > locations near 0xdeadc0de. I am not sure that the check for > (ch->running != request) is completely safe with this in mind, since > it could be possible that the request was freed and already reinserted. Right I have a local fix semilar to this, but yes the test could fail and I've looked at different ways to stay clear, but havn't decided yet (besides the chances are very small for this to happen)... > Søren, can you think of a reason why the interrupt bit would not be set? Bad silicon, broken design - both fit the CMD nicely :( > Otherwise, can you please take a look at the patch and tweak it so that > some fix for this problem can be committed? Yes, I'll see if I can get the alpha in the air with a new -current... -Søren