2.6.37.2_plus_v1: BFS, CFS,THP,compaction, zcache or TOI

[kernelOfTruth]

Update15:

Bump from 2.6.37.2 to 2.6.37.6

patch-2.6.37.2-to-6_plus_v1_CFS_compaction_zcache_no-2.6.38

only for the following patch (with CFS): 2.6.37.2_plus_v1_CFS_compaction_zcache_new.patch

FIXME: does BFQ need an update ?


Update14:

BFQ version bump to v2

now working nicely with NCQ

Speeds up an allmodconfig kernel compile with 5%. Even better

please apply the incremental patch at the address mentioned at BFQ-v2 for 2.6.37

*click* <-- link to directory



Update13:

if you get: "kernel/sched.c error: implicit declaration of function ‘TIMER_DEFERRED_INITIALIZER’" or similar error message
please revert: [tip:sched/core] sched: Untangle cpu-load and timekeeping code

TOI patches for BFS landing

edit:

TOI patches for CFS landing

updated some broken THP patches

Update12:

uploaded - *new*:

* THP (transparent huge pages) patches for CFS & BFS with zcache

to make THP work

* [revert] kswapd changes
* [revert] several patches of ck-patchset

had to be reverted

* includes the "latency problems with memory compaction?" fixes mentioned in Update11


Update11:

updated:

* broken-out (individual) patches "broken-out_2.6.37.2_plus_.7z"

hotfix

apply on top of all 2.6.37.2_plus_v1* patches that contain zcache (currently: ALL)

* 2.6.37.2_plus_v1_zcache_broken_btrfs-fix.patch (5.77 KB)

fix broken zcache: reverting "[PATCH] Allow sharing xvmalloc for zram and zcache"
fix btrfs support [upstream]: btrfs now should work fine with zcache enabled

md5sum:
e5cb9c722bc011c01d2a7f1d90839548 2.6.37.2_plus_v1_zcache_broken_btrfs-fix.patch

latency problems with memory compaction ?

try applying the following 2 patches [not tested yet]:

* [PATCH 1/2] mm: compaction: Minimise the time IRQs are disabled while isolating free pages
* [PATCH 2/2] mm: compaction: Minimise the time IRQs are disabled while isolating pages for migration

Update10:

cumulative update to 2.6.37.2_plus_v1

testing:

* currently only BFS & CFS (with zcache) builds patches available, tarball with broken-out patches, several diff-patches will be available soon
* compile-tested - boot-tested (the one with compaction)
* includes zcache but not TOI
* if there are problems on 32 bit try the one without compaction

bump to 2.6.37.2_plus_v1

reverted (from 2.6.37.1): [PATCH] Change wait_for_completion_*_timeout to return a signed long to make BFS compile


apply the patches on top of 2.6.37.2

**********************************************************************************************************************

Hi guys,

this originally was planned as a long-term stable kernel for me solely which maximal speed (throughput), data integrity (reliability) and interactivity

but as I already had shared liveCDs, kernel-patch(sets) and stuff with the community in the past:

here it is - the latest incarnation of my highly interactive patch(set) !


patch since I won't provide the broken-out patches - only the list of the patches included (will follow later)

**********************************************************************************************************************

DISCLAIMER: I'm in no way responsible for any data loss, data corruption, earthquakes, you having auras of the flying spaghetti monster or outcomes of any other kind

the patch(set) has been created with maximum data safety/integrity, interactivity and productivity in mind


**********************************************************************************************************************


Structure & Organization of the patch-set:

*-* you have the base-patch ("2.6.37.2_plus_v1-base-non_BFS-compaction-CFS-TOI-zcache-btrfs"), including the patches below "base-patch"
*-* which has the following excluded ("optional"):
** BFS
** CFS (from 2.6.38 )
** 2.6.38_stuff
** memory compaction
** TOI (tuxonice)
** zcache
** upstream btrfs changes since 2.6.37
*-* those can be added on top of that "base"

modular design
(cumulative optional patches for your convenience)

base-patch:

2.6.37.2_plus_v1-base-non_BFS-compaction-CFS-TOI-zcache-btrfs_new.patch (3.15 MB)
• 0 custom-flags
• 1 BFQ
• 2 dm-crypt multi-cpu
• 3 fadvise (v6), for rsync
• 4 ck-patchset
• 5 zram (+fixes) + zram & xvmalloc 64K page fixes and optimizations
• 6 incorrect unlikely & likely cleanups
• 7 io-less dirty throttling
• 8 vmscan: protect exectuable page from inactive list scan
• 9 mmu-preemptible (v6)
• 10 jhash 3
• 11 mm: Avoid possible deadlock caused by too_many_isolated()
• 12 fix __set_page_dirty_no_writeback() return value
• 13 some cfq, pm, reiserfs, gcc 4.5 inlining fixes & more
• 14 SFB network scheduler
• 15 squashfs + lzma support
• 16 usb mouse polling
• .
• 18 kswapd
• .
• 21 ext4 fixes
• .
• 23 memmove, cfq, smp, rtmutex fixes; usb-storage support for ums-realtek
• 24 ureadahead, radix_tree fixes
• .
• 26 coordinated flush requests
• 27 delayed tickless during load, ksoftirq fixes, uvesa/vesafb fixes; "remove 8 bytes of padding from block_device on 64bit builds"
• 28 inode data integrity patches [probably needs to be merged manually, when not applying patches in ladder order]
• 29 reiser4
• 30 slqb
• .
• 32 linux-phc
• 33 Improve drain pages performance on large systems; fbcondecor

optional:

• memory compaction, THP (transparent hugepages) [memory compaction and THP are mutually exclusive] or contain each other]
• BFS, CFS [both are mutually exclusive]
• some 2.6.38 fixes & changes
• TOI [zcache and TOI are mutually exclusive]
• latest btrfs fixes & changes

new patches:

apply the patches on top of 2.6.37.2



**********************************************************************************************************************


Instruction/Info:

