# warning: don't use mm-sources on non-testing systems

## iBormuth

I know several people using the mm-sources kernel tree on daily use systems (I also used to).

Just to point it out again: The mm-patchset replaced the odd numbered experimental tree (2.7) and thus cannot be expected to be reliable.

The current  tree (mm-sources-2.6.9_rc1-r1) has a bug which can lead to massive data loss via truncated files.

I used it on a rock solid box with ext3 filesystem. After a while the system was nealy unusable. Booting an older kernel fixed the issue.

Other similar cases have been reported in the forum.

----------

## codergeek42

Hm...I just finished compiling and rebooting into 2.6.9-rc1-mm1.Are you sure it wasn't a hardware bug or ACPI or something like that?

----------

## zerojay

 *codergeek42 wrote:*   

> Hm...I just finished compiling and rebooting into 2.6.9-rc1-mm1.Are you sure it wasn't a hardware bug or ACPI or something like that?

 

Yep, pretty sure. I'm suffering from this bug at the moment.

----------

## speeding

arrrrgh!!!     :Shocked:   :Shocked:   :Shocked: 

Thank you!

Thank you!

Thank you!

I just spent the better part of the day tring to figure out why 'tar' was producing truncated files

.... 

Never thought it could be the kernel.

Thank you again for mentioning it.

----------

## zerojay

Sure was a confusing little bastard. I was sitting here wondering what I should do about it all.

----------

## codergeek42

Ok. The bug bit me too...I went to re-compile my kernel (forgot to add support for my NIC) and it said it could not recognize some of the source files because they were truncated...oops.

/me is back in his safe little 2.6.8-rc2-love3 kernel, compiling the vanilla 2.6.9-rc1 kernel

----------

## markfl

Will:

http://www.mafteah.co.il/mafteah-sources/2.6.9-rc1/2.6.9-rc1-Mafteah2/broken-out/2.6.9-rc1-mm1-fix.patch

Fix the filesystem corruption?

I think there's going to be a new mm soon anyway.

----------

## bulletman

Thanks for pointing this out -- I couldn't find out what was going on.

Are the earlier versions of mm-sources the only safe kernels with reiser4 so far?

Stephen

----------

## Master One

I started with mm-sources for my daily used workstation, because they were they first having the fixes for my nforce2 board, and also I tried a lot of other sources, I always returned to mm-sources.

I don't think it's worth a general warning, only because something breaks from time to time, especially as there are always fixes comming up fast.

I really like these sources, and as I doubt I'll find something better, I simply stick with it   :Smile: 

BTW Mafteah's patch fixed it.

----------

## iBormuth

 *Quote:*   

> I don't think it's worth a general warning, only because something breaks from time to time, especially as there are always fixes comming up fast. 

 

I would never want to stop people from using the mm-tree. Testing new technology on a broad basis is much to important. But you should know what you are dealing with. My impression was that many people think of mm as a pretty stable pathset to the 2.6 tree, but as the described case showes mm introduces insufficiently tested code that can harm your data event if you not explicit use new features (e. g. reiserfs4 which seems pretty stable). 

The Changelog of 2.6.8.1-mm4 says everything:

 *Quote:*   

> This kernel has an x86 patch which alters the copy_*_user() functions so they will return -EFAULT on a fault rather than the number of bytes which remain to be copied.  This is a bit of an experiment, because this seems to be the preferred API for those functions.   It's a see-what-breaks thing.
> 
> And things will break. If weird behaviour is observed, please revert usercopy-return-EFAULT.patch and send a report.
> 
> taken from: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8.1/2.6.8.1-mm4/announce.txt

 

To conclude: I use gentoo-sources (2.4) on my production server, gentoo-dev-sources (2.6) on my daily use notebook and mm-sources on my testing box.

----------

## Rainmaker

other question: do the nvidia drivers compile cleanly to this new mm kernel?

----------

## iBormuth

Talking about the 2.6 development model:

