Bug 1506064

Okay, so there was a bit of a miscommunication between the mail thread listed on c#1 and this bug. Essentially the patch I made was a python re-write but Its my understanding now that restraint is trying to not introduce new dependencies (eg python). Therefore I'm going to do this patch again using only bash + coreutils.

The other important part of this bug is that we want to whitelist that same "mapping multiple BARs" warning on the x3250m4 boxes, like we already did in rhts. I mean, not just be able to whitelist, but actually do it. :-)

In other words, the actual aim of this bug is to make restraint's dmesg checking functionality match what we have in rhts (including the actual patterns we have got there).

I am now wondering if we should also expand restraint's dmesg checker to read /usr/share/rhts/failurestrings and /usr/share/rhts/falsestrings for compatibility with rhts, as well...

Also, the more we expand the functionality of the dmesg checker, the more it makes me feel like it really needs some test coverage and may deserve to be written in a language other than bash...

Removing Gerrit change 6172 as it is abandoned.

Also I'm just going to flip this bug back to ASSIGNED so we do not forget that the current patch is only halfway there, we need the x3250m4 whitelisting too.

(In reply to Dan Callaghan from comment #3)
> The other important part of this bug is that we want to whitelist that same
> "mapping multiple BARs" warning on the x3250m4 boxes, like we already did in
> rhts. I mean, not just be able to whitelist, but actually do it. :-)
> 
> In other words, the actual aim of this bug is to make restraint's dmesg
> checking functionality match what we have in rhts (including the actual
> patterns we have got there).

This wasn't made clear in the bug. Both the bug description and title elude to the 'capability', not the implementation.

> Also, the more we expand the functionality of the dmesg checker, the more it
> makes me feel like it really needs some test coverage and may deserve to be
> written in a language other than bash...

I think a re-write belongs in another bug. There are ways to test what we have that don't involve a re-write.

(In reply to Dan Callaghan from comment #5)
> Also I'm just going to flip this bug back to ASSIGNED so we do not forget
> that the current patch is only halfway there, we need the x3250m4
> whitelisting too.

I don't think halfway is quite an accurate representation, considering its simply a matter of adding the x3250m4 regex to FALSESTRINGS.

I think when I wrote the bug description I was assuming that Restraint already obeyed the patterns in /usr/share/rhts/falsestrings.

This can now be tested on https://beaker-devel.app.eng.bos.redhat.com/ with Restraint 0.1.35-1.git.9.bb4a7eb

Restraint is still reporting the dmesg warning in this case, when it should be ignoring it.

Note that the kernel was fixed (message severity reduced) at some point. The problem doesn't exist on RHEL7.6. I am using RHEL7.2 to reproduce it (that's where the original issue was reported.)

https://beaker-devel.app.eng.bos.redhat.com/recipes/25216#task163106

There is a Fail result for /01_dmesg_check with this output:

[   10.678425] Installing knfsd (copyright (C) 1996 okir.de).
[   10.685959] SELinux: initialized (dev nfsd, type nfsd), uses genfs_contexts
[   11.073140] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[   11.140321] EDAC MC: Ver: 3.0.0
[   11.146139] resource sanity check: requesting [mem 0xfed10000-0xfed17fff], which spans more than reserved [mem 0xfed10000-0xfed13fff]
[   11.159536] ------------[ cut here ]------------
[   11.164690] WARNING: at arch/x86/mm/ioremap.c:195 __ioremap_caller+0x286/0x370()
[   11.172942] Info: mapping multiple BARs. Your kernel is fine.
[   11.179158] Modules linked in:
[   11.182572]  ie31200_edac(+) edac_core shpchp nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod crc_t10dif sr_mod crct10dif_generic cdrom ata_generic pata_acpi mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm crct10dif_pclmul drm crct10dif_common e1000e ata_piix ptp libata crc32c_intel i2c_core pps_core dm_mirror dm_region_hash dm_log dm_mod
[   11.220095] CPU: 3 PID: 559 Comm: systemd-udevd Not tainted 3.10.0-327.el7.x86_64 #1

Note that it seems to only include a random smattering of lines from the trace, instead of the whole trace as expected. If you look in the complete dmesg output:

https://beaker-devel.app.eng.bos.redhat.com/beaker-logs/2018/08/150/15029/25216/163106/boot.messages

you can see the whole message, including the "Hardware:" line which is what we are supposed to be matching on.