*) the patches apply cleanly to plain vanilla 2.6.37.2 from kernel.org (e.g. linux-2.6.37.2.tar.bz2)

*) I left out the EXTRAVERSION in Makefile out on purpose - so you can call it how you like

*) Don't get confused: KZTMEM got renamed to ZCACHE (the new zcache equals the old kztmem - and in the future Dan Magenheimer and Nitin Gupta will collaborate on it)


**********************************************************************************************************************


Contents/Parts:

(compaction == memory compaction included) (<-- link for more information)
(no-compaction == no memory compaction; might help to solve hangs, locks or other problems with 32bit)
(thp_V2_pt4 == Transparent huge pages included) (<-- link for more information)


**********************************************************************************************************************
ZCACHE patches
**********************************************************************************************************************

0) Patch-sets:

BFS patchsets (zcache):

* 2.6.37.2_plus_v1_BFS_compaction_zcache_new.patch (3.53 MB)
* 2.6.37.2_plus_v1_BFS_no-compaction_zcache.patch (3.5 MB)
* 2.6.37.2_plus_v1_BFS_thp_V2_pt4_zcache.patch (3.74 MB)

md5sums:
12b8a5e930a8361640f249ff463df22d 2.6.37.2_plus_v1_BFS_compaction_zcache_new.patch
efb62a16edae2b678d54597864c93503 2.6.37.2_plus_v1_BFS_no-compaction_zcache.patch
526babd488ae4ed8ac8b2227317757c5 2.6.37.2_plus_v1_BFS_thp_V2_pt4_zcache.patch


CFS patchsets (zcache) (mainly autogroup & other fixes & improvements [CFS from 2.6.38]):

* 2.6.37.2_plus_v1_CFS_compaction_zcache_new.patch (3.44 MB)
* 2.6.37.2_plus_v1_CFS_no-compaction_zcache_new.patch (3.41 MB)
* 2.6.37.2_plus_v1_CFS_thp_zcache_new.patch (3.7 MB)

md5sums:

a6e8b1c04fbe908706b1a430a37a87b6 2.6.37.2_plus_v1_CFS_compaction_zcache_new.patch
dac12c78906a1291626c7c6be7227774 2.6.37.2_plus_v1_CFS_no-compaction_zcache_new.patch
63528fb3e048a5c34eee166fb99ecaeb 2.6.37.2_plus_v1_CFS_thp_zcache_new.patch


CFS patchsets (zcache) with additional 2.6.38 changes (autogroup, other general 2.6.38 changes [security, hwmon, fpu, rcu, tsc, locking, etc.]):
+ ("20_extra_2.6.37.2_2.6.38-stuff.patch" in broken-out)

* 2.6.37.2_plus_v1_CFS_compaction_zcache-2.6.38-stuff_new.patch (3.65 MB)
* 2.6.37.2_plus_v1_CFS_no-compaction_zcache-2.6.38-stuff_new.patch (3.61 MB)
* 2.6.37.2_plus_v1_CFS_thp_V2_pt4_zcache-2.6.38-stuff.patch (3.86 MB)


md5sums:

2a9898f40626a3abf234c38658951883 2.6.37.2_plus_v1_CFS_compaction_zcache-2.6.38-stuff_new.patch
7086bc70bd952d6586a9aa9fb52930ff 2.6.37.2_plus_v1_CFS_no-compaction_zcache-2.6.38-stuff_new.patch
41e5751ef7530e9d36559e2e955247c9 2.6.37.2_plus_v1_CFS_thp_V2_pt4_zcache-2.6.38-stuff.patch




*hotfix*

apply on top of all 2.6.37.2_plus_v1* patches that contain zcache (currently: ALL)

* 2.6.37.2_plus_v1_zcache_broken_btrfs-fix.patch (5.77 KB)

fix broken zcache: reverting "[PATCH] Allow sharing xvmalloc for zram and zcache"
fix btrfs support [upstream]: btrfs now should work fine with zcache enabled

md5sum:
e5cb9c722bc011c01d2a7f1d90839548 2.6.37.2_plus_v1_zcache_broken_btrfs-fix.patch

**********************************************************************************************************************
TUXONICE patches
**********************************************************************************************************************


BFS patchsets (TOI (tuxonice):

* 2.6.37.2_plus_v1_BFS_compaction_TOI.patch (4 MB)
* 2.6.37.2_plus_v1_BFS_no-compaction_TOI_new.patch (4.06 MB)
* 2.6.37.2_plus_v1_BFS_thp_TOI.patch (4.2 MB)

md5sums:
6bb384eb39523e03b7c1ab37b49f2481 2.6.37.2_plus_v1_BFS_compaction_TOI.patch
f81d670af93f0a2fd99f34b219c325bd 2.6.37.2_plus_v1_BFS_no-compaction_TOI_new.patch
eb27bd621cf8ebd57631f3e10231506c 2.6.37.2_plus_v1_BFS_thp_TOI.patch


CFS patchsets (tuxonice) (mainly autogroup & other fixes & improvements [CFS from 2.6.38]):

* 2.6.37.2_plus_v1_CFS_compaction_TOI_new.patch (4.52 MB)
* 2.6.37.2_plus_v1_CFS_no-compaction_TOI_new.patch (4.41 MB)
* 2.6.37.2_plus_v1_CFS_thp_TOI_new.patch (4.52 MB)

md5sums:

39cbefd311db1af9afe8da0d55d9c602 2.6.37.2_plus_v1_CFS_compaction_TOI_new.patch
fb40f69bc792954807416ad2e04905fd 2.6.37.2_plus_v1_CFS_no-compaction_TOI_new.patch
9ef13b879b152e0398a9e45112d7e416 2.6.37.2_plus_v1_CFS_thp_TOI_new.patch


CFS patchsets (tuxonice) with additional 2.6.38 changes (autogroup, other general 2.6.38 changes [security, hwmon, fpu, rcu, tsc, locking, etc.]):
+ ("20_extra_2.6.37.2_2.6.38-stuff.patch" in broken-out)

* 2.6.37.2_plus_v1_CFS_compaction_TOI_2.6.38-stuff.patch (4.12 MB)
* 2.6.37.2_plus_v1_CFS_no-compaction_TOI_2.6.38-stuff_new.patch (4.18 MB)
* 2.6.37.2_plus_v1_CFS_thp_TOI_2.6.38-stuff.patch (4.32 MB)


md5sums:

b58c31dfb5ad3bff637788a532825256 2.6.37.2_plus_v1_CFS_compaction_TOI_2.6.38-stuff.patch
61f473874dba95af3f6e2c9aec08153f 2.6.37.2_plus_v1_CFS_no-compaction_TOI_2.6.38-stuff_new.patch
ef092245cc6141e9fc527a049f62cefe 2.6.37.2_plus_v1_CFS_thp_TOI_2.6.38-stuff.patch



**********************************************************************************************************************


1) broken-out (individual) patches

