Announcement

Collapse
No announcement yet.

No free memory for buffer

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • No free memory for buffer

    I'm running BurninTest using a Core i7-12700kf CPU on an ASUS TUF Gaming Z690-Plus WIFI D4 motherboard with 16 GB G. Skill DDR4-3200 RAM. The memory is running at 3300 using the XMP 3200 settings for everything else and passes both the two-hour, four-pass MemTest86 tests and the BurninTest 12-minute RAM tests with no errors. However, when I run the three-minute system BurninTest, everything passes except for one or two 'No free memory for buffer' RAM errors. Nothing else is running when the three-minute test runs, and the test indicates that there are 7 to 11 GB of free physical RAM during the course of the three-minute test. The system has a single 1T Samsung 980 Pro M.2 drive divided into five partitions, with the pagefile in the G: partition, defaulting to system-managed size, and I've been using this setup on this and previous systems since I started running Windows 10 x64 (the current version is 21H2 with all updates). I updated the system to use a system-managed pagefile on the C: drive, too, but still got the error. However, when I set up system-managed pagefiles in each of the five partitions, the 'No free memory for buffer' message went away. That seems to indicate that it's an issue with the pagefile and the way Windows 10 allocates space for it rather than a physical RAM problem.
    Mike

  • #2
    The RAM test when running with 3 minute configuration should only be using about half of the available system RAM, so it shouldn't really be causing the page file to be used. There could be a very severe memory leak somewhere or some other process allocated a large amount of RAM around the same time. Normally any device driver memory leaks that would trigger such an error would take several hours to appear though.

    Potentially BurnInTest is starting too many test threads as the current version doesn't differentiate between P and E cores for 12th gen Intel CPUS, so this may be causing the RAM test to timeout. It doesn't explain why changing the page file settings affects the behavior.

    First you should try limiting the CPU test threads to 20, in the CPU test options there is a "select number of threads" options where you can set it to 10 (currently BurnInTest would try and start up to 24 test threads). If that doesn't seem to change the behavior you could try reducing the amount of tests that are running to try and narrow it down to a particular test or combination of tests, eg try without the 3D test and then the 2D tests as these could be using a fair amount of memory (particularly if you were using an integrated video card however it shouldn't be an issue with this CPU).

    You should enable the trace log in the logging options as well as this could give more of an idea of what happening with the current memory state of the system.

    Comment


    • #3
      Removing either the 2D Graphics Test or 3D Graphics Test eliminated the 'no buffer' errors. Running with both graphics tests but eliminating the sound, disk, or video tests did not eliminate them, so it looks like the two graphics tests are the problem, but only when both are running. This shows what's going on when the error occurs:

      LOG NOTE: 2022-01-02 10:04:15, Disk , Disk free space: 172811MB, disk size: 310955MB
      LOG NOTE: 2022-01-02 10:04:15, Disk , Disk free space: 55228MB, disk size: 60437MB
      LOG NOTE: 2022-01-02 10:04:16, 3D Graphics, 3D DX12 test 1 - Running on NVIDIA GeForce RTX 3080 Ti
      LOG NOTE: 2022-01-02 10:04:17, Memory (RAM), System Memory Total: 16164MB, Available: 12116MB
      LOG NOTE: 2022-01-02 10:04:18, 2D Graphics, GPU , Found OpenCL platform NVIDIA CUDA
      LOG NOTE: 2022-01-02 10:04:18, 2D Graphics, GPU NVIDIA GeForce RTX 3080 Ti, Using Device NVIDIA GeForce RTX 3080 Ti, global memory 12884377600
      LOG NOTE: 2022-01-02 10:04:18, 2D Graphics, GPU NVIDIA GeForce RTX 3080 Ti, Total test memory: 10951720800, using buffer block size: 109517208
      LOG NOTE: 2022-01-02 10:04:42, Sound, Starting MP3 test
      LOG NOTE: 2022-01-02 10:05:11, Sound, Starting Wave test
      LOG NOTE: 2022-01-02 10:05:39, Sound, Starting MP3 test
      LOG NOTE: 2022-01-02 10:05:49, Memory (RAM), System Memory Total: 16164MB, Test RAM allocated 5200MB, Available: 7003MB, Suggested Delta: 3467317248, New Test RAM: 7200MB, Activity count: 364, Operations: 10400
      LOG NOTE: 2022-01-02 10:05:49, Memory (RAM), Mem Total Phys: 16164MB [Available Phys: 7003MB], Page: 23041MB [Available Page: 872MB], Total Virt: 134217727MB [Available Virt: 134212396MB], Memory Load: 56
      LOG NOTE: 2022-01-02 10:05:49, Memory (RAM), Process 0, VirtualAlloc error code: 1455
      LOG NOTE: 2022-01-02 10:05:49, Memory (RAM), Process 0, VirtualAlloc error code: 1455
      LOG NOTE: 2022-01-02 10:05:49, Memory (RAM), Process 0, VirtualAlloc error code: 1455
      LOG NOTE: 2022-01-02 10:05:50, Memory (RAM), Process 0, VirtualAlloc error code: 1455

      Error 1455 repeats a number of times, followed by:

      LOG NOTE: 2022-01-02 10:06:02, Memory (RAM), Process 0, VirtualAlloc error code: 1455
      LOG NOTE: 2022-01-02 10:06:02, Memory (RAM), Process 0, VirtualAlloc error code: 1455
      WARNING: 2022-01-02 10:06:02, RAM, No free memory for buffer
      LOG NOTE: 2022-01-02 10:06:07, Sound, Starting Wave test
      LOG NOTE: 2022-01-02 10:06:35, Sound, Starting MP3 test
      LOG NOTE: 2022-01-02 10:07:03, Sound, Starting Wave test
      LOG NOTE: 2022-01-02 10:07:12, StopTests [S2]
      LOG NOTE: 2022-01-02 10:07:12, CPU, FPU status register(4): 0x0001
      LOG NOTE: 2022-01-02 10:07:12, CPU, FPU Control register (4): 0x8001f
      LOG NOTE: 2022-01-02 10:07:12, CPU, SSE MXCSR Control register (4): 0x1fa0
      LOG NOTE: 2022-01-02 10:07:12, CPU, Stopping test

      If I'm interpreting the trace correctly, there are 7003 MB of RAM available and the Memory Test wants to use 7200 MB, and because there are only 872 MB available on the Pagefile, it can't use that to free up RAM. I thought Windows 10's Pagefile would increase dynamically if more storage was needed, but that probably isn't the real problem if BurninTest should be leaving more RAM available during testing.
      Mike

      Comment


      • #4
        Once the page file is involved everything becomes much much slower and as the page file gets bigger memory allocations can still fail.

        BurInTest tries to keep the amount of amount of RAM allocated for testing below the amount of available so it looks like the amount of free RAM dropped in between it determining what to use and the update to the test or there was some other issue with the calculation of how much to use.

        We'll take a look at the allocation calculation.

        Comment


        • #5
          Thanks. I won't worry about the errors.
          Mike

          Comment

          Working...
          X