View Issue Details

IDProjectCategoryView StatusLast Update
0016414CentOS-7kernelpublic2019-10-15 08:23
ReporterZahn 
PrioritylowSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version7.7-1908 
Target VersionFixed in Version 
Summary0016414: tmpfs: Bad mount option huge
DescriptionI installed Centos 7.7-1908 and now I get the message: tmpfs: Bad mount option huge
when I reboot the system.

How can I avoid this mesage ?
TagsNo tags attached.
abrt_hash
URL

Activities

Zahn

Zahn

2019-09-23 15:35

reporter   ~0035203

When I issue: dmesg | grep mount I get

[ 0.955947] tmpfs: Bad mount option huge

Where is the source for this message ?
Where are tmpfs filesystems mounted ? - in /etc/fstab is nothing about tmpfs

Any help would be appreciated - Martin Zahn
TrevorH

TrevorH

2019-09-23 15:40

manager   ~0035204

It is followed by

[ 1.176086] [drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-22).

This looks entirely cosmetic to me and I suspect you can just ignore it.
fpaquet

fpaquet

2019-09-25 05:48

reporter   ~0035207

Look at this upstream issue
https://www.linuxquestions.org/questions/linux-newbie-8/tmpfs-mounting-4175658881/
Zahn

Zahn

2019-09-25 07:22

reporter   ~0035208

Hello

Thanks you a lot for the respone. I already spent hour and hours to solve this issue - I habe already
consulted the article (and many more) without success. Ths final question remains:

- Where are tmpfs filesystems mounted, if not in /etc/fstab ?
- The message tmpfs: Bad mount option huge is only for the Kernel 3.x and not for 4.x
fpaquet

fpaquet

2019-09-25 07:36

reporter   ~0035210

Mounts can also be defined via systemd service, but the service is disabled on my notebook.
If you read the linked article, it looks as if the huge page option is compiled into some system components.
Zahn

Zahn

2019-09-25 10:28

reporter   ~0035212

- For a /tmp test I have systemd tmp.mount disabled:

systemctl status tmp.mount
systemctl stop tmp.mount
systemctl disable tmp.mount

- then add an entry in /etc/fstab

tmpfs /tmp tmpfs defaults 0 0
reboot

The message: tmpfs: Bad mount option huge remains.
so I is not the tmp.mount command - it must be something else which uses tmpfs - but what ?
fpaquet

fpaquet

2019-09-25 10:42

reporter   ~0035213

There must be a bug in default mount options for tmpfs.
On my notebook it prevents tmpfs from being loaded.

Maybe you could use ramfs in place of tmpfs ?
https://www.thegeekstuff.com/2008/11/overview-of-ramfs-and-tmpfs-on-linux/
Zahn

Zahn

2019-09-27 12:04

reporter   ~0035253

So far I found no solution to avoid the boot message: tmpfs: Bad mount option huge in Centos 7.7
jianyayu

jianyayu

2019-10-09 02:01

reporter   ~0035372

I have the same issue, downgrade to Centos 7.6 to fix it.
jianyayu

jianyayu

2019-10-09 02:04

reporter   ~0035373

I believe this is kernel bug, you can try to downgrade to 3.10.0-957 to fix it.
Zahn

Zahn

2019-10-09 07:34

reporter   ~0035376

Downgrading to Centos 7.6 is NOT a solution for me, even dowgrading to Kernel 3.10.0-957 is NOT a solution for me.
TrevorH

TrevorH

2019-10-09 08:12

manager   ~0035377

I don't even think this is a bug. It's something trying to use hugepages without checking if they are enabled and in use on the machine and when they are not, it carries on as it did before. Can someone point out to me what effects this has other than a stupid cosmetic message in the logs?
fpaquet

fpaquet

2019-10-09 08:43

reporter   ~0035378

The effect is, that tempfs mount is aborted and not mouted.
You will end up in /tmp on real filesystem which causes performance degradation.
TrevorH

TrevorH

2019-10-09 09:05

manager   ~0035379

Not here it doesn't. This is not about tmp.mount, it's issued by the kernel way before it gets to anything systemd related.
TrevorH

TrevorH

2019-10-09 09:13

manager   ~0035380