(numbers in between - left out - got merged in upstream meanwhile, don't apply or are not worthwhile for 2.6.37)

* broken-out_2.6.37.2_plus_.7z (1.9 MB)

md5sum:

6d1423c6a5adf1537cc07c82d0118bc1 broken-out_2.6.37.2_plus_.7z

some help for usage:

* n.a._broken_queue [folder]:
patches (or patch series) in this directory don't apply cleanly, don't apply to 2.6.37 (are for earlier or newer [>2.6.38] kernels), simply break the kernel or are under consideration

* applied, n.a., old [patches or folders beginning with this]:
they already have been applied by upstream (e.g. applied_2.6.37.1_...), are older revisions (old_ ...), or not applicable

* extra_ ...:
there are in total 2 patch(sets) and folders called that way:
4_ck-patchset -> extra_12_BFS [apply this after you've applied the other ck-patchset patches]

20_2.6.38_patches -> extra_7_CFS
2.6.38's CFS is a part of 2.6.38 changes but, like the changes from 2.6.38 can be applied separately


**********************************************************************************************************************


2) broken-out_sets_2.6.37.2_plus_ (sets of patches) [sets of patches are combined for your convenience & faster patching]

with these you can revert patch(sets) that you don't like or might indicate a problem caused by them:

* broken-out_sets_2.6.37.2_plus_.7z (234.18 KB)

md5sum:
090892e04d0f8d711fb775fe6c04dc3a broken-out_sets_2.6.37.2_plus_.7z

inside the archive:

md5sums
1a80bcc8bc8ad3dd787825a3f475e176 1_2.6.37.1_BFQ.patch
b3c499efe628b5ad32c948316c498b14 3_2.6.37.1_fadvise_v6.patch
b05fe41c053030a5eb8bc56bb93afc59 4_2.6.37.1_ck-patchset_only.patch
2a663a09ab47fafd84a348fb4081a83c 4_extra_2.6.37.2_plus_v1_BFS-sole.patch
31ea58b80fdd034e970d8c604d2fee25 5_2.6.37.1_zram_64K.patch
ce7949e3095761e465c730b35029ad92 6_2.6.37.1_unlikely-likely.patch
1c3abb9a9af127c702158a61d3cc5050 7_2.6.37.1_io-less_dirty-throttling.patch
6dcaf53c490487303afd67e030ddaed7 9_2.6.37.1_mmu-preempt_v6.patch
271dc49b329134f7650f36910b278970 17_2.6.37.2_mem-compaction_pt3.patch
01663344281fd94b902af2c9255b01f1 18_2.6.37.2_kswapd.patch
52d0fb256693792e6e7b53d96b09bdcc 20_2.6.37_CFS_pt3_autogroup-runtime_on-off_pre2.6.37.1-2.patch
b47e0fddb759f27dd15db4d53aa4eebb 20_extra_2.6.37.2_2.6.38-stuff.patch
fdaa4a9aa389e99900063b5f49878408 21_2.6.37.2_ext4_pt5_new.patch
65b37244962fa29af34398d9478fb764 28_2.6.37.2_plus_v1-_inode-integrity.patch




**********************************************************************************************************************

**********************************************************************************************************************

**********************************************************************************************************************




old patches:


**********************************************************************************************************************

Instruction/Info:

*) the patches apply cleanly to plain vanilla 2.6.37 from kernel.org (linux-2.6.37.tar.bz2)

*) I left out the EXTRAVERSION in Makefile out on purpose - so you can call it how you like

*) Don't get confused: KZTMEM got renamed to ZCACHE (the new zcache contains the main part of kztmem - and in the future Dan Magenheimer and Nitin Gupta will collaborate on it)

*) 2.6.37_plus_v15_zcache_coordinate-flush_inode-integrity includes kztmem for this to work you need to enable ZRAM, cleancache, frontswap and - of course - ZCACHE in the kernel-config and append zcache as a boot parameter

*) 2.6.37_plus_v15_coordinate-flush_inode-integrity_TOI obviously does NOT include zcache (not in its name) - it was somewhat hard to get it working with zcache, but tuxonice ("current-tuxonice-for-2.6.37.patch.bz2")


**********************************************************************************************************************

Update9 [for 2.6.37_plus_v16]:

*Hotfix* for zcache:


2.6.37_plus_v16_zcache_linux-next_fixes.patch (2.85 KB) (multiupload.com)

2.6.37_plus_v16_zcache_linux-next_fixes.patch (pastebin.com mirror)

9fc278096e07c8bde4af7ebb5ee823bb 2.6.37_plus_v16_zcache_linux-next_fixes.patch

contents:

* [PATCH] zcache: Fix build error when sysfs is not defined
* static int cleancache_get_key from linux-next
* fix for fs/super.c (will be included in next release of zcache) - kudos & thanks to Dan Magenheimer !





Update8: [bump to 2.6.37_plus_v16]

(re-uploaded & added missing patches to changelog and patch(set))

