From patchwork Wed Nov 18 17:09:17 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mikulas Patocka X-Patchwork-Id: 38764 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id 3C082B6F0A for ; Thu, 19 Nov 2009 04:10:14 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757967AbZKRRJX (ORCPT ); Wed, 18 Nov 2009 12:09:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757968AbZKRRJX (ORCPT ); Wed, 18 Nov 2009 12:09:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50238 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757667AbZKRRJU (ORCPT ); Wed, 18 Nov 2009 12:09:20 -0500 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAIH9JOK002360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Nov 2009 12:09:19 -0500 Received: from hs20-bc2-1.build.redhat.com (hs20-bc2-1.build.redhat.com [10.10.28.34]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nAIH9HSA011885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 12:09:18 -0500 Received: from hs20-bc2-1.build.redhat.com (localhost.localdomain [127.0.0.1]) by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1) with ESMTP id nAIH9HmW012388; Wed, 18 Nov 2009 12:09:17 -0500 Received: from localhost (mpatocka@localhost) by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1/Submit) with ESMTP id nAIH9HR7012382; Wed, 18 Nov 2009 12:09:17 -0500 X-Authentication-Warning: hs20-bc2-1.build.redhat.com: mpatocka owned process doing -bs Date: Wed, 18 Nov 2009 12:09:17 -0500 (EST) From: Mikulas Patocka X-X-Sender: mpatocka@hs20-bc2-1.build.redhat.com To: David Miller cc: linux-ide@vger.kernel.org, alan@lxorguk.ukuu.org.uk Subject: Re: [PATCH] Don't use UDMA on VIA UDMA33 controller with Transcend SSD In-Reply-To: <20091117.043002.224755438.davem@davemloft.net> Message-ID: References: <20091026121804.3789c4c0@lxorguk.ukuu.org.uk> <20091117.043002.224755438.davem@davemloft.net> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.67 on 10.5.11.16 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ide@vger.kernel.org On Tue, 17 Nov 2009, David Miller wrote: > From: Mikulas Patocka > Date: Wed, 4 Nov 2009 20:25:21 -0500 (EST) > > > Don't use UDMA on VIA UDMA33 controller with Transcend SSD > > > > The computer locks up if Transcend SSD runs in any of UDMA modes. > > It doesn't lockup with different brand SSD, so this is specific to Transcend. > > > > Signed-off-by: Mikulas Patocka > > Mikulas, I'm happy to apply this if you match on the full > ID string, not just "TS". > > Please update your patch and I'll push it upstream. > > Thank you. Transcend makes various versions of their SSDs and all begin with TS. You can assume that Transcend SSDs with different capacity or format won't work too because they likely use the same controller. The naming is this: TS64GSSD25-M TS: Transcend 64G: capacity SSD25: 2.5" format -M: MLC So the problem is that if you match against the full string, you are going to miss the other Transcend devices and the patch becomes quite useless. If you want to harden it against false negatives, you can grep the string for "SSD", as in the patch below, but there is not anything better to do --- if you include "64G" in the string, you fail on non-64G devices, if you include "SSD25", you fail on 1.8" devices, if you include "-M", you fail on SLC. Mikulas Reviewed-by: Bartlomiej Zolnierkiewicz --- Don't use UDMA on VIA UDMA33 controller with Transcend SSD The computer locks up after if Transcend SSD runs in any of UDMA modes. It doesn't lockup with different brand SSD, so this is specific to Transcend. Signed-off-by: Mikulas Patocka --- drivers/ide/via82cxxx.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Index: linux-2.6.31.6-fast/drivers/ide/via82cxxx.c =================================================================== --- linux-2.6.31.6-fast.orig/drivers/ide/via82cxxx.c 2009-11-16 13:08:04.000000000 +0100 +++ linux-2.6.31.6-fast/drivers/ide/via82cxxx.c 2009-11-18 17:57:22.000000000 +0100 @@ -195,6 +195,22 @@ static void via_set_pio_mode(ide_drive_t via_set_drive(drive, XFER_PIO_0 + pio); } +static u8 via_udma_filter(ide_drive_t *drive) +{ + char *m = (char *)&drive->id[ATA_ID_PROD]; + + /* + * Restrict UDMA for Transcend flash cards. + * On VIA 33, UDMA locks up. On VIA 133, it works. I can't test other + * controllers. + */ + if (!memcmp(m, "TS", 2) && strstr(m, "SSD") && + drive->hwif->ultra_mask == ATA_UDMA2) + return 0; + + return drive->hwif->ultra_mask; +} + static struct via_isa_bridge *via_config_find(struct pci_dev **isa) { struct via_isa_bridge *via_config; @@ -372,6 +388,7 @@ static const struct ide_port_ops via_por .set_pio_mode = via_set_pio_mode, .set_dma_mode = via_set_drive, .cable_detect = via82cxxx_cable_detect, + .udma_filter = via_udma_filter, }; static const struct ide_port_info via82cxxx_chipset __devinitdata = {