View Issue Details

IDProjectCategoryView StatusLast Update
0016414CentOS-7kernelpublic2019-10-15 08:23
ReporterZahn Assigned To 
Status newResolutionopen 
Product Version7.7-1908 
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.




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


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.


2019-09-25 05:48

reporter   ~0035207

Look at this upstream issue


2019-09-25 07:22

reporter   ~0035208


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


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.


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

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 ?


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 ?


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


2019-10-09 02:01

reporter   ~0035372

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


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.


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.


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?


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.


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.


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?


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


       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);


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.


2019-10-09 09:31

manager   ~0035383

Also, since this appears to be an upstream bug, someone needs to open a ticket on 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 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.


2019-10-09 09:37

reporter   ~0035384

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


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.


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


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.


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.


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 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.


2019-10-09 14:37

reporter   ~0035397

I submitted a bug:


2019-10-14 14:32

reporter   ~0035460

some research:

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

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) {
                        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

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:

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.


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.


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