Hi there,

I'm responsible for some of these drivers and can explain what's going
on. I have notes inline on the various issues that you brought up.

On 3/3/24 06:58, Norman via illumos-discuss wrote:
> Hello,
> 
> I've noticed that I've been getting certain warnings in my message log 
> buffer, namely:
> amdzen: [ID 696525 kern.warning] WARNING: amdzen0: failed to online child dip 
> usmn: -1
> amdzen: [ID 696525 kern.warning] WARNING: amdzen0: failed to online child dip 
> zen_udf: -1

These are basically optional drivers that can be installed for
debugging/development purposes (pkg:/driver/developer/amd/zen). Note,
these are not recommended for normal use. I'll try to fix it so it isn't
generating a warning, sorry about that.

> zen_umc: [ID 735894 kern.warning] WARNING: zen_umc-1: encountered invalid 
> channel interleave on rule 0, df/inst 0x0/0x2: 0x8
> zen_umc: [ID 310245 kern.warning] WARNING: zen_umc-1: failed to read DRAM 
> rule 0 on df/inst 0x0/0x2: 22
> amdzen: [ID 696525 kern.warning] WARNING: amdzen0: failed to online child dip 
> zen_umc: -1
> The two consecutive zen_umc warnings also get triggered on other occasions as 
> well (I don't know what's the condition to trigger them), the amdzen 
> warnings, however, do not - they are only at immediate post-boot time. The 
> frequency of warnings is somewhere around 1-5 times per day, I'd say, 
> depending on the workload (at the moment my OmniOS install is only a simple 
> file-server). Sometimes there are multiple days when the warning is not 
> triggered.

I think I can explain this. The first two are only happening when the
parent driver (amdzen) attaches and attempts to online its children.
Once that happens it'll never happen again. However, the bit about
amdzen is causing issues while that driver tries to attach an instance.
There are other activities or commands that can be run on the system
that have a side effect of trying to reattach all known devices, wihch
would cause that to get called again and get logged again.
 i
> I've tested my RAM, it passes 16 cycles on MemTest86+, so I consider it fine 
> for the most part. The CPU in question is AMD EPYC 3151 4C/8T with SMTEN 
> enabled.

None of this is indicative of bad RAM, please don't worry.

> Would be grateful if anyone had insights as to whether I can simply ignore 
> this, or whether there are some tweaks or workarounds around this. Happy to 
> provide more info as needed.

The first case of the failed to online children bit you can ignore and I
will try to stop from coming up. The second case is something we should
dig into and try to fix; however, your system will be working fine while
we try to figure that out.

It looks like this is advertising itself as family 17h, model 01h,
stepping 02. I suspect this system has two dram channels present. Is
that correct? I'll need to spend a bit of time refreshing myself with
this part of the Zen 1 implementation, but will follow up in a bit.

Let me know if you have other questions or how much of the
implementation I should explain.

Robert

------------------------------------------
illumos: illumos-discuss
Permalink: 
https://illumos.topicbox.com/groups/discuss/T3b091ca17f2f86dc-Mc705057dc4941e402fa5da05
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription

Reply via email to