daily CVS update output
Updating src tree: P src/etc/security P src/sys/arch/arm/at91/at91emac.c P src/sys/arch/arm/fdt/gic_fdt.c P src/sys/dev/mii/ihphy.c P src/sys/dev/pci/if_wm.c P src/sys/stand/efiboot/boot.c P src/tests/usr.bin/indent/token_binary_op.c P src/tests/usr.bin/indent/token_comment.c P src/tests/usr.bin/indent/token_unary_op.c P src/usr.bin/indent/indent.c P src/usr.bin/indent/io.c P src/usr.bin/indent/pr_comment.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 47599151 Nov 5 03:03 ls-lRA.gz
Re: IDENTIFY failed
From: Rin Okuyama
Subject: Re: IDENTIFY failed
Date: Thu, 4 Nov 2021 21:18:35 +0900
> Yeah. Patrick, Jun, experiment to adjust delays will be appreciated a
> lot,
> if you have time. But, dmesg should be helpful enough :)
On my environment,
1. after that,back to the original kernel , boot fine.
> NetBSD 9.99.92 (GENERIC) #0: Mon Oct 25 20:32:38 UTC 2021 Failed
8 times reboot,and cold boot after 15min system stop seems ok.
2. change deley time 500/250/125/60/30/15/7/0. boot fine.
+#defineAHCISATA_EXTRA_DELAY_TIME 250
--- ahcisata_core.c 2021/11/04 23:58:09 1.1
+++ ahcisata_core.c 2021/11/05 00:00:11
@@ -114,6 +114,7 @@
#define ATA_DELAY 1 /* 10s for a drive I/O */
#define ATA_RESET_DELAY 31000 /* 31s for a drive reset */
#define AHCI_RST_WAIT (ATA_RESET_DELAY / 10)
+#defineAHCISATA_EXTRA_DELAY_TIME 250
const struct ata_bustype ahci_ata_bustype = {
.bustype_type = SCSIPI_BUSTYPE_ATA,
@@ -971,7 +972,7 @@
end:
ahci_channel_stop(sc, chp, flags);
#ifdef AHCISATA_EXTRA_DELAY
- ata_delay(chp, 500, "ahcirst", flags);
+ ata_delay(chp, AHCISATA_EXTRA_DELAY_TIME, "ahcirst", flags);
#endif
/* clear port interrupt register */
AHCI_WRITE(sc, AHCI_P_IS(chp->ch_channel), 0x);
@@ -997,7 +998,7 @@
}
ata_kill_active(chp, KILL_RESET, flags);
#ifdef AHCISATA_EXTRA_DELAY
- ata_delay(chp, 500, "ahcirst", flags);
+ ata_delay(chp, AHCISATA_EXTRA_DELAY_TIME, "ahcirst", flags);
#endif
/* clear port interrupt register */
AHCI_WRITE(sc, AHCI_P_IS(chp->ch_channel), 0x);
@@ -1069,7 +1070,7 @@
achp->ahcic_sstatus, AT_WAIT)) {
case SStatus_DET_DEV:
#ifdef AHCISATA_EXTRA_DELAY
- ata_delay(chp, 500, "ahcidv", AT_WAIT);
+ ata_delay(chp, AHCISATA_EXTRA_DELAY_TIME, "ahcidv", AT_WAIT);
#endif
/* Initial value, used in case the soft reset fails */
@@ -,7 +1112,7 @@
AHCI_P_IX_PSS | AHCI_P_IX_DHRS | AHCI_P_IX_SDBS);
#ifdef AHCISATA_EXTRA_DELAY
/* wait 500ms before actually starting operations */
- ata_delay(chp, 500, "ahciprb", AT_WAIT);
+ ata_delay(chp, AHCISATA_EXTRA_DELAY_TIME, "ahciprb", AT_WAIT);
#endif
break;
Re: IDENTIFY failed
From: Rin Okuyama Subject: Re: IDENTIFY failed Date: Thu, 4 Nov 2021 21:00:58 +0900 > Hmm, if affected hardware is somehow limited, we can just introduce > something > like AHCI_QUIRK_EXTRADELAY. Otherwise, we can reconsider, for example, > before > NetBSD 10 is released. > Jun, Patrick, can you please provide full dmesg for your machines? two machines, https://github.com/ebijun/NetBSD/blob/master/dmesg/amd64/SONY_VGN-NW50JB https://github.com/ebijun/NetBSD/blob/master/dmesg/amd64/ASUS_X200M thanx. -- Jun Ebihara
Re: IDENTIFY failed
Hello. Without going and reading the probe routines, I wonder if we can create some sort of hybrid approach? Specifically, probe with the shorter delays, then, if we get a timeout, reset and probe with the longer delays? That wil cause hardware that doesn't exhibit the behavior to work with the faster probes, while slowing the non-working hardware, slightly during boot, while it's probed twice. Again, I'm not sure how dificult it is to introduce that logic, but it's a similar logic we used to determine if old PATA drives needed specific ATA commands to address blocks over 148GB, or something like that. (We'd try the command with the standard command and, if it failed, then try it with the altered command and set a quirk.) -thanks -Brian
Re: IDENTIFY failed
Yeah. Patrick, Jun, experiment to adjust delays will be appreciated a lot, if you have time. But, dmesg should be helpful enough :) Thanks, rin On 2021/11/04 21:04, Jared McNeill wrote: It's also possible that 2 full seconds of delays are unnecessary. Do those delays really need to be 500ms each? On Thu, 4 Nov 2021, Rin Okuyama wrote: Yeah, I know that. But, we already have two problem reports. What I am concerned about is similar problems will occur for a lot of machines. (Thinking again...) But, yes, by this way, innocent people will be punished forever by extra seconds per boot... Hmm, if affected hardware is somehow limited, we can just introduce something like AHCI_QUIRK_EXTRADELAY. Otherwise, we can reconsider, for example, before NetBSD 10 is released. Jun, Patrick, can you please provide full dmesg for your machines? Thanks, rin On 2021/11/04 19:58, Jared McNeill wrote: From the commit message: There are a handful of inexplicable 500ms delays introduced to the drive detect path in this driver, slowing boot. They can be re-enabled with options AHCISATA_EXTRA_DELAY, but should not be enabled for normal kernels. If a delay does need to be introduced in these places, the value should either be more carefully selected or the scope limited to hardware that requires the extra delay. I don't have any hardware that has problems with the delays removed, so go ahead and revert this commit if you're happy with that as a solution. It would be better to fix the problem properly though as this costs multiple seconds per drive at boot. Take care, Jared On Thu, 4 Nov 2021, Rin Okuyama wrote: Can't we put back AHCISATA_EXTRA_DELAY by default? IIUC, the option affects only probe/reset; no bad effects for I/O performance. Thanks, rin On 2021/11/01 21:19, Patrick Welche wrote: On Fri, Oct 29, 2021 at 01:05:26PM +0900, Jun Ebihara wrote: From: matthew green Subject: re: IDENTIFY failed Date: Fri, 29 Oct 2021 07:18:09 +1100 autoconfiguration error: ahcisata0 port 1: setting WDCTL_RST failed for drive 0 https://mail-index.netbsd.org/current-users/2021/10/27/msg041615.html this one has reduced timeframe, too: between NetBSD 9.99.91 (GENERIC) #0: Tue Oct 12 19:57:53 UTC 2021 OK NetBSD 9.99.92 (GENERIC) #0: Mon Oct 25 20:32:38 UTC 2021 Failed which changed how some interrupt handling works, and: http://mail-index.netbsd.org/source-changes/2021/10/11/msg132941.html which removed some delays in the probe path. possibly this one is more likely to be at fault since it touches the probe path directly. add /usr/src/sys/arch/amd64/conf/GENERIC.local options AHCISATA_EXTRA_DELAY compile kernel That did the trick - thanks! (Wanted to be near the box before trying it) Cheers, Patrick
Re: IDENTIFY failed
It's also possible that 2 full seconds of delays are unnecessary. Do those delays really need to be 500ms each? On Thu, 4 Nov 2021, Rin Okuyama wrote: Yeah, I know that. But, we already have two problem reports. What I am concerned about is similar problems will occur for a lot of machines. (Thinking again...) But, yes, by this way, innocent people will be punished forever by extra seconds per boot... Hmm, if affected hardware is somehow limited, we can just introduce something like AHCI_QUIRK_EXTRADELAY. Otherwise, we can reconsider, for example, before NetBSD 10 is released. Jun, Patrick, can you please provide full dmesg for your machines? Thanks, rin On 2021/11/04 19:58, Jared McNeill wrote: From the commit message: There are a handful of inexplicable 500ms delays introduced to the drive detect path in this driver, slowing boot. They can be re-enabled with options AHCISATA_EXTRA_DELAY, but should not be enabled for normal kernels. If a delay does need to be introduced in these places, the value should either be more carefully selected or the scope limited to hardware that requires the extra delay. I don't have any hardware that has problems with the delays removed, so go ahead and revert this commit if you're happy with that as a solution. It would be better to fix the problem properly though as this costs multiple seconds per drive at boot. Take care, Jared On Thu, 4 Nov 2021, Rin Okuyama wrote: Can't we put back AHCISATA_EXTRA_DELAY by default? IIUC, the option affects only probe/reset; no bad effects for I/O performance. Thanks, rin On 2021/11/01 21:19, Patrick Welche wrote: On Fri, Oct 29, 2021 at 01:05:26PM +0900, Jun Ebihara wrote: From: matthew green Subject: re: IDENTIFY failed Date: Fri, 29 Oct 2021 07:18:09 +1100 autoconfiguration error: ahcisata0 port 1: setting WDCTL_RST failed for drive 0 https://mail-index.netbsd.org/current-users/2021/10/27/msg041615.html this one has reduced timeframe, too: between NetBSD 9.99.91 (GENERIC) #0: Tue Oct 12 19:57:53 UTC 2021 OK NetBSD 9.99.92 (GENERIC) #0: Mon Oct 25 20:32:38 UTC 2021 Failed which changed how some interrupt handling works, and: http://mail-index.netbsd.org/source-changes/2021/10/11/msg132941.html which removed some delays in the probe path. possibly this one is more likely to be at fault since it touches the probe path directly. add /usr/src/sys/arch/amd64/conf/GENERIC.local options AHCISATA_EXTRA_DELAY compile kernel That did the trick - thanks! (Wanted to be near the box before trying it) Cheers, Patrick
Re: IDENTIFY failed
Yeah, I know that. But, we already have two problem reports. What I am concerned about is similar problems will occur for a lot of machines. (Thinking again...) But, yes, by this way, innocent people will be punished forever by extra seconds per boot... Hmm, if affected hardware is somehow limited, we can just introduce something like AHCI_QUIRK_EXTRADELAY. Otherwise, we can reconsider, for example, before NetBSD 10 is released. Jun, Patrick, can you please provide full dmesg for your machines? Thanks, rin On 2021/11/04 19:58, Jared McNeill wrote: From the commit message: There are a handful of inexplicable 500ms delays introduced to the drive detect path in this driver, slowing boot. They can be re-enabled with options AHCISATA_EXTRA_DELAY, but should not be enabled for normal kernels. If a delay does need to be introduced in these places, the value should either be more carefully selected or the scope limited to hardware that requires the extra delay. I don't have any hardware that has problems with the delays removed, so go ahead and revert this commit if you're happy with that as a solution. It would be better to fix the problem properly though as this costs multiple seconds per drive at boot. Take care, Jared On Thu, 4 Nov 2021, Rin Okuyama wrote: Can't we put back AHCISATA_EXTRA_DELAY by default? IIUC, the option affects only probe/reset; no bad effects for I/O performance. Thanks, rin On 2021/11/01 21:19, Patrick Welche wrote: On Fri, Oct 29, 2021 at 01:05:26PM +0900, Jun Ebihara wrote: From: matthew green Subject: re: IDENTIFY failed Date: Fri, 29 Oct 2021 07:18:09 +1100 autoconfiguration error: ahcisata0 port 1: setting WDCTL_RST failed for drive 0 https://mail-index.netbsd.org/current-users/2021/10/27/msg041615.html this one has reduced timeframe, too: between NetBSD 9.99.91 (GENERIC) #0: Tue Oct 12 19:57:53 UTC 2021 OK NetBSD 9.99.92 (GENERIC) #0: Mon Oct 25 20:32:38 UTC 2021 Failed which changed how some interrupt handling works, and: http://mail-index.netbsd.org/source-changes/2021/10/11/msg132941.html which removed some delays in the probe path. possibly this one is more likely to be at fault since it touches the probe path directly. add /usr/src/sys/arch/amd64/conf/GENERIC.local options AHCISATA_EXTRA_DELAY compile kernel That did the trick - thanks! (Wanted to be near the box before trying it) Cheers, Patrick
Re: IDENTIFY failed
From the commit message: There are a handful of inexplicable 500ms delays introduced to the drive detect path in this driver, slowing boot. They can be re-enabled with options AHCISATA_EXTRA_DELAY, but should not be enabled for normal kernels. If a delay does need to be introduced in these places, the value should either be more carefully selected or the scope limited to hardware that requires the extra delay. I don't have any hardware that has problems with the delays removed, so go ahead and revert this commit if you're happy with that as a solution. It would be better to fix the problem properly though as this costs multiple seconds per drive at boot. Take care, Jared On Thu, 4 Nov 2021, Rin Okuyama wrote: Can't we put back AHCISATA_EXTRA_DELAY by default? IIUC, the option affects only probe/reset; no bad effects for I/O performance. Thanks, rin On 2021/11/01 21:19, Patrick Welche wrote: On Fri, Oct 29, 2021 at 01:05:26PM +0900, Jun Ebihara wrote: From: matthew green Subject: re: IDENTIFY failed Date: Fri, 29 Oct 2021 07:18:09 +1100 autoconfiguration error: ahcisata0 port 1: setting WDCTL_RST failed for drive 0 https://mail-index.netbsd.org/current-users/2021/10/27/msg041615.html this one has reduced timeframe, too: between NetBSD 9.99.91 (GENERIC) #0: Tue Oct 12 19:57:53 UTC 2021 OK NetBSD 9.99.92 (GENERIC) #0: Mon Oct 25 20:32:38 UTC 2021 Failed which changed how some interrupt handling works, and: http://mail-index.netbsd.org/source-changes/2021/10/11/msg132941.html which removed some delays in the probe path. possibly this one is more likely to be at fault since it touches the probe path directly. add /usr/src/sys/arch/amd64/conf/GENERIC.local options AHCISATA_EXTRA_DELAY compile kernel That did the trick - thanks! (Wanted to be near the box before trying it) Cheers, Patrick
Re: IDENTIFY failed
Can't we put back AHCISATA_EXTRA_DELAY by default? IIUC, the option affects only probe/reset; no bad effects for I/O performance. Thanks, rin On 2021/11/01 21:19, Patrick Welche wrote: On Fri, Oct 29, 2021 at 01:05:26PM +0900, Jun Ebihara wrote: From: matthew green Subject: re: IDENTIFY failed Date: Fri, 29 Oct 2021 07:18:09 +1100 autoconfiguration error: ahcisata0 port 1: setting WDCTL_RST failed for drive 0 https://mail-index.netbsd.org/current-users/2021/10/27/msg041615.html this one has reduced timeframe, too: between NetBSD 9.99.91 (GENERIC) #0: Tue Oct 12 19:57:53 UTC 2021 OK NetBSD 9.99.92 (GENERIC) #0: Mon Oct 25 20:32:38 UTC 2021 Failed which changed how some interrupt handling works, and: http://mail-index.netbsd.org/source-changes/2021/10/11/msg132941.html which removed some delays in the probe path. possibly this one is more likely to be at fault since it touches the probe path directly. add /usr/src/sys/arch/amd64/conf/GENERIC.local options AHCISATA_EXTRA_DELAY compile kernel That did the trick - thanks! (Wanted to be near the box before trying it) Cheers, Patrick
