From rostedt@goodmis.org Fri Nov 25 13:40:52 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 25 Nov 2005 13:43:05 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751478AbVKYVlw (ORCPT ); Fri, 25 Nov 2005 16:41:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751483AbVKYVld (ORCPT ); Fri, 25 Nov 2005 16:41:33 -0500 Received: from ms-smtp-04.nyroc.rr.com ([24.24.2.58]:48809 "EHLO ms-smtp-04.nyroc.rr.com") by vger.kernel.org with ESMTP id S1751478AbVKYVlc (ORCPT ); Fri, 25 Nov 2005 16:41:32 -0500 Received: from [192.168.23.10] (cpe-24-94-57-164.stny.res.rr.com [24.94.57.164]) by ms-smtp-04.nyroc.rr.com (8.12.10/8.12.10) with ESMTP id jAPLeq94019038; Fri, 25 Nov 2005 16:40:53 -0500 (EST) Subject: [PATCH] IDE compat_semaphore to completion From: Steven Rostedt To: Daniel Walker Cc: B.Zolnierkiewicz@elka.pw.edu.pl, LKML , linux-ide@vger.kernel.org, Ingo Molnar , Linus Torvalds , Andrew Morton , Aleksey Makarov In-Reply-To: <1132929218.11915.2.camel@localhost.localdomain> References: <438709F5.1050801@dev.rtsoft.ru> <1132929218.11915.2.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 25 Nov 2005 16:40:52 -0500 Message-Id: <1132954852.24417.20.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org The following patch is from Montavista. I modified it slightly. Semaphores are currently being used where it makes more sense for completions. This patch corrects that. -- Steve Signed-off-by: Steven Rostedt Source: MontaVista Software, Inc. Signed-off-by: Aleksey Makarov Description: The patch changes semaphores that are initialized as locked to complete(). Index: linux-2.6.15-rc2-git5/drivers/ide/ide-probe.c =================================================================== --- linux-2.6.15-rc2-git5.orig/drivers/ide/ide-probe.c 2005-11-23 07:59:15.000000000 -0500 +++ linux-2.6.15-rc2-git5/drivers/ide/ide-probe.c 2005-11-25 16:15:01.000000000 -0500 @@ -655,7 +655,7 @@ { ide_hwif_t *hwif = container_of(dev, ide_hwif_t, gendev); - up(&hwif->gendev_rel_sem); + complete(&hwif->gendev_rel_comp); } static void hwif_register (ide_hwif_t *hwif) @@ -1325,7 +1325,7 @@ drive->queue = NULL; spin_unlock_irq(&ide_lock); - up(&drive->gendev_rel_sem); + complete(&drive->gendev_rel_comp); } /* Index: linux-2.6.15-rc2-git5/drivers/ide/ide.c =================================================================== --- linux-2.6.15-rc2-git5.orig/drivers/ide/ide.c 2005-11-23 07:59:15.000000000 -0500 +++ linux-2.6.15-rc2-git5/drivers/ide/ide.c 2005-11-25 16:15:01.000000000 -0500 @@ -222,7 +222,7 @@ hwif->mwdma_mask = 0x80; /* disable all mwdma */ hwif->swdma_mask = 0x80; /* disable all swdma */ - sema_init(&hwif->gendev_rel_sem, 0); + init_completion(&hwif->gendev_rel_comp); default_hwif_iops(hwif); default_hwif_transport(hwif); @@ -245,7 +245,7 @@ drive->is_flash = 0; drive->vdma = 0; INIT_LIST_HEAD(&drive->list); - sema_init(&drive->gendev_rel_sem, 0); + init_completion(&drive->gendev_rel_comp); } } @@ -602,7 +602,7 @@ } spin_unlock_irq(&ide_lock); device_unregister(&drive->gendev); - down(&drive->gendev_rel_sem); + wait_for_completion(&drive->gendev_rel_comp); spin_lock_irq(&ide_lock); } hwif->present = 0; @@ -662,7 +662,7 @@ /* More messed up locking ... */ spin_unlock_irq(&ide_lock); device_unregister(&hwif->gendev); - down(&hwif->gendev_rel_sem); + wait_for_completion(&hwif->gendev_rel_comp); /* * Remove us from the kernel's knowledge Index: linux-2.6.15-rc2-git5/include/linux/ide.h =================================================================== --- linux-2.6.15-rc2-git5.orig/include/linux/ide.h 2005-11-23 07:59:21.000000000 -0500 +++ linux-2.6.15-rc2-git5/include/linux/ide.h 2005-11-25 16:25:21.000000000 -0500 @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include @@ -759,7 +760,7 @@ int crc_count; /* crc counter to reduce drive speed */ struct list_head list; struct device gendev; - struct semaphore gendev_rel_sem; /* to deal with device release() */ + struct completion gendev_rel_comp; /* to deal with device release() */ } ide_drive_t; #define to_ide_device(dev)container_of(dev, ide_drive_t, gendev) @@ -915,7 +916,7 @@ unsigned sg_mapped : 1; /* sg_table and sg_nents are ready */ struct device gendev; - struct semaphore gendev_rel_sem; /* To deal with device release() */ + struct completion gendev_rel_comp; /* To deal with device release() */ void *hwif_data; /* extra hwif data */ - 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 From rostedt@goodmis.org Fri Nov 25 14:46:21 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 25 Nov 2005 14:49:00 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932380AbVKYWql (ORCPT ); Fri, 25 Nov 2005 17:46:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932418AbVKYWql (ORCPT ); Fri, 25 Nov 2005 17:46:41 -0500 Received: from ms-smtp-01.nyroc.rr.com ([24.24.2.55]:51391 "EHLO ms-smtp-01.nyroc.rr.com") by vger.kernel.org with ESMTP id S932380AbVKYWqk (ORCPT ); Fri, 25 Nov 2005 17:46:40 -0500 Received: from [192.168.23.10] (cpe-24-94-57-164.stny.res.rr.com [24.94.57.164]) by ms-smtp-01.nyroc.rr.com (8.12.10/8.12.10) with ESMTP id jAPMkLFe010810; Fri, 25 Nov 2005 17:46:22 -0500 (EST) Subject: [PATCH] 2.6.14-rt15 IDE compat_semaphore to completion From: Steven Rostedt To: Ingo Molnar Cc: LKML , Daniel Walker , Aleksey Makarov In-Reply-To: <1132929218.11915.2.camel@localhost.localdomain> References: <438709F5.1050801@dev.rtsoft.ru> <1132929218.11915.2.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 25 Nov 2005 17:46:21 -0500 Message-Id: <1132958781.24417.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Ingo, Here's a patch from MontaVista, that I slightly modified. I sent this to the mainline as well (you were CC'd). -- Steve Source: MontaVista Software, Inc. MR: 14219 Type: Defect fix Disposition: Should be submitted to lkml Signed-off-by: Aleksey Makarov Description: The patch changes semaphores that are initialized as locked to complete(). Index: linux-2.6.14-rt13/drivers/ide/ide-probe.c =================================================================== --- linux-2.6.14-rt13.orig/drivers/ide/ide-probe.c 2005-11-17 17:43:04.000000000 -0500 +++ linux-2.6.14-rt13/drivers/ide/ide-probe.c 2005-11-17 17:46:01.000000000 -0500 @@ -656,7 +656,7 @@ { ide_hwif_t *hwif = container_of(dev, ide_hwif_t, gendev); - up(&hwif->gendev_rel_sem); + complete(&hwif->gendev_rel_comp); } static void hwif_register (ide_hwif_t *hwif) @@ -1328,7 +1328,7 @@ drive->queue = NULL; spin_unlock_irq(&ide_lock); - up(&drive->gendev_rel_sem); + complete(&drive->gendev_rel_comp); } /* Index: linux-2.6.14-rt13/drivers/ide/ide.c =================================================================== --- linux-2.6.14-rt13.orig/drivers/ide/ide.c 2005-11-17 17:43:04.000000000 -0500 +++ linux-2.6.14-rt13/drivers/ide/ide.c 2005-11-17 17:45:31.000000000 -0500 @@ -222,7 +222,7 @@ hwif->mwdma_mask = 0x80; /* disable all mwdma */ hwif->swdma_mask = 0x80; /* disable all swdma */ - sema_init(&hwif->gendev_rel_sem, 0); + init_completion(&hwif->gendev_rel_comp); default_hwif_iops(hwif); default_hwif_transport(hwif); @@ -245,7 +245,7 @@ drive->is_flash = 0; drive->vdma = 0; INIT_LIST_HEAD(&drive->list); - sema_init(&drive->gendev_rel_sem, 0); + init_completion(&drive->gendev_rel_comp); } } @@ -602,7 +602,7 @@ } spin_unlock_irq(&ide_lock); device_unregister(&drive->gendev); - down(&drive->gendev_rel_sem); + wait_for_completion(&drive->gendev_rel_comp); spin_lock_irq(&ide_lock); } hwif->present = 0; @@ -662,7 +662,7 @@ /* More messed up locking ... */ spin_unlock_irq(&ide_lock); device_unregister(&hwif->gendev); - down(&hwif->gendev_rel_sem); + wait_for_completion(&hwif->gendev_rel_comp); /* * Remove us from the kernel's knowledge Index: linux-2.6.14-rt13/include/linux/ide.h =================================================================== --- linux-2.6.14-rt13.orig/include/linux/ide.h 2005-11-17 17:43:04.000000000 -0500 +++ linux-2.6.14-rt13/include/linux/ide.h 2005-11-17 17:44:36.000000000 -0500 @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include @@ -754,7 +755,7 @@ int crc_count; /* crc counter to reduce drive speed */ struct list_head list; struct device gendev; - struct compat_semaphore gendev_rel_sem; /* to deal with device release() */ + struct completion gendev_rel_comp; /* to deal with device release() */ } ide_drive_t; #define to_ide_device(dev)container_of(dev, ide_drive_t, gendev) @@ -910,7 +911,7 @@ unsigned sg_mapped : 1; /* sg_table and sg_nents are ready */ struct device gendev; - struct semaphore gendev_rel_sem; /* To deal with device release() */ + struct completion gendev_rel_comp; /* To deal with device release() */ void *hwif_data; /* extra hwif data */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From reuben-lkml@reub.net Sat Nov 26 01:09:47 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Sat, 26 Nov 2005 01:10:10 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750704AbVKZJJu (ORCPT ); Sat, 26 Nov 2005 04:09:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750701AbVKZJJt (ORCPT ); Sat, 26 Nov 2005 04:09:49 -0500 Received: from tornado.reub.net ([202.89.145.182]:26308 "EHLO tornado.reub.net") by vger.kernel.org with ESMTP id S1750704AbVKZJJt (ORCPT ); Sat, 26 Nov 2005 04:09:49 -0500 Received: from [192.168.0.8] (typhoon.reub.net [192.168.0.8]) by tornado.reub.net (Postfix) with ESMTP id 8E24738D13; Sat, 26 Nov 2005 22:09:46 +1300 (NZDT) Message-ID: <4388265B.8020309@reub.net> Date: Sat, 26 Nov 2005 22:09:47 +1300 From: Reuben Farrelly User-Agent: Thunderbird 1.6a1 (Windows/20051125) MIME-Version: 1.0 To: "Randy.Dunlap" CC: jgarzik@pobox.com, linux-ide@vger.kernel.org Subject: Re: Problems with SATA/AHCI with 'nosmp' boot option References: <43312397.9080501@reub.net> <43425A0E.9050500@pobox.com> <437D5E36.7000103@reub.net> <20051117230701.1684a43e.rdunlap@xenotime.net> In-Reply-To: <20051117230701.1684a43e.rdunlap@xenotime.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Hi again Randy and others, On 18/11/2005 8:07 p.m., Randy.Dunlap wrote: > On Fri, 18 Nov 2005 17:53:10 +1300 Reuben Farrelly wrote: > >> Hi, >> >> On 4/10/2005 11:31 p.m., Jeff Garzik wrote: >>> Reuben Farrelly wrote: >>>> Hi, >>>> >>>> While trying to gather more info about a problem with the latest >>>> sky2.c Gig ethernet driver hanging, I thought I'd boot my SMP built >>>> kernel (on an SMP/HT machine) with the 'nosmp' boot option. >>>> >>>> However when I did this, I could no longer boot the machine, because >>>> the ahci >>>> driver reported timeouts when probing the drives attached to the SATA >>>> ports, like this: >>>> >>>> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 >>>> ide: Assuming 33MHz system bus speed for PIO modes; override with >>>> idebus=xx >>>> ICH6: IDE controller at PCI slot 0000:00:1f.1 >>>> ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 73 >>>> ICH6: chipset revision 3 >>>> ICH6: not 100% native mode: will probe irqs later >>>> ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:pio, hdb:pio >>>> ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio >>>> ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 81 >>>> ahci(0000:00:1f.2) AHCI 0001.0000 32 slots 4 ports 1.5 Gbps 0xf impl >>>> SATA mode >>>> ahci(0000:00:1f.2) flags: 64bit ncq led slum part >>>> ata1: SATA max UDMA/133 cmd 0xF8806D00 ctl 0x0 bmdma 0x0 irq 81 >>>> ata2: SATA max UDMA/133 cmd 0xF8806D80 ctl 0x0 bmdma 0x0 irq 81 >>>> ata3: SATA max UDMA/133 cmd 0xF8806E00 ctl 0x0 bmdma 0x0 irq 81 >>>> ata4: SATA max UDMA/133 cmd 0xF8806E80 ctl 0x0 bmdma 0x0 irq 81 >>>> ata1 is slow to respond, please be patient >>>> ata1 failed to respond (30 secs) >>>> scsi0 : ahci >>>> ata2 is slow to respond, please be patient >>>> ata2 failed to respond (30 secs) >>> Sounds like AHCI or MSI is broken. >>> >>> Jeff >> I am still seeing this on 2.6.15-rc1-mm1. I don't think we got any further >> than to conclude it _might_ be AHCI or MSI. >> >> What other information is required for me to be able to help someone look >> closer and/or resolve this bug? >> >> I have information about my system up at http://www.reub.net/kernel/ including >> some system specifications and my .config. (It's a lot easier to put it there >> than attaching to every email) > > Hi, > > Jeff sent a message to lkml yesterday that he is seeing some > bad results with MSI interrupts: > http://lkml.org/lkml/2005/11/17/4 > > Hopefully that will get some results, although not yet AFAIK. > > --- > ~Randy I've just compiled up a 2.6.15-rc2-mm1 but without PCI-X and also without MSI support, and I'm seeing the same problem of AHCI timing out when booting with the nosmp option. I guess this looks more like an AHCI issue rather than MSI? I have put up an updated boot dump on http://www.reub.net/files/kernel/ Reuben - 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 From eyal@eyal.emu.id.au Sat Nov 26 01:10:58 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Sat, 26 Nov 2005 01:11:07 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750701AbVKZJLE (ORCPT ); Sat, 26 Nov 2005 04:11:04 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750728AbVKZJLE (ORCPT ); Sat, 26 Nov 2005 04:11:04 -0500 Received: from ihug-mail.icp-qv1-irony5.iinet.net.au ([203.59.1.199]:56496 "EHLO mail-ihug.icp-qv1-irony5.iinet.net.au") by vger.kernel.org with ESMTP id S1750701AbVKZJLD (ORCPT ); Sat, 26 Nov 2005 04:11:03 -0500 Received: from 202-161-15-66.dyn.iinet.net.au (HELO e4.eyal.emu.id.au) ([202.161.15.66]) by mail-ihug.icp-qv1-irony5.iinet.net.au with ESMTP; 26 Nov 2005 17:11:01 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from [192.168.3.7] (e7.eyal.emu.id.au [192.168.3.7]) by e4.eyal.emu.id.au (8.11.6/8.11.6) with ESMTP id jAQ9AxP14893 for ; Sat, 26 Nov 2005 20:10:59 +1100 Message-ID: <438826A2.2020204@eyal.emu.id.au> Date: Sat, 26 Nov 2005 20:10:58 +1100 From: Eyal Lebedinsky Organization: Eyal at Home User-Agent: Debian Thunderbird 1.0.2 (X11/20051002) X-Accept-Language: en-us, en MIME-Version: 1.0 To: list linux-ide Subject: Q: IDE->SATA adaptor X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org I am still looking for a working setup for adding more SATA disks to my machine. I acquired a small PCB that plugs into the IDE socket on the mobo and provides two SATA sockets. It worked out of the box, except that it only does udma2. Not what I want. If I try to set it to a higher mode I get the message hdc: Speed warnings UDMA 3/4/5 is not functional. After some digging into the ide code I identified the problem as 'id->hw_config' being zero. In two places it is checked before allowing higher udma modes. One bit seems to be related to the 80c (which has no meaning here and should probably be hardwired on the board) and the other I am not sure. I patched ide-iops.c to not check hw_config in the two funcs where it does so: eighty_ninty_three ide_ata66_check BTW my .config says: CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_IVB=y CONFIG_IDEDMA_AUTO=y but the IVB is not enough here. Does anyone know what is the correct way to get this adapter going without a patch? I should say that the disks do identify themselves correctly (see below) but the kernel only accept some modes: # hdparm -i /dev/hdc ================== /dev/hdc: Model=WDC WD3200JD-00KLB0, FwRev=08.05J08, SerialNo=WD-WCAMR1427570 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 AdvancedPM=no WriteCache=enabled Drive conforms to: device does not report version: * signifies the current active mode # hdparm -I /dev/hdc ================== /dev/hdc: ATA device, with non-removable media Model Number: WDC WD3200JD-00KLB0 Serial Number: WD-WCAMR1427570 Firmware Revision: 08.05J08 Standards: Supported: 6 5 4 3 Likely used: 6 Configuration: Logical max current cylinders 16383 65535 heads 16 1 sectors/track 63 63 -- CHS current addressable sectors: 4128705 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 625142448 device size with M = 1024*1024: 305245 MBytes device size with M = 1000*1000: 320072 MBytes (320 GB) Capabilities: LBA, IORDY(can be disabled) bytes avail on r/w long: 4 Queue depth: 1 Standby timer values: spec'd by Standard, with device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Recommended acoustic management value: 128, current value: 254 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: * READ BUFFER cmd * WRITE BUFFER cmd * Host Protected Area feature set * Look-ahead * Write cache * Power Management feature set Security Mode feature set SMART feature set * FLUSH CACHE EXT command * Mandatory FLUSH CACHE command * Device Configuration Overlay feature set * 48-bit Address feature set Automatic Acoustic Management feature set SET MAX security extension * DOWNLOAD MICROCODE cmd * SMART self-test * SMART error logging Security: Master password revision code = 65534 supported not enabled not locked not frozen not expired: security count not supported: enhanced erase Checksum: correct -- Eyal Lebedinsky (eyal@eyal.emu.id.au) attach .zip as .dat - 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 From vojtech@suse.cz Sat Nov 26 03:28:44 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Sat, 26 Nov 2005 03:29:21 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750828AbVKZL3H (ORCPT ); Sat, 26 Nov 2005 06:29:07 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750829AbVKZL3G (ORCPT ); Sat, 26 Nov 2005 06:29:06 -0500 Received: from styx.suse.cz ([82.119.242.94]:59566 "EHLO mail.suse.cz") by vger.kernel.org with ESMTP id S1750828AbVKZL3F (ORCPT ); Sat, 26 Nov 2005 06:29:05 -0500 Received: from vpnhost02.suse.cz (twilight.ucw.cz [81.30.235.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 721466283D6; Sat, 26 Nov 2005 12:29:02 +0100 (CET) Received: by vpnhost02.suse.cz (Postfix, from userid 1000) id 3AB1188238; Sat, 26 Nov 2005 12:28:44 +0100 (CET) Date: Sat, 26 Nov 2005 12:28:44 +0100 From: Vojtech Pavlik To: Eyal Lebedinsky Cc: list linux-ide Subject: Re: Q: IDE->SATA adaptor Message-ID: <20051126112844.GA10006@midnight.suse.cz> References: <438826A2.2020204@eyal.emu.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438826A2.2020204@eyal.emu.id.au> X-Bounce-Cookie: It's a lemon tree, dear Watson! User-Agent: Mutt/1.5.10i Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org On Sat, Nov 26, 2005 at 08:10:58PM +1100, Eyal Lebedinsky wrote: > I am still looking for a working setup for adding more SATA > disks to my machine. I acquired a small PCB that plugs into > the IDE socket on the mobo and provides two SATA sockets. > > It worked out of the box, except that it only does udma2. Not > what I want. > > If I try to set it to a higher mode I get the message > hdc: Speed warnings UDMA 3/4/5 is not functional. > > After some digging into the ide code I identified the problem > as 'id->hw_config' being zero. In two places it is checked > before allowing higher udma modes. One bit seems to be related > to the 80c (which has no meaning here and should probably > be hardwired on the board) and the other I am not sure. What IDE controller are you using? > I patched ide-iops.c to not check hw_config in the two funcs > where it does so: > eighty_ninty_three > ide_ata66_check > > > BTW my .config says: > CONFIG_BLK_DEV_IDEDMA=y > CONFIG_IDEDMA_IVB=y > CONFIG_IDEDMA_AUTO=y > > but the IVB is not enough here. > > > Does anyone know what is the correct way to get this adapter going without > a patch? I think specifying "ide0=ata66" on the kernel command line could help. > I should say that the disks do identify themselves correctly (see below) > but the kernel only accept some modes: > > # hdparm -i /dev/hdc > ================== > /dev/hdc: > > Model=WDC WD3200JD-00KLB0, FwRev=08.05J08, SerialNo=WD-WCAMR1427570 > Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq } > RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4 > BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16 > CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455 > IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} > PIO modes: pio0 pio3 pio4 > DMA modes: mdma0 mdma1 mdma2 > UDMA modes: udma0 udma1 udma2 > AdvancedPM=no WriteCache=enabled > Drive conforms to: device does not report version: > > * signifies the current active mode > > > # hdparm -I /dev/hdc > ================== > /dev/hdc: > > ATA device, with non-removable media > Model Number: WDC WD3200JD-00KLB0 > Serial Number: WD-WCAMR1427570 > Firmware Revision: 08.05J08 > Standards: > Supported: 6 5 4 3 > Likely used: 6 > Configuration: > Logical max current > cylinders 16383 65535 > heads 16 1 > sectors/track 63 63 > -- > CHS current addressable sectors: 4128705 > LBA user addressable sectors: 268435455 > LBA48 user addressable sectors: 625142448 > device size with M = 1024*1024: 305245 MBytes > device size with M = 1000*1000: 320072 MBytes (320 GB) > Capabilities: > LBA, IORDY(can be disabled) > bytes avail on r/w long: 4 Queue depth: 1 > Standby timer values: spec'd by Standard, with device specific minimum > R/W multiple sector transfer: Max = 16 Current = 16 > Recommended acoustic management value: 128, current value: 254 > DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 > Cycle time: min=120ns recommended=120ns > PIO: pio0 pio1 pio2 pio3 pio4 > Cycle time: no flow control=120ns IORDY flow control=120ns > Commands/features: > Enabled Supported: > * READ BUFFER cmd > * WRITE BUFFER cmd > * Host Protected Area feature set > * Look-ahead > * Write cache > * Power Management feature set > Security Mode feature set > SMART feature set > * FLUSH CACHE EXT command > * Mandatory FLUSH CACHE command > * Device Configuration Overlay feature set > * 48-bit Address feature set > Automatic Acoustic Management feature set > SET MAX security extension > * DOWNLOAD MICROCODE cmd > * SMART self-test > * SMART error logging > Security: > Master password revision code = 65534 > supported > not enabled > not locked > not frozen > not expired: security count > not supported: enhanced erase > Checksum: correct > > -- > Eyal Lebedinsky (eyal@eyal.emu.id.au) > attach .zip as .dat > - > 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 > -- Vojtech Pavlik SuSE Labs, SuSE CR - 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 From eyal@eyal.emu.id.au Sat Nov 26 04:32:58 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Sat, 26 Nov 2005 04:33:08 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932113AbVKZMdF (ORCPT ); Sat, 26 Nov 2005 07:33:05 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750865AbVKZMdF (ORCPT ); Sat, 26 Nov 2005 07:33:05 -0500 Received: from ihug-mail.icp-qv1-irony4.iinet.net.au ([203.59.1.198]:62011 "EHLO mail-ihug.icp-qv1-irony4.iinet.net.au") by vger.kernel.org with ESMTP id S1750854AbVKZMdD (ORCPT ); Sat, 26 Nov 2005 07:33:03 -0500 Received: from 202-161-15-66.dyn.iinet.net.au (HELO e4.eyal.emu.id.au) ([202.161.15.66]) by mail-ihug.icp-qv1-irony4.iinet.net.au with ESMTP; 26 Nov 2005 20:33:01 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from [192.168.3.7] (e7.eyal.emu.id.au [192.168.3.7]) by e4.eyal.emu.id.au (8.11.6/8.11.6) with ESMTP id jAQCWwP15138; Sat, 26 Nov 2005 23:32:59 +1100 Message-ID: <438855FA.6050100@eyal.emu.id.au> Date: Sat, 26 Nov 2005 23:32:58 +1100 From: Eyal Lebedinsky Organization: Eyal at Home User-Agent: Debian Thunderbird 1.0.2 (X11/20051002) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vojtech Pavlik CC: list linux-ide Subject: Re: Q: IDE->SATA adaptor References: <438826A2.2020204@eyal.emu.id.au> <20051126112844.GA10006@midnight.suse.cz> In-Reply-To: <20051126112844.GA10006@midnight.suse.cz> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Vojtech Pavlik wrote: > On Sat, Nov 26, 2005 at 08:10:58PM +1100, Eyal Lebedinsky wrote: > >>I am still looking for a working setup for adding more SATA >>disks to my machine. I acquired a small PCB that plugs into >>the IDE socket on the mobo and provides two SATA sockets. >> >>It worked out of the box, except that it only does udma2. Not >>what I want. >> >>If I try to set it to a higher mode I get the message >> hdc: Speed warnings UDMA 3/4/5 is not functional. >> >>After some digging into the ide code I identified the problem >>as 'id->hw_config' being zero. In two places it is checked >>before allowing higher udma modes. One bit seems to be related >>to the 80c (which has no meaning here and should probably >>be hardwired on the board) and the other I am not sure. > > > What IDE controller are you using? I do not think that it matters. ide0 sees its disks just fine. ide1 had no problems in the past. It is only when the adaptor is plugged in that this problem is seen. Nevertheless, this is an ICH5: 0000:00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra ATA 100 Storage Controller (rev 02) >>I patched ide-iops.c to not check hw_config in the two funcs >>where it does so: >> eighty_ninty_three >> ide_ata66_check >> >> >>BTW my .config says: >> CONFIG_BLK_DEV_IDEDMA=y >> CONFIG_IDEDMA_IVB=y >> CONFIG_IDEDMA_AUTO=y >> >>but the IVB is not enough here. >> >> >>Does anyone know what is the correct way to get this adapter going without >>a patch? > > I think specifying "ide0=ata66" on the kernel command line could help. I added 'ide1=ata66' and it did not help. I also got the messages: Kernel command line: BOOT_IMAGE=2.6.14.3 ro root=306 console=ttyS0,38400 console=tty0 irqpoll ide1=ata66 single ide_setup: ide1=ata66 -- OBSOLETE OPTION, WILL BE REMOVED SOON! -- Eyal Lebedinsky (eyal@eyal.emu.id.au) attach .zip as .dat - 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 From raziebe@gmail.com Sat Nov 26 05:45:24 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Sat, 26 Nov 2005 05:45:40 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964769AbVKZNp0 (ORCPT ); Sat, 26 Nov 2005 08:45:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964779AbVKZNp0 (ORCPT ); Sat, 26 Nov 2005 08:45:26 -0500 Received: from wproxy.gmail.com ([64.233.184.206]:16174 "EHLO wproxy.gmail.com") by vger.kernel.org with ESMTP id S964769AbVKZNpZ convert rfc822-to-8bit (ORCPT ); Sat, 26 Nov 2005 08:45:25 -0500 Received: by wproxy.gmail.com with SMTP id 70so1422235wra for ; Sat, 26 Nov 2005 05:45:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=TDLVGPdBWWVu6qJ+BVNLrwXkuUm18Em/ednqVT8z7a58+nQRIoI3X1yU+jPGwy3Lta3GvcZmvl8tb/B3CjYnOczMMVy7//nIvasatVYu0mXP0TdFmtI1QKptwdBirxFxETPR0MPIPQnb4KuGGE4tok/rzIeO1zQdW9UZWfXiOC0= Received: by 10.54.101.20 with SMTP id y20mr6034111wrb; Sat, 26 Nov 2005 05:45:24 -0800 (PST) Received: by 10.54.122.20 with HTTP; Sat, 26 Nov 2005 05:45:24 -0800 (PST) Message-ID: <5d96567b0511260545j61970a01j3b5c435766a51a6d@mail.gmail.com> Date: Sat, 26 Nov 2005 05:45:24 -0800 From: "Raz Ben-Jehuda(caro)" To: jgarzik@pobox.com Subject: cpu consumption Cc: linux-ide@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Disposition: inline Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Hello Jeff. Here is my problem. When I issue a READ operation over a SATA disk in linux i have huge cpu consumption , about 90% cpu usage. I am using MAXTOR disks in a supermicro machine. the cpu test was made when i "raw read" from the DISK using DIRECT_IO. XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX this is my dmesg. ata1: SATA max UDMA/133 cmd 0xE900 ctl 0xEA02 bmdma 0xED00 irq 10 ata2: SATA max UDMA/133 cmd 0xEB00 ctl 0xEC02 bmdma 0xED08 irq 10 ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4673 85:7c69 86:3e01 87:4663 88:207f ata1: dev 0 ATA, max UDMA/133, 490234752 sectors: lba48 ata1: dev 0 configured for UDMA/133 scsi0 : ata_piix ata2: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4673 85:7c69 86:3e01 87:4663 88:207f ata2: dev 0 ATA, max UDMA/133, 490234752 sectors: lba48 ata2: dev 0 configured for UDMA/133 scsi1 : ata_piix Vendor: ATA Model: Maxtor 7L250S0 Rev: BANC Type: Direct-Access ANSI SCSI revision: 05 Vendor: ATA Model: Maxtor 7L250S0 Rev: BANC Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) SCSI device sda: drive cache: write back SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) SCSI device sda: drive cache: write back /dev/scsi/host0/bus0/target0/lun0: p1 p2 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 SCSI device sdb: 490234752 512-byte hdwr sectors (251000 MB) SCSI device sdb: drive cache: write back SCSI device sdb: 490234752 512-byte hdwr sectors (251000 MB) SCSI device sdb: drive cache: write back /dev/scsi/host1/bus0/target0/lun0: Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0 Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0 Attached scsi generic sg1 at scsi1, channel 0, id 0, lun 0, type 0 mice: PS/2 mouse device common for all mice i2c /dev entries driver md: linear personality registered as nr 1 md: raid0 personality registered as nr 2 md: raid1 personality registered as nr 3 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Thank you. -- Raz - 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 From dom@ijichi.org Sat Nov 26 07:56:22 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Sat, 26 Nov 2005 07:56:30 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422657AbVKZP43 (ORCPT ); Sat, 26 Nov 2005 10:56:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964800AbVKZP43 (ORCPT ); Sat, 26 Nov 2005 10:56:29 -0500 Received: from buffy.ijichi.org ([213.161.76.94]:19706 "EHLO buffy.ijichi.org") by vger.kernel.org with ESMTP id S964799AbVKZP42 (ORCPT ); Sat, 26 Nov 2005 10:56:28 -0500 Received: from localhost (localhost [127.0.0.1]) by buffy.ijichi.org (Postfix) with ESMTP id B8ADC183E7 for ; Sat, 26 Nov 2005 15:56:26 +0000 (GMT) Received: from buffy.ijichi.org ([127.0.0.1]) by localhost (buffy.ijichi.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04079-05 for ; Sat, 26 Nov 2005 15:56:22 +0000 (GMT) Received: by buffy.ijichi.org (Postfix, from userid 502) id ADE0618333; Sat, 26 Nov 2005 15:56:22 +0000 (GMT) Received: from 81-178-109-8.dsl.pipex.com (81-178-109-8.dsl.pipex.com [81.178.109.8]) by www.ijichi.org (IMP) with HTTP for ; Sat, 26 Nov 2005 15:56:22 +0000 Message-ID: <1133020582.438885a6615dc@www.ijichi.org> Date: Sat, 26 Nov 2005 15:56:22 +0000 From: Dominic Ijichi To: linux-ide@vger.kernel.org Subject: sata suspend status? MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Priority: 3 (Normal) X-Originating-IP: 81.178.109.8 X-DSPAM-Result: Innocent X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 438885a9449291284361 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at ijichi.org X-Spam-Status: No, score=-2.453 tagged_above=-999 required=6.31 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DSPAM_HAM=-0.1, RCVD_IN_SORBS_DUL=2.046] X-Spam-Score: -2.453 X-Spam-Level: Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org hello i've been trying to get my laptop s3 suspend working - its all working except I believe for sata. it resumes and you can do type in, interact with the kernel but as soon as you do anything that requires disk access it hangs. sorry if this isn't very technical description, i can provide anything if told roughly what to do! i've searched extensively for patches, tried all the various incantations, and currently running 2.6.15-rc2 which is supposed to provide support for ata passthrough and basic scsi suspend, but still same problem. i have: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 04) /dev/sda = HITACHI_DK23FA-60 hdparm -I /dev/sda works fine. I note recent patches from randy dunlap from intel to do with this controller and acpi but not sure what kernel this is against or whether it's relevent. i believe there are many people out there who would love to get sata suspend/resume working, its a major problem for all recent laptops and us folks who love running linux. what's the current status please? thanks dom ------------------------------------------ This message was penned by the hand of Dom - 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 From ricknu-0@student.ltu.se Sat Nov 26 15:35:33 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Sat, 26 Nov 2005 15:30:46 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750783AbVKZXai (ORCPT ); Sat, 26 Nov 2005 18:30:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750784AbVKZXai (ORCPT ); Sat, 26 Nov 2005 18:30:38 -0500 Received: from gepetto.dc.ltu.se ([130.240.42.40]:934 "EHLO gepetto.dc.ltu.se") by vger.kernel.org with ESMTP id S1750783AbVKZXai (ORCPT ); Sat, 26 Nov 2005 18:30:38 -0500 Received: from [130.240.205.31] (thinktank.campus.luth.se [130.240.205.31]) by gepetto.dc.ltu.se (8.12.5/8.12.5) with ESMTP id jAQNUKDT028084; Sun, 27 Nov 2005 00:30:20 +0100 (MET) Message-ID: <4388F145.3060308@student.ltu.se> Date: Sun, 27 Nov 2005 00:35:33 +0100 From: Richard Knutsson User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: benh@kernel.crashing.org, jgarzik@pobox.com CC: linux-ide@vger.kernel.org Subject: [PATCH 2.6.15-rc2-mm1] scsi: fix compiler-warning for sata_svw.c Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org From: Richard Knutsson Fix compiler-warning "... makes pointer from integer without a cast". Signed-off-by: Richard Knutsson --- sata_svw.c | 65 ++++++++++++++++++++++++++++++++----------------------------- 1 files changed, 35 insertions(+), 30 deletions(-) --- a/drivers/scsi/sata_svw.c 2005-11-26 21:41:35.000000000 +0100 +++ b/drivers/scsi/sata_svw.c 2005-11-26 23:46:32.000000000 +0100 @@ -110,26 +110,31 @@ static void k2_sata_tf_load(struct ata_p unsigned int is_addr = tf->flags & ATA_TFLAG_ISADDR; if (tf->ctl != ap->last_ctl) { - writeb(tf->ctl, ioaddr->ctl_addr); + writeb(tf->ctl, (void *) ioaddr->ctl_addr); ap->last_ctl = tf->ctl; ata_wait_idle(ap); } if (is_addr && (tf->flags & ATA_TFLAG_LBA48)) { - writew(tf->feature | (((u16)tf->hob_feature) << 8), ioaddr->feature_addr); - writew(tf->nsect | (((u16)tf->hob_nsect) << 8), ioaddr->nsect_addr); - writew(tf->lbal | (((u16)tf->hob_lbal) << 8), ioaddr->lbal_addr); - writew(tf->lbam | (((u16)tf->hob_lbam) << 8), ioaddr->lbam_addr); - writew(tf->lbah | (((u16)tf->hob_lbah) << 8), ioaddr->lbah_addr); + writew(tf->feature | (((u16)tf->hob_feature) << 8), + (void *) ioaddr->feature_addr); + writew(tf->nsect | (((u16)tf->hob_nsect) << 8), + (void *) ioaddr->nsect_addr); + writew(tf->lbal | (((u16)tf->hob_lbal) << 8), + (void *) ioaddr->lbal_addr); + writew(tf->lbam | (((u16)tf->hob_lbam) << 8), + (void *) ioaddr->lbam_addr); + writew(tf->lbah | (((u16)tf->hob_lbah) << 8), + (void *) ioaddr->lbah_addr); } else if (is_addr) { - writew(tf->feature, ioaddr->feature_addr); - writew(tf->nsect, ioaddr->nsect_addr); - writew(tf->lbal, ioaddr->lbal_addr); - writew(tf->lbam, ioaddr->lbam_addr); - writew(tf->lbah, ioaddr->lbah_addr); + writew(tf->feature, (void *) ioaddr->feature_addr); + writew(tf->nsect, (void *) ioaddr->nsect_addr); + writew(tf->lbal, (void *) ioaddr->lbal_addr); + writew(tf->lbam, (void *) ioaddr->lbam_addr); + writew(tf->lbah, (void *) ioaddr->lbah_addr); } if (tf->flags & ATA_TFLAG_DEVICE) - writeb(tf->device, ioaddr->device_addr); + writeb(tf->device, (void *) ioaddr->device_addr); ata_wait_idle(ap); } @@ -140,26 +145,26 @@ static void k2_sata_tf_read(struct ata_p struct ata_ioports *ioaddr = &ap->ioaddr; u16 nsect, lbal, lbam, lbah, feature; - tf->command = k2_stat_check_status(ap); - tf->device = readw(ioaddr->device_addr); - feature = readw(ioaddr->error_addr); - nsect = readw(ioaddr->nsect_addr); - lbal = readw(ioaddr->lbal_addr); - lbam = readw(ioaddr->lbam_addr); - lbah = readw(ioaddr->lbah_addr); - - tf->feature = feature; - tf->nsect = nsect; - tf->lbal = lbal; - tf->lbam = lbam; - tf->lbah = lbah; + tf->command = k2_stat_check_status(ap); + tf->device = readw((void *) ioaddr->device_addr); + feature = readw((void *) ioaddr->error_addr); + nsect = readw((void *) ioaddr->nsect_addr); + lbal = readw((void *) ioaddr->lbal_addr); + lbam = readw((void *) ioaddr->lbam_addr); + lbah = readw((void *) ioaddr->lbah_addr); + + tf->feature = feature; + tf->nsect = nsect; + tf->lbal = lbal; + tf->lbam = lbam; + tf->lbah = lbah; if (tf->flags & ATA_TFLAG_LBA48) { - tf->hob_feature = feature >> 8; - tf->hob_nsect = nsect >> 8; - tf->hob_lbal = lbal >> 8; - tf->hob_lbam = lbam >> 8; - tf->hob_lbah = lbah >> 8; + tf->hob_feature = feature >> 8; + tf->hob_nsect = nsect >> 8; + tf->hob_lbal = lbal >> 8; + tf->hob_lbam = lbam >> 8; + tf->hob_lbah = lbah >> 8; } } - 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 From ricknu-0@student.ltu.se Sat Nov 26 15:36:16 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Sat, 26 Nov 2005 15:30:59 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750784AbVKZXa4 (ORCPT ); Sat, 26 Nov 2005 18:30:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750785AbVKZXaz (ORCPT ); Sat, 26 Nov 2005 18:30:55 -0500 Received: from gepetto.dc.ltu.se ([130.240.42.40]:1702 "EHLO gepetto.dc.ltu.se") by vger.kernel.org with ESMTP id S1750784AbVKZXaz (ORCPT ); Sat, 26 Nov 2005 18:30:55 -0500 Received: from [130.240.205.31] (thinktank.campus.luth.se [130.240.205.31]) by gepetto.dc.ltu.se (8.12.5/8.12.5) with ESMTP id jAQNUrDT028221 for ; Sun, 27 Nov 2005 00:30:54 +0100 (MET) Message-ID: <4388F170.9050703@student.ltu.se> Date: Sun, 27 Nov 2005 00:36:16 +0100 From: Richard Knutsson User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-ide@vger.kernel.org Subject: [PATCH 2.6.15-rc2-mm1] scsi: fix compiler-warning for sata_vsc.c Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org From: Richard Knutsson Fix compiler-warning "... makes pointer from integer without a cast". Signed-off-by: Richard Knutsson --- Jeremy Higdon, sorry but I couldn't find your mail-address. sata_vsc.c | 67 ++++++++++++++++++++++++++++++++----------------------------- 1 files changed, 36 insertions(+), 31 deletions(-) --- a/drivers/scsi/sata_vsc.c 2005-11-26 23:10:56.000000000 +0100 +++ b/drivers/scsi/sata_vsc.c 2005-11-26 23:41:53.000000000 +0100 @@ -130,21 +130,26 @@ static void vsc_sata_tf_load(struct ata_ vsc_intr_mask_update(ap, tf->ctl & ATA_NIEN); } if (is_addr && (tf->flags & ATA_TFLAG_LBA48)) { - writew(tf->feature | (((u16)tf->hob_feature) << 8), ioaddr->feature_addr); - writew(tf->nsect | (((u16)tf->hob_nsect) << 8), ioaddr->nsect_addr); - writew(tf->lbal | (((u16)tf->hob_lbal) << 8), ioaddr->lbal_addr); - writew(tf->lbam | (((u16)tf->hob_lbam) << 8), ioaddr->lbam_addr); - writew(tf->lbah | (((u16)tf->hob_lbah) << 8), ioaddr->lbah_addr); + writew(tf->feature | (((u16)tf->hob_feature) << 8), + (void *) ioaddr->feature_addr); + writew(tf->nsect | (((u16)tf->hob_nsect) << 8), + (void *) ioaddr->nsect_addr); + writew(tf->lbal | (((u16)tf->hob_lbal) << 8), + (void *) ioaddr->lbal_addr); + writew(tf->lbam | (((u16)tf->hob_lbam) << 8), + (void *) ioaddr->lbam_addr); + writew(tf->lbah | (((u16)tf->hob_lbah) << 8), + (void *) ioaddr->lbah_addr); } else if (is_addr) { - writew(tf->feature, ioaddr->feature_addr); - writew(tf->nsect, ioaddr->nsect_addr); - writew(tf->lbal, ioaddr->lbal_addr); - writew(tf->lbam, ioaddr->lbam_addr); - writew(tf->lbah, ioaddr->lbah_addr); + writew(tf->feature, (void *) ioaddr->feature_addr); + writew(tf->nsect, (void *) ioaddr->nsect_addr); + writew(tf->lbal, (void *) ioaddr->lbal_addr); + writew(tf->lbam, (void *) ioaddr->lbam_addr); + writew(tf->lbah, (void *) ioaddr->lbah_addr); } if (tf->flags & ATA_TFLAG_DEVICE) - writeb(tf->device, ioaddr->device_addr); + writeb(tf->device, (void *) ioaddr->device_addr); ata_wait_idle(ap); } @@ -155,26 +160,26 @@ static void vsc_sata_tf_read(struct ata_ struct ata_ioports *ioaddr = &ap->ioaddr; u16 nsect, lbal, lbam, lbah, feature; - tf->command = ata_check_status(ap); - tf->device = readw(ioaddr->device_addr); - feature = readw(ioaddr->error_addr); - nsect = readw(ioaddr->nsect_addr); - lbal = readw(ioaddr->lbal_addr); - lbam = readw(ioaddr->lbam_addr); - lbah = readw(ioaddr->lbah_addr); - - tf->feature = feature; - tf->nsect = nsect; - tf->lbal = lbal; - tf->lbam = lbam; - tf->lbah = lbah; + tf->command = ata_check_status(ap); + tf->device = readw((void *) ioaddr->device_addr); + feature = readw((void *) ioaddr->error_addr); + nsect = readw((void *) ioaddr->nsect_addr); + lbal = readw((void *) ioaddr->lbal_addr); + lbam = readw((void *) ioaddr->lbam_addr); + lbah = readw((void *) ioaddr->lbah_addr); + + tf->feature = feature; + tf->nsect = nsect; + tf->lbal = lbal; + tf->lbam = lbam; + tf->lbah = lbah; if (tf->flags & ATA_TFLAG_LBA48) { - tf->hob_feature = feature >> 8; - tf->hob_nsect = nsect >> 8; - tf->hob_lbal = lbal >> 8; - tf->hob_lbam = lbam >> 8; - tf->hob_lbah = lbah >> 8; + tf->hob_feature = feature >> 8; + tf->hob_nsect = nsect >> 8; + tf->hob_lbal = lbal >> 8; + tf->hob_lbam = lbam >> 8; + tf->hob_lbah = lbah >> 8; } } @@ -280,8 +285,8 @@ static void __devinit vsc_sata_setup_por port->ctl_addr = base + VSC_SATA_TF_CTL_OFFSET; port->bmdma_addr = base + VSC_SATA_DMA_CMD_OFFSET; port->scr_addr = base + VSC_SATA_SCR_STATUS_OFFSET; - writel(0, base + VSC_SATA_UP_DESCRIPTOR_OFFSET); - writel(0, base + VSC_SATA_UP_DATA_BUFFER_OFFSET); + writel(0, (void *) base + VSC_SATA_UP_DESCRIPTOR_OFFSET); + writel(0, (void *) base + VSC_SATA_UP_DATA_BUFFER_OFFSET); } - 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 From jgarzik@pobox.com Sat Nov 26 16:55:09 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Sat, 26 Nov 2005 16:55:23 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750797AbVK0AzP (ORCPT ); Sat, 26 Nov 2005 19:55:15 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750802AbVK0AzO (ORCPT ); Sat, 26 Nov 2005 19:55:14 -0500 Received: from havoc.gtf.org ([69.61.125.42]:2265 "EHLO havoc.gtf.org") by vger.kernel.org with ESMTP id S1750797AbVK0AzN (ORCPT ); Sat, 26 Nov 2005 19:55:13 -0500 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by havoc.gtf.org (Postfix) with ESMTP id CFB0D1C095F4; Sat, 26 Nov 2005 19:55:10 -0500 (EST) Received: (from garzik@localhost) by havoc.gtf.org (8.13.1/8.13.1/Submit) id jAR0t9a8002290; Sat, 26 Nov 2005 19:55:09 -0500 Date: Sat, 26 Nov 2005 19:55:09 -0500 From: Jeff Garzik To: Richard Knutsson Cc: benh@kernel.crashing.org, linux-ide@vger.kernel.org Subject: Re: [PATCH 2.6.15-rc2-mm1] scsi: fix compiler-warning for sata_svw.c Message-ID: <20051127005509.GA2246@havoc.gtf.org> References: <4388F145.3060308@student.ltu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4388F145.3060308@student.ltu.se> User-Agent: Mutt/1.4.1i Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org On Sun, Nov 27, 2005 at 12:35:33AM +0100, Richard Knutsson wrote: > From: Richard Knutsson > > Fix compiler-warning "... makes pointer from integer without a cast". > > Signed-off-by: Richard Knutsson NAK, as it has been NAK'd many times before. Please check the archives and fix the real problem. Jeff - 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 From jgarzik@pobox.com Sat Nov 26 16:55:31 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Sat, 26 Nov 2005 16:55:36 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750802AbVK0Azd (ORCPT ); Sat, 26 Nov 2005 19:55:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750803AbVK0Azd (ORCPT ); Sat, 26 Nov 2005 19:55:33 -0500 Received: from havoc.gtf.org ([69.61.125.42]:3801 "EHLO havoc.gtf.org") by vger.kernel.org with ESMTP id S1750802AbVK0Azc (ORCPT ); Sat, 26 Nov 2005 19:55:32 -0500 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by havoc.gtf.org (Postfix) with ESMTP id 441311C4B6C6; Sat, 26 Nov 2005 19:55:32 -0500 (EST) Received: (from garzik@localhost) by havoc.gtf.org (8.13.1/8.13.1/Submit) id jAR0tVaK002308; Sat, 26 Nov 2005 19:55:31 -0500 Date: Sat, 26 Nov 2005 19:55:31 -0500 From: Jeff Garzik To: Richard Knutsson Cc: linux-ide@vger.kernel.org Subject: Re: [PATCH 2.6.15-rc2-mm1] scsi: fix compiler-warning for sata_vsc.c Message-ID: <20051127005531.GB2246@havoc.gtf.org> References: <4388F170.9050703@student.ltu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4388F170.9050703@student.ltu.se> User-Agent: Mutt/1.4.1i Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org On Sun, Nov 27, 2005 at 12:36:16AM +0100, Richard Knutsson wrote: > From: Richard Knutsson > > Fix compiler-warning "... makes pointer from integer without a cast". > > Signed-off-by: Richard Knutsson > --- > Jeremy Higdon, sorry but I couldn't find your mail-address. NAK, check the archives and fix the real problem. Jeff - 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 From fbusse@gmx.de Sun Nov 27 00:59:10 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Sun, 27 Nov 2005 01:00:00 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750953AbVK0I7N (ORCPT ); Sun, 27 Nov 2005 03:59:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750956AbVK0I7N (ORCPT ); Sun, 27 Nov 2005 03:59:13 -0500 Received: from mail.gmx.net ([213.165.64.20]:20682 "HELO mail.gmx.net") by vger.kernel.org with SMTP id S1750947AbVK0I7M (ORCPT ); Sun, 27 Nov 2005 03:59:12 -0500 Received: (qmail invoked by alias); 27 Nov 2005 08:59:11 -0000 Received: from port-212-202-42-131.dynamic.qsc.de (EHLO avalon.fbunet.de) [212.202.42.131] by mail.gmx.net (mp034) with SMTP; 27 Nov 2005 09:59:11 +0100 X-Authenticated: #4707809 Date: Sun, 27 Nov 2005 09:59:10 +0100 From: Fridtjof Busse To: linux-kernel@vger.kernel.org Subject: PROBLEM: Assertion failed in libata Message-Id: <20051127095910.4abeef90.fbusse@gmx.de> X-Mailer: Sylpheed version 2.1.7 (GTK+ 2.8.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org I'm running 2.6.14-rc2 on a Thinkpad T43, using libata.atapi_enabled=1 and ATA_ENABLE_PATA/ATAPI_ENABLE_DMADIR in include/linux/libata.h. During heavy diskload, I sometimes get a couple of errors (not reproducable for me yet): Assertion failed! qc->n_elem > 0,drivers/scsi/libata-core.c,ata_fill_sg,line=2482 Since the reading/writing has problems accessing the file if this occurs, I guess it is more than just a warning. Since Google didn't turn anything up, I just wanted to report this. Please CC me, thanks. -- Fridtjof Busse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From kernel-lists@projecthugo.co.uk Sun Nov 27 12:08:50 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Sun, 27 Nov 2005 12:09:12 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751087AbVK0UJK (ORCPT ); Sun, 27 Nov 2005 15:09:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751092AbVK0UJK (ORCPT ); Sun, 27 Nov 2005 15:09:10 -0500 Received: from host81-138-64-234.in-addr.btopenworld.com ([81.138.64.234]:20146 "HELO alesi.projecthugo.co.uk") by vger.kernel.org with SMTP id S1751087AbVK0UJK (ORCPT ); Sun, 27 Nov 2005 15:09:10 -0500 Received: (qmail 10887 invoked from network); 27 Nov 2005 20:08:53 -0000 Received: from buildhost.no-dns.co.uk (HELO ?10.11.216.17?) (10.11.216.17) by alesi.projecthugo.co.uk with SMTP; 27 Nov 2005 20:08:53 -0000 Message-ID: <438A1252.1010507@projecthugo.co.uk> Date: Sun, 27 Nov 2005 20:08:50 +0000 From: Matt Darcy User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-ide@vger.kernel.org Subject: Sata_mv 2.6.15 driver information request. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Hello Linux-ide list, I'm trying to get some additional information on the sata_mv driver that has appeared in the 2.6.15 kernel This has long been a personal pain to me, after being locked into the 2.6.12 kernel with the propritary driver, and the ammount of hacked up boot scripts I have to include sata disks that hang of my controller in a raid 5 array. I've decided to try to not use the 3rd party driver and try to get the driver in .15 working. I was very pleased that my test upgrad worked well, and my meta devices where seen and configured straight away, and with straight boot scripts, no hacking needed. I am however having some pretty serious stability issues with it (locking my whole system up in certain situations) I note that comments mark it as extremly experimental - and I totally appriciate this, which is why I'd like to try offer up as much information as possible to get this driver to a more stable condition, as quickly as possible. I notice that Brett Russ wrote the driver and its copyrighted by EMC (seems unusual for a sata driver). The notes in the drivers code say to copy this email list on any mails, and seeing as the driver doesn't provide any information on any one else to contact, it seemed like a good place to start. What base information and pre-requists are there in reporting bugs and issues with a driver, and is this the best place to do it ? Many thanks, Matt Darcy - 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 From rdunlap@xenotime.net Sun Nov 27 20:56:13 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Sun, 27 Nov 2005 20:55:47 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751140AbVK1Ezo (ORCPT ); Sun, 27 Nov 2005 23:55:44 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751230AbVK1Ezo (ORCPT ); Sun, 27 Nov 2005 23:55:44 -0500 Received: from xenotime.net ([66.160.160.81]:1723 "HELO xenotime.net") by vger.kernel.org with SMTP id S1751140AbVK1Ezn (ORCPT ); Sun, 27 Nov 2005 23:55:43 -0500 Received: from midway ([71.111.157.99]) by xenotime.net for ; Sun, 27 Nov 2005 20:55:42 -0800 Date: Sun, 27 Nov 2005 20:56:13 -0800 From: "Randy.Dunlap" To: Dominic Ijichi Cc: linux-ide@vger.kernel.org Subject: Re: sata suspend status? Message-Id: <20051127205613.18f48772.rdunlap@xenotime.net> In-Reply-To: <1133020582.438885a6615dc@www.ijichi.org> References: <1133020582.438885a6615dc@www.ijichi.org> Organization: YPO4 X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org On Sat, 26 Nov 2005 15:56:22 +0000 Dominic Ijichi wrote: > hello > > i've been trying to get my laptop s3 suspend working - its all working except I > believe for sata. it resumes and you can do type in, interact with the kernel > but as soon as you do anything that requires disk access it hangs. sorry if this > isn't very technical description, i can provide anything if told roughly what to do! > > i've searched extensively for patches, tried all the various incantations, and > currently running 2.6.15-rc2 which is supposed to provide support for ata > passthrough and basic scsi suspend, but still same problem. i have: > > Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 04) > > /dev/sda = HITACHI_DK23FA-60 > > hdparm -I /dev/sda works fine. > > I note recent patches from randy dunlap from intel to do with this controller > and acpi but not sure what kernel this is against or whether it's relevent. > > i believe there are many people out there who would love to get sata > suspend/resume working, its a major problem for all recent laptops and us folks > who love running linux. what's the current status please? Hi, It seems to work for some people. I don't know if that's just good luck or that some controllers don't need the SATA ACPI methods that I am working on. We should know more about that in the next few weeks, I hope. --- ~Randy - 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 From rdunlap@xenotime.net Sun Nov 27 21:03:32 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Sun, 27 Nov 2005 21:03:34 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751239AbVK1FDF (ORCPT ); Mon, 28 Nov 2005 00:03:05 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751244AbVK1FDE (ORCPT ); Mon, 28 Nov 2005 00:03:04 -0500 Received: from xenotime.net ([66.160.160.81]:8386 "HELO xenotime.net") by vger.kernel.org with SMTP id S1751239AbVK1FDC (ORCPT ); Mon, 28 Nov 2005 00:03:02 -0500 Received: from midway ([71.111.157.99]) by xenotime.net for ; Sun, 27 Nov 2005 21:03:02 -0800 Date: Sun, 27 Nov 2005 21:03:32 -0800 From: "Randy.Dunlap" To: Edward Falk Cc: randy_d_dunlap@linux.intel.com, jgarzik@pobox.com, linux-ide@vger.kernel.org Subject: Re: [RFC 2/5] ata_acpi: libata.h fields Message-Id: <20051127210332.433c2d43.rdunlap@xenotime.net> In-Reply-To: <43850B7E.5010506@google.com> References: <20051123154055.6ab5cab2.randy_d_dunlap@linux.intel.com> <20051123155103.7e58140c.randy_d_dunlap@linux.intel.com> <43850B7E.5010506@google.com> Organization: YPO4 X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org On Wed, 23 Nov 2005 16:38:22 -0800 Edward Falk wrote: > Why do this in the libata layer rather than the block or device layers? > - Hi, Thanks for your question. There is some device-to-ACPI table associations that are needed. I don't see how the block layer would be appropriate for that. Could it be? Also, calls must be made to each SATA device driver to perform a raw taskfile write. What do you mean by the device layer? Maybe the ops function entries in each SATA driver? If so, it looks like I may need to add the raw taskfile write as an entry there, but I haven't really studied that very much yet. Do you have some other (different) suggestions for doing this? --- ~Randy - 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 From dom@ijichi.org Mon Nov 28 01:10:49 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Mon, 28 Nov 2005 01:11:06 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751243AbVK1JK5 (ORCPT ); Mon, 28 Nov 2005 04:10:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751253AbVK1JK5 (ORCPT ); Mon, 28 Nov 2005 04:10:57 -0500 Received: from buffy.ijichi.org ([213.161.76.94]:31667 "EHLO buffy.ijichi.org") by vger.kernel.org with ESMTP id S1751243AbVK1JK4 (ORCPT ); Mon, 28 Nov 2005 04:10:56 -0500 Received: from localhost (localhost [127.0.0.1]) by buffy.ijichi.org (Postfix) with ESMTP id C7CEA183BD; Mon, 28 Nov 2005 09:10:54 +0000 (GMT) Received: from buffy.ijichi.org ([127.0.0.1]) by localhost (buffy.ijichi.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15171-03; Mon, 28 Nov 2005 09:10:50 +0000 (GMT) Received: by buffy.ijichi.org (Postfix, from userid 502) id 6D52D1831C; Mon, 28 Nov 2005 09:10:50 +0000 (GMT) Received: from 81-178-109-8.dsl.pipex.com (81-178-109-8.dsl.pipex.com [81.178.109.8]) by www.ijichi.org (IMP) with HTTP for ; Mon, 28 Nov 2005 09:10:49 +0000 Message-ID: <1133169049.438ac999da2ab@www.ijichi.org> Date: Mon, 28 Nov 2005 09:10:49 +0000 From: Dominic Ijichi To: "Randy.Dunlap" Cc: linux-ide@vger.kernel.org Subject: Re: sata suspend status? References: <1133020582.438885a6615dc@www.ijichi.org> <20051127205613.18f48772.rdunlap@xenotime.net> In-Reply-To: <20051127205613.18f48772.rdunlap@xenotime.net> MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Priority: 3 (Normal) X-Originating-IP: 81.178.109.8 X-DSPAM-Result: Innocent X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 438ac99d1543632114418 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at ijichi.org X-Spam-Status: No, score=-2.453 tagged_above=-999 required=6.31 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DSPAM_HAM=-0.1, RCVD_IN_SORBS_DUL=2.046] X-Spam-Score: -2.453 X-Spam-Level: Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 87 Quoting "Randy.Dunlap" : > On Sat, 26 Nov 2005 15:56:22 +0000 Dominic Ijichi wrote: > > > hello > > > > i've been trying to get my laptop s3 suspend working - its all working > except I > > believe for sata. it resumes and you can do type in, interact with the > kernel > > but as soon as you do anything that requires disk access it hangs. sorry if > this > > isn't very technical description, i can provide anything if told roughly > what to do! > > > > i've searched extensively for patches, tried all the various incantations, > and > > currently running 2.6.15-rc2 which is supposed to provide support for ata > > passthrough and basic scsi suspend, but still same problem. i have: > > > > Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 04) > > > > /dev/sda = HITACHI_DK23FA-60 > > > > hdparm -I /dev/sda works fine.love > > > > I note recent patches from randy dunlap from intel to do with this > controller > > and acpi but not sure what kernel this is against or whether it's relevent. > > > > i believe there are many people out there who would love to get sata > > suspend/resume working, its a major problem for all recent laptops and us > folks > > who love running linux. what's the current status please? > > Hi, > It seems to work for some people. I don't know if that's just > good luck or that some controllers don't need the SATA ACPI methods > that I am working on. We should know more about that in the next > few weeks, I hope. hiya can't work out how to apply your patches, have tried against 2.6.15-rc2 with symlinked directories but everything rejects. sorry for my ignorance, would like to try these out! ------------------------------------------ This message was penned by the hand of Dom - 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 From kernel-lists@projecthugo.co.uk Mon Nov 28 02:03:58 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Mon, 28 Nov 2005 02:04:32 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751161AbVK1KED (ORCPT ); Mon, 28 Nov 2005 05:04:03 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751037AbVK1KED (ORCPT ); Mon, 28 Nov 2005 05:04:03 -0500 Received: from beng-03.stn.ab2.ifl.net ([194.238.49.3]:35086 "EHLO [127.0.0.1]") by vger.kernel.org with ESMTP id S1751161AbVK1KEC (ORCPT ); Mon, 28 Nov 2005 05:04:02 -0500 Message-ID: <438AD60E.8050200@projecthugo.co.uk> Date: Mon, 28 Nov 2005 10:03:58 +0000 From: Matt Darcy Reply-To: kernel-lists@projecthugo.co.uk User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-ide@vger.kernel.org Subject: Sata_MV 2.6.15 release Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 104 Hi all, I've been using the propritary sata_mv driver for some time with good stability and reasonable performance. It has been a pain though due to using it for software raid configuration, and the fact that it is a module that has to be loaded at boot time, plus I cannot use it in a kernel after 2.6.12.6 I was delighted to see the inclusion and development of this driver in the 2.6.15 kernel. I decided to give this a try. I was pleased to note it worked straight out of the box - with regard to detecting the disks attatched and making them available for raid startup at boot. However I had problems using lvm2 with the meta devices, the driver actually hangs the system, and for some reason includes cdrom devices when trying to create a volume group (note the cdrom drives are IDE based, on a VIA chip - so I don't know why the sata driver probes them - or at least thats how it appears) I noted that the driver is maked as very experimental, and I would like to feed into this drivers testing and debugging, as to be honest the sooner this driver becomes stable and usable, the easier my life will be. the note at the header of the driver says to use this mailing list for development/bugs, however it does seem a little strange mailing linux-ide when sata is classed as SCSI in the kernel. Is this the correct mailing list to discuss/report bugs on ? If so, what information is needed to report bugs effectivly - each list normally has a set of pre-requs, distro/version/config/certain libs etc etc. Many thanks, Matt - 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 From kernel-lists@projecthugo.co.uk Mon Nov 28 02:05:03 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Mon, 28 Nov 2005 02:05:14 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751239AbVK1KFH (ORCPT ); Mon, 28 Nov 2005 05:05:07 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751235AbVK1KFG (ORCPT ); Mon, 28 Nov 2005 05:05:06 -0500 Received: from beng-03.stn.ab2.ifl.net ([194.238.49.3]:35598 "EHLO [127.0.0.1]") by vger.kernel.org with ESMTP id S1751239AbVK1KFF (ORCPT ); Mon, 28 Nov 2005 05:05:05 -0500 Message-ID: <438AD64F.90203@projecthugo.co.uk> Date: Mon, 28 Nov 2005 10:05:03 +0000 From: Matt Darcy Reply-To: kernel-lists@projecthugo.co.uk User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-ide@vger.kernel.org Subject: sata_mv 2.6.15 development/debugging Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 106 Hi all, I've been using the propritary sata_mv driver for some time with good stability and reasonable performance. It has been a pain though due to using it for software raid configuration, and the fact that it is a module that has to be loaded at boot time, plus I cannot use it in a kernel after 2.6.12.6 I was delighted to see the inclusion and development of this driver in the 2.6.15 kernel. I decided to give this a try. I was pleased to note it worked straight out of the box - with regard to detecting the disks attatched and making them available for raid startup at boot. However I had problems using lvm2 with the meta devices, the driver actually hangs the system, and for some reason includes cdrom devices when trying to create a volume group (note the cdrom drives are IDE based, on a VIA chip - so I don't know why the sata driver probes them - or at least thats how it appears) I noted that the driver is maked as very experimental, and I would like to feed into this drivers testing and debugging, as to be honest the sooner this driver becomes stable and usable, the easier my life will be. the note at the header of the driver says to use this mailing list for development/bugs, however it does seem a little strange mailing linux-ide when sata is classed as SCSI in the kernel. Is this the correct mailing list to discuss/report bugs on ? If so, what information is needed to report bugs effectivly - each list normally has a set of pre-requs, distro/version/config/certain libs etc etc. Many thanks, Matt - 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 From kernel-lists@projecthugo.co.uk Mon Nov 28 06:47:13 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Mon, 28 Nov 2005 06:47:23 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750873AbVK1OrQ (ORCPT ); Mon, 28 Nov 2005 09:47:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750874AbVK1OrQ (ORCPT ); Mon, 28 Nov 2005 09:47:16 -0500 Received: from beng-03.stn.ab2.ifl.net ([194.238.49.3]:3091 "EHLO [127.0.0.1]") by vger.kernel.org with ESMTP id S1750869AbVK1OrP (ORCPT ); Mon, 28 Nov 2005 09:47:15 -0500 Message-ID: <438B1871.7040807@projecthugo.co.uk> Date: Mon, 28 Nov 2005 14:47:13 +0000 From: Matt Darcy Reply-To: kernel-lists@projecthugo.co.uk User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-ide@vger.kernel.org Subject: Re: Sata_MV 2.6.15 release References: <438AD60E.8050200@projecthugo.co.uk> <438B1452.3030809@emc.com> In-Reply-To: <438B1452.3030809@emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 204 Ric Wheeler wrote: > > > Matt Darcy wrote: > >> Hi all, >> >> I've been using the propritary sata_mv driver for some time with good >> stability and reasonable performance. It has been a pain though due >> to using it for software raid configuration, and the fact that it is >> a module that has to be loaded at boot time, plus I cannot use it in >> a kernel after 2.6.12.6 >> >> I was delighted to see the inclusion and development of this driver >> in the 2.6.15 kernel. I decided to give this a try. >> >> I was pleased to note it worked straight out of the box - with regard >> to detecting the disks attatched and making them available for raid >> startup at boot. >> >> However I had problems using lvm2 with the meta devices, the driver >> actually hangs the system, and for some reason includes cdrom devices >> when trying to create a volume group (note the cdrom drives are IDE >> based, on a VIA chip - so I don't know why the sata driver probes >> them - or at least thats how it appears) >> >> I noted that the driver is maked as very experimental, and I would >> like to feed into this drivers testing and debugging, as to be honest >> the sooner this driver becomes stable and usable, the easier my life >> will be. >> >> the note at the header of the driver says to use this mailing list >> for development/bugs, however it does seem a little strange mailing >> linux-ide when sata is classed as SCSI in the kernel. >> >> Is this the correct mailing list to discuss/report bugs on ? >> >> If so, what information is needed to report bugs effectivly - each >> list normally has a set of pre-requs, distro/version/config/certain >> libs etc etc. >> >> Many thanks, >> >> Matt >> >> >> > This is the right list - IDE and S-ATA drives both use libata which > does a SCSI -> IDE translation so that they can look & behave mostly > like real SCSI drives. > > Jeff Garzik is the main libata guy & has recently posted a large > update to the Marvell driver. Brett left my group at EMC, but it > still lurking on this list as well, so you might get some help from > him as well. Hopefully we (EMC) will have a full time person assigned > to the Marvell driver in the near future, but that person will focus > mostly on the hardware that we have at hand. > > What you normally need to do for a bug report is to try and get a run > with the latest kernel. Jeff uses git to roll the experimental fixes > into his "libata" development branch, you can have a look at his page > for information on how to use git, etc: > > http://linux.yyz.us/git-howto.html > > He also has a s-ata status page at the same site: > > http://linux.yyz.us/sata/sata-status.html > > If you can reproduce your bugs on this libata-dev kernel, you will > have the best response from people on this list. > > Good luck! > > ric > > Hi Ric, thanks for all the info, apologies on the double post, my mail client crashed in the middle of sending, and it looked like the mail did not get sent, however it looks like it did, but by then I had already re-sent. I'll start looking at these changes now. I assume these changes are post-2.6.15-rc2 applied thanks, Matt - 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 From htejun@gmail.com Mon Nov 28 08:42:01 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Mon, 28 Nov 2005 08:42:16 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751274AbVK1QmK (ORCPT ); Mon, 28 Nov 2005 11:42:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751293AbVK1QmK (ORCPT ); Mon, 28 Nov 2005 11:42:10 -0500 Received: from zproxy.gmail.com ([64.233.162.203]:7221 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S1751274AbVK1QmI (ORCPT ); Mon, 28 Nov 2005 11:42:08 -0500 Received: by zproxy.gmail.com with SMTP id 13so2514382nzn for ; Mon, 28 Nov 2005 08:42:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:mime-version:content-type:content-disposition:user-agent; b=ofD0DZtsmxPkZktwDdC1PaY76ogoGxS5T6YD59SHcSScAPwTgi8FBq/AXIOoY+UBDpBjpzUZKCDIWr0aiw0kRtgCwPZuSdwNfBLDVEgMUBL0r5f3jTgBGMik7vcClHXf0j29uzKEOdTbGzDz/ECw9fgnldADdjJv/KpvuTyQZh4= Received: by 10.36.5.11 with SMTP id 11mr3633680nze; Mon, 28 Nov 2005 08:42:07 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id e1sm3963857nzd.2005.11.28.08.42.05; Mon, 28 Nov 2005 08:42:07 -0800 (PST) Received: by htj.dyndns.org (Postfix, from userid 1000) id 348A21860CA; Tue, 29 Nov 2005 01:42:01 +0900 (KST) Date: Tue, 29 Nov 2005 01:42:01 +0900 From: Tejun Heo To: Jeff Garzik , linux-ide@vger.kernel.org Subject: [PATCH] libata: implement ata_qc_exec_internal() Message-ID: <20051128164201.GA7530@htj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 268 Each user libata internal commands initializes a qc, issues it, waits for its completion and checks for errors. This patch factors internal command execution sequence into ata_qc_exec_internal(). The function also removes race condition between irq and timeout handling. Signed-off-by: Tejun Heo diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c index f1047a0..40c488e 100644 --- a/drivers/scsi/libata-core.c +++ b/drivers/scsi/libata-core.c @@ -1047,28 +1047,73 @@ static unsigned int ata_pio_modes(const return modes; } -static int ata_qc_wait_err(struct ata_queued_cmd *qc, - struct completion *wait) +/** + * ata_qc_exec_internal - execute libata internal command + * @qc: Command to execute + * + * Executes libata internal command with timeout. Timeout and + * error conditions are reported via return value. No recovery + * action is taken after a command times out. It's caller's duty + * to clean up after timeout. + * + * Also, note that error condition is checked after the qc is + * completed, meaning that if another command is issued before + * checking the condition, we get the wrong values. As internal + * cmds are used only for initialization and recovery, this + * shouldn't cause any problem. + * + * LOCKING: + * None. Should be called with kernel context, might sleep. + */ + +static unsigned ata_qc_exec_internal(struct ata_queued_cmd *qc) { - int rc = 0; + struct ata_port *ap = qc->ap; + DECLARE_COMPLETION(wait); + unsigned long tmout_left; + unsigned int err_mask; + int rc; - if (wait_for_completion_timeout(wait, 30 * HZ) < 1) { - /* timeout handling */ - unsigned int err_mask = ac_err_mask(ata_chk_status(qc->ap)); + if (ata_busy_sleep(ap, ATA_TMOUT_INTERNAL_QUICK, ATA_TMOUT_INTERNAL)) + return -ETIMEDOUT; - if (!err_mask) { + qc->complete_fn = ata_qc_complete_noop; + qc->waiting = &wait; + + spin_lock_irq(&ap->host_set->lock); + rc = ata_qc_issue(qc); + spin_unlock_irq(&ap->host_set->lock); + + if (rc) + return AC_ERR_OTHER; + + tmout_left = wait_for_completion_timeout(&wait, ATA_TMOUT_INTERNAL); + err_mask = ac_err_mask(ata_chk_status(qc->ap)); + + if (!tmout_left) { + /* timeout handling */ + if (!err_mask) printk(KERN_WARNING "ata%u: slow completion (cmd %x)\n", qc->ap->id, qc->tf.command); - } else { + else printk(KERN_WARNING "ata%u: qc timeout (cmd %x)\n", qc->ap->id, qc->tf.command); - rc = -EIO; - } - ata_qc_complete(qc, err_mask); + spin_lock_irq(&ap->host_set->lock); + + /* We're racing with irq here. If we lose, the + * following test prevents us from completing the qc + * again. If completion irq occurs after here but + * before the caller cleans up, it will result in a + * spurious interrupt. We can live with that. + */ + if (qc->flags & ATA_QCFLAG_ACTIVE) + ata_qc_complete(qc, err_mask); + + spin_unlock_irq(&ap->host_set->lock); } - return rc; + return err_mask; } /** @@ -1100,9 +1145,8 @@ static void ata_dev_identify(struct ata_ u16 tmp; unsigned long xfer_modes; unsigned int using_edd; - DECLARE_COMPLETION(wait); struct ata_queued_cmd *qc; - unsigned long flags; + unsigned int err_mask; int rc; if (!ata_dev_present(dev)) { @@ -1140,23 +1184,18 @@ retry: DPRINTK("do ATAPI identify\n"); } - qc->waiting = &wait; - qc->complete_fn = ata_qc_complete_noop; + err_mask = ata_qc_exec_internal(qc); - spin_lock_irqsave(&ap->host_set->lock, flags); - rc = ata_qc_issue(qc); - spin_unlock_irqrestore(&ap->host_set->lock, flags); + if (err_mask) { + unsigned long flags; - if (rc) - goto err_out; - else - ata_qc_wait_err(qc, &wait); + if (err_mask & ~AC_ERR_DEV) + goto err_out; - spin_lock_irqsave(&ap->host_set->lock, flags); - ap->ops->tf_read(ap, &qc->tf); - spin_unlock_irqrestore(&ap->host_set->lock, flags); + spin_lock_irqsave(&ap->host_set->lock, flags); + ap->ops->tf_read(ap, &qc->tf); + spin_unlock_irqrestore(&ap->host_set->lock, flags); - if (qc->tf.command & ATA_ERR) { /* * arg! EDD works for all test cases, but seems to return * the ATA signature for some ATAPI devices. Until the @@ -2288,10 +2327,7 @@ static int ata_choose_xfer_mode(const st static void ata_dev_set_xfermode(struct ata_port *ap, struct ata_device *dev) { - DECLARE_COMPLETION(wait); struct ata_queued_cmd *qc; - int rc; - unsigned long flags; /* set up set-features taskfile */ DPRINTK("set features - xfer mode\n"); @@ -2305,17 +2341,11 @@ static void ata_dev_set_xfermode(struct qc->tf.protocol = ATA_PROT_NODATA; qc->tf.nsect = dev->xfer_mode; - qc->waiting = &wait; - qc->complete_fn = ata_qc_complete_noop; - - spin_lock_irqsave(&ap->host_set->lock, flags); - rc = ata_qc_issue(qc); - spin_unlock_irqrestore(&ap->host_set->lock, flags); - - if (rc) + if (ata_qc_exec_internal(qc)) { + printk(KERN_ERR "ata%u: failed to set xfermode, disabled\n", + ap->id); ata_port_disable(ap); - else - ata_qc_wait_err(qc, &wait); + } DPRINTK("EXIT\n"); } @@ -2330,10 +2360,7 @@ static void ata_dev_set_xfermode(struct static void ata_dev_reread_id(struct ata_port *ap, struct ata_device *dev) { - DECLARE_COMPLETION(wait); struct ata_queued_cmd *qc; - unsigned long flags; - int rc; qc = ata_qc_new_init(ap, dev); BUG_ON(qc == NULL); @@ -2353,18 +2380,9 @@ static void ata_dev_reread_id(struct ata qc->tf.protocol = ATA_PROT_PIO; qc->nsect = 1; - qc->waiting = &wait; - qc->complete_fn = ata_qc_complete_noop; - - spin_lock_irqsave(&ap->host_set->lock, flags); - rc = ata_qc_issue(qc); - spin_unlock_irqrestore(&ap->host_set->lock, flags); - - if (rc) + if (ata_qc_exec_internal(qc)) goto err_out; - ata_qc_wait_err(qc, &wait); - swap_buf_le16(dev->id, ATA_ID_WORDS); ata_dump_id(dev); @@ -2373,6 +2391,7 @@ static void ata_dev_reread_id(struct ata return; err_out: + printk(KERN_ERR "ata%u: failed to reread ID, disabled\n", ap->id); ata_port_disable(ap); } @@ -2386,10 +2405,7 @@ err_out: static void ata_dev_init_params(struct ata_port *ap, struct ata_device *dev) { - DECLARE_COMPLETION(wait); struct ata_queued_cmd *qc; - int rc; - unsigned long flags; u16 sectors = dev->id[6]; u16 heads = dev->id[3]; @@ -2409,17 +2425,11 @@ static void ata_dev_init_params(struct a qc->tf.nsect = sectors; qc->tf.device |= (heads - 1) & 0x0f; /* max head = num. of heads - 1 */ - qc->waiting = &wait; - qc->complete_fn = ata_qc_complete_noop; - - spin_lock_irqsave(&ap->host_set->lock, flags); - rc = ata_qc_issue(qc); - spin_unlock_irqrestore(&ap->host_set->lock, flags); - - if (rc) + if (ata_qc_exec_internal(qc)) { + printk(KERN_ERR "ata%u: failed to init parameters, disabled\n", + ap->id); ata_port_disable(ap); - else - ata_qc_wait_err(qc, &wait); + } DPRINTK("EXIT\n"); } diff --git a/drivers/scsi/libata.h b/drivers/scsi/libata.h diff --git a/include/linux/libata.h b/include/linux/libata.h index 9aa10df..2fe64f6 100644 --- a/include/linux/libata.h +++ b/include/linux/libata.h @@ -136,6 +136,8 @@ enum { ATA_TMOUT_BOOT_QUICK = 7 * HZ, /* hueristic */ ATA_TMOUT_DATAOUT = 30 * HZ, ATA_TMOUT_DATAOUT_QUICK = 5 * HZ, + ATA_TMOUT_INTERNAL = 30 * HZ, + ATA_TMOUT_INTERNAL_QUICK = 5 * HZ, /* ATA bus states */ BUS_UNKNOWN = 0, - 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 From raziebe@gmail.com Mon Nov 28 09:48:21 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Mon, 28 Nov 2005 09:48:31 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932136AbVK1RsW (ORCPT ); Mon, 28 Nov 2005 12:48:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751271AbVK1RsW (ORCPT ); Mon, 28 Nov 2005 12:48:22 -0500 Received: from wproxy.gmail.com ([64.233.184.200]:26275 "EHLO wproxy.gmail.com") by vger.kernel.org with ESMTP id S1751262AbVK1RsW convert rfc822-to-8bit (ORCPT ); Mon, 28 Nov 2005 12:48:22 -0500 Received: by wproxy.gmail.com with SMTP id 71so1746995wri for ; Mon, 28 Nov 2005 09:48:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eRE9iMnplrkQWV9XPBJO18UNGelwUMoB8PdRIePFWAQnKyOdKin9WU8uAl10jem7t5WUjB+Sg/Nq1eUaUkcQ5z4ATeCglc807aAl6YvL+KTRhJ5xqxCLWGT4qU2y8JIXP9qVyLEKEc/TF5747URykJYwLTYrFEb6HSZia/yCyBk= Received: by 10.54.100.2 with SMTP id x2mr8558042wrb; Mon, 28 Nov 2005 09:48:21 -0800 (PST) Received: by 10.54.122.20 with HTTP; Mon, 28 Nov 2005 09:48:21 -0800 (PST) Message-ID: <5d96567b0511280948t45881bf9x989f27be235b47a1@mail.gmail.com> Date: Mon, 28 Nov 2005 19:48:21 +0200 From: "Raz Ben-Jehuda(caro)" To: Tejun Heo Subject: Re: [PATCH] libata: implement ata_qc_exec_internal() Cc: Jeff Garzik , linux-ide@vger.kernel.org In-Reply-To: <20051128164201.GA7530@htj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Disposition: inline References: <20051128164201.GA7530@htj.dyndns.org> Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 325 does it solve the cpu usage ? On 11/28/05, Tejun Heo wrote: > Each user libata internal commands initializes a qc, issues it, waits > for its completion and checks for errors. This patch factors internal > command execution sequence into ata_qc_exec_internal(). The function > also removes race condition between irq and timeout handling. > > Signed-off-by: Tejun Heo > > diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c > index f1047a0..40c488e 100644 > --- a/drivers/scsi/libata-core.c > +++ b/drivers/scsi/libata-core.c > @@ -1047,28 +1047,73 @@ static unsigned int ata_pio_modes(const > return modes; > } > > -static int ata_qc_wait_err(struct ata_queued_cmd *qc, > - struct completion *wait) > +/** > + * ata_qc_exec_internal - execute libata internal command > + * @qc: Command to execute > + * > + * Executes libata internal command with timeout. Timeout and > + * error conditions are reported via return value. No recovery > + * action is taken after a command times out. It's caller's duty > + * to clean up after timeout. > + * > + * Also, note that error condition is checked after the qc is > + * completed, meaning that if another command is issued before > + * checking the condition, we get the wrong values. As internal > + * cmds are used only for initialization and recovery, this > + * shouldn't cause any problem. > + * > + * LOCKING: > + * None. Should be called with kernel context, might sleep. > + */ > + > +static unsigned ata_qc_exec_internal(struct ata_queued_cmd *qc) > { > - int rc = 0; > + struct ata_port *ap = qc->ap; > + DECLARE_COMPLETION(wait); > + unsigned long tmout_left; > + unsigned int err_mask; > + int rc; > > - if (wait_for_completion_timeout(wait, 30 * HZ) < 1) { > - /* timeout handling */ > - unsigned int err_mask = ac_err_mask(ata_chk_status(qc->ap)); > + if (ata_busy_sleep(ap, ATA_TMOUT_INTERNAL_QUICK, ATA_TMOUT_INTERNAL)) > + return -ETIMEDOUT; > > - if (!err_mask) { > + qc->complete_fn = ata_qc_complete_noop; > + qc->waiting = &wait; > + > + spin_lock_irq(&ap->host_set->lock); > + rc = ata_qc_issue(qc); > + spin_unlock_irq(&ap->host_set->lock); > + > + if (rc) > + return AC_ERR_OTHER; > + > + tmout_left = wait_for_completion_timeout(&wait, ATA_TMOUT_INTERNAL); > + err_mask = ac_err_mask(ata_chk_status(qc->ap)); > + > + if (!tmout_left) { > + /* timeout handling */ > + if (!err_mask) > printk(KERN_WARNING "ata%u: slow completion (cmd %x)\n", > qc->ap->id, qc->tf.command); > - } else { > + else > printk(KERN_WARNING "ata%u: qc timeout (cmd %x)\n", > qc->ap->id, qc->tf.command); > - rc = -EIO; > - } > > - ata_qc_complete(qc, err_mask); > + spin_lock_irq(&ap->host_set->lock); > + > + /* We're racing with irq here. If we lose, the > + * following test prevents us from completing the qc > + * again. If completion irq occurs after here but > + * before the caller cleans up, it will result in a > + * spurious interrupt. We can live with that. > + */ > + if (qc->flags & ATA_QCFLAG_ACTIVE) > + ata_qc_complete(qc, err_mask); > + > + spin_unlock_irq(&ap->host_set->lock); > } > > - return rc; > + return err_mask; > } > > /** > @@ -1100,9 +1145,8 @@ static void ata_dev_identify(struct ata_ > u16 tmp; > unsigned long xfer_modes; > unsigned int using_edd; > - DECLARE_COMPLETION(wait); > struct ata_queued_cmd *qc; > - unsigned long flags; > + unsigned int err_mask; > int rc; > > if (!ata_dev_present(dev)) { > @@ -1140,23 +1184,18 @@ retry: > DPRINTK("do ATAPI identify\n"); > } > > - qc->waiting = &wait; > - qc->complete_fn = ata_qc_complete_noop; > + err_mask = ata_qc_exec_internal(qc); > > - spin_lock_irqsave(&ap->host_set->lock, flags); > - rc = ata_qc_issue(qc); > - spin_unlock_irqrestore(&ap->host_set->lock, flags); > + if (err_mask) { > + unsigned long flags; > > - if (rc) > - goto err_out; > - else > - ata_qc_wait_err(qc, &wait); > + if (err_mask & ~AC_ERR_DEV) > + goto err_out; > > - spin_lock_irqsave(&ap->host_set->lock, flags); > - ap->ops->tf_read(ap, &qc->tf); > - spin_unlock_irqrestore(&ap->host_set->lock, flags); > + spin_lock_irqsave(&ap->host_set->lock, flags); > + ap->ops->tf_read(ap, &qc->tf); > + spin_unlock_irqrestore(&ap->host_set->lock, flags); > > - if (qc->tf.command & ATA_ERR) { > /* > * arg! EDD works for all test cases, but seems to return > * the ATA signature for some ATAPI devices. Until the > @@ -2288,10 +2327,7 @@ static int ata_choose_xfer_mode(const st > > static void ata_dev_set_xfermode(struct ata_port *ap, struct ata_device *dev) > { > - DECLARE_COMPLETION(wait); > struct ata_queued_cmd *qc; > - int rc; > - unsigned long flags; > > /* set up set-features taskfile */ > DPRINTK("set features - xfer mode\n"); > @@ -2305,17 +2341,11 @@ static void ata_dev_set_xfermode(struct > qc->tf.protocol = ATA_PROT_NODATA; > qc->tf.nsect = dev->xfer_mode; > > - qc->waiting = &wait; > - qc->complete_fn = ata_qc_complete_noop; > - > - spin_lock_irqsave(&ap->host_set->lock, flags); > - rc = ata_qc_issue(qc); > - spin_unlock_irqrestore(&ap->host_set->lock, flags); > - > - if (rc) > + if (ata_qc_exec_internal(qc)) { > + printk(KERN_ERR "ata%u: failed to set xfermode, disabled\n", > + ap->id); > ata_port_disable(ap); > - else > - ata_qc_wait_err(qc, &wait); > + } > > DPRINTK("EXIT\n"); > } > @@ -2330,10 +2360,7 @@ static void ata_dev_set_xfermode(struct > > static void ata_dev_reread_id(struct ata_port *ap, struct ata_device *dev) > { > - DECLARE_COMPLETION(wait); > struct ata_queued_cmd *qc; > - unsigned long flags; > - int rc; > > qc = ata_qc_new_init(ap, dev); > BUG_ON(qc == NULL); > @@ -2353,18 +2380,9 @@ static void ata_dev_reread_id(struct ata > qc->tf.protocol = ATA_PROT_PIO; > qc->nsect = 1; > > - qc->waiting = &wait; > - qc->complete_fn = ata_qc_complete_noop; > - > - spin_lock_irqsave(&ap->host_set->lock, flags); > - rc = ata_qc_issue(qc); > - spin_unlock_irqrestore(&ap->host_set->lock, flags); > - > - if (rc) > + if (ata_qc_exec_internal(qc)) > goto err_out; > > - ata_qc_wait_err(qc, &wait); > - > swap_buf_le16(dev->id, ATA_ID_WORDS); > > ata_dump_id(dev); > @@ -2373,6 +2391,7 @@ static void ata_dev_reread_id(struct ata > > return; > err_out: > + printk(KERN_ERR "ata%u: failed to reread ID, disabled\n", ap->id); > ata_port_disable(ap); > } > > @@ -2386,10 +2405,7 @@ err_out: > > static void ata_dev_init_params(struct ata_port *ap, struct ata_device *dev) > { > - DECLARE_COMPLETION(wait); > struct ata_queued_cmd *qc; > - int rc; > - unsigned long flags; > u16 sectors = dev->id[6]; > u16 heads = dev->id[3]; > > @@ -2409,17 +2425,11 @@ static void ata_dev_init_params(struct a > qc->tf.nsect = sectors; > qc->tf.device |= (heads - 1) & 0x0f; /* max head = num. of heads - 1 */ > > - qc->waiting = &wait; > - qc->complete_fn = ata_qc_complete_noop; > - > - spin_lock_irqsave(&ap->host_set->lock, flags); > - rc = ata_qc_issue(qc); > - spin_unlock_irqrestore(&ap->host_set->lock, flags); > - > - if (rc) > + if (ata_qc_exec_internal(qc)) { > + printk(KERN_ERR "ata%u: failed to init parameters, disabled\n", > + ap->id); > ata_port_disable(ap); > - else > - ata_qc_wait_err(qc, &wait); > + } > > DPRINTK("EXIT\n"); > } > diff --git a/drivers/scsi/libata.h b/drivers/scsi/libata.h > diff --git a/include/linux/libata.h b/include/linux/libata.h > index 9aa10df..2fe64f6 100644 > --- a/include/linux/libata.h > +++ b/include/linux/libata.h > @@ -136,6 +136,8 @@ enum { > ATA_TMOUT_BOOT_QUICK = 7 * HZ, /* hueristic */ > ATA_TMOUT_DATAOUT = 30 * HZ, > ATA_TMOUT_DATAOUT_QUICK = 5 * HZ, > + ATA_TMOUT_INTERNAL = 30 * HZ, > + ATA_TMOUT_INTERNAL_QUICK = 5 * HZ, > > /* ATA bus states */ > BUS_UNKNOWN = 0, > - > 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 > -- Raz - 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 From rdunlap@xenotime.net Mon Nov 28 14:41:36 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Mon, 28 Nov 2005 14:41:44 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932271AbVK1Wll (ORCPT ); Mon, 28 Nov 2005 17:41:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932269AbVK1Wll (ORCPT ); Mon, 28 Nov 2005 17:41:41 -0500 Received: from xenotime.net ([66.160.160.81]:3251 "HELO xenotime.net") by vger.kernel.org with SMTP id S932267AbVK1Wll (ORCPT ); Mon, 28 Nov 2005 17:41:41 -0500 Received: from shark.he.net ([66.160.160.2]) by xenotime.net for ; Mon, 28 Nov 2005 14:41:36 -0800 Date: Mon, 28 Nov 2005 14:41:36 -0800 (PST) From: "Randy.Dunlap" X-X-Sender: rddunlap@shark.he.net To: Dominic Ijichi cc: "Randy.Dunlap" , linux-ide@vger.kernel.org Subject: Re: sata suspend status? In-Reply-To: <1133169049.438ac999da2ab@www.ijichi.org> Message-ID: References: <1133020582.438885a6615dc@www.ijichi.org> <20051127205613.18f48772.rdunlap@xenotime.net> <1133169049.438ac999da2ab@www.ijichi.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: A X-Keywords: X-UID: 602 On Mon, 28 Nov 2005, Dominic Ijichi wrote: > Quoting "Randy.Dunlap" : > > > On Sat, 26 Nov 2005 15:56:22 +0000 Dominic Ijichi wrote: > > > > > hello > > > > > > i've been trying to get my laptop s3 suspend working - its all working > > except I > > > believe for sata. it resumes and you can do type in, interact with the > > kernel > > > but as soon as you do anything that requires disk access it hangs. sorry if > > this > > > isn't very technical description, i can provide anything if told roughly > > what to do! > > > > > > i've searched extensively for patches, tried all the various incantations, > > and > > > currently running 2.6.15-rc2 which is supposed to provide support for ata > > > passthrough and basic scsi suspend, but still same problem. i have: > > > > > > Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 04) > > > > > > /dev/sda = HITACHI_DK23FA-60 > > > > > > hdparm -I /dev/sda works fine.love > > > > > > I note recent patches from randy dunlap from intel to do with this > > controller > > > and acpi but not sure what kernel this is against or whether it's relevent. > > > > > > i believe there are many people out there who would love to get sata > > > suspend/resume working, its a major problem for all recent laptops and us > > folks > > > who love running linux. what's the current status please? > > > > Hi, > > It seems to work for some people. I don't know if that's just > > good luck or that some controllers don't need the SATA ACPI methods > > that I am working on. We should know more about that in the next > > few weeks, I hope. > > hiya > can't work out how to apply your patches, have tried against 2.6.15-rc2 with > symlinked directories but everything rejects. sorry for my ignorance, would > like to try these out! Sorry about that. I'll correct that and repost with exact info about correct kernel version to use. However, these current patches won't get you much additional help for SATA suspend/resume since they lack writing the taskfile data to the controller ports. -- ~Randy - 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 From rdunlap@xenotime.net Mon Nov 28 15:12:46 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Mon, 28 Nov 2005 15:12:52 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932097AbVK1XMu (ORCPT ); Mon, 28 Nov 2005 18:12:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932277AbVK1XMu (ORCPT ); Mon, 28 Nov 2005 18:12:50 -0500 Received: from xenotime.net ([66.160.160.81]:11168 "HELO xenotime.net") by vger.kernel.org with SMTP id S932097AbVK1XMt (ORCPT ); Mon, 28 Nov 2005 18:12:49 -0500 Received: from shark.he.net ([66.160.160.2]) by xenotime.net for ; Mon, 28 Nov 2005 15:12:46 -0800 Date: Mon, 28 Nov 2005 15:12:46 -0800 (PST) From: "Randy.Dunlap" X-X-Sender: rddunlap@shark.he.net To: "Randy.Dunlap" cc: Dominic Ijichi , linux-ide@vger.kernel.org Subject: Re: sata suspend status? In-Reply-To: Message-ID: References: <1133020582.438885a6615dc@www.ijichi.org> <20051127205613.18f48772.rdunlap@xenotime.net> <1133169049.438ac999da2ab@www.ijichi.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 652 On Mon, 28 Nov 2005, Randy.Dunlap wrote: > On Mon, 28 Nov 2005, Dominic Ijichi wrote: > > > Quoting "Randy.Dunlap" : > > > > > On Sat, 26 Nov 2005 15:56:22 +0000 Dominic Ijichi wrote: > > > > > > > hello > > > > > > > > i've been trying to get my laptop s3 suspend working - its all working > > > except I > > > > believe for sata. it resumes and you can do type in, interact with the > > > kernel > > > > but as soon as you do anything that requires disk access it hangs. sorry if > > > this > > > > isn't very technical description, i can provide anything if told roughly > > > what to do! > > > > > > > > i've searched extensively for patches, tried all the various incantations, > > > and > > > > currently running 2.6.15-rc2 which is supposed to provide support for ata > > > > passthrough and basic scsi suspend, but still same problem. i have: > > > > > > > > Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 04) > > > > > > > > /dev/sda = HITACHI_DK23FA-60 > > > > > > > > hdparm -I /dev/sda works fine.love > > > > > > > > I note recent patches from randy dunlap from intel to do with this > > > controller > > > > and acpi but not sure what kernel this is against or whether it's relevent. > > > > > > > > i believe there are many people out there who would love to get sata > > > > suspend/resume working, its a major problem for all recent laptops and us > > > folks > > > > who love running linux. what's the current status please? > > > > > > Hi, > > > It seems to work for some people. I don't know if that's just > > > good luck or that some controllers don't need the SATA ACPI methods > > > that I am working on. We should know more about that in the next > > > few weeks, I hope. > > > > hiya > > can't work out how to apply your patches, have tried against 2.6.15-rc2 with > > symlinked directories but everything rejects. sorry for my ignorance, would > > like to try these out! > > Sorry about that. I'll correct that and repost with exact > info about correct kernel version to use. The patch series (5 patches) was made against 2.6.15-rc2 and applies cleanly and builds without errors. (Yes, there are a few warnings due to work-in-progress.) > However, these current patches won't get you much additional help > for SATA suspend/resume since they lack writing the taskfile data > to the controller ports. -- ~Randy - 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 From htejun@gmail.com Mon Nov 28 19:08:08 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Mon, 28 Nov 2005 19:08:19 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932342AbVK2DIQ (ORCPT ); Mon, 28 Nov 2005 22:08:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932344AbVK2DIQ (ORCPT ); Mon, 28 Nov 2005 22:08:16 -0500 Received: from wproxy.gmail.com ([64.233.184.193]:15656 "EHLO wproxy.gmail.com") by vger.kernel.org with ESMTP id S932342AbVK2DIP (ORCPT ); Mon, 28 Nov 2005 22:08:15 -0500 Received: by wproxy.gmail.com with SMTP id 71so1860094wri for ; Mon, 28 Nov 2005 19:08:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=PYdjen13M0FiIaXaekjNSlmAuq9e5t8BGhqRkncQoEWDbuZW4qeN6kvhD5juAaOsRZ46w0VcKZXBoTMMqqo61DzJv0dnaw2Oza8S0zsI+j88rXCvsQvp3XqFYqzTchGmx3SpNOprACsIuvcVsV/RCR6KZvOJccEkTkltVWNJI6o= Received: by 10.54.68.4 with SMTP id q4mr3928392wra; Mon, 28 Nov 2005 19:08:14 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id g5sm335350wra.2005.11.28.19.08.12; Mon, 28 Nov 2005 19:08:14 -0800 (PST) Received: from [127.0.0.1] (htj.dyndns.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by htj.dyndns.org (Postfix) with ESMTP id 37E731842E0; Tue, 29 Nov 2005 12:08:08 +0900 (KST) Message-ID: <438BC618.8070300@gmail.com> Date: Tue, 29 Nov 2005 12:08:08 +0900 From: Tejun Heo User-Agent: Debian Thunderbird 1.0.7 (X11/20051019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Raz Ben-Jehuda(caro)" CC: Jeff Garzik , linux-ide@vger.kernel.org Subject: Re: [PATCH] libata: implement ata_qc_exec_internal() References: <20051128164201.GA7530@htj.dyndns.org> <5d96567b0511280948t45881bf9x989f27be235b47a1@mail.gmail.com> In-Reply-To: <5d96567b0511280948t45881bf9x989f27be235b47a1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Raz Ben-Jehuda(caro) wrote: > does it solve the cpu usage ? > > On 11/28/05, Tejun Heo wrote: > >>Each user libata internal commands initializes a qc, issues it, waits >>for its completion and checks for errors. This patch factors internal >>command execution sequence into ata_qc_exec_internal(). The function >>also removes race condition between irq and timeout handling. >> >>Signed-off-by: Tejun Heo >> Hi, Raz. It propabably has nothing to do with the cpu usage problem on piix you reported. I think you need to post more data to get people on the list interested in your problem. The followings may help. 1. Please report exactly which kernel you're using and more information on the hardware will also help. 2. Don't use raid or any fs on it. Just perform tests on raw /dev/sdx devices. Do something like 'time dd if=/dev/sdx of=/dev/zero bs=1M count=1024' and report how much user/system time it uses. 3. If above shows large system time consumption, build your kernel with oprofile. Start recording non-idle cpu cycles (the default) including the kernel. Repeat test in #2. Dump oprofile result and post that here. Hope it helps. -- tejun - 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 From htejun@gmail.com Mon Nov 28 19:09:27 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Mon, 28 Nov 2005 19:09:37 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932344AbVK2DJf (ORCPT ); Mon, 28 Nov 2005 22:09:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932345AbVK2DJf (ORCPT ); Mon, 28 Nov 2005 22:09:35 -0500 Received: from zproxy.gmail.com ([64.233.162.201]:10556 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S932344AbVK2DJe (ORCPT ); Mon, 28 Nov 2005 22:09:34 -0500 Received: by zproxy.gmail.com with SMTP id 13so18526nzn for ; Mon, 28 Nov 2005 19:09:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=U2oUe4WCvtKv9NUjIMPoFVn+3eethCnJQ5KbadmVf64OXO/jaAIl8YMhmQWFtkt7oGP2n8ZDhk59mo1lqm04nt/e0kzapFnhVY7X0xgbyOlPdtjNWn88Oerz5x9P+NodshDLGSznaMSQTfu6cI1s7ne0VywTJW8qjAI7BCm9Esg= Received: by 10.36.227.25 with SMTP id z25mr4116956nzg; Mon, 28 Nov 2005 19:09:34 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id 15sm398836nzp.2005.11.28.19.09.31; Mon, 28 Nov 2005 19:09:33 -0800 (PST) Received: from [127.0.0.1] (htj.dyndns.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by htj.dyndns.org (Postfix) with ESMTP id E773D1842E0; Tue, 29 Nov 2005 12:09:27 +0900 (KST) Message-ID: <438BC667.4040107@gmail.com> Date: Tue, 29 Nov 2005 12:09:27 +0900 From: Tejun Heo User-Agent: Debian Thunderbird 1.0.7 (X11/20051019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tejun Heo CC: "Raz Ben-Jehuda(caro)" , Jeff Garzik , linux-ide@vger.kernel.org Subject: Re: [PATCH] libata: implement ata_qc_exec_internal() References: <20051128164201.GA7530@htj.dyndns.org> <5d96567b0511280948t45881bf9x989f27be235b47a1@mail.gmail.com> <438BC618.8070300@gmail.com> In-Reply-To: <438BC618.8070300@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Tejun Heo wrote: > Raz Ben-Jehuda(caro) wrote: > >> does it solve the cpu usage ? >> >> On 11/28/05, Tejun Heo wrote: >> >>> Each user libata internal commands initializes a qc, issues it, waits >>> for its completion and checks for errors. This patch factors internal >>> command execution sequence into ata_qc_exec_internal(). The function >>> also removes race condition between irq and timeout handling. >>> >>> Signed-off-by: Tejun Heo >>> > > Hi, Raz. > > It propabably has nothing to do with the cpu usage problem on piix you > reported. I think you need to post more data to get people on the list > interested in your problem. The followings may help. > > 1. Please report exactly which kernel you're using and more information > on the hardware will also help. > > 2. Don't use raid or any fs on it. Just perform tests on raw /dev/sdx > devices. Do something like 'time dd if=/dev/sdx of=/dev/zero bs=1M > count=1024' and report how much user/system time it uses. Oops, count=1024 is way too small. Do something like bs=1M count=1M or maybe count=10M. > > 3. If above shows large system time consumption, build your kernel with > oprofile. Start recording non-idle cpu cycles (the default) including > the kernel. Repeat test in #2. Dump oprofile result and post that here. > > Hope it helps. > -- tejun - 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 From htejun@gmail.com Mon Nov 28 19:12:04 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Mon, 28 Nov 2005 19:12:14 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932345AbVK2DMM (ORCPT ); Mon, 28 Nov 2005 22:12:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932346AbVK2DMM (ORCPT ); Mon, 28 Nov 2005 22:12:12 -0500 Received: from zproxy.gmail.com ([64.233.162.202]:8375 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S932345AbVK2DML (ORCPT ); Mon, 28 Nov 2005 22:12:11 -0500 Received: by zproxy.gmail.com with SMTP id 14so1519623nzn for ; Mon, 28 Nov 2005 19:12:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=TeMMfj+ftf0D6UrEsU4c2YCwqBh5ou8Ens4Tl0T/FWXr0IONJQPcnxtZ25qlNc8Gsyx0IPA3j4EXdHzcjnGMgAsHdkB5H8IYgj6H4+84nAE8OkCBh3vCnZBtLbB7CMc3h4BMuN0ioRvCMpT+WKMV0ifK8/bDzObL06kC/FRIg3E= Received: by 10.36.108.14 with SMTP id g14mr3951436nzc; Mon, 28 Nov 2005 19:12:10 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id j4sm210512nzd.2005.11.28.19.12.08; Mon, 28 Nov 2005 19:12:10 -0800 (PST) Received: from [127.0.0.1] (htj.dyndns.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by htj.dyndns.org (Postfix) with ESMTP id 8DC601842E0; Tue, 29 Nov 2005 12:12:04 +0900 (KST) Message-ID: <438BC704.9080604@gmail.com> Date: Tue, 29 Nov 2005 12:12:04 +0900 From: Tejun Heo User-Agent: Debian Thunderbird 1.0.7 (X11/20051019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tejun Heo CC: "Raz Ben-Jehuda(caro)" , Jeff Garzik , linux-ide@vger.kernel.org Subject: Re: [PATCH] libata: implement ata_qc_exec_internal() References: <20051128164201.GA7530@htj.dyndns.org> <5d96567b0511280948t45881bf9x989f27be235b47a1@mail.gmail.com> <438BC618.8070300@gmail.com> <438BC667.4040107@gmail.com> In-Reply-To: <438BC667.4040107@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Tejun Heo wrote: > Tejun Heo wrote: > >> Raz Ben-Jehuda(caro) wrote: >> >>> does it solve the cpu usage ? >>> >>> On 11/28/05, Tejun Heo wrote: >>> >>>> Each user libata internal commands initializes a qc, issues it, waits >>>> for its completion and checks for errors. This patch factors internal >>>> command execution sequence into ata_qc_exec_internal(). The function >>>> also removes race condition between irq and timeout handling. >>>> >>>> Signed-off-by: Tejun Heo >>>> >> >> Hi, Raz. >> >> It propabably has nothing to do with the cpu usage problem on piix you >> reported. I think you need to post more data to get people on the >> list interested in your problem. The followings may help. >> >> 1. Please report exactly which kernel you're using and more >> information on the hardware will also help. >> >> 2. Don't use raid or any fs on it. Just perform tests on raw /dev/sdx >> devices. Do something like 'time dd if=/dev/sdx of=/dev/zero bs=1M >> count=1024' and report how much user/system time it uses. > > > Oops, count=1024 is way too small. Do something like bs=1M count=1M or > maybe count=10M. I hate myself. I must be on crack or something now. count=1024 should be fine (count=2k or 4k should be fine too). Don't do count=1M or 10M. Sorry guys. :-) -- tejun - 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 From thanatoz@ucla.edu Mon Nov 28 20:04:33 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Mon, 28 Nov 2005 20:05:49 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750713AbVK2EEg (ORCPT ); Mon, 28 Nov 2005 23:04:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750714AbVK2EEf (ORCPT ); Mon, 28 Nov 2005 23:04:35 -0500 Received: from smtp-5.smtp.ucla.edu ([169.232.47.138]:64135 "EHLO smtp-5.smtp.ucla.edu") by vger.kernel.org with ESMTP id S1750713AbVK2EEf (ORCPT ); Mon, 28 Nov 2005 23:04:35 -0500 Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.141]) by smtp-5.smtp.ucla.edu (8.13.4/8.13.4) with ESMTP id jAT44X4H007392; Mon, 28 Nov 2005 20:04:33 -0800 Received: from [128.97.167.86] (s3167-86.resnet.ucla.edu [128.97.167.86] (may be forged)) (authenticated bits=0) by mail.ucla.edu (8.13.4/8.13.4) with ESMTP id jAT44XPR023065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Nov 2005 20:04:33 -0800 Message-ID: <438BD351.60902@ucla.edu> Date: Mon, 28 Nov 2005 20:04:33 -0800 From: Ethan Chen User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org CC: thanatoz@ucla.edu Subject: SIL_QUIRK_MOD15WRITE workaround problem on 2.6.14 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Probable-Spam: no X-Spam-Report: none X-Scanned-By: smtp.ucla.edu on 169.232.47.138 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org I've got a dual Opteron 242 machine here with 2x Seagate ST3200822AS SATA drives attached to a Silicon Image SI3114 controller, and after upgrading to 2.6.14 from 2.6.13, it seems the SIL_QUIRK_MOD15WRITE workaround for the sata_sil driver isn't being applied anymore. This caused me trouble in the past before my drive was added to the blacklist, and this message that comes up when writing (~4GBfiles to test) files, right before the computer locks up, is the same as before: kernel: ata1: command 0x35 timeout, stat 0xd8 host_stat 0x61 In the dmesg, the 'Applying Seagate errata fix' message doesn't appear anymore as well. Finally, without the fix, write speeds are much higher as well, before it locks up. dmesg snippet from 2.6.13.4 kernel: SCSI subsystem initialized kernel: ACPI: PCI Interrupt 0000:03:05.0[A] -> GSI 17 (level, low) -> IRQ 16 kernel: ata1: SATA max UDMA/100 cmd 0xFFFFC20000004C80 ctl 0xFFFFC20000004C8A bmdma 0xFFFFC20000004C00 irq 16 kernel: ata2: SATA max UDMA/100 cmd 0xFFFFC20000004CC0 ctl 0xFFFFC20000004CCA bmdma 0xFFFFC20000004C08 irq 16 kernel: ata3: SATA max UDMA/100 cmd 0xFFFFC20000004E80 ctl 0xFFFFC20000004E8A bmdma 0xFFFFC20000004E00 irq 16 kernel: ata4: SATA max UDMA/100 cmd 0xFFFFC20000004EC0 ctl 0xFFFFC20000004ECA bmdma 0xFFFFC20000004E08 irq 16 kernel: input: AT Translated Set 2 keyboard on isa0060/serio0 kernel: ata1: dev 0 ATA, max UDMA/133, 390721968 sectors: lba48 kernel: ata1(0): applying Seagate errata fix kernel: ata1: dev 0 configured for UDMA/100 kernel: scsi0 : sata_sil kernel: ata2: dev 0 ATA, max UDMA/133, 390721968 sectors: lba48 kernel: ata2(0): applying Seagate errata fix kernel: ata2: dev 0 configured for UDMA/100 kernel: scsi1 : sata_sil kernel: ata3: dev 0 ATA, max UDMA/133, 586114704 sectors: lba48 kernel: ata3: dev 0 configured for UDMA/100 kernel: scsi2 : sata_sil kernel: ata4: no device found (phy stat 00000000) kernel: scsi3 : sata_sil dmesg snippet from 2.6.14.2 kernel: SCSI subsystem initialized kernel: ACPI: PCI Interrupt 0000:03:05.0[A] -> GSI 17 (level, low) -> IRQ 16 kernel: ata1: SATA max UDMA/100 cmd 0xFFFFC20000004C80 ctl 0xFFFFC20000004C8A bmdma 0xFFFFC20000004C00 irq 16 kernel: ata2: SATA max UDMA/100 cmd 0xFFFFC20000004CC0 ctl 0xFFFFC20000004CCA bmdma 0xFFFFC20000004C08 irq 16 kernel: ata3: SATA max UDMA/100 cmd 0xFFFFC20000004E80 ctl 0xFFFFC20000004E8A bmdma 0xFFFFC20000004E00 irq 16 kernel: ata4: SATA max UDMA/100 cmd 0xFFFFC20000004EC0 ctl 0xFFFFC20000004ECA bmdma 0xFFFFC20000004E08 irq 16 kernel: input: AT Translated Set 2 keyboard on isa0060/serio0 kernel: ata1: dev 0 ATA, max UDMA/133, 390721968 sectors: lba48 kernel: ata1: dev 0 configured for UDMA/100 kernel: scsi0 : sata_sil kernel: ata2: dev 0 ATA, max UDMA/133, 390721968 sectors: lba48 kernel: ata2: dev 0 configured for UDMA/100 kernel: scsi1 : sata_sil kernel: ata3: dev 0 ATA, max UDMA/133, 586114704 sectors: lba48 kernel: ata3: dev 0 configured for UDMA/100 kernel: scsi2 : sata_sil kernel: ata4: no device found (phy stat 00000000) kernel: scsi3 : sata_sil Thanks, Ethan Chen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From albertcc@tw.ibm.com Mon Nov 28 23:41:57 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Mon, 28 Nov 2005 23:42:16 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750800AbVK2HmN (ORCPT ); Tue, 29 Nov 2005 02:42:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750801AbVK2HmN (ORCPT ); Tue, 29 Nov 2005 02:42:13 -0500 Received: from e33.co.us.ibm.com ([32.97.110.151]:42933 "EHLO e33.co.us.ibm.com") by vger.kernel.org with ESMTP id S1750800AbVK2HmM (ORCPT ); Tue, 29 Nov 2005 02:42:12 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAT7g6pV001666 for ; Tue, 29 Nov 2005 02:42:06 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAT7fZCh109756 for ; Tue, 29 Nov 2005 00:41:36 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jAT7g5MR019549 for ; Tue, 29 Nov 2005 00:42:05 -0700 Received: from [127.0.0.1] ([9.191.75.115]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jAT7ftC2019440; Tue, 29 Nov 2005 00:42:04 -0700 Message-ID: <438C0645.3020301@tw.ibm.com> Date: Tue, 29 Nov 2005 15:41:57 +0800 From: Albert Lee User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tejun Heo CC: Jeff Garzik , linux-ide@vger.kernel.org Subject: Re: [PATCH] libata: implement ata_qc_exec_internal() References: <20051128164201.GA7530@htj.dyndns.org> In-Reply-To: <20051128164201.GA7530@htj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 39 Tejun Heo wrote: > Each user libata internal commands initializes a qc, issues it, waits > for its completion and checks for errors. This patch factors internal > command execution sequence into ata_qc_exec_internal(). The function > also removes race condition between irq and timeout handling. > > Signed-off-by: Tejun Heo > > diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c > index f1047a0..40c488e 100644 > --- a/drivers/scsi/libata-core.c > +++ b/drivers/scsi/libata-core.c > @@ -1047,28 +1047,73 @@ static unsigned int ata_pio_modes(const > return modes; > } > > -static int ata_qc_wait_err(struct ata_queued_cmd *qc, > - struct completion *wait) > +/** > + * ata_qc_exec_internal - execute libata internal command > + * @qc: Command to execute > + * > + * Executes libata internal command with timeout. Timeout and > + * error conditions are reported via return value. No recovery > + * action is taken after a command times out. It's caller's duty > + * to clean up after timeout. > + * > + * Also, note that error condition is checked after the qc is > + * completed, meaning that if another command is issued before > + * checking the condition, we get the wrong values. As internal > + * cmds are used only for initialization and recovery, this > + * shouldn't cause any problem. > + * > + * LOCKING: > + * None. Should be called with kernel context, might sleep. > + */ > + > +static unsigned ata_qc_exec_internal(struct ata_queued_cmd *qc) > { > - int rc = 0; > + struct ata_port *ap = qc->ap; > + DECLARE_COMPLETION(wait); > + unsigned long tmout_left; > + unsigned int err_mask; > + int rc; > > - if (wait_for_completion_timeout(wait, 30 * HZ) < 1) { > - /* timeout handling */ > - unsigned int err_mask = ac_err_mask(ata_chk_status(qc->ap)); > + if (ata_busy_sleep(ap, ATA_TMOUT_INTERNAL_QUICK, ATA_TMOUT_INTERNAL)) > + return -ETIMEDOUT; > > - if (!err_mask) { > + qc->complete_fn = ata_qc_complete_noop; > + qc->waiting = &wait; > + > + spin_lock_irq(&ap->host_set->lock); > + rc = ata_qc_issue(qc); > + spin_unlock_irq(&ap->host_set->lock); > + > + if (rc) > + return AC_ERR_OTHER; > + > + tmout_left = wait_for_completion_timeout(&wait, ATA_TMOUT_INTERNAL); > + err_mask = ac_err_mask(ata_chk_status(qc->ap)); Could we get the err_mask from the qc->complete_fn? (For some case where the software finds something wrong, but the device ata_chk_status(qc->ap) is zero.) Albert > + > + if (!tmout_left) { > + /* timeout handling */ > + if (!err_mask) > printk(KERN_WARNING "ata%u: slow completion (cmd %x)\n", > qc->ap->id, qc->tf.command); > - } else { > + else > printk(KERN_WARNING "ata%u: qc timeout (cmd %x)\n", > qc->ap->id, qc->tf.command); > - rc = -EIO; > - } > > - ata_qc_complete(qc, err_mask); > + spin_lock_irq(&ap->host_set->lock); > + > + /* We're racing with irq here. If we lose, the > + * following test prevents us from completing the qc > + * again. If completion irq occurs after here but > + * before the caller cleans up, it will result in a > + * spurious interrupt. We can live with that. > + */ > + if (qc->flags & ATA_QCFLAG_ACTIVE) > + ata_qc_complete(qc, err_mask); > + > + spin_unlock_irq(&ap->host_set->lock); > } > > - return rc; > + return err_mask; > } > - 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 From htejun@gmail.com Tue Nov 29 05:17:17 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 05:17:33 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751343AbVK2NRZ (ORCPT ); Tue, 29 Nov 2005 08:17:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751354AbVK2NRZ (ORCPT ); Tue, 29 Nov 2005 08:17:25 -0500 Received: from zproxy.gmail.com ([64.233.162.201]:20520 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S1751343AbVK2NRZ (ORCPT ); Tue, 29 Nov 2005 08:17:25 -0500 Received: by zproxy.gmail.com with SMTP id 13so123622nzn for ; Tue, 29 Nov 2005 05:17:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=agNLvJTDQ3mCsDMChMA7opLHCo8wGkbPfBQOoVH9WDE9SMKs6A5T7YCvyh7MzEwvlrIpQk1Oxm/qUYGF7th4X8fkDifgFD12QDc6J3GMbnjrKUtI/0ussjB29iZOQDCYmhsThoLFW0C1vi7OKqN4YkVvbe+NkJbKeWssziA+jNs= Received: by 10.36.251.76 with SMTP id y76mr4535924nzh; Tue, 29 Nov 2005 05:17:24 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id 23sm538260nzn.2005.11.29.05.17.21; Tue, 29 Nov 2005 05:17:24 -0800 (PST) Received: by htj.dyndns.org (Postfix, from userid 1000) id 307B21842E5; Tue, 29 Nov 2005 22:17:17 +0900 (KST) Date: Tue, 29 Nov 2005 22:17:17 +0900 From: Tejun Heo To: Albert Lee Cc: Jeff Garzik , linux-ide@vger.kernel.org Subject: [PATCH 1/2] libata: implement ata_exec_internal() Message-ID: <20051129131717.GA8505@htj.dyndns.org> References: <20051128164201.GA7530@htj.dyndns.org> <438C0645.3020301@tw.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438C0645.3020301@tw.ibm.com> User-Agent: Mutt/1.5.11 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 126 Each user libata internal commands initializes a qc, issues it, waits for its completion and checks for errors. This patch factors internal command execution sequence into ata_qc_exec_internal(). This change fixes the following bugs. * qc not freed on issue failure * ap->qactive clearing could race with the next internal command * race between timeout handling and irq * ignoring error condition not represented in tf->status Also, qc & hardware are not accessed anymore once it's completed, making internal commands more conformant with general semantics. This change also makes it easy to issue internal commands from multiple threads if that becomes necessary. Signed-off-by: Tejun Heo -- This is take #2 of ata_exec_internal(). qc allocation and tf reading-back have also been moved into ata_exec_internal(). Now all qc handling is done while properly holding host_set lock removing above mentioned rare race conditon (the second item). Index: work/drivers/scsi/libata-core.c =================================================================== --- work.orig/drivers/scsi/libata-core.c 2005-11-29 22:04:15.000000000 +0900 +++ work/drivers/scsi/libata-core.c 2005-11-29 22:06:20.000000000 +0900 @@ -1047,28 +1047,119 @@ static unsigned int ata_pio_modes(const return modes; } -static int ata_qc_wait_err(struct ata_queued_cmd *qc, - struct completion *wait) +struct ata_exec_internal_arg { + unsigned int err_mask; + struct ata_taskfile *tf; + struct completion *waiting; +}; + +int ata_qc_complete_internal(struct ata_queued_cmd *qc, unsigned int err_mask) { - int rc = 0; + struct ata_exec_internal_arg *arg = qc->complete_data; + struct completion *waiting = arg->waiting; - if (wait_for_completion_timeout(wait, 30 * HZ) < 1) { - /* timeout handling */ - unsigned int err_mask = ac_err_mask(ata_chk_status(qc->ap)); - - if (!err_mask) { - printk(KERN_WARNING "ata%u: slow completion (cmd %x)\n", - qc->ap->id, qc->tf.command); - } else { - printk(KERN_WARNING "ata%u: qc timeout (cmd %x)\n", - qc->ap->id, qc->tf.command); - rc = -EIO; - } + if (!(err_mask & ~AC_ERR_DEV)) + qc->ap->ops->tf_read(qc->ap, arg->tf); + arg->err_mask = err_mask; + arg->waiting = NULL; + complete(waiting); + + return 0; +} + +/** + * ata_exec_internal - execute libata internal command + * @ap: Port to which the command is sent + * @dev: Device to which the command is sent + * @tf: Taskfile registers for the command and the result + * @dma_dir: Data tranfer direction of the command + * @buf: Data buffer of the command + * @buflen: Length of data buffer + * + * Executes libata internal command with timeout. @tf contains + * command on entry and result on return. Timeout and error + * conditions are reported via return value. No recovery action + * is taken after a command times out. It's caller's duty to + * clean up after timeout. + * + * LOCKING: + * None. Should be called with kernel context, might sleep. + */ + +static unsigned +ata_exec_internal(struct ata_port *ap, struct ata_device *dev, + struct ata_taskfile *tf, + int dma_dir, void *buf, unsigned int buflen) +{ + u8 command = tf->command; + struct ata_queued_cmd *qc; + DECLARE_COMPLETION(wait); + unsigned long flags; + struct ata_exec_internal_arg arg; + + if (ata_busy_sleep(ap, ATA_TMOUT_INTERNAL_QUICK, ATA_TMOUT_INTERNAL)) + return AC_ERR_OTHER; + + spin_lock_irqsave(&ap->host_set->lock, flags); + + qc = ata_qc_new_init(ap, dev); + BUG_ON(qc == NULL); + + qc->tf = *tf; + qc->dma_dir = dma_dir; + if (dma_dir != DMA_NONE) { + ata_sg_init_one(qc, buf, buflen); + qc->nsect = buflen / ATA_SECT_SIZE; + printk("dma_dir=%d buflen=%u nsect=%d\n", + dma_dir, buflen, qc->nsect); + } + + arg.waiting = &wait; + arg.tf = tf; + qc->complete_data = &arg; + qc->complete_fn = ata_qc_complete_internal; + + if (ata_qc_issue(qc)) + goto issue_fail; + + spin_unlock_irqrestore(&ap->host_set->lock, flags); + + if (!wait_for_completion_timeout(&wait, ATA_TMOUT_INTERNAL)) { + int timedout; + + spin_lock_irqsave(&ap->host_set->lock, flags); + + /* We're racing with irq here. If we lose, the + * following test prevents us from completing the qc + * again. If completion irq occurs after here but + * before the caller cleans up, it will result in a + * spurious interrupt. We can live with that. + */ + timedout = arg.waiting != NULL; + if (timedout) + ata_qc_complete(qc, 0); + + spin_unlock_irqrestore(&ap->host_set->lock, flags); - ata_qc_complete(qc, err_mask); + if (timedout) { + arg.err_mask = ac_err_mask(tf->command); + if (!arg.err_mask) + printk(KERN_WARNING + "ata%u: slow completion (cmd %x)\n", + ap->id, command); + else + printk(KERN_WARNING + "ata%u: qc timeout (cmd %x)\n", + ap->id, command); + } } - return rc; + return arg.err_mask; + + issue_fail: + ata_qc_free(qc); + spin_unlock_irqrestore(&ap->host_set->lock, flags); + return AC_ERR_OTHER; } /** @@ -1100,9 +1191,8 @@ static void ata_dev_identify(struct ata_ u16 tmp; unsigned long xfer_modes; unsigned int using_edd; - DECLARE_COMPLETION(wait); - struct ata_queued_cmd *qc; - unsigned long flags; + struct ata_taskfile tf; + unsigned int err_mask; int rc; if (!ata_dev_present(dev)) { @@ -1123,40 +1213,26 @@ static void ata_dev_identify(struct ata_ ata_dev_select(ap, device, 1, 1); /* select device 0/1 */ - qc = ata_qc_new_init(ap, dev); - BUG_ON(qc == NULL); - - ata_sg_init_one(qc, dev->id, sizeof(dev->id)); - qc->dma_dir = DMA_FROM_DEVICE; - qc->tf.protocol = ATA_PROT_PIO; - qc->nsect = 1; - retry: + ata_tf_init(ap, &tf, device); + if (dev->class == ATA_DEV_ATA) { - qc->tf.command = ATA_CMD_ID_ATA; + tf.command = ATA_CMD_ID_ATA; DPRINTK("do ATA identify\n"); } else { - qc->tf.command = ATA_CMD_ID_ATAPI; + tf.command = ATA_CMD_ID_ATAPI; DPRINTK("do ATAPI identify\n"); } - qc->waiting = &wait; - qc->complete_fn = ata_qc_complete_noop; + tf.protocol = ATA_PROT_PIO; - spin_lock_irqsave(&ap->host_set->lock, flags); - rc = ata_qc_issue(qc); - spin_unlock_irqrestore(&ap->host_set->lock, flags); + err_mask = ata_exec_internal(ap, dev, &tf, DMA_FROM_DEVICE, + dev->id, sizeof(dev->id)); - if (rc) - goto err_out; - else - ata_qc_wait_err(qc, &wait); - - spin_lock_irqsave(&ap->host_set->lock, flags); - ap->ops->tf_read(ap, &qc->tf); - spin_unlock_irqrestore(&ap->host_set->lock, flags); + if (err_mask) { + if (err_mask & ~AC_ERR_DEV) + goto err_out; - if (qc->tf.command & ATA_ERR) { /* * arg! EDD works for all test cases, but seems to return * the ATA signature for some ATAPI devices. Until the @@ -1169,13 +1245,9 @@ retry: * to have this problem. */ if ((using_edd) && (dev->class == ATA_DEV_ATA)) { - u8 err = qc->tf.feature; + u8 err = tf.feature; if (err & ATA_ABORTED) { dev->class = ATA_DEV_ATAPI; - qc->cursg = 0; - qc->cursg_ofs = 0; - qc->cursect = 0; - qc->nsect = 1; goto retry; } } @@ -2288,34 +2360,23 @@ static int ata_choose_xfer_mode(const st static void ata_dev_set_xfermode(struct ata_port *ap, struct ata_device *dev) { - DECLARE_COMPLETION(wait); - struct ata_queued_cmd *qc; - int rc; - unsigned long flags; + struct ata_taskfile tf; /* set up set-features taskfile */ DPRINTK("set features - xfer mode\n"); - qc = ata_qc_new_init(ap, dev); - BUG_ON(qc == NULL); - - qc->tf.command = ATA_CMD_SET_FEATURES; - qc->tf.feature = SETFEATURES_XFER; - qc->tf.flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE; - qc->tf.protocol = ATA_PROT_NODATA; - qc->tf.nsect = dev->xfer_mode; - - qc->waiting = &wait; - qc->complete_fn = ata_qc_complete_noop; - - spin_lock_irqsave(&ap->host_set->lock, flags); - rc = ata_qc_issue(qc); - spin_unlock_irqrestore(&ap->host_set->lock, flags); + ata_tf_init(ap, &tf, dev->devno); + tf.command = ATA_CMD_SET_FEATURES; + tf.feature = SETFEATURES_XFER; + tf.flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE; + tf.protocol = ATA_PROT_NODATA; + tf.nsect = dev->xfer_mode; - if (rc) + if (ata_exec_internal(ap, dev, &tf, DMA_NONE, NULL, 0)) { + printk(KERN_ERR "ata%u: failed to set xfermode, disabled\n", + ap->id); ata_port_disable(ap); - else - ata_qc_wait_err(qc, &wait); + } DPRINTK("EXIT\n"); } @@ -2330,41 +2391,25 @@ static void ata_dev_set_xfermode(struct static void ata_dev_reread_id(struct ata_port *ap, struct ata_device *dev) { - DECLARE_COMPLETION(wait); - struct ata_queued_cmd *qc; - unsigned long flags; - int rc; - - qc = ata_qc_new_init(ap, dev); - BUG_ON(qc == NULL); + struct ata_taskfile tf; - ata_sg_init_one(qc, dev->id, sizeof(dev->id)); - qc->dma_dir = DMA_FROM_DEVICE; + ata_tf_init(ap, &tf, dev->devno); if (dev->class == ATA_DEV_ATA) { - qc->tf.command = ATA_CMD_ID_ATA; + tf.command = ATA_CMD_ID_ATA; DPRINTK("do ATA identify\n"); } else { - qc->tf.command = ATA_CMD_ID_ATAPI; + tf.command = ATA_CMD_ID_ATAPI; DPRINTK("do ATAPI identify\n"); } - qc->tf.flags |= ATA_TFLAG_DEVICE; - qc->tf.protocol = ATA_PROT_PIO; - qc->nsect = 1; - - qc->waiting = &wait; - qc->complete_fn = ata_qc_complete_noop; + tf.flags |= ATA_TFLAG_DEVICE; + tf.protocol = ATA_PROT_PIO; - spin_lock_irqsave(&ap->host_set->lock, flags); - rc = ata_qc_issue(qc); - spin_unlock_irqrestore(&ap->host_set->lock, flags); - - if (rc) + if (ata_exec_internal(ap, dev, &tf, DMA_FROM_DEVICE, + dev->id, sizeof(dev->id))) goto err_out; - ata_qc_wait_err(qc, &wait); - swap_buf_le16(dev->id, ATA_ID_WORDS); ata_dump_id(dev); @@ -2373,6 +2418,7 @@ static void ata_dev_reread_id(struct ata return; err_out: + printk(KERN_ERR "ata%u: failed to reread ID, disabled\n", ap->id); ata_port_disable(ap); } @@ -2386,10 +2432,7 @@ err_out: static void ata_dev_init_params(struct ata_port *ap, struct ata_device *dev) { - DECLARE_COMPLETION(wait); - struct ata_queued_cmd *qc; - int rc; - unsigned long flags; + struct ata_taskfile tf; u16 sectors = dev->id[6]; u16 heads = dev->id[3]; @@ -2400,26 +2443,18 @@ static void ata_dev_init_params(struct a /* set up init dev params taskfile */ DPRINTK("init dev params \n"); - qc = ata_qc_new_init(ap, dev); - BUG_ON(qc == NULL); - - qc->tf.command = ATA_CMD_INIT_DEV_PARAMS; - qc->tf.flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE; - qc->tf.protocol = ATA_PROT_NODATA; - qc->tf.nsect = sectors; - qc->tf.device |= (heads - 1) & 0x0f; /* max head = num. of heads - 1 */ - - qc->waiting = &wait; - qc->complete_fn = ata_qc_complete_noop; - - spin_lock_irqsave(&ap->host_set->lock, flags); - rc = ata_qc_issue(qc); - spin_unlock_irqrestore(&ap->host_set->lock, flags); + ata_tf_init(ap, &tf, dev->devno); + tf.command = ATA_CMD_INIT_DEV_PARAMS; + tf.flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE; + tf.protocol = ATA_PROT_NODATA; + tf.nsect = sectors; + tf.device |= (heads - 1) & 0x0f; /* max head = num. of heads - 1 */ - if (rc) + if (ata_exec_internal(ap, dev, &tf, DMA_NONE, NULL, 0)) { + printk(KERN_ERR "ata%u: failed to init parameters, disabled\n", + ap->id); ata_port_disable(ap); - else - ata_qc_wait_err(qc, &wait); + } DPRINTK("EXIT\n"); } @@ -3641,11 +3676,6 @@ struct ata_queued_cmd *ata_qc_new_init(s return qc; } -int ata_qc_complete_noop(struct ata_queued_cmd *qc, unsigned int err_mask) -{ - return 0; -} - static void __ata_qc_complete(struct ata_queued_cmd *qc) { struct ata_port *ap = qc->ap; Index: work/drivers/scsi/libata.h =================================================================== --- work.orig/drivers/scsi/libata.h 2005-11-29 22:04:15.000000000 +0900 +++ work/drivers/scsi/libata.h 2005-11-29 22:05:26.000000000 +0900 @@ -39,7 +39,6 @@ struct ata_scsi_args { /* libata-core.c */ extern int atapi_enabled; -extern int ata_qc_complete_noop(struct ata_queued_cmd *qc, unsigned int err_mask); extern struct ata_queued_cmd *ata_qc_new_init(struct ata_port *ap, struct ata_device *dev); extern void ata_rwcmd_protocol(struct ata_queued_cmd *qc); Index: work/include/linux/libata.h =================================================================== --- work.orig/include/linux/libata.h 2005-11-29 22:04:15.000000000 +0900 +++ work/include/linux/libata.h 2005-11-29 22:06:20.000000000 +0900 @@ -136,6 +136,8 @@ enum { ATA_TMOUT_BOOT_QUICK = 7 * HZ, /* hueristic */ ATA_TMOUT_DATAOUT = 30 * HZ, ATA_TMOUT_DATAOUT_QUICK = 5 * HZ, + ATA_TMOUT_INTERNAL = 30 * HZ, + ATA_TMOUT_INTERNAL_QUICK = 5 * HZ, /* ATA bus states */ BUS_UNKNOWN = 0, @@ -284,6 +286,7 @@ struct ata_queued_cmd { struct scatterlist *__sg; ata_qc_cb_t complete_fn; + void *complete_data; struct completion *waiting; - 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 From htejun@gmail.com Tue Nov 29 05:19:06 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 05:19:18 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751353AbVK2NTP (ORCPT ); Tue, 29 Nov 2005 08:19:15 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751354AbVK2NTP (ORCPT ); Tue, 29 Nov 2005 08:19:15 -0500 Received: from zproxy.gmail.com ([64.233.162.207]:10023 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S1751353AbVK2NTO (ORCPT ); Tue, 29 Nov 2005 08:19:14 -0500 Received: by zproxy.gmail.com with SMTP id 14so1619697nzn for ; Tue, 29 Nov 2005 05:19:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=WTn8/JBQJcsdzYQEqFffIY0/0gupGRtmbYQ55stBn2ouEbhdoNLASpJLl4FfOIR5jimRiWgZIgRj1G+qd2F7SNOZDhI8OCm7Cs+K5U3ZwNnVmadVZCoVwv+bp002l63yE1+DUBax7Hp/EqntGFTAJhWQHQVwnDFX/sHWTFKDmdw= Received: by 10.36.221.64 with SMTP id t64mr398102nzg; Tue, 29 Nov 2005 05:19:14 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id 19sm1099576nzp.2005.11.29.05.19.11; Tue, 29 Nov 2005 05:19:13 -0800 (PST) Received: by htj.dyndns.org (Postfix, from userid 1000) id CBF551842E5; Tue, 29 Nov 2005 22:19:06 +0900 (KST) Date: Tue, 29 Nov 2005 22:19:06 +0900 From: Tejun Heo To: Albert Lee Cc: Jeff Garzik , linux-ide@vger.kernel.org Subject: [PATCH 2/2] libata: remove qc->waiting Message-ID: <20051129131906.GB8505@htj.dyndns.org> References: <20051128164201.GA7530@htj.dyndns.org> <438C0645.3020301@tw.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438C0645.3020301@tw.ibm.com> User-Agent: Mutt/1.5.11 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 127 With internal commands converted to use ata_exec_internal(), there is no user of qc->waiting left. Kill it. Signed-off-by: Tejun Heo Index: work/drivers/scsi/libata-core.c =================================================================== --- work.orig/drivers/scsi/libata-core.c 2005-11-29 22:06:20.000000000 +0900 +++ work/drivers/scsi/libata-core.c 2005-11-29 22:06:38.000000000 +0900 @@ -3679,7 +3679,7 @@ struct ata_queued_cmd *ata_qc_new_init(s static void __ata_qc_complete(struct ata_queued_cmd *qc) { struct ata_port *ap = qc->ap; - unsigned int tag, do_clear = 0; + unsigned int tag; qc->flags = 0; tag = qc->tag; @@ -3687,17 +3687,8 @@ static void __ata_qc_complete(struct ata if (tag == ap->active_tag) ap->active_tag = ATA_TAG_POISON; qc->tag = ATA_TAG_POISON; - do_clear = 1; - } - - if (qc->waiting) { - struct completion *waiting = qc->waiting; - qc->waiting = NULL; - complete(waiting); - } - - if (likely(do_clear)) clear_bit(tag, &ap->qactive); + } } /** @@ -3713,7 +3704,6 @@ static void __ata_qc_complete(struct ata void ata_qc_free(struct ata_queued_cmd *qc) { assert(qc != NULL); /* ata_qc_from_tag _might_ return NULL */ - assert(qc->waiting == NULL); /* nothing should be waiting */ __ata_qc_complete(qc); } Index: work/include/linux/libata.h =================================================================== --- work.orig/include/linux/libata.h 2005-11-29 22:06:20.000000000 +0900 +++ work/include/linux/libata.h 2005-11-29 22:06:38.000000000 +0900 @@ -288,8 +288,6 @@ struct ata_queued_cmd { ata_qc_cb_t complete_fn; void *complete_data; - struct completion *waiting; - void *private_data; }; - 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 From bzolnier@gmail.com Tue Nov 29 06:58:22 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 06:59:14 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751369AbVK2O6Y (ORCPT ); Tue, 29 Nov 2005 09:58:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751371AbVK2O6Y (ORCPT ); Tue, 29 Nov 2005 09:58:24 -0500 Received: from nproxy.gmail.com ([64.233.182.203]:9651 "EHLO nproxy.gmail.com") by vger.kernel.org with ESMTP id S1751369AbVK2O6X convert rfc822-to-8bit (ORCPT ); Tue, 29 Nov 2005 09:58:23 -0500 Received: by nproxy.gmail.com with SMTP id q29so586727nfc for ; Tue, 29 Nov 2005 06:58:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MvnzCScgNfCGaUt+AEy5Hsqgv/RiUE+FU2RtPmBLMRgSoXl7LtK9Gpm9XDDTycBj7J0Xpwm4Yx14Xr4dHY5ty1E6nApsSiXpc7BodHJowEsnUd0epp+gzO2Ep2g3Q+DcTsyjffMD5qRUqBIkRI9nKAItAQEiQV6biZSIWs7VuyU= Received: by 10.48.211.11 with SMTP id j11mr588693nfg; Tue, 29 Nov 2005 06:58:22 -0800 (PST) Received: by 10.48.49.7 with HTTP; Tue, 29 Nov 2005 06:58:19 -0800 (PST) Message-ID: <58cb370e0511290658m682ae978hea2100f57252a928@mail.gmail.com> Date: Tue, 29 Nov 2005 15:58:22 +0100 From: Bartlomiej Zolnierkiewicz To: Bill Davidsen Subject: Re: ide-cd doesn't replace ide-scsi? Cc: Luke-Jr , Linux Kernel Mailing List In-Reply-To: <438B70AA.7090805@tmr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Disposition: inline References: <200511281218.17141.luke-jr@utopios.org> <438B70AA.7090805@tmr.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 171 On 11/28/05, Bill Davidsen wrote: > Luke-Jr wrote: > > Note: results are with 2.6.13 (-gentoo-r4 + supermount) and 2.6.14 (-gentoo) > > I've been struggling with burning DVD+R DL discs and upgrading the firmware on > > my DVD burner, and just today decided to rmmod ide-cd and try using ide-scsi. > > Turns out it works... so is ide-cd *supposed* to handle cases other than > > simple reading and burning or is this a bug? If not a bug, should ide-scsi > > really be marked as deprecated? > > Also, two bugs with ide-scsi: > > 1. On loading the module, it detects and allocates 6 SCSI devices for a single > > DVD burner (Toshiba ODD-DVD SD-R5272); kernel log for this event attached > > 2. On attempted unloading of the module, rmmod says 'Killed' and the module > > stays put, corrupt. There was some kind of error in dmesg, but it appears to > > have avoided syslog-- If I see it again, I'll save it. > > I think you may have the probe-all-LUNs set, and a CD burner which > responds to more than one. That's one possible cause for this. That may be it. > Unfortunately using ide-cd still doesn't have the code set to allow all > burning features to work if you are not root. Even if you have > read+write there's one command you need to do multi-session which is > only allowed to root. Works fine for single sessions, I guess that's all > someone uses. Interesting because both drivers ide-cd and sr+ide-scsi use exactly the same code (block/scsi_ioctl.c) to verify which commands don't need root privileges. Care to give details? > Haven't tried unloading the module, so I have no advice on that other > than "don't do that." Known problem with ide-scsi, reference counting for "virtual" SCSI host is missing (it was always buggy but was exposed in 2.6.x something by sr.c changes). Bartlomiej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From axboe@suse.de Tue Nov 29 07:23:01 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 07:23:13 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751377AbVK2PWG (ORCPT ); Tue, 29 Nov 2005 10:22:06 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751378AbVK2PWG (ORCPT ); Tue, 29 Nov 2005 10:22:06 -0500 Received: from ns.virtualhost.dk ([195.184.98.160]:56869 "EHLO virtualhost.dk") by vger.kernel.org with ESMTP id S1751377AbVK2PWF (ORCPT ); Tue, 29 Nov 2005 10:22:05 -0500 Received: from [62.242.22.158] (helo=router.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.36 #1) id 1Eh7Ib-0006tn-00; Tue, 29 Nov 2005 16:21:41 +0100 Received: from nelson.home.kernel.dk ([192.168.0.33] helo=kernel.dk) by router.home.kernel.dk with esmtp (Exim 4.22) id 1Eh7IZ-0006Zn-95; Tue, 29 Nov 2005 16:21:39 +0100 Received: by kernel.dk (Postfix, from userid 1000) id 40A891893AF; Tue, 29 Nov 2005 16:23:01 +0100 (CET) Date: Tue, 29 Nov 2005 16:23:01 +0100 From: Jens Axboe To: Bartlomiej Zolnierkiewicz Cc: Bill Davidsen , Luke-Jr , Linux Kernel Mailing List Subject: Re: ide-cd doesn't replace ide-scsi? Message-ID: <20051129152300.GX15804@suse.de> References: <200511281218.17141.luke-jr@utopios.org> <438B70AA.7090805@tmr.com> <58cb370e0511290658m682ae978hea2100f57252a928@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58cb370e0511290658m682ae978hea2100f57252a928@mail.gmail.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 188 On Tue, Nov 29 2005, Bartlomiej Zolnierkiewicz wrote: > > Unfortunately using ide-cd still doesn't have the code set to allow all > > burning features to work if you are not root. Even if you have > > read+write there's one command you need to do multi-session which is > > only allowed to root. Works fine for single sessions, I guess that's all > > someone uses. > > Interesting because both drivers ide-cd and sr+ide-scsi use exactly > the same code (block/scsi_ioctl.c) to verify which commands don't > need root privileges. Care to give details? Not if he is using /dev/sgX with ide-scsi, only SG_IO through /dev/srX will go through the block/scsi_ioctl.c path. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From brking@us.ibm.com Tue Nov 29 14:13:10 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 14:14:28 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964784AbVK2WO0 (ORCPT ); Tue, 29 Nov 2005 17:14:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964786AbVK2WO0 (ORCPT ); Tue, 29 Nov 2005 17:14:26 -0500 Received: from e5.ny.us.ibm.com ([32.97.182.145]:25542 "EHLO e5.ny.us.ibm.com") by vger.kernel.org with ESMTP id S964784AbVK2WOZ (ORCPT ); Tue, 29 Nov 2005 17:14:25 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jATMEHqw032056; Tue, 29 Nov 2005 17:14:17 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jATMEGGx112296; Tue, 29 Nov 2005 17:14:17 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jATMEG8I012223; Tue, 29 Nov 2005 17:14:16 -0500 Received: from [9.10.86.199] (kaled.rchland.ibm.com [9.10.86.199]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jATMEFGf012208; Tue, 29 Nov 2005 17:14:15 -0500 Message-ID: <438CD276.5030007@us.ibm.com> Date: Tue, 29 Nov 2005 16:13:10 -0600 From: Brian King Reply-To: brking@us.ibm.com User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050715) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dougg@torque.net CC: Luben Tuikov , Jeff Garzik , Bartlomiej Zolnierkiewicz , linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, t.schorpp@gmx.de Subject: Re: [PATCH 1/2] libata: Remove dependence on host_set->dev for SAS References: <4341A91A.3020000@us.ibm.com> <434251E0.9060000@pobox.com> <58cb370e0510040322q1cb7a13bjfc6c7875140d20a9@mail.gmail.com> <58cb370e0510041356h780e7a5aifda0c232f677471e@mail.gmail.com> <43443E99.4090008@pobox.com> <435D5D83.1060201@us.ibm.com> <435D5DE5.7010306@us.ibm.com> <435E7105.4010105@pobox.com> <435E87E8.9010506@us.ibm.com> <435E8AC7.1080407@pobox.com> <435EB656.1040502@adaptec.com> <4360FAC1.8020409@us.ibm.com> <43850F0D.7040907@torque.net> In-Reply-To: <43850F0D.7040907@torque.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 561 Douglas Gilbert wrote: > Brian King wrote: >> I think you really need a >> libata API that the LLDD can call from its queuecommand function >> to translate and send a command, which then calls back into the LLDD >> to send the FIS to the hardware. This allows for all SAS/SATA devices >> under the same HBA to show up under the same scsi_host. > > Brian, > I don't think a SATL is that easy. That is essentially the API that libata has today. Existing SATA drivers have a queuecommand routine that invokes a libata API to send a taskfile to the hardware. > One SCSI command can > translate into zero or more ATA commands. If it translates > to multiple commands, then there is the possibility of an > error prior to the last in the sequence of ATA commands > (how to report; rollback needed ?). The SATL needs to hold > state and needs a service thread if it is to support the > IMMED bit on some commands (e.g. START STOP UNIT). I guess I don't see these problems as unique to SATA drives attached via a SAS adapter, which is what my patchset is trying to implement, but rather general libata issues. Reading Jeff's response, it sounds like the service thread issue is already being worked in another manner. Brian -- Brian King eServer Storage I/O IBM Linux Technology Center - 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 From plink0025@fmail.co.uk Tue Nov 29 16:19:03 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 16:19:07 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751419AbVK3ATF (ORCPT ); Tue, 29 Nov 2005 19:19:05 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751428AbVK3ATF (ORCPT ); Tue, 29 Nov 2005 19:19:05 -0500 Received: from out4.smtp.messagingengine.com ([66.111.4.28]:24277 "EHLO out4.smtp.messagingengine.com") by vger.kernel.org with ESMTP id S1751419AbVK3ATE (ORCPT ); Tue, 29 Nov 2005 19:19:04 -0500 Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 2BCE7D19839 for ; Tue, 29 Nov 2005 19:19:03 -0500 (EST) Received: from web3.messagingengine.com ([10.202.2.212]) by frontend1.internal (MEProxy); Tue, 29 Nov 2005 19:19:03 -0500 Received: by web3.messagingengine.com (Postfix, from userid 99) id D9CBD1C547; Tue, 29 Nov 2005 19:19:03 -0500 (EST) Message-Id: <1133309943.4904.248622863@webmail.messagingengine.com> X-Sasl-Enc: P7WIbWQ3VcEjBzmGKA/PQ/6hdlozlo/7pBlD8ajQLK+L 1133309943 From: "plink" To: linux-ide@vger.kernel.org Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.5 (F2.73; T1.15; A1.64; B3.05; Q3.03) Subject: hda and ide errors after acpi s3 resume, ich4-m controller, PIIX driver Date: Tue, 29 Nov 2005 16:19:03 -0800 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 683 I have a laptop and i'm having a problem concerning acpi s3 and my ide driver. basically, after resume from acpi s3, the hard drive is inaccessible for about a minute and a half. dmesg shows these hda and ide errors immdediately after a resume from s3: hda: lost interrupt evevent-0299: *** Error: No installed handler for fixed event [00000002] Restarting tasks... done hda: dma_timer_expiry: dma status == 0x21 hda: DMA timeout error hda: dma timeout error: status=0x50 { DriveReady SeekComplete } ide: failed opcode was: unknown hda: status error: status=0x50 { DriveReady SeekComplete } ide: failed opcode was: unknown hda: no DRQ after issuing MULTWRITE_EXT hda: status error: status=0x50 { DriveReady SeekComplete } ide: failed opcode was: unknown hda: no DRQ after issuing MULTWRITE_EXT hda: lost interrupt hda: status error: status=0x50 { DriveReady SeekComplete } ide: failed opcode was: unknown hda: no DRQ after issuing MULTWRITE_EXT hda: status error: status=0x50 { DriveReady SeekComplete } ide: failed opcode was: unknown hda: no DRQ after issuing MULTWRITE_EXT ide0: reset: success I posted this on the acpi-devel mailing list and was told that it sounded like a problem with the ide driver and directed to this list. I have an ich4-m ide controller and i'm using the PIIX ide driver, kernel 2.6.13.4. I'm no expert, but it looks like the acpi resume routine is trying to wake up the hard drive in a way that the ide isn't compatible with, and after a few tries just resets the drive. After the reset everything, the drive is fine, but i'm worried about these errors, isn't reseting the drive bad for it? hdparm has it marked as dangerous, and it adds time that i cant do anything after s3 resume. If anybody can help me, I'd really appreciate it. -Jaime Kitsmiller -- http://www.fastmail.fm - Faster than the air-speed velocity of an unladen european swallow - 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 From dom@ijichi.org Tue Nov 29 16:34:00 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 16:34:12 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750706AbVK3AeK (ORCPT ); Tue, 29 Nov 2005 19:34:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750731AbVK3AeK (ORCPT ); Tue, 29 Nov 2005 19:34:10 -0500 Received: from buffy.ijichi.org ([213.161.76.94]:14585 "EHLO buffy.ijichi.org") by vger.kernel.org with ESMTP id S1750706AbVK3AeJ (ORCPT ); Tue, 29 Nov 2005 19:34:09 -0500 Received: from localhost (localhost [127.0.0.1]) by buffy.ijichi.org (Postfix) with ESMTP id 1CFDF183D8; Wed, 30 Nov 2005 00:34:07 +0000 (GMT) Received: from buffy.ijichi.org ([127.0.0.1]) by localhost (buffy.ijichi.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26307-01; Wed, 30 Nov 2005 00:34:01 +0000 (GMT) Received: by buffy.ijichi.org (Postfix, from userid 502) id C49AC183D7; Wed, 30 Nov 2005 00:34:00 +0000 (GMT) Received: from 81-178-123-44.dsl.pipex.com (81-178-123-44.dsl.pipex.com [81.178.123.44]) by www.ijichi.org (IMP) with HTTP for ; Wed, 30 Nov 2005 00:34:00 +0000 Message-ID: <1133310840.438cf3782abee@www.ijichi.org> Date: Wed, 30 Nov 2005 00:34:00 +0000 From: Dominic Ijichi To: "Randy.Dunlap" Cc: linux-ide@vger.kernel.org Subject: Re: sata suspend status? References: <1133020582.438885a6615dc@www.ijichi.org> <20051127205613.18f48772.rdunlap@xenotime.net> <1133169049.438ac999da2ab@www.ijichi.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Priority: 3 (Normal) X-Originating-IP: 81.178.123.44 X-DSPAM-Result: Innocent X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 438cf37c263613203328042 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at ijichi.org X-Spam-Status: No, score=-2.453 tagged_above=-999 required=6.31 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DSPAM_HAM=-0.1, RCVD_IN_SORBS_DUL=2.046] X-Spam-Score: -2.453 X-Spam-Level: Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: A X-Keywords: X-UID: 696 Quoting "Randy.Dunlap" : > On Mon, 28 Nov 2005, Dominic Ijichi wrote: > > > Quoting "Randy.Dunlap" : > > > > > On Sat, 26 Nov 2005 15:56:22 +0000 Dominic Ijichi wrote: > > > > > > > hello > > > > > > > > i've been trying to get my laptop s3 suspend working - its all working > > > except I > > > > believe for sata. it resumes and you can do type in, interact with the > > > kernel > > > > but as soon as you do anything that requires disk access it hangs. > sorry if > > > this > > > > isn't very technical description, i can provide anything if told > roughly > > > what to do! > > > > > > > > i've searched extensively for patches, tried all the various > incantations, > > > and > > > > currently running 2.6.15-rc2 which is supposed to provide support for > ata > > > > passthrough and basic scsi suspend, but still same problem. i have: > > > > > > > > Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 04) > > > > > > > > /dev/sda = HITACHI_DK23FA-60 > > > > > > > > hdparm -I /dev/sda works fine.love > > > > > > > > I note recent patches from randy dunlap from intel to do with this > > > controller > > > > and acpi but not sure what kernel this is against or whether it's > relevent. > > > > > > > > i believe there are many people out there who would love to get sata > > > > suspend/resume working, its a major problem for all recent laptops and > us > > > folks > > > > who love running linux. what's the current status please? > > > > > > Hi, > > > It seems to work for some people. I don't know if that's just > > > good luck or that some controllers don't need the SATA ACPI methods > > > that I am working on. We should know more about that in the next > > > few weeks, I hope. > > > > hiya > > can't work out how to apply your patches, have tried against 2.6.15-rc2 > with > > symlinked directories but everything rejects. sorry for my ignorance, > would > > like to try these out! > > Sorry about that. I'll correct that and repost with exact > info about correct kernel version to use. hmm, i must have cut and paste them wrongly as i get failed hunks. is there a decent archive of the mailing list? the MARC one pointed to from kernel.org doesnt seem to update or have attachments. > However, these current patches won't get you much additional help > for SATA suspend/resume since they lack writing the taskfile data > to the controller ports. really look forward to it! thanks for your work dom > -- > ~Randy ------------------------------------------ This message was penned by the hand of Dom - 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 From rdunlap@xenotime.net Tue Nov 29 16:41:04 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 16:41:09 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750736AbVK3AlH (ORCPT ); Tue, 29 Nov 2005 19:41:07 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750737AbVK3AlH (ORCPT ); Tue, 29 Nov 2005 19:41:07 -0500 Received: from xenotime.net ([66.160.160.81]:52870 "HELO xenotime.net") by vger.kernel.org with SMTP id S1750736AbVK3AlG (ORCPT ); Tue, 29 Nov 2005 19:41:06 -0500 Received: from shark.he.net ([66.160.160.2]) by xenotime.net for ; Tue, 29 Nov 2005 16:41:04 -0800 Date: Tue, 29 Nov 2005 16:41:04 -0800 (PST) From: "Randy.Dunlap" X-X-Sender: rddunlap@shark.he.net To: Dominic Ijichi cc: "Randy.Dunlap" , linux-ide@vger.kernel.org Subject: Re: sata suspend status? In-Reply-To: <1133310840.438cf3782abee@www.ijichi.org> Message-ID: References: <1133020582.438885a6615dc@www.ijichi.org> <20051127205613.18f48772.rdunlap@xenotime.net> <1133169049.438ac999da2ab@www.ijichi.org> <1133310840.438cf3782abee@www.ijichi.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 703 On Wed, 30 Nov 2005, Dominic Ijichi wrote: > Quoting "Randy.Dunlap" : > > > On Mon, 28 Nov 2005, Dominic Ijichi wrote: > > > > > Quoting "Randy.Dunlap" : > > > > > > > On Sat, 26 Nov 2005 15:56:22 +0000 Dominic Ijichi wrote: > > > > > > > > > hello [snip] > > > > Hi, > > > > It seems to work for some people. I don't know if that's just > > > > good luck or that some controllers don't need the SATA ACPI methods > > > > that I am working on. We should know more about that in the next > > > > few weeks, I hope. > > > > > > hiya > > > can't work out how to apply your patches, have tried against 2.6.15-rc2 > > with > > > symlinked directories but everything rejects. sorry for my ignorance, > > would > > > like to try these out! > > > > Sorry about that. I'll correct that and repost with exact > > info about correct kernel version to use. > > hmm, i must have cut and paste them wrongly as i get failed hunks. is there a > decent archive of the mailing list? the MARC one pointed to from kernel.org > doesnt seem to update or have attachments. Cut-n-paste often converts tabs to spaces, so that could be the problem. (BTW, I double-checked after your first email and verified that they applied cleanly.) MARC has the patches -- and none of them were sent as attachments. 1 of 5: http://marc.theaimsgroup.com/?l=linux-ide&m=113279087717303&w=2 then click on "Download message RAW" 2 of 5: http://marc.theaimsgroup.com/?l=linux-ide&m=113279088931675&w=2 and Download message RAW 3 of 5: http://marc.theaimsgroup.com/?l=linux-ide&m=113279087922204&w=2 and Download message RAW 4/5: http://marc.theaimsgroup.com/?l=linux-ide&m=113279088127703&w=2 and Download message RAW 5/5: http://marc.theaimsgroup.com/?l=linux-ide&m=113279088916977&w=2 and Download message RAW > > However, these current patches won't get you much additional help > > for SATA suspend/resume since they lack writing the taskfile data > > to the controller ports. > > really look forward to it! > > thanks for your work > dom I'll also put them on a web site for download after I have these changes made. -- ~Randy - 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 From dom@ijichi.org Tue Nov 29 17:32:04 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 17:32:18 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750771AbVK3BcO (ORCPT ); Tue, 29 Nov 2005 20:32:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750772AbVK3BcO (ORCPT ); Tue, 29 Nov 2005 20:32:14 -0500 Received: from buffy.ijichi.org ([213.161.76.94]:20475 "EHLO buffy.ijichi.org") by vger.kernel.org with ESMTP id S1750771AbVK3BcN (ORCPT ); Tue, 29 Nov 2005 20:32:13 -0500 Received: from localhost (localhost [127.0.0.1]) by buffy.ijichi.org (Postfix) with ESMTP id 9AB27183D8; Wed, 30 Nov 2005 01:32:11 +0000 (GMT) Received: from buffy.ijichi.org ([127.0.0.1]) by localhost (buffy.ijichi.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26430-05; Wed, 30 Nov 2005 01:32:05 +0000 (GMT) Received: by buffy.ijichi.org (Postfix, from userid 502) id C4277183D7; Wed, 30 Nov 2005 01:32:04 +0000 (GMT) Received: from 81-178-123-44.dsl.pipex.com (81-178-123-44.dsl.pipex.com [81.178.123.44]) by www.ijichi.org (IMP) with HTTP for ; Wed, 30 Nov 2005 01:32:04 +0000 Message-ID: <1133314324.438d0114556cd@www.ijichi.org> Date: Wed, 30 Nov 2005 01:32:04 +0000 From: Dominic Ijichi To: "Randy.Dunlap" Cc: linux-ide@vger.kernel.org Subject: Re: sata suspend status? References: <1133020582.438885a6615dc@www.ijichi.org> <20051127205613.18f48772.rdunlap@xenotime.net> <1133169049.438ac999da2ab@www.ijichi.org> <1133310840.438cf3782abee@www.ijichi.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Priority: 3 (Normal) X-Originating-IP: 81.178.123.44 X-DSPAM-Result: Innocent X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 438d01172667190287793 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at ijichi.org X-Spam-Status: No, score=-2.453 tagged_above=-999 required=6.31 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DSPAM_HAM=-0.1, RCVD_IN_SORBS_DUL=2.046] X-Spam-Score: -2.453 X-Spam-Level: Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Quoting "Randy.Dunlap" : > On Wed, 30 Nov 2005, Dominic Ijichi wrote: > > > Quoting "Randy.Dunlap" : > > > > > On Mon, 28 Nov 2005, Dominic Ijichi wrote: > > > > > > > Quoting "Randy.Dunlap" : > > > > > > > > > On Sat, 26 Nov 2005 15:56:22 +0000 Dominic Ijichi wrote: > > > > > > > > > > > hello > > [snip] > > > > > > Hi, > > > > > It seems to work for some people. I don't know if that's just > > > > > good luck or that some controllers don't need the SATA ACPI methods > > > > > that I am working on. We should know more about that in the next > > > > > few weeks, I hope. > > > > > > > > hiya > > > > can't work out how to apply your patches, have tried against 2.6.15-rc2 > > > with > > > > symlinked directories but everything rejects. sorry for my ignorance, > > > would > > > > like to try these out! > > > > > > Sorry about that. I'll correct that and repost with exact > > > info about correct kernel version to use. > > > > hmm, i must have cut and paste them wrongly as i get failed hunks. is > there a > > decent archive of the mailing list? the MARC one pointed to from > kernel.org > > doesnt seem to update or have attachments. > > Cut-n-paste often converts tabs to spaces, so that could be > the problem. (BTW, I double-checked after your first email > and verified that they applied cleanly.) ah, super, downloading and snipping the raw messages did the trick nicely. they apply cleanly to 2.6.15-rc3 with 2.6.15-rc3-libata1.patch.bz2 as well. thanks! dom ps - i can't see any messages after the 25th on MARC, as an aside. > > MARC has the patches -- and none of them were sent as > attachments. > > 1 of 5: http://marc.theaimsgroup.com/?l=linux-ide&m=113279087717303&w=2 > then click on "Download message RAW" > > 2 of 5: http://marc.theaimsgroup.com/?l=linux-ide&m=113279088931675&w=2 > and Download message RAW > > 3 of 5: http://marc.theaimsgroup.com/?l=linux-ide&m=113279087922204&w=2 > and Download message RAW > > 4/5: http://marc.theaimsgroup.com/?l=linux-ide&m=113279088127703&w=2 > and Download message RAW > > 5/5: http://marc.theaimsgroup.com/?l=linux-ide&m=113279088916977&w=2 > and Download message RAW > > > > > However, these current patches won't get you much additional help > > > for SATA suspend/resume since they lack writing the taskfile data > > > to the controller ports. > > > > really look forward to it! > > > > thanks for your work > > dom > > I'll also put them on a web site for download after I have these > changes made. > > -- > ~Randy > - > 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 ------------------------------------------ This message was penned by the hand of Dom - 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 From luke-jr@utopios.org Tue Nov 29 18:53:52 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 18:50:11 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750818AbVK3CtN (ORCPT ); Tue, 29 Nov 2005 21:49:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750821AbVK3CtM (ORCPT ); Tue, 29 Nov 2005 21:49:12 -0500 Received: from CPE-24-31-244-49.kc.res.rr.com ([24.31.244.49]:52890 "EHLO tsurukikun.utopios.org") by vger.kernel.org with ESMTP id S1750818AbVK3CtM (ORCPT ); Tue, 29 Nov 2005 21:49:12 -0500 Received: from ip6-localhost (ip6-localhost [IPv6:::1]) by tsurukikun.utopios.org (Postfix) with ESMTP id 6E75ECF4157 for ; Wed, 30 Nov 2005 02:53:53 +0000 (UTC) From: Luke-Jr To: Linux Kernel Mailing List Subject: Re: ide-cd doesn't replace ide-scsi? Date: Wed, 30 Nov 2005 02:53:52 +0000 User-Agent: KMail/1.9 References: <200511281218.17141.luke-jr@utopios.org> <438B70AA.7090805@tmr.com> <58cb370e0511290658m682ae978hea2100f57252a928@mail.gmail.com> In-Reply-To: <58cb370e0511290658m682ae978hea2100f57252a928@mail.gmail.com> Public-GPG-Key: 0xD53E9583 Public-GPG-Key-URI: http://dashjr.org/~luke-jr/myself/Luke-Jr.pgp IM-Address: luke-jr@jabber.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511300253.53260.luke-jr@utopios.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 29 November 2005 14:58, you wrote: > Known problem with ide-scsi, reference counting for "virtual" SCSI host > is missing (it was always buggy but was exposed in 2.6.x something by > sr.c changes). In case it's helpful, here's the error: Unable to handle kernel NULL pointer dereference at 0000000000000410 RIP: {:ide_scsi:idescsi_queue+322} PGD 31418067 PUD 31eb6067 PMD 0 Oops: 0000 [1] PREEMPT CPU 0 Modules linked in: sr_mod cdrom ide_scsi ipv6 ohci_hcd analog 8250_pnp 8250 serial_core parport_pc parport floppy radeonfb snd_via82xx gameport snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd i2c_viapro ehci_hcd cdc_ether usbnet usbhid usblp uhci_hcd sata_via libata scsi_mod skge ohci1394 ieee1394 usbcore supermount sk98lin Pid: 13304, comm: rmmod Tainted: G M 2.6.14-gentoo-r2-ljr #3 RIP: 0010:[] {:ide_scsi:idescsi_queue+322} RSP: 0018:ffff810031897908 EFLAGS: 00010016 RAX: 0000000000000000 RBX: ffff81003721f2c0 RCX: 0000000000000000 RDX: 00000000ffffda7e RSI: ffff81003c9038fa RDI: ffff81003721f2ca RBP: ffff81003c903880 R08: 00000000000004e1 R09: ffff81003c903988 R10: ffff81003e1d2c80 R11: ffffffff80280700 R12: ffff810031fab800 R13: ffffffff80408910 R14: ffff81003c903880 R15: ffff81003721f2c0 FS: 00002aaaaadfeb00(0000) GS:ffffffff80420800(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000410 CR3: 0000000032def000 CR4: 00000000000006e0 Process rmmod (pid: 13304, threadinfo ffff810031896000, task ffff810032c78180) Stack: ffff81003c9038f0 0000000000000282 000000003f8ccb88 00000000000003e0 ffffffff8807d740 ffff81003bfecee0 ffff81003c903880 ffff81003b315800 0000000000000000 ffff81003ddd97f8 Call Trace:{:scsi_mod:scsi_done+0} {:scsi_mod:scsi_dispatch_cmd+505} {:scsi_mod:scsi_request_fn+768} {generic_unplug_device+25} {blk_execute_rq+193} {blk_rq_bio_prep+51} {:scsi_mod:scsi_execute+229} {:sr_mod:sr_do_ioctl+175} {:sr_mod:sr_packet+30} {:cdrom:cdrom_get_disc_info+86} {:cdrom:cdrom_mrw_exit+39} {dput+35} {simple_unlink+94} {:cdrom:unregister_cdrom+213} {:sr_mod:sr_kref_release+93} {:sr_mod:sr_kref_release+0} {kref_put+96} {:sr_mod:sr_remove+70} {__device_release_driver+107} {device_release_driver+49} {bus_remove_device+172} {device_del+56} {:scsi_mod:__scsi_remove_device+58} {:scsi_mod:scsi_forget_host+120} {:scsi_mod:scsi_remove_host+212} {:ide_scsi:ide_scsi_remove+106} {__device_release_driver+107} {driver_detach+195} {bus_remove_driver+148} {driver_unregister+13} {sys_delete_module+500} {sys_munmap+85} {system_call+126} Code: 8b 80 10 04 00 00 a8 01 74 0a 41 0f ba 6f 50 02 4c 8b 73 40 RIP {:ide_scsi:idescsi_queue+322} RSP CR2: 0000000000000410 <6>note: rmmod[13304] exited with preempt_count 1 Unable to handle kernel NULL pointer dereference at 0000000000000410 RIP: {:ide_scsi:idescsi_queue+322} PGD 32e09067 PUD 31d03067 PMD 0 Oops: 0000 [2] PREEMPT CPU 0 Modules linked in: sr_mod cdrom ide_scsi ipv6 ohci_hcd analog 8250_pnp 8250 serial_core parport_pc parport floppy radeonfb snd_via82xx gameport snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd i2c_viapro ehci_hcd cdc_ether usbnet usbhid usblp uhci_hcd sata_via libata scsi_mod skge ohci1394 ieee1394 usbcore supermount sk98lin Pid: 13174, comm: scsi_eh_3 Tainted: G M 2.6.14-gentoo-r2-ljr #3 RIP: 0010:[] {:ide_scsi:idescsi_queue+322} RSP: 0018:ffff8100319d9da8 EFLAGS: 00010006 RAX: 0000000000000000 RBX: ffff810036caabc0 RCX: 0000000000000000 RDX: 00000000ffffdf60 RSI: ffff81003c9038f6 RDI: ffff810036caabc6 RBP: ffff81003c903880 R08: 00000000000009c3 R09: ffff81003c903988 R10: 00000000ffffffff R11: 0000000000000101 R12: ffff81003589fe00 R13: ffffffff80408910 R14: ffff81003c903880 R15: ffff810036caabc0 FS: 00002aaaaadfeb00(0000) GS:ffffffff80420800(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000000000410 CR3: 00000000318f4000 CR4: 00000000000006e0 Process scsi_eh_3 (pid: 13174, threadinfo ffff8100319d8000, task ffff810031900240) Stack: ffff81003c9038f0 0000000000000282 0000000000000296 00000000000003e0 ffffffff880805a0 ffff81003c903880 ffff81003b315800 ffff8100319d9e18 0000000000000001 ffff81003c903988 Call Trace:{:scsi_mod:scsi_eh_done+0} {:scsi_mod:scsi_send_eh_cmnd+158} {ide_wait_not_busy+45} {:scsi_mod:scsi_eh_tur+175} {:scsi_mod:scsi_error_handler+851} {:scsi_mod:scsi_error_handler+0} {keventd_create_kthread+0} {kthread+205} {child_rip+8} {keventd_create_kthread+0} {kthread+0} {child_rip+0} Code: 8b 80 10 04 00 00 a8 01 74 0a 41 0f ba 6f 50 02 4c 8b 73 40 RIP {:ide_scsi:idescsi_queue+322} RSP CR2: 0000000000000410 <6>note: scsi_eh_3[13174] exited with preempt_count 1 -- Luke-Jr Developer, Utopios http://utopios.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From luke-jr@utopios.org Tue Nov 29 18:54:26 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 18:50:11 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750821AbVK3Ctr (ORCPT ); Tue, 29 Nov 2005 21:49:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750823AbVK3Ctr (ORCPT ); Tue, 29 Nov 2005 21:49:47 -0500 Received: from CPE-24-31-244-49.kc.res.rr.com ([24.31.244.49]:55450 "EHLO tsurukikun.utopios.org") by vger.kernel.org with ESMTP id S1750821AbVK3Ctq (ORCPT ); Tue, 29 Nov 2005 21:49:46 -0500 Received: from ip6-localhost (ip6-localhost [IPv6:::1]) by tsurukikun.utopios.org (Postfix) with ESMTP id C891ACF4157 for ; Wed, 30 Nov 2005 02:54:27 +0000 (UTC) From: Luke-Jr To: Linux Kernel Mailing List Subject: Re: ide-cd doesn't replace ide-scsi? Date: Wed, 30 Nov 2005 02:54:26 +0000 User-Agent: KMail/1.9 References: <200511281218.17141.luke-jr@utopios.org> <58cb370e0511290658m682ae978hea2100f57252a928@mail.gmail.com> <20051129152300.GX15804@suse.de> In-Reply-To: <20051129152300.GX15804@suse.de> Public-GPG-Key: 0xD53E9583 Public-GPG-Key-URI: http://dashjr.org/~luke-jr/myself/Luke-Jr.pgp IM-Address: luke-jr@jabber.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511300254.27329.luke-jr@utopios.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 29 November 2005 15:23, Jens Axboe wrote: > On Tue, Nov 29 2005, Bartlomiej Zolnierkiewicz wrote: > > > Unfortunately using ide-cd still doesn't have the code set to allow all > > > burning features to work if you are not root. Even if you have > > > read+write there's one command you need to do multi-session which is > > > only allowed to root. Works fine for single sessions, I guess that's > > > all someone uses. > > > > Interesting because both drivers ide-cd and sr+ide-scsi use exactly > > the same code (block/scsi_ioctl.c) to verify which commands don't > > need root privileges. Care to give details? > > Not if he is using /dev/sgX with ide-scsi, only SG_IO through /dev/srX > will go through the block/scsi_ioctl.c path. Is is possible to get a "IDE generic" device for ide-cdrom? ;) -- Luke-Jr Developer, Utopios http://utopios.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From htejun@gmail.com Tue Nov 29 20:16:18 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 20:17:06 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750900AbVK3EQ3 (ORCPT ); Tue, 29 Nov 2005 23:16:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750898AbVK3EQ2 (ORCPT ); Tue, 29 Nov 2005 23:16:28 -0500 Received: from zproxy.gmail.com ([64.233.162.206]:8118 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S1750895AbVK3EQ1 (ORCPT ); Tue, 29 Nov 2005 23:16:27 -0500 Received: by zproxy.gmail.com with SMTP id 13so327635nzn for ; Tue, 29 Nov 2005 20:16:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=qtg+sN80Mr5jUTaqvETYnP46P9Y/ata7KUbShVEtcDJz9DBPETXX6Nzv5yw1TDmj32qJMiZgB1M+x0af6hB5sAoxOsH0y/gf3gG+xQAHnWHBzYub9AtpfQjbh/lGrE8Vn516z5Hz1UoboFZeCnaljy+60DxWDgw9YhiXgm5MMTY= Received: by 10.37.2.53 with SMTP id e53mr5336721nzi; Tue, 29 Nov 2005 20:16:26 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id 15sm2143197nzn.2005.11.29.20.16.23; Tue, 29 Nov 2005 20:16:26 -0800 (PST) Received: from [127.0.0.1] (htj.dyndns.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by htj.dyndns.org (Postfix) with ESMTP id ACEC41860F8; Wed, 30 Nov 2005 13:16:18 +0900 (KST) Message-ID: <438D2792.9050105@gmail.com> Date: Wed, 30 Nov 2005 13:16:18 +0900 From: Tejun Heo User-Agent: Debian Thunderbird 1.0.7 (X11/20051019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ethan Chen CC: linux-kernel@vger.kernel.org, Jeff Garzik , Carlos Pardo , Linux-ide Subject: Re: SIL_QUIRK_MOD15WRITE workaround problem on 2.6.14 References: <438BD351.60902@ucla.edu> In-Reply-To: <438BD351.60902@ucla.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org [CC'ing Jeff, Carlos & linux-ide] Ethan Chen wrote: > I've got a dual Opteron 242 machine here with 2x Seagate ST3200822AS > SATA drives attached to a Silicon Image SI3114 controller, and after > upgrading to 2.6.14 from 2.6.13, it seems the SIL_QUIRK_MOD15WRITE > workaround for the sata_sil driver isn't being applied anymore. This > caused me trouble in the past before my drive was added to the > blacklist, and this message that comes up when writing (~4GBfiles to > test) files, right before the computer locks up, is the same as before: > kernel: ata1: command 0x35 timeout, stat 0xd8 host_stat 0x61 > In the dmesg, the 'Applying Seagate errata fix' message doesn't appear > anymore as well. > Finally, without the fix, write speeds are much higher as well, before > it locks up. Hello, Ethan. Sometime ago, Silicon Image has confirmed that 3114's and 3512's are not affected by the m15w problem - only 3112's are affected. So, a patch has made into the tree before 2.6.14 to apply the m15w quirk selectively. Can you post 'lspci -nv' result? -- tejun - 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 From htejun@gmail.com Tue Nov 29 20:35:37 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 20:35:47 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750925AbVK3Efp (ORCPT ); Tue, 29 Nov 2005 23:35:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750980AbVK3Efp (ORCPT ); Tue, 29 Nov 2005 23:35:45 -0500 Received: from zproxy.gmail.com ([64.233.162.192]:1708 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S1750925AbVK3Efo (ORCPT ); Tue, 29 Nov 2005 23:35:44 -0500 Received: by zproxy.gmail.com with SMTP id 13so330915nzn for ; Tue, 29 Nov 2005 20:35:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Rk/pRnOWCZzJ8o8O6nfpPw0kIkINGbXDS8hh3Hbc9UJOcWzkXO3BTDPtatCgAiYr3vBWUrh0fF27eE/Xw/1NI4YzcTlD4HPyFxGc+KiFFNOMGLgT2lZ+AmL2LFBNiAbrDnbr8XxHvomDfpGrq/ZFHk5xgz6sqhpK7U+IIFfO1SQ= Received: by 10.36.227.10 with SMTP id z10mr5343644nzg; Tue, 29 Nov 2005 20:35:43 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id 34sm2165754nza.2005.11.29.20.35.41; Tue, 29 Nov 2005 20:35:43 -0800 (PST) Received: from [127.0.0.1] (htj.dyndns.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by htj.dyndns.org (Postfix) with ESMTP id C9F661860EA; Wed, 30 Nov 2005 13:35:37 +0900 (KST) Message-ID: <438D2C19.3030008@gmail.com> Date: Wed, 30 Nov 2005 13:35:37 +0900 From: Tejun Heo User-Agent: Debian Thunderbird 1.0.7 (X11/20051019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "0602@eq.cz" <0602@eq.cz> CC: linux-kernel@vger.kernel.org, Linux-ide Subject: Re: totally random "VFS: Cannot open root device" References: <438B6E05.8070009@eq.cz> In-Reply-To: <438B6E05.8070009@eq.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org 0602@eq.cz wrote: > Hi! > > (Please CC me your answers as I am not subscribed.) > > I have a problem with 2.6.14.3 kernel (but this probably isn't too > version-specific). I have a kernel which succesfully boots on totally > random basis (cca 70% is success). My root partition resides on a SATA > disc connected to a controller on Intel 6300ESB ICH southbridge (mb > Intel se7320vp2). There is a reiserfs 3 filesystem on my root partition. > Without any changes to configuration (os or bios or whatever) I > sometimes get: > > VFS: Cannot open root device "801" or unknown block(8,1) > > Could this be some timeout issue, or indication of crappy hw? I've tried > this about 10 times (immediately ctrl+alt+del on successfull boot or > reset button on aforementioned panic) and I saw no regularities in this > misbehaviour. > > I sincerely appreciate any advice anyone can give. > [CC'ing linux-ide] Hello, 0602. :-) Can you please post dmesg of a successful booting? That will tell us which SATA controller/disks you are using. Also, the boot log of a failed boot will be very helpful - the best way to get this is via serial console. If you don't have access to serial console, taking note / picture of the part where SATA detection fails will do too. Also, when the machine boots successfully, does it work without generating disk related kernel logs? Just perform any IO-heavy operations - cp'ing directories which contain large files, tar/untarring... - and see if the kernel complains about anyting. -- tejun - 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 From jgarzik@pobox.com Tue Nov 29 20:42:52 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 20:44:07 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750993AbVK3EnI (ORCPT ); Tue, 29 Nov 2005 23:43:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750990AbVK3EnI (ORCPT ); Tue, 29 Nov 2005 23:43:08 -0500 Received: from mail.dvmed.net ([216.237.124.58]:5298 "EHLO mail.dvmed.net") by vger.kernel.org with ESMTP id S1750986AbVK3EnH (ORCPT ); Tue, 29 Nov 2005 23:43:07 -0500 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1EhJo3-0000Ri-KL; Wed, 30 Nov 2005 04:43:01 +0000 Message-ID: <438D2DCC.4010805@pobox.com> Date: Tue, 29 Nov 2005 23:42:52 -0500 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tejun Heo CC: Ethan Chen , linux-kernel@vger.kernel.org, Carlos Pardo , Linux-ide Subject: Re: SIL_QUIRK_MOD15WRITE workaround problem on 2.6.14 References: <438BD351.60902@ucla.edu> <438D2792.9050105@gmail.com> In-Reply-To: <438D2792.9050105@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Spam-Report: Spam detection software, running on the system "srv2.dvmed.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Tejun Heo wrote: > [CC'ing Jeff, Carlos & linux-ide] > > Ethan Chen wrote: > >> I've got a dual Opteron 242 machine here with 2x Seagate ST3200822AS >> SATA drives attached to a Silicon Image SI3114 controller, and after >> upgrading to 2.6.14 from 2.6.13, it seems the SIL_QUIRK_MOD15WRITE >> workaround for the sata_sil driver isn't being applied anymore. This >> caused me trouble in the past before my drive was added to the >> blacklist, and this message that comes up when writing (~4GBfiles to >> test) files, right before the computer locks up, is the same as before: >> kernel: ata1: command 0x35 timeout, stat 0xd8 host_stat 0x61 >> In the dmesg, the 'Applying Seagate errata fix' message doesn't appear >> anymore as well. >> Finally, without the fix, write speeds are much higher as well, before >> it locks up. > > > Hello, Ethan. > > Sometime ago, Silicon Image has confirmed that 3114's and 3512's are not > affected by the m15w problem - only 3112's are affected. So, a patch > has made into the tree before 2.6.14 to apply the m15w quirk selectively. [...] Content analysis details: (0.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.1 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [69.134.188.146 listed in dnsbl.sorbs.net] Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Tejun Heo wrote: > [CC'ing Jeff, Carlos & linux-ide] > > Ethan Chen wrote: > >> I've got a dual Opteron 242 machine here with 2x Seagate ST3200822AS >> SATA drives attached to a Silicon Image SI3114 controller, and after >> upgrading to 2.6.14 from 2.6.13, it seems the SIL_QUIRK_MOD15WRITE >> workaround for the sata_sil driver isn't being applied anymore. This >> caused me trouble in the past before my drive was added to the >> blacklist, and this message that comes up when writing (~4GBfiles to >> test) files, right before the computer locks up, is the same as before: >> kernel: ata1: command 0x35 timeout, stat 0xd8 host_stat 0x61 >> In the dmesg, the 'Applying Seagate errata fix' message doesn't appear >> anymore as well. >> Finally, without the fix, write speeds are much higher as well, before >> it locks up. > > > Hello, Ethan. > > Sometime ago, Silicon Image has confirmed that 3114's and 3512's are not > affected by the m15w problem - only 3112's are affected. So, a patch > has made into the tree before 2.6.14 to apply the m15w quirk selectively. Most likely, mod15write quirk was just hiding an unrelated problem. mod15write often hid BIOS problems in the past which led to corruption. Until sata_sil properly handles SATA phy / DMA errors by resetting the controller and retrying the command, we won't know if its a driver problem or not. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From thanatoz@ucla.edu Tue Nov 29 20:48:37 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 20:48:46 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750992AbVK3Eso (ORCPT ); Tue, 29 Nov 2005 23:48:44 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750998AbVK3Eso (ORCPT ); Tue, 29 Nov 2005 23:48:44 -0500 Received: from smtp-8.smtp.ucla.edu ([169.232.47.137]:52939 "EHLO smtp-8.smtp.ucla.edu") by vger.kernel.org with ESMTP id S1750992AbVK3Esn (ORCPT ); Tue, 29 Nov 2005 23:48:43 -0500 Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.141]) by smtp-8.smtp.ucla.edu (8.13.4/8.13.4) with ESMTP id jAU4mc13001951; Tue, 29 Nov 2005 20:48:38 -0800 Received: from [128.97.167.86] (s3167-86.resnet.ucla.edu [128.97.167.86] (may be forged)) (authenticated bits=0) by mail.ucla.edu (8.13.4/8.13.4) with ESMTP id jAU4mcZ6023000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Nov 2005 20:48:38 -0800 Message-ID: <438D2F25.2020707@ucla.edu> Date: Tue, 29 Nov 2005 20:48:37 -0800 From: Ethan Chen User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tejun Heo CC: linux-kernel@vger.kernel.org, thanatoz@ucla.edu, Carlos.Pardo@siliconimage.com, jgarzik@pobox.com, linux-ide@vger.kernel.org Subject: Re: SIL_QUIRK_MOD15WRITE workaround problem on 2.6.14 References: <438BD351.60902@ucla.edu> <438D2792.9050105@gmail.com> In-Reply-To: <438D2792.9050105@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Probable-Spam: no X-Spam-Report: none X-Scanned-By: smtp.ucla.edu on 169.232.47.137 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Tejun, The motherboard is an Iwill DK8X utilizing the AMD 8151+8131+8111 chips. lspci -nv 00:00.0 Class 0600: 1022:7454 (rev 13) Subsystem: 1022:7454 Flags: bus master, medium devsel, latency 0 Memory at f8000000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 3.0 Capabilities: [c0] HyperTransport: Slave or Primary Interface 00:01.0 Class 0604: 1022:7455 (rev 13) Flags: bus master, 66Mhz, medium devsel, latency 32 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 Memory behind bridge: fc700000-fe7fffff Prefetchable memory behind bridge: e4600000-f45fffff 00:06.0 Class 0604: 1022:7460 (rev 07) Flags: bus master, 66Mhz, medium devsel, latency 32 Bus: primary=00, secondary=02, subordinate=02, sec-latency=32 I/O behind bridge: 0000a000-0000afff Memory behind bridge: fe800000-fe8fffff Capabilities: [c0] HyperTransport: Slave or Primary Interface Capabilities: [f0] HyperTransport: Interrupt Discovery and Configuration 00:07.0 Class 0601: 1022:7468 (rev 05) Subsystem: 1022:7468 Flags: bus master, 66Mhz, medium devsel, latency 0 00:07.1 Class 0101: 1022:7469 (rev 03) (prog-if 8a [Master SecP PriP]) Subsystem: 1022:7469 Flags: bus master, medium devsel, latency 32 I/O ports at ffa0 [size=16] 00:07.2 Class 0c05: 1022:746a (rev 02) Subsystem: 1022:746a Flags: medium devsel, IRQ 9 I/O ports at cc00 [size=32] 00:07.3 Class 0680: 1022:746b (rev 05) Subsystem: 1022:746b Flags: medium devsel 00:0a.0 Class 0604: 1022:7450 (rev 12) Flags: bus master, 66Mhz, medium devsel, latency 32 Bus: primary=00, secondary=03, subordinate=03, sec-latency=32 I/O behind bridge: 0000b000-0000bfff Memory behind bridge: fe900000-feafffff Capabilities: [a0] PCI-X bridge device. Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration Capabilities: [c0] HyperTransport: Slave or Primary Interface 00:0a.1 Class 0800: 1022:7451 (rev 01) (prog-if 10) Subsystem: 1022:7451 Flags: bus master, medium devsel, latency 0 Memory at febff000 (64-bit, non-prefetchable) [size=4K] 00:0b.0 Class 0604: 1022:7450 (rev 12) Flags: bus master, 66Mhz, medium devsel, latency 32 Bus: primary=00, secondary=04, subordinate=04, sec-latency=32 Capabilities: [a0] PCI-X bridge device. Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration 00:0b.1 Class 0800: 1022:7451 (rev 01) (prog-if 10) Subsystem: 1022:7451 Flags: bus master, medium devsel, latency 0 Memory at febfe000 (64-bit, non-prefetchable) [size=4K] 00:18.0 Class 0600: 1022:1100 Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface Capabilities: [a0] HyperTransport: Host or Secondary Interface Capabilities: [c0] HyperTransport: Host or Secondary Interface 00:18.1 Class 0600: 1022:1101 Flags: fast devsel 00:18.2 Class 0600: 1022:1102 Flags: fast devsel 00:18.3 Class 0600: 1022:1103 Flags: fast devsel 00:19.0 Class 0600: 1022:1100 Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface Capabilities: [a0] HyperTransport: Host or Secondary Interface Capabilities: [c0] HyperTransport: Host or Secondary Interface 00:19.1 Class 0600: 1022:1101 Flags: fast devsel 00:19.2 Class 0600: 1022:1102 Flags: fast devsel 00:19.3 Class 0600: 1022:1103 Flags: fast devsel 01:00.0 Class 0300: 10de:0281 (rev a1) Flags: bus master, 66Mhz, medium devsel, latency 248, IRQ 18 Memory at fd000000 (32-bit, non-prefetchable) [size=16M] Memory at e8000000 (32-bit, prefetchable) [size=128M] Expansion ROM at fe7e0000 [disabled] [size=128K] Capabilities: [60] Power Management version 2 Capabilities: [44] AGP version 3.0 02:00.0 Class 0c03: 1022:7464 (rev 0b) (prog-if 10) Subsystem: 1022:7464 Flags: bus master, medium devsel, latency 32, IRQ 17 Memory at fe8fe000 (32-bit, non-prefetchable) [size=4K] 02:00.1 Class 0c03: 1022:7464 (rev 0b) (prog-if 10) Subsystem: 1022:7464 Flags: bus master, medium devsel, latency 32, IRQ 17 Memory at fe8ff000 (32-bit, non-prefetchable) [size=4K] 02:04.0 Class 0401: 1102:0002 (rev 07) Subsystem: 1102:8064 Flags: bus master, medium devsel, latency 32, IRQ 18 I/O ports at a880 [size=32] Capabilities: [dc] Power Management version 1 02:04.1 Class 0980: 1102:7002 (rev 07) Subsystem: 1102:0020 Flags: bus master, medium devsel, latency 32 I/O ports at ac00 [size=8] Capabilities: [dc] Power Management version 1 02:06.0 Class 0c00: 104c:8023 (prog-if 10) Subsystem: 104c:8023 Flags: bus master, medium devsel, latency 32, IRQ 19 Memory at fe8fd800 (32-bit, non-prefetchable) [size=2K] Memory at fe8f8000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 02:07.0 Class 0c03: 1033:0035 (rev 43) (prog-if 10) Subsystem: 1033:0035 Flags: bus master, medium devsel, latency 32, IRQ 17 Memory at fe8f7000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 02:07.1 Class 0c03: 1033:0035 (rev 43) (prog-if 10) Subsystem: 1033:0035 Flags: bus master, medium devsel, latency 32, IRQ 18 Memory at fe8fc000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 02:07.2 Class 0c03: 1033:00e0 (rev 04) (prog-if 20) Subsystem: 1033:00e0 Flags: bus master, medium devsel, latency 32, IRQ 16 Memory at fe8fd400 (32-bit, non-prefetchable) [size=256] Capabilities: [40] Power Management version 2 03:03.0 Class 0200: 11ab:4320 (rev 13) Subsystem: 15d4:0047 Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 17 Memory at feaf8000 (32-bit, non-prefetchable) [size=16K] I/O ports at b000 [size=256] Expansion ROM at feac0000 [disabled] [size=128K] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data 03:05.0 Class 0180: 1095:3114 (rev 02) Subsystem: 1095:3114 Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 16 I/O ports at bc00 [size=8] I/O ports at b880 [size=4] I/O ports at b800 [size=8] I/O ports at b480 [size=4] I/O ports at b400 [size=16] Memory at feaffc00 (32-bit, non-prefetchable) [size=1K] Expansion ROM at fea00000 [disabled] [size=512K] Capabilities: [60] Power Management version 2 Thanks, -Ethan Tejun Heo wrote: > [CC'ing Jeff, Carlos & linux-ide] > > Ethan Chen wrote: > >> I've got a dual Opteron 242 machine here with 2x Seagate ST3200822AS >> SATA drives attached to a Silicon Image SI3114 controller, and after >> upgrading to 2.6.14 from 2.6.13, it seems the SIL_QUIRK_MOD15WRITE >> workaround for the sata_sil driver isn't being applied anymore. This >> caused me trouble in the past before my drive was added to the >> blacklist, and this message that comes up when writing (~4GBfiles to >> test) files, right before the computer locks up, is the same as before: >> kernel: ata1: command 0x35 timeout, stat 0xd8 host_stat 0x61 >> In the dmesg, the 'Applying Seagate errata fix' message doesn't >> appear anymore as well. >> Finally, without the fix, write speeds are much higher as well, >> before it locks up. > > > Hello, Ethan. > > Sometime ago, Silicon Image has confirmed that 3114's and 3512's are > not affected by the m15w problem - only 3112's are affected. So, a > patch has made into the tree before 2.6.14 to apply the m15w quirk > selectively. > > Can you post 'lspci -nv' result? > - 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 From htejun@gmail.com Tue Nov 29 21:37:44 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 21:38:03 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751063AbVK3Fhz (ORCPT ); Wed, 30 Nov 2005 00:37:55 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751066AbVK3Fhz (ORCPT ); Wed, 30 Nov 2005 00:37:55 -0500 Received: from zproxy.gmail.com ([64.233.162.194]:38417 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S1751061AbVK3Fhy (ORCPT ); Wed, 30 Nov 2005 00:37:54 -0500 Received: by zproxy.gmail.com with SMTP id 14so1836182nzn for ; Tue, 29 Nov 2005 21:37:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=sHj14We9Ql6vNOGRNk62xCdAJy92dtgD56oVbCLSGOA/NXMapRXVNxAHZvILdIAqRPel1JdHy39HiZ+US8emmzcgSgYtmyR6hNaeYoh9H5DP+rc2ISz+drQ/fcihUQIsHTiYw/AnRWJ8RM2V5sr5cdbfKTNqvu5We9VmFP0mFPI= Received: by 10.37.21.18 with SMTP id y18mr5154874nzi; Tue, 29 Nov 2005 21:37:51 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id r1sm1189071nzd.2005.11.29.21.37.49; Tue, 29 Nov 2005 21:37:51 -0800 (PST) Received: from [127.0.0.1] (htj.dyndns.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by htj.dyndns.org (Postfix) with ESMTP id 0B36E1860EA; Wed, 30 Nov 2005 14:37:45 +0900 (KST) Message-ID: <438D3AA8.9030504@gmail.com> Date: Wed, 30 Nov 2005 14:37:44 +0900 From: Tejun Heo User-Agent: Debian Thunderbird 1.0.7 (X11/20051019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Ethan Chen , linux-kernel@vger.kernel.org, Carlos Pardo , Linux-ide Subject: Re: SIL_QUIRK_MOD15WRITE workaround problem on 2.6.14 References: <438BD351.60902@ucla.edu> <438D2792.9050105@gmail.com> <438D2DCC.4010805@pobox.com> In-Reply-To: <438D2DCC.4010805@pobox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Jeff Garzik wrote: > Tejun Heo wrote: > >> [CC'ing Jeff, Carlos & linux-ide] >> >> Ethan Chen wrote: >> >>> I've got a dual Opteron 242 machine here with 2x Seagate ST3200822AS >>> SATA drives attached to a Silicon Image SI3114 controller, and after >>> upgrading to 2.6.14 from 2.6.13, it seems the SIL_QUIRK_MOD15WRITE >>> workaround for the sata_sil driver isn't being applied anymore. This >>> caused me trouble in the past before my drive was added to the >>> blacklist, and this message that comes up when writing (~4GBfiles to >>> test) files, right before the computer locks up, is the same as before: >>> kernel: ata1: command 0x35 timeout, stat 0xd8 host_stat 0x61 >>> In the dmesg, the 'Applying Seagate errata fix' message doesn't >>> appear anymore as well. >>> Finally, without the fix, write speeds are much higher as well, >>> before it locks up. >> >> >> >> Hello, Ethan. >> >> Sometime ago, Silicon Image has confirmed that 3114's and 3512's are >> not affected by the m15w problem - only 3112's are affected. So, a >> patch has made into the tree before 2.6.14 to apply the m15w quirk >> selectively. > > > Most likely, mod15write quirk was just hiding an unrelated problem. > mod15write often hid BIOS problems in the past which led to corruption. > > Until sata_sil properly handles SATA phy / DMA errors by resetting the > controller and retrying the command, we won't know if its a driver > problem or not. > Ethan confirmed that it's 1095:3114. Arghhh.... Maybe we should keep m15w quirk for 3114's for the time being? Better be slow than hang. Whatever bug the m15w quirk was hiding. Carlos, can you double check that 3114's don't have the m15w issue? It just seems too similar to the usual m15w lockup. -- tejun - 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 From benh@kernel.crashing.org Tue Nov 29 21:44:37 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 21:51:30 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751065AbVK3FvX (ORCPT ); Wed, 30 Nov 2005 00:51:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751066AbVK3FvW (ORCPT ); Wed, 30 Nov 2005 00:51:22 -0500 Received: from gate.crashing.org ([63.228.1.57]:62898 "EHLO gate.crashing.org") by vger.kernel.org with ESMTP id S1751047AbVK3FvW (ORCPT ); Wed, 30 Nov 2005 00:51:22 -0500 Received: from gaston (localhost [127.0.0.1]) by gate.crashing.org (8.12.8/8.12.8) with ESMTP id jAU5lhWG031856; Tue, 29 Nov 2005 23:47:48 -0600 Subject: Crash when inserting media bay CD with 2.6.15-rc3 From: Benjamin Herrenschmidt To: Bartlomiej Zolnierkiewicz Cc: list linux-ide , Andrew Morton Content-Type: text/plain Date: Wed, 30 Nov 2005 16:44:37 +1100 Message-Id: <1133329478.16726.65.camel@gaston> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org X-IMAPbase: 1133367604 710 Status: O X-Status: X-Keywords: X-UID: 2 Hi Bart ! When inserting my pmac hotswap bay CD-ROM drive, I get a crash that looks like : Probing IDE interface ide1.... hdc: MATSHITA CR-174, ATAPI CD/DVD-ROM drive. Then the crash: Vector: 300 (Data Access) at [c5e1fdc0] pc: c00b7370: create_dir+0x20/0x200 lr: c00b7598: sysfs_create_dir+0x48/0xa0 sp: c5e1fe70 msr: 9032 dar: 65670008 dsisr: 40000000 current = 0xc5f44070 pid = 730, comm = media-bay enter ? for help mon> t [c5e1fe90] c00b7598 sysfs_create_dir+0x48/0xa0 [c5e1feb0] c0124380 kobject_add+0x80/0x190 [c5e1fed0] c01cb9e0 device_add+0xa0/0x170 [c5e1fef0] c020540c probe_hwif+0x2ac/0x8a0 [c5e1ff30] c02065ac probe_hwif_init_with_fixup+0x1c/0xb0 [c5e1ff40] c01fe20c ide_register_hw_with_fixup+0x1fc/0x230 [c5e1ff70] c01f09f0 media_bay_step+0x5a0/0x5b0 [c5e1ffd0] c01f0ca4 media_bay_task+0xe4/0x140 [c5e1fff0] c000f4e8 kernel_thread+0x44/0x60 This "translates" to an Oops accessing a wrong pointer, 0x65670008 is the pointer value (totally bogus) and you can see the backtrace above. The interfaces are as follow: ide0: Found Apple Heathrow ATA controller, bus ID 0, irq 13 hda: IBM-DTCA-24090, ATA DISK drive hda: Enabling MultiWord DMA 2 ide0 at 0xc701a000-0xc701a007,0xc701a160 on irq 13 ide1: Found Apple Heathrow ATA controller, bus ID 1 (mediabay), irq 14 ide2: Found Apple Heathrow ATA controller, bus ID 4 (mediabay), irq 78 As you see, ide1 and ide2 are there and have been setup with the various fields for ide/ppc/pmac.c. They have not been probed at boot though as the media bay was empty. Any idea ? I'll try to track it down on my side too but I'm chasing a few different issues at the same time, so if you have a clue, you are welcome :) For your information, the media bay driver, when detecting an IDE device, first waits for the BUSY bit to clear (historical reasons: the IDE driver used not to do it before I fixed it and I never udpated the mediabay driver) and then does: ide_init_hwif_ports(&hw, (unsigned long) bay->cd_base, (unsigned long) 0, NULL); hw.irq = bay->cd_irq; hw.chipset = ide_pmac; bay->cd_index = ide_register_hw(&hw, NULL); cd_base and cd_irq have been set by the ide-pmac driver (it calls into the mediabay driver to "inform" it of the base & irq of the controller hooked to that bay). This code used to work, I can't tell for sure when this broke as I didn't test on that old machine with a mediabay for a long time. Any clue welcome. Cheers, Ben. - 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 From htejun@gmail.com Tue Nov 29 23:39:46 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Tue, 29 Nov 2005 23:39:59 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751104AbVK3Hjz (ORCPT ); Wed, 30 Nov 2005 02:39:55 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751111AbVK3Hjy (ORCPT ); Wed, 30 Nov 2005 02:39:54 -0500 Received: from zproxy.gmail.com ([64.233.162.200]:15804 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S1751104AbVK3Hjx (ORCPT ); Wed, 30 Nov 2005 02:39:53 -0500 Received: by zproxy.gmail.com with SMTP id 14so1855944nzn for ; Tue, 29 Nov 2005 23:39:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=TkJ9loNQNB4WV214zOGJVyh5k71BM2UUtSxnhMlCT3n3nvZXoxlGoub5MIQP0/qj3k657J8/NIfGn9M/MdFLZcV+70j1nikbSKII2CS+mO4kZOE2AMsvB0WfIZEzjwfiYE4/5qnfUPjHgH0TM3l6DGgVAjdC0yIqm75PHkQsoXk= Received: by 10.36.50.14 with SMTP id x14mr5241475nzx; Tue, 29 Nov 2005 23:39:53 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id r1sm1264304nzd.2005.11.29.23.39.51; Tue, 29 Nov 2005 23:39:52 -0800 (PST) Received: from [127.0.0.1] (htj.dyndns.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by htj.dyndns.org (Postfix) with ESMTP id 9E6791860EA; Wed, 30 Nov 2005 16:39:46 +0900 (KST) Message-ID: <438D5742.3000804@gmail.com> Date: Wed, 30 Nov 2005 16:39:46 +0900 From: Tejun Heo User-Agent: Debian Thunderbird 1.0.7 (X11/20051019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: russb@emc.com, Jeff Garzik , Linux-ide Subject: [QUESTION] in ata_scsi_pass_thru() Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 45 Hi, all. In the translation function ata_scsi_pass_thru(), when it determines that the command cannot be translated and should be finished early, it does NOT set sense data or result code. This seems buggy. Is this intentional? Thanks. -- tejun - 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 From bzolnier@gmail.com Wed Nov 30 00:12:34 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Wed, 30 Nov 2005 00:12:39 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751119AbVK3IMg (ORCPT ); Wed, 30 Nov 2005 03:12:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751120AbVK3IMg (ORCPT ); Wed, 30 Nov 2005 03:12:36 -0500 Received: from nproxy.gmail.com ([64.233.182.203]:6802 "EHLO nproxy.gmail.com") by vger.kernel.org with ESMTP id S1751119AbVK3IMg convert rfc822-to-8bit (ORCPT ); Wed, 30 Nov 2005 03:12:36 -0500 Received: by nproxy.gmail.com with SMTP id q29so642150nfc for ; Wed, 30 Nov 2005 00:12:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Wly8RNhbKF8XCdj9MhSUhJ+fBn7sI0ydkS7AixZ/w7e+IocyupJ/Es5hJCa/FCFYMyQFrOr54vZ2PivlJxJrn+1JIGQRi8SR3XrEjQd49nxMN7y54A0iiQ1QEPOHiigIFOGv46V4AEXxQW+sP+JAa5apyX0XrF+JeSoiHKvWhe8= Received: by 10.48.220.6 with SMTP id s6mr666082nfg; Wed, 30 Nov 2005 00:12:34 -0800 (PST) Received: by 10.48.49.7 with HTTP; Wed, 30 Nov 2005 00:12:34 -0800 (PST) Message-ID: <58cb370e0511300012p2f703ec0wd5ea054d5b7403d6@mail.gmail.com> Date: Wed, 30 Nov 2005 09:12:34 +0100 From: Bartlomiej Zolnierkiewicz To: Benjamin Herrenschmidt Subject: Re: Crash when inserting media bay CD with 2.6.15-rc3 Cc: list linux-ide , Andrew Morton In-Reply-To: <1133329478.16726.65.camel@gaston> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Disposition: inline References: <1133329478.16726.65.camel@gaston> Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 66 On 11/30/05, Benjamin Herrenschmidt wrote: > Hi Bart ! Hi, > When inserting my pmac hotswap bay CD-ROM drive, I get a crash that > looks like : > > Probing IDE interface ide1.... > hdc: MATSHITA CR-174, ATAPI CD/DVD-ROM drive. > > Then the crash: > > Vector: 300 (Data Access) at [c5e1fdc0] > pc: c00b7370: create_dir+0x20/0x200 > lr: c00b7598: sysfs_create_dir+0x48/0xa0 > sp: c5e1fe70 > msr: 9032 > dar: 65670008 > dsisr: 40000000 > current = 0xc5f44070 > pid = 730, comm = media-bay > enter ? for help > mon> t > [c5e1fe90] c00b7598 sysfs_create_dir+0x48/0xa0 > [c5e1feb0] c0124380 kobject_add+0x80/0x190 > [c5e1fed0] c01cb9e0 device_add+0xa0/0x170 > [c5e1fef0] c020540c probe_hwif+0x2ac/0x8a0 > [c5e1ff30] c02065ac probe_hwif_init_with_fixup+0x1c/0xb0 > [c5e1ff40] c01fe20c ide_register_hw_with_fixup+0x1fc/0x230 > [c5e1ff70] c01f09f0 media_bay_step+0x5a0/0x5b0 > [c5e1ffd0] c01f0ca4 media_bay_task+0xe4/0x140 > [c5e1fff0] c000f4e8 kernel_thread+0x44/0x60 > > This "translates" to an Oops accessing a wrong pointer, 0x65670008 is > the pointer value (totally bogus) and you can see the backtrace above. > > The interfaces are as follow: > > ide0: Found Apple Heathrow ATA controller, bus ID 0, irq 13 > hda: IBM-DTCA-24090, ATA DISK drive > hda: Enabling MultiWord DMA 2 > ide0 at 0xc701a000-0xc701a007,0xc701a160 on irq 13 > ide1: Found Apple Heathrow ATA controller, bus ID 1 (mediabay), irq 14 > ide2: Found Apple Heathrow ATA controller, bus ID 4 (mediabay), irq 78 > > As you see, ide1 and ide2 are there and have been setup with the various > fields for ide/ppc/pmac.c. They have not been probed at boot though as > the media bay was empty. > > Any idea ? I'll try to track it down on my side too but I'm chasing a > few different issues at the same time, so if you have a clue, you are > welcome :) > > For your information, the media bay driver, when detecting an IDE > device, first waits for the BUSY bit to clear (historical reasons: the > IDE driver used not to do it before I fixed it and I never udpated the > mediabay driver) and then does: > > ide_init_hwif_ports(&hw, (unsigned long) bay->cd_base, (unsigned long) 0, NULL); > hw.irq = bay->cd_irq; > hw.chipset = ide_pmac; > bay->cd_index = ide_register_hw(&hw, NULL); mediabay driver allocates hw_regs_t hw from the stack but doesn't clear it before usage (hw->dev was added recently)? Cheers, Bartlomiej - 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 From luke-jr@utopios.org Wed Nov 30 01:03:13 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Wed, 30 Nov 2005 00:59:21 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751149AbVK3I6f (ORCPT ); Wed, 30 Nov 2005 03:58:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751150AbVK3I6f (ORCPT ); Wed, 30 Nov 2005 03:58:35 -0500 Received: from CPE-24-31-244-49.kc.res.rr.com ([24.31.244.49]:60630 "EHLO tsurukikun.utopios.org") by vger.kernel.org with ESMTP id S1751149AbVK3I6f (ORCPT ); Wed, 30 Nov 2005 03:58:35 -0500 Received: from ip6-localhost (ip6-localhost [IPv6:::1]) by tsurukikun.utopios.org (Postfix) with ESMTP id B7158CF4157 for ; Wed, 30 Nov 2005 09:03:16 +0000 (UTC) From: Luke-Jr To: Linux Kernel Mailing List Subject: Re: ide-cd doesn't replace ide-scsi? Date: Wed, 30 Nov 2005 09:03:13 +0000 User-Agent: KMail/1.9 References: <200511281218.17141.luke-jr@utopios.org> <58cb370e0511290658m682ae978hea2100f57252a928@mail.gmail.com> <20051129152300.GX15804@suse.de> In-Reply-To: <20051129152300.GX15804@suse.de> Public-GPG-Key: 0xD53E9583 Public-GPG-Key-URI: http://dashjr.org/~luke-jr/myself/Luke-Jr.pgp IM-Address: luke-jr@jabber.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511300903.15184.luke-jr@utopios.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 84 On Tuesday 29 November 2005 15:23, Jens Axboe wrote: > On Tue, Nov 29 2005, Bartlomiej Zolnierkiewicz wrote: > > > Unfortunately using ide-cd still doesn't have the code set to allow all > > > burning features to work if you are not root. Even if you have > > > read+write there's one command you need to do multi-session which is > > > only allowed to root. Works fine for single sessions, I guess that's > > > all someone uses. > > > > Interesting because both drivers ide-cd and sr+ide-scsi use exactly > > the same code (block/scsi_ioctl.c) to verify which commands don't > > need root privileges. Care to give details? > > Not if he is using /dev/sgX with ide-scsi, only SG_IO through /dev/srX > will go through the block/scsi_ioctl.c path. Actually, growisofs refuses to work with anything but a block device-- so it's using /dev/sr1. So apparently something else is up, since ide-cd errors, yet ide-scsi does not. Apparently, ide-scsi isn't working either though, just a different problem: the burning *appears* to work (I get status info, and the drive seems to do something), but the disc ends up unburned and empty. Has anyone successfully burned a dual layer disc? I'm using a BenQ DW1620 drive. -- Luke-Jr Developer, Utopios http://utopios.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From jfs@keytradebank.com Wed Nov 30 01:05:55 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Wed, 30 Nov 2005 01:07:03 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751157AbVK3JGU (ORCPT ); Wed, 30 Nov 2005 04:06:20 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751156AbVK3JGQ (ORCPT ); Wed, 30 Nov 2005 04:06:16 -0500 Received: from mail123.messagelabs.com ([85.158.136.3]:33378 "HELO mail123.messagelabs.com") by vger.kernel.org with SMTP id S1751154AbVK3JGP (ORCPT ); Wed, 30 Nov 2005 04:06:15 -0500 X-VirusChecked: Checked X-Env-Sender: jfs@keytradebank.com X-Msg-Ref: server-6.tower-123.messagelabs.com!1133341568!19746533!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [62.72.98.157] Received: (qmail 10818 invoked from network); 30 Nov 2005 09:06:08 -0000 Received: from mail.keytradebank.com (HELO mail.keytradebank.com) (62.72.98.157) by server-6.tower-123.messagelabs.com with SMTP; 30 Nov 2005 09:06:08 -0000 Received: by mail.keytradebank.com (Postfix, from userid 1002) id 2EC397C58B0; Wed, 30 Nov 2005 10:06:07 +0100 (CET) Received: from [192.168.201.144] (jfs.it.keytrade.com [192.168.201.144]) by mail.keytradebank.com (Postfix) with ESMTP id D95017C5892; Wed, 30 Nov 2005 10:06:06 +0100 (CET) Message-ID: <438D6B73.2060902@keytradebank.com> Date: Wed, 30 Nov 2005 10:05:55 +0100 From: =?ISO-8859-2?Q?Jean-Fran=E7ois_Stenuit?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux-ide Cc: Tejun Heo , "0602@eq.cz" <0602@eq.cz> Subject: Re: totally random "VFS: Cannot open root device" References: <438B6E05.8070009@eq.cz> <438D2C19.3030008@gmail.com> In-Reply-To: <438D2C19.3030008@gmail.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010007040900030102060401" X-Disclaimer: Please visit http://www.keytradebank.com/maildisclamer.html Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: FA X-Keywords: X-UID: 89 This is a cryptographically signed message in MIME format. --------------ms010007040900030102060401 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Note that I experienced the same problem yesterday evening with a 2.6.15-rc3 on HP Proliant DL140, which has an ICH-5 based controller and a Maxtor drive Successfull boot shows : ... libata version 1.12 loaded. ata_piix version 1.04 ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1f.2 to 64 ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1470 irq 14 ata1: dev 0 cfg 49:2f00 82:7869 83:7d09 84:4633 85:7869 86:3c01 87:4623 88:203f ata1: dev 0 ATA, max UDMA/100, 156301488 sectors: lba48 ata1: dev 0 configured for UDMA/100 scsi0 : ata_piix Vendor: ATA Model: Maxtor 6L080M0 Rev: BANC Type: Direct-Access ANSI SCSI revision: 05 ata2: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x1478 irq 15 ata2: SATA port has no device. scsi1 : ata_piix st: Version 20050830, fixed bufsize 32768, s/g segs 256 SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) SCSI device sda: drive cache: write back SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 > Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0 ... A failed boot shows "ata1: SATA port has no device". I'll try to set-up a serial console to log the boot messages. This behaviour can be reproduced on four different DL140's, so it's fairly safe to say it's not a cabling/hardware problem. Tejun Heo wrote: > 0602@eq.cz wrote: > >> Hi! >> >> (Please CC me your answers as I am not subscribed.) >> >> I have a problem with 2.6.14.3 kernel (but this probably isn't too >> version-specific). I have a kernel which succesfully boots on totally >> random basis (cca 70% is success). My root partition resides on a >> SATA disc connected to a controller on Intel 6300ESB ICH southbridge >> (mb Intel se7320vp2). There is a reiserfs 3 filesystem on my root >> partition. Without any changes to configuration (os or bios or >> whatever) I sometimes get: >> >> VFS: Cannot open root device "801" or unknown block(8,1) >> >> Could this be some timeout issue, or indication of crappy hw? I've >> tried this about 10 times (immediately ctrl+alt+del on successfull >> boot or reset button on aforementioned panic) and I saw no >> regularities in this misbehaviour. >> >> I sincerely appreciate any advice anyone can give. >> > > [CC'ing linux-ide] > > Hello, 0602. :-) > > Can you please post dmesg of a successful booting? That will tell us > which SATA controller/disks you are using. Also, the boot log of a > failed boot will be very helpful - the best way to get this is via > serial console. If you don't have access to serial console, taking > note / picture of the part where SATA detection fails will do too. > > Also, when the machine boots successfully, does it work without > generating disk related kernel logs? Just perform any IO-heavy > operations - cp'ing directories which contain large files, > tar/untarring... - and see if the kernel complains about anyting. > -- Jean-François "Jef" Stenuit Network & Security manager Keytrade Bank SA --------------ms010007040900030102060401 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9TCC AtUwggI+oAMCAQICAw940zANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwOTEzMTU0NDM0WhcNMDYwOTEzMTU0NDM0 WjBGMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRq ZnNAa2V5dHJhZGViYW5rLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJvF EsxKTbVcg2evoxzm3Gs2PErR2jLXLyAosTiTvopWw3HZAKTD+3rVBQKZA4ykdbC4Spk7ca05 2ENgt3naP/6bJ8gWCrgd9AQ0CRRDNuyE1A0YWjM4G8SYaKNXC+yjhrhaobmKcBQhtysQxHMo s0+SDVbNAOdYjK7rdjN+WGZQpbjJ3E8LtP4Vqv4YoA5LpyumVGq1aCcRNvHC0EbNfGi9p6R6 sIjMglPH0ZAa9YGcX9U6qz/je8ImvL/k9B7Hys8YAN8uLDol9qMKXkys7Nc2UA/V6Qy3/vME PkQ6mnx8m30a1IAHK8zxvpRSpY/SmdSGIk3PGrOwXnCazsAKyX8CAwEAAaMxMC8wHwYDVR0R BBgwFoEUamZzQGtleXRyYWRlYmFuay5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQF AAOBgQC0RNI63E0hHdNOy1ffX2Vg+qddH4vJDdtKHcYbI6B3/C8OJTCQLWRRZpOPwVQqNpVL 8OzsDYTX1ARzlzMA9H0grN5AD3hLZxSsNJj0X47SpEq8OyVPlACaKa1YAulRg5QL57gCDSGf 9xPO1nrA9sdlRG0fZLSauFLf4IOdnF7hJzCCAtUwggI+oAMCAQICAw940zANBgkqhkiG9w0B AQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcN MDUwOTEzMTU0NDM0WhcNMDYwOTEzMTU0NDM0WjBGMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1h aWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZnNAa2V5dHJhZGViYW5rLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAJvFEsxKTbVcg2evoxzm3Gs2PErR2jLXLyAosTiT vopWw3HZAKTD+3rVBQKZA4ykdbC4Spk7ca052ENgt3naP/6bJ8gWCrgd9AQ0CRRDNuyE1A0Y WjM4G8SYaKNXC+yjhrhaobmKcBQhtysQxHMos0+SDVbNAOdYjK7rdjN+WGZQpbjJ3E8LtP4V qv4YoA5LpyumVGq1aCcRNvHC0EbNfGi9p6R6sIjMglPH0ZAa9YGcX9U6qz/je8ImvL/k9B7H ys8YAN8uLDol9qMKXkys7Nc2UA/V6Qy3/vMEPkQ6mnx8m30a1IAHK8zxvpRSpY/SmdSGIk3P GrOwXnCazsAKyX8CAwEAAaMxMC8wHwYDVR0RBBgwFoEUamZzQGtleXRyYWRlYmFuay5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQC0RNI63E0hHdNOy1ffX2Vg+qddH4vJ DdtKHcYbI6B3/C8OJTCQLWRRZpOPwVQqNpVL8OzsDYTX1ARzlzMA9H0grN5AD3hLZxSsNJj0 X47SpEq8OyVPlACaKa1YAulRg5QL57gCDSGf9xPO1nrA9sdlRG0fZLSauFLf4IOdnF7hJzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDD3jTMAkGBSsOAwIaBQCgggGnMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MTEzMDA5MDU1NlowIwYJ KoZIhvcNAQkEMRYEFL5Km/pf2sJLlyq64s8oCCyT89XDMFIGCSqGSIb3DQEJDzFFMEMwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMPeNMwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDD3jTMA0GCSqGSIb3DQEBAQUA BIIBAIix1UWzzOBqxDgFE0EXI5BfZ32qY1CppLAOra7f/CZ9RiqIgRr1h5m/QoMzJSdnYjtl eyOjP2PyoI01aEYfqC1PoKgL39yztjkQKlWA0dBoMBfDj28aksI43RD1y4n8aO/fwqj9B1TO 0McxsRrszBem0eQomxUCShtgGXHyDrdXEmckLYbrquel+T+HpwNoKOOS3pZnWFs42h29a1Tq hrOtNHnB41C/TeIhRbWzjuOCPzG+KGzTBMl8yoE346GsCoL+FmAGIIcGDGN221rZdnuDGBH5 KGBDPAdopb7poM4tYqModwJRUCDtJpzANc4AWsZSG8VKMhhWMfrlO0A4d00AAAAAAAA= --------------ms010007040900030102060401-- - 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 From RossBoylan@stanfordalumni.org Wed Nov 30 01:13:12 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Wed, 30 Nov 2005 01:14:30 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751156AbVK3JNT (ORCPT ); Wed, 30 Nov 2005 04:13:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751158AbVK3JNT (ORCPT ); Wed, 30 Nov 2005 04:13:19 -0500 Received: from mail0.rawbw.com ([198.144.192.41]:30483 "EHLO mail0.rawbw.com") by vger.kernel.org with ESMTP id S1751156AbVK3JNT (ORCPT ); Wed, 30 Nov 2005 04:13:19 -0500 Received: from wheat.betterworld.us (m201-14.dsl.tsoft.com [198.144.201.14]) by mail0.rawbw.com (8.11.6p2/8.11.6) with ESMTP id jAU9DDl26869; Wed, 30 Nov 2005 01:13:13 -0800 (PST) Received: from ross by wheat.betterworld.us with local (Exim 3.36 #1 (Debian)) id 1EhO1Y-0005Pi-00; Wed, 30 Nov 2005 01:13:12 -0800 Date: Wed, 30 Nov 2005 01:13:12 -0800 To: linux-kernel@vger.kernel.org Cc: Ross Boylan Subject: WD 2nd generation SATA not detected on Intel 945PSNLK Message-ID: <20051130091312.GC4092@wheat.betterworld.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i From: Ross Boylan Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Status: RO X-Status: F X-Keywords: X-UID: 95 I have an excessively new system for which 2.6.12 kernel in the Debian etch beta 1 installer doesn't detect the hard drive. Intel D945PSNLK Motherboard WD25000JS-OOM, which Western Digital's site says is a 2nd generation SATA. Pentium 4 630 processor. Intel provides drivers for this motherboard, but they only seem to concern the on-board audio and LAN. I'm not sure if the problem is the m/b or the disk, or the combination. Win2K managed to see the drive, so the hardware is OK. dmesg shows IHC7: ICH7: IDE controller at PCI slot 0000:00:1f.1 ICH7: chipset revision 1 ICH7: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x30b0-0x30b7, BIOST settings: hda:DMA, hdb:pio Unfortunately, the thing at IDE0 is the DVD. manually loading the ahci driver doesn't work. An earlier thread with a somewhat similar problem advised doing this to see what the messages were, but nothing useful showed up (modprove -v ahci). The installer doesn't seem to have lspci. I've tried ATA/IDE mode as enhanced and legacy in the BIOS; neither works. Any suggestions? I would appreciate if you cc'd me. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From devenbalani@gmail.com Wed Nov 30 02:41:47 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Wed, 30 Nov 2005 02:44:27 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750980AbVK3Kls (ORCPT ); Wed, 30 Nov 2005 05:41:48 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751125AbVK3Kls (ORCPT ); Wed, 30 Nov 2005 05:41:48 -0500 Received: from zproxy.gmail.com ([64.233.162.204]:6221 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S1750980AbVK3Kls convert rfc822-to-8bit (ORCPT ); Wed, 30 Nov 2005 05:41:48 -0500 Received: by zproxy.gmail.com with SMTP id 14so1889627nzn for ; Wed, 30 Nov 2005 02:41:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=J9GXZ96jlAkk4fNhdyXYMdWwSLNNJXt8EIM1Ox7aMdLOPKgEqQ6wXwcndX/OI74xdpnYhiVpkZb41UEMilcwAxXSsTtR+PmhDcfe4zUaybRsExCL4mjMavhbbMY5qn0Gfq5DZj76MGSkeHP9niu1oTWYWw1TwHqbJVaJ1HcC1h8= Received: by 10.36.50.19 with SMTP id x19mr33915nzx; Wed, 30 Nov 2005 02:41:47 -0800 (PST) Received: by 10.36.48.1 with HTTP; Wed, 30 Nov 2005 02:41:47 -0800 (PST) Message-ID: <7a37e95e0511300241j3136e407r1d2395342f5c045b@mail.gmail.com> Date: Wed, 30 Nov 2005 16:11:47 +0530 From: Deven Balani To: linux-kernel@vger.kernel.org Subject: kiobuf mechanism for SATA drivers MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 115 Hi All! I am using a SATA driver. I want to do zero-copy mechanism in the Application using this SATA driver. Can I use kiobuf mechanism on SCSI Disk drivers. Is there any source where I can know more on using kiobuf mechanism for SATA. I came to know SCSI Generic uses this mechanism. Can SCSI Disk driver do the same. Regards, deven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From 0602@eq.cz Wed Nov 30 05:07:06 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Wed, 30 Nov 2005 05:06:24 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751206AbVK3NGX (ORCPT ); Wed, 30 Nov 2005 08:06:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751208AbVK3NGX (ORCPT ); Wed, 30 Nov 2005 08:06:23 -0500 Received: from mail.cesky-hosting.cz ([81.0.238.178]:38386 "EHLO mail.cesky-hosting.cz") by vger.kernel.org with ESMTP id S1751206AbVK3NGW (ORCPT ); Wed, 30 Nov 2005 08:06:22 -0500 Received: (qmail 8433 invoked from network); 30 Nov 2005 13:06:14 -0000 Received: from unknown (HELO ?192.168.0.200?) (pokus@eq.cz@195.47.114.89) by mail.cesky-hosting.cz with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Nov 2005 13:06:14 -0000 Message-ID: <438DA3FA.2010809@eq.cz> Date: Wed, 30 Nov 2005 14:07:06 +0100 From: "0602@eq.cz" <0602@eq.cz> User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051129) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tejun Heo CC: linux-kernel@vger.kernel.org, Linux-ide Subject: Re: totally random "VFS: Cannot open root device" References: <438B6E05.8070009@eq.cz> <438D2C19.3030008@gmail.com> In-Reply-To: <438D2C19.3030008@gmail.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 151 Hi, (Please CC me your answers as I am not subscribed.) Tejun Heo wrote: [...] > Can you please post dmesg of a successful booting? That will tell us > which SATA controller/disks you are using. Also, the boot log of a > failed boot will be very helpful - the best way to get this is via > serial console. If you don't have access to serial console, taking note > / picture of the part where SATA detection fails will do too. I've placed the dmesg and the picture of panic here: http://26143.eq.cz/ > > Also, when the machine boots successfully, does it work without > generating disk related kernel logs? Just perform any IO-heavy > operations - cp'ing directories which contain large files, > tar/untarring... - and see if the kernel complains about anyting. > There are no signs of anything wrong in logs, all my IO tests passed ok. Regards, r. - 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 From rdunlap@xenotime.net Wed Nov 30 08:30:36 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Wed, 30 Nov 2005 08:30:40 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751438AbVK3Qai convert rfc822-to-quoted-printable (ORCPT ); Wed, 30 Nov 2005 11:30:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751442AbVK3Qai (ORCPT ); Wed, 30 Nov 2005 11:30:38 -0500 Received: from xenotime.net ([66.160.160.81]:57285 "HELO xenotime.net") by vger.kernel.org with SMTP id S1751438AbVK3Qah convert rfc822-to-8bit (ORCPT ); Wed, 30 Nov 2005 11:30:37 -0500 Received: from shark.he.net ([66.160.160.2]) by xenotime.net for ; Wed, 30 Nov 2005 08:30:36 -0800 Date: Wed, 30 Nov 2005 08:30:36 -0800 (PST) From: "Randy.Dunlap" X-X-Sender: rddunlap@shark.he.net To: =?ISO-8859-2?Q?Jean-Fran=E7ois_Stenuit?= cc: Linux-ide , Tejun Heo , "0602@eq.cz" <0602@eq.cz> Subject: Re: totally random "VFS: Cannot open root device" In-Reply-To: <438D6B73.2060902@keytradebank.com> Message-ID: References: <438B6E05.8070009@eq.cz> <438D2C19.3030008@gmail.com> <438D6B73.2060902@keytradebank.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 254 On Wed, 30 Nov 2005, [ISO-8859-2] Jean-Fran=E7ois Stenuit wrote: > > Note that I experienced the same problem yesterday evening with a > 2.6.15-rc3 on HP Proliant DL140, which has an ICH-5 based controller = and > a Maxtor drive > > Successfull boot shows : > ... > libata version 1.12 loaded. > ata_piix version 1.04 > ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 17 > PCI: Setting latency timer of device 0000:00:1f.2 to 64 > ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1470 irq 14 > ata1: dev 0 cfg 49:2f00 82:7869 83:7d09 84:4633 85:7869 86:3c01 87:46= 23 > 88:203f > ata1: dev 0 ATA, max UDMA/100, 156301488 sectors: lba48 > ata1: dev 0 configured for UDMA/100 > scsi0 : ata_piix > Vendor: ATA Model: Maxtor 6L080M0 Rev: BANC > Type: Direct-Access ANSI SCSI revision: 05 > ata2: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x1478 irq 15 > ata2: SATA port has no device. > scsi1 : ata_piix > st: Version 20050830, fixed bufsize 32768, s/g segs 256 > SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) > SCSI device sda: drive cache: write back > SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) > SCSI device sda: drive cache: write back > sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 > > Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 > Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0 > ... > > A failed boot shows "ata1: SATA port has no device". I'll try to set-= up > a serial console to log the boot messages. I've seen this a few times. If you were using MSI interrupts, I would blame that, but you aren't AFAICT, so try booting with the "irqpoll" kernel boot option to see if the kernel can reroute the (seemingly) lost interrupts. Maybe we can deduce something from that. If it works, please post the /proc/interrupts file. > This behaviour can be reproduced on four different DL140's, so it's > fairly safe to say it's not a cabling/hardware problem. > > Tejun Heo wrote: > > > 0602@eq.cz wrote: > > > >> Hi! > >> > >> (Please CC me your answers as I am not subscribed.) > >> > >> I have a problem with 2.6.14.3 kernel (but this probably isn't too > >> version-specific). I have a kernel which succesfully boots on tota= lly > >> random basis (cca 70% is success). My root partition resides on a > >> SATA disc connected to a controller on Intel 6300ESB ICH southbrid= ge > >> (mb Intel se7320vp2). There is a reiserfs 3 filesystem on my root > >> partition. Without any changes to configuration (os or bios or > >> whatever) I sometimes get: > >> > >> VFS: Cannot open root device "801" or unknown block(8,1) > >> > >> Could this be some timeout issue, or indication of crappy hw? I've > >> tried this about 10 times (immediately ctrl+alt+del on successfull > >> boot or reset button on aforementioned panic) and I saw no > >> regularities in this misbehaviour. > >> > >> I sincerely appreciate any advice anyone can give. > >> > > > > [CC'ing linux-ide] > > > > Hello, 0602. :-) > > > > Can you please post dmesg of a successful booting? That will tell = us > > which SATA controller/disks you are using. Also, the boot log of a > > failed boot will be very helpful - the best way to get this is via > > serial console. If you don't have access to serial console, taking > > note / picture of the part where SATA detection fails will do too= =2E > > > > Also, when the machine boots successfully, does it work without > > generating disk related kernel logs? Just perform any IO-heavy > > operations - cp'ing directories which contain large files, > > tar/untarring... - and see if the kernel complains about anyting. --=20 ~Randy - 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 From benh@kernel.crashing.org Wed Nov 30 14:39:29 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Wed, 30 Nov 2005 14:46:07 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751178AbVK3WqF (ORCPT ); Wed, 30 Nov 2005 17:46:05 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751198AbVK3WqF (ORCPT ); Wed, 30 Nov 2005 17:46:05 -0500 Received: from gate.crashing.org ([63.228.1.57]:2236 "EHLO gate.crashing.org") by vger.kernel.org with ESMTP id S1751178AbVK3WqF (ORCPT ); Wed, 30 Nov 2005 17:46:05 -0500 Received: from gaston (localhost [127.0.0.1]) by gate.crashing.org (8.12.8/8.12.8) with ESMTP id jAUMgbWG014963; Wed, 30 Nov 2005 16:42:38 -0600 Subject: Re: Crash when inserting media bay CD with 2.6.15-rc3 From: Benjamin Herrenschmidt To: Bartlomiej Zolnierkiewicz Cc: list linux-ide , Andrew Morton In-Reply-To: <58cb370e0511300012p2f703ec0wd5ea054d5b7403d6@mail.gmail.com> References: <1133329478.16726.65.camel@gaston> <58cb370e0511300012p2f703ec0wd5ea054d5b7403d6@mail.gmail.com> Content-Type: text/plain Date: Thu, 01 Dec 2005 09:39:29 +1100 Message-Id: <1133390370.16726.82.camel@gaston> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 520 On Wed, 2005-11-30 at 09:12 +0100, Bartlomiej Zolnierkiewicz wrote: > > For your information, the media bay driver, when detecting an IDE > > device, first waits for the BUSY bit to clear (historical reasons: the > > IDE driver used not to do it before I fixed it and I never udpated the > > mediabay driver) and then does: > > > > ide_init_hwif_ports(&hw, (unsigned long) bay->cd_base, (unsigned long) 0, NULL); > > hw.irq = bay->cd_irq; > > hw.chipset = ide_pmac; > > bay->cd_index = ide_register_hw(&hw, NULL); > > mediabay driver allocates hw_regs_t hw from the stack but doesn't > clear it before usage (hw->dev was added recently)? Ah yes, the hw_regs_t in the past was only used temporarily, ide_register_hw just copied it. I'll have to dig in there and figure out how things changed. Thanks. Ben. - 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 From jgarzik@pobox.com Wed Nov 30 21:26:24 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Wed, 30 Nov 2005 21:28:07 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932075AbVLAF0d (ORCPT ); Thu, 1 Dec 2005 00:26:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751395AbVLAF0d (ORCPT ); Thu, 1 Dec 2005 00:26:33 -0500 Received: from mail.dvmed.net ([216.237.124.58]:23744 "EHLO mail.dvmed.net") by vger.kernel.org with ESMTP id S1751369AbVLAF0c (ORCPT ); Thu, 1 Dec 2005 00:26:32 -0500 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1Ehgxf-0003it-LP; Thu, 01 Dec 2005 05:26:30 +0000 Message-ID: <438E8980.4030800@pobox.com> Date: Thu, 01 Dec 2005 00:26:24 -0500 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "linux-ide@vger.kernel.org" CC: Linux Kernel Subject: Linux SATA status report updated Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Spam-Report: Spam detection software, running on the system "srv2.dvmed.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: I just updated the Linux SATA status pages with the latest drivers and progress: hardware: http://linux.yyz.us/sata/sata-status.html software: http://linux.yyz.us/sata/software-status.html Let me know if there are any errors or omissions. [...] Content analysis details: (0.6 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.5 TO_ADDRESS_EQ_REAL To: repeats address as real name 0.1 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [69.134.188.146 listed in dnsbl.sorbs.net] Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org I just updated the Linux SATA status pages with the latest drivers and progress: hardware: http://linux.yyz.us/sata/sata-status.html software: http://linux.yyz.us/sata/software-status.html Let me know if there are any errors or omissions. Jeff - 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 From jfs@keytradebank.com Thu Dec 1 01:40:18 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 01:40:41 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932119AbVLAJkj (ORCPT ); Thu, 1 Dec 2005 04:40:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932121AbVLAJkj (ORCPT ); Thu, 1 Dec 2005 04:40:39 -0500 Received: from mail92.messagelabs.com ([194.106.220.51]:64488 "HELO mail92.messagelabs.com") by vger.kernel.org with SMTP id S932119AbVLAJki (ORCPT ); Thu, 1 Dec 2005 04:40:38 -0500 X-VirusChecked: Checked X-Env-Sender: jfs@keytradebank.com X-Msg-Ref: server-9.tower-92.messagelabs.com!1133430031!16223871!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [62.72.98.157] Received: (qmail 29136 invoked from network); 1 Dec 2005 09:40:31 -0000 Received: from mail.keytradebank.com (HELO mail.keytradebank.com) (62.72.98.157) by server-9.tower-92.messagelabs.com with SMTP; 1 Dec 2005 09:40:31 -0000 Received: by mail.keytradebank.com (Postfix, from userid 1002) id 6C4837C5914; Thu, 1 Dec 2005 10:40:30 +0100 (CET) Received: from [192.168.201.144] (jfs.it.keytrade.com [192.168.201.144]) by mail.keytradebank.com (Postfix) with ESMTP id 21CC67C5907; Thu, 1 Dec 2005 10:40:30 +0100 (CET) Message-ID: <438EC502.1090103@keytradebank.com> Date: Thu, 01 Dec 2005 10:40:18 +0100 From: =?ISO-8859-1?Q?Jean-Fran=E7ois_Stenuit?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Mannthey Cc: "0602@eq.cz" <0602@eq.cz>, Tejun Heo , Linux-ide Subject: Re: totally random "VFS: Cannot open root device" References: <438B6E05.8070009@eq.cz> <438D2C19.3030008@gmail.com> <438DA3FA.2010809@eq.cz> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050404060906010904050401" X-Disclaimer: Please visit http://www.keytradebank.com/maildisclamer.html Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 107 This is a cryptographically signed message in MIME format. --------------ms050404060906010904050401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Keith, I have been able to reproduce the bug (randomly - needing a few reboots to make it happen) on a 2.6.15-rc3 kernel. System is an HP DL140G2 with following SATA controller (from lspci -vv) : 0000:00:1f.2 IDE interface: Intel Corp. 82801EB (ICH5) Serial ATA 150 Storage Controller (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: Hewlett-Packard Company: Unknown device 3208 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Region 1: I/O ports at Region 2: I/O ports at Region 3: I/O ports at Region 4: I/O ports at 1470 [size=16] Keith Mannthey wrote: >On 11/30/05, 0602@eq.cz <0602@eq.cz> wrote: > >Best guess is driver initilization troubles. The screen shot only >dosen't really show anything besides it is broken. A full boot log >from the failed boot would be nice. There were some recent SATA >change could you try the current 2.6.15-rc3 as well? > >Thanks, > Keith > -- Jean-François "Jef" Stenuit Network & Security manager Keytrade Bank SA --------------ms050404060906010904050401 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9TCC AtUwggI+oAMCAQICAw940zANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwOTEzMTU0NDM0WhcNMDYwOTEzMTU0NDM0 WjBGMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRq ZnNAa2V5dHJhZGViYW5rLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJvF EsxKTbVcg2evoxzm3Gs2PErR2jLXLyAosTiTvopWw3HZAKTD+3rVBQKZA4ykdbC4Spk7ca05 2ENgt3naP/6bJ8gWCrgd9AQ0CRRDNuyE1A0YWjM4G8SYaKNXC+yjhrhaobmKcBQhtysQxHMo s0+SDVbNAOdYjK7rdjN+WGZQpbjJ3E8LtP4Vqv4YoA5LpyumVGq1aCcRNvHC0EbNfGi9p6R6 sIjMglPH0ZAa9YGcX9U6qz/je8ImvL/k9B7Hys8YAN8uLDol9qMKXkys7Nc2UA/V6Qy3/vME PkQ6mnx8m30a1IAHK8zxvpRSpY/SmdSGIk3PGrOwXnCazsAKyX8CAwEAAaMxMC8wHwYDVR0R BBgwFoEUamZzQGtleXRyYWRlYmFuay5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQF AAOBgQC0RNI63E0hHdNOy1ffX2Vg+qddH4vJDdtKHcYbI6B3/C8OJTCQLWRRZpOPwVQqNpVL 8OzsDYTX1ARzlzMA9H0grN5AD3hLZxSsNJj0X47SpEq8OyVPlACaKa1YAulRg5QL57gCDSGf 9xPO1nrA9sdlRG0fZLSauFLf4IOdnF7hJzCCAtUwggI+oAMCAQICAw940zANBgkqhkiG9w0B AQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcN MDUwOTEzMTU0NDM0WhcNMDYwOTEzMTU0NDM0WjBGMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1h aWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZnNAa2V5dHJhZGViYW5rLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAJvFEsxKTbVcg2evoxzm3Gs2PErR2jLXLyAosTiT vopWw3HZAKTD+3rVBQKZA4ykdbC4Spk7ca052ENgt3naP/6bJ8gWCrgd9AQ0CRRDNuyE1A0Y WjM4G8SYaKNXC+yjhrhaobmKcBQhtysQxHMos0+SDVbNAOdYjK7rdjN+WGZQpbjJ3E8LtP4V qv4YoA5LpyumVGq1aCcRNvHC0EbNfGi9p6R6sIjMglPH0ZAa9YGcX9U6qz/je8ImvL/k9B7H ys8YAN8uLDol9qMKXkys7Nc2UA/V6Qy3/vMEPkQ6mnx8m30a1IAHK8zxvpRSpY/SmdSGIk3P GrOwXnCazsAKyX8CAwEAAaMxMC8wHwYDVR0RBBgwFoEUamZzQGtleXRyYWRlYmFuay5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQC0RNI63E0hHdNOy1ffX2Vg+qddH4vJ DdtKHcYbI6B3/C8OJTCQLWRRZpOPwVQqNpVL8OzsDYTX1ARzlzMA9H0grN5AD3hLZxSsNJj0 X47SpEq8OyVPlACaKa1YAulRg5QL57gCDSGf9xPO1nrA9sdlRG0fZLSauFLf4IOdnF7hJzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDD3jTMAkGBSsOAwIaBQCgggGnMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MTIwMTA5NDAxOVowIwYJ KoZIhvcNAQkEMRYEFNFPtt3wMehSFP912E2zcJLWLneBMFIGCSqGSIb3DQEJDzFFMEMwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMPeNMwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDD3jTMA0GCSqGSIb3DQEBAQUA BIIBABeeThhYFLhMAGzFCejaiGwHhsGdaoh2Glu2QJPD/suXp5Dwi/9DUHQv3ogBl2y+zC9O OU5JurywWNG+QCUCsQw1VtoluocSn8OkPQWO1SD9lW1/5JuiV6E1c4zwgIkAT9OKSLp0tMwR WXSrCpfVTgfTEyBUx7GZHCkShhdcfgwm1Cb0BREsb3ZQ2OzXGKjx6QXVdwFI3K8hkpvERIOt xZIW+LhxAjRzFolA4/cwhn69BQK+z3eppQIH5C2EoFvA1vXmy1CDPdeFmanBz233ZwyW4fAl TAq2RAcc0eGOb1eJLkgra2di4XBDgD4hIrMKQPSzCtKXNXKGX30wx49Rc5MAAAAAAAA= --------------ms050404060906010904050401-- - 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 From jfs@keytradebank.com Thu Dec 1 01:42:48 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 01:43:02 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932121AbVLAJnA (ORCPT ); Thu, 1 Dec 2005 04:43:00 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932124AbVLAJnA (ORCPT ); Thu, 1 Dec 2005 04:43:00 -0500 Received: from mail91.messagelabs.com ([194.106.220.35]:29662 "HELO mail91.messagelabs.com") by vger.kernel.org with SMTP id S932121AbVLAJnA (ORCPT ); Thu, 1 Dec 2005 04:43:00 -0500 X-VirusChecked: Checked X-Env-Sender: jfs@keytradebank.com X-Msg-Ref: server-10.tower-91.messagelabs.com!1133430178!18041189!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [62.72.98.157] Received: (qmail 5603 invoked from network); 1 Dec 2005 09:42:58 -0000 Received: from mail.keytradebank.com (HELO mail.keytradebank.com) (62.72.98.157) by server-10.tower-91.messagelabs.com with SMTP; 1 Dec 2005 09:42:58 -0000 Received: by mail.keytradebank.com (Postfix, from userid 1002) id 16D177C58BC; Thu, 1 Dec 2005 10:42:57 +0100 (CET) Received: from [192.168.201.144] (jfs.it.keytrade.com [192.168.201.144]) by mail.keytradebank.com (Postfix) with ESMTP id CDEAB7C589D; Thu, 1 Dec 2005 10:42:56 +0100 (CET) Message-ID: <438EC598.8050803@keytradebank.com> Date: Thu, 01 Dec 2005 10:42:48 +0100 From: =?ISO-8859-1?Q?Jean-Fran=E7ois_Stenuit?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randy.Dunlap" Cc: Linux-ide , Tejun Heo , "0602@eq.cz" <0602@eq.cz> Subject: Re: totally random "VFS: Cannot open root device" References: <438B6E05.8070009@eq.cz> <438D2C19.3030008@gmail.com> <438D6B73.2060902@keytradebank.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080206070300040501050205" X-Disclaimer: Please visit http://www.keytradebank.com/maildisclamer.html Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 109 This is a cryptographically signed message in MIME format. --------------ms080206070300040501050205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Randy, Booting with irqpoll does not help. I guess we'll need to dig a little further ;-) Randy.Dunlap wrote: >On Wed, 30 Nov 2005, [ISO-8859-2] Jean-François Stenuit wrote: > > >>Note that I experienced the same problem yesterday evening with a >>2.6.15-rc3 on HP Proliant DL140, which has an ICH-5 based controller and >>a Maxtor drive >> >> >I've seen this a few times. >If you were using MSI interrupts, I would blame that, >but you aren't AFAICT, so try booting with the "irqpoll" kernel >boot option to see if the kernel can reroute the (seemingly) >lost interrupts. Maybe we can deduce something from that. >If it works, please post the /proc/interrupts file. > > -- Jean-François "Jef" Stenuit Network & Security manager Keytrade Bank SA --------------ms080206070300040501050205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9TCC AtUwggI+oAMCAQICAw940zANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwOTEzMTU0NDM0WhcNMDYwOTEzMTU0NDM0 WjBGMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRq ZnNAa2V5dHJhZGViYW5rLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJvF EsxKTbVcg2evoxzm3Gs2PErR2jLXLyAosTiTvopWw3HZAKTD+3rVBQKZA4ykdbC4Spk7ca05 2ENgt3naP/6bJ8gWCrgd9AQ0CRRDNuyE1A0YWjM4G8SYaKNXC+yjhrhaobmKcBQhtysQxHMo s0+SDVbNAOdYjK7rdjN+WGZQpbjJ3E8LtP4Vqv4YoA5LpyumVGq1aCcRNvHC0EbNfGi9p6R6 sIjMglPH0ZAa9YGcX9U6qz/je8ImvL/k9B7Hys8YAN8uLDol9qMKXkys7Nc2UA/V6Qy3/vME PkQ6mnx8m30a1IAHK8zxvpRSpY/SmdSGIk3PGrOwXnCazsAKyX8CAwEAAaMxMC8wHwYDVR0R BBgwFoEUamZzQGtleXRyYWRlYmFuay5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQF AAOBgQC0RNI63E0hHdNOy1ffX2Vg+qddH4vJDdtKHcYbI6B3/C8OJTCQLWRRZpOPwVQqNpVL 8OzsDYTX1ARzlzMA9H0grN5AD3hLZxSsNJj0X47SpEq8OyVPlACaKa1YAulRg5QL57gCDSGf 9xPO1nrA9sdlRG0fZLSauFLf4IOdnF7hJzCCAtUwggI+oAMCAQICAw940zANBgkqhkiG9w0B AQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcN MDUwOTEzMTU0NDM0WhcNMDYwOTEzMTU0NDM0WjBGMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1h aWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZnNAa2V5dHJhZGViYW5rLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAJvFEsxKTbVcg2evoxzm3Gs2PErR2jLXLyAosTiT vopWw3HZAKTD+3rVBQKZA4ykdbC4Spk7ca052ENgt3naP/6bJ8gWCrgd9AQ0CRRDNuyE1A0Y WjM4G8SYaKNXC+yjhrhaobmKcBQhtysQxHMos0+SDVbNAOdYjK7rdjN+WGZQpbjJ3E8LtP4V qv4YoA5LpyumVGq1aCcRNvHC0EbNfGi9p6R6sIjMglPH0ZAa9YGcX9U6qz/je8ImvL/k9B7H ys8YAN8uLDol9qMKXkys7Nc2UA/V6Qy3/vMEPkQ6mnx8m30a1IAHK8zxvpRSpY/SmdSGIk3P GrOwXnCazsAKyX8CAwEAAaMxMC8wHwYDVR0RBBgwFoEUamZzQGtleXRyYWRlYmFuay5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQC0RNI63E0hHdNOy1ffX2Vg+qddH4vJ DdtKHcYbI6B3/C8OJTCQLWRRZpOPwVQqNpVL8OzsDYTX1ARzlzMA9H0grN5AD3hLZxSsNJj0 X47SpEq8OyVPlACaKa1YAulRg5QL57gCDSGf9xPO1nrA9sdlRG0fZLSauFLf4IOdnF7hJzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDD3jTMAkGBSsOAwIaBQCgggGnMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MTIwMTA5NDI0OFowIwYJ KoZIhvcNAQkEMRYEFLcZ8UvABZOJeaLF3Xj/gueZGWGkMFIGCSqGSIb3DQEJDzFFMEMwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMPeNMwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDD3jTMA0GCSqGSIb3DQEBAQUA BIIBAGd8RmA50qtz3ZED3tzXaGLgPdzq8brWl4DD/906OaS0ERwyYMQy3LZq1DxXonuiT+0R sLctE0Enueg7ORMViANnYR3Fhxx8QdtaA9djQh1jyq4uEO3QRD5N9NG+0p8VtfPUcwh6wI23 FQQRZL86mUaG1tGw0AfoM22CGkLnHJDTSrgDgSn2Uqd7p6oLF+CZoHSye0sSEafc0GWwxjBk Ev+HqQhXDMS8B7cbBeej1+UvhN59KyKEQD84dh0sF4oR33m9U2n1t6BeAHSzq6sxnwqoX0kg QCv030xJtFHwvtMuj5POZ8xQ74u+UXIbqElCUv272OMjDnYumhlxrNEw6tQAAAAAAAA= --------------ms080206070300040501050205-- - 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 From jgarzik@pobox.com Thu Dec 1 02:01:17 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 02:01:24 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751360AbVLAKBU (ORCPT ); Thu, 1 Dec 2005 05:01:20 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751665AbVLAKBU (ORCPT ); Thu, 1 Dec 2005 05:01:20 -0500 Received: from havoc.gtf.org ([69.61.125.42]:12781 "EHLO havoc.gtf.org") by vger.kernel.org with ESMTP id S1751360AbVLAKBT (ORCPT ); Thu, 1 Dec 2005 05:01:19 -0500 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by havoc.gtf.org (Postfix) with ESMTP id 597AB1C4B407; Thu, 1 Dec 2005 05:01:18 -0500 (EST) Received: (from garzik@localhost) by havoc.gtf.org (8.13.1/8.13.1/Submit) id jB1A1Hic023886; Thu, 1 Dec 2005 05:01:17 -0500 Date: Thu, 1 Dec 2005 05:01:17 -0500 From: Jeff Garzik To: linux-ide@vger.kernel.org Cc: linux-kernel@vger.kernel.org, akpm@osdl.org Subject: libata queue updated Message-ID: <20051201100117.GA23762@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 116 Here is the current contents of libata-dev.git#ALL, which is auto-propagated to Andrew Morton's -mm tree. http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.15-rc4-libata1.patch.bz2 A lot of this stuff is the 'pata-drivers' branch, which is available for testing, but not bound for upstream anytime soon. Alan Cox: Add libata CMD/SI680 driver [libata] Add PATA driver for Compaq Triflex [libata] Add PATA VIA driver. [libata] Add driver for PATA AMD/NVIDIA chips. libata: Update the AMD driver to support the AMD CS5536. libata: Add enablebits support to the triflex driver libata: Add enablebits to via driver [libata] Add new PATA driver pata_opti libata: AMD pata fixes libata: Fix opti pci enable bits as with the AMD bug libata: Fix enable bits for triflex libata: Clean up and fix the VIA PATA libata driver Albert Lee: [libata] add driver for Promise PATA 2027x libata-dev-2.6: pdc2027x add ata_scsi_ioctl libata-dev-2.6: pdc2027x change comments libata-dev-2.6: pdc2027x move the PLL counter reading code libata-dev-2.6: pdc2027x PLL input clock detection fix libata-dev: Convert pdc2027x from PIO to MMIO libata-dev: pdc2027x use "long" for counter data type libata-dev: pdc2027x ATAPI DMA lost irq problem workaround libata: interrupt driven pio for libata-core libata: interrupt driven pio for LLD libata irq-pio: add comments and cleanup libata irq-pio: rename atapi_packet_task() and comments libata irq-pio: simplify if condition in ata_dataout_task() libata irq-pio: cleanup ata_qc_issue_prot() libata: move atapi_send_cdb() and ata_dataout_task() [libata irq-pio] reorganize ata_pio_sector() and __atapi_pio_bytes() [libata irq-pio] reorganize "buf + offset" in ata_pio_sector() [libata irq-pio] use PageHighMem() to optimize the kmap_atomic() usage libata CHS: LBA28/LBA48 optimization (revise #6) libata irq-pio: misc fixes libata irq-pio: merge the ata_dataout_task workqueue with ata_pio_task workqueue libata irq-pio: eliminate unnecessary queuing in ata_pio_first_block() libata irq-pio: add read/write multiple support libata: pata_pdc2027x minor fix Erik Benada: [libata sata_promise] support PATA ports on SATA controllers Jeff Garzik: [libata] pata_pdc2027x: update for recent ->host_stop() API changes [libata pata_pdc2027x] add documentation ref in header; trim trailing whitespace [libata irq-pio] build fix [libata pdc_adma] update for removal of ATA_FLAG_NOINTR [libata pata_sil680] add to Makefile/Kconfig libata: Add makefile rules for pata_via driver. [libata pdc_adma] fix for new irq-driven PIO code [libata] minor updates to PATA drivers [libata] constify PCI tables in PATA drivers [libata] remove two unused fields from struct ata_port [libata ata_piix] cleanup: remove duplicate ata_port_info records [libata sata_mv] IRQ PIO build fix [libata pata_via] fix warning [libata] Print out SATA speed, if link is up [libata sata_promise] minor whitespace cleanup drivers/scsi/Kconfig | 52 ++ drivers/scsi/Makefile | 6 drivers/scsi/ata_piix.c | 40 -- drivers/scsi/libata-core.c | 571 +++++++++++++++++++++------- drivers/scsi/libata-scsi.c | 48 +- drivers/scsi/pata_amd.c | 644 ++++++++++++++++++++++++++++++++ drivers/scsi/pata_opti.c | 267 +++++++++++++ drivers/scsi/pata_pdc2027x.c | 855 +++++++++++++++++++++++++++++++++++++++++++ drivers/scsi/pata_sil680.c | 361 ++++++++++++++++++ drivers/scsi/pata_triflex.c | 267 +++++++++++++ drivers/scsi/pata_via.c | 511 +++++++++++++++++++++++++ drivers/scsi/pdc_adma.c | 8 drivers/scsi/sata_mv.c | 8 drivers/scsi/sata_nv.c | 4 drivers/scsi/sata_promise.c | 67 ++- drivers/scsi/sata_qstor.c | 11 drivers/scsi/sata_sx4.c | 7 drivers/scsi/sata_vsc.c | 6 include/linux/ata.h | 23 + include/linux/libata.h | 32 - include/linux/pci_ids.h | 8 21 files changed, 3539 insertions(+), 257 deletions(-) - 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 From htejun@gmail.com Thu Dec 1 03:20:15 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 03:20:24 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932148AbVLALUW (ORCPT ); Thu, 1 Dec 2005 06:20:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932153AbVLALUW (ORCPT ); Thu, 1 Dec 2005 06:20:22 -0500 Received: from zproxy.gmail.com ([64.233.162.201]:38065 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S932148AbVLALUW (ORCPT ); Thu, 1 Dec 2005 06:20:22 -0500 Received: by zproxy.gmail.com with SMTP id 14so270078nzn for ; Thu, 01 Dec 2005 03:20:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=LoIT8QEPRaOCcRzTpVHy0SQZveT6ygCfjj1qaa4rMSb1U/iRxKxcoK4aYMvKklSlALbYGwNnR4owNK8SXpNX1y0pRG5m+fe/+BG1yH6hDM87e3vZliVWGuD7NZq9PqaadRaLYsbC+vU/BY1670jzQZUPXsaEJdbUEunRBH09bf0= Received: by 10.37.22.8 with SMTP id z8mr1394686nzi; Thu, 01 Dec 2005 03:20:20 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id j4sm742489nzd.2005.12.01.03.20.18; Thu, 01 Dec 2005 03:20:19 -0800 (PST) Received: by htj.dyndns.org (Postfix, from userid 1000) id 8E00018611E; Thu, 1 Dec 2005 20:20:15 +0900 (KST) Date: Thu, 1 Dec 2005 20:20:15 +0900 From: Tejun Heo To: Jean-Fran?ois Stenuit Cc: Keith Mannthey , "0602@eq.cz" <0602@eq.cz>, Linux-ide Subject: Re: totally random "VFS: Cannot open root device" Message-ID: <20051201112015.GA10462@htj.dyndns.org> References: <438B6E05.8070009@eq.cz> <438D2C19.3030008@gmail.com> <438DA3FA.2010809@eq.cz> <438EC502.1090103@keytradebank.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438EC502.1090103@keytradebank.com> User-Agent: Mutt/1.5.11 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 167 On Thu, Dec 01, 2005 at 10:40:18AM +0100, Jean-Fran?ois Stenuit wrote: > > Hi Keith, > > I have been able to reproduce the bug (randomly - needing a few reboots > to make it happen) on a 2.6.15-rc3 kernel. > > System is an HP DL140G2 with following SATA controller (from lspci -vv) : > > 0000:00:1f.2 IDE interface: Intel Corp. 82801EB (ICH5) Serial ATA 150 > Storage Controller (rev 02) (prog-if 8a [Master SecP PriP]) > Subsystem: Hewlett-Packard Company: Unknown device 3208 > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 0 > Interrupt: pin A routed to IRQ 17 > Region 0: I/O ports at > Region 1: I/O ports at > Region 2: I/O ports at > Region 3: I/O ports at > Region 4: I/O ports at 1470 [size=16] Hi, Can you try the following patch? It adds a module parameter override_PCS. If your piix module is built into the kernel, adding the following to the kernel paramter shoudl work. ata_piix.override_PCS=n Where, n is one of 0: normal behavior 1: ignore PCS and always try to probe ports 2: overwrite PCS such that all ENABLED bits are 1 First, try with override_PCS=0 and make not of the printed combined and orig_mask values on success and failure cases. Then, try with override_PCS=1, if it also fails, try with override_PCS=2. You can tell if an override option works or not by comparing the combined and orig_mask value to the failure case. If the machine boots successfully with the same combined/orig_mask values as the failure case, it means that the override option works. BTW, all these are based on the previous message in which you said that when boot failed the kernel printed the following log message. "ata1: SATA port has no device." Right? diff --git a/drivers/scsi/ata_piix.c b/drivers/scsi/ata_piix.c index 887b2b9..639da80 100644 --- a/drivers/scsi/ata_piix.c +++ b/drivers/scsi/ata_piix.c @@ -340,6 +340,9 @@ static void piix_pata_phy_reset(struct a ata_bus_reset(ap); } +static int override_PCS; +module_param(override_PCS, int, 0700); + /** * piix_sata_probe - Probe PCI device for present SATA devices * @ap: Port associated with the PCI device we wish to probe @@ -367,6 +370,17 @@ static int piix_sata_probe (struct ata_p pci_read_config_byte(pdev, ICH5_PCS, &pcs); orig_mask = (int) pcs & 0xff; + printk("ata%u: combined=%d orig_mask=0x%x\n", ap->id, combined, orig_mask); + + switch (override_PCS) { + case 1: + printk("ata%u: ignoring PCS\n", ap->id); + return 1; + case 2: + printk("ata%u: turning on PCS ENABLED bits\n", ap->id); + pci_write_config_byte(pdev, ICH5_PCS, 0x0f); + return 1; + } /* TODO: this is vaguely wrong for ICH6 combined mode, * where only two of the four SATA ports are mapped - 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 From jfs@keytradebank.com Thu Dec 1 03:20:29 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 03:20:46 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932153AbVLALUo (ORCPT ); Thu, 1 Dec 2005 06:20:44 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932154AbVLALUo (ORCPT ); Thu, 1 Dec 2005 06:20:44 -0500 Received: from mail114.messagelabs.com ([195.245.231.163]:14252 "HELO mail114.messagelabs.com") by vger.kernel.org with SMTP id S932153AbVLALUn (ORCPT ); Thu, 1 Dec 2005 06:20:43 -0500 X-VirusChecked: Checked X-Env-Sender: jfs@keytradebank.com X-Msg-Ref: server-14.tower-114.messagelabs.com!1133436038!26266363!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [62.72.98.157] Received: (qmail 30066 invoked from network); 1 Dec 2005 11:20:38 -0000 Received: from mail.keytradebank.com (HELO mail.keytradebank.com) (62.72.98.157) by server-14.tower-114.messagelabs.com with SMTP; 1 Dec 2005 11:20:38 -0000 Received: by mail.keytradebank.com (Postfix, from userid 1002) id B2AE37C5972; Thu, 1 Dec 2005 12:20:37 +0100 (CET) Received: from [192.168.201.144] (jfs.it.keytrade.com [192.168.201.144]) by mail.keytradebank.com (Postfix) with ESMTP id 787017C589D; Thu, 1 Dec 2005 12:20:37 +0100 (CET) Message-ID: <438EDC7D.2020704@keytradebank.com> Date: Thu, 01 Dec 2005 12:20:29 +0100 From: =?ISO-8859-2?Q?Jean-Fran=E7ois_Stenuit?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux-ide Cc: Tejun Heo , "0602@eq.cz" <0602@eq.cz> Subject: Re: totally random "VFS: Cannot open root device" References: <438B6E05.8070009@eq.cz> <438D2C19.3030008@gmail.com> <438D6B73.2060902@keytradebank.com> In-Reply-To: <438D6B73.2060902@keytradebank.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070905060905020000010706" X-Disclaimer: Please visit http://www.keytradebank.com/maildisclamer.html Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 168 This is a cryptographically signed message in MIME format. --------------ms070905060905020000010706 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable Jean-Fran=E7ois Stenuit wrote: > A failed boot shows "ata1: SATA port has no device". I'll try to=20 > set-up a serial console to log the boot messages. As promised, here is the complete bootlog of a failed, then a=20 successfull boot : GNU GRUB version 0.95 (622K lower / 1046976K upper memory) +------------------------------------------------------------------------= -+||||||||||||||||||||||||+----------------------------------------------= ---------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line. Debian GNU/Lin= ux, kernel 2.6.15-rc3-dl140-10 Debian GNU/Lin= ux, kernel 2.6.15-rc3-dl140-10 (recovery mode) Debian GNU/Lin= ux, kernel 2.6.15-rc3-dl140-9 Debian GNU/Lin= ux, kernel 2.6.15-rc3-dl140-9 (recovery mode) = = = = = = = = The highlighte= d entry will be booted automatically in 5 seconds. The highlighted ent= ry will be booted automatically in 4 seconds. The highlighted entry wi= ll be booted automatically in 3 seconds. The highlighted entry will be= booted automatically in 2 seconds. The highlighted entry will be boot= ed automatically in 1 seconds. Booting 'Debian GNU/Linux, kernel 2.6= =2E15-rc3-dl140-10 ' root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel /boot/vmlinuz-2.6.15-rc3-dl140-10 root=3D/dev/sda1 ro console=3Dt= tyS0,9600n8 [Linux-bzImage, setup=3D0x1c00, size=3D0x1a817b] savedefault boot Linux version 2.6.15-rc3-dl140-10 (jfs@dl140) (gcc version 3.3.5 (Debian = 1:3.3.5-13)) #1 SMP Thu Dec 1 11:44:28 CET 2005 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009b800 (usable) BIOS-e820: 000000000009b800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000ca000 - 00000000000cc000 (reserved) BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000003ff70000 (usable) BIOS-e820: 000000003ff70000 - 000000003ff7a000 (ACPI data) BIOS-e820: 000000003ff7a000 - 000000003ff80000 (ACPI NVS) BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved) BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved) BIOS-e820: 00000000fffffc00 - 0000000100000000 (reserved) 127MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000f6790 DMI present. ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 15:4 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 ACPI: IOAPIC (id[0x03] address[0xfec84000] gsi_base[24]) IOAPIC[1]: apic_id 3, version 32, address 0xfec84000, GSI 24-47 ACPI: IOAPIC (id[0x04] address[0xfec84400] gsi_base[48]) IOAPIC[2]: apic_id 4, version 32, address 0xfec84400, GSI 48-71 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Enabling APIC mode: Flat. Using 3 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 50000000 (gap: 40000000:a0000000) Built 1 zonelists Kernel command line: root=3D/dev/sda1 ro console=3DttyS0,9600n8 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 2800.863 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1034136k/1048000k available (2098k kernel code, 12972k reserved, = 1222k data, 204k init, 130496k highmem) Checking if this processor honours the WP bit even in supervisor mode... = Ok. Calibrating delay using timer specific routine.. 5608.53 BogoMIPS (lpj=3D= 11217073) Mount-cache hash table entries: 512 monitor/mwait feature present. using mwait in idle threads. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU: Physical Processor ID: 0 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel(R) Xeon(TM) CPU 2.80GHz stepping 01 Booting processor 1/1 eip 2000 Initializing CPU#1 Calibrating delay using timer specific routine.. 5600.62 BogoMIPS (lpj=3D= 11201255) monitor/mwait feature present. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU: Physical Processor ID: 0 CPU1: Intel(R) Xeon(TM) CPU 2.80GHz stepping 01 Total of 2 processors activated (11209.16 BogoMIPS). ENABLING IO-APIC IRQs =2E.TIMER: vector=3D0x31 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1 checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfd83a, last bus=3D7 PCI: Using MMCONFIG ACPI: Subsystem revision 20050902 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (0000:00) PCI quirk: region 1000-107f claimed by ICH4 ACPI/GPIO/TCO PCI quirk: region 1180-11bf claimed by ICH4 GPIO PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.2 PCI: PXH quirk detected, disabling MSI for SHPC device PCI: PXH quirk detected, disabling MSI for SHPC device PCI: Transparent bridge - 0000:00:1e.0 ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 6 7 10 11 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 14 15) *0, disabled= =2E ACPI: PCI Interrupt Link [LNKF] (IRQs 4 5 6 7 10 11 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 14 15) *0, disabled= =2E ACPI: PCI Interrupt Link [LNKH] (IRQs 4 5 6 7 10 *11 14 15) SCSI subsystem initialized PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=3Drouteirq". If it helps, post a= report TC classifier action (bugs to netdev@vger.kernel.org cc hadi@cyberus.ca) PCI: Bridge: 0000:00:02.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:04.0 IO window: disabled. MEM window: dd100000-dd1fffff PREFETCH window: disabled. PCI: Bridge: 0000:00:05.0 IO window: disabled. MEM window: dd200000-dd2fffff PREFETCH window: disabled. PCI: Bridge: 0000:04:00.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:04:00.2 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:06.0 IO window: disabled. MEM window: dd300000-dd3fffff PREFETCH window: disabled. PCI: Bridge: 0000:00:1e.0 IO window: 2000-2fff MEM window: dd400000-deffffff PREFETCH window: 50000000-500fffff ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16 ACPI: PCI Interrupt 0000:00:04.0[A] -> GSI 16 (level, low) -> IRQ 16 ACPI: PCI Interrupt 0000:00:05.0[A] -> GSI 16 (level, low) -> IRQ 16 ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 16 (level, low) -> IRQ 16 Simple Boot Flag at 0x3b set to 0x1 highmem bounce pool size: 64 pages Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered pci_hotplug: PCI Hot Plug PCI Core version: 0.5 shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 ACPI: Power Button (FF) [PWRF] ACPI: Power Button (CM) [PWRB] ACPI: Processor [CPU0] (supports 8 throttling states) ACPI: Processor [CPU1] (supports 8 throttling states) Real Time Clock Driver v1.12 serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled= serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize loop: loaded (max 8 devices) Intel(R) PRO/1000 Network Driver - version 6.1.16-k2-NAPI Copyright (c) 1999-2005 Intel Corporation. Ethernet Channel Bonding Driver: v2.6.5 (November 4, 2005) bonding: Warning: either miimon or arp_interval and arp_ip_target module = parameters must be specified, otherwise bonding will not detect link fail= ures! see bonding.txt for details. tg3.c:v3.43 (Oct 24, 2005) ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 16 eth0: Tigon3 [partno(BCM95721) rev 4101 PHY(5750)] (PCI Express) 10/100/1= 000BaseT Ethernet 00:14:c2:54:b4:b6 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOc= ap[1]=20 eth0: dma_rwctrl[76180000] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 16 (level, low) -> IRQ 16 eth1: Tigon3 [partno(BCM95721) rev 4101 PHY(5750)] (PCI Express) 10/100/1= 000BaseT Ethernet 00:14:c2:54:b4:b7 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOc= ap[1]=20 eth1: dma_rwctrl[76180000] Equalizer2002: Simon Janes (simon@ncm.com) and David S. Miller (davem@red= hat.com) tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 17 ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1470 irq 14 ata1: SATA port has no device. scsi0 : ata_piix ata2: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x1478 irq 15 ata2: SATA port has no device. scsi1 : ata_piix mice: PS/2 mouse device common for all mice Mirror/redirect action on netem: version 1.1 u32 classifier Perfomance counters on input device check on=20 Actions configured=20 NET: Registered protocol family 2 input: AT Translated Set 2 keyboard as /class/input/input0 IP route cache hash table entries: 65536 (order: 6, 262144 bytes) TCP established hash table entries: 262144 (order: 9, 2097152 bytes) TCP bind hash table entries: 65536 (order: 7, 524288 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP reno registered ip_conntrack version 2.4 (8187 buckets, 65496 max) - 212 bytes per conntr= ack ip_tables: (C) 2000-2002 Netfilter core team logips2pp: Detected unknown logitech mouse model 1 input: PS/2 Logitech Mouse as /class/input/input1 ipt_recent v0.3.1: Stephen Frost . http://snowman.ne= t/projects/ipt_recent/ TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 802.1Q VLAN Support v1.8 Ben Greear All bugs added by David S. Miller Starting balanced_irq Using IPI Shortcut mode VFS: Cannot open root device "sda1" or unknown-block(0,0) Please append a correct "root=3D" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block= (0,0) =20 GNU GRUB version 0.95 (622K lower / 1046976K upper memory) +------------------------------------------------------------------------= -+||||||||||||||||||||||||+----------------------------------------------= ---------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line. Debian GNU/Lin= ux, kernel 2.6.15-rc3-dl140-10 Debian GNU/Lin= ux, kernel 2.6.15-rc3-dl140-10 (recovery mode) Debian GNU/Lin= ux, kernel 2.6.15-rc3-dl140-9 Debian GNU/Lin= ux, kernel 2.6.15-rc3-dl140-9 (recovery mode) = = = = = = = = The highlighte= d entry will be booted automatically in 5 seconds. The highlighted ent= ry will be booted automatically in 4 seconds. The highlighted entry wi= ll be booted automatically in 3 seconds. The highlighted entry will be= booted automatically in 2 seconds. The highlighted entry will be boot= ed automatically in 1 seconds. Booting 'Debian GNU/Linux, kernel 2.6= =2E15-rc3-dl140-10 ' root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel /boot/vmlinuz-2.6.15-rc3-dl140-10 root=3D/dev/sda1 ro console=3Dt= tyS0,9600n8 [Linux-bzImage, setup=3D0x1c00, size=3D0x1a817b] savedefault boot Linux version 2.6.15-rc3-dl140-10 (jfs@dl140) (gcc version 3.3.5 (Debian = 1:3.3.5-13)) #1 SMP Thu Dec 1 11:44:28 CET 2005 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009b800 (usable) BIOS-e820: 000000000009b800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000ca000 - 00000000000cc000 (reserved) BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000003ff70000 (usable) BIOS-e820: 000000003ff70000 - 000000003ff7a000 (ACPI data) BIOS-e820: 000000003ff7a000 - 000000003ff80000 (ACPI NVS) BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved) BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved) BIOS-e820: 00000000fffffc00 - 0000000100000000 (reserved) 127MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000f6790 DMI present. ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 15:4 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 ACPI: IOAPIC (id[0x03] address[0xfec84000] gsi_base[24]) IOAPIC[1]: apic_id 3, version 32, address 0xfec84000, GSI 24-47 ACPI: IOAPIC (id[0x04] address[0xfec84400] gsi_base[48]) IOAPIC[2]: apic_id 4, version 32, address 0xfec84400, GSI 48-71 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Enabling APIC mode: Flat. Using 3 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 50000000 (gap: 40000000:a0000000) Built 1 zonelists Kernel command line: root=3D/dev/sda1 ro console=3DttyS0,9600n8 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 2800.704 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1034136k/1048000k available (2098k kernel code, 12972k reserved, = 1222k data, 204k init, 130496k highmem) Checking if this processor honours the WP bit even in supervisor mode... = Ok. Calibrating delay using timer specific routine.. 5608.50 BogoMIPS (lpj=3D= 11217008) Mount-cache hash table entries: 512 monitor/mwait feature present. using mwait in idle threads. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU: Physical Processor ID: 0 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel(R) Xeon(TM) CPU 2.80GHz stepping 01 Booting processor 1/1 eip 2000 Initializing CPU#1 Calibrating delay using timer specific routine.. 5600.65 BogoMIPS (lpj=3D= 11201307) monitor/mwait feature present. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU: Physical Processor ID: 0 CPU1: Intel(R) Xeon(TM) CPU 2.80GHz stepping 01 Total of 2 processors activated (11209.15 BogoMIPS). ENABLING IO-APIC IRQs =2E.TIMER: vector=3D0x31 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1 checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfd83a, last bus=3D7 PCI: Using MMCONFIG ACPI: Subsystem revision 20050902 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (0000:00) PCI quirk: region 1000-107f claimed by ICH4 ACPI/GPIO/TCO PCI quirk: region 1180-11bf claimed by ICH4 GPIO PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.2 PCI: PXH quirk detected, disabling MSI for SHPC device PCI: PXH quirk detected, disabling MSI for SHPC device PCI: Transparent bridge - 0000:00:1e.0 ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 6 7 10 11 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *10 11 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 14 15) *0, disabled= =2E ACPI: PCI Interrupt Link [LNKF] (IRQs 4 5 6 7 10 11 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 14 15) *0, disabled= =2E ACPI: PCI Interrupt Link [LNKH] (IRQs 4 5 6 7 10 *11 14 15) SCSI subsystem initialized PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=3Drouteirq". If it helps, post a= report TC classifier action (bugs to netdev@vger.kernel.org cc hadi@cyberus.ca) PCI: Bridge: 0000:00:02.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:04.0 IO window: disabled. MEM window: dd100000-dd1fffff PREFETCH window: disabled. PCI: Bridge: 0000:00:05.0 IO window: disabled. MEM window: dd200000-dd2fffff PREFETCH window: disabled. PCI: Bridge: 0000:04:00.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:04:00.2 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:06.0 IO window: disabled. MEM window: dd300000-dd3fffff PREFETCH window: disabled. PCI: Bridge: 0000:00:1e.0 IO window: 2000-2fff MEM window: dd400000-deffffff PREFETCH window: 50000000-500fffff ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16 ACPI: PCI Interrupt 0000:00:04.0[A] -> GSI 16 (level, low) -> IRQ 16 ACPI: PCI Interrupt 0000:00:05.0[A] -> GSI 16 (level, low) -> IRQ 16 ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 16 (level, low) -> IRQ 16 Simple Boot Flag at 0x3b set to 0x1 highmem bounce pool size: 64 pages Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered pci_hotplug: PCI Hot Plug PCI Core version: 0.5 shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 ACPI: Power Button (FF) [PWRF] ACPI: Power Button (CM) [PWRB] ACPI: Processor [CPU0] (supports 8 throttling states) ACPI: Processor [CPU1] (supports 8 throttling states) Real Time Clock Driver v1.12 serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled= serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize loop: loaded (max 8 devices) Intel(R) PRO/1000 Network Driver - version 6.1.16-k2-NAPI Copyright (c) 1999-2005 Intel Corporation. Ethernet Channel Bonding Driver: v2.6.5 (November 4, 2005) bonding: Warning: either miimon or arp_interval and arp_ip_target module = parameters must be specified, otherwise bonding will not detect link fail= ures! see bonding.txt for details. tg3.c:v3.43 (Oct 24, 2005) ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 16 eth0: Tigon3 [partno(BCM95721) rev 4101 PHY(5750)] (PCI Express) 10/100/1= 000BaseT Ethernet 00:14:c2:54:b4:b6 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOc= ap[1]=20 eth0: dma_rwctrl[76180000] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 16 (level, low) -> IRQ 16 eth1: Tigon3 [partno(BCM95721) rev 4101 PHY(5750)] (PCI Express) 10/100/1= 000BaseT Ethernet 00:14:c2:54:b4:b7 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOc= ap[1]=20 eth1: dma_rwctrl[76180000] Equalizer2002: Simon Janes (simon@ncm.com) and David S. Miller (davem@red= hat.com) tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 17 ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x1470 irq 14 ata1: dev 0 ATA-7, max UDMA/100, 156301488 sectors: LBA48 ata1: dev 0 configured for UDMA/100 scsi0 : ata_piix Vendor: ATA Model: Maxtor 6L080M0 Rev: BANC Type: Direct-Access ANSI SCSI revision: 05 ata2: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x1478 irq 15 ata2: SATA port has no device. scsi1 : ata_piix SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) SCSI device sda: drive cache: write through SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) SCSI device sda: drive cache: write through sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 > sd 0:0:0:0: Attached scsi disk sda mice: PS/2 mouse device common for all mice Mirror/redirect action on netem: version 1.1 u32 classifier Perfomance counters on input device check on=20 Actions configured=20 NET: Registered protocol family 2 input: AT Translated Set 2 keyboard as /class/input/input0 IP route cache hash table entries: 65536 (order: 6, 262144 bytes) TCP established hash table entries: 262144 (order: 9, 2097152 bytes) TCP bind hash table entries: 65536 (order: 7, 524288 bytes) logips2pp: Detected unknown logitech mouse model 1 input: PS/2 Logitech Mouse as /class/input/input1 TCP: Hash tables configured (established 262144 bind 65536) TCP reno registered ip_conntrack version 2.4 (8187 buckets, 65496 max) - 212 bytes per conntr= ack ip_tables: (C) 2000-2002 Netfilter core team ipt_recent v0.3.1: Stephen Frost . http://snowman.ne= t/projects/ipt_recent/ TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 802.1Q VLAN Support v1.8 Ben Greear All bugs added by David S. Miller Starting balanced_irq Using IPI Shortcut mode kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 204k freed INIT: version 2.86 booting Activating swap. Adding 2714944k swap on /dev/sda7. Priority:-1 extents:1 across:2714944k= Checking root file system... fsck 1.37 (21-Mar-2005) /: clean, 6566/136544 files, 441EXT3 FS on sda1, 68/273073 blocksinternal= journal System time was Thu Dec 1 10:55:29 UTC 2005. Setting the System Clock using the Hardware Clock as reference... System Clock set. System local time is now Thu Dec 1 10:55:31 UTC 2005. Cleaning up ifupdown...done. Checking all file systems... fsck 1.37 (21-Mar-2005) /home: clean, 22860/8372224 files, 366885/16737714 blocks /tmp: clean, 11/192768 files, 32456/393217 blocks /usr: clean, 18050/kjournald starting. Commit interval 5 seconds 610432 files, 86EXT3 FS on sda9, internal journal 948/1220932 blocEXT3-fs: mounted filesystem with ordered data mode. ks /var: clean,kjournald starting. Commit interval 5 seconds 1295/366528 filEXT3 FS on sda8, internal journal es, 40433/732957EXT3-fs: mounted filesystem with ordered data mode. blocks Setting kernel variables ... =2E.. done.kjournald starting. Commit interval 5 seconds Mounting localEXT3 FS on sda5, internal journal filesystems...EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on sda6, internal journal EXT3-fs: mounted filesystem with ordered data mode. tg3: eth0: Link is up at 100 Mbps, full duplex. tg3: eth0: Flow control is off for TX and off for RX. INIT: Entering runlevel: 2 Starting system log daemon: syslogd. Starting kernel log daemon: klogd. Starting MTA: exim4. Starting internet superserver: inetd. Starting SMP IRQ Balancer: irqbalance. Starting OpenBSD Secure Shell server: sshd. Starting deferred execution scheduler: atd. Starting periodic command scheduler: cron. --=20 Jean-Fran=E7ois "Jef" Stenuit Network & Security manager Keytrade Bank SA --------------ms070905060905020000010706 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9TCC AtUwggI+oAMCAQICAw940zANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwOTEzMTU0NDM0WhcNMDYwOTEzMTU0NDM0 WjBGMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRq ZnNAa2V5dHJhZGViYW5rLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJvF EsxKTbVcg2evoxzm3Gs2PErR2jLXLyAosTiTvopWw3HZAKTD+3rVBQKZA4ykdbC4Spk7ca05 2ENgt3naP/6bJ8gWCrgd9AQ0CRRDNuyE1A0YWjM4G8SYaKNXC+yjhrhaobmKcBQhtysQxHMo s0+SDVbNAOdYjK7rdjN+WGZQpbjJ3E8LtP4Vqv4YoA5LpyumVGq1aCcRNvHC0EbNfGi9p6R6 sIjMglPH0ZAa9YGcX9U6qz/je8ImvL/k9B7Hys8YAN8uLDol9qMKXkys7Nc2UA/V6Qy3/vME PkQ6mnx8m30a1IAHK8zxvpRSpY/SmdSGIk3PGrOwXnCazsAKyX8CAwEAAaMxMC8wHwYDVR0R BBgwFoEUamZzQGtleXRyYWRlYmFuay5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQF AAOBgQC0RNI63E0hHdNOy1ffX2Vg+qddH4vJDdtKHcYbI6B3/C8OJTCQLWRRZpOPwVQqNpVL 8OzsDYTX1ARzlzMA9H0grN5AD3hLZxSsNJj0X47SpEq8OyVPlACaKa1YAulRg5QL57gCDSGf 9xPO1nrA9sdlRG0fZLSauFLf4IOdnF7hJzCCAtUwggI+oAMCAQICAw940zANBgkqhkiG9w0B AQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcN MDUwOTEzMTU0NDM0WhcNMDYwOTEzMTU0NDM0WjBGMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1h aWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZnNAa2V5dHJhZGViYW5rLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAJvFEsxKTbVcg2evoxzm3Gs2PErR2jLXLyAosTiT vopWw3HZAKTD+3rVBQKZA4ykdbC4Spk7ca052ENgt3naP/6bJ8gWCrgd9AQ0CRRDNuyE1A0Y WjM4G8SYaKNXC+yjhrhaobmKcBQhtysQxHMos0+SDVbNAOdYjK7rdjN+WGZQpbjJ3E8LtP4V qv4YoA5LpyumVGq1aCcRNvHC0EbNfGi9p6R6sIjMglPH0ZAa9YGcX9U6qz/je8ImvL/k9B7H ys8YAN8uLDol9qMKXkys7Nc2UA/V6Qy3/vMEPkQ6mnx8m30a1IAHK8zxvpRSpY/SmdSGIk3P GrOwXnCazsAKyX8CAwEAAaMxMC8wHwYDVR0RBBgwFoEUamZzQGtleXRyYWRlYmFuay5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQC0RNI63E0hHdNOy1ffX2Vg+qddH4vJ DdtKHcYbI6B3/C8OJTCQLWRRZpOPwVQqNpVL8OzsDYTX1ARzlzMA9H0grN5AD3hLZxSsNJj0 X47SpEq8OyVPlACaKa1YAulRg5QL57gCDSGf9xPO1nrA9sdlRG0fZLSauFLf4IOdnF7hJzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDD3jTMAkGBSsOAwIaBQCgggGnMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MTIwMTExMjAyOVowIwYJ KoZIhvcNAQkEMRYEFLdZNpOkT2tqQzzAD8SVHcY1UR33MFIGCSqGSIb3DQEJDzFFMEMwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMPeNMwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDD3jTMA0GCSqGSIb3DQEBAQUA BIIBAIl2l8k3hXGYjzMW3jFzKo5+WK/Sz+X6P7DwHIxo1zliWDwPXhuAi3JFwIgvso6HzY5h nSXUbkLY/FKQoM4opiiteS9glgOc/31aAefN9/rCky+TDawhlKXVreMVKlziowhf0ajW8mYn HOq7ayBWxZHSr82ljCScIAp5pv9oqL6FJ/5mmwbVrwBAGpvn5BQYWMFRabBit5/mLM3iZ3RP M/BS017kkLMbBxteMAkcffo1AX0jtBDSKLsIj0ltrjw3mqS+AmOXefuYEQ5K0x648aYO++NR MBDWhpA9k+TsANzQCLIYnCSQImh4I/WS4k5UQc0ViqZ7Ab8lDZtAEN3RgVwAAAAAAAA= --------------ms070905060905020000010706-- - 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 From dougg@torque.net Thu Dec 1 03:35:41 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 03:34:44 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932159AbVLALeg (ORCPT ); Thu, 1 Dec 2005 06:34:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932163AbVLALeg (ORCPT ); Thu, 1 Dec 2005 06:34:36 -0500 Received: from zorg.st.net.au ([203.16.233.9]:51349 "EHLO borg.st.net.au") by vger.kernel.org with ESMTP id S932159AbVLALef (ORCPT ); Thu, 1 Dec 2005 06:34:35 -0500 Received: from localhost (localhost [127.0.0.1]) by borg.st.net.au (Postfix) with ESMTP id EF1623951E1; Thu, 1 Dec 2005 21:34:28 +1000 (EST) Received: from borg.st.net.au ([203.16.233.9]) by localhost (borg.st.net.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09867-10; Thu, 1 Dec 2005 21:34:28 +1000 (EST) Received: from [192.168.48.80] (dsl-220.131.240.220.lns02-wick-bne.dsl.comindico.com.au [220.240.131.220]) by borg.st.net.au (Postfix) with ESMTP id BA85739518C; Thu, 1 Dec 2005 21:34:22 +1000 (EST) Message-ID: <438EE00D.1030108@torque.net> Date: Thu, 01 Dec 2005 21:35:41 +1000 From: Douglas Gilbert Reply-To: dougg@torque.net User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Bottomley CC: Alan Stern , Patrick Mansfield , Matthew Dharm , thomas schorpp , USB Storage list , Timothy Thelin , Linux SCSI list , linux-ide@vger.kernel.org Subject: [PATCH] writable scsi_level [was: [Merging ATA passthru] on integrating SMART/ATA-Security in usb-storage driver] References: <1131401153.3333.6.camel@mulgrave> In-Reply-To: <1131401153.3333.6.camel@mulgrave> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/mixed; boundary="------------010609050604070309020204" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at st.net.au Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-scsi@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 179 This is a multi-part message in MIME format. --------------010609050604070309020204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit James Bottomley wrote: > On Mon, 2005-11-07 at 15:59 -0500, Alan Stern wrote: > >>>That is, is usb-storage forcing scsi-2 when the device tells us it is >>>scsi-3 compliant, or is the hardware reporting devices are scsi-2, yet >>>requiring non-LUN value in cdb[1]? >> >>I think we may have both. However I don't know how this Cypress chip >>reports itself. A system log showing the INQUIRY data would be very >>helpful. > > > We were told in prior emails that it actually reports a level of zero > (i.e. no compliance with any SCSI standard). My original proposal was > just not to modify the CDB[1] for this case if we could get the INQUIRY > passed through unmangled. > > >>It's quite possible that usb-storage no longer needs to force the >>scsi-level to 2. No one has recently tested what would happen without >>it. Matt probably has the best selection of devices for testing... >> >>There is one problem we have with devices that report themselves as SCSI-3 >>or SCSI-4 but hang when they receive a REPORT LUNS command. That's easily >>handled by making usb-storage set the NOREPORTLUN flag. Maybe that's all >>we need to do. This patch may add some flexibility. It allows /sys/class/scsi_device//device/scsi_level to be written. It won't help during scanning but will indirectly allow people to get the functionality of SG_FLAG_LUN_INHIBIT back (via writing a number greater than 3 into scsi_level). The patch is against lk 2.6.15-rc3 Changelog: - make sysfs scsi_level attribute writable - fix bug in sdev_rw_attr macro (but can't use it because scsi_device::scsi_level is a char) Signed-off-by: Douglas Gilbert Doug Gilbert --------------010609050604070309020204 Content-Type: text/x-patch; name="scsi_level_wr2615rc3.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="scsi_level_wr2615rc3.diff" --- linux/drivers/scsi/scsi_sysfs.c 2005-11-30 08:43:00.000000000 +1000 +++ linux/drivers/scsi/scsi_sysfs.c2615rc3sl 2005-12-01 21:04:40.000000000 +1000 @@ -322,7 +322,7 @@ { \ struct scsi_device *sdev; \ sdev = to_scsi_device(dev); \ - snscanf (buf, 20, format_string, &sdev->field); \ + sscanf (buf, format_string, &sdev->field); \ return count; \ } \ static DEVICE_ATTR(field, S_IRUGO | S_IWUSR, sdev_show_##field, sdev_store_##field); @@ -375,12 +375,32 @@ sdev_rd_attr (device_blocked, "%d\n"); sdev_rd_attr (queue_depth, "%d\n"); sdev_rd_attr (type, "%d\n"); -sdev_rd_attr (scsi_level, "%d\n"); sdev_rd_attr (vendor, "%.8s\n"); sdev_rd_attr (model, "%.16s\n"); sdev_rd_attr (rev, "%.4s\n"); static ssize_t +sdev_show_scsi_level (struct device *dev, struct device_attribute *attr, char *buf) +{ + struct scsi_device *sdev; + sdev = to_scsi_device(dev); + return snprintf (buf, 20, "%d\n", (int)sdev->scsi_level); +} + +static ssize_t +sdev_store_scsi_level (struct device *dev, struct device_attribute *attr, + const char *buf, size_t count) +{ + struct scsi_device *sdev; + int val; + sdev = to_scsi_device(dev); + sscanf (buf, "%d\n", &val); + sdev->scsi_level = val; + return count; +} +static DEVICE_ATTR(scsi_level, S_IRUGO | S_IWUSR, sdev_show_scsi_level, sdev_store_scsi_level); + +static ssize_t sdev_show_timeout (struct device *dev, struct device_attribute *attr, char *buf) { struct scsi_device *sdev; --------------010609050604070309020204-- - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From jfs@keytradebank.com Thu Dec 1 04:59:34 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 05:00:58 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932217AbVLAM7x (ORCPT ); Thu, 1 Dec 2005 07:59:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932213AbVLAM7x (ORCPT ); Thu, 1 Dec 2005 07:59:53 -0500 Received: from mail91.messagelabs.com ([194.106.220.35]:12210 "HELO mail91.messagelabs.com") by vger.kernel.org with SMTP id S932214AbVLAM7u (ORCPT ); Thu, 1 Dec 2005 07:59:50 -0500 X-VirusChecked: Checked X-Env-Sender: jfs@keytradebank.com X-Msg-Ref: server-3.tower-91.messagelabs.com!1133441984!15454203!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [62.72.98.157] Received: (qmail 22373 invoked from network); 1 Dec 2005 12:59:44 -0000 Received: from mail.keytradebank.com (HELO mail.keytradebank.com) (62.72.98.157) by server-3.tower-91.messagelabs.com with SMTP; 1 Dec 2005 12:59:44 -0000 Received: by mail.keytradebank.com (Postfix, from userid 1002) id C87E07C58D5; Thu, 1 Dec 2005 13:59:42 +0100 (CET) Received: from [192.168.201.144] (jfs.it.keytrade.com [192.168.201.144]) by mail.keytradebank.com (Postfix) with ESMTP id 982CE7C58B4; Thu, 1 Dec 2005 13:59:42 +0100 (CET) Message-ID: <438EF3B6.7020007@keytradebank.com> Date: Thu, 01 Dec 2005 13:59:34 +0100 From: =?ISO-8859-1?Q?Jean-Fran=E7ois_Stenuit?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tejun Heo Cc: Keith Mannthey , "0602@eq.cz" <0602@eq.cz>, Linux-ide Subject: Re: totally random "VFS: Cannot open root device" References: <438B6E05.8070009@eq.cz> <438D2C19.3030008@gmail.com> <438DA3FA.2010809@eq.cz> <438EC502.1090103@keytradebank.com> <20051201112015.GA10462@htj.dyndns.org> In-Reply-To: <20051201112015.GA10462@htj.dyndns.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080403000103030004030009" X-Disclaimer: Please visit http://www.keytradebank.com/maildisclamer.html Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 224 This is a cryptographically signed message in MIME format. --------------ms080403000103030004030009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Tejun, Thanks for taking the time to check. Output of your trace with ata_piix.override_PCS=0 1st boot : success : combined=0 orig_mask=0x11 2nd boot : success : combined=0 orig_mask=0x11 3rd boot : failure : combined=0 orig_mask=0x0 4th boot : failure : combined=0 orig_mask=0x0 5th boot : failure : combined=0 orig_mask=0x0 6th boot : failure : combined=0 orig_mask=0x0 7th boot : success : combined=0 orig_mask=0x11 Output of your trace with ata_piix.override_PCS=1 1st boot : success : combined=0 orig_mask=0x0 2nd boot : success : combined=0 orig_mask=0x0 3rd boot : success : combined=0 orig_mask=0x0 4th boot : success : combined=0 orig_mask=0x0 5th boot : success : combined=0 orig_mask=0x0 6th boot : success : combined=0 orig_mask=0x0 7th boot : success : combined=0 orig_mask=0x0 8th boot : success : combined=0 orig_mask=0x0 Looks like you have found a fix/workaround for this bug (but it still does not give the reason why it's failing). Tejun Heo wrote: >On Thu, Dec 01, 2005 at 10:40:18AM +0100, Jean-Fran?ois Stenuit wrote: > > >>Hi Keith, >> >>I have been able to reproduce the bug (randomly - needing a few reboots >>to make it happen) on a 2.6.15-rc3 kernel. >> >>System is an HP DL140G2 with following SATA controller (from lspci -vv) : >> >>0000:00:1f.2 IDE interface: Intel Corp. 82801EB (ICH5) Serial ATA 150 >>Storage Controller (rev 02) (prog-if 8a [Master SecP PriP]) >> Subsystem: Hewlett-Packard Company: Unknown device 3208 >> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- >>ParErr- Stepping- SERR- FastB2B- >> Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- >>SERR- > Latency: 0 >> Interrupt: pin A routed to IRQ 17 >> Region 0: I/O ports at >> Region 1: I/O ports at >> Region 2: I/O ports at >> Region 3: I/O ports at >> Region 4: I/O ports at 1470 [size=16] >> >> > >Hi, > >Can you try the following patch? It adds a module parameter >override_PCS. If your piix module is built into the kernel, adding >the following to the kernel paramter shoudl work. > >ata_piix.override_PCS=n > >Where, n is one of > >0: normal behavior >1: ignore PCS and always try to probe ports >2: overwrite PCS such that all ENABLED bits are 1 > >First, try with override_PCS=0 and make not of the printed combined >and orig_mask values on success and failure cases. Then, try with >override_PCS=1, if it also fails, try with override_PCS=2. > >You can tell if an override option works or not by comparing the >combined and orig_mask value to the failure case. If the machine >boots successfully with the same combined/orig_mask values as the >failure case, it means that the override option works. > >BTW, all these are based on the previous message in which you said >that when boot failed the kernel printed the following log message. > >"ata1: SATA port has no device." > >Right? > > >diff --git a/drivers/scsi/ata_piix.c b/drivers/scsi/ata_piix.c >index 887b2b9..639da80 100644 >--- a/drivers/scsi/ata_piix.c >+++ b/drivers/scsi/ata_piix.c >@@ -340,6 +340,9 @@ static void piix_pata_phy_reset(struct a > ata_bus_reset(ap); > } > >+static int override_PCS; >+module_param(override_PCS, int, 0700); >+ > /** > * piix_sata_probe - Probe PCI device for present SATA devices > * @ap: Port associated with the PCI device we wish to probe >@@ -367,6 +370,17 @@ static int piix_sata_probe (struct ata_p > > pci_read_config_byte(pdev, ICH5_PCS, &pcs); > orig_mask = (int) pcs & 0xff; >+ printk("ata%u: combined=%d orig_mask=0x%x\n", ap->id, combined, orig_mask); >+ >+ switch (override_PCS) { >+ case 1: >+ printk("ata%u: ignoring PCS\n", ap->id); >+ return 1; >+ case 2: >+ printk("ata%u: turning on PCS ENABLED bits\n", ap->id); >+ pci_write_config_byte(pdev, ICH5_PCS, 0x0f); >+ return 1; >+ } > > /* TODO: this is vaguely wrong for ICH6 combined mode, > * where only two of the four SATA ports are mapped > > > -- Jean-François "Jef" Stenuit Network & Security manager Keytrade Bank SA --------------ms080403000103030004030009 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9TCC AtUwggI+oAMCAQICAw940zANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwOTEzMTU0NDM0WhcNMDYwOTEzMTU0NDM0 WjBGMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRq ZnNAa2V5dHJhZGViYW5rLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJvF EsxKTbVcg2evoxzm3Gs2PErR2jLXLyAosTiTvopWw3HZAKTD+3rVBQKZA4ykdbC4Spk7ca05 2ENgt3naP/6bJ8gWCrgd9AQ0CRRDNuyE1A0YWjM4G8SYaKNXC+yjhrhaobmKcBQhtysQxHMo s0+SDVbNAOdYjK7rdjN+WGZQpbjJ3E8LtP4Vqv4YoA5LpyumVGq1aCcRNvHC0EbNfGi9p6R6 sIjMglPH0ZAa9YGcX9U6qz/je8ImvL/k9B7Hys8YAN8uLDol9qMKXkys7Nc2UA/V6Qy3/vME PkQ6mnx8m30a1IAHK8zxvpRSpY/SmdSGIk3PGrOwXnCazsAKyX8CAwEAAaMxMC8wHwYDVR0R BBgwFoEUamZzQGtleXRyYWRlYmFuay5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQF AAOBgQC0RNI63E0hHdNOy1ffX2Vg+qddH4vJDdtKHcYbI6B3/C8OJTCQLWRRZpOPwVQqNpVL 8OzsDYTX1ARzlzMA9H0grN5AD3hLZxSsNJj0X47SpEq8OyVPlACaKa1YAulRg5QL57gCDSGf 9xPO1nrA9sdlRG0fZLSauFLf4IOdnF7hJzCCAtUwggI+oAMCAQICAw940zANBgkqhkiG9w0B AQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcN MDUwOTEzMTU0NDM0WhcNMDYwOTEzMTU0NDM0WjBGMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1h aWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZnNAa2V5dHJhZGViYW5rLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAJvFEsxKTbVcg2evoxzm3Gs2PErR2jLXLyAosTiT vopWw3HZAKTD+3rVBQKZA4ykdbC4Spk7ca052ENgt3naP/6bJ8gWCrgd9AQ0CRRDNuyE1A0Y WjM4G8SYaKNXC+yjhrhaobmKcBQhtysQxHMos0+SDVbNAOdYjK7rdjN+WGZQpbjJ3E8LtP4V qv4YoA5LpyumVGq1aCcRNvHC0EbNfGi9p6R6sIjMglPH0ZAa9YGcX9U6qz/je8ImvL/k9B7H ys8YAN8uLDol9qMKXkys7Nc2UA/V6Qy3/vMEPkQ6mnx8m30a1IAHK8zxvpRSpY/SmdSGIk3P GrOwXnCazsAKyX8CAwEAAaMxMC8wHwYDVR0RBBgwFoEUamZzQGtleXRyYWRlYmFuay5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQC0RNI63E0hHdNOy1ffX2Vg+qddH4vJ DdtKHcYbI6B3/C8OJTCQLWRRZpOPwVQqNpVL8OzsDYTX1ARzlzMA9H0grN5AD3hLZxSsNJj0 X47SpEq8OyVPlACaKa1YAulRg5QL57gCDSGf9xPO1nrA9sdlRG0fZLSauFLf4IOdnF7hJzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDD3jTMAkGBSsOAwIaBQCgggGnMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MTIwMTEyNTkzNFowIwYJ KoZIhvcNAQkEMRYEFC7s8CZHm3ZqAA8xc9TOm7rwkZaTMFIGCSqGSIb3DQEJDzFFMEMwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMPeNMwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDD3jTMA0GCSqGSIb3DQEBAQUA BIIBAAf5fQGphT1U5IpoWWVKeQY2yzcY+KLvWNZPlToUo4D+wOlvFe8kDIKjWB/3JVu7TZzS cyyHDMWcd9dtdZbfm+JwxtaGzxXcIoLkXP9qe5l871wfFbXhFSmDBQrB/S9vqj+ZXEeh12Xr qAbpxgX+4XdcmDizq2F7cubaU4LbPQq0rbLypa6iJU+VwbNmsCTRaWLNGk7KZvENmXhSFKvG Y0Zd8LlzuVvtWTl8/J8TkR3oMfbzzlwf34EA0LJyFqDtnHYkdVmbPhJu73a36wSBCdxo0Oom Cxq8RicfGv1eejJbBAjEkL8vcyBJ+ptaVC0QNdd1R2yVA1IislG4HUh/Z8YAAAAAAAA= --------------ms080403000103030004030009-- - 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 From htejun@gmail.com Thu Dec 1 05:29:09 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 05:29:16 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932213AbVLAN3P convert rfc822-to-quoted-printable (ORCPT ); Thu, 1 Dec 2005 08:29:15 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932225AbVLAN3P (ORCPT ); Thu, 1 Dec 2005 08:29:15 -0500 Received: from zproxy.gmail.com ([64.233.162.202]:60504 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S932213AbVLAN3O (ORCPT ); Thu, 1 Dec 2005 08:29:14 -0500 Received: by zproxy.gmail.com with SMTP id 13so60895nzn for ; Thu, 01 Dec 2005 05:29:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=M6c7FFGCbGy1rCwutyRZSXLtNR/aQYBGzANIJSJbTmVDcagAuDOGckdl2PJhXavYAk32LuXyHIuWoVKhieDufIFbM4wvf6G7yhrCl5VPm2nz9Sq5mFuhtDHqXwfjoVfKmFxTEookYNAPw9sSbx0FiPQPawdAZ+NmEgO884oCWiw= Received: by 10.36.220.33 with SMTP id s33mr1531401nzg; Thu, 01 Dec 2005 05:29:13 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id c12sm1482999nzc.2005.12.01.05.29.12; Thu, 01 Dec 2005 05:29:13 -0800 (PST) Received: from [127.0.0.1] (htj.dyndns.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by htj.dyndns.org (Postfix) with ESMTP id 8B58E18604D; Thu, 1 Dec 2005 22:29:09 +0900 (KST) Message-ID: <438EFAA5.3070901@gmail.com> Date: Thu, 01 Dec 2005 22:29:09 +0900 From: Tejun Heo User-Agent: Debian Thunderbird 1.0.7 (X11/20051019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jean-Fran=E7ois_Stenuit?= CC: Keith Mannthey , "0602@eq.cz" <0602@eq.cz>, Linux-ide , Jeff Garzik Subject: Re: totally random "VFS: Cannot open root device" References: <438B6E05.8070009@eq.cz> <438D2C19.3030008@gmail.com> <438DA3FA.2010809@eq.cz> <438EC502.1090103@keytradebank.com> <20051201112015.GA10462@htj.dyndns.org> <438EF3B6.7020007@keytradebank.com> In-Reply-To: <438EF3B6.7020007@keytradebank.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 244 Jean-Fran=E7ois Stenuit wrote: > Hi Tejun, >=20 > Thanks for taking the time to check. >=20 > Output of your trace with ata_piix.override_PCS=3D0 > 1st boot : success : combined=3D0 orig_mask=3D0x11 > 2nd boot : success : combined=3D0 orig_mask=3D0x11 > 3rd boot : failure : combined=3D0 orig_mask=3D0x0 > 4th boot : failure : combined=3D0 orig_mask=3D0x0 > 5th boot : failure : combined=3D0 orig_mask=3D0x0 > 6th boot : failure : combined=3D0 orig_mask=3D0x0 > 7th boot : success : combined=3D0 orig_mask=3D0x11 > Output of your trace with ata_piix.override_PCS=3D1 > 1st boot : success : combined=3D0 orig_mask=3D0x0 > 2nd boot : success : combined=3D0 orig_mask=3D0x0 > 3rd boot : success : combined=3D0 orig_mask=3D0x0 > 4th boot : success : combined=3D0 orig_mask=3D0x0 > 5th boot : success : combined=3D0 orig_mask=3D0x0 > 6th boot : success : combined=3D0 orig_mask=3D0x0 > 7th boot : success : combined=3D0 orig_mask=3D0x0 > 8th boot : success : combined=3D0 orig_mask=3D0x0 >=20 > Looks like you have found a fix/workaround for this bug (but it still= =20 > does not give the reason why it's failing). >=20 It probably is a BIOS issue. The weird thing though is that the port=20 works fine with its corresponding ENABLED bit cleared. Anyways, if it=20 works by ignoring the ENABLED bit, ignoring should just be fine. 0602, can you verify this workaround works on your machine too? Jeff (Hi!), if 0602 also confirms that this workaround works, I'll=20 submit a patch to make ata_piix ignore PCS values on ICH5's. How does=20 that sound to you? --=20 tejun - 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 From jgarzik@pobox.com Thu Dec 1 13:48:37 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 13:48:42 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932499AbVLAVsk (ORCPT ); Thu, 1 Dec 2005 16:48:40 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932498AbVLAVsk (ORCPT ); Thu, 1 Dec 2005 16:48:40 -0500 Received: from havoc.gtf.org ([69.61.125.42]:39305 "EHLO havoc.gtf.org") by vger.kernel.org with ESMTP id S932494AbVLAVsj (ORCPT ); Thu, 1 Dec 2005 16:48:39 -0500 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by havoc.gtf.org (Postfix) with ESMTP id 25E6B1C4ACEC; Thu, 1 Dec 2005 16:48:38 -0500 (EST) Received: (from garzik@localhost) by havoc.gtf.org (8.13.1/8.13.1/Submit) id jB1LmbV4025449; Thu, 1 Dec 2005 16:48:37 -0500 Date: Thu, 1 Dec 2005 16:48:37 -0500 From: Jeff Garzik To: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Marcelo Tosatti Subject: Final 2.4.x SATA updates Message-ID: <20051201214837.GA25256@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 588 Now that ATAPI support is pretty stable, the 2.4 version of libata will be receiving its final updates soon. Here is the current backport, for testing and feedback. Please report problems -- particularly any regressions -- to linux-ide@vger.kernel.org. I may not be able to respond personally to each and every bug report, but rest assured all feedback is noted. Sometimes, solutions only become apparent after a few people report the same problem. The 'combined' branch of rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-2.4.git http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.4.32-libata1.patch.bz2 (available as soon as kernel.org mirrors catch up) contains the following updates: drivers/pci/quirks.c | 86 ++ drivers/scsi/ahci.c | 305 ++++--- drivers/scsi/ata_piix.c | 136 +-- drivers/scsi/libata-core.c | 1743 +++++++++++++++++++++++++++--------------- drivers/scsi/libata-scsi.c | 1635 ++++++++++++++++++++++++++++++--------- drivers/scsi/libata.h | 68 - drivers/scsi/sata_nv.c | 86 +- drivers/scsi/sata_promise.c | 166 ++-- drivers/scsi/sata_promise.h | 33 drivers/scsi/sata_qstor.c | 114 +- drivers/scsi/sata_sil.c | 100 +- drivers/scsi/sata_sis.c | 146 ++- drivers/scsi/sata_svw.c | 85 +- drivers/scsi/sata_sx4.c | 292 +++---- drivers/scsi/sata_uli.c | 66 - drivers/scsi/sata_via.c | 110 +- drivers/scsi/sata_vsc.c | 79 + include/linux/ata.h | 86 +- include/linux/ioport.h | 1 include/linux/libata-compat.h | 102 ++ include/linux/libata.h | 264 ++++-- include/linux/pci_ids.h | 6 include/scsi/scsi.h | 4 kernel/ksyms.c | 1 kernel/resource.c | 10 25 files changed, 3957 insertions(+), 1767 deletions(-) Jeff Garzik: [libata] resync with kernel 2.6.13 [libata sata_sx4] trim trailing whitespace [libata] resync with 2.6.14 [libata] resync with 2.6.15-rc3 [libata] fix build [libata] combined mode support, using ugly ____request_resource() hack [libata] fix potential oops in pdev_printk() compat helper - 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 From andersen@codepoet.org Thu Dec 1 15:10:08 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 15:10:13 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932548AbVLAXKL (ORCPT ); Thu, 1 Dec 2005 18:10:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932549AbVLAXKK (ORCPT ); Thu, 1 Dec 2005 18:10:10 -0500 Received: from codepoet.org ([166.70.99.138]:23474 "EHLO codepoet.org") by vger.kernel.org with ESMTP id S932548AbVLAXKJ (ORCPT ); Thu, 1 Dec 2005 18:10:09 -0500 Received: by codepoet.org (Codepoet.org Mail Daemon, from userid 1000) id 98AB4864D00; Thu, 1 Dec 2005 16:10:08 -0700 (MST) Date: Thu, 1 Dec 2005 16:10:08 -0700 From: Erik Andersen To: Jeff Garzik Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, Marcelo Tosatti Subject: Re: Final 2.4.x SATA updates Message-ID: <20051201231008.GA7921@codepoet.org> Reply-To: andersen@codepoet.org Mail-Followup-To: andersen@codepoet.org, Jeff Garzik , linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, Marcelo Tosatti References: <20051201214837.GA25256@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051201214837.GA25256@havoc.gtf.org> X-No-Junk-Mail: I do not want to get *any* junk mail. User-Agent: Mutt/1.5.9i Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 663 On Thu Dec 01, 2005 at 04:48:37PM -0500, Jeff Garzik wrote: > > Now that ATAPI support is pretty stable, the 2.4 version of libata will > be receiving its final updates soon. Here is the current backport, > for testing and feedback. Awesome. 2.4.x lacks KM_IRQ0 in kmap_types.h gcc -D__KERNEL__ -I/usr/src/linux-2.4.32/include -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fomit-frame-pointer -Os -falign-functions=2 -falign-jumps=2 -falign-labels=2 -falign-loops=2 -pipe -mpreferred-stack-boundary=2 -march=i486 -DMODULE -nostdinc -iwithprefix include -DKBUILD_BASENAME=libata_core -DEXPORT_SYMTAB -c libata-core.c libata-core.c: In function `ata_sg_clean': libata-core.c:2427: error: `KM_IRQ0' undeclared (first use in this function) libata-core.c:2427: error: (Each undeclared identifier is reported only once libata-core.c:2427: error: for each function it appears in.) libata-core.c: In function `ata_sg_setup': libata-core.c:2701: error: `KM_IRQ0' undeclared (first use in this function) make[2]: *** [libata-core.o] Error 1 -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- - 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 From seb.kuzminsky@gmail.com Thu Dec 1 15:36:44 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 15:36:57 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932549AbVLAXgr (ORCPT ); Thu, 1 Dec 2005 18:36:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932556AbVLAXgq (ORCPT ); Thu, 1 Dec 2005 18:36:46 -0500 Received: from xproxy.gmail.com ([66.249.82.195]:43971 "EHLO xproxy.gmail.com") by vger.kernel.org with ESMTP id S932549AbVLAXgq convert rfc822-to-8bit (ORCPT ); Thu, 1 Dec 2005 18:36:46 -0500 Received: by xproxy.gmail.com with SMTP id i30so388899wxd for ; Thu, 01 Dec 2005 15:36:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=nK5qDVXPw+2Af2xYUp0vYImydOD67GdVb1HTHSat6aSOIVCz49u/M9h7ykqKzi3v9rT3vuz11JNpscG4CVAlmPAdjE4qG/WPf5czyDdqPur2YyB5l05ahwKaZkLJH1ztTI61ZE18WQNj7MfwCNPdBFrYXlvOajy7Sij+xGPFp4A= Received: by 10.70.105.12 with SMTP id d12mr1865477wxc; Thu, 01 Dec 2005 15:36:44 -0800 (PST) Received: by 10.54.86.7 with HTTP; Thu, 1 Dec 2005 15:36:44 -0800 (PST) Message-ID: <7f55de720512011536n681af61el796c3da5a90143db@mail.gmail.com> Date: Thu, 1 Dec 2005 16:36:44 -0700 From: Sebastian Kuzminsky To: linux-ide@vger.kernel.org Subject: What eSATA hardware? MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Disposition: inline Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 696 Hi folks, I hope this is not too off-topic... I'm building a disk server, and I want to use eSATA, and I need hardware advice... I'm considering the Sonnet Tempo-X eSATA 8 , and the Addonics ADSA3GX4R-E . I think both of these are supported in 2.6, is one prefered over the other? Are there any others I should consider? I prefer the Sonnet, just because it's got 8 ports so that saves me a PCI-X slot. I'm also looking for a good eSATA enclosure. I'd prefer an 8x enclosure with redundant power supplies, but I've been unable to find one. Anyone know of one? My second choice would be to use a bunch of 2x enclosures. The thinking is, if I lose one power supply, my RAID-6 array stays up. I'm thinking cooler drives live longer, so I want the enclosure I buy to have at least one fan on each disk, plus a big exhaust fan, plus the power supply fan. Any suggestions and advice would be greatly appreciated... -- Sebastian Kuzminsky - 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 From jgarzik@pobox.com Thu Dec 1 17:41:01 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 17:41:38 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932719AbVLBBlK (ORCPT ); Thu, 1 Dec 2005 20:41:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932718AbVLBBlJ (ORCPT ); Thu, 1 Dec 2005 20:41:09 -0500 Received: from mail.dvmed.net ([216.237.124.58]:12509 "EHLO mail.dvmed.net") by vger.kernel.org with ESMTP id S932715AbVLBBlH (ORCPT ); Thu, 1 Dec 2005 20:41:07 -0500 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1Ehzv7-0005qS-1y; Fri, 02 Dec 2005 01:41:06 +0000 Message-ID: <438FA62D.2040707@pobox.com> Date: Thu, 01 Dec 2005 20:41:01 -0500 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: andersen@codepoet.org CC: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, Marcelo Tosatti Subject: Re: Final 2.4.x SATA updates References: <20051201214837.GA25256@havoc.gtf.org> <20051201231008.GA7921@codepoet.org> In-Reply-To: <20051201231008.GA7921@codepoet.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Spam-Report: Spam detection software, running on the system "srv2.dvmed.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Erik Andersen wrote: > On Thu Dec 01, 2005 at 04:48:37PM -0500, Jeff Garzik wrote: > >>Now that ATAPI support is pretty stable, the 2.4 version of libata will >>be receiving its final updates soon. Here is the current backport, >>for testing and feedback. > > > Awesome. 2.4.x lacks KM_IRQ0 in kmap_types.h > > gcc -D__KERNEL__ -I/usr/src/linux-2.4.32/include -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fomit-frame-pointer -Os -falign-functions=2 -falign-jumps=2 -falign-labels=2 -falign-loops=2 -pipe -mpreferred-stack-boundary=2 -march=i486 -DMODULE -nostdinc -iwithprefix include -DKBUILD_BASENAME=libata_core -DEXPORT_SYMTAB -c libata-core.c > libata-core.c: In function `ata_sg_clean': > libata-core.c:2427: error: `KM_IRQ0' undeclared (first use in this function) > libata-core.c:2427: error: (Each undeclared identifier is reported only once > libata-core.c:2427: error: for each function it appears in.) > libata-core.c: In function `ata_sg_setup': > libata-core.c:2701: error: `KM_IRQ0' undeclared (first use in this function) > make[2]: *** [libata-core.o] Error 1 [...] Content analysis details: (0.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.1 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [69.134.188.146 listed in dnsbl.sorbs.net] Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 867 Erik Andersen wrote: > On Thu Dec 01, 2005 at 04:48:37PM -0500, Jeff Garzik wrote: > >>Now that ATAPI support is pretty stable, the 2.4 version of libata will >>be receiving its final updates soon. Here is the current backport, >>for testing and feedback. > > > Awesome. 2.4.x lacks KM_IRQ0 in kmap_types.h > > gcc -D__KERNEL__ -I/usr/src/linux-2.4.32/include -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fomit-frame-pointer -Os -falign-functions=2 -falign-jumps=2 -falign-labels=2 -falign-loops=2 -pipe -mpreferred-stack-boundary=2 -march=i486 -DMODULE -nostdinc -iwithprefix include -DKBUILD_BASENAME=libata_core -DEXPORT_SYMTAB -c libata-core.c > libata-core.c: In function `ata_sg_clean': > libata-core.c:2427: error: `KM_IRQ0' undeclared (first use in this function) > libata-core.c:2427: error: (Each undeclared identifier is reported only once > libata-core.c:2427: error: for each function it appears in.) > libata-core.c: In function `ata_sg_setup': > libata-core.c:2701: error: `KM_IRQ0' undeclared (first use in this function) > make[2]: *** [libata-core.o] Error 1 hmmm, interesting. Easy enough to fix. I guess I didn't build on a highmem box. Jeff - 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 From jgarzik@pobox.com Thu Dec 1 17:53:40 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 17:53:55 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964775AbVLBBxx convert rfc822-to-quoted-printable (ORCPT ); Thu, 1 Dec 2005 20:53:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964778AbVLBBxx (ORCPT ); Thu, 1 Dec 2005 20:53:53 -0500 Received: from mail.dvmed.net ([216.237.124.58]:21981 "EHLO mail.dvmed.net") by vger.kernel.org with ESMTP id S964775AbVLBBxw (ORCPT ); Thu, 1 Dec 2005 20:53:52 -0500 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1Ei07L-0005rA-Qh; Fri, 02 Dec 2005 01:53:44 +0000 Message-ID: <438FA924.1090005@pobox.com> Date: Thu, 01 Dec 2005 20:53:40 -0500 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tejun Heo CC: =?ISO-8859-1?Q?Jean-Fran=E7ois_Stenuit?= , Keith Mannthey , "0602@eq.cz" <0602@eq.cz>, Linux-ide Subject: Re: totally random "VFS: Cannot open root device" References: <438B6E05.8070009@eq.cz> <438D2C19.3030008@gmail.com> <438DA3FA.2010809@eq.cz> <438EC502.1090103@keytradebank.com> <20051201112015.GA10462@htj.dyndns.org> <438EF3B6.7020007@keytradebank.com> <438EFAA5.3070901@gmail.com> In-Reply-To: <438EFAA5.3070901@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Score: 0.1 (/) X-Spam-Report: Spam detection software, running on the system "srv2.dvmed.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Tejun Heo wrote: > =?ISO-8859-1?Q?=20Jean-Fran=E7ois?= Stenuit wrote: > >> Hi Tejun, >> >> Thanks for taking the time to check. >> >> Output of your trace with ata_piix.override_PCS=0 >> 1st boot : success : combined=0 orig_mask=0x11 >> 2nd boot : success : combined=0 orig_mask=0x11 >> 3rd boot : failure : combined=0 orig_mask=0x0 >> 4th boot : failure : combined=0 orig_mask=0x0 >> 5th boot : failure : combined=0 orig_mask=0x0 >> 6th boot : failure : combined=0 orig_mask=0x0 >> 7th boot : success : combined=0 orig_mask=0x11 >> Output of your trace with ata_piix.override_PCS=1 >> 1st boot : success : combined=0 orig_mask=0x0 >> 2nd boot : success : combined=0 orig_mask=0x0 >> 3rd boot : success : combined=0 orig_mask=0x0 >> 4th boot : success : combined=0 orig_mask=0x0 >> 5th boot : success : combined=0 orig_mask=0x0 >> 6th boot : success : combined=0 orig_mask=0x0 >> 7th boot : success : combined=0 orig_mask=0x0 >> 8th boot : success : combined=0 orig_mask=0x0 >> >> Looks like you have found a fix/workaround for this bug (but it still >> does not give the reason why it's failing). >> > > It probably is a BIOS issue. The weird thing though is that the port > works fine with its corresponding ENABLED bit cleared. Anyways, if it > works by ignoring the ENABLED bit, ignoring should just be fine. > > 0602, can you verify this workaround works on your machine too? > > Jeff (Hi!), if 0602 also confirms that this workaround works, I'll > submit a patch to make ata_piix ignore PCS values on ICH5's. How does > that sound to you? [...] Content analysis details: (0.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.1 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [69.134.188.146 listed in dnsbl.sorbs.net] Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Tejun Heo wrote: > Jean-Fran=E7ois Stenuit wrote: >=20 >> Hi Tejun, >> >> Thanks for taking the time to check. >> >> Output of your trace with ata_piix.override_PCS=3D0 >> 1st boot : success : combined=3D0 orig_mask=3D0x11 >> 2nd boot : success : combined=3D0 orig_mask=3D0x11 >> 3rd boot : failure : combined=3D0 orig_mask=3D0x0 >> 4th boot : failure : combined=3D0 orig_mask=3D0x0 >> 5th boot : failure : combined=3D0 orig_mask=3D0x0 >> 6th boot : failure : combined=3D0 orig_mask=3D0x0 >> 7th boot : success : combined=3D0 orig_mask=3D0x11 >> Output of your trace with ata_piix.override_PCS=3D1 >> 1st boot : success : combined=3D0 orig_mask=3D0x0 >> 2nd boot : success : combined=3D0 orig_mask=3D0x0 >> 3rd boot : success : combined=3D0 orig_mask=3D0x0 >> 4th boot : success : combined=3D0 orig_mask=3D0x0 >> 5th boot : success : combined=3D0 orig_mask=3D0x0 >> 6th boot : success : combined=3D0 orig_mask=3D0x0 >> 7th boot : success : combined=3D0 orig_mask=3D0x0 >> 8th boot : success : combined=3D0 orig_mask=3D0x0 >> >> Looks like you have found a fix/workaround for this bug (but it stil= l=20 >> does not give the reason why it's failing). >> >=20 > It probably is a BIOS issue. The weird thing though is that the port= =20 > works fine with its corresponding ENABLED bit cleared. Anyways, if i= t=20 > works by ignoring the ENABLED bit, ignoring should just be fine. >=20 > 0602, can you verify this workaround works on your machine too? >=20 > Jeff (Hi!), if 0602 also confirms that this workaround works, I'll=20 > submit a patch to make ata_piix ignore PCS values on ICH5's. How doe= s=20 > that sound to you? I am being dragged into this thread with little background info. Here'= s=20 some data points that may be relevant: * until very recently, ata_piix's definitions for the ENABLED and=20 PRESENT bits was reversed. * the PRESENT bit reflects a device present status just like the SStatu= s=20 phy register does. This implies that one must wait, before assuming=20 that the PRESENT bit's absence truly indicates absence of a device. * the device may be in various power management states. It may be wise= =20 to issue COMRESET by - clear ENABLED bit - set ENABLED bit - wait for device to appear - if no device appeared, clear ENABLED bit In sum, think about the underlying SATA phy registers, and how they=20 logically map to the PCS bits. Jeff - 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 From jgarzik@pobox.com Thu Dec 1 17:59:42 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 17:59:53 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964779AbVLBB7u (ORCPT ); Thu, 1 Dec 2005 20:59:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964780AbVLBB7u (ORCPT ); Thu, 1 Dec 2005 20:59:50 -0500 Received: from mail.dvmed.net ([216.237.124.58]:25053 "EHLO mail.dvmed.net") by vger.kernel.org with ESMTP id S964779AbVLBB7t (ORCPT ); Thu, 1 Dec 2005 20:59:49 -0500 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1Ei0DA-0005rV-GF; Fri, 02 Dec 2005 01:59:44 +0000 Message-ID: <438FAA8E.9010502@pobox.com> Date: Thu, 01 Dec 2005 20:59:42 -0500 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tejun Heo CC: russb@emc.com, Linux-ide Subject: Re: [QUESTION] in ata_scsi_pass_thru() References: <438D5742.3000804@gmail.com> In-Reply-To: <438D5742.3000804@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Spam-Report: Spam detection software, running on the system "srv2.dvmed.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Tejun Heo wrote: > Hi, all. > > In the translation function ata_scsi_pass_thru(), when it determines > that the command cannot be translated and should be finished early, it > does NOT set sense data or result code. This seems buggy. Is this > intentional? [...] Content analysis details: (0.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.1 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [69.134.188.146 listed in dnsbl.sorbs.net] Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Tejun Heo wrote: > Hi, all. > > In the translation function ata_scsi_pass_thru(), when it determines > that the command cannot be translated and should be finished early, it > does NOT set sense data or result code. This seems buggy. Is this > intentional? Yes, a bug. Jeff - 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 From jgarzik@pobox.com Thu Dec 1 18:01:00 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 18:01:11 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964783AbVLBCBJ (ORCPT ); Thu, 1 Dec 2005 21:01:09 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964782AbVLBCBJ (ORCPT ); Thu, 1 Dec 2005 21:01:09 -0500 Received: from mail.dvmed.net ([216.237.124.58]:26845 "EHLO mail.dvmed.net") by vger.kernel.org with ESMTP id S964778AbVLBCBH (ORCPT ); Thu, 1 Dec 2005 21:01:07 -0500 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1Ei0EQ-0005re-7C; Fri, 02 Dec 2005 02:01:02 +0000 Message-ID: <438FAADC.6060907@pobox.com> Date: Thu, 01 Dec 2005 21:01:00 -0500 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tejun Heo CC: Ethan Chen , linux-kernel@vger.kernel.org, Carlos Pardo , Linux-ide Subject: Re: SIL_QUIRK_MOD15WRITE workaround problem on 2.6.14 References: <438BD351.60902@ucla.edu> <438D2792.9050105@gmail.com> <438D2DCC.4010805@pobox.com> <438D3AA8.9030504@gmail.com> In-Reply-To: <438D3AA8.9030504@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Spam-Report: Spam detection software, running on the system "srv2.dvmed.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Tejun Heo wrote: > Ethan confirmed that it's 1095:3114. Arghhh.... Maybe we should keep > m15w quirk for 3114's for the time being? Better be slow than hang. > Whatever bug the m15w quirk was hiding. [...] Content analysis details: (0.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.1 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [69.134.188.146 listed in dnsbl.sorbs.net] Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Tejun Heo wrote: > Ethan confirmed that it's 1095:3114. Arghhh.... Maybe we should keep > m15w quirk for 3114's for the time being? Better be slow than hang. > Whatever bug the m15w quirk was hiding. A generic 'slow_down_io' module option is reasonable. It is not appropriate to apply mod15write quirk to hardware that isn't affected by the chip bug. A better solution is to write a 311x-specific interrupt handler. Jeff - 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 From jgarzik@pobox.com Thu Dec 1 18:02:44 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 18:02:50 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964782AbVLBCCr (ORCPT ); Thu, 1 Dec 2005 21:02:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964785AbVLBCCr (ORCPT ); Thu, 1 Dec 2005 21:02:47 -0500 Received: from mail.dvmed.net ([216.237.124.58]:28637 "EHLO mail.dvmed.net") by vger.kernel.org with ESMTP id S964782AbVLBCCr (ORCPT ); Thu, 1 Dec 2005 21:02:47 -0500 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1Ei0G6-0005rp-Ep; Fri, 02 Dec 2005 02:02:46 +0000 Message-ID: <438FAB44.5030807@pobox.com> Date: Thu, 01 Dec 2005 21:02:44 -0500 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Raz Ben-Jehuda(caro)" CC: linux-ide@vger.kernel.org Subject: Re: cpu consumption References: <5d96567b0511260545j61970a01j3b5c435766a51a6d@mail.gmail.com> In-Reply-To: <5d96567b0511260545j61970a01j3b5c435766a51a6d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Spam-Report: Spam detection software, running on the system "srv2.dvmed.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Raz Ben-Jehuda(caro) wrote: > Hello Jeff. > Here is my problem. > > When I issue a READ operation over a SATA disk in linux i have > huge cpu consumption , about 90% cpu usage. > > I am using MAXTOR disks in a supermicro machine. > the cpu test was made when i "raw read" from the DISK using DIRECT_IO. [...] Content analysis details: (0.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.1 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [69.134.188.146 listed in dnsbl.sorbs.net] Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Raz Ben-Jehuda(caro) wrote: > Hello Jeff. > Here is my problem. > > When I issue a READ operation over a SATA disk in linux i have > huge cpu consumption , about 90% cpu usage. > > I am using MAXTOR disks in a supermicro machine. > the cpu test was made when i "raw read" from the DISK using DIRECT_IO. I dunno... do some profiling (in-kernel profiler, or oprofile) and see where the CPU is being consumed. Are you also seeing a lot of interrupts? Jeff - 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 From jgarzik@pobox.com Thu Dec 1 18:05:44 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 18:06:17 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964790AbVLBCF4 (ORCPT ); Thu, 1 Dec 2005 21:05:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964788AbVLBCF4 (ORCPT ); Thu, 1 Dec 2005 21:05:56 -0500 Received: from mail.dvmed.net ([216.237.124.58]:32989 "EHLO mail.dvmed.net") by vger.kernel.org with ESMTP id S964787AbVLBCFy (ORCPT ); Thu, 1 Dec 2005 21:05:54 -0500 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1Ei0J1-0005s6-H4; Fri, 02 Dec 2005 02:05:47 +0000 Message-ID: <438FABF8.3020802@pobox.com> Date: Thu, 01 Dec 2005 21:05:44 -0500 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bartlomiej Zolnierkiewicz CC: dougg@torque.net, brking@us.ibm.com, Luben Tuikov , linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, t.schorpp@gmx.de Subject: Re: [PATCH 1/2] libata: Remove dependence on host_set->dev for SAS References: <4341A91A.3020000@us.ibm.com> <435D5D83.1060201@us.ibm.com> <435D5DE5.7010306@us.ibm.com> <435E7105.4010105@pobox.com> <435E87E8.9010506@us.ibm.com> <435E8AC7.1080407@pobox.com> <435EB656.1040502@adaptec.com> <4360FAC1.8020409@us.ibm.com> <43850F0D.7040907@torque.net> <43851262.7020807@pobox.com> <58cb370e0511240012r64ad150eo90553b230992424e@mail.gmail.com> In-Reply-To: <58cb370e0511240012r64ad150eo90553b230992424e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Spam-Report: Spam detection software, running on the system "srv2.dvmed.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Bartlomiej Zolnierkiewicz wrote: > On 11/24/05, Jeff Garzik wrote: > >>Douglas Gilbert wrote: >> >>>I don't think a SATL is that easy. One SCSI command can >>>translate into zero or more ATA commands. If it translates >>>to multiple commands, then there is the possibility of an >>>error prior to the last in the sequence of ATA commands >>>(how to report; rollback needed ?). The SATL needs to hold >>>state and needs a service thread if it is to support the >>>IMMED bit on some commands (e.g. START STOP UNIT). >> >>It needs a conceptual service thread, not necessarily an explicit one. >> >>With REQUEST SENSE, I've demonstrated how to report errors with each >>step in the sequence. With demo patches I've posted, I've demonstrated >>(using qc->private_data) how to hold state. >> >> >> >>>libata still has a ways to go to catch up to SAT rev 7 >>>but has made some good progress lately with the addition >>>of the ATA pass through commands (lk 2.6.15-rc1 and onward). >>>smartmontools (just prior to 5.34) now works with '-d ata' >>>on libata-connected SATA disks. The '-d ata' ** overrides >>>the guess of a SCSI disk based on the device node (e.g. >>>/dev/sda) and uses the HDIO_DRIVE_CMD and HDIO_DRIVE_TASK >>>ioctls. The absence of support for the HDIO_DRIVE_TASKFILE >>>ioctl means that "selective" self-test can't be done. >>>I'm not sure if moving smartmontools to the ATA PASS THROUGH >>>SCSI commands will win back the "selective" self-test >>>capability. Anyway, going to those ATA PASS THROUGH SCSI >> >>ATA passthru can do anything the legacy IDE ioctls can do (and more). > > > [ definitely ATA passthru is the way to go but... ] > > discrete taskfiles? [...] Content analysis details: (0.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.1 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [69.134.188.146 listed in dnsbl.sorbs.net] Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Bartlomiej Zolnierkiewicz wrote: > On 11/24/05, Jeff Garzik wrote: > >>Douglas Gilbert wrote: >> >>>I don't think a SATL is that easy. One SCSI command can >>>translate into zero or more ATA commands. If it translates >>>to multiple commands, then there is the possibility of an >>>error prior to the last in the sequence of ATA commands >>>(how to report; rollback needed ?). The SATL needs to hold >>>state and needs a service thread if it is to support the >>>IMMED bit on some commands (e.g. START STOP UNIT). >> >>It needs a conceptual service thread, not necessarily an explicit one. >> >>With REQUEST SENSE, I've demonstrated how to report errors with each >>step in the sequence. With demo patches I've posted, I've demonstrated >>(using qc->private_data) how to hold state. >> >> >> >>>libata still has a ways to go to catch up to SAT rev 7 >>>but has made some good progress lately with the addition >>>of the ATA pass through commands (lk 2.6.15-rc1 and onward). >>>smartmontools (just prior to 5.34) now works with '-d ata' >>>on libata-connected SATA disks. The '-d ata' ** overrides >>>the guess of a SCSI disk based on the device node (e.g. >>>/dev/sda) and uses the HDIO_DRIVE_CMD and HDIO_DRIVE_TASK >>>ioctls. The absence of support for the HDIO_DRIVE_TASKFILE >>>ioctl means that "selective" self-test can't be done. >>>I'm not sure if moving smartmontools to the ATA PASS THROUGH >>>SCSI commands will win back the "selective" self-test >>>capability. Anyway, going to those ATA PASS THROUGH SCSI >> >>ATA passthru can do anything the legacy IDE ioctls can do (and more). > > > [ definitely ATA passthru is the way to go but... ] > > discrete taskfiles? what is this? > multi-PIO? what is this? multi-sector PIO, such as READ MULTIPLE SECTORS? ATA passthru can do that. > setting transfer speed? That's not a limitation of passthru, but a limitation of the driver. I don't yet see the value... Jeff - 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 From htejun@gmail.com Thu Dec 1 18:14:16 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 18:14:27 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964788AbVLBCOW (ORCPT ); Thu, 1 Dec 2005 21:14:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964794AbVLBCOW (ORCPT ); Thu, 1 Dec 2005 21:14:22 -0500 Received: from zproxy.gmail.com ([64.233.162.199]:61075 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S964788AbVLBCOW (ORCPT ); Thu, 1 Dec 2005 21:14:22 -0500 Received: by zproxy.gmail.com with SMTP id 14so132916nzn for ; Thu, 01 Dec 2005 18:14:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Chngm97i9O9kZ3NKtQ6ACqwe9fgt8Qc0ICEENnxn3dWM8w9g8aO/6+pu7gdYWTxBA/0W8OSnVkJqnDyffl7qY4bgoETMReY2lID8GVGBtwFZlF9z5d6+t25Hp0gJE5cH/IYbRf/uhIXeBi87G94UagYhH6/UR18oRyQELX0hG/Q= Received: by 10.36.221.17 with SMTP id t17mr2085488nzg; Thu, 01 Dec 2005 18:14:20 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id 19sm2313029nzp.2005.12.01.18.14.19; Thu, 01 Dec 2005 18:14:20 -0800 (PST) Received: from [127.0.0.1] (htj.dyndns.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by htj.dyndns.org (Postfix) with ESMTP id A792A18409E; Fri, 2 Dec 2005 11:14:16 +0900 (KST) Message-ID: <438FADF8.5050209@gmail.com> Date: Fri, 02 Dec 2005 11:14:16 +0900 From: Tejun Heo User-Agent: Debian Thunderbird 1.0.7 (X11/20051019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: "Raz Ben-Jehuda(caro)" , linux-ide@vger.kernel.org Subject: Re: cpu consumption References: <5d96567b0511260545j61970a01j3b5c435766a51a6d@mail.gmail.com> <438FAB44.5030807@pobox.com> In-Reply-To: <438FAB44.5030807@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Jeff Garzik wrote: > Raz Ben-Jehuda(caro) wrote: > >> Hello Jeff. >> Here is my problem. >> >> When I issue a READ operation over a SATA disk in linux i have >> huge cpu consumption , about 90% cpu usage. >> >> I am using MAXTOR disks in a supermicro machine. >> the cpu test was made when i "raw read" from the DISK using DIRECT_IO. > > > I dunno... do some profiling (in-kernel profiler, or oprofile) and see > where the CPU is being consumed. > > Are you also seeing a lot of interrupts? > > Jeff > > Jeff, this one is resolved. It turned out that Raz mistook wait time to be busy. Hmmm... marc doesn't show any mesage after 2005-11-25. This is is resolved in a thread on linux-ide named "CPU usage is very high while io'ing a sata disk" from Raz. The first message of the thread is posted on 2005-11-30 06:23 +0900. -- tejun - 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 From htejun@gmail.com Thu Dec 1 18:49:11 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 18:49:56 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964811AbVLBCta (ORCPT ); Thu, 1 Dec 2005 21:49:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964813AbVLBCta (ORCPT ); Thu, 1 Dec 2005 21:49:30 -0500 Received: from zproxy.gmail.com ([64.233.162.199]:20586 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S964811AbVLBCt3 (ORCPT ); Thu, 1 Dec 2005 21:49:29 -0500 Received: by zproxy.gmail.com with SMTP id 13so4809nzn for ; Thu, 01 Dec 2005 18:49:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=NtwnlgL9zsmNjdQI9HybZ6ttqyHD2u2Rur4P0aC+MTxEnkwcKXPeDFGt9v1+qzkDnq1L3tS/FfmFwr/NU+KApvpt3g05zaIVWJFq5xSncsSaUN8N4ByKxIWPv64E2byDkLtLYmriYScSYDAaWwdgkPfzhH8bfwV2qzrRdwS43Xs= Received: by 10.36.9.18 with SMTP id 18mr2209741nzi; Thu, 01 Dec 2005 18:49:28 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id 38sm2315422nzk.2005.12.01.18.49.27; Thu, 01 Dec 2005 18:49:28 -0800 (PST) Received: by htj.dyndns.org (Postfix, from userid 1000) id C7B4D18604C; Fri, 2 Dec 2005 11:49:11 +0900 (KST) Date: Fri, 2 Dec 2005 11:49:11 +0900 From: Tejun Heo To: Jeff Garzik Cc: russb@emc.com, Linux-ide Subject: [PATCH] libata: fix ata_scsi_pass_thru error handling Message-ID: <20051202024911.GA13292@htj.dyndns.org> References: <438D5742.3000804@gmail.com> <438FAA8E.9010502@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438FAA8E.9010502@pobox.com> User-Agent: Mutt/1.5.11 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org This patch makes ata_scsi_pass_thru() properly set result code and sense data on translation failures. Signed-off-by: Tejun Heo diff --git a/drivers/scsi/libata-scsi.c b/drivers/scsi/libata-scsi.c index 957a9ca..7445d8b 100644 --- a/drivers/scsi/libata-scsi.c +++ b/drivers/scsi/libata-scsi.c @@ -2233,7 +2233,7 @@ ata_scsi_pass_thru(struct ata_queued_cmd struct scsi_cmnd *cmd = qc->scsicmd; if ((tf->protocol = ata_scsi_map_proto(scsicmd[1])) == ATA_PROT_UNKNOWN) - return 1; + goto invalid_fld; /* * 12 and 16 byte CDBs use different offsets to @@ -2295,7 +2295,7 @@ ata_scsi_pass_thru(struct ata_queued_cmd */ if ((tf->command == ATA_CMD_SET_FEATURES) && (tf->feature == SETFEATURES_XFER)) - return 1; + goto invalid_fld; /* * Set flags so that all registers will be written, @@ -2316,6 +2316,11 @@ ata_scsi_pass_thru(struct ata_queued_cmd qc->nsect = cmd->bufflen / ATA_SECT_SIZE; return 0; + + invalid_fld: + ata_scsi_set_sense(qc->scsicmd, ILLEGAL_REQUEST, 0x24, 0x00); + /* "Invalid field in cdb" */ + return 1; } /** - 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 From htejun@gmail.com Thu Dec 1 19:00:05 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 19:00:17 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964821AbVLBDAO convert rfc822-to-quoted-printable (ORCPT ); Thu, 1 Dec 2005 22:00:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964822AbVLBDAN (ORCPT ); Thu, 1 Dec 2005 22:00:13 -0500 Received: from zproxy.gmail.com ([64.233.162.207]:2130 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S964821AbVLBDAL (ORCPT ); Thu, 1 Dec 2005 22:00:11 -0500 Received: by zproxy.gmail.com with SMTP id 14so141765nzn for ; Thu, 01 Dec 2005 19:00:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=KnkOII/iBHPSvrr6l60TpvdH1OTzE1ZjxEd2GpOXZqjPM3O/+dxUroQHDiCS8Lk6Txby3F/MKh/qsCmhyBDY8s0ZtO5AIQofBAzP4EDwGw6sOimhiGCAnGFy6tWIdTTmzeF/YNmtKz81EkSrZx97IkiIYixRUP0z+awKjdJDwfw= Received: by 10.36.49.1 with SMTP id w1mr2173787nzw; Thu, 01 Dec 2005 19:00:10 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id j7sm174909nzd.2005.12.01.19.00.08; Thu, 01 Dec 2005 19:00:10 -0800 (PST) Received: from [127.0.0.1] (htj.dyndns.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by htj.dyndns.org (Postfix) with ESMTP id A468E184251; Fri, 2 Dec 2005 12:00:05 +0900 (KST) Message-ID: <438FB8B5.8070505@gmail.com> Date: Fri, 02 Dec 2005 12:00:05 +0900 From: Tejun Heo User-Agent: Debian Thunderbird 1.0.7 (X11/20051019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: =?ISO-8859-1?Q?Jean-Fran=E7ois_Stenuit?= , Keith Mannthey , "0602@eq.cz" <0602@eq.cz>, Linux-ide Subject: Re: totally random "VFS: Cannot open root device" References: <438B6E05.8070009@eq.cz> <438D2C19.3030008@gmail.com> <438DA3FA.2010809@eq.cz> <438EC502.1090103@keytradebank.com> <20051201112015.GA10462@htj.dyndns.org> <438EF3B6.7020007@keytradebank.com> <438EFAA5.3070901@gmail.com> <438FA924.1090005@pobox.com> In-Reply-To: <438FA924.1090005@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Jeff Garzik wrote: > Tejun Heo wrote: >=20 >> Jean-Fran=E7ois Stenuit wrote: >> >>> Hi Tejun, >>> >>> Thanks for taking the time to check. >>> >>> Output of your trace with ata_piix.override_PCS=3D0 >>> 1st boot : success : combined=3D0 orig_mask=3D0x11 >>> 2nd boot : success : combined=3D0 orig_mask=3D0x11 >>> 3rd boot : failure : combined=3D0 orig_mask=3D0x0 >>> 4th boot : failure : combined=3D0 orig_mask=3D0x0 >>> 5th boot : failure : combined=3D0 orig_mask=3D0x0 >>> 6th boot : failure : combined=3D0 orig_mask=3D0x0 >>> 7th boot : success : combined=3D0 orig_mask=3D0x11 >>> Output of your trace with ata_piix.override_PCS=3D1 >>> 1st boot : success : combined=3D0 orig_mask=3D0x0 >>> 2nd boot : success : combined=3D0 orig_mask=3D0x0 >>> 3rd boot : success : combined=3D0 orig_mask=3D0x0 >>> 4th boot : success : combined=3D0 orig_mask=3D0x0 >>> 5th boot : success : combined=3D0 orig_mask=3D0x0 >>> 6th boot : success : combined=3D0 orig_mask=3D0x0 >>> 7th boot : success : combined=3D0 orig_mask=3D0x0 >>> 8th boot : success : combined=3D0 orig_mask=3D0x0 >>> >>> Looks like you have found a fix/workaround for this bug (but it sti= ll=20 >>> does not give the reason why it's failing). >>> >> >> It probably is a BIOS issue. The weird thing though is that the por= t=20 >> works fine with its corresponding ENABLED bit cleared. Anyways, if = it=20 >> works by ignoring the ENABLED bit, ignoring should just be fine. >> >> 0602, can you verify this workaround works on your machine too? >> >> Jeff (Hi!), if 0602 also confirms that this workaround works, I'll=20 >> submit a patch to make ata_piix ignore PCS values on ICH5's. How do= es=20 >> that sound to you? >=20 Hi, Jeff. >=20 > I am being dragged into this thread with little background info. Her= e's=20 > some data points that may be relevant: >=20 > * until very recently, ata_piix's definitions for the ENABLED and=20 > PRESENT bits was reversed. I saw that in the log but it doesn't seem to be the reason for this as=20 PCS reports 0x00 on failure cases. None of ENABLED/PRESENTS bits is se= t. > * the PRESENT bit reflects a device present status just like the SSta= tus=20 > phy register does. This implies that one must wait, before assuming=20 > that the PRESENT bit's absence truly indicates absence of a device. >=20 > * the device may be in various power management states. It may be wi= se=20 > to issue COMRESET by > - clear ENABLED bit > - set ENABLED bit > - wait for device to appear > - if no device appeared, clear ENABLED bit >=20 > In sum, think about the underlying SATA phy registers, and how they=20 > logically map to the PCS bits. Interestingly, it seems that those problemetic ICH5's seem to work=20 happily on ports where ENABLED bits are cleared. Turning off ENABLED=20 bits on my ICH7 certainly disables the ports. It almost seems that the= =20 ENABLED bits are read incorrectly even though they are set correctly. I'm a little bit scared about turning on or off those bits. As probing= =20 a disabled/non-present port doesn't cause any problem (we're doing it=20 already for combined cases) and simply ignoring the ENABLED bits does=20 cure the symptom. IMHO, it's best to just ignore those mysteriously=20 zero but nevertheless working bits. I'll submit a patch to ignore=20 ENABLED bits on ICH5's. If you don't like it, please NACK it; then,=20 I'll try to cook something up which dances with the ENABLED bits. Thanks. --=20 tejun - 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 From htejun@gmail.com Thu Dec 1 19:26:05 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Thu, 1 Dec 2005 19:26:55 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964831AbVLBD0Q (ORCPT ); Thu, 1 Dec 2005 22:26:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964830AbVLBD0Q (ORCPT ); Thu, 1 Dec 2005 22:26:16 -0500 Received: from zproxy.gmail.com ([64.233.162.198]:53589 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S964827AbVLBD0K (ORCPT ); Thu, 1 Dec 2005 22:26:10 -0500 Received: by zproxy.gmail.com with SMTP id 14so146533nzn for ; Thu, 01 Dec 2005 19:26:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=ElVdNrs77q7w/jP+qIaSmtB+S56lawUU3HtPw4iy80COt25auRz02AjJgPWMZdeBqnCFqyUo/8WuI9qhlaNL1jtTCOk61fXB3d/gxvhdkrO422MmdibyNmfTrgDL0Xwn3MLgA3hfTiC1BmHJ7fqVJFH1PfsMUbnoNnkUox6QOvw= Received: by 10.36.109.5 with SMTP id h5mr226976nzc; Thu, 01 Dec 2005 19:26:09 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id 38sm2345647nza.2005.12.01.19.26.08; Thu, 01 Dec 2005 19:26:09 -0800 (PST) Received: by htj.dyndns.org (Postfix, from userid 1000) id 29EE318604A; Fri, 2 Dec 2005 12:26:05 +0900 (KST) Date: Fri, 2 Dec 2005 12:26:05 +0900 From: Tejun Heo To: Jeff Garzik Cc: Jean-Fran?ois Stenuit , Keith Mannthey , "0602@eq.cz" <0602@eq.cz>, Linux-ide Subject: [PATCH] ata_piix: ignore all zero PCS value on ICH5's Message-ID: <20051202032605.GA15528@htj.dyndns.org> References: <438B6E05.8070009@eq.cz> <438D2C19.3030008@gmail.com> <438DA3FA.2010809@eq.cz> <438EC502.1090103@keytradebank.com> <20051201112015.GA10462@htj.dyndns.org> <438EF3B6.7020007@keytradebank.com> <438EFAA5.3070901@gmail.com> <438FA924.1090005@pobox.com> <438FB8B5.8070505@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438FB8B5.8070505@gmail.com> User-Agent: Mutt/1.5.11 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Some ICH5's report 0 for PCS even when they have active working ports. This patch makes piix_sata_probe() ignore 0 PCS value on ICH5's and probe all ports in such cases. And while at it, remove bogus assignment to mask. Signed-off-by: Tejun Heo -- Hi, Jean-Francois (sorry, cannot type that character) and 0602. Can you guys please verify that this patch works? This patch is supposed to do the same thing as my previous patch with override_PCS=1. diff --git a/drivers/scsi/ata_piix.c b/drivers/scsi/ata_piix.c index 887b2b9..482995b 100644 --- a/drivers/scsi/ata_piix.c +++ b/drivers/scsi/ata_piix.c @@ -58,6 +58,7 @@ enum { ICH5_PCS = 0x92, /* port control and status */ PIIX_SCC = 0x0A, /* sub-class code register */ + PIIX_FLAG_UNRELIABLE_PCS= (1 << 27), /* PCS bits are unreliable */ PIIX_FLAG_AHCI = (1 << 28), /* AHCI possible */ PIIX_FLAG_CHECKINTR = (1 << 29), /* make sure PCI INTx enabled */ PIIX_FLAG_COMBINED = (1 << 30), /* combined mode possible */ @@ -223,7 +224,8 @@ static struct ata_port_info piix_port_in { .sht = &piix_sht, .host_flags = ATA_FLAG_SATA | ATA_FLAG_SRST | - PIIX_FLAG_COMBINED | PIIX_FLAG_CHECKINTR, + PIIX_FLAG_COMBINED | PIIX_FLAG_CHECKINTR | + PIIX_FLAG_UNRELIABLE_PCS, .pio_mask = 0x1f, /* pio0-4 */ .mwdma_mask = 0x07, /* mwdma0-2 */ .udma_mask = 0x7f, /* udma0-6 */ @@ -362,12 +364,15 @@ static int piix_sata_probe (struct ata_p int orig_mask, mask, i; u8 pcs; - mask = (PIIX_PORT_PRESENT << ap->hard_port_no) | - (PIIX_PORT_ENABLED << ap->hard_port_no); - pci_read_config_byte(pdev, ICH5_PCS, &pcs); orig_mask = (int) pcs & 0xff; + if (orig_mask == 0 && ap->flags & PIIX_FLAG_UNRELIABLE_PCS) { + printk(KERN_INFO "ata%u: PIIX PCS reports 0x00, ignoring PCS\n", + ap->id); + return 1; + } + /* TODO: this is vaguely wrong for ICH6 combined mode, * where only two of the four SATA ports are mapped * onto a single ATA channel. It is also vaguely inaccurate - 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 From bzolnier@gmail.com Fri Dec 2 00:07:29 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 00:07:38 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932455AbVLBIHb (ORCPT ); Fri, 2 Dec 2005 03:07:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932329AbVLBIHb (ORCPT ); Fri, 2 Dec 2005 03:07:31 -0500 Received: from nproxy.gmail.com ([64.233.182.195]:59808 "EHLO nproxy.gmail.com") by vger.kernel.org with ESMTP id S1751755AbVLBIHa convert rfc822-to-8bit (ORCPT ); Fri, 2 Dec 2005 03:07:30 -0500 Received: by nproxy.gmail.com with SMTP id x4so170078nfb for ; Fri, 02 Dec 2005 00:07:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ltcMW/AIjrZTSn09WqCe0he9Zk3APZUGItJOTchJSX0daMty2SXjmxdK4SzSdrUyGs+em9PZAW/Dw9SQVfT3XOURoIaeeRbSIJCJrS8h5ue9pYqv+0Cmquiw57P1pdoLlITODZEXtNe6NQRfHmDqgBIh8a3BM00rhmajWZCOOdI= Received: by 10.48.221.20 with SMTP id t20mr533614nfg; Fri, 02 Dec 2005 00:07:29 -0800 (PST) Received: by 10.48.49.7 with HTTP; Fri, 2 Dec 2005 00:07:29 -0800 (PST) Message-ID: <58cb370e0512020007n67f7ba30g7cae84c66b18859@mail.gmail.com> Date: Fri, 2 Dec 2005 09:07:29 +0100 From: Bartlomiej Zolnierkiewicz To: Jeff Garzik Subject: Re: [PATCH 1/2] libata: Remove dependence on host_set->dev for SAS Cc: dougg@torque.net, brking@us.ibm.com, Luben Tuikov , linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, t.schorpp@gmx.de In-Reply-To: <438FABF8.3020802@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Disposition: inline References: <4341A91A.3020000@us.ibm.com> <435E7105.4010105@pobox.com> <435E87E8.9010506@us.ibm.com> <435E8AC7.1080407@pobox.com> <435EB656.1040502@adaptec.com> <4360FAC1.8020409@us.ibm.com> <43850F0D.7040907@torque.net> <43851262.7020807@pobox.com> <58cb370e0511240012r64ad150eo90553b230992424e@mail.gmail.com> <438FABF8.3020802@pobox.com> Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 32 On 12/2/05, Jeff Garzik wrote: > Bartlomiej Zolnierkiewicz wrote: > > On 11/24/05, Jeff Garzik wrote: > > > >>Douglas Gilbert wrote: > >> > >>>I don't think a SATL is that easy. One SCSI command can > >>>translate into zero or more ATA commands. If it translates > >>>to multiple commands, then there is the possibility of an > >>>error prior to the last in the sequence of ATA commands > >>>(how to report; rollback needed ?). The SATL needs to hold > >>>state and needs a service thread if it is to support the > >>>IMMED bit on some commands (e.g. START STOP UNIT). > >> > >>It needs a conceptual service thread, not necessarily an explicit one. > >> > >>With REQUEST SENSE, I've demonstrated how to report errors with each > >>step in the sequence. With demo patches I've posted, I've demonstrated > >>(using qc->private_data) how to hold state. > >> > >> > >> > >>>libata still has a ways to go to catch up to SAT rev 7 > >>>but has made some good progress lately with the addition > >>>of the ATA pass through commands (lk 2.6.15-rc1 and onward). > >>>smartmontools (just prior to 5.34) now works with '-d ata' > >>>on libata-connected SATA disks. The '-d ata' ** overrides > >>>the guess of a SCSI disk based on the device node (e.g. > >>>/dev/sda) and uses the HDIO_DRIVE_CMD and HDIO_DRIVE_TASK > >>>ioctls. The absence of support for the HDIO_DRIVE_TASKFILE > >>>ioctl means that "selective" self-test can't be done. > >>>I'm not sure if moving smartmontools to the ATA PASS THROUGH > >>>SCSI commands will win back the "selective" self-test > >>>capability. Anyway, going to those ATA PASS THROUGH SCSI > >> > >>ATA passthru can do anything the legacy IDE ioctls can do (and more). > > > > > > [ definitely ATA passthru is the way to go but... ] > > > > discrete taskfiles? > > what is this? flagged taskfiles yes, this is a low priority but your statement is oversimplification and I don't even mentioned other "IDE ioctl", so: ATA passthru can do anything _important_ that legacy IDE ioctls can do (write cache [dis,en]abling?) > > multi-PIO? > > what is this? multi-sector PIO, such as READ MULTIPLE SECTORS? ATA short for multi sector-sector PIO > passthru can do that. not in the mainline, I've just checked libata-dev and it is OK > > setting transfer speed? > > That's not a limitation of passthru, but a limitation of the driver. I > don't yet see the value... Same for me... Bartlomiej - 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 From yang.geum.seok@gmail.com Fri Dec 2 00:39:21 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 00:41:16 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932147AbVLBIjb (ORCPT ); Fri, 2 Dec 2005 03:39:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932548AbVLBIja (ORCPT ); Fri, 2 Dec 2005 03:39:30 -0500 Received: from zproxy.gmail.com ([64.233.162.192]:36794 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S932147AbVLBIja convert rfc822-to-8bit (ORCPT ); Fri, 2 Dec 2005 03:39:30 -0500 Received: by zproxy.gmail.com with SMTP id 4so484775nzn for ; Fri, 02 Dec 2005 00:39:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=alYGiH1gnVko+FPFpTaFY3FGLEJxWjBLb8YdFZdA8cEsESqaIPoGN/P5LIOkKX/Zw9TuA/QseFA0LGZF05gD6AXKwVS5Op7JKU1QwxUnX7vlaNGDiRVZ8/Kk7VAxy38TEYT7fyoya7HCJl7MAlnAayRkJFGu0FqvhMT1BG1q1Zo= Received: by 10.65.191.8 with SMTP id t8mr1337593qbp; Fri, 02 Dec 2005 00:39:21 -0800 (PST) Received: by 10.65.163.10 with HTTP; Fri, 2 Dec 2005 00:39:21 -0800 (PST) Message-ID: Date: Fri, 2 Dec 2005 17:39:21 +0900 From: Yanggun To: linux-kernel@vger.kernel.org Subject: 2.6.14 + SATAII150 TX2Plus does not recognize MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 50 Hi, i am currently using linux kernel version 2.6.14 on x86 with Promise SATAII150 TX2Plus(250G SATA HDD Disk x 2). But, SATA HDD disk does not become. program execute result of "fdisk /dev/sda" is "Unable to read /dev/sda". Work well in linux kernel version 2.6.13.2. Do not act below since change as result that do debugging. "[SCSI] use scatter lists for all block pc requests and simplify hw handlers" - http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=392160335c798bbe94ab3aae6ea0c85d32b81bbc What should I do? Test Enviroment -------------- Kernel version: 2.6.14 SATA Controller: Promise SATAII150 TX2Plus SATA HDD: Western Digital 250G x 2 SATA Driver: http://www.promise.com/support/download/download2_eng.asp?productID=126&category=all&os=100# Log ---------------- Nov 24 18:08:27 sentry24 kernel: ulsata2:[info] Drive 1/0: WDC WD2500JS-22MHB0 488397167s 250059MB UDMA6 Nov 24 18:08:27 sentry24 kernel: ulsata2:[info] Drive 3/0: WDC WD2500JS-22MHB0 488397167s 250059MB UDMA6 Nov 24 18:08:27 sentry24 kernel: scsi0 : ulsata2 Nov 24 18:08:27 sentry24 kernel: Vendor: Model: Rev: Nov 24 18:08:27 sentry24 kernel: Type: Direct-Access ANSI SCSI revision: 00 Nov 24 18:08:27 sentry24 kernel: sda : sector size 0 reported, assuming 512. Nov 24 18:08:27 sentry24 kernel: SCSI device sda: 1 512-byte hdwr sectors (0 MB) Nov 24 18:08:27 sentry24 kernel: sda: asking for cache data failed Nov 24 18:08:27 sentry24 kernel: sda: assuming drive cache: write through Nov 24 18:08:27 sentry24 kernel: sda : sector size 0 reported, assuming 512. Nov 24 18:08:27 sentry24 kernel: SCSI device sda: 1 512-byte hdwr sectors (0 MB) Nov 24 18:08:27 sentry24 kernel: sda: asking for cache data failed Nov 24 18:08:27 sentry24 kernel: sda: assuming drive cache: write through Nov 24 18:08:27 sentry24 kernel: sda: sda1 Nov 24 18:08:27 sentry24 kernel: sd 0:0:0:0: Attached scsi disk sda Nov 24 18:08:27 sentry24 kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0 Nov 24 18:08:27 sentry24 kernel: Vendor: Model: Rev: Nov 24 18:08:27 sentry24 kernel: Type: Direct-Access ANSI SCSI revision: 00 Nov 24 18:08:27 sentry24 kernel: sdb : sector size 0 reported, assuming 512. Nov 24 18:08:27 sentry24 kernel: SCSI device sdb: 1 512-byte hdwr sectors (0 MB) Nov 24 18:08:27 sentry24 kernel: sdb: asking for cache data failed Nov 24 18:08:27 sentry24 kernel: sdb: assuming drive cache: write through Nov 24 18:08:27 sentry24 kernel: sdb : sector size 0 reported, assuming 512. Nov 24 18:08:27 sentry24 kernel: SCSI device sdb: 1 512-byte hdwr sectors (0 MB) Nov 24 18:08:27 sentry24 kernel: sdb: asking for cache data failed Nov 24 18:08:27 sentry24 kernel: sdb: assuming drive cache: write through Nov 24 18:08:27 sentry24 kernel: sdb: sdb1 Nov 24 18:08:27 sentry24 kernel: sd 0:0:2:0: Attached scsi disk sdb Nov 24 18:08:27 sentry24 kernel: sd 0:0:2:0: Attached scsi generic sg1 type 0 [root@test root]# lsmod Module Size Used by snd_pcm_oss 48288 0 snd_pcm 80520 1 snd_pcm_oss snd_timer 21508 1 snd_pcm snd_page_alloc 8456 1 snd_pcm snd_mixer_oss 17024 1 snd_pcm_oss lp 9412 0 parport 31816 1 lp snd 47076 4 snd_pcm_oss,snd_pcm,snd_timer,snd_mixer_oss soundcore 7776 1 snd sr_mod 15268 0 sg 34208 0 i810 20480 0 i830 24832 0 odcap 21488 2 button 5008 0 sbp2 21252 0 ohci1394 31540 0 ieee1394 87224 2 sbp2,ohci1394 pl2303 18948 0 usbserial 27368 1 pl2303 usb_storage 53696 0 uhci_hcd 30096 0 ide_scsi 14468 0 raid1 17920 0 md_mod 59088 1 raid1 ehci_hcd 29960 0 usbcore 106880 6 pl2303,usbserial,usb_storage,uhci_hcd,ehci_hcd e1000 99892 0 sd_mod 15888 0 ulsata2 132060 0 scsi_mod 122984 7 sr_mod,sg,sbp2,usb_storage,ide_scsi,sd_mod,ulsata2 [root@sentry24 root]# sfdisk -l Disk /dev/hda: 1007 cylinders, 16 heads, 63 sectors/track Units = cylinders of 516096 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/hda1 * 0+ 1006 1007- 507496+ 83 Linux /dev/hda2 0 - 0 0 0 Empty /dev/hda3 0 - 0 0 0 Empty /dev/hda4 0 - 0 0 0 Empty Disk /dev/sda: 0 cylinders, 64 heads, 32 sectors/track Warning: The partition table looks like it was made for C/H/S=*/255/63 (instead of 0/64/32). For this listing I'll assume that geometry. Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/sda1 0+ 30400 30401- 244196001 83 Linux /dev/sda2 0 - 0 0 0 Empty /dev/sda3 0 - 0 0 0 Empty /dev/sda4 0 - 0 0 0 Empty Disk /dev/sdb: 0 cylinders, 64 heads, 32 sectors/track Warning: The partition table looks like it was made for C/H/S=*/255/63 (instead of 0/64/32). For this listing I'll assume that geometry. Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/sdb1 0+ 30400 30401- 244196001 83 Linux /dev/sdb2 0 - 0 0 0 Empty /dev/sdb3 0 - 0 0 0 Empty /dev/sdb4 0 - 0 0 0 Empty [root@sentry24 root]# [root@sentry24 root]# sg_map -i -x /dev/sg0 0 0 0 0 0 /dev/sda WDC WD2500JS-00M /dev/sg1 0 0 2 0 0 /dev/sdb WDC WD2500JS-00M [root@sentry24 root]# [root@sentry24 root]# fdisk -l /dev/sda [root@sentry24 root]# fdisk /dev/sda Unable to read /dev/sda [root@sentry24 root]# [root@sentry24 root]# !parted parted --script /dev/sda mklabel msdos Error: Can't have a partition outside the disk! Error: Operation not permitted during read on /dev/sda Error: Operation not permitted during write on /dev/sda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From dougg@torque.net Fri Dec 2 02:28:48 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 02:28:08 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750905AbVLBK1x (ORCPT ); Fri, 2 Dec 2005 05:27:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750950AbVLBK1x (ORCPT ); Fri, 2 Dec 2005 05:27:53 -0500 Received: from zorg.st.net.au ([203.16.233.9]:58595 "EHLO borg.st.net.au") by vger.kernel.org with ESMTP id S1750905AbVLBK1w (ORCPT ); Fri, 2 Dec 2005 05:27:52 -0500 Received: from localhost (localhost [127.0.0.1]) by borg.st.net.au (Postfix) with ESMTP id 9F42D395219; Fri, 2 Dec 2005 20:27:45 +1000 (EST) Received: from borg.st.net.au ([203.16.233.9]) by localhost (borg.st.net.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10863-01; Fri, 2 Dec 2005 20:27:45 +1000 (EST) Received: from [192.168.48.80] (static-195.29.240.220.dsl.comindico.com.au [220.240.29.195]) by borg.st.net.au (Postfix) with ESMTP id 9CA6639520E; Fri, 2 Dec 2005 20:27:30 +1000 (EST) Message-ID: <439021E0.9040203@torque.net> Date: Fri, 02 Dec 2005 20:28:48 +1000 From: Douglas Gilbert Reply-To: dougg@torque.net User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bartlomiej Zolnierkiewicz CC: Jeff Garzik , brking@us.ibm.com, Luben Tuikov , linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, t.schorpp@gmx.de Subject: Re: [PATCH 1/2] libata: Remove dependence on host_set->dev for SAS References: <4341A91A.3020000@us.ibm.com> <435E7105.4010105@pobox.com> <435E87E8.9010506@us.ibm.com> <435E8AC7.1080407@pobox.com> <435EB656.1040502@adaptec.com> <4360FAC1.8020409@us.ibm.com> <43850F0D.7040907@torque.net> <43851262.7020807@pobox.com> <58cb370e0511240012r64ad150eo90553b230992424e@mail.gmail.com> <438FABF8.3020802@pobox.com> <58cb370e0512020007n67f7ba30g7cae84c66b18859@mail.gmail.com> In-Reply-To: <58cb370e0512020007n67f7ba30g7cae84c66b18859@mail.gmail.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at st.net.au Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 84 Bartlomiej Zolnierkiewicz wrote: > On 12/2/05, Jeff Garzik wrote: > >>Bartlomiej Zolnierkiewicz wrote: >> >>>On 11/24/05, Jeff Garzik wrote: >>> >>> >>>>Douglas Gilbert wrote: >>>> >>>> >>>>>I don't think a SATL is that easy. One SCSI command can >>>>>translate into zero or more ATA commands. If it translates >>>>>to multiple commands, then there is the possibility of an >>>>>error prior to the last in the sequence of ATA commands >>>>>(how to report; rollback needed ?). The SATL needs to hold >>>>>state and needs a service thread if it is to support the >>>>>IMMED bit on some commands (e.g. START STOP UNIT). >>>> >>>>It needs a conceptual service thread, not necessarily an explicit one. >>>> >>>>With REQUEST SENSE, I've demonstrated how to report errors with each >>>>step in the sequence. With demo patches I've posted, I've demonstrated >>>>(using qc->private_data) how to hold state. >>>> >>>> >>>> >>>> >>>>>libata still has a ways to go to catch up to SAT rev 7 >>>>>but has made some good progress lately with the addition >>>>>of the ATA pass through commands (lk 2.6.15-rc1 and onward). >>>>>smartmontools (just prior to 5.34) now works with '-d ata' >>>>>on libata-connected SATA disks. The '-d ata' ** overrides >>>>>the guess of a SCSI disk based on the device node (e.g. >>>>>/dev/sda) and uses the HDIO_DRIVE_CMD and HDIO_DRIVE_TASK >>>>>ioctls. The absence of support for the HDIO_DRIVE_TASKFILE >>>>>ioctl means that "selective" self-test can't be done. >>>>>I'm not sure if moving smartmontools to the ATA PASS THROUGH >>>>>SCSI commands will win back the "selective" self-test >>>>>capability. Anyway, going to those ATA PASS THROUGH SCSI >>>> >>>>ATA passthru can do anything the legacy IDE ioctls can do (and more). >>> >>> >>>[ definitely ATA passthru is the way to go but... ] >>> >>>discrete taskfiles? >> >>what is this? > > > flagged taskfiles > > yes, this is a low priority but your statement is oversimplification > and I don't even mentioned other "IDE ioctl", so: > > ATA passthru can do anything _important_ that legacy IDE ioctls > can do (write cache [dis,en]abling?) > > >>>multi-PIO? >> >>what is this? multi-sector PIO, such as READ MULTIPLE SECTORS? ATA > > > short for multi sector-sector PIO > > >>passthru can do that. > > > not in the mainline, I've just checked libata-dev and it is OK > > >>>setting transfer speed? >> >>That's not a limitation of passthru, but a limitation of the driver. I >>don't yet see the value... > > > Same for me... I noticed that the protocol field in the ATA_12 and ATA_16 pass through commands included hard reset, SRST and device reset. Would it be useful to implement these? Doug Gilbert - 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 From jgarzik@pobox.com Fri Dec 2 02:48:16 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 02:48:41 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932720AbVLBKsd (ORCPT ); Fri, 2 Dec 2005 05:48:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932721AbVLBKsc (ORCPT ); Fri, 2 Dec 2005 05:48:32 -0500 Received: from mail.dvmed.net ([216.237.124.58]:35552 "EHLO mail.dvmed.net") by vger.kernel.org with ESMTP id S932720AbVLBKsc (ORCPT ); Fri, 2 Dec 2005 05:48:32 -0500 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1Ei8Si-0006K7-7y; Fri, 02 Dec 2005 10:48:22 +0000 Message-ID: <43902670.6000607@pobox.com> Date: Fri, 02 Dec 2005 05:48:16 -0500 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dougg@torque.net CC: Bartlomiej Zolnierkiewicz , brking@us.ibm.com, Luben Tuikov , linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, t.schorpp@gmx.de Subject: Re: [PATCH 1/2] libata: Remove dependence on host_set->dev for SAS References: <4341A91A.3020000@us.ibm.com> <435E7105.4010105@pobox.com> <435E87E8.9010506@us.ibm.com> <435E8AC7.1080407@pobox.com> <435EB656.1040502@adaptec.com> <4360FAC1.8020409@us.ibm.com> <43850F0D.7040907@torque.net> <43851262.7020807@pobox.com> <58cb370e0511240012r64ad150eo90553b230992424e@mail.gmail.com> <438FABF8.3020802@pobox.com> <58cb370e0512020007n67f7ba30g7cae84c66b18859@mail.gmail.com> <439021E0.9040203@torque.net> In-Reply-To: <439021E0.9040203@torque.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Spam-Report: Spam detection software, running on the system "srv2.dvmed.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Douglas Gilbert wrote: > I noticed that the protocol field in the ATA_12 and > ATA_16 pass through commands included hard reset, > SRST and device reset. Would it be useful to implement > these? Yes, at least SRST should be implemented. [...] Content analysis details: (0.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.1 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [69.134.188.146 listed in dnsbl.sorbs.net] Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 93 Douglas Gilbert wrote: > I noticed that the protocol field in the ATA_12 and > ATA_16 pass through commands included hard reset, > SRST and device reset. Would it be useful to implement > these? Yes, at least SRST should be implemented. Jeff - 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 From htejun@gmail.com Fri Dec 2 03:04:50 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 03:05:46 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932237AbVLBLE4 (ORCPT ); Fri, 2 Dec 2005 06:04:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932721AbVLBLE4 (ORCPT ); Fri, 2 Dec 2005 06:04:56 -0500 Received: from zproxy.gmail.com ([64.233.162.197]:17850 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S932237AbVLBLEz (ORCPT ); Fri, 2 Dec 2005 06:04:55 -0500 Received: by zproxy.gmail.com with SMTP id 14so234642nzn for ; Fri, 02 Dec 2005 03:04:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Zx0dFRa5IAiAVjZcjEUHUp5PfYZEFxlHy/g3ZgSd9gDlJRMlE3vi6xCt31kuUpuEuoSwATNS3WzA+nB3Ctv/zXcIsDAgSaSdy+uxFz09USMy3fRKEdpZhsVsfUkblnL3WXMqDSEvRtYLipCv1e9Djg27EEURavqu2sOej0XYU/A= Received: by 10.36.224.57 with SMTP id w57mr2453336nzg; Fri, 02 Dec 2005 03:04:54 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id m2sm1548999nzf.2005.12.02.03.04.53; Fri, 02 Dec 2005 03:04:54 -0800 (PST) Received: from [127.0.0.1] (htj.dyndns.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by htj.dyndns.org (Postfix) with ESMTP id 8E76D184251; Fri, 2 Dec 2005 20:04:50 +0900 (KST) Message-ID: <43902A52.9040909@gmail.com> Date: Fri, 02 Dec 2005 20:04:50 +0900 From: Tejun Heo User-Agent: Debian Thunderbird 1.0.7 (X11/20051019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yanggun CC: linux-kernel@vger.kernel.org Subject: Re: 2.6.14 + SATAII150 TX2Plus does not recognize References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 99 Yanggun wrote: > Hi, > > i am currently using linux kernel version 2.6.14 on x86 with Promise > SATAII150 TX2Plus(250G SATA HDD Disk x 2). > > But, SATA HDD disk does not become. program execute result of "fdisk > /dev/sda" is "Unable to read /dev/sda". > > Work well in linux kernel version 2.6.13.2. > > Do not act below since change as result that do debugging. > "[SCSI] use scatter lists for all block pc requests and > simplify hw handlers" > - http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=392160335c798bbe94ab3aae6ea0c85d32b81bbc > > What should I do? > Your controller is probably supported by sata_promise driver included in the kernel. Just use the standard driver. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From andersen@codepoet.org Fri Dec 2 04:35:54 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 04:35:59 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750713AbVLBMf4 (ORCPT ); Fri, 2 Dec 2005 07:35:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750714AbVLBMf4 (ORCPT ); Fri, 2 Dec 2005 07:35:56 -0500 Received: from codepoet.org ([166.70.99.138]:38363 "EHLO codepoet.org") by vger.kernel.org with ESMTP id S1750713AbVLBMfz (ORCPT ); Fri, 2 Dec 2005 07:35:55 -0500 Received: by codepoet.org (Codepoet.org Mail Daemon, from userid 1000) id 7F9702E8403; Fri, 2 Dec 2005 05:35:54 -0700 (MST) Date: Fri, 2 Dec 2005 05:35:54 -0700 From: Erik Andersen To: linux-ide@vger.kernel.org Cc: Jeff Garzik Subject: Draft libata GET_IDENTITY and DRIVE_TASKFILE Message-ID: <20051202123554.GA14781@codepoet.org> References: <20051201214837.GA25256@havoc.gtf.org> <20051201231008.GA7921@codepoet.org> <438FA62D.2040707@pobox.com> <20051202022309.GA10639@codepoet.org> <438FB468.6090504@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438FB468.6090504@pobox.com> X-No-Junk-Mail: I do not want to get *any* junk mail. User-Agent: Mutt/1.5.9i Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 137 Here is a first draft patch adding support for HDIO_GET_IDENTITY and HDIO_DRIVE_TASKFILE to libata. Unlike the older ioctl-get-identity.patch, this returns the actual drive identity rather than kluding out a few fields. It needs a bit more cleanup, and review, but the IDENTITY stuff does produce output matching the sort coming from the ide driver and is enough to allow i.e. 'smartctl -i -a -d ata /dev/sda' to be happy doing its thing. If this goes in, smartctl will be able to Just Work for sata -- and there will be much rejoicing. :-) I opted to copy and adapt the byteswapping code from ide_fix_driveid() rather than making a function call, since there is no guarantee the older ide driver would be compiled in and making the routine shared seems more bother than it's worth. The TASKFILE stuff seems to sortof work, but could use some scrubbing from someone with a better understanding of how libata works, especialy the part doing 'switch (taskfile->data_phase)' where you can no doubt see I had no idea what I was doing. It'd be great to get some review and extra eyeballs to weed out the problems doubtless lurking in here. Please CC me as I'm not currently subscribed to linux-ide. -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- --- linux/drivers/scsi.orig/libata-scsi.c 2005-12-01 22:51:48 +0000 +++ linux/drivers/scsi/libata-scsi.c 2005-12-02 10:56:01 +0000 @@ -273,6 +273,366 @@ return rc; } +/** + * ata_taskfile_ioctl - Handler for HDIO_DRIVE_TASKFILE ioctl + * @scsidev: Device to which we are issuing command + * @arg: User provided data for issuing command + * + * LOCKING: + * Defined by the SCSI layer. We don't really care. + * + * RETURNS: + * Zero on success, negative errno on error. + */ +int ata_taskfile_ioctl(struct scsi_device *scsidev, void __user *arg) +{ + int rc = 0, tasksize = sizeof(struct ide_task_request_s); + u8 *outbuf = NULL; + u8 *inbuf = NULL; + u8 scsi_cmd[MAX_COMMAND_SIZE]; + struct scsi_request *sreq; + struct ide_task_request_s *taskfile; + struct hd_drive_task_hdr *task; + struct hd_drive_hob_hdr *hob; + + if (NULL == (void *)arg) + return -EINVAL; + + taskfile = kmalloc(tasksize, GFP_KERNEL); + if (NULL == (void *)taskfile) + return -ENOMEM; + memset(taskfile, 0, tasksize); + + if (copy_from_user(taskfile, arg, tasksize)) { + kfree(taskfile); + return -EFAULT; + } + task = (struct hd_drive_task_hdr *) taskfile->io_ports; + hob = (struct hd_drive_hob_hdr *) taskfile->hob_ports; + + memset(scsi_cmd, 0, sizeof(scsi_cmd)); + scsi_cmd[0] = ATA_16; + //scsi_cmd[1] = hob->data; + //scsi_cmd[2] = task->data; + scsi_cmd[3] = hob->feature; + scsi_cmd[4] = task->feature; + scsi_cmd[5] = hob->sector_count; + scsi_cmd[6] = task->sector_count; + scsi_cmd[7] = hob->sector_number; + scsi_cmd[8] = task->sector_number; + scsi_cmd[9] = hob->low_cylinder; + scsi_cmd[10] = task->low_cylinder; + scsi_cmd[11] = hob->high_cylinder; + scsi_cmd[12] = task->high_cylinder; + scsi_cmd[13] = hob->control; + scsi_cmd[14] = task->command; + + sreq = scsi_allocate_request(scsidev); + if (!sreq) { + rc = -EINTR; + goto error; + } + + switch (taskfile->data_phase) + { + case TASKFILE_IN: + case TASKFILE_MULTI_IN: + //sreq->sr_data_direction = SCSI_DATA_READ; + scsi_cmd[1] = (4 << 1); /* PIO Data-in */ + scsi_cmd[2] = 0x0e; + sreq->sr_data_direction = DMA_FROM_DEVICE; + break; + case TASKFILE_IN_DMA: + case TASKFILE_IN_DMAQ: + scsi_cmd[1] = (6 << 1); /* DMA */ + scsi_cmd[2] = 0x0e; + sreq->sr_data_direction = DMA_FROM_DEVICE; + break; + case TASKFILE_OUT: + case TASKFILE_MULTI_OUT: + scsi_cmd[1] = (5 << 1); /* PIO Data-out */ + scsi_cmd[2] = 0x0e; + //sreq->sr_data_direction = SCSI_DATA_WRITE; + sreq->sr_data_direction = DMA_TO_DEVICE; + break; + case TASKFILE_OUT_DMA: + case TASKFILE_OUT_DMAQ: + scsi_cmd[1] = (6 << 1); /* DMA */ + scsi_cmd[2] = 0x0e; + sreq->sr_data_direction = DMA_TO_DEVICE; + break; + case TASKFILE_NO_DATA: + scsi_cmd[1] = (3 << 1); /* Non-data */ + scsi_cmd[2] = 0; + sreq->sr_data_direction = DMA_NONE; + break; + default: + rc = -EFAULT; + goto error; + } + + /* Given the nature of scsi_wait_req, we can either + * read, or we can write. Not both. */ + if (taskfile->out_size && taskfile->in_size) { + rc = -EFAULT; + goto error; + } + + if (taskfile->out_size) { + outbuf = kmalloc(taskfile->out_size, GFP_KERNEL); + if (outbuf == NULL) { + rc = -ENOMEM; + goto error; + } + memset(outbuf, 0, taskfile->out_size); + if (copy_from_user(outbuf, (void *)arg + tasksize, + taskfile->out_size)) + { + rc = -EFAULT; + goto error; + } + /* Good values for timeout and retries? Values below + from scsi_ioctl_send_command() for default case... */ + scsi_wait_req(sreq, scsi_cmd, outbuf, + taskfile->out_size, (10*HZ), 5); + } else if (taskfile->in_size) { + inbuf = kmalloc(taskfile->in_size, GFP_KERNEL); + if (inbuf == NULL) { + rc = -ENOMEM; + goto error; + } + memset(inbuf, 0, taskfile->in_size); + if (copy_from_user(inbuf, (void *)arg + tasksize + + taskfile->out_size, taskfile->in_size)) + { + rc = -EFAULT; + goto error; + } + /* Good values for timeout and retries? Values below + from scsi_ioctl_send_command() for default case... */ + scsi_wait_req(sreq, scsi_cmd, inbuf, + taskfile->in_size, (10*HZ), 5); + } else { + /* Good values for timeout and retries? Values below + from scsi_ioctl_send_command() for default case... */ + scsi_wait_req(sreq, scsi_cmd, NULL, 0, (10*HZ), 5); + } + + if (sreq->sr_result) { + rc = -EIO; + goto error; + } + + /* Need code to retrieve data from check condition? */ + + if (copy_to_user(arg, taskfile, tasksize)) { + rc = -EFAULT; + goto error; + } + + if (taskfile->out_size && copy_to_user((void *)arg + tasksize, + outbuf, taskfile->out_size)) + { + rc = -EFAULT; + goto error; + } else if (taskfile->in_size && copy_to_user( + (void *)arg + tasksize + taskfile->out_size, + inbuf, taskfile->in_size)) + { + rc = -EFAULT; + goto error; + } + + +error: + scsi_release_request(sreq); + + kfree(taskfile); + if (inbuf) + kfree(inbuf); + if (outbuf) + kfree(outbuf); + return rc; +} + +static void ide_fixstring (u8 *s, const int bytecount) +{ + u8 *p = s, *end = &s[bytecount & ~1]; /* bytecount must be even */ + +#ifndef __BIG_ENDIAN +# ifdef __LITTLE_ENDIAN + /* convert from big-endian to host byte order */ + for (p = end ; p != s;) { + unsigned short *pp = (unsigned short *) (p -= 2); + *pp = ntohs(*pp); + } +# else +# error "Please fix " +# endif +#endif + /* strip leading blanks */ + while (s != end && *s == ' ') + ++s; + /* compress internal blanks and strip trailing blanks */ + while (s != end && *s) { + if (*s++ != ' ' || (s != end && *s && *s != ' ')) + *p++ = *(s-1); + } + /* wipe out trailing garbage */ + while (p != end) + *p++ = '\0'; +} + +static void ide_fix_driveid (struct hd_driveid *id) +{ +#ifndef __LITTLE_ENDIAN +# ifdef __BIG_ENDIAN + int i; + u16 *stringcast; + + id->config = __le16_to_cpu(id->config); + id->cyls = __le16_to_cpu(id->cyls); + id->reserved2 = __le16_to_cpu(id->reserved2); + id->heads = __le16_to_cpu(id->heads); + id->track_bytes = __le16_to_cpu(id->track_bytes); + id->sector_bytes = __le16_to_cpu(id->sector_bytes); + id->sectors = __le16_to_cpu(id->sectors); + id->vendor0 = __le16_to_cpu(id->vendor0); + id->vendor1 = __le16_to_cpu(id->vendor1); + id->vendor2 = __le16_to_cpu(id->vendor2); + stringcast = (u16 *)&id->serial_no[0]; + for (i = 0; i < (20/2); i++) + stringcast[i] = __le16_to_cpu(stringcast[i]); + id->buf_type = __le16_to_cpu(id->buf_type); + id->buf_size = __le16_to_cpu(id->buf_size); + id->ecc_bytes = __le16_to_cpu(id->ecc_bytes); + stringcast = (u16 *)&id->fw_rev[0]; + for (i = 0; i < (8/2); i++) + stringcast[i] = __le16_to_cpu(stringcast[i]); + stringcast = (u16 *)&id->model[0]; + for (i = 0; i < (40/2); i++) + stringcast[i] = __le16_to_cpu(stringcast[i]); + id->dword_io = __le16_to_cpu(id->dword_io); + id->reserved50 = __le16_to_cpu(id->reserved50); + id->field_valid = __le16_to_cpu(id->field_valid); + id->cur_cyls = __le16_to_cpu(id->cur_cyls); + id->cur_heads = __le16_to_cpu(id->cur_heads); + id->cur_sectors = __le16_to_cpu(id->cur_sectors); + id->cur_capacity0 = __le16_to_cpu(id->cur_capacity0); + id->cur_capacity1 = __le16_to_cpu(id->cur_capacity1); + id->lba_capacity = __le32_to_cpu(id->lba_capacity); + id->dma_1word = __le16_to_cpu(id->dma_1word); + id->dma_mword = __le16_to_cpu(id->dma_mword); + id->eide_pio_modes = __le16_to_cpu(id->eide_pio_modes); + id->eide_dma_min = __le16_to_cpu(id->eide_dma_min); + id->eide_dma_time = __le16_to_cpu(id->eide_dma_time); + id->eide_pio = __le16_to_cpu(id->eide_pio); + id->eide_pio_iordy = __le16_to_cpu(id->eide_pio_iordy); + for (i = 0; i < 2; ++i) + id->words69_70[i] = __le16_to_cpu(id->words69_70[i]); + for (i = 0; i < 4; ++i) + id->words71_74[i] = __le16_to_cpu(id->words71_74[i]); + id->queue_depth = __le16_to_cpu(id->queue_depth); + for (i = 0; i < 4; ++i) + id->words76_79[i] = __le16_to_cpu(id->words76_79[i]); + id->major_rev_num = __le16_to_cpu(id->major_rev_num); + id->minor_rev_num = __le16_to_cpu(id->minor_rev_num); + id->command_set_1 = __le16_to_cpu(id->command_set_1); + id->command_set_2 = __le16_to_cpu(id->command_set_2); + id->cfsse = __le16_to_cpu(id->cfsse); + id->cfs_enable_1 = __le16_to_cpu(id->cfs_enable_1); + id->cfs_enable_2 = __le16_to_cpu(id->cfs_enable_2); + id->csf_default = __le16_to_cpu(id->csf_default); + id->dma_ultra = __le16_to_cpu(id->dma_ultra); + id->trseuc = __le16_to_cpu(id->trseuc); + id->trsEuc = __le16_to_cpu(id->trsEuc); + id->CurAPMvalues = __le16_to_cpu(id->CurAPMvalues); + id->mprc = __le16_to_cpu(id->mprc); + id->hw_config = __le16_to_cpu(id->hw_config); + id->acoustic = __le16_to_cpu(id->acoustic); + id->msrqs = __le16_to_cpu(id->msrqs); + id->sxfert = __le16_to_cpu(id->sxfert); + id->sal = __le16_to_cpu(id->sal); + id->spg = __le32_to_cpu(id->spg); + id->lba_capacity_2 = __le64_to_cpu(id->lba_capacity_2); + for (i = 0; i < 22; i++) + id->words104_125[i] = __le16_to_cpu(id->words104_125[i]); + id->last_lun = __le16_to_cpu(id->last_lun); + id->word127 = __le16_to_cpu(id->word127); + id->dlf = __le16_to_cpu(id->dlf); + id->csfo = __le16_to_cpu(id->csfo); + for (i = 0; i < 26; i++) + id->words130_155[i] = __le16_to_cpu(id->words130_155[i]); + id->word156 = __le16_to_cpu(id->word156); + for (i = 0; i < 3; i++) + id->words157_159[i] = __le16_to_cpu(id->words157_159[i]); + id->cfa_power = __le16_to_cpu(id->cfa_power); + for (i = 0; i < 14; i++) + id->words161_175[i] = __le16_to_cpu(id->words161_175[i]); + for (i = 0; i < 31; i++) + id->words176_205[i] = __le16_to_cpu(id->words176_205[i]); + for (i = 0; i < 48; i++) + id->words206_254[i] = __le16_to_cpu(id->words206_254[i]); + id->integrity_word = __le16_to_cpu(id->integrity_word); +# else +# error "Please fix " +# endif +#endif + ide_fixstring(id->model, sizeof(id->model)); + ide_fixstring(id->fw_rev, sizeof(id->fw_rev)); + ide_fixstring(id->serial_no, sizeof(id->serial_no)); +} + +/** + * ata_identify_ioctl - Handler for HDIO_GET_IDENTITY ioctl + * @scsidev: Device to which we are issuing command + * @id: a SECTOR_SIZE buffer in which to return the ATA identity + * + * LOCKING: + * Defined by the SCSI layer. We don't really care. + * + * RETURNS: + * Zero on success, negative errno on error. + */ +int ata_identify_ioctl(struct scsi_device *scsidev, + int cmd, u8 *argbuf) +{ + int rc = 0; + u8 scsi_cmd[MAX_COMMAND_SIZE]; + struct scsi_request *sreq; + struct hd_driveid *id; + + sreq = scsi_allocate_request(scsidev); + if (!sreq) + return -EINTR; + + memset(scsi_cmd, 0, sizeof(scsi_cmd)); + scsi_cmd[0] = ATA_16; + scsi_cmd[14] = cmd; /* WIN_IDENTIFY or WIN_PIDENTIFY */ + scsi_cmd[1] = (4 << 1); /* PIO Data-in */ + scsi_cmd[2] = 0x0e; /* no off.line or cc, read from dev, + block count in sector count field */ + sreq->sr_data_direction = DMA_FROM_DEVICE; + + /* Good values for timeout and retries? Values below + from scsi_ioctl_send_command() for default case... */ + scsi_wait_req(sreq, scsi_cmd, argbuf, SECTOR_SIZE, (10*HZ), 5); + + if (sreq->sr_result) { + rc = -EIO; + goto error; + } + + /* Need code to retrieve data from check condition? */ + + id = (struct hd_driveid *) argbuf; + ide_fix_driveid(id); + +error: + scsi_release_request(sreq); + return rc; +} + int ata_scsi_ioctl(struct scsi_device *scsidev, int cmd, void __user *arg) { struct ata_port *ap; @@ -312,6 +672,39 @@ return -EACCES; return ata_task_ioctl(scsidev, arg); + case HDIO_DRIVE_TASKFILE: + if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_RAWIO)) + return -EACCES; + return ata_taskfile_ioctl(scsidev, arg); + + case HDIO_GET_IDENTITY: + case HDIO_OBSOLETE_IDENTITY: + { + int ret, idcmd; + u8 *argbuf; + + if (!capable(CAP_SYS_RAWIO)) + return -EACCES; + + argbuf = kmalloc(SECTOR_SIZE, GFP_KERNEL); + if (NULL == (void *)argbuf) { + return -ENOMEM; + } + + idcmd = WIN_IDENTIFY; + if (!atapi_enabled && dev->class == ATA_DEV_ATAPI) { + idcmd = WIN_PIDENTIFY; + } + ret = ata_identify_ioctl(scsidev, idcmd, argbuf); + if (ret!=0 || copy_to_user((char *)arg, (char *)argbuf, + (cmd == HDIO_GET_IDENTITY) ? + sizeof(struct hd_driveid) : 142)) + { + ret = -EFAULT; + } + kfree(argbuf); + return ret; + } default: rc = -ENOTTY; break; - 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 From yang.geum.seok@gmail.com Fri Dec 2 04:36:45 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 04:37:47 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750714AbVLBMgt (ORCPT ); Fri, 2 Dec 2005 07:36:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750717AbVLBMgt (ORCPT ); Fri, 2 Dec 2005 07:36:49 -0500 Received: from zproxy.gmail.com ([64.233.162.194]:60437 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S1750714AbVLBMgs convert rfc822-to-8bit (ORCPT ); Fri, 2 Dec 2005 07:36:48 -0500 Received: by zproxy.gmail.com with SMTP id 34so48867nzf for ; Fri, 02 Dec 2005 04:36:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bs+Kr0HGcPUQL5/8FzAVnta6sve3f+nVqzNmULutgtDfWS5t+9pXZag5At2mcjO6rMMapv/ZxnFcle6J+Gq5gx/Llf/6PbJ3ltCBDbcwljpUJfcDEu6obIve5VP+C7+mLQYeUBVFoWQZxUT4Y6I6PPvedL76rFBMzAzf/Od2qp8= Received: by 10.64.183.2 with SMTP id g2mr1434998qbf; Fri, 02 Dec 2005 04:36:45 -0800 (PST) Received: by 10.65.163.10 with HTTP; Fri, 2 Dec 2005 04:36:45 -0800 (PST) Message-ID: Date: Fri, 2 Dec 2005 21:36:45 +0900 From: Yanggun To: Tejun Heo Subject: Re: 2.6.14 + SATAII150 TX2Plus does not recognize Cc: linux-kernel@vger.kernel.org In-Reply-To: <43902A52.9040909@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Disposition: inline References: <43902A52.9040909@gmail.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 138 thanks. but sata_promise driver not seem to support hot-swap. As following message is said, it becomes block. Even if use irqpoll option, result is same. I want to use hot-swap. Nov 18 03:19:36 kernel: irq 11: nobody cared (try booting with the "irqpoll" option) Nov 18 03:19:36 kernel: [__report_bad_irq+42/141] __report_bad_irq+0x2a/0x8d Nov 18 03:19:36 kernel: [note_interrupt+158/247] note_interrupt+0x9e/0xf7 Nov 18 03:19:36 kernel: [__do_IRQ+261/292] __do_IRQ+0x105/0x124 Nov 18 03:19:36 kernel: [do_IRQ+82/124] do_IRQ+0x52/0x7c Nov 18 03:19:36 kernel: ======================= Nov 18 03:19:36 kernel: [common_interrupt+26/32] common_interrupt+0x1a/0x20 Nov 18 03:19:36 kernel: [__do_softirq+58/156] __do_softirq+0x3a/0x9c Nov 18 03:19:36 kernel: [do_softirq+112/116] do_softirq+0x70/0x74 Nov 18 03:19:36 kernel: ======================= Nov 18 03:19:36 kernel: [irq_exit+56/58] irq_exit+0x38/0x3a Nov 18 03:19:36 kernel: [do_IRQ+89/124] do_IRQ+0x59/0x7c Nov 18 03:19:36 kernel: [common_interrupt+26/32] common_interrupt+0x1a/0x20 Nov 18 03:19:36 gconfd (root-2818): Received signal 1, shutting down cleanly Nov 18 03:19:55 kernel: [unix_poll+96/180] unix_poll+0x60/0xb4 Nov 18 03:19:55 gconfd (root-2818): Exiting Nov 18 03:19:55 kernel: [get_offset_tsc+14/23] get_offset_tsc+0xe/0x17 Nov 18 03:19:55 kernel: [do_gettimeofday+24/176] do_gettimeofday+0x18/0xb0 Nov 18 03:19:55 kernel: [sys_gettimeofday+39/127] sys_gettimeofday+0x27/0x7f Nov 18 03:19:55 kernel: [syscall_call+7/11] syscall_call+0x7/0xb Nov 18 03:19:55 kernel: handlers: 2005/12/2, Tejun Heo : > Yanggun wrote: > > Hi, > > > > i am currently using linux kernel version 2.6.14 on x86 with Promise > > SATAII150 TX2Plus(250G SATA HDD Disk x 2). > > > > But, SATA HDD disk does not become. program execute result of "fdisk > > /dev/sda" is "Unable to read /dev/sda". > > > > Work well in linux kernel version 2.6.13.2. > > > > Do not act below since change as result that do debugging. > > "[SCSI] use scatter lists for all block pc requests and > > simplify hw handlers" > > - http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=392160335c798bbe94ab3aae6ea0c85d32b81bbc > > > > What should I do? > > > > Your controller is probably supported by sata_promise driver included in > the kernel. Just use the standard driver. > > -- > tejun > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From htejun@gmail.com Fri Dec 2 04:59:11 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 05:00:06 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750723AbVLBM7S (ORCPT ); Fri, 2 Dec 2005 07:59:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750729AbVLBM7S (ORCPT ); Fri, 2 Dec 2005 07:59:18 -0500 Received: from zproxy.gmail.com ([64.233.162.203]:18498 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S1750723AbVLBM7R (ORCPT ); Fri, 2 Dec 2005 07:59:17 -0500 Received: by zproxy.gmail.com with SMTP id 14so261588nzn for ; Fri, 02 Dec 2005 04:59:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=eX3B/dK0bCtsEwikLMPNGoATSnZW5UQ+NCwg4TOWX7BnZJpxjowWMmx3l3+u8pF4qApkDtz8LTz8otI1o1B2pT5EW+8NQvNtERG4aEpQPl6UqSK9YLfhN6/PJzYlwuKBA4b2pt4V/vGfTkfx/twvzDOkhsTvO0vIEU7DCzIzNSw= Received: by 10.37.22.8 with SMTP id z8mr2543537nzi; Fri, 02 Dec 2005 04:59:16 -0800 (PST) Received: from htj.dyndns.org ( [221.139.199.105]) by mx.gmail.com with ESMTP id c1sm1609197nzd.2005.12.02.04.59.15; Fri, 02 Dec 2005 04:59:16 -0800 (PST) Received: from [127.0.0.1] (htj.dyndns.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by htj.dyndns.org (Postfix) with ESMTP id 026DF184180; Fri, 2 Dec 2005 21:59:12 +0900 (KST) Message-ID: <4390451F.9020903@gmail.com> Date: Fri, 02 Dec 2005 21:59:11 +0900 From: Tejun Heo User-Agent: Debian Thunderbird 1.0.7 (X11/20051019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yanggun CC: linux-kernel@vger.kernel.org Subject: Re: 2.6.14 + SATAII150 TX2Plus does not recognize References: <43902A52.9040909@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 146 Yanggun wrote: > thanks. > > but sata_promise driver not seem to support hot-swap. As following > message is said, it becomes block. Even if use irqpoll option, result > is same. > > I want to use hot-swap. > Yeap, the standard doesn't support hot-swap yet. I think either you gotta stay with 2.6.13 for the time being or wait for promise to update their driver. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From thomas.jarosch@intra2net.com Fri Dec 2 08:28:35 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 08:28:50 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750806AbVLBQ2t convert rfc822-to-quoted-printable (ORCPT ); Fri, 2 Dec 2005 11:28:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750813AbVLBQ2t (ORCPT ); Fri, 2 Dec 2005 11:28:49 -0500 Received: from rs02.intra2net.com ([81.169.173.116]:59863 "EHLO rs02.intra2net.com") by vger.kernel.org with ESMTP id S1750806AbVLBQ2s convert rfc822-to-8bit (ORCPT ); Fri, 2 Dec 2005 11:28:48 -0500 Received: from intranator.m.i2n (unknown [172.16.1.99]) by rs02.intra2net.com (Postfix) with ESMTP id B571A5EB8; Fri, 2 Dec 2005 17:28:37 +0100 (CET) Received: from localhost (intranator.m.i2n [127.0.0.1]) by localhost (Postfix) with ESMTP id 2658116C; Fri, 2 Dec 2005 17:28:37 +0100 (CET) Received: from storm.m.i2n (storm.m.i2n [172.16.1.2]) by intranator.m.i2n (Postfix) with ESMTP id DEEA314C; Fri, 2 Dec 2005 17:28:35 +0100 (CET) From: Thomas Jarosch Organization: Intra2net AG To: linux-kernel@vger.kernel.org Subject: sata performance with 2.4.32 + latest libata Date: Fri, 2 Dec 2005 17:28:35 +0100 User-Agent: KMail/1.8.3 Cc: linux-ide@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Disposition: inline Message-Id: <200512021728.35130.thomas.jarosch@intra2net.com> X-Virus-Scanned: by Intranator (www.intranator.com) with AMaViS and F-Secure AntiVirus X-Spam-Status: hits=-1.8 tests=[ALL_TRUSTED=-1.8] X-Spam-Level: 982 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 207 Hello, I just tried kernel 2.4.32 + latest libata patches from 2005-12-01 after my performance problems described here: http://marc.theaimsgroup.com/?l=3Dlinux-kernel&m=3D113171290329839 Now the machine is performing very fast :-) Results with 2.4.32 + libata latest: Version 1.03 ------Sequential Output------ --Sequential Input- -= -Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- -= -Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP = /sec %CP proliant 2G 33294 91 57592 20 26778 5 30885 77 56081 5 1= 74.2 0 ------Sequential Create------ --------Random Create= -------- -Create-- --Read--- -Delete-- -Create-- --Read--- -= Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP = /sec %CP 16 27313 100 +++++ +++ 26421 99 27285 101 +++++ +++ 2= 1477 89 proliant,2G,33294,91,57592,20,26778,5,30885,77,56081,5,174.2,0,16,27313= ,100,+++++,+++,26421,99,27285,101,+++++,+++,21477,89 Previous results with kernel 2.4.32-rc3: Version =A01.03 =A0 =A0 =A0 ------Sequential Output------ --Sequential = Input- --Random- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -Per Chr- --Block-- -Rewrite- -= Per Chr- --Block-- --Seeks-- Machine =A0 =A0 =A0 =A0Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/s= ec %CP =A0/sec %CP proliant =A0 =A0 =A0 =A0 2G 10523 =A028 11532 =A0 3 =A07162 =A0 1 24271= =A060 53495 =A0 5 164.3 =A0 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ------Sequential Create------ -= -------Random Create-------- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -Create-- --Read--- -Delete-- -= Create-- --Read--- -Delete-- =A0 =A0 =A0 =A0 =A0 =A0 =A0 files =A0/sec %CP =A0/sec %CP =A0/sec %CP =A0= /sec %CP =A0/sec %CP =A0/sec %CP =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A016 30498 100 +++++ +++ 27244 =A098 2= 9630 =A099 +++++ +++ 11587 =A046 proliant,2G,10523,28,11532,3,7162,1,24271,60,53495,5,164.3,0,16,30498,1= 00,+++++,+++,27244,98,29630,99,+++++,+++,11587,46 A RAID1 rebuild went from 6-8 mb/s to this: [=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>...] recovery =3D= 85.9% (2202816/2562240) finish=3D0.1min speed=3D56280K/sec Thanks Jeff, you rock. Thomas - 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 From davidsen@tmr.com Fri Dec 2 08:32:52 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 08:20:51 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750822AbVLBQU3 (ORCPT ); Fri, 2 Dec 2005 11:20:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750826AbVLBQU3 (ORCPT ); Fri, 2 Dec 2005 11:20:29 -0500 Received: from mail.tmr.com ([64.65.253.246]:16793 "EHLO gaimboi.tmr.com") by vger.kernel.org with ESMTP id S1750822AbVLBQU2 (ORCPT ); Fri, 2 Dec 2005 11:20:28 -0500 Received: from [127.0.0.1] (gaimboi.tmr.com [127.0.0.1]) by gaimboi.tmr.com (8.12.8/8.12.8) with ESMTP id jB2GWqqd024231; Fri, 2 Dec 2005 11:32:53 -0500 Message-ID: <43907734.6090207@tmr.com> Date: Fri, 02 Dec 2005 11:32:52 -0500 From: Bill Davidsen Organization: TMR Associates Inc, Schenectady NY User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.11) Gecko/20050729 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luke-Jr , Linux Kernel mailing List Subject: Re: ide-cd doesn't replace ide-scsi? References: <200511281218.17141.luke-jr@utopios.org> <438B70AA.7090805@tmr.com> <200511291912.21255.luke-jr@utopios.org> In-Reply-To: <200511291912.21255.luke-jr@utopios.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 203 Luke-Jr wrote: > On Monday 28 November 2005 21:03, you wrote: > >>Luke-Jr wrote: >> >>>Note: results are with 2.6.13 (-gentoo-r4 + supermount) and 2.6.14 >>>(-gentoo) I've been struggling with burning DVD+R DL discs and upgrading >>>the firmware on my DVD burner, and just today decided to rmmod ide-cd and >>>try using ide-scsi. Turns out it works... so is ide-cd *supposed* to >>>handle cases other than simple reading and burning or is this a bug? If >>>not a bug, should ide-scsi really be marked as deprecated? >>>Also, two bugs with ide-scsi: >>>1. On loading the module, it detects and allocates 6 SCSI devices for a >>>single DVD burner (Toshiba ODD-DVD SD-R5272); kernel log for this event >>>attached 2. On attempted unloading of the module, rmmod says 'Killed' and >>>the module stays put, corrupt. There was some kind of error in dmesg, but >>>it appears to have avoided syslog-- If I see it again, I'll save it. >> >>I think you may have the probe-all-LUNs set, and a CD burner which >>responds to more than one. That's one possible cause for this. > > > Yep, it was set. I'll try turning it off. > > >>Unfortunately using ide-cd still doesn't have the code set to allow all >>burning features to work if you are not root. Even if you have read+write >>there's one command you need to do multi-session which is only allowed to >>root. Works fine for single sessions, I guess that's all someone uses. > > > I'm pretty sure I tried doing everything as root days before I even considered > ide-scsi... In regards to firmware upgrades, I wouldn't expect non-root to be > allowed to, even with rw access. Actually, a single session burn seems to work (I'm doing tests as soon as I get a compile of the latest kernel). What doesn't (or didn't) work is multisession, even with r/w "cdrecord -msinfo" fails, which is how you get the starting info for the next session. > > >>Haven't tried unloading the module, so I have no advice on that other than >>"don't do that." > > > Well, I had reasons... =p > The first time, I was going to switch back to ide-cd (for DMA), and the second > time was because the drive was stuck on Busy and I'm not sure of any (other?) > way to reset it without hotplugging the IDE power cable (which I'm sure isn't > a good idea and I don't want to risk). I thought ide-scsi now did DMA, at least for data burns. Don't know about audio, I occasionally do an audio burn, but my main machine for burning uses ide-cd, so it's not an issue. I saw a note somewhere about using capabilities on the cdrecord executable to allow the realtime sched to be set, but I don't seem to find it now. Maybe it was a question rather than an example :-( -- bill davidsen CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From randy_d_dunlap@linux.intel.com Fri Dec 2 10:03:50 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 10:14:10 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750892AbVLBSOI (ORCPT ); Fri, 2 Dec 2005 13:14:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750904AbVLBSOI (ORCPT ); Fri, 2 Dec 2005 13:14:08 -0500 Received: from fmr18.intel.com ([134.134.136.17]:32648 "EHLO orsfmr003.jf.intel.com") by vger.kernel.org with ESMTP id S1750896AbVLBSOD (ORCPT ); Fri, 2 Dec 2005 13:14:03 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id jB2IDwsn020068; Fri, 2 Dec 2005 18:13:58 GMT Received: from vortex.site (vortex.co.intel.com [10.10.212.123]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id jB2IDwg6005405; Fri, 2 Dec 2005 18:13:58 GMT Date: Fri, 2 Dec 2005 10:03:50 -0800 From: Randy Dunlap To: ide Cc: axboe@suse.de, jgarzik@pobox.com Subject: [PATCH 1/6] libata_suspend (Jens) Message-Id: <20051202100350.1878706a.randy_d_dunlap@linux.intel.com> In-Reply-To: <20051202100119.032b242e.randy_d_dunlap@linux.intel.com> References: <20051202100119.032b242e.randy_d_dunlap@linux.intel.com> X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.3; x86_64-unknown-linux-gnu) X-Face: "}I"O`t9.W]b]8SycP0Jap#)%JR,H)Eg(FP)?S1qh0ZJRu|mz*%SKpL7rcKI3(OwmK2@uo\b2 GB:7w&?a,*<8v[ldN`5)MXFcm'cjwRs5)ui)j Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 281 From: Jens Axboe SATA suspend/resume patch. --- drivers/scsi/ata_piix.c | 4 + drivers/scsi/libata-core.c | 122 +++++++++++++++++++++++++++++++++++++++++++++ drivers/scsi/libata-scsi.c | 16 +++++ drivers/scsi/scsi_sysfs.c | 35 ++++++++++++ include/linux/ata.h | 2 include/linux/libata.h | 7 ++ include/scsi/scsi_host.h | 6 ++ 7 files changed, 190 insertions(+), 2 deletions(-) --- linux-2615-rc4.orig/drivers/scsi/ata_piix.c +++ linux-2615-rc4/drivers/scsi/ata_piix.c @@ -125,6 +125,8 @@ static struct pci_driver piix_pci_driver .id_table = piix_pci_tbl, .probe = piix_init_one, .remove = ata_pci_remove_one, + .suspend = ata_pci_device_suspend, + .resume = ata_pci_device_resume, }; static struct scsi_host_template piix_sht = { @@ -145,6 +147,8 @@ static struct scsi_host_template piix_sh .slave_configure = ata_scsi_slave_config, .bios_param = ata_std_bios_param, .ordered_flush = 1, + .suspend = ata_scsi_device_suspend, + .resume = ata_scsi_device_resume, }; static const struct ata_port_operations piix_pata_ops = { --- linux-2615-rc4.orig/drivers/scsi/libata-core.c +++ linux-2615-rc4/drivers/scsi/libata-core.c @@ -4099,6 +4099,104 @@ err_out: } +/* + * Execute a 'simple' command, that only consists of the opcode 'cmd' itself, + * without filling any other registers + */ +static int ata_do_simple_cmd(struct ata_port *ap, struct ata_device *dev, + u8 cmd) +{ + DECLARE_COMPLETION(wait); + struct ata_queued_cmd *qc; + unsigned long flags; + int rc; + + while ((qc = ata_qc_new_init(ap, dev)) == NULL) + msleep(10); + + qc->tf.command = cmd; + qc->tf.flags |= ATA_TFLAG_DEVICE; + qc->tf.protocol = ATA_PROT_NODATA; + + qc->waiting = &wait; + qc->complete_fn = ata_qc_complete_noop; + + spin_lock_irqsave(&ap->host_set->lock, flags); + rc = ata_qc_issue(qc); + spin_unlock_irqrestore(&ap->host_set->lock, flags); + + if (!rc) + wait_for_completion(&wait); + + return rc; +} + +static int ata_flush_cache(struct ata_port *ap, struct ata_device *dev) +{ + u8 cmd; + + if (!ata_try_flush_cache(dev)) + return 0; + + if (ata_id_has_flush_ext(dev->id)) + cmd = ATA_CMD_FLUSH_EXT; + else + cmd = ATA_CMD_FLUSH; + + return ata_do_simple_cmd(ap, dev, cmd); +} + +static int ata_standby_drive(struct ata_port *ap, struct ata_device *dev) +{ + return ata_do_simple_cmd(ap, dev, ATA_CMD_STANDBYNOW1); +} + +static int ata_start_drive(struct ata_port *ap, struct ata_device *dev) +{ + return ata_do_simple_cmd(ap, dev, ATA_CMD_IDLEIMMEDIATE); +} + +/** + * ata_device_resume - wakeup a previously suspended devices + * + * Kick the drive back into action, by sending it an idle immediate + * command and making sure its transfer mode matches between drive + * and host. + * + */ +int ata_device_resume(struct ata_port *ap, struct ata_device *dev) +{ + if (ap->flags & ATA_FLAG_SUSPENDED) { + ap->flags &= ~ATA_FLAG_SUSPENDED; + ata_set_mode(ap); + } + if (!ata_dev_present(dev)) + return 0; + if (dev->class == ATA_DEV_ATA) + ata_start_drive(ap, dev); + + return 0; +} + +/** + * ata_device_suspend - prepare a device for suspend + * + * Flush the cache on the drive, if appropriate, then issue a + * standbynow command. + * + */ +int ata_device_suspend(struct ata_port *ap, struct ata_device *dev) +{ + if (!ata_dev_present(dev)) + return 0; + if (dev->class == ATA_DEV_ATA) + ata_flush_cache(ap, dev); + + ata_standby_drive(ap, dev); + ap->flags |= ATA_FLAG_SUSPENDED; + return 0; +} + /** * ata_port_start - Set port up for dma. * @ap: Port to initialize @@ -4860,6 +4958,23 @@ int pci_test_config_bits(struct pci_dev return (tmp == bits->val) ? 1 : 0; } + +int ata_pci_device_suspend(struct pci_dev *pdev, pm_message_t state) +{ + pci_save_state(pdev); + pci_disable_device(pdev); + pci_set_power_state(pdev, PCI_D3hot); + return 0; +} + +int ata_pci_device_resume(struct pci_dev *pdev) +{ + pci_set_power_state(pdev, PCI_D0); + pci_restore_state(pdev); + pci_enable_device(pdev); + pci_set_master(pdev); + return 0; +} #endif /* CONFIG_PCI */ @@ -4963,4 +5078,11 @@ EXPORT_SYMBOL_GPL(ata_pci_host_stop); EXPORT_SYMBOL_GPL(ata_pci_init_native_mode); EXPORT_SYMBOL_GPL(ata_pci_init_one); EXPORT_SYMBOL_GPL(ata_pci_remove_one); +EXPORT_SYMBOL_GPL(ata_pci_device_suspend); +EXPORT_SYMBOL_GPL(ata_pci_device_resume); #endif /* CONFIG_PCI */ + +EXPORT_SYMBOL_GPL(ata_device_suspend); +EXPORT_SYMBOL_GPL(ata_device_resume); +EXPORT_SYMBOL_GPL(ata_scsi_device_suspend); +EXPORT_SYMBOL_GPL(ata_scsi_device_resume); --- linux-2615-rc4.orig/drivers/scsi/libata-scsi.c +++ linux-2615-rc4/drivers/scsi/libata-scsi.c @@ -396,6 +396,22 @@ void ata_dump_status(unsigned id, struct } } +int ata_scsi_device_resume(struct scsi_device *sdev) +{ + struct ata_port *ap = (struct ata_port *) &sdev->host->hostdata[0]; + struct ata_device *dev = &ap->device[sdev->id]; + + return ata_device_resume(ap, dev); +} + +int ata_scsi_device_suspend(struct scsi_device *sdev) +{ + struct ata_port *ap = (struct ata_port *) &sdev->host->hostdata[0]; + struct ata_device *dev = &ap->device[sdev->id]; + + return ata_device_suspend(ap, dev); +} + /** * ata_to_sense_error - convert ATA error to SCSI error * @id: ATA device number --- linux-2615-rc4.orig/drivers/scsi/scsi_sysfs.c +++ linux-2615-rc4/drivers/scsi/scsi_sysfs.c @@ -263,9 +263,40 @@ static int scsi_bus_match(struct device return (sdp->inq_periph_qual == SCSI_INQ_PQ_CON)? 1: 0; } +static int scsi_bus_suspend(struct device * dev, pm_message_t state) +{ + struct scsi_device *sdev = to_scsi_device(dev); + struct scsi_host_template *sht = sdev->host->hostt; + int err; + + err = scsi_device_quiesce(sdev); + if (err) + return err; + + if (sht->suspend) + err = sht->suspend(sdev); + + return err; +} + +static int scsi_bus_resume(struct device * dev) +{ + struct scsi_device *sdev = to_scsi_device(dev); + struct scsi_host_template *sht = sdev->host->hostt; + int err = 0; + + if (sht->resume) + err = sht->resume(sdev); + + scsi_device_resume(sdev); + return err; +} + struct bus_type scsi_bus_type = { - .name = "scsi", - .match = scsi_bus_match, + .name = "scsi", + .match = scsi_bus_match, + .suspend = scsi_bus_suspend, + .resume = scsi_bus_resume, }; int scsi_sysfs_register(void) --- linux-2615-rc4.orig/include/linux/ata.h +++ linux-2615-rc4/include/linux/ata.h @@ -141,6 +141,8 @@ enum { ATA_CMD_PACKET = 0xA0, ATA_CMD_VERIFY = 0x40, ATA_CMD_VERIFY_EXT = 0x42, + ATA_CMD_STANDBYNOW1 = 0xE0, + ATA_CMD_IDLEIMMEDIATE = 0xE1, ATA_CMD_INIT_DEV_PARAMS = 0x91, /* SETFEATURES stuff */ --- linux-2615-rc4.orig/include/linux/libata.h +++ linux-2615-rc4/include/linux/libata.h @@ -122,6 +122,7 @@ enum { ATA_FLAG_NOINTR = (1 << 9), /* FIXME: Remove this once * proper HSM is in place. */ ATA_FLAG_DEBUGMSG = (1 << 10), + ATA_FLAG_SUSPENDED = (1 << 11), /* port is suspended */ ATA_QCFLAG_ACTIVE = (1 << 1), /* cmd not yet ack'd to scsi lyer */ ATA_QCFLAG_SG = (1 << 3), /* have s/g table? */ @@ -435,6 +436,8 @@ extern void ata_std_ports(struct ata_iop extern int ata_pci_init_one (struct pci_dev *pdev, struct ata_port_info **port_info, unsigned int n_ports); extern void ata_pci_remove_one (struct pci_dev *pdev); +extern int ata_pci_device_suspend(struct pci_dev *pdev, pm_message_t state); +extern int ata_pci_device_resume(struct pci_dev *pdev); #endif /* CONFIG_PCI */ extern int ata_device_add(const struct ata_probe_ent *ent); extern void ata_host_set_remove(struct ata_host_set *host_set); @@ -444,6 +447,10 @@ extern int ata_scsi_queuecmd(struct scsi extern int ata_scsi_error(struct Scsi_Host *host); extern int ata_scsi_release(struct Scsi_Host *host); extern unsigned int ata_host_intr(struct ata_port *ap, struct ata_queued_cmd *qc); +extern int ata_scsi_device_resume(struct scsi_device *); +extern int ata_scsi_device_suspend(struct scsi_device *); +extern int ata_device_resume(struct ata_port *, struct ata_device *); +extern int ata_device_suspend(struct ata_port *, struct ata_device *); extern int ata_ratelimit(void); /* --- linux-2615-rc4.orig/include/scsi/scsi_host.h +++ linux-2615-rc4/include/scsi/scsi_host.h @@ -296,6 +296,12 @@ struct scsi_host_template { int (*proc_info)(struct Scsi_Host *, char *, char **, off_t, int, int); /* + * suspend support + */ + int (*suspend)(struct scsi_device *); + int (*resume)(struct scsi_device *); + + /* * Name of proc directory */ char *proc_name; --- - 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 From randy_d_dunlap@linux.intel.com Fri Dec 2 10:04:52 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 10:14:12 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750899AbVLBSOL (ORCPT ); Fri, 2 Dec 2005 13:14:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750905AbVLBSOL (ORCPT ); Fri, 2 Dec 2005 13:14:11 -0500 Received: from fmr17.intel.com ([134.134.136.16]:45457 "EHLO orsfmr002.jf.intel.com") by vger.kernel.org with ESMTP id S1750899AbVLBSOG (ORCPT ); Fri, 2 Dec 2005 13:14:06 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id jB2IDwpQ020153; Fri, 2 Dec 2005 18:13:58 GMT Received: from vortex.site (vortex.co.intel.com [10.10.212.123]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id jB2IDwg6005412; Fri, 2 Dec 2005 18:13:58 GMT Date: Fri, 2 Dec 2005 10:04:52 -0800 From: Randy Dunlap To: ide Cc: axboe@suse.de, jgarzik@pobox.com Subject: [PATCH 2/6] SATA ACPI: make/config changes Message-Id: <20051202100452.1e740baf.randy_d_dunlap@linux.intel.com> In-Reply-To: <20051202100119.032b242e.randy_d_dunlap@linux.intel.com> References: <20051202100119.032b242e.randy_d_dunlap@linux.intel.com> X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.3; x86_64-unknown-linux-gnu) X-Face: "}I"O`t9.W]b]8SycP0Jap#)%JR,H)Eg(FP)?S1qh0ZJRu|mz*%SKpL7rcKI3(OwmK2@uo\b2 GB:7w&?a,*<8v[ldN`5)MXFcm'cjwRs5)ui)j Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 283 From: Randy Dunlap Add ata_acpi in Makefile and Kconfig. Signed-off-by: Randy Dunlap --- drivers/scsi/Kconfig | 5 +++++ drivers/scsi/Makefile | 1 + 2 files changed, 6 insertions(+) --- linux-2615-rc4.orig/drivers/scsi/Makefile +++ linux-2615-rc4/drivers/scsi/Makefile @@ -138,6 +138,7 @@ obj-$(CONFIG_SCSI_SATA_NV) += libata.o s obj-$(CONFIG_SCSI_SATA_ULI) += libata.o sata_uli.o obj-$(CONFIG_SCSI_SATA_MV) += libata.o sata_mv.o obj-$(CONFIG_SCSI_PDC_ADMA) += libata.o pdc_adma.o +obj-$(CONFIG_SCSI_SATA_ACPI) += libata.o ata_acpi.o obj-$(CONFIG_ARM) += arm/ --- linux-2615-rc4.orig/drivers/scsi/Kconfig +++ linux-2615-rc4/drivers/scsi/Kconfig @@ -598,6 +598,11 @@ config SCSI_SATA_INTEL_COMBINED depends on IDE=y && !BLK_DEV_IDE_SATA && (SCSI_SATA_AHCI || SCSI_ATA_PIIX) default y +config SCSI_SATA_ACPI + bool + depends on SCSI_SATA && ACPI + default y + config SCSI_BUSLOGIC tristate "BusLogic SCSI support" depends on (PCI || ISA || MCA) && SCSI && ISA_DMA_API --- - 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 From randy_d_dunlap@linux.intel.com Fri Dec 2 10:05:41 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 10:14:07 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750897AbVLBSOG (ORCPT ); Fri, 2 Dec 2005 13:14:06 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750882AbVLBSOF (ORCPT ); Fri, 2 Dec 2005 13:14:05 -0500 Received: from fmr20.intel.com ([134.134.136.19]:51857 "EHLO orsfmr005.jf.intel.com") by vger.kernel.org with ESMTP id S1750897AbVLBSOD (ORCPT ); Fri, 2 Dec 2005 13:14:03 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id jB2IDw1i019988; Fri, 2 Dec 2005 18:13:58 GMT Received: from vortex.site (vortex.co.intel.com [10.10.212.123]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id jB2IDwg6005422; Fri, 2 Dec 2005 18:13:58 GMT Date: Fri, 2 Dec 2005 10:05:41 -0800 From: Randy Dunlap To: ide Cc: axboe@suse.de, jgarzik@pobox.com Subject: [PATCH 3/6] SATA ACPI: libata.h changes Message-Id: <20051202100541.1dfb3db4.randy_d_dunlap@linux.intel.com> In-Reply-To: <20051202100119.032b242e.randy_d_dunlap@linux.intel.com> References: <20051202100119.032b242e.randy_d_dunlap@linux.intel.com> X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.3; x86_64-unknown-linux-gnu) X-Face: "}I"O`t9.W]b]8SycP0Jap#)%JR,H)Eg(FP)?S1qh0ZJRu|mz*%SKpL7rcKI3(OwmK2@uo\b2 GB:7w&?a,*<8v[ldN`5)MXFcm'cjwRs5)ui)j Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 279 From: Randy Dunlap Add ACPI data pointer/length holders. Signed-off-by: Randy Dunlap --- include/linux/libata.h | 6 ++++++ 1 files changed, 6 insertions(+) --- linux-2615-rc4.orig/include/linux/libata.h +++ linux-2615-rc4/include/linux/libata.h @@ -33,6 +33,7 @@ #include #include #include +#include /* * compile-time options @@ -311,6 +312,11 @@ struct ata_device { u16 cylinders; /* Number of cylinders */ u16 heads; /* Number of heads */ u16 sectors; /* Number of sectors per track */ + + /* ACPI objects info */ + acpi_handle obj_handle; + acpi_size gtf_length; + u8 *gtf_address; }; struct ata_port { --- - 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 From randy_d_dunlap@linux.intel.com Fri Dec 2 10:07:02 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 10:14:06 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750891AbVLBSOE (ORCPT ); Fri, 2 Dec 2005 13:14:04 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750886AbVLBSOE (ORCPT ); Fri, 2 Dec 2005 13:14:04 -0500 Received: from fmr18.intel.com ([134.134.136.17]:31112 "EHLO orsfmr003.jf.intel.com") by vger.kernel.org with ESMTP id S1750891AbVLBSOC (ORCPT ); Fri, 2 Dec 2005 13:14:02 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id jB2IDwsn020074; Fri, 2 Dec 2005 18:13:59 GMT Received: from vortex.site (vortex.co.intel.com [10.10.212.123]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id jB2IDwg6005426; Fri, 2 Dec 2005 18:13:58 GMT Date: Fri, 2 Dec 2005 10:07:02 -0800 From: Randy Dunlap To: ide Cc: axboe@suse.de, jgarzik@pobox.com Subject: [PATCH 4/6] SATA ACPI: call new ACPI functions Message-Id: <20051202100702.5bd1e7d8.randy_d_dunlap@linux.intel.com> In-Reply-To: <20051202100119.032b242e.randy_d_dunlap@linux.intel.com> References: <20051202100119.032b242e.randy_d_dunlap@linux.intel.com> X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.3; x86_64-unknown-linux-gnu) X-Face: "}I"O`t9.W]b]8SycP0Jap#)%JR,H)Eg(FP)?S1qh0ZJRu|mz*%SKpL7rcKI3(OwmK2@uo\b2 GB:7w&?a,*<8v[ldN`5)MXFcm'cjwRs5)ui)j Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 278 From: Randy Dunlap Add calls to ACPI methods for SATA drives. Signed-off-by: Randy Dunlap --- drivers/scsi/libata-core.c | 4 ++++ drivers/scsi/libata.h | 7 +++++++ 2 files changed, 11 insertions(+) --- linux-2615-rc4.orig/drivers/scsi/libata-core.c +++ linux-2615-rc4/drivers/scsi/libata-core.c @@ -1345,6 +1345,8 @@ void ata_dev_config(struct ata_port *ap, if (ap->ops->dev_config) ap->ops->dev_config(ap, &ap->device[i]); + + do_drive_SDD(ap, i); } /** @@ -1784,6 +1786,8 @@ static void ata_set_mode(struct ata_port if (ap->flags & ATA_FLAG_PORT_DISABLED) return; + do_drive_update_taskfiles(ap); + if (ap->ops->post_set_mode) ap->ops->post_set_mode(ap); --- linux-2615-rc4.orig/drivers/scsi/libata.h +++ linux-2615-rc4/drivers/scsi/libata.h @@ -53,6 +53,13 @@ extern int ata_task_ioctl(struct scsi_de extern int ata_cmd_ioctl(struct scsi_device *scsidev, void __user *arg); +/* ata_acpi.c */ +extern int do_drive_SDD(struct ata_port *ap, unsigned int ix); +extern int do_drive_get_GTF(struct ata_port *ap, struct ata_device *atadev); +extern int do_drive_set_taskfiles(struct ata_port *ap, struct ata_device *atadev); +extern int do_drive_update_taskfiles(struct ata_port *ap); + + /* libata-scsi.c */ extern void ata_scsi_scan_host(struct ata_port *ap); extern int ata_scsi_error(struct Scsi_Host *host); --- - 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 From randy_d_dunlap@linux.intel.com Fri Dec 2 10:07:54 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 10:14:05 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750902AbVLBSOE (ORCPT ); Fri, 2 Dec 2005 13:14:04 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750898AbVLBSOD (ORCPT ); Fri, 2 Dec 2005 13:14:03 -0500 Received: from fmr19.intel.com ([134.134.136.18]:63651 "EHLO orsfmr004.jf.intel.com") by vger.kernel.org with ESMTP id S1750886AbVLBSOC (ORCPT ); Fri, 2 Dec 2005 13:14:02 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id jB2IDxjo029735; Fri, 2 Dec 2005 18:13:59 GMT Received: from vortex.site (vortex.co.intel.com [10.10.212.123]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id jB2IDwg6005431; Fri, 2 Dec 2005 18:13:58 GMT Date: Fri, 2 Dec 2005 10:07:54 -0800 From: Randy Dunlap To: ide Cc: axboe@suse.de, jgarzik@pobox.com Subject: [PATCH 5/6] SATA ACPI: kernel-doc Message-Id: <20051202100754.6194bfb2.randy_d_dunlap@linux.intel.com> In-Reply-To: <20051202100119.032b242e.randy_d_dunlap@linux.intel.com> References: <20051202100119.032b242e.randy_d_dunlap@linux.intel.com> X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.3; x86_64-unknown-linux-gnu) X-Face: "}I"O`t9.W]b]8SycP0Jap#)%JR,H)Eg(FP)?S1qh0ZJRu|mz*%SKpL7rcKI3(OwmK2@uo\b2 GB:7w&?a,*<8v[ldN`5)MXFcm'cjwRs5)ui)j Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 277 From: Randy Dunlap Add ata_acpi.c to libata kernel-doc template file. Signed-off-by: Randy Dunlap --- Documentation/DocBook/libata.tmpl | 6 ++++++ 1 files changed, 6 insertions(+) --- linux-2615-rc4.orig/Documentation/DocBook/libata.tmpl +++ linux-2615-rc4/Documentation/DocBook/libata.tmpl @@ -787,6 +787,12 @@ and other resources, etc. !Idrivers/scsi/libata-scsi.c + + libata ACPI interfaces/methods +!Edrivers/scsi/ata_acpi.c +!Idrivers/scsi/ata_acpi.c + + ATA errors & exceptions --- - 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 From randy_d_dunlap@linux.intel.com Fri Dec 2 10:08:50 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 10:14:09 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750895AbVLBSOH (ORCPT ); Fri, 2 Dec 2005 13:14:07 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750904AbVLBSOH (ORCPT ); Fri, 2 Dec 2005 13:14:07 -0500 Received: from fmr17.intel.com ([134.134.136.16]:41105 "EHLO orsfmr002.jf.intel.com") by vger.kernel.org with ESMTP id S1750895AbVLBSOD (ORCPT ); Fri, 2 Dec 2005 13:14:03 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id jB2IDxpQ020169; Fri, 2 Dec 2005 18:13:59 GMT Received: from vortex.site (vortex.co.intel.com [10.10.212.123]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id jB2IDxg6005445; Fri, 2 Dec 2005 18:13:59 GMT Date: Fri, 2 Dec 2005 10:08:50 -0800 From: Randy Dunlap To: ide Cc: axboe@suse.de, jgarzik@pobox.com Subject: [PATCH 6/6] SATA ACPI: ata_acpi functions Message-Id: <20051202100850.11b831ea.randy_d_dunlap@linux.intel.com> In-Reply-To: <20051202100119.032b242e.randy_d_dunlap@linux.intel.com> References: <20051202100119.032b242e.randy_d_dunlap@linux.intel.com> X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.3; x86_64-unknown-linux-gnu) X-Face: "}I"O`t9.W]b]8SycP0Jap#)%JR,H)Eg(FP)?S1qh0ZJRu|mz*%SKpL7rcKI3(OwmK2@uo\b2 GB:7w&?a,*<8v[ldN`5)MXFcm'cjwRs5)ui)j Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 280 From: Randy Dunlap Add support for ACPI methods to SATA suspend/resume. Signed-off-by: Randy Dunlap --- drivers/scsi/ata_acpi.c | 488 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 488 insertions(+) --- /dev/null +++ linux-2615-rc4/drivers/scsi/ata_acpi.c @@ -0,0 +1,488 @@ +/* + * ata-acpi.c + * Provides ACPI support for PATA/SATA. + * + * Copyright (C) 2005 Intel Corp. + * Copyright (C) 2005 Randy Dunlap + */ + +#include +#include +#include +#include +#include +#include "scsi.h" +#include +#include +#include "libata.h" + +#include +#include +#include +#include +#include +#include +#include + +#define SATA_ROOT_PORT(x) (((x) >> 16) & 0xffff) +#define SATA_PORT_NUMBER(x) ((x) & 0xffff) /* or NO_PORT_MULT */ +#define NO_PORT_MULT 0xffff +#define SATA_ADR_RSVD 0xffffffff + +#define REGS_PER_GTF 7 +struct taskfile_array { + u8 tfa[REGS_PER_GTF]; /* regs. 0x1f1 - 0x1f7 */ +}; + +#define DEBUGGING 1 +/* note: adds function name and KERN_DEBUG */ +#ifdef DEBUGGING +#define DEBPRINT(fmt, args...) \ + printk(KERN_DEBUG "%s: " fmt, __FUNCTION__, ## args) +#else +#define DEBPRINT(fmt, args...) do {} while (0) +#endif /* DEBUGGING */ + +static u8 *acpi_path_name(acpi_handle handle) +{ + acpi_status status; + static u8 path_name[ACPI_PATHNAME_MAX]; + struct acpi_buffer ret_buf = { ACPI_PATHNAME_MAX, path_name }; + + memset(path_name, 0, sizeof (path_name)); + status = acpi_get_name(handle, ACPI_FULL_PATHNAME, &ret_buf); + + if (ACPI_FAILURE(status)) + return NULL; + + return path_name; +} + +/** + * pci_acpi_get_dev_handle - finds acpi_handle and pci device.function + * @dev: device to locate + * @handle: returned acpi_handle for @dev + * @pcidevfn: return PCI device.func for @dev + * + * Returns 0 on success, <0 on error. + */ +static int pci_acpi_get_dev_handle(struct device *dev, acpi_handle *handle, + acpi_integer *pcidevfn) +{ + struct pci_dev *pci_dev; + acpi_integer addr; + + pci_dev = to_pci_dev(dev); + /* Please refer to the ACPI spec for the syntax of _ADR. */ + addr = (PCI_SLOT(pci_dev->devfn) << 16) | PCI_FUNC(pci_dev->devfn); + *pcidevfn = addr; + *handle = acpi_get_child(DEVICE_ACPI_HANDLE(dev->parent), addr); + DEBPRINT("pcidevfn: 0x%llx\n", + (unsigned long long)*pcidevfn); + if (!*handle) + return -ENODEV; + return 0; +} + +struct walk_info { /* can be trimmed some */ + struct device *dev; + struct acpi_device *adev; + acpi_handle handle; + acpi_integer pcidevfn; + unsigned int drivenum; + acpi_handle obj_handle; + struct ata_port *ataport; + struct ata_device *atadev; + u32 sata_adr; + int status; + char basepath[ACPI_PATHNAME_MAX]; + int basepath_len; +}; + +static acpi_status get_devices(acpi_handle handle, + u32 level, void *context, void **return_value) +{ + acpi_status status; + struct walk_info *winfo = context; + u8 *path_name = acpi_path_name(handle); + struct acpi_buffer buffer; + struct acpi_device_info *dinfo; + + buffer.length = ACPI_ALLOCATE_LOCAL_BUFFER; + buffer.pointer = NULL; + status = acpi_get_object_info(handle, &buffer); + + if (ACPI_SUCCESS(status)) { + dinfo = buffer.pointer; + + /* find full device path name for pcidevfn */ + if (dinfo && (dinfo->valid & ACPI_VALID_ADR) && + dinfo->address == winfo->pcidevfn) { + DEBPRINT(":%s: matches pcidevfn (0x%llx)\n", + path_name, winfo->pcidevfn); + strlcpy(winfo->basepath, path_name, + sizeof(winfo->basepath)); + winfo->basepath_len = strlen(path_name); + goto out; + } + + /* if basepath is not yet known, ignore this object */ + if (!winfo->basepath_len) + goto out; + + /* if this object is in scope of basepath, maybe use it */ + if (strncmp(path_name, winfo->basepath, + winfo->basepath_len) == 0) { + if (!(dinfo->valid & ACPI_VALID_ADR)) + goto out; + DEBPRINT("GOT ONE: " + "(%s) root_port = 0x%llx, port_num = 0x%llx\n", + path_name, + SATA_ROOT_PORT(dinfo->address), + SATA_PORT_NUMBER(dinfo->address)); + /* heuristics: */ + if (SATA_PORT_NUMBER(dinfo->address) != NO_PORT_MULT) + DEBPRINT("warning: don't know how to handle SATA port multiplier\n"); + if (SATA_ROOT_PORT(dinfo->address) == + winfo->ataport->port_no && + SATA_PORT_NUMBER(dinfo->address) == NO_PORT_MULT) { + DEBPRINT("THIS ^^^^^ is the requested SATA drive (handle = 0x%p)\n", + handle); + winfo->sata_adr = dinfo->address; + winfo->obj_handle = handle; + } + } +out: + ACPI_MEM_FREE(dinfo); + } + + return status; +} + +/* Get the SATA drive _ADR object. */ +static int get_sata_adr(struct device *dev, acpi_handle handle, + acpi_integer pcidevfn, unsigned int drive, + struct ata_port *ap, + struct ata_device *atadev, u32 *dev_adr) +{ + acpi_status status; + struct walk_info *winfo; + int err = -ENOMEM; + + winfo = kzalloc(sizeof(struct walk_info), GFP_KERNEL); + if (!winfo) + goto out; + + winfo->dev = dev; + winfo->atadev = atadev; + winfo->ataport = ap; + if (acpi_bus_get_device(handle, &winfo->adev) < 0) + DEBPRINT("acpi_bus_get_device failed\n"); + winfo->handle = handle; + winfo->pcidevfn = pcidevfn; + winfo->drivenum = drive; + + status = acpi_get_devices(NULL, get_devices, winfo, NULL); + if (ACPI_FAILURE(status)) + err = -ENODEV; + else { + *dev_adr = winfo->sata_adr; + atadev->obj_handle = winfo->obj_handle; + err = 0; + } + kfree(winfo); +out: + return err; +} + +/** + * do_drive_SDD - send Identify data to a drive + * @ap: the ata_port for the drive + * @ix: drive index + * + * Must be after Identify (Packet) Device -- uses its data. + */ +int do_drive_SDD(struct ata_port *ap, unsigned int ix) +{ + acpi_handle handle; + acpi_integer pcidevfn; + int err = -ENODEV; + struct device *dev = ap->host_set->dev; + struct ata_device *atadev = &ap->device[ix]; + u32 dev_adr; + acpi_status status; + struct acpi_object_list input; + union acpi_object in_params[1]; + + printk(KERN_DEBUG + "%s: ap->id: %d, ix = %d, port#: %d, hard_port#: %d\n", + __FUNCTION__, ap->id, ix, ap->port_no, ap->hard_port_no); + + /* Don't continue if not a SATA device. */ + if (!ata_id_is_sata(atadev->id)) + goto out; + + /* Don't continue if device has no _ADR method. + * _SDD is intended for known motherboard devices. */ + err = pci_acpi_get_dev_handle(dev, &handle, &pcidevfn); + if (err < 0) + goto out; + /* Get this drive's _ADR info. */ + dev_adr = SATA_ADR_RSVD; + err = get_sata_adr(dev, handle, pcidevfn, ix, ap, atadev, &dev_adr); + if (err < 0 || dev_adr == SATA_ADR_RSVD || atadev->obj_handle == NULL) + goto out; + + /* Give the drive Identify data to the drive via the _SDD method */ + /* _SDD: set up input parameters */ + input.count = 1; + input.pointer = in_params; + in_params[0].type = ACPI_TYPE_BUFFER; + in_params[0].buffer.length = sizeof(atadev->id); + in_params[0].buffer.pointer = (u8 *)atadev->id; + /* Output buffer: _SDD has no output */ + + /* It's OK for _SDD to be missing too. */ + status = acpi_evaluate_object(atadev->obj_handle, "_SDD", &input, NULL); + err = ACPI_FAILURE(status) ? -EIO : 0; + if (err < 0) { + printk(KERN_DEBUG + "ata%u(%u): %s _SDD error: status = 0x%x\n", + ap->id, ap->device->devno, __FUNCTION__, status); + } +out: + return err; +} +EXPORT_SYMBOL_GPL(do_drive_SDD); + +/** + * do_drive_get_GTF - get the drive bootup default taskfile settings + * @ap: the ata_port for the drive + * @atadev: target ata_device + * + * This applies to both PATA and SATA drives. + * + * The _GTF method has no input parameters. + * It returns a variable number of register set values (registers + * hex 1F1..1F7, taskfiles). + * The is not known in advance, so have ACPI-CA + * allocate the buffer as needed and return it, then free it later. + * + */ +int do_drive_get_GTF(struct ata_port *ap, struct ata_device *atadev) +{ + acpi_status status; + acpi_handle handle; + acpi_integer pcidevfn; + struct acpi_buffer output; + union acpi_object *out_obj; + struct device *dev = ap->host_set->dev; + int err = -ENODEV; + + if (!ata_dev_present(atadev)) /* or port disabled ? */ + goto out; + + /* Don't continue if device has no _ADR method. + * _GTF is intended for known motherboard devices. */ + err = pci_acpi_get_dev_handle(dev, &handle, &pcidevfn); + if (err < 0) + goto out; + + /* Setting up output buffer */ + output.length = ACPI_ALLOCATE_BUFFER; + output.pointer = NULL; /* ACPI-CA sets this; save/free it later */ + + /* _GTF has no input parameters */ + err = -EIO; + status = acpi_evaluate_object(atadev->obj_handle, "_GTF", + NULL, &output); + if (ACPI_FAILURE(status)) { + ACPI_MEM_FREE(output.pointer); + printk(KERN_DEBUG + "%s: Run _GTF error: status = 0x%x\n", + __FUNCTION__, status); + goto out; + } + + if (!output.length || !output.pointer) { + printk(KERN_DEBUG + "%s: Run _GTF: length or ptr is NULL (0x%llx, 0x%p)\n", + __FUNCTION__, + (unsigned long long)output.length, output.pointer); + ACPI_MEM_FREE(output.pointer); + goto out; + } + + out_obj = output.pointer; + if (out_obj->type != ACPI_TYPE_BUFFER) { + ACPI_MEM_FREE(output.pointer); + printk(KERN_DEBUG "%s: Run _GTF: error: " + "expected object type of ACPI_TYPE_BUFFER, got 0x%x\n", + __FUNCTION__, out_obj->type); + err = -ENOENT; + goto out; + } + + atadev->gtf_length = out_obj->buffer.length; + atadev->gtf_address = out_obj->buffer.pointer; + err = 0; +out: + return err; +} +EXPORT_SYMBOL_GPL(do_drive_get_GTF); + +/** + * taskfile_load_raw - send taskfile registers to host controller + * @ap: Port to which output is sent + * @gtf: raw ATA taskfile register set (0x1f1 - 0x1f7) + * + * Outputs ATA taskfile to standard ATA host controller using MMIO + * or PIO as indicated by the ATA_FLAG_MMIO flag. + * Writes the control, feature, nsect, lbal, lbam, and lbah registers. + * Optionally (ATA_TFLAG_LBA48) writes hob_feature, hob_nsect, + * hob_lbal, hob_lbam, and hob_lbah. + * + * This function waits for idle (!BUSY and !DRQ) after writing + * registers. If the control register has a new value, this + * function also waits for idle after writing control and before + * writing the remaining registers. + * + * LOCKING: TBD: + * Inherited from caller. + */ +static void taskfile_load_raw(struct ata_port *ap, + struct ata_device *atadev, + const struct taskfile_array *gtf) +{ + DEBPRINT("(0x1f1-1f7): hex: %02x %02x %02x %02x %02x %02x %02x\n", + gtf->tfa[0], gtf->tfa[1], gtf->tfa[2], + gtf->tfa[3], gtf->tfa[4], gtf->tfa[5], gtf->tfa[6]); + + if (ap->ops->tf_load && ap->ops->exec_command) { + struct ata_taskfile atf; + + /* convert gtf to atf */ + ata_tf_init(ap, &atf, 0); + atf.flags = ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE; /* TBD */ + atf.protocol = ATA_PROT_NODATA; /* or ATA_PROT_ATAPI_NODATA */ + atf.feature = gtf->tfa[0]; /* 0x1f1 */ + atf.nsect = gtf->tfa[1]; /* 0x1f2 */ + atf.lbal = gtf->tfa[2]; /* 0x1f3 */ + atf.lbam = gtf->tfa[3]; /* 0x1f4 */ + atf.lbah = gtf->tfa[4]; /* 0x1f5 */ + atf.device = gtf->tfa[5]; /* 0x1f6 */ + atf.command = gtf->tfa[6]; /* 0x1f7 */ + + DEBPRINT("call tf_load:\n"); + ap->ops->tf_load(ap, &atf); + DEBPRINT("call exec_command:\n"); + ap->ops->exec_command(ap, &atf); + DEBPRINT("tf_load & exec_command done.\n"); + } else if (ap->ops->qc_issue && ap->ops->qc_prep) { + int ret; + struct ata_queued_cmd *qc; + unsigned long flags; + DECLARE_COMPLETION(wait); + + qc = ata_qc_new_init(ap, atadev); + if (!qc) { + printk(KERN_DEBUG "%s: ata_qc_new_init ret. NULL\n", + __FUNCTION__); + return; + } + + /* convert gtf to qc.tf */ + qc->tf.flags = ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE; /* TBD */ + qc->tf.protocol = ATA_PROT_NODATA; /* or ATA_PROT_ATAPI_NODATA */ + qc->tf.feature = gtf->tfa[0]; /* 0x1f1 */ + qc->tf.nsect = gtf->tfa[1]; /* 0x1f2 */ + qc->tf.lbal = gtf->tfa[2]; /* 0x1f3 */ + qc->tf.lbam = gtf->tfa[3]; /* 0x1f4 */ + qc->tf.lbah = gtf->tfa[4]; /* 0x1f5 */ + qc->tf.device = gtf->tfa[5]; /* 0x1f6 */ + qc->tf.command = gtf->tfa[6]; /* 0x1f7 */ + + qc->waiting = &wait; + qc->complete_fn = ata_qc_complete_noop; + + // TBD: fix locking and return value/wait_for_completion here: + DEBPRINT("call ata_qc_issue:\n"); + spin_lock_irqsave(&ap->host_set->lock, flags); + ret = ata_qc_issue(qc); + spin_unlock_irqrestore(&ap->host_set->lock, flags); + DEBPRINT("ata_qc_issue done: ret = 0x%x\n", ret); + + if (!ret) + wait_for_completion(&wait); + } else + printk(KERN_WARNING "%s: SATA driver is missing tf_load/exec_command or qc_issue function entry points\n", + __FUNCTION__); +} + +/** + * do_drive_set_taskfiles - write the drive taskfile settings from _GTF + * @ap: the ata_port for the drive + * @atadev: target ata_device + * + * This applies to both PATA and SATA drives. + * + * Write {atadev->gtf_address, length atadev->gtf_length} in groups of + * REGS_PER_GTF bytes. + * + */ +int do_drive_set_taskfiles(struct ata_port *ap, struct ata_device *atadev) +{ + int err = -ENODEV; + int gtf_count = + atadev->gtf_length / REGS_PER_GTF; + int ix; + struct taskfile_array *gtf; + + if (!ata_dev_present(atadev)) /* or port disabled ? */ + goto out; + if (!gtf_count) /* shouldn't be here */ + goto out; + + DEBPRINT("total GTF bytes = %lld (0x%llx), gtf_count = %d\n", + (unsigned long long)atadev->gtf_length, + (unsigned long long)atadev->gtf_length, gtf_count); + if (atadev->gtf_length % REGS_PER_GTF) { + printk(KERN_ERR "%s: unexpected GTF length (%zd)\n", + __FUNCTION__, atadev->gtf_length); + goto out; + } + + for (ix = 0; ix < gtf_count; ix++) { + gtf = (struct taskfile_array *) + (atadev->gtf_address + ix * REGS_PER_GTF); + + /* send all TaskFile registers (0x1f1-0x1f7) *in*that*order* */ + taskfile_load_raw(ap, atadev, gtf); + } + + err = 0; +out: + return err; +} +EXPORT_SYMBOL_GPL(do_drive_set_taskfiles); + +/** + * do_drive_update_taskfiles - get then write drive taskfile settings + * @ap: the ata_port for the drive + * + * This applies to both PATA and SATA drives. + */ +int do_drive_update_taskfiles(struct ata_port *ap) +{ + int ix; + int ret; + + for (ix = 0; ix < ATA_MAX_DEVICES; ix++) { + ret = do_drive_get_GTF(ap, &ap->device[ix]); + if (ret >= 0) + ret = do_drive_set_taskfiles(ap, &ap->device[ix]); + } + + return ret; +} +EXPORT_SYMBOL_GPL(do_drive_update_taskfiles); --- - 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 From giulioo@gmail.com Fri Dec 2 10:09:23 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 10:12:11 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750781AbVLBSMG (ORCPT ); Fri, 2 Dec 2005 13:12:06 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750850AbVLBSMG (ORCPT ); Fri, 2 Dec 2005 13:12:06 -0500 Received: from wnx-5a.seeweb.it ([212.25.170.113]:24452 "EHLO wnx-5a.seeweb.it") by vger.kernel.org with ESMTP id S1750781AbVLBSMF (ORCPT ); Fri, 2 Dec 2005 13:12:05 -0500 Received: from i3.golden.dom (xs-213-255-43-90.to1.albacom.net [213.255.43.90] (may be forged)) (authenticated bits=0) by wnx-5a.seeweb.it (8.12.3/8.12.3/Debian-7.1) with ESMTP id jB2IBvDr024049 for ; Fri, 2 Dec 2005 19:11:58 +0100 Received: from pc93 (pc93 [192.168.1.193]) by i3.golden.dom (Postfix) with SMTP id B6A74F817 for ; Fri, 2 Dec 2005 19:09:23 +0100 (CET) From: Giulio Orsero To: linux-ide@vger.kernel.org Subject: writing to ide dvd-ram: terrible slow-downs Date: Fri, 02 Dec 2005 19:09:23 +0100 Reply-To: giulioo@pobox.com X-Mailer: Forte Agent 3.2/32.799 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20051202180923.B6A74F817@i3.golden.dom> Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 274 1st system: kernel 2.4.32 2 SATA HDs on intel sata using ata_piix (bios is enhanced mode) 1 IDE DVD-RAM/-RW/+RW (LG 4163B) on hda. DVD-RAM media When writing to the DVD-RAM (I have ext2 fs on it), accessed via ide-scsi, there are terrible slow-downs on the 2 sata disks like writing to and ide device would affect the 2 sata channels, is this normal behavior? =========== 2ns system: kernel 2.6.15- 1 HD on hda 1 IDE DVD-RAM (LG 4163B) on hdc. When writing to the DVD-RAM (I have ext2 fs on it) accessed via ide-cd, there are terrible slow-downs on the ide disk like writing to an ide device on 2nd ide channel would affect the 1st ide channel (different ide cable) is this normal behavior? In bot cases I write to the dvd-ram this way: mount -t ext2 /dev/scd0 /mnt/dvd (kernel 24) or mount -t ext2 /dev/hdc /mnt/dvd (kernel 26) and then cp data /mnt/dvd/ I remember having similar problems when using cdrecord to write cd-rw in the past which I could solve using the cdrecord "-immed" flag. Before flogging the list with long dmesg I wanted to be certain this is not the way it's supposed to work. Suggestions? Thanks - 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 From randy_d_dunlap@linux.intel.com Fri Dec 2 10:15:04 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 10:14:11 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750886AbVLBSOK (ORCPT ); Fri, 2 Dec 2005 13:14:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750896AbVLBSOJ (ORCPT ); Fri, 2 Dec 2005 13:14:09 -0500 Received: from fmr18.intel.com ([134.134.136.17]:35464 "EHLO orsfmr003.jf.intel.com") by vger.kernel.org with ESMTP id S1750894AbVLBSOF (ORCPT ); Fri, 2 Dec 2005 13:14:05 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id jB2IDxsn020107; Fri, 2 Dec 2005 18:13:59 GMT Received: from vortex.site (vortex.co.intel.com [10.10.212.123]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id jB2IDxg6005457; Fri, 2 Dec 2005 18:13:59 GMT Date: Fri, 2 Dec 2005 10:15:04 -0800 From: Randy Dunlap To: ide Cc: axboe@suse.de, jgarzik@pobox.com Subject: Re: [PATCH 0/6] SATA use ACPI methods for PM Message-Id: <20051202101504.27d0dfc0.randy_d_dunlap@linux.intel.com> In-Reply-To: <20051202100119.032b242e.randy_d_dunlap@linux.intel.com> References: <20051202100119.032b242e.randy_d_dunlap@linux.intel.com> X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.3; x86_64-unknown-linux-gnu) X-Face: "}I"O`t9.W]b]8SycP0Jap#)%JR,H)Eg(FP)?S1qh0ZJRu|mz*%SKpL7rcKI3(OwmK2@uo\b2 GB:7w&?a,*<8v[ldN`5)MXFcm'cjwRs5)ui)j Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: O X-Status: X-Keywords: X-UID: 282 more comments: Yes, the patch still contains some debugging code. If you try it out and have problems, please give me as much of the debug output as possible. It is likely that I will also want to see your ACPI tables. To dump those, use 'acpidump' from the latest pmtools release at: http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ The patch series is available at: http://www.xenotime.net/linux/SATA/2.6.15-rc/ --- ~Randy - 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 From randy_d_dunlap@linux.intel.com Fri Dec 2 10:16:37 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 10:13:47 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750850AbVLBSNp (ORCPT ); Fri, 2 Dec 2005 13:13:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750883AbVLBSNp (ORCPT ); Fri, 2 Dec 2005 13:13:45 -0500 Received: from fmr19.intel.com ([134.134.136.18]:50851 "EHLO orsfmr004.jf.intel.com") by vger.kernel.org with ESMTP id S1750850AbVLBSNp (ORCPT ); Fri, 2 Dec 2005 13:13:45 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id jB2IDTjo029349; Fri, 2 Dec 2005 18:13:30 GMT Received: from vortex.site (vortex.co.intel.com [10.10.212.123]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id jB2IDTg6004995; Fri, 2 Dec 2005 18:13:29 GMT Date: Fri, 2 Dec 2005 10:16:37 -0800 From: Randy Dunlap To: ide Cc: axboe , jgarzik Subject: [PATCH 0/6] SATA use ACPI methods for PM Message-Id: <20051202101637.2167851a.randy_d_dunlap@linux.intel.com> X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.3; x86_64-unknown-linux-gnu) X-Face: "}I"O`t9.W]b]8SycP0Jap#)%JR,H)Eg(FP)?S1qh0ZJRu|mz*%SKpL7rcKI3(OwmK2@uo\b2 GB:7w&?a,*<8v[ldN`5)MXFcm'cjwRs5)ui)j Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 276 This is an update to the SATA suspend/resume patches to use ACPI methods (specifically _SDD and _GTF). This patch series applies to 2.6.15-rc4. It boots but needs lots of testing & review/comments, as well as adding a call to write taskfiles on COMRESET event(s) (at least on async. loss of signal). This is not intended to be a final patch for merging. The patchset begins with the libata suspend/resume patch from Jens Axboe and builds on that. --- ~Randy - 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 From osv@javad.com Fri Dec 2 11:33:57 2005 Return-Path: Received: from vger.kernel.org ([209.132.176.167]) by xenotime.net for ; Fri, 2 Dec 2005 11:34:52 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750976AbVLBTeI (ORCPT ); Fri, 2 Dec 2005 14:34:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750978AbVLBTeI (ORCPT ); Fri, 2 Dec 2005 14:34:08 -0500 Received: from javad.com ([216.122.176.236]:52752 "EHLO javad.com") by vger.kernel.org with ESMTP id S1750976AbVLBTeH (ORCPT ); Fri, 2 Dec 2005 14:34:07 -0500 Received: from osv ([87.236.81.130]) by javad.com (8.11.6/8.11.0) with ESMTP id jB2JY4j56612; Fri, 2 Dec 2005 19:34:04 GMT (envelope-from osv@javad.com) Received: from osv by osv with local (Exim 4.54) id 1EiGfN-0005oB-TG; Fri, 02 Dec 2005 22:33:57 +0300 From: "Sergei Organov" To: "Jeff Garzik" Cc: Subject: Re: SATA ICH6M problems on Sharp M4000 References: <200511221013.04798.marekw1977> In-reply-to: <200511221013.04798.marekw1977> Date: Fri, 02 Dec 2005 22:33:57 +0300 Message-ID: <87u0dri996.fsf@javad.com> User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Status: RO X-Status: X-Keywords: X-UID: 330 Jeff Garzik wrote: > Josh Litherland wrote: > > Trying to get this laptop operational; it has SATA for the hard disc and > > PATA for the optical drive. The hard drive is wired to the secondary > > IDE interface, the optical to the primary. [...] > > With ata_piix driving the hard drive, performance is great, but the > > optical device is never enumerated. I have exactly the same problem with my IBM ThinkPad T43 and 2.6.14 kernel and still can't find a way to let ata_piix manage the hard drive and generic_ide to manage the optical one. BIOS doesn't have any settings for SATA on this notebook. > > Expected behavior, since the default for module option atapi_enabled > is zero (disabled). > > > When the piix driver tries to load, the following occurs: > > > > ide0: I/O resource 0x1F0-0x1F7 not free. > > ide0: ports already in use, skipping probe > > ide1: I/O resource 0x170-0x177 not free. > > ide1: ports already in use, skipping probe [...] > So far everything seems to be expected behavior. Sorry, but provided ata_piix has ignored the optical drive, couldn't corresponding I/O resource be left free so that subsequently loaded, say, generic-ide module is able to get over and support the drive? BTW, loading the modules in reverse order helped on 2.6.13 kernel (that I'm currently using) as generic-ide didn't recognize the hard-drive at all allowing ata_piix to get over it later. With 2.6.14 kernel generic-ide does recognize both hard-drive and optical drive thus preventing ata_piix from managing the hard-drive :( -- Sergei. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From jgarzik@pobox.com Fri Dec 2 21:41:27 2005 Retur