Poll: http://kerneltrap.org/node/view/3516

Story: http://kerneltrap.org/node/view/3522

----------

## Master One

Ok, I have to admit, my statement was a little to early, as just after writing my posting, my box froze and I had to perform a hardreset. There are definitely some bugs in mm-sources-2.6.9_rc1-r1, I wasn't aware of.

So for the moment I made a backstep to development-sources-2.6.9-rc1, which work just fine.

For the future, I'll keep both (mm-sources & development-sources) on my workstation, so that I can revert to something stable if necessary.

----------

## codergeek42

 *Rainmaker wrote:*   

> other question: do the nvidia drivers compile cleanly to this new mm kernel?

 When I tried 2.6.9-rc1-mm1 wih the 6111-r4  kernel module, it didn't compile. Works fine though in the vanilla 2.6.9-rc1 (what I'm using right now).

----------

## plate

This thread has prevented major data corruption on my desktop, thanks a lot! I've had "truncated file" errors during a Perl upgrade just now, wondering what on earth was going on, especially since the same upgrade to Perl 5.8.5 compiled flawlessly on another desktop standing right next to it - the only difference being a 2.4.27 kernel on that one... Phew.  :Razz:  I've just rebooted to the 2.6.8.1-mm4 kernel I was running before 2.6.9-rc1-mm1, and it looks like it's cured the hickup. 

Maybe the corruption had to do with my earlier assaults on this particular machine: This afternoon I copied 700 MB worth of email (in > 50.000 individual files) from an NFS share to a local directory, and ran a bash script over the whole shebang to convert it from MH to maildir format...   :Rolling Eyes: 

----------

## Regor

Hmm, shame. It's the smoothest kernel for desktop use I've tried in a while.  :Sad: 

I haven't had any problems, but I don't want to risk it. Guess it's back to 2.6.8-rc2-love3.

----------

## Rainmaker

mm2 is out. Should be fixed now

----------

## iBormuth

'

Just to close the thread, here is the official comment:

 *Quote:*   

> Nothing particularly noteworthy here.  Some seriously bad scheduler performance with SMT and HT was fixed up, as was the fails-to-read-the-last-4k-of-a-file brown bag.
> 
> From: http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc1/2.6.9-rc1-mm2/announce.txt

 

Cheers

.

----------

## codergeek42

Coolness. I'll try it out when I get home later.

Is renaming the -mm1 ebuild sufficient or is there another ebuild somewhere that I should use?

----------

## tormen

Thnx a lot for this incredible important information!!!

Without it I could have destroyed all my system with the time...    :Sad: 

But YOU are my HERO   :Razz: 

----------

## routerguy

I am having a few problems with mm2.

cdparanoia can't access the CD-ROM drive like my other kernels can

the nvidia kernel module refuses to load even though I have my /usr/src/linux symlink correctly set up and have done emerge nvidia-kernel and opengl-update nvidia many times.  What else would the problem be?

----------

## Tronil

 *Mystic0 wrote:*   

> I am having a few problems with mm2.
> 
> cdparanoia can't access the CD-ROM drive like my other kernels can
> 
> the nvidia kernel module refuses to load even though I have my /usr/src/linux symlink correctly set up and have done emerge nvidia-kernel and opengl-update nvidia many times.  What else would the problem be?
> ...

 

Regarding the nvidia module see this thread: https://forums.gentoo.org/viewtopic.php?t=216985

----------

## DJ_Rubbie

Not sure if this completely relates, but using this particular mm kernel caused this error message to show up during reiserfsck (on ReiserFS v3).

Bread: End of file. Cannot read the block (8705213).

Then it complained that it can't fix it up, and asked for the root password for system maintanence... 

Boot into gentoo-sources 2.6.7 had no problems, nor did love-sources 2.6.8.1. Not sure if this is related, but it sounds like it saw end of file prematurely, as if it was truncated. Good thing it didn't mount, who knows what it would have done to my /usr partition...

----------

