Date: Fri, 24 Oct 2025 13:36:19 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 2612f1b8649b - main - deadfs: Return ENXIO instead of EIO when the device is gone. Message-ID: <aPtWo1UP-UpPdsVf@kib.kiev.ua> In-Reply-To: <202510241012.59OACUDA002781@critter.freebsd.dk> References: <202510240741.59O7fBAe041995@gitrepo.freebsd.org> <aPs27Dc_w10t3ENH@kib.kiev.ua> <202510241012.59OACUDA002781@critter.freebsd.dk>
index | next in thread | previous in thread | raw e-mail
On Fri, Oct 24, 2025 at 10:12:30AM +0000, Poul-Henning Kamp wrote: > -------- > Konstantin Belousov writes: > > > On Fri, Oct 24, 2025 at 07:41:11AM +0000, Poul-Henning Kamp wrote: > > > > Something changed recently, and while testing this fix, I noticed > > Nothing changed WRT code, it is just a race that causes the behavior. > > That is why I wrote "something", because I agree that it is not code > in our tree which has changed. > > > > that drm-kmod-66/i915kms may be the condition which trigger > > > the different code-path. > > It worries me if loading drm-kmod-66/i915kms can cause this kind > of change of behaviour. > > Even with the fix, I see 2-4 read(2) operations return EIO before > the ENXIO manifests. > > The only hypothesis I have, is that something in DRM-world hogs > some kind of HW resource, but I do not have time (nor drm-skillz) > to look into that this morning, and I wanted to get the ENXIO fix > in for RELENG-15 purposes[1]. I do not think that DRM really affects the code path for io. I see several EIOs in CAM, in particular scsi_da.c, but I do not know CAM/USB/umass stack to track that down by reading.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aPtWo1UP-UpPdsVf>