piix4_smbus 0000:00:07.3: SMBus base address uninitialized – upgrade BIOS or use force_addr=0xaddr

The message you’re seeing:

is a very common kernel warning that appears during boot on many Linux distributions (Ubuntu, CentOS/RHEL, Arch, openSUSE, etc.). It comes from the i2c-piix4 (or piix4_smbus) driver probing for an SMBus (System Management Bus) controller.

Why This Happens

Virtual machines (e.g., VirtualBox, VMware Workstation/Player, ESXi, Hyper-V, KVM/QEMU, AWS EC2, etc.) emulate a PIIX4 chipset (an old Intel southbridge), but they seldom implement a real SMBus controller in hardware. The Linux kernel tries to initialize it anyway, finds the base I/O address isn’t set (uninitialized), and prints this warning.

• On physical hardware, this could indicate a real BIOS/firmware issue (missing SMBus config), but that’s rare nowadays.
• In a VM, it’s expected behavior because there’s no actual SMBus hardware to configure.

Is It a Problem?

In the vast majority of cases, no, it’s harmless and purely cosmetic. It doesn’t prevent booting, doesn’t affect performance, stability, or functionality (unless you’re specifically using SMBus/I2C devices like certain hardware sensors or temperature monitoring in a VM, which is uncommon).

Many users have seen this for years without issues. Red Hat, VirtualBox forums, VMware communities, and others all classify it as benign in virtual environments.

How to Suppress the Message (Optional)

If the warning annoys you or clutters logs, blacklist the module so it never loads:

1. Create or edit a blacklist file:
3. text
4. sudo nano /etc/modprobe.d/blacklist.conf
5. (or use any text editor)
6. Add this line at the end:
7. text
8. blacklist i2c_piix4
9. Save and exit.
10. Update initramfs (most distros; adjust for the distro if needed):
    • Ubuntu/Debian/Mint: sudo update-initramfs -u
    • Fedora/RHEL/CentOS: sudo dracut -f
    • Arch: sudo mkinitcpio -P
11. Reboot.

After this, the message should disappear. Blacklisting is safe in a VM since you don’t need SMBus there anyway.

Rare Cases Where It Might Matter

• If your VM actually hangs/freezes at this message (doesn’t continue booting), it’s usually not caused by this warning — look for other issues (e.g., disk corruption, bad snapshot in VMware, wrong firmware/UEFI settings, graphics driver problems, or Hyper-V install choices like selecting GUI during setup).
• On very old hypervisors or specific configs, people have fixed boot hangs by forcing an address (e.g., kernel parameter i2c-piix4.force_addr=0x0), but that’s rarely needed today.

If this is inside a VM and boot proceeds normally after the message, just ignore it or blacklist as above. If the system isn’t booting at all, share more details (hypervisor type/version, guest OS/distribution, full boot log or behavior).

The message you’re seeing (piix4_smbus … SMBus base address uninitialized – upgrade BIOS or use force_addr=0xaddr) is almost always harmless in a virtual machine (VirtualBox, VMware, etc.), as there’s no real SMBus hardware. The recommended fix is still to blacklist the module (as I described earlier), which prevents it from loading at all:

If you specifically want to try the force_addr method via GRUB (kernel boot parameter)

The driver (i2c-piix4) supports a module parameter called force_addr (or sometimes written as force_addr=0xaddr in the message). You pass it like this: i2c_piix4.force_addr=0x0 (or try other values like 0xb00, 0xb20, etc., but 0x0 is a common test value that often silences it without side effects in VMs).

Temporary test (one boot only – recommended first)

1. Reboot your system.
2. When the GRUB menu appears (if it doesn’t show automatically, hold Shift during boot on Ubuntu-like distros, or Esc on some others).
3. Highlight your normal boot entry (usually the top one).
4. Press e to edit.
5. Find the line that starts with linux (it will have something like /boot/vmlinuz-… root=UUID=… ro quiet splash).
6. Go to the end of that line (after any existing parameters like quiet splash).
7. Add a space, then: i2c_piix4.force_addr=0x0
8. Example of what the modified line might look like:
9. xbtextlinux /boot/vmlinuz-6.8.0-40-generic root=UUID=abcd-1234 rw quiet splash i2c_piix4.force_addr=0x0
10. Press Ctrl + X (or F10 on some systems) to boot with the change.
11. If the message disappears (or changes behavior) and the system boots normally → great, it works for your setup. If not, try 0xb00 or skip to blacklisting.

