I am finding that any of the 4.4 final releases are really slow compared to 4.4 beta 2. Previously I was getting 25Mb/s copying to my cache drive, now I get about 3mb/s. I have completely redone the flash and tried using my spare, both have fine speed when 4.4 beta 2 is on, and really slow when 4.4.2 is. I have also noticed that the web site itself is quite a bit slower to respond with 4.4.2 and if i start unmenu then that takes about a minute to load each page, whereas it takes a few seconds on 4.4 beta 2. So I am pretty sure something is either hammering the CPU or severely slowing it down with the 4.4.2. Any Ideas?

easiest way to debug is to start unRAID with each version capture and diff the syslogs

 

something will likely jump right out at you

Probably, just painful even booting 4.4.2 at the moment, even booting up takes about 5 mins compared to 30 seconds.

In addition to the 2 syslogs, could you give us some detail on your hardware setup?

OK. I have attached the 2 syslogs, each one is of a boot then 1.2GB file copy to the cache drive. 4.4.2 copied at about 4mb/s and 4.4 beta2 at about 22mb/s.

The hardware setup is:

 

gigabyte ep35-ds3l

Core2Quad Q6600

8GB PC6400 RAM

4x Seagate 7200.11 1.5TB

4x Seagate 7200.9 500GB

1x Seagate 40GB from years ago as cache drive.

 

I've had a look myself but couldn't see much, one thing I have noticed is that the syslog times dont represent what I see watching the monitor on boot.

At the:

Feb 13 22:06:28 media kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk

in the 4.4.2 syslog, it carries straight on after into another line on the same second, when booting it actually hung here for a good 30 seconds. Same with this same line for [sdi]. The whole boot takes at least 3-4 minutes with 4.4.2 but the syslog really doesnt represent that.

 

Any ideas are welcome!

 

And as attachments are full, here is a sendspace link for the logs (sorry dont have any webspace!):

http://www.sendspace.com/file/e9kusp

There do not appear to be any problems or errors reported at all in the v4.4.2 syslog.  Because the drive controllers were picked up in a different order, it was hard to tell, but I don't see anything materially wrong with the drives, in either syslog.  One very minor nit, the Seagate 500GB with serial ending in 3GA probably has its SATA150 jumper still installed (see the Improving unRAID Performance page).

 

I was expecting to see something 'jump right out at' me but did not, at least not drive-related.  What did jump out was a memory related problem right at the start in the v4.4-beta2 syslog, not apparent in the v4.4.2 syslog.  But a closer look at the V4.4.2 syslog show something that looks very wrong to me, something I don't understand.

 

From v4.4-beta2 syslog:

Feb 13 22:15:46 media kernel: WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 512MB of RAM.

Feb 13 22:15:46 media kernel: ------------[ cut here ]------------

Feb 13 22:15:46 media kernel: WARNING: at arch/x86/kernel/cpu/mtrr/main.c:706 mtrr_trim_uncached_memory+0xf5/0x155()

Feb 13 22:15:46 media kernel: Modules linked in:

Feb 13 22:15:46 media kernel: Pid: 0, comm: swapper Not tainted 2.6.26.5-unRAID #9

Feb 13 22:15:46 media kernel:  [<c011b234>] warn_on_slowpath+0x40/0x65

Feb 13 22:15:46 media kernel:  [<c012c354>] up+0x9/0x2a

Feb 13 22:15:46 media kernel:  [<c011b6cb>] release_console_sem+0x16d/0x186

Feb 13 22:15:46 media kernel:  [<c011bb4d>] printk+0x14/0x18

Feb 13 22:15:46 media kernel:  [<c03ff800>] mtrr_trim_uncached_memory+0xf5/0x155

Feb 13 22:15:46 media kernel:  [<c011326c>] pat_init+0x82/0x86

Feb 13 22:15:46 media kernel:  [<c03fd80f>] setup_arch+0x1c4/0x506

Feb 13 22:15:46 media kernel:  [<c03fa5b7>] start_kernel+0x54/0x276

Feb 13 22:15:46 media kernel:  =======================

Feb 13 22:15:46 media kernel: ---[ end trace 4eaa2a86a8e2da22 ]---

Feb 13 22:15:46 media kernel: update e820 for mtrr

Feb 13 22:15:46 media kernel: modified physical RAM map:

...

Feb 13 22:15:46 media kernel: Warning only 4GB will be used.

Feb 13 22:15:46 media kernel: Use a HIGHMEM64G enabled kernel.

Feb 13 22:15:46 media kernel: 3200MB HIGHMEM available.

Feb 13 22:15:46 media kernel: 896MB LOWMEM available.

 

From the v4.4.2 syslog:

Feb 13 22:06:27 media kernel: 7808MB HIGHMEM available.

Feb 13 22:06:27 media kernel: 896MB LOWMEM available.

 

Now, which one looks much more rock solid ... the v4.4.2 one of course.  The v4.4-beta2 one looks like it almost crashed right from the start!  But look at those numbers, and tell me how 7808MB + 896MB adds up to the 8GB you have installed!  At least the beta's 3200MB + 896MB equals 4096MB, which equals 4GB.  Neither syslog gives me much confidence that it is handling the memory correctly, and I suspect there is something really wrong, perhaps with the BIOS, or the motherboard's own support of 8GB.

 

Two suggestions, look for a BIOS update for this motherboard, and/or remove 4GB, just run with 4GB installed, and test again.  You also might want to run a memory test.

 

As to the delays on the monitor, I can't say for sure, but it could be that the thread that actually displays the logged messages on the screen was not keeping up with what was actually happening.  Don't know why.  Nothing related to that is reported in the syslog.

OK, so, removed 4gb of the memory and then it worked fine. So I put the memory back in, upgraded the BIOS and at the same time made sure all other BIOS settings were right. It was picking up the wrong memory timings for a start so I fixed those, I also set all the disks to AHCI. Oh and there were 3 of the disks that had the sata150 jumper still installed so I removed all of those as well... and now I am happy to say I am on 4.4.2 and copying at 22mb/s. Oh, and you may find the following interesting, its still picking up the memory as:

Feb 14 10:52:16 media kernel: 7808MB HIGHMEM available.

Feb 14 10:52:16 media kernel: 896MB LOWMEM available.

 

Make of that what you will, but as its working fine now, I'm happy! Cheers for pointing me in the right direction.

 

Great to hear.

 

I did some research on other syslogs, and did find a few other examples of odd HIGHMEM numbers, often too high by 512MB, but sometimes double that.  These seem to only occur in very recent kernel releases with SMP on, for installed memory sizes of 4GB or 8GB.  A little further down in the syslog will be a highmem number (in lowercase), that is the correct high mem size.

 

Seems regrettable, but I need to research it more, understand it better.  Always more to learn...

 

I could only see the SATA link speed of the one Seagate with a jumper that was using AHCI at the time.  Drives not using AHCI don't show their SATA link speed in the syslog.  It's good you checked for others.