From: Matt Corallo <yalbrymrb@mattcorallo.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: PMBus memory overflow
Date: Thu, 17 Apr 2025 14:14:58 -0400 [thread overview]
Message-ID: <e030f44f-11ee-4739-b9d3-c22883bbbf02@mattcorallo.com> (raw)
In-Reply-To: <9e01e3ec-3ac5-4d83-a065-d00d568b9cc7@roeck-us.net>
On 4/17/25 2:00 PM, Guenter Roeck wrote:
> On Thu, Apr 17, 2025 at 11:39:14AM -0400, Matt Corallo wrote:
>> When adding the PMBus entry for a FSP520-20RAB (actually FSP Twins Pro but
>> it appears to be identical hardware with a provided SMBus -> USB adapter and
>> it self-reports as an FSP520-20RAB when queried over PMBus using the old
>> pmbus_peek.c script) with `echo pmbus 0x59 >
>> /sys/bus/i2c/devices/i2c-3/new_device` I got the following BUG_ON (on
>> Proxmox's 6.8.12-8-pve kernel). Its redundant and reports back fine on 0x60
>> and 0x59 for both of its modules (using pmbus_peek.c) and I'd already added
>> 0x60 and it BUG'd adding the second module at 0x59.
>>
> ...
>> Apr 17 15:31:19 rackchill-refresh kernel: i2c_smbus_read_block_data+0x116/0x120
>> Apr 17 15:31:19 rackchill-refresh kernel:
>> pmbus_check_block_register.constprop.0+0x77/0x100 [pmbus_core]
>
> Interesting. That function reads into a buffer which is larger than the
> largest valid PMBus transaction. I can only imagine that the controller
> returns invalid data in that transaction, where the first returned byte
> is not the length of the transfer but something else.
> i2c_smbus_read_block_data() does an unconditional
> memcpy(values, &data.block[1], data.block[0]);
> which of course will go haywire if data.block[0] (or in other words the
> first data byte returned from the device) exceeds the size of the
> data buffer. Do you happen to have a datasheet ?
I do not, sadly (though FSP support has been rumored to help out at least marginally, though they
haven't been useful for me). Interestingly the (I guess ancient now) pmbus_peek.c script has no
issues reading from it (added a quick print on the -E2BIG line and it didn't get hit). pmbuss_peek.c
says the following:
root@rackchill-refresh:~# ./a.out -b /dev/i2c-3 -s 0x59
PMBus slave on /dev/i2c-3, address 0x59
Inventory Data:
Manufacturer: FSP-GROUP
Model: FSP520-20RAB
Revision: (null)
Built on:
Serial:
IC Device: PIC24FJ32GA004
PMBus revisions (0x22): part I, ver 1.1; part II, ver 1.2
Capabilities (0x90): PEC, SMBALERT#, 100 KHz
Status 0000:
Attribute Values:
page 00: (BITMAP)
operation 00: (BITMAP)
on_off_config 15: (BITMAP)
vout_mode 17: (BITMAP)
fan_command_1 0000: 0
ein ba4ba00938ba: 5.26211e+06
eout 1e56a12038ba: 5.29753e+06
vin f1e8: 122 Volts
iin c09c: 0.609375 Amperes
vout 1869: 12.2051 Volts
iout caad: 5.35156 Amperes
temperature_1 001c: 28 degrees Celsius
temperature_2 0024: 36 degrees Celsius
fan_speed_1 1a1f: 4344
frequency f0ec: 59
pout f108: 66 Watts
pin f128: 74 Watts
mfr_vout_min 0000: 0 Volts
mfr_iout_max 0000: 0 Amperes
root@rackchill-refresh:~# ./a.out -b /dev/i2c-3 -s 0x58
PMBus slave on /dev/i2c-3, address 0x58
Inventory Data:
Manufacturer: FSP-GROUP
Model: FSP520-20RAB
Revision: (null)
Built on:
Serial:
IC Device: PIC24FJ32GA004
PMBus revisions (0x22): part I, ver 1.1; part II, ver 1.2
Capabilities (0x90): PEC, SMBALERT#, 100 KHz
Status 0000:
Attribute Values:
page 00: (BITMAP)
operation 00: (BITMAP)
on_off_config 15: (BITMAP)
vout_mode 17: (BITMAP)
fan_command_1 0000: 0
ein 0574e89f8070: 7.63164e+06
eout 613f88b78070: 4.47254e+06
vin f1e8: 122 Volts
iin c039: 0.222656 Amperes
vout 1871: 12.2207 Volts
iout c11e: 1.11719 Amperes
temperature_1 001b: 27 degrees Celsius
temperature_2 0024: 36 degrees Celsius
fan_speed_1 13e5: 3988
frequency f0ec: 59
pout f038: 14 Watts
pin f050: 20 Watts
mfr_vout_min 0000: 0 Volts
mfr_iout_max 0000: 0 Amperes
next prev parent reply other threads:[~2025-04-17 18:15 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 15:39 PMBus memory overflow Matt Corallo
2025-04-17 18:00 ` Guenter Roeck
2025-04-17 18:14 ` Matt Corallo [this message]
2025-04-18 1:21 ` Guenter Roeck
2025-04-18 21:03 ` Matt Corallo
2025-04-18 22:30 ` Guenter Roeck
2025-04-19 17:53 ` Matt Corallo
2025-04-19 19:05 ` Guenter Roeck
2025-04-19 19:29 ` Matt Corallo
2025-04-19 22:38 ` Guenter Roeck
2025-04-19 22:49 ` Guenter Roeck
2025-04-20 2:29 ` Matt Corallo
2025-04-20 3:03 ` Guenter Roeck
2025-04-25 8:16 ` Wolfram Sang
2025-05-05 20:41 ` Matt Corallo
2025-05-05 20:50 ` Guenter Roeck
2025-05-05 20:57 ` Matt Corallo
2025-05-06 1:39 ` Guenter Roeck
2025-06-06 20:57 ` Matt Corallo
2025-06-07 8:19 ` Greg KH
2025-06-07 13:25 ` Matt Corallo
2025-06-08 7:14 ` Greg KH
2025-06-09 13:57 ` Matt Corallo
2026-03-01 13:46 ` Matt Corallo
2026-03-01 16:12 ` Kees Cook
2026-03-01 17:10 ` Matt Corallo
2026-03-01 20:17 ` Guenter Roeck
2026-03-02 5:09 ` Kees Cook
2026-03-02 5:19 ` Guenter Roeck
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=e030f44f-11ee-4739-b9d3-c22883bbbf02@mattcorallo.com \
--to=yalbrymrb@mattcorallo.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux@roeck-us.net \
/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