Make it permanent (applies to all future boots)

1. Edit the GRUB config file:
2. sudo nano /etc/default/grub(or use vim, gedit, etc.)
3. Find the line:
4. GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"(it might have other options already)
5. Add your parameter at the end, inside the quotes:
6. GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i2c_piix4.force_addr=0x0"→ Final example:
7. GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i2c_piix4.force_addr=0x0"
8. Save and exit (Ctrl+O → Enter → Ctrl+X in nano).
9. Update GRUB:
   • Ubuntu/Debian/Mint/Pop!_OS:
   • sudo update-grub
   • Fedora/RHEL/CentOS/Rocky:
   • sudo grub2-mkconfig -o /boot/grub2/grub.cfg (or /boot/efi/EFI/…/grub.cfg on UEFI systems – check with ls /boot).
   • Arch/Manjaro:
   • sudo grub-mkconfig -o /boot/grub/grub.cfg
10. Reboot:
11. sudo reboot

If the message persists even with force_addr=0x0, or if boot hangs (very rare), revert by removing the parameter and use the blacklist method instead.

Blacklisting is preferred in VMs because forcing an address doesn’t provide any real benefit (no SMBus exists), and blacklisting is cleaner.

The message you’re trying to suppress (e.g., piix4_smbus … SMBus base address uninitialized or similar variants like “Host SMBus controller not enabled”) comes from the i2c_piix4 kernel module in Linux (including Kali, which is Debian-based).

Note on naming:

• There is no module named “i2c_smbus” to blacklist directly — i2c_smbus is a generic helper subsystem/module used by many I2C/SMBus drivers.
• The actual driver probing the (non-existent) hardware in VMs is i2c_piix4 (the PIIX4-compatible SMBus controller driver). Blacklisting i2c_piix4 stops the probe and eliminates the warning. Blacklisting “i2c_smbus” won’t work and may cause issues.

This warning is harmless in virtual machines (Hyper-V, VMware, VirtualBox, etc.) because there’s no real SMBus hardware — it’s purely cosmetic and doesn’t affect performance or functionality.

Recommended Method: Blacklist via modprobe config file (persistent, clean)

1. Open a terminal in Kali (if GUI is working) or use Ctrl+Alt+F3 to get a text console and log in.
2. Create a dedicated blacklist file (best practice):
3. sudo bash -c 'echo "blacklist i2c_piix4" > /etc/modprobe.d/blacklist-i2c_piix4.conf'
   • Or manually edit (if you prefer):
   • sudo nano /etc/modprobe.d/blacklist-i2c_piix4.confAdd this single line:
   • blacklist i2c_piix4Save and exit (Ctrl+O → Enter → Ctrl+X).
4. Rebuild the initramfs so the blacklist applies early during boot (critical step — skipping this is why it often doesn’t work):sudo update-initramfs -u -k all
   • This may take 10–60 seconds.
5. Reboot:sudo reboot

Alternative: Blacklist via GRUB kernel parameter (no initramfs rebuild needed)

If the file method doesn’t stick or you want quick testing:

1. Edit GRUB config:textsudo nano /etc/default/grub
2. Find the line GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash” (or similar).
3. Add the blacklist inside the quotes:textGRUB_CMDLINE_LINUX_DEFAULT="quiet splash modprobe.blacklist=i2c_piix4"
4. Save/exit, then update GRUB:
5. sudo update-grub
6. Reboot:
7. sudo reboot

Verify It’s Working

After reboot:

• Check if module is loaded (should show nothing):
• lsmod | grep i2c_piix4
• Check dmesg for the message:
• dmesg | grep -i piix4 or
• dmesg | grep -i smbus(Should be gone.)

If the warning still appears:

• Confirm the spelling: It’s i2c_piix4 (underscore, no dash in blacklist line).
• Try adding install i2c_piix4 /bin/false in the same config file for extra enforcement:
• blacklist i2c_piix4 install i2c_piix4 /bin/false
• Then rerun sudo update-initramfs -u -k all and reboot.
• If you’re in recovery/initramfs mode (stuck boot), remount root rw first:
• mount -o remount,rw /Then create/edit the file as above.