[   11.159536] ------------[ cut here ]------------
[   11.164690] WARNING: at arch/x86/mm/ioremap.c:195 __ioremap_caller+0x286/0x370()
[   11.172942] Info: mapping multiple BARs. Your kernel is fine.
[   11.179158] Modules linked in:
[   11.182572]  ie31200_edac(+) edac_core shpchp nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod crc_t10dif sr_mod crct10dif_generic cdrom ata_generic pata_acpi mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm crct10dif_pclmul drm crct10dif_common e1000e ata_piix ptp libata crc32c_intel i2c_core pps_core dm_mirror dm_region_hash dm_log dm_mod
[   11.220095] CPU: 3 PID: 559 Comm: systemd-udevd Not tainted 3.10.0-327.el7.x86_64 #1
[   11.228733] Hardware name: IBM System x3250 M4 -[2583AC1]-/81Y7073, BIOS -[JQE166FUS-1.08]- 05/26/2014
[   11.239118]  ffff8802301d3a88 000000000e1454a6 ffff8802301d3a40 ffffffff816351f1
[   11.247408]  ffff8802301d3a78 ffffffff8107b200 ffffc90004e50000 ffffc90004e50000
[   11.255697]  00000000fed18000 ffffc90004e50000 0000000000008000 ffff8802301d3ae0
[   11.263989] Call Trace:
[   11.266719]  [<ffffffff816351f1>] dump_stack+0x19/0x1b
[   11.272453]  [<ffffffff8107b200>] warn_slowpath_common+0x70/0xb0
[   11.279153]  [<ffffffff8107b29c>] warn_slowpath_fmt+0x5c/0x80
[   11.285562]  [<ffffffff81086b54>] ? iomem_map_sanity_check+0xc4/0xd0
[   11.292653]  [<ffffffff8105fdd6>] __ioremap_caller+0x286/0x370
[   11.299161]  [<ffffffff8105fed7>] ioremap_nocache+0x17/0x20
[   11.305378]  [<ffffffffa02d8133>] ie31200_init_one+0xf3/0x490 [ie31200_edac]
[   11.313245]  [<ffffffff81327df5>] local_pci_probe+0x45/0xa0
[   11.319461]  [<ffffffff813290e5>] ? pci_match_device+0xe5/0x120
[   11.326065]  [<ffffffff81329259>] pci_device_probe+0xf9/0x150
[   11.332477]  [<ffffffff813f6497>] driver_probe_device+0x87/0x390
[   11.339177]  [<ffffffff813f6873>] __driver_attach+0x93/0xa0
[   11.345395]  [<ffffffff813f67e0>] ? __device_attach+0x40/0x40
[   11.351805]  [<ffffffff813f4203>] bus_for_each_dev+0x73/0xc0
[   11.358117]  [<ffffffff813f5eee>] driver_attach+0x1e/0x20
[   11.364141]  [<ffffffff813f5a40>] bus_add_driver+0x200/0x2d0
[   11.370454]  [<ffffffff813f6ef4>] driver_register+0x64/0xf0
[   11.376670]  [<ffffffff81328d95>] __pci_register_driver+0xa5/0xc0
[   11.383468]  [<ffffffffa003c000>] ? 0xffffffffa003bfff
[   11.389200]  [<ffffffffa003c031>] ie31200_init+0x31/0x1000 [ie31200_edac]
[   11.396773]  [<ffffffff810020e8>] do_one_initcall+0xb8/0x230
[   11.403087]  [<ffffffff810ed4ae>] load_module+0x134e/0x1b50
[   11.409303]  [<ffffffff81316880>] ? ddebug_proc_write+0xf0/0xf0
[   11.415907]  [<ffffffff810e9743>] ? copy_module_from_fd.isra.42+0x53/0x150
[   11.423577]  [<ffffffff810ede66>] SyS_finit_module+0xa6/0xd0
[   11.429892]  [<ffffffff81645909>] system_call_fastpath+0x16/0x1b
[   11.436593] ---[ end trace 6ad2fcc85bf394c3 ]---

(In reply to Dan Callaghan from comment #9)

Sorry, disregard... this test used restraint-0.1.35-2.el7bkr which, in spite of the higher NVR, does *not* actually contain the fix. That is due to a deficiency in tito where its --test git builds do not actually increment the version as they should.

Tried it again but this time using restraint-0.1.35-1.git.13.e94ac53.el7bkr which contains the fix. :-)

The warning appears in dmesg, but the dmesg checker correctly ignores it and you get a nice Pass.

https://beaker-devel.app.eng.bos.redhat.com/recipes/25234#task163153

Restraint 0.1.36 was released on 24 August.