From: "Krzysztof Olędzki" <ole@ans.pl>
To: Guenter Roeck <linux@roeck-us.net>,
Heiner Kallweit <hkallweit1@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Bartosz Golaszewski <brgl@bgdev.pl>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Wolfram Sang <wsa@the-dreams.de>
Cc: stable@vger.kernel.org, linux-i2c@vger.kernel.org,
linux-hwmon@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Regression caused by "eeprom: at24: Probe for DDR3 thermal sensor in the SPD case" - "sysfs: cannot create duplicate filename"
Date: Thu, 27 Jun 2024 04:29:16 -0700 [thread overview]
Message-ID: <9541ab9f-0f13-4856-85f0-14615b77142f@ans.pl> (raw)
In-Reply-To: <5a4e1cd6-5770-423b-9a25-a0fbfd93014a@roeck-us.net>
On 24.06.2024 at 20:45, Guenter Roeck wrote:
> On 6/24/24 13:58, Heiner Kallweit wrote:
> [ ... ]
>>
>> Too me the issue also looks like a race. According to the OP's logs:
>> - jc42 at 0x18 is instantiated successfully
>> - jc42 at 0x19 returns -EBUSY. This is what is expected if the device
>> has been instantiated otherwise already.
>> - jc42 at 0x1a returns -EEXIST. Here two instantiations of the the same
>> device seem to collide.
>> - jc42 at 0x1b returns -EBUSY, like at 0x19.
>>
>> So it looks like referenced change isn't wrong, but reveals an
>> underlying issue with device instantiation races.
>
> It isn't just a race, though. Try to unload the at24 (or ee1004 driver
> for DDR4) and load it again, and you'll see the -EBUSY errors. Problem
> is that instantiating those drivers _always_ triggers the call to
> i2c_new_client_device() even if the jc42 device is already instantiated.
> Unloading the spd/eeprom driver doesn't unload the jc42 driver,
> so -EBUSY will be seen if the spd/eeprom driver is loaded again.
>
> I have not been able to reproduce the backtrace with my systems, but those
> are all with AMD CPUs using the piix4 driver, so timing is likely different.
> Another difference is that my systems (with DDR4) use the ee1004 driver.
> That driver instantiates the jc42 devices under a driver lock, so it is
> guaranteed that a single instantiation doesn't interfere with other
> instantiations running in parallel.
Right, sorry for not mentioning this in the original report:
[ 0.269013] pci 0000:00:1f.3: [8086:1c22] type 00 class 0x0c0500
[ 0.269098] pci 0000:00:1f.3: reg 0x10: [mem 0xc3a02000-0xc3a020ff 64bit]
[ 0.269186] pci 0000:00:1f.3: reg 0x20: [io 0x3000-0x301f]
[ 0.334962] pci 0000:00:1f.3: Adding to iommu group 7
[ 7.874736] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt
$ lspci -s 0000:00:1f.3 -vvnn
00:1f.3 SMBus [0c05]: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller [8086:1c22] (rev 04)
Subsystem: Dell Device [1028:04de]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin C routed to IRQ 19
IOMMU group: 7
Region 0: Memory at c3a02000 (64-bit, non-prefetchable) [size=256]
Region 4: I/O ports at 3000 [size=32]
Kernel driver in use: i801_smbus
Krzysztof
next prev parent reply other threads:[~2024-06-27 11:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-23 18:47 Regression caused by "eeprom: at24: Probe for DDR3 thermal sensor in the SPD case" - "sysfs: cannot create duplicate filename" Krzysztof Olędzki
2024-06-24 5:33 ` Guenter Roeck
2024-06-24 8:38 ` Krzysztof Olędzki
2024-06-24 14:54 ` Guenter Roeck
2024-06-24 16:23 ` Guenter Roeck
2024-06-24 20:58 ` Heiner Kallweit
2024-06-25 3:45 ` Guenter Roeck
2024-06-27 11:29 ` Krzysztof Olędzki [this message]
2024-06-27 12:12 ` Krzysztof Olędzki
2024-06-27 11:24 ` Krzysztof Olędzki
2024-06-29 21:56 ` Heiner Kallweit
2024-06-24 5:43 ` Greg Kroah-Hartman
2024-06-24 13:35 ` Guenter Roeck
2024-07-02 20:25 ` Heiner Kallweit
2024-07-07 1:42 ` Krzysztof Olędzki
2024-07-23 14:12 ` Krzysztof Olędzki
2024-08-03 17:19 ` Heiner Kallweit
2024-08-13 16:28 ` Krzysztof Olędzki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9541ab9f-0f13-4856-85f0-14615b77142f@ans.pl \
--to=ole@ans.pl \
--cc=brgl@bgdev.pl \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=hkallweit1@gmail.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=stable@vger.kernel.org \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox