I keep getting a full log file 100% can anyone help

this is what comes up in repeat

Nov 14 02:34:27 Abyss kernel: pcieport 0000:00:03.0: AER: Correctable error message received from 0000:02:00.0

Nov 14 02:34:27 Abyss kernel: mpt3sas 0000:02:00.0: PCIe Bus Error: severity=Correctable, type=Physical Layer, (Receiver ID)

Nov 14 02:34:27 Abyss kernel: mpt3sas 0000:02:00.0:   device [1000:0087] error status/mask=00000001/00002000

abyss-diagnostics-20251115-0109.zip

unraid has verbose login set fairy high by default at boot.

these can be ignored these are known log spam with aspm and known power states especially with passing pcie device into vms, dockers etc...

I recommend adding this to your unraid syslinux boot options:
pci=noaer pcie_aspm=off

example:

this doesn't stop the device from reporting or erroring! Just stops the log spamming of it.

pci=noaer disables PCIe Advanced Error Reporting, which stops the system from logging corrected errors, and pcie_aspm=off disables PCIe Active State Power Management, which prevents PCIe devices from entering lower power states to reduce power consumption. Both are often used together as a workaround for bugs or unstable systems where PCIe devices report frequent, but benign, errors that can fill up log files. 

=========================================

pci=noaer

• What it does: Disables PCIe Advanced Error Reporting (AER), a feature that detects and reports errors on the PCIe bus.

• Why it's used: It stops the system from logging benign "corrected" errors, which can flood logs and cause performance issues.

• Side effect: It hides potential errors, so you won't be notified of them in the system logs

pcie_aspm=off

• What it does: Disables PCIe Active State Power Management (ASPM). ASPM is a power-saving feature that puts PCIe links into a lower power state when idle.

• Why it's used: It can fix issues on systems where ASPM causes instability, device errors, or performance problems.

• Side effect: It slightly increases power consumption because PCIe links will not be put into low-power states when idle. 

When to use them

• These parameters are commonly used together to solve the problem of excessive PCIe error messages in the system logs that don't indicate a serious hardware failure.

• They are a workaround, so it's best to first check for updated drivers, firmware, or BIOS/UEFI settings before using these options. 

Thanks I’m going to give this a go .

it strange I’ve starting getting this it’s the same hardware with no system changes for over 3 years apart from updating to latest version of unraid

Hi Community / @bmartino1 Sorry to hijack this thread but I had a relatable question regarding "pcie_aspm=off".

If this is enabled would it still effect a GPU's power state that has been passed through / VFIO bond to a windows VM?

Edited February 4Feb 4 by wacko37

5 hours ago, wacko37 said:

Hi Community / @bmartino1 Sorry to hijack this thread but I had a relatable question regarding "pcie_aspm=off".

If this is enabled would it still effect a GPU's power state that has been passed through / VFIO bond to a windows VM?

Kinda...

When ran at the grub level your telling the kernel at the software level to not use ASPM.

Aspm is and can also be a bios level setting...

ASPM (Active State Power Management) is a PCI-Express power management feature that lets PCIe links enter low-power states when idle (L0s, L1), reducing power draw but potentially adding link latency. It’s mainly used on mobile systems to extend battery life.

(Yes this affects all pcie devices...)

The kernel parm does not enable deeper power states for devices or tell each device to stop entering low-power modes itself — instead, it tells the Linux kernel to leave whatever ASPM configuration the firmware (BIOS/UEFI) already set untouched, and not to try to change or enforce it. This is a nuanced change in recent kernels — older docs sometimes described it as forcing ASPM completely off, but the current behavior is more like “don’t touch ASPM settings.”

It more of hey the host had a setting for the car. Unraid don't touch it the VM bios will mange it latter. So yes it will affect a VMS GPU with vfio.

If bound correctly it would matter as the host no longer sees the card and then more used for log spam and vfio assistance with sriovn and how some pcie devices use power states ...

This is why I uses disable d3 power mode with vfio on proxmox in mod configs to assist with the VM using and deciding when to idle the device...

Because of unraid decides to idle.it when passed to a VM it breaks the VM ability to use and manage the device....

*This is also whenever multifunction and device setting in VM come in to play and why I would chose both to allow the host and VM to manage a device...

Conversely:

pcie_aspm=force attempts to force ASPM enabled even on devices that claim not to support it (which can be unsafe on unsupported hardware).

.

You can also influence policy via pcie_aspm.policy=<default|powersave|performance>, where “performance” minimizes ASPM and “powersave” maximizes it.

It I found trying to set kernel software ASPM to not work very well and it better to turn off sleep idle at host when passing device to a VM as the VM should mange and the os should mange it from there...

Edited February 4Feb 4 by bmartino1

WOW, thankyou kindly for your expert advise and detailed explanation.

I Have an onboard 10gbe NIC (AQtion AQC107) that gives an error a few times a day which is related to ASPM. It doesn't cause any problems so its not a major issue, just annoying.

Feb 4 06:11:43 Wacko-UNRAID kernel: pcieport 0000:00:1c.4: AER: Multiple Correctable error message received from 0000:06:00.0

Feb 4 06:11:43 Wacko-UNRAID kernel: atlantic 0000:06:00.0: PCIe Bus Error: severity=Correctable, type=Physical Layer, (Receiver ID)

Feb 4 06:11:43 Wacko-UNRAID kernel: atlantic 0000:06:00.0:   device [1d6a:d107] error status/mask=00000041/0000a000

Feb 4 06:11:43 Wacko-UNRAID kernel: atlantic 0000:06:00.0:    [ 0] RxErr                  (First)

Feb 4 06:11:43 Wacko-UNRAID kernel: atlantic 0000:06:00.0:    [ 6] BadTLP 

To help clear the logs for easy "error" finding, I was going to add "pcie_aspm=off" But given your above reply, I feel its not worth implementing in my case as I don't really have a major issue apart from a few random error logs.

2 hours ago, wacko37 said:

WOW, thankyou kindly for your expert advise and detailed explanation.

I Have an onboard 10gbe NIC (AQtion AQC107) that gives an error a few times a day which is related to ASPM. It doesn't cause any problems so its not a major issue, just annoying.

Feb 4 06:11:43 Wacko-UNRAID kernel: pcieport 0000:00:1c.4: AER: Multiple Correctable error message received from 0000:06:00.0

Feb 4 06:11:43 Wacko-UNRAID kernel: atlantic 0000:06:00.0: PCIe Bus Error: severity=Correctable, type=Physical Layer, (Receiver ID)

Feb 4 06:11:43 Wacko-UNRAID kernel: atlantic 0000:06:00.0:   device [1d6a:d107] error status/mask=00000041/0000a000

Feb 4 06:11:43 Wacko-UNRAID kernel: atlantic 0000:06:00.0:    [ 0] RxErr                  (First)

Feb 4 06:11:43 Wacko-UNRAID kernel: atlantic 0000:06:00.0:    [ 6] BadTLP 

To help clear the logs for easy "error" finding, I was going to add "pcie_aspm=off" But given your above reply, I feel its not worth implementing in my case as I don't really have a major issue apart from a few random error logs.

That's normal to see and is comon log spam.

based on what you’ve shown, adding pcie_aspm=off is very likely not worth it for this situation.

This is where using ASPM off can stop the spamming in the log.

Community users often add pcie_port_pm=off and pcie_aspm.policy=performance in passthrough builds to avoid devices going into low-power states unexpectedly, which can help prevent NICs or GPUs from disappearing from the bus on idle.

It's trial error and worth a test. But if it's functional then it's not worth messing. We can run and do other things like turnacate a log and side Linux stuff...

Network nic, gpus, and hba will often have vfio notification and error due to the kernel level interactions.

This is where system drives and options like mod probe configs can come in to help ease vfio and stuff like softmod device name vfio.

What those log messages really mean

You’re seeing AER Correctable PCIe Physical Layer errors from the Aquantia AQC107

severity=Correctable

type=Physical Layer

RxErr

BadTLP

Key points:

Correctable means the PCIe link detected an issue, retried, and recovered.

Physical Layer + RxErr / BadTLP almost always means signal integrity noise, not a driver or functional failure.

The device continues to operate normally — no link resets, no device drop, no throughput collapse.

This is extremely common with:

Aquantia / Marvell AQC10x NICs

10GbE PHYs running close to signal margin limits...

Systems where ASPM L1/L1.2 transitions are enabled but not perfectly implemented

In other words: annoying, noisy, but benign.

I would look into turning off WOL having had issues in the past with that...

Otherwise:

Suppress AER reporting (targeted, low risk)

If you really want silence without touching ASPM:

pci=noaer

or (slightly less aggressive):

pcie_ports=native

This stops the kernel from reporting correctable AER events while leaving PCIe power behavior intact.

⚠️ Note: You’ll also hide other correctable PCIe noise, so only do this if you’re confident in your hardware.

Disable ASPM in BIOS only for that slot (if supported)

Some boards allow:

Per-slot ASPM control

Forcing L0s/L1 disabled on specific root ports

That’s far cleaner than a global kernel flag — but many consumer boards don’t expose it.

Edited February 4Feb 4 by bmartino1
Type on phone. Fat thumbs

6 hours ago, bmartino1 said:

That's normal to see and is comon log spam.

based on what you’ve shown, adding pcie_aspm=off is very likely not worth it for this situation.

This is where using ASPM off can stop the spamming in the log.

Community users often add pcie_port_pm=off and pcie_aspm.policy=performance in passthrough builds to avoid devices going into low-power states unexpectedly, which can help prevent NICs or GPUs from disappearing from the bus on idle.

It's trial error and worth a test. But if it's functional then it's not worth messing. We can run and do other things like turnacate a log and side Linux stuff...

Network nic, gpus, and hba will often have vfio notification and error due to the kernel level interactions.

This is where system drives and options like mod probe configs can come in to help ease vfio and stuff like softmod device name vfio.

What those log messages really mean

You’re seeing AER Correctable PCIe Physical Layer errors from the Aquantia AQC107

severity=Correctable

type=Physical Layer

RxErr

BadTLP

Key points:

Correctable means the PCIe link detected an issue, retried, and recovered.

Physical Layer + RxErr / BadTLP almost always means signal integrity noise, not a driver or functional failure.

The device continues to operate normally — no link resets, no device drop, no throughput collapse.

This is extremely common with:

Aquantia / Marvell AQC10x NICs

10GbE PHYs running close to signal margin limits...

Systems where ASPM L1/L1.2 transitions are enabled but not perfectly implemented

In other words: annoying, noisy, but benign.

I would look into turning off WOL having had issues in the past with that...

Otherwise:

Suppress AER reporting (targeted, low risk)

If you really want silence without touching ASPM:

pci=noaer

or (slightly less aggressive):

pcie_ports=native

This stops the kernel from reporting correctable AER events while leaving PCIe power behavior intact.

⚠️ Note: You’ll also hide other correctable PCIe noise, so only do this if you’re confident in your hardware.

Disable ASPM in BIOS only for that slot (if supported)

Some boards allow:

Per-slot ASPM control

Forcing L0s/L1 disabled on specific root ports

That’s far cleaner than a global kernel flag — but many consumer boards don’t expose it.

Mate, I wish i had you as my next door neighbour, youd be sick of me asking you questions....🤪 Just donated you a beer! (Transaction ID: 22C69294F8897324B)

@bmartino1 sorry to bring up this old topic again, but I an idea pop into my head today, to alternately stop this log spamming without added "pcie_aspm=off" or the likes.

Would be possible to stop the NIC from attempting to enter into a ASPM state by creating a scheduled user script to keep the nic active /live?

Just now, wacko37 said:

@bmartino1 sorry to bring up this old topic again, but I an idea pop into my head today, to alternately stop this log spamming without added "pcie_aspm=off" or the likes.

Would be possible to stop the NIC from attempting to enter into a ASPM state by creating a scheduled user script to keep the nic active /live?

yes we ca use whats called a hook script adn target the aspm of a single device. the issues is who / what is in contorl and manging xyz. as we can run a comand to do that but other interactions, service etc can turn it back on...

this is why the global edit and the global option was mentioned

Edited February 27Feb 27 by bmartino1

example as I would need the lspci pcie device number or diag file to help structure the command..

Step 1 — Find the NIC’s PCI Address

Show all Ethernet controllers with PCI slot

lspci -nn | grep -i ethernet

Example output:

03:00.0 Ethernet controller [0200]: Intel Corporation I225-V [8086:15f3]

👉 The PCI address is:

03:00.0

---

If you want to match it to a specific interface (like eth0)

ethtool -i eth0

Look for:

bus-info: 0000:03:00.0

That’s the exact PCI device path.

---

🔎 Step 2 — Confirm ASPM Status for That Device

lspci -vv -s 03:00.0 | grep -i aspm

You’ll see something like:

LnkCtl: ASPM L1 Enabled

---

🛑 Step 3 — Disable ASPM for ONLY That PCI Device

Linux controls ASPM via sysfs per device.

Disable ASPM for that NIC:

echo performance | sudo tee /sys/bus/pci/devices/0000:03:00.0/power/control

OR explicitly disable link power states:

echo 0 | sudo tee /sys/bus/pci/devices/0000:03:00.0/link/l1_aspm
echo 0 | sudo tee /sys/bus/pci/devices/0000:03:00.0/link/l0s_aspm

⚠ If link/l1_aspm does not exist, your kernel may not expose per-link controls (depends on kernel version).

---

Verify It Disabled

lspci -vv -s 03:00.0 | grep -i aspm

You should now see:

ASPM Disabled

---

If You Want It Persistent Across Reboot

Make a user script at boot:

echo 0 | sudo tee /sys/bus/pci/devices/0000:03:00.0/link/l1_aspm
echo 0 | sudo tee /sys/bus/pci/devices/0000:03:00.0/link/l0s_aspm

8 hours ago, bmartino1 said:

example as I would need the lspci pcie device number or diag file to help structure the command..

Step 1 — Find the NIC’s PCI Address

Show all Ethernet controllers with PCI slot

lspci -nn | grep -i ethernet

Example output:

03:00.0 Ethernet controller [0200]: Intel Corporation I225-V [8086:15f3]

👉 The PCI address is:

03:00.0

---

If you want to match it to a specific interface (like eth0)

ethtool -i eth0

Look for:

bus-info: 0000:03:00.0

That’s the exact PCI device path.

---

🔎 Step 2 — Confirm ASPM Status for That Device

lspci -vv -s 03:00.0 | grep -i aspm

You’ll see something like:

LnkCtl: ASPM L1 Enabled

---

🛑 Step 3 — Disable ASPM for ONLY That PCI Device

Linux controls ASPM via sysfs per device.

Disable ASPM for that NIC:

echo performance | sudo tee /sys/bus/pci/devices/0000:03:00.0/power/control

OR explicitly disable link power states:

echo 0 | sudo tee /sys/bus/pci/devices/0000:03:00.0/link/l1_aspm
echo 0 | sudo tee /sys/bus/pci/devices/0000:03:00.0/link/l0s_aspm

⚠ If link/l1_aspm does not exist, your kernel may not expose per-link controls (depends on kernel version).

---

Verify It Disabled

lspci -vv -s 03:00.0 | grep -i aspm

You should now see:

ASPM Disabled

---

If You Want It Persistent Across Reboot

Make a user script at boot:

echo 0 | sudo tee /sys/bus/pci/devices/0000:03:00.0/link/l1_aspm
echo 0 | sudo tee /sys/bus/pci/devices/0000:03:00.0/link/l0s_aspm

WoW, thankyou for this detailed response once again, legend!

This method is much more appealing to me personally... I hope this thread helps others who dont want to global edit.

Im away at work atm but will set this up remotely over the next day or 2.

Just reporting back my resolution to this issue to help any others in a similar situation.

Basically any attempt to prevent / disable ASPM on the specific device failed to prevent the errors from occurring or being reported in the syslogs.

With the help of AI, I tried Masking the specific errors which also failed to have any effect.

Finally solution was to create a syslog filter to prevent only the “correctable” error logs from being reported on the syslogs which are only relative to the device in question, this way all other error will get reported.

As I know the original error being reported have zero effect on the stability of the server itself apart from filling the logs over time with unwanted errors which made filtering out new errors etc more difficult this seems the cleanest most efficient way of doing so.

I created a new syslog filter via userscript for easier management / monitoring. The script runs once after array start, as the filter file that is created does not persist after a reboot.

#!/bin/bash

# Create the file with your specific AER ignore lines
cat <<EOF > /etc/rsyslog.d/02-blocklist-ignore-aqc107-aer-errors.conf
:msg,contains,"pcieport 0000:00:1c.4: AER: Correctable error message received from 0000:06:00.0" stop
:msg,contains,"atlantic 0000:06:00.0: PCIe Bus Error: severity=Correctable" stop
:msg,contains,"atlantic 0000:06:00.0:   device [1d6a:d107] error status/mask=" stop
EOF

# Restart rsyslog to apply the new filter
/etc/rc.d/rc.rsyslogd restart

echo "Blocklist created and rsyslog restarted."

unraid is also verbose formthe start and doen't have a logrotate built in for servers runnign longer then a acouple months ...

a user scirpt on a cron can turncate teh logs as it builds up in ram as well.

example:

#!/bin/bash
# Unraid: save syslog + dmesg every 14 days
# Good for CA User Scripts

OUTDIR="/mnt/user/system_logs"
STAMPFILE="/boot/config/plugins/user.scripts/.dmesg_syslog_last_run"
HOSTNAME="$(hostname)"
NOW_EPOCH="$(date +%s)"
DATE_TAG="$(date +%Y-%m-%d_%H-%M-%S)"

mkdir -p "$OUTDIR"
mkdir -p "$(dirname "$STAMPFILE")"

# 14 days = 1209600 seconds
INTERVAL=1209600

if [[ -f "$STAMPFILE" ]]; then
    LAST_RUN="$(cat "$STAMPFILE" 2>/dev/null)"
else
    LAST_RUN=0
fi

# If not enough time has passed, exit quietly
if [[ $((NOW_EPOCH - LAST_RUN)) -lt $INTERVAL ]]; then
    exit 0
fi

SYSLOG_FILE="${OUTDIR}/${HOSTNAME}_syslog_${DATE_TAG}.log"
DMESG_FILE="${OUTDIR}/${HOSTNAME}_dmesg_${DATE_TAG}.log"

echo "===== SYSLOG ${DATE_TAG} =====" > "$SYSLOG_FILE"
cat /var/log/syslog >> "$SYSLOG_FILE" 2>/dev/null || tail -n 5000 /var/log/syslog >> "$SYSLOG_FILE" 2>/dev/null

echo "===== DMESG ${DATE_TAG} =====" > "$DMESG_FILE"
dmesg -T > "$DMESG_FILE" 2>/dev/null || dmesg > "$DMESG_FILE"

# Optional: gzip old logs larger than a few days old
find "$OUTDIR" -type f -name "*.log" -mtime +3 -exec gzip -f {} \;

# Optional: delete compressed logs older than 180 days
find "$OUTDIR" -type f \( -name "*.gz" -o -name "*.log" \) -mtime +180 -delete

echo "$NOW_EPOCH" > "$STAMPFILE"

In User Scripts:

• Create a new script

• Paste that in

• Set schedule to Custom

• Use this cron:

0 3 * * 0

That means every Sunday at 3:00 AM, and the script itself only performs the save once every 14 days.

so yo can also add a cp line to a disk for long term storage...

somting i usaly look for with sd card arm devices like p is the logrotate and cron schedules on things.