Re: "Could not allocate I/O space" and "intsmb0 attach returned 6" in a under-Hyper-V context on Ryzen Threadripper: Is this expected?

From: Andriy Gapon <avg_at_FreeBSD.org>
Date: Tue, 10 Apr 2018 08:32:13 +0300
On 09/04/2018 22:37, John Baldwin wrote:
> On Sunday, April 01, 2018 02:23:36 PM Mark Millard wrote:
>> For:
>>
>> # uname -apKU
>> FreeBSD FBSDHUGE 12.0-CURRENT FreeBSD 12.0-CURRENT  r331831M  amd64 amd64 1200060 1200060
>>
>> I get:
>>
>> . . .
>> pci0: <bridge> at device 7.3 (no driver attached)
>> . . .
>> intsmb0: <Intel PIIX4 SMBUS Interface> at device 7.3 on pci0
>> intsmb0: Could not allocate I/O space
>> device_attach: intsmb0 attach returned 6
>>
>> on a Ryzen Threadripper 1950X where FreeBSD is being run under
>> Hyper-V (on a Windows 10 Pro machine).

Note the above.

>> Is this expected? Did I misconfigure something in Hyper-V?
> 
> That seems like an odd device to have for an AMD machine.

Except that this is not an AMD machine but a Hyper-V?
(And even if that were a physical AMD machine the driver would not be odd for it
as the driver supports AMD chipsets that provide SMBus controllers compatible
with PIIX4).

Mark provided the following information in his post:
>> # pciconf -l -v 0:0:7:3
>> none0_at_pci0:0:7:3:       class=0x068000 card=0x00000000 chip=0x71138086 rev=0x02 
>> hdr=0x00
>>     vendor     = 'Intel Corporation'
>>     device     = '82371AB/EB/MB PIIX4 ACPI'
>>     class      = bridge


My guess is that Hyper-V's emulation of PIIX4 is not complete or correct with
respect to the SMBus controller.  And, as I am sure that Hyper-V does not
emulate any SMBus slaves anyway, it would be completely useless.

> I suspect that this has never
> worked and the module started auto-loading due to devmatch.

This must be true.


-- 
Andriy Gapon
Received on Tue Apr 10 2018 - 03:32:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:15 UTC