on boot I saw plenty of rubbish like:

|ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
|pci_root PNP0A03:00: Force enabled HPET at 0x%lx
|host bridge window [io  0x0000-0x0cf7] (ignored)
|pci_root PNP0A03:00: Force enabled HPET at 0x%lx
|host bridge window [io  0x0d00-0xffff] (ignored)
|pci_root PNP0A03:00: Force enabled HPET at 0x%lx
|ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10
|virtio-pci 0000:00:05.0: Force enabled HPET at 0x%lx

First I wonder myself why the kernel Force enables more than one HPET
and why the address isn't printed. Then I wasn't sure why virtio-pci
does the same thing.
As it turns out commit af7f2158fdee ("drivers-core: make structured
logging play nice with dynamic-debug") has probably an off by one error.
Since commit 314ba3520 ("printk: add kern_levels.h to make KERN_<LEVEL>
available for asm use") the whole shrunk by one byte. And for some
reason the compiler put the HPET string just after one of the kernel log
levels so level[3] was always true.

This should make the rubish go away, I am not sure if the dynamic debug
is still working. Jim could you please try?

Cc: Jim Cromie <[email protected]>
Cc: Jason Baron <[email protected]>
Cc: stable <[email protected]>
Cc: Kay Sievers <[email protected]>
Cc: Joe Perches <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
---
 drivers/base/core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index cdd01c5..5a864c3 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1912,7 +1912,7 @@ int __dev_printk(const char *level, const struct device 
*dev,
                                    "DEVICE=+%s:%s", subsys, dev_name(dev));
        }
 skip:
-       if (level[3])
+       if (level[sizeof(KERN_ERR) - 1])
                level_extra = &level[3]; /* skip past "<L>" */
 
        return printk_emit(0, level[1] - '0',
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to