From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268537AbTGTUqT (ORCPT ); Sun, 20 Jul 2003 16:46:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268564AbTGTUqT (ORCPT ); Sun, 20 Jul 2003 16:46:19 -0400 Received: from astound-64-85-224-253.ca.astound.net ([64.85.224.253]:51471 "EHLO master.linux-ide.org") by vger.kernel.org with ESMTP id S268537AbTGTUp5 convert rfc822-to-8bit (ORCPT ); Sun, 20 Jul 2003 16:45:57 -0400 Date: Sun, 20 Jul 2003 13:53:39 -0700 (PDT) From: Andre Hedrick To: =?utf-8?q?J=C3=BCrgen=20Stohr?= cc: linux-kernel@vger.kernel.org, Alan Cox Subject: Re: BUG in pdc202xx_old.c In-Reply-To: <200307202206.21872.juergen.stohr@gmx.de> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Juergen: I have formally given up on Promise. If it works somebody take it and stuff it into a kernel tree it is a DGD for me now. DGD == Don't Giva Damn Cheers, Andre Hedrick LAD Storage Consulting Group On Sun, 20 Jul 2003, [utf-8] Jürgen Stohr wrote: > Hi Andre, > in pdc202xx_old.c is a bug that prevents the use of "66 Clocking". The driver > always falls back to UDMA 33. The reason for this bug is found in function > "config_chipset_for_dma" when checking if the "other" drive is capable of > UDMA 66. The follwing patch, which should apply against 2.4.22-pre7, solves > the problem for me: > > --- pdc202xx_old.c.broken 2003-07-20 20:12:39.000000000 +0200 > +++ pdc202xx_old.c 2003-07-20 20:18:50.000000000 +0200 > @@ -425,7 +425,7 @@ > * check to make sure drive on same channel > * is u66 capable > */ > - if (hwif->drives[!(drive->dn%2)].id) { > + if (hwif->drives[!(drive->dn%2)].present) { > if (hwif->drives[!(drive->dn%2)].id->dma_ultra > & 0x0078) { > hwif->OUTB(CLKSPD | mask, > (hwif->dma_master + 0x11)); > } else { > > regards, > Jürgen >