I just checked over 80 CentOS 7.7 systems and the only ones (2 of them) giving this error have Intel graphics cards. Is this true for everyone experiencing this message?
TrevorH

TrevorH

2019-10-09 09:23

manager   ~0035381

Confirmed, this message is in the i915 kernel module and has nothing at all to do with /tmp

i915/i915_gem.c

       err = i915_gemfs_init(dev_priv);
        if (err)
                DRM_NOTE("Unable to create a private tmpfs mount, hugepage support will be disabled(%d).\n", err);
TrevorH

TrevorH

2019-10-09 09:29

manager   ~0035382

Bug component changed to "kernel", severity lowered from High to Low as this is entirely cosmetic and affects nothing.
TrevorH

TrevorH

2019-10-09 09:31

manager   ~0035383

Also, since this appears to be an upstream bug, someone needs to open a ticket on bugzilla.redhat.com to report this and to stand a chance of either getting it fixed or an explanation of how to avoid it if it's not a bug.

CentOS is a rebuild of the sources used to create RHEL. We do not modify anything except to remove branding and logos. You will need to submit your report to Redhat via bugzilla.redhat.com and if/when RH accepts it and incorporates it into RHEL and releases a patched version, then CentOS will pick it up and rebuild it.
fpaquet

fpaquet

2019-10-09 09:37

reporter   ~0035384

Graphics card has no influence. We can see the message here with Intel and Nvidia graphics.
TrevorH

TrevorH

2019-10-09 09:41

manager   ~0035385

No, really, it does. The message is in i915.c which is entirely and utterly dedicated to Intel graphics cards. It does not exist anywhere else in the kernel source - I looked.
fpaquet

fpaquet

2019-10-09 12:02

reporter   ~0035389

OK, our Core i7-2600 systems have built-in IntelĀ® HD-Grafik 2000

dmesg reports
[ 1.392945] tmpfs: Bad mount option huge
[ 1.397577] [drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-22).
[ 1.397643] [drm] Replacing VGA console driver
TrevorH

TrevorH

2019-10-09 12:05

manager   ~0035390

Yes, and all Intel graphics chips use the i915 driver.

If your /tmp is not being mounted then this has nothing to do with this bug. This bug is entirely in the i915 Intel graphics driver and has no effect on /tmp or anything else that uses tmpfs.
Zahn

Zahn

2019-10-09 12:48

reporter   ~0035391

However with Centos 7.6 (Kernel 3.10.0-957) no problems with tmpfs: Bad mount option huge. I have done a new installation to Centos 7.7 and now I get tmpfs: Bad mount option huge. I can mount the /tmp filesystem with tmpfs. So it must be an issue with the new kernel on Centos 7.7. I have no account @ Redhat and so I cannot issue the bug report.
TrevorH

TrevorH

2019-10-09 13:16

manager   ~0035393

Yes, this is a new bug in 7.7 so you don't see it on 7.6. However, the real question is "Does it affect anything?" and so far the answer is "no, this affects nothing". I would suggest that you report it on bugzilla.redhat.com as this is a bug inherited from RHEL 7.7 and thus needs to be fixed there.

It's still a trivial cosmetic bug that affects nothing.
Zahn

Zahn

2019-10-09 14:37

reporter   ~0035397

I submitted a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1759980
BugMeNot

BugMeNot

2019-10-14 14:32

reporter   ~0035460

some research:

the following code uses "huge=never" tmpfs mount option:

[drivers/gpu/drm/i915/i915_gemfs.c]
int i915_gemfs_init(struct drm_i915_private *i915)
{ ...
        if (has_transparent_hugepage()) {
                struct super_block *sb = gemfs->mnt_sb;
                /* FIXME: Disabled until we get W/A for read BW issue. */
                char options[] = "huge=never";
                int flags = 0;
                int err;

                err = sb->s_op->remount_fs(sb, &flags, options);
                if (err) {
                        kern_unmount(gemfs);
                        return err;
                }
        }

this code was brought into RHEL7 by the commit d4094528f348 ("[gpu] drm: backport from v5.0").

the error is due to the fact that tmpfs does not have the "huge" mount option in RHEL7:

$ grep 'strcmp(this_char' mm/shmem.c
        if (!strcmp(this_char,"size")) {
        } else if (!strcmp(this_char,"nr_blocks")) {
        } else if (!strcmp(this_char,"nr_inodes")) {
        } else if (!strcmp(this_char,"mode")) {
        } else if (!strcmp(this_char,"uid")) {
        } else if (!strcmp(this_char,"gid")) {
        } else if (!strcmp(this_char,"mpol")) {


compare with the upstream:

[man 5 tmpfs]
       huge=huge_option (since Linux 4.7.0)
              Set the huge table memory allocation policy for all files in
              this instance (if CONFIG_TRANSPARENT_HUGE_PAGECACHE is
              enabled).

the option is present for test mount indeed:

# mount -t tmpfs -o huge=always testfs ~/tmpfstest
testfs on /home/test/tmpfstest type tmpfs (rw,relatime,huge=always)

obviously, it is also present in the tmpfs code:

[mm/shmem.c]
static const struct fs_parameter_spec shmem_param_specs[] = {
        fsparam_u32 ("gid", Opt_gid),
        fsparam_enum ("huge", Opt_huge),
        fsparam_u32oct("mode", Opt_mode),
        fsparam_string("mpol", Opt_mpol),
        fsparam_string("nr_blocks", Opt_nr_blocks),
        fsparam_string("nr_inodes", Opt_nr_inodes),
        fsparam_string("size", Opt_size),
        fsparam_u32 ("uid", Opt_uid),
        {}
};

this code was brought into the upstream by the commits b901bb89324a ("drm/i915/gemfs: enable THP") and fd50fbb6bfde ("drm/i915: Disable THP until we have a GPU read BW W/A").

nevertheless, the upstream has dropped "huge" mount option since v5.4-rc1 by the commit 72e67f046374 ("drm/i915: Stop reconfiguring our shmemfs mountpoint"). the best option for the RHEL7 would be just to backport this commit, i believe.
TrevorH

TrevorH

2019-10-14 14:40

manager   ~0035461

Thanks for that research. If you didn't add it to the upstream issue already then you (or someone with write access to the RH ticket) should do so.
BugMeNot

BugMeNot

2019-10-15 08:23

reporter   ~0035479

yes, i will handle bringing this patch into the next RHEL7 kernel (RHEL-7.8, i guess).

Issue History

Date Modified Username Field Change
2019-09-19 01:00 Zahn New Issue
2019-09-23 15:35 Zahn Note Added: 0035203
2019-09-23 15:40 TrevorH Note Added: 0035204
2019-09-25 05:48 fpaquet Note Added: 0035207
2019-09-25 07:22 Zahn Note Added: 0035208
2019-09-25 07:36 fpaquet Note Added: 0035210
2019-09-25 10:28 Zahn Note Added: 0035212
2019-09-25 10:42 fpaquet Note Added: 0035213
2019-09-27 12:04 Zahn Note Added: 0035253
2019-10-09 02:01 jianyayu Note Added: 0035372
2019-10-09 02:04 jianyayu Note Added: 0035373
2019-10-09 07:34 Zahn Note Added: 0035376
2019-10-09 08:12 TrevorH Note Added: 0035377
2019-10-09 08:43 fpaquet Note Added: 0035378
2019-10-09 09:05 TrevorH Note Added: 0035379
2019-10-09 09:13 TrevorH Note Added: 0035380
2019-10-09 09:23 TrevorH Note Added: 0035381
2019-10-09 09:28 TrevorH Priority high => low
2019-10-09 09:28 TrevorH Category startup-notification => kernel
2019-10-09 09:29 TrevorH Note Added: 0035382
2019-10-09 09:31 TrevorH Note Added: 0035383
2019-10-09 09:37 fpaquet Note Added: 0035384
2019-10-09 09:41 TrevorH Note Added: 0035385
2019-10-09 12:02 fpaquet Note Added: 0035389
2019-10-09 12:05 TrevorH Note Added: 0035390
2019-10-09 12:48 Zahn Note Added: 0035391
2019-10-09 13:16 TrevorH Note Added: 0035393
2019-10-09 14:37 Zahn Note Added: 0035397
2019-10-14 14:32 BugMeNot Note Added: 0035460
2019-10-14 14:40 TrevorH Note Added: 0035461
2019-10-15 08:23 BugMeNot Note Added: 0035479