Everyone's advised to update to v16 !

(as always - this is a cumulative update of all patches from the beginning)

changes (for v15 -> v16):

"25 kztmem" --> "25 zcache"
2 [PATCH] staging: zcache: fix memory leak
3 [PATCH] zcache: Fix build error when sysfs is not defined

27 even more changes ->
13 fs: remove 8 bytes of padding from block_device on 64bit builds
14 (V2) Fix prlimit64 for suid_sgid processes

23 post-2.6.37-fixes -> 4 ext4 -> 12 new_v16
1 [patch] ext4: off by one check in ext4_groupinfo_create_slab()
3 [PATCH] jbd2: call __jbd2_log_start_commit with j_state_lock write locked
4 [PATCH] ext4: allow inode_readahead_blks=0 (linux-2.6.37)

20 2.6.38_patches -> 7 CFS -> 11 v16_sd_idle and first_idle_cpu
1 sched-Resolve-sd_idle-and-first_idle_cpu-Catch-22---v1
2 [PATCH] sched: Wholesale removal of sd_idle logic

20 2.6.38_patches -> 13_timer ->
5 (feb6) [GIT\ PULL\]\ timer\ fixes.txt

20 2.6.38_patches -> 15 x86\ platform ->
8 [PATCH\]\ x86\:\ Fix\ io_bitmap_ptr\ memory\ leak\ on\ copy_process\(\)

32 linux-phc_phc-intel
phc-intel-0.3.2.12.1-2.6.37.patch

"31 btrfs"
-> included latest btrfs changes from 2.6.37 to 2.6.38-rc4 (as of February 15th) (commit: c26a920373a983b52223eed5a13b97404d8b4158 (as of February 15th) in http://git.eu.kernel.org/?p=linux/kerne ... ;a=summary)
1 btrfs-2.6.38-rc4_feb-15th.patch
2 [PATCH] fix (latent?) memory corruption in btrfs_encode_fh()

you can try to use btrfs with zcache but most likely a (yet to be fixed) BUG will be triggered: http://forums.gentoo.org/viewtopic-p-65 ... ml#6571799

upstream has been notified - no solution or patch to fix it has been posted yet

- more efficiency in CFS (cpu scheduler): removed cruft from HT scheduler
- more memory efficiency: fixed memory leaks in zcache, filesystem, and "fs: remove 8 bytes of padding from block_device on 64bit builds"
- latest btrfs from February 15th
- fixes for ext4 & ability to disable inode_readahead_blks (inode_readahead_blks=0)
- linux-phc (undervolting of the CPU to prolong battery runtime on note- and netbooks)

kudos to all devs making this possible !


**********************************************************************************************************************


1) with zcache (no tuxonice)

2.6.37_plus_v16_zcache_coordinate-flush_inode-integrity.7z (765.35 KB)
("highly interactive kernel with TOI and no zcache")

bb656907db085e51d1b98abfd632ec97 2.6.37_plus_v16_zcache_coordinate-flush_inode-integrity.7z

2a84edb7c174591b71ca7125f7136a24 2.6.37_plus_v16_zcache_coordinate-flush_inode-integrity.patch

**********************************************************************************************************************

2) with tuxonice (no zcache)

2.6.37_plus_v16_coordinate-flush_inode-integrity_TOI.7z (859.91 KB)
("highly interactive kernel similar to zen-kernel with TOI and no zcache")

2ae53415d6d46a00716d7f90f8d46f7b 2.6.37_plus_v16_coordinate-flush_inode-integrity_TOI.7z

7862cef0d6f8ca35f825aebf5e572a1e 2.6.37_plus_v16_coordinate-flush_inode-integrity_TOI.patch

**********************************************************************************************************************

**********************************************************************************************************************

**********************************************************************************************************************



Acknowledgement:

*) zen-kernel.org - since this kernel patch includes a few of the modified patches from zen-kernel.org (so they're not directly from upstream)
*) kernel.org Linus Torvalds, and all the other kernel hackers out there
*) Edward Shishkin who keeps on pushing Reiser4 (it should be ready for mainline but needs corporate backing: phoronix.com: An Update On Reiser4 For The Mainline Linux Kernel )


**********************************************************************************************************************


Request:

*) after you've downloaded and tested the patched kernel - please leave a comment about your experience with it

Thanks !


*) If you feel like honoring my work - it seems to be more and more common practice in the opensource community to donate: My Paypal address email address (*click*)
(replace the first . (dot) with the @-sign)

Thanks !



**********************************************************************************************************************

Changelog:


edit:

bumped to v13

edit2:

finished list of included patches

edit3:

bumped to v14
ext4 fixes, no multiple page-io submission won't/shouldn't lead to data-corruption anymore when activated (disabled by default - will be enabled with >2.6.39) - enable via mblk_io_submit mount-option - ENABLE AT YOUR OWN RISK

added reiser4
added slqb (from git.zen-kernel.org repository)
added BFQ (from git.zen-kernel.org repository)


edit4:

bumped the patch(set) to v15

bumped kztmem (V1) to zcache (V2) [rename]

uvesafb, vesafb performance fixes

x86-32: Make sure the stack is set up before we use it

included are all changes since v14

edit5:

bumped to v16

most notable:

* fixed memory leaks (zcache, remove 8 bytes of padding from block_device on 64bit builds, x86: Fix io_bitmap_ptr memory leak on copy_process())
* CFS (cpu scheduler): "sched-Resolve-sd_idle-and-first_idle_cpu-Catch-22---v1" & "Wholesale removal of sd_idle logic"
* btrfs latest for 2.6.38-rc4 february 15th & [PATCH] fix (latent?) memory corruption in btrfs_encode_fh()
* linux-phc (over- and underclocking)
* fixes for ext4 & ability to disable inode_readahead_blks (inode_readahead_blks=0) [this might be really useful where the readahead is affecting performance negatively, e.g. in specific workloads on servers]

edit6:

2.6.37.2_plus_v1

modular design

first patches out: BFS with & without compaction and zcache

reverted (from 2.6.37.1): [PATCH] Change wait_for_completion_*_timeout to return a signed long to make BFS compile

edit7:

more CFS patches with & without compaction and zcache, additional 2.6.38-changes & fixes

edit8:

hotfix for zcache to work & function with btrfs [upstream]

edit9:

THP (transparent huge pages) builds for CFS & BFS for zcache

[one_and_only]

I thought that r4 means reiser4, but I don't see latest Edward's patches in yout patchset...
Could you explain why not BFS?

[kernelOfTruth]

I thought that r4 means reiser4, but I don't see latest Edward's patches in yout patchset...
Could you explain why not BFS?

I made the experience that it simply didn't work that well like compared to the BFS-versions in the past (e.g. 2.6.36 + zen)

I don't know why

maybe I'll give it a try later

keep in mind that I haven't finished the list with the included patches yet - among them the CFS (from 2.6.38 ) with autogroup functionality and other improvements

so IMO BFS isn't really needed anymore

reiser4 caused problems for me in the past since it would lock the kernel and system up during heavy i/o operation (no FUD - just fact) so I'm currently not using reiser4 at all


thanks for your interest

[reed1]

why ?? I'm moving my partition to reiser4 as I type this . Seeing u'r last statement , is reiser4 not recommended for everyday use ? I did not see u/anyone else mention that in other reiser4 thread

[kernelOfTruth]

why ?? I'm moving my partition to reiser4 as I type this . Seeing u'r last statement , is reiser4 not recommended for everyday use ? I did not see u/anyone else mention that in other reiser4 thread

hey - calm down

I didn't say that - it's only for my workflow: I need to sync files pretty often

besides that I'm listening a lot to music and it seemed to get interrupted during heavy syncs quite often (that was with 2.6.36 or 2.6.35)

and reiser4 tends to be a little slow in that regard (e.g. fsync or manually doing a 'sync')


if you still want to use a filesystem which cares about integrity of your data to the max (which was built with data integrity in mind)

I'd still highly recommend reiserfs (v3.6) and reiser4

the only "issue" with them is that they are somewhat slow compared to xfs, ext4 and zfs (if you take the excellent compression, deduplication and checksumming into account)


with all those patches and fixes I included in this kernel I feel that ext4 is stable enough for my purposes - besides that I'm also using xfs and zfs

so it's weighing the pros and cons for the filesystems

[tranquilcool]

CC arch/x86/kernel/asm-offsets.s
In file included from include/linux/suspend.h:8:0,
from arch/x86/kernel/asm-offsets_32.c:11,
from arch/x86/kernel/asm-offsets.c:2:
include/linux/mm.h:515:2: error: #error SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH > BITS_PER_LONG - NR_PAGEFLAGS
make[1]: *** [arch/x86/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2

builds with this;

if SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH <= BITS_PER_LONG - NR_PAGEFLAGS

but then i have these errors;

Kernel: arch/x86/boot/bzImage is ready (#1)
Building modules, stage 2.
MODPOST 169 modules
ln: target `/source' is not a directory
make: *** [_modinst_] Error 1

[kernelOfTruth]

CC arch/x86/kernel/asm-offsets.s
In file included from include/linux/suspend.h:8:0,
from arch/x86/kernel/asm-offsets_32.c:11,
from arch/x86/kernel/asm-offsets.c:2:
include/linux/mm.h:515:2: error: #error SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH > BITS_PER_LONG - NR_PAGEFLAGS
make[1]: *** [arch/x86/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2

builds with this;

if SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH <= BITS_PER_LONG - NR_PAGEFLAGS

but then i have these errors;

Kernel: arch/x86/boot/bzImage is ready (#1)
Building modules, stage 2.
MODPOST 169 modules
ln: target `/source' is not a directory
make: *** [_modinst_] Error 1

please provide more information:

architecture (32bit, 64bit), gcc-version, which kernel (the one with kztmem ?),

kernel-config (e.g. on pastebin.com), hardware,

you have kztmem, zram, ext4 enabled ?

[tranquilcool]

CC arch/x86/kernel/asm-offsets.s
In file included from include/linux/suspend.h:8:0,
from arch/x86/kernel/asm-offsets_32.c:11,
from arch/x86/kernel/asm-offsets.c:2:
include/linux/mm.h:515:2: error: #error SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH > BITS_PER_LONG - NR_PAGEFLAGS
make[1]: *** [arch/x86/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2

builds with this;

if SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH <= BITS_PER_LONG - NR_PAGEFLAGS

but then i have these errors;

Kernel: arch/x86/boot/bzImage is ready (#1)
Building modules, stage 2.
MODPOST 169 modules
ln: target `/source' is not a directory
make: *** [_modinst_] Error 1

please provide more information:

architecture (32bit, 64bit), gcc-version, which kernel (the one with kztmem ?),

kernel-config (e.g. on pastebin.com), hardware,

you have kztmem, zram, ext4 enabled ?

32bit, gcc-4.5.2, kernel with kztmem, ext4.

i think the problem is some patch from the zen-kernel. i have the same mm.h problems
with the zen-kernel and with the correction above, the zen-kernel panics. could it be bfq from zen-git?

[kernelOfTruth]

32bit, gcc-4.5.2, kernel with kztmem, ext4.

i think the problem is some patch from the zen-kernel. i have the same mm.h problems
with the zen-kernel and with the correction above, the zen-kernel panics. could it be bfq from zen-git?

not really, it doesn't even include changes in mm.h

yeah, I remember having seen the same error message in the zen-kernel thread


but let's start with that:

you disabled BFQ in your kernel-config and tried with that ?

(I doubt that'll make a change but why not )


edit:

while looking at the code I remember having made changes to that file in the process of patching the kernel together

currently my mind is too clouded (I also need to do some studying) - hopefully I'll figure out which patch(es) was/were involved ...

edit2:

ok, try reverting the 2 patches in the ureadahead branch (from zen)

1) Add trace events required by ureadahead
then
2) UBUNTU: SAUCE: add tracing for user initiated readahead requests

(that like won't help)

edit3:

try disabling kztmem with all other parts entirely:

kztmem, zram (or what its name is), cleancache, frontswap

[tranquilcool]

32bit, gcc-4.5.2, kernel with kztmem, ext4.

i think the problem is some patch from the zen-kernel. i have the same mm.h problems
with the zen-kernel and with the correction above, the zen-kernel panics. could it be bfq from zen-git?

not really, it doesn't even include changes in mm.h

yeah, I remember having seen the same error message in the zen-kernel thread


but let's start with that:

you disabled BFQ in your kernel-config and tried with that ?

(I doubt that'll make a change but why not )


edit:

while looking at the code I remember having made changes to that file in the process of patching the kernel together

currently my mind is too clouded (I also need to do some studying) - hopefully I'll figure out which patch(es) was/were involved ...

edit2:

ok, try reverting the 2 patches in the ureadahead branch (from zen)

1) Add trace events required by ureadahead
then
2) UBUNTU: SAUCE: add tracing for user initiated readahead requests

(that like won't help)

edit3:

try disabling kztmem with all other parts entirely:

kztmem, zram (or what its name is), cleancache, frontswap

i tried disabling bfq to no avail.
no problem with kztmen, zram, cleancache and frontswap as i have them applied
to pf-kernel and it's working fine.
yes the mm.h code is the same, but with the zen-kernel it doesn't compile.
that's why i have stopped using zen-kernel for now and i guess the problem is
one of their patches.

[kernelOfTruth]

i tried disabling bfq to no avail.
no problem with kztmen, zram, cleancache and frontswap as i have them applied
to pf-kernel and it's working fine.
yes the mm.h code is the same, but with the zen-kernel it doesn't compile.
that's why i have stopped using zen-kernel for now and i guess the problem is
one of their patches.

yeah,

have fun with pf-kernel

might be some 32bit bug or incompatibility of the patches included in zen and my kernel

that's really some serious issue: 32bit and UP (uniprocessor) boxes don't get that much testing anymore in upstream

[kernelOfTruth]

Update:

All users are advised to update to v13 with the integrated "Inode data integrity" patchset by Nick Piggin
I wanted to include them already with the previous version but there were some delays in merging all of those patchsets

also from v12 to v13 - the following got dropped:
- *) 1 BFQ (provided by zen-kernel.org git repository) -
- **) 22 workqueue: relax lockdep annotation on flush_work()

so this practically means that (especially) ext4 (and other filesystems) usage should be several orders of magnitudes more safer


this also applies to the zen-kernel, btw

[wrc1944]

Hmmm. After I figured out I needed p7zip I got 2.6.37 patched without trouble, loaded my normal config file for this system's hardware after noting how the patched kernel had defaulted to (cgroups, etc.), tuned it up, and proceeded with make bzImage. All seemed well (albeit very briefly), until this:

Code: Select all

  VDSOSYM arch/x86/vdso/vdso32-int80-syms.lds
  VDSOSYM arch/x86/vdso/vdso32-sysenter-syms.lds
  VDSOSYM arch/x86/vdso/vdso32-syms.lds
  LD      arch/x86/vdso/built-in.o
  LD      arch/x86/built-in.o
  CC      kernel/sched.o
kernel/sched.c: In function 'yield_to':
kernel/sched.c:5446:2: error: implicit declaration of function 'double_rq_lock'
kernel/sched.c:5448:3: error: implicit declaration of function 'double_rq_unlock'
kernel/sched.c: At top level:
kernel/sched_fair.c:448:29: warning: '__pick_last_entity' defined but not used
make[1]: *** [kernel/sched.o] Error 1
make: *** [kernel] Error 2
wrc@gentoo ~/kern/linux-2.6.37-plusv13 $

Any ideas? I do have the big kernel lock disabled in my normal config in several systems, with no problems- don't know if that might be related. If need be, I can pastebin the config for this kernel. Could I have made a config mistake to cause these errors?

I do have CONFIG_COMPAT_VDSO=y. Could this be the problem?

EDIT: Nope. disabled the VDSO and got exactly the same error.

EDIT 2: More info: lines 5441-5450 of kernel/sched.c:

Code: Select all

	local_irq_save(flags);
	rq = this_rq();

again:
	p_rq = task_rq(p);
	double_rq_lock(rq, p_rq);
	while (task_rq(p) != p_rq) {
		double_rq_unlock(rq, p_rq);
		goto again;
	} 

EDIT 3: from kernel config:

Code: Select all

# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
# CONFIG_INLINE_SPIN_UNLOCK is not set
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
# CONFIG_INLINE_READ_UNLOCK is not set
# CONFIG_INLINE_READ_UNLOCK_BH is not set
# CONFIG_INLINE_READ_UNLOCK_IRQ is not set
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
# CONFIG_INLINE_WRITE_UNLOCK is not set
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
# CONFIG_MUTEX_SPIN_ON_OWNER is not set
CONFIG_FREEZER=y 

Maybe I missed it, but I don't recall seeing any of these CONFIG_INLINE options- guess they are set behind the scenes?

[kernelOfTruth]

Hmmm. After I figured out I needed p7zip I got 2.6.37 patched without trouble, loaded my normal config file for this system's hardware after noting how the patched kernel had defaulted to (cgroups, etc.), tuned it up, and proceeded with make bzImage. All seemed well (albeit very briefly), until this:

Code: Select all

  VDSOSYM arch/x86/vdso/vdso32-int80-syms.lds
  VDSOSYM arch/x86/vdso/vdso32-sysenter-syms.lds
  VDSOSYM arch/x86/vdso/vdso32-syms.lds
  LD      arch/x86/vdso/built-in.o
  LD      arch/x86/built-in.o
  CC      kernel/sched.o
kernel/sched.c: In function 'yield_to':
kernel/sched.c:5446:2: error: implicit declaration of function 'double_rq_lock'
kernel/sched.c:5448:3: error: implicit declaration of function 'double_rq_unlock'
kernel/sched.c: At top level:
kernel/sched_fair.c:448:29: warning: '__pick_last_entity' defined but not used
make[1]: *** [kernel/sched.o] Error 1
make: *** [kernel] Error 2
wrc@gentoo ~/kern/linux-2.6.37-plusv13 $

Any ideas? I do have the big kernel lock disabled in my normal config in several systems, with no problems- don't know if that might be related. If need be, I can pastebin the config for this kernel. Could I have made a config mistake to cause these errors?

I do have CONFIG_COMPAT_VDSO=y. Could this be the problem?

EDIT: Nope. disabled the VDSO and got exactly the same error.

EDIT 2: More info: lines 5441-5450 of kernel/sched.c:

Code: Select all

	local_irq_save(flags);
	rq = this_rq();

again:
	p_rq = task_rq(p);
	double_rq_lock(rq, p_rq);
	while (task_rq(p) != p_rq) {
		double_rq_unlock(rq, p_rq);
		goto again;
	} 

EDIT 3: from kernel config:

Code: Select all

# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
# CONFIG_INLINE_SPIN_UNLOCK is not set
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
# CONFIG_INLINE_READ_UNLOCK is not set
# CONFIG_INLINE_READ_UNLOCK_BH is not set
# CONFIG_INLINE_READ_UNLOCK_IRQ is not set
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
# CONFIG_INLINE_WRITE_UNLOCK is not set
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
# CONFIG_MUTEX_SPIN_ON_OWNER is not set
CONFIG_FREEZER=y 

Maybe I missed it, but I don't recall seeing any of these CONFIG_INLINE options- guess they are set behind the scenes?

Hi wrc1944,

please try to do the following:

Update2:

2.6.37_20_5_directed-yield_v7.patch (13.87 KB) seems to cause trouble so please revert it
patch -p1 -R < 2.6.37_20_5_directed-yield_v7.patch

md5sum:
213852ef6d72d4241a37323b775057c1 2.6.37_20_5_directed-yield_v7.patch

[wrc1944]

I extracted a fresh 2.6.37 tree, patched with patch -p1 < 2.6.37_plus_v13_kztmem_coordinate-flush_inode-integrity.patch (no rejections or even offsets), and then tried to revert with how you instructed, but got this:

Code: Select all

wrc@gentoo ~/kern/linux-2.6.37 $ patch -p1 -R < 2.6.37_20_5_directed-yield_v7.patch
bash: 2.6.37_20_5_directed-yield_v7.patch: No such file or directory
wrc@gentoo ~/kern/linux-2.6.37 $

Where am I going wrong? My md5's were correct.

[kernelOfTruth]

I extracted a fresh 2.6.37 tree, patched with patch -p1 < 2.6.37_plus_v13_kztmem_coordinate-flush_inode-integrity.patch (no rejections or even offsets), and then tried to revert with how you instructed, but got this:

Code: Select all

wrc@gentoo ~/kern/linux-2.6.37 $ patch -p1 -R < 2.6.37_20_5_directed-yield_v7.patch
bash: 2.6.37_20_5_directed-yield_v7.patch: No such file or directory
wrc@gentoo ~/kern/linux-2.6.37 $

Where am I going wrong? My md5's were correct.

if you've placed the patch in the directory one hierarchy above do the following:

patch -p1 -R < ../2.6.37_20_5_directed-yield_v7.patch

[wrc1944]

Thanks- I stupidly forgot to move it into the kernel tree. I'll see if I can make some progress now.

BTW, do I just append the grub kernel line with a plain "kztmem" or is there a different syntax like =kztmem, or sometthing?

[kernelOfTruth]

Thanks- I stupidly forgot to move it into the kernel tree. I'll see if I can make some progress now.

BTW, do I just append the grub kernel line with a plain "kztmem" or is there a different syntax like =kztmem, or sometthing?

nope,

kztmem

should suffice

also select SLUB as the slab allocator

since slub and kztmem work best in conjunction with the "[PATCH 0/6] Shrinking the size of ext4_inode_info" I included for ext4

The following set of patches shrink the size of ext4_inode_info, which
is present in memory for every single ext4 inode in the inode cache.
For example, on one of my machines I currently have 172261 ext4 inodes
in my cache, which represents 161 megabytes of memory. On an x86_64
machine, these patches allow me to shrink the ext4 in-core inode size
from 952 bytes to 872 bytes. This represents a 8.4% decrease. Using
the SLUB allocator, this means we can now fit 18 inodes into an order 4
(16384 bytes) slab, instead of the previous 17 inodes. This results in
an effective decrease of 5.6% of memory consumption by the ext4 inode
cache.

It would be possible to further slim down the ext4_inode_cache by
another 100 bytes or so, by breaking the ext4_inode_info into the
portion of the inode required a file is opened for writing, and
everything else. That would be a fairly disruptive change, though, so
I'll save that for another time.

- Ted

Theodore Ts'o (6):
ext4: replace i_delalloc_reserved_flag with
EXT4_STATE_DELALLOC_RESERVED
ext4: Use ext4_lblk_t instead of sector_t for logical blocks
ext4: Drop ec_type from the ext4_ext_cache structure
ext4: reorder ext4_inode_info structure elements to remove unneeded
padding
ext4: Drop i_state_flags on architectures with 64-bit longs
ext4: Dynamically allocate the jbd2_inode in ext4_inode_info as
necessary

well, seems like I haven't added those to the list of included patches yet - oh well

[wrc1944]

I can't seem to find any zram or ktzmem options in make xconfig. Are they called something else? I see cleancache and frontswap.

As you said: [quote]2.6.37_plus_v13_kztmem_coordinate-flush_inode-integrity includes kztmem for this to work you need to enable ZRAM, cleancache, frontswap and - of course - KZTMEM in the kernel-config and append kztmem as a boot parameter[/code]

So I figure I can't continue until I resolve this in my mind and the kernel. I've looked in xconfig, online, and in kernel docs for over an hour now- I must be missing something simple.

[kernelOfTruth]

I can't seem to find any zram or ktzmem options in make xconfig. Are they called something else? I see cleancache and frontswap.

As you said:

2.6.37_plus_v13_kztmem_coordinate-flush_inode-integrity includes kztmem for this to work you need to enable ZRAM, cleancache, frontswap and - of course - KZTMEM in the kernel-config and append kztmem as a boot parameter

So I figure I can't continue until I resolve this in my mind and the kernel. I've looked in xconfig, online, and in kernel docs for over an hour now- I must be missing something simple.

I dunno,

I just use menuconfig - xconfig and the other kernel config interfaces are too impractical for me

zcat /proc/config.gz | grep CLEANC
CONFIG_CLEANCACHE=y



zcat /proc/config.gz | grep FRONT
CONFIG_FRONTSWAP=y



zcat /proc/config.gz | grep KZT
CONFIG_KZTMEM=y



zcat /proc/config.gz | grep ZRA
CONFIG_ZRAM=y
# CONFIG_ZRAM_DEBUG is not set

edit:

it works fine for me, btw

make xconfig -> edit -> find

search for:
kzt
front
clean
zram

should find each of those

[wrc1944]

Weird.
CONFIG_KZTMEM=y and CONFIG_ZRAM=y aren't in xconfig or in the kernel config file itself, so no wonder I can't find them.
I'll start from scratch again.

Sorry to bother you with such ridiculous stuff- I know you're very busy. My sincerest apologies, and I really appreciate your help.

[tranquilcool]

GEN include/generated/bounds.h
CC arch/x86/kernel/asm-offsets.s
In file included from include/linux/suspend.h:8:0,
from arch/x86/kernel/asm-offsets_32.c:11,
from arch/x86/kernel/asm-offsets.c:2:
include/linux/mm.h:515:2: error: #error SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH > BITS_PER_LONG - NR_PAGEFLAGS
make[1]: *** [arch/x86/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2

am very much interested to know what is happening here and with zen and your
sources.
i have been investigating and no solutions so far.
the code seems to be same but apparently something else is not right.

[kernelOfTruth]

GEN include/generated/bounds.h
CC arch/x86/kernel/asm-offsets.s
In file included from include/linux/suspend.h:8:0,
from arch/x86/kernel/asm-offsets_32.c:11,
from arch/x86/kernel/asm-offsets.c:2:
include/linux/mm.h:515:2: error: #error SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH > BITS_PER_LONG - NR_PAGEFLAGS
make[1]: *** [arch/x86/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2

am very much interested to know what is happening here and with zen and your
sources.
i have been investigating and no solutions so far.
the code seems to be same but apparently something else is not right.

ok,

try disabling NUMA (you most likely don't have a numa box)

if that does not help try to disable PAE,

whether that makes a change

from what I read on the net the memory model also seems to be involved in those kind of things so please post the memory model (flat, sparse you have available for selection)



if I understood correctly it's running out of pageflags


gotta go to sleep now ...

[wrc1944]

Hmmm. I've done a fresh 2.6.37 tree and re-patched several times, used make xconfig -> edit -> find, and also menuconfig (dug down in every submenu), and I swear I simply can't find the zram or ktzmem options listed. All I can figure is I must not be getting a full patch, even though the md5's checked out the same as you posted.

I'm switching over to another Gentoo box and try again....

[wrc1944]

OK- on my other Gentoo ~xf86 box I finally found zram and kztmem under "Staging drivers" down at the last part of xconfig right before firmware drivers and file systems.
Had to disable the "Exclude staging drivers from being built" option (under enabling staging drivers) to see all the other options.

I then did a config for my hardware, enabling the plus v13 options.
After saving/quiting make xconfig, I got this:

Code: Select all

warning: (MMC_TIFM_SD && MMC && EXPERIMENTAL && PCI || MEMSTICK_TIFM_MS && MEMSTICK && EXPERIMENTAL && PCI) selects TIFM_CORE which has unmet direct dependencies (MISC_DEVICES && EXPERIMENTAL && PCI)
#
# configuration written to .config

Then:

Code: Select all

gentoo linux-2.6.37 # make bzImage
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf --silentoldconfig Kconfig
warning: (MMC_TIFM_SD && MMC && EXPERIMENTAL && PCI || MEMSTICK_TIFM_MS && MEMSTICK && EXPERIMENTAL && PCI) selects TIFM_CORE which has unmet direct dependencies (MISC_DEVICES && EXPERIMENTAL && PCI)
#
# configuration written to .config
#
warning: (MMC_TIFM_SD && MMC && EXPERIMENTAL && PCI || MEMSTICK_TIFM_MS && MEMSTICK && EXPERIMENTAL && PCI) selects TIFM_CORE which has unmet direct dependencies (MISC_DEVICES && EXPERIMENTAL && PCI)

SNIPPED-  bzImage seemingly built OK, and I got:

Root device is (8, 3)
Setup is 12700 bytes (padded to 12800 bytes).
System is 1951 kB
CRC 3065e6ad
Kernel: arch/x86/boot/bzImage is ready  (#1)

make modules went OK, but then on make modules_install, I got this:

Code: Select all

gentoo linux-2.6.37 # make modules_install
ln: target `/source' is not a directory
make: *** [_modinst_] Error 1
gentoo linux-2.6.37 # 

So until I figure this out, guess I'm stalled. Time to sleep.

UPDATE: OK- couldn't give it up- tried again. Forget the bzImage warnings- that was a stupid config option I should have disabled (not needed). All went normally in a new tree, so I have gotten a plus-v13 patched kernel compiled with no problems (make modules_install problem vanished, not sure why), and am rebooting.