From owner-freebsd-geom@freebsd.org Wed Jan 25 22:59:27 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4CE8DCC199D for ; Wed, 25 Jan 2017 22:59:27 +0000 (UTC) (envelope-from octavianh@gmail.com) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1DB9B84 for ; Wed, 25 Jan 2017 22:59:26 +0000 (UTC) (envelope-from octavianh@gmail.com) Received: by mail-qt0-x235.google.com with SMTP id v23so44608880qtb.0 for ; Wed, 25 Jan 2017 14:59:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=IxnkPxRf1wcGVqxE74tCCCdKSa4xYrPUEMNaViQjPXA=; b=M0+Ptnsji2SNY8kKHF7jORcL2b9Bi0ZzDKp/AZQ2mEKxMQKmPHvZDf5gU89IGYl/zm wSOSeBwm0aCL9UMDuNPRB9MIoUG2RTVBQ5FQA78Uy+aEZXhOScoAhIRK14NqdAfiZxRD xbAeBuBwTt9Z4eGJJS/qVpiMPlwWJ7Rf9LA+LeeCC8KaKiddNxvTJPx6wgyvPZjrA5lE /dwm+TQd/FCovBCEeEU6kWbwCiTUgUvFDIEQ6FXZsnYaGNjA1oqQqKMKdcGputG/HOZw qbggwuBLKsNGD9CfhhXVqKmxrgORL9DTAAz45Me4nqENVV9o9jYBQ77B3bE1/afZBcAR UtiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IxnkPxRf1wcGVqxE74tCCCdKSa4xYrPUEMNaViQjPXA=; b=hFKMVjL58ajQ1W2UW/ut0TnvIjtxgidJPhQZsKexhKzZErZz/LqH2W3RSgQa+eEt5X CKVbWAskZIeew8EzhrF3kIfvvC5czFroR4Uvt+duYn6rJm4wrGR4DN2fklDf02DzePge s0I0HFWpZWnSknC05IBZ7SmW7MwDvB4w1Tk6R/46BYENRRgENUUMnVMp5ikT04Mz5Xmb V4fPl6AdP09gjdh1UNzpM2Fq/m18IJw0G0maD+2hS5ML3OtH8o4t3p2Q/cgMCZw17Gy7 B2639X3SVNhPLd97VsxLb7wLSV68LPfzAmKsC55axk8IUpux0uS3wbvyukxwm9ooiFKI iYRQ== X-Gm-Message-State: AIkVDXL8vgAjD+mM0onvv+F30tYhXPBx02fPVqW5jV4PHQkomcZ6sJyV7iyXHD2F6KX8PgBP3u7rOYM/EFG6FQ== X-Received: by 10.200.34.12 with SMTP id o12mr36502081qto.93.1485385165942; Wed, 25 Jan 2017 14:59:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.82.49 with HTTP; Wed, 25 Jan 2017 14:59:25 -0800 (PST) From: Octavian Hornoiu Date: Wed, 25 Jan 2017 14:59:25 -0800 Message-ID: Subject: AHCI Issues with WDC Black drives and GEOM_MIRROR To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 22:59:27 -0000 OS: 10.3-RELEASE-p12 Motherboard: ASRock FM2A85X Extreme6 FM2 AMD A85X (Hudson D4) SATA 6Gb/s USB 3.0 HDMI ATX AMD Motherboard Memory: 16 GB RAM 6 Drives: 6x 1TB WD1001FALS (Caviar BLACK) I am having a strange issue where I have 6 drives attached to my motherboard and 4 of them are coming up as SATA 2.x and the others are coming up in a strange downgraded mode. The first 4 disks are always shown as being normal and ada4/5 always have the strange configuration. I know the motherboard chipset is good and supports 7 drives of SATA 2/3 in any combination so I'm perplexed as to what the issue is. Why are drives 4 and 5 listed as being on bus ata0 and ata1 instead of ahcich4 and 5? Here is the dmesg output: Jan 25 14:09:15 beastie3 kernel: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 Jan 25 14:09:15 beastie3 kernel: ada0: ATA8-ACS SATA 2.x device Jan 25 14:09:15 beastie3 kernel: ada0: Serial Number WD-WMATV0273934 Jan 25 14:09:15 beastie3 kernel: ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) Jan 25 14:09:15 beastie3 kernel: ada0: Command Queueing enabled Jan 25 14:09:15 beastie3 kernel: ada0: 953869MB (1953525168 512 byte sectors) Jan 25 14:09:15 beastie3 kernel: ada0: Previously was known as ad4 Jan 25 14:09:15 beastie3 kernel: ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 Jan 25 14:09:15 beastie3 kernel: ada1: ATA8-ACS SATA 2.x device Jan 25 14:09:15 beastie3 kernel: ada1: Serial Number WD-WMATV0098011 Jan 25 14:09:15 beastie3 kernel: ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) Jan 25 14:09:15 beastie3 kernel: ada1: Command Queueing enabled Jan 25 14:09:15 beastie3 kernel: ada1: 953869MB (1953525168 512 byte sectors) Jan 25 14:09:15 beastie3 kernel: ada1: Previously was known as ad6 Jan 25 14:09:15 beastie3 kernel: ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 Jan 25 14:09:15 beastie3 kernel: ada2: ATA8-ACS SATA 2.x device Jan 25 14:09:15 beastie3 kernel: ada2: Serial Number WD-WMATV0333576 Jan 25 14:09:15 beastie3 kernel: ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) Jan 25 14:09:15 beastie3 kernel: ada2: Command Queueing enabled Jan 25 14:09:15 beastie3 kernel: ada2: 953869MB (1953525168 512 byte sectors) Jan 25 14:09:15 beastie3 kernel: ada2: Previously was known as ad8 Jan 25 14:09:15 beastie3 kernel: ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 Jan 25 14:09:15 beastie3 kernel: ada3: ATA8-ACS SATA 2.x device Jan 25 14:09:15 beastie3 kernel: ada3: Serial Number WD-WMATV0280372 Jan 25 14:09:15 beastie3 kernel: ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) Jan 25 14:09:15 beastie3 kernel: ada3: Command Queueing enabled Jan 25 14:09:15 beastie3 kernel: ada3: 953869MB (1953525168 512 byte sectors) Jan 25 14:09:15 beastie3 kernel: ada3: Previously was known as ad10 Jan 25 14:09:15 beastie3 kernel: ada4 at ata0 bus 0 scbus4 target 1 lun 0 Jan 25 14:09:15 beastie3 kernel: ada4: ATA8-ACS SATA 2.x device Jan 25 14:09:15 beastie3 kernel: ada4: Serial Number WD-WMATV1053912 Jan 25 14:09:15 beastie3 kernel: ada4: 133.000MB/s transfers (UDMA6, PIO 8192bytes) Jan 25 14:09:15 beastie3 kernel: ada4: 953869MB (1953525168 512 byte sectors) Jan 25 14:09:15 beastie3 kernel: ada4: Previously was known as ad1 Jan 25 14:09:15 beastie3 kernel: ada5 at ata1 bus 0 scbus5 target 1 lun 0 Jan 25 14:09:15 beastie3 kernel: ada5: ATA8-ACS SATA 2.x device Jan 25 14:09:15 beastie3 kernel: ada5: Serial Number WD-WMATV0972074 Jan 25 14:09:15 beastie3 kernel: ada5: 133.000MB/s transfers (UDMA6, PIO 8192bytes) Jan 25 14:09:15 beastie3 kernel: ada5: 953869MB (1953525168 512 byte sectors) Jan 25 14:09:15 beastie3 kernel: ada5: Previously was known as ad3 Jan 25 14:09:15 beastie3 kernel: SMP: AP CPU #1 Launched! Jan 25 14:09:15 beastie3 kernel: Timecounter "TSC-low" frequency 1696947066 Hz quality 1000 Jan 25 14:09:15 beastie3 kernel: GEOM_MIRROR: Cancelling unmapped because of ada5p3. Jan 25 14:09:15 beastie3 kernel: GEOM_MIRROR: Cancelling unmapped because of ada4p3. Jan 25 14:09:15 beastie3 kernel: GEOM_MIRROR: Device mirror/rootfs launched (6/6). Jan 25 14:09:15 beastie3 kernel: Trying to mount root from ufs:/dev/mirror/rootfs [rw]... It seems that the last 2 drives are also getting a GEOM_MIRROR: Cancelling unmapped because of X partition error also. What is this? Thanks for any help and please CC me as I might not be on this list. Thank you! Octavian From owner-freebsd-geom@freebsd.org Thu Jan 26 08:47:43 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A9DECC0244 for ; Thu, 26 Jan 2017 08:47:43 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EB1B1EA2 for ; Thu, 26 Jan 2017 08:47:42 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA00245; Thu, 26 Jan 2017 10:47:40 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1cWfiW-000BIp-Ln; Thu, 26 Jan 2017 10:47:40 +0200 Subject: Re: AHCI Issues with WDC Black drives and GEOM_MIRROR To: Octavian Hornoiu , freebsd-geom@FreeBSD.org References: From: Andriy Gapon Message-ID: Date: Thu, 26 Jan 2017 10:46:44 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 08:47:43 -0000 On 26/01/2017 00:59, Octavian Hornoiu wrote: > OS: 10.3-RELEASE-p12 > Motherboard: ASRock FM2A85X Extreme6 FM2 AMD A85X (Hudson D4) SATA 6Gb/s > USB 3.0 HDMI ATX AMD Motherboard > Memory: 16 GB RAM > 6 Drives: 6x 1TB WD1001FALS (Caviar BLACK) > > I am having a strange issue where I have 6 drives attached to my > motherboard and 4 of them are coming up as SATA 2.x and the others are > coming up in a strange downgraded mode. The first 4 disks are always shown > as being normal and ada4/5 always have the strange configuration. I know > the motherboard chipset is good and supports 7 drives of SATA 2/3 in any > combination so I'm perplexed as to what the issue is. > > Why are drives 4 and 5 listed as being on bus ata0 and ata1 instead of > ahcich4 and 5? Check your BIOS settings. Sometimes they have a separate IDE/AHCI knob for the last two channels. -- Andriy Gapon From owner-freebsd-geom@freebsd.org Fri Jan 27 05:05:12 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C79A8CC3C5E for ; Fri, 27 Jan 2017 05:05:12 +0000 (UTC) (envelope-from octavianh@gmail.com) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83D389CB; Fri, 27 Jan 2017 05:05:12 +0000 (UTC) (envelope-from octavianh@gmail.com) Received: by mail-qt0-x233.google.com with SMTP id k15so114905780qtg.3; Thu, 26 Jan 2017 21:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rRZzaodD22fGWfoLoVHRePseZCP7B14yiwLWbs1dr0w=; b=HQTVkkPQr34lPpSIpYEdK06QTacdzl/mqImZK1AQp+04ydevp3PAHPI2iYP6XE4RCD 5BTa4ItlMuYLWnA0136388uWKjfWMonBCI4jpkGlFNoDHngPY/CEaR3RVaAHyrGVpZLA vIRZ5UdEYzGjCKZIZNybNmk4mVdHNTv+iUV8zlPVLZpmUM465mYCdQofLEM0ZyMaMKEd I+UCqOOvd+hyRbPKUItEtxAefg4E72CW42qTcDc457TWHTmfsJed/Ot/V83O1alpJ2sE y7eYB9WDAn3esqiHwPdEtTCRUnXputi+K6XZLkRZbu7XFySizkP2/U7X0sG3U42P1HSW SHRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rRZzaodD22fGWfoLoVHRePseZCP7B14yiwLWbs1dr0w=; b=e5043vzhbaEOby6j7izVW5SfsvfrefjzI8ki3VaROjTTmYim7h32P7X+X41FGYmC30 4YIUzS1MuzM/97qjVSpEzAtxgYUhrDPbKUQ+5L+zZR7F1nyvt4066xcUFwqKkPeDcuVz O7GfpJS4Z4Nc2wvVM3UKGTEIpqV5yzwGWDsd+GSM22XvdQ1iDNSf2ZsIDCv3L8mFVGaK WMQyGtc2/t+i9cRBR6jmbB762RlCj6Wgbe4I+auXtjkqR+1vIegIAeu9IkMQpRsc7p9e otJ2DBCFO1MkujMtOHDc/8+e0f10vJXzXUT69sKEyIytUabi2ExMw7hioQC+XukZ7Ldr FAHQ== X-Gm-Message-State: AIkVDXJ90VgEzIytbViHzVf//WBVX5MTmKQxx40o2bWm2RUFFpuGe0+hFkpSI4MMzluzecxh6NmoUHXoQfvwDw== X-Received: by 10.237.34.250 with SMTP id q55mr6574189qtc.127.1485493511680; Thu, 26 Jan 2017 21:05:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.82.49 with HTTP; Thu, 26 Jan 2017 21:05:11 -0800 (PST) In-Reply-To: References: From: Octavian Hornoiu Date: Thu, 26 Jan 2017 21:05:11 -0800 Message-ID: Subject: Re: AHCI Issues with WDC Black drives and GEOM_MIRROR To: Andriy Gapon Cc: freebsd-geom@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 05:05:12 -0000 Thank Andriy, it appears my motherboard had a "IDE/SATA" compatibility mode which was enabled by default and i had no idea what the option meant but once i turned it off everything is showing up as AHCI. Thanks for your suggestion! Octavian On Thu, Jan 26, 2017 at 12:46 AM, Andriy Gapon wrote: > On 26/01/2017 00:59, Octavian Hornoiu wrote: > > OS: 10.3-RELEASE-p12 > > Motherboard: ASRock FM2A85X Extreme6 FM2 AMD A85X (Hudson D4) SATA 6Gb/s > > USB 3.0 HDMI ATX AMD Motherboard > > Memory: 16 GB RAM > > 6 Drives: 6x 1TB WD1001FALS (Caviar BLACK) > > > > I am having a strange issue where I have 6 drives attached to my > > motherboard and 4 of them are coming up as SATA 2.x and the others are > > coming up in a strange downgraded mode. The first 4 disks are always > shown > > as being normal and ada4/5 always have the strange configuration. I know > > the motherboard chipset is good and supports 7 drives of SATA 2/3 in any > > combination so I'm perplexed as to what the issue is. > > > > Why are drives 4 and 5 listed as being on bus ata0 and ata1 instead of > > ahcich4 and 5? > > Check your BIOS settings. Sometimes they have a separate IDE/AHCI knob > for the > last two channels. > > > -- > Andriy Gapon > From owner-freebsd-geom@freebsd.org Fri Jan 27 16:56:22 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CFE3BCC324E for ; Fri, 27 Jan 2017 16:56:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 055E1235 for ; Fri, 27 Jan 2017 16:56:21 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA04167 for ; Fri, 27 Jan 2017 18:56:14 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1cX9or-000D3S-R6 for freebsd-geom@FreeBSD.org; Fri, 27 Jan 2017 18:56:13 +0200 To: freebsd-geom@FreeBSD.org From: Andriy Gapon Subject: g_disk_done() vs a destroyed disk Message-ID: Date: Fri, 27 Jan 2017 18:55:18 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 16:56:22 -0000 I've seen a situation where g_disk_done() was called on a bio after the corresponding disk had been already destroyed via g_disk_destroy(). That call resulted in a crash here: devstat_end_transaction_bio_bt(sc->dp->d_devstat, bp, &now); because sc->dp was NULL. Is it a bug that we do not check for dp being NULL (or dp->d_destroyed being set) in g_disk_done() ? Or is it a bug that a controller driver called biodone() for that bio having earlier called disk_destroy() ? Thanks! -- Andriy Gapon From owner-freebsd-geom@freebsd.org Fri Jan 27 21:55:12 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B95CCC3195 for ; Fri, 27 Jan 2017 21:55:12 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 4150F825; Fri, 27 Jan 2017 21:55:12 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 7228F273E8; Fri, 27 Jan 2017 21:55:05 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v0RLt400031396; Fri, 27 Jan 2017 21:55:04 GMT (envelope-from phk@phk.freebsd.dk) To: Andriy Gapon cc: freebsd-geom@FreeBSD.org Subject: Re: g_disk_done() vs a destroyed disk In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31394.1485554104.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jan 2017 21:55:04 +0000 Message-ID: <31395.1485554104@critter.freebsd.dk> X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 21:55:12 -0000 -------- In message , Andriy Gapo= n writes: > >I've seen a situation where g_disk_done() was called on a bio after the >corresponding disk had been already destroyed via g_disk_destroy(). >That call resulted in a crash here: > devstat_end_transaction_bio_bt(sc->dp->d_devstat, bp, &now); >because sc->dp was NULL. > >Is it a bug that we do not check for dp being NULL (or dp->d_destroyed be= ing >set) in g_disk_done() ? >Or is it a bug that a controller driver called biodone() for that bio hav= ing >earlier called disk_destroy() ? It is a driver bug to call disk_destroy() before purging all in-flight bio= s with biodone() -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-geom@freebsd.org Sat Jan 28 11:44:54 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7470CC59AA for ; Sat, 28 Jan 2017 11:44:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 39625151D for ; Sat, 28 Jan 2017 11:44:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA07401; Sat, 28 Jan 2017 13:44:51 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1cXRR5-000ExI-6v; Sat, 28 Jan 2017 13:44:51 +0200 Subject: Re: g_disk_done() vs a destroyed disk To: Poul-Henning Kamp References: <31395.1485554104@critter.freebsd.dk> Cc: freebsd-geom@FreeBSD.org From: Andriy Gapon Message-ID: <8de79017-f0b0-c86a-93c5-65be4d97b21c@FreeBSD.org> Date: Sat, 28 Jan 2017 13:43:55 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <31395.1485554104@critter.freebsd.dk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2017 11:44:54 -0000 On 27/01/2017 23:55, Poul-Henning Kamp wrote: > -------- > In message , Andriy Gapon writes: >> >> I've seen a situation where g_disk_done() was called on a bio after the >> corresponding disk had been already destroyed via g_disk_destroy(). >> That call resulted in a crash here: >> devstat_end_transaction_bio_bt(sc->dp->d_devstat, bp, &now); >> because sc->dp was NULL. >> >> Is it a bug that we do not check for dp being NULL (or dp->d_destroyed being >> set) in g_disk_done() ? >> Or is it a bug that a controller driver called biodone() for that bio having I should have said a disk driver here. >> earlier called disk_destroy() ? > > It is a driver bug to call disk_destroy() before purging all in-flight bios > with biodone() Oh, I didn't think of that. So, the correct sequence should be: - call disk_gone() to prevent new I/O - handle all in-flight I/O - call disk_destroy() Is that right? Thank you! -- Andriy Gapon From owner-freebsd-geom@freebsd.org Sat Jan 28 13:23:44 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D183CC4337 for ; Sat, 28 Jan 2017 13:23:44 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 39B36B75; Sat, 28 Jan 2017 13:23:43 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 3379D2738B; Sat, 28 Jan 2017 13:23:42 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v0SDNeZN033961; Sat, 28 Jan 2017 13:23:40 GMT (envelope-from phk@phk.freebsd.dk) To: Andriy Gapon cc: freebsd-geom@FreeBSD.org Subject: Re: g_disk_done() vs a destroyed disk In-reply-to: <8de79017-f0b0-c86a-93c5-65be4d97b21c@FreeBSD.org> From: "Poul-Henning Kamp" References: <31395.1485554104@critter.freebsd.dk> <8de79017-f0b0-c86a-93c5-65be4d97b21c@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <33959.1485609820.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sat, 28 Jan 2017 13:23:40 +0000 Message-ID: <33960.1485609820@critter.freebsd.dk> X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2017 13:23:44 -0000 -------- In message <8de79017-f0b0-c86a-93c5-65be4d97b21c@FreeBSD.org>, Andriy Gapo= n wri tes: >So, the correct sequence should be: >- call disk_gone() to prevent new I/O >- handle all in-flight I/O >- call disk_destroy() >Is that right? exactly! -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= .