Official thread: "zen-sources" - Part 6

[broch]

I have problem with suspend too:
2.6.29-zen will not wake up from suspend-to-RAM, requires hard reset
2.6.29 vanilla works
nvidia driver 180.37

[Phlogiston]

[charlie]

A week or two ago there were 5-6 power outages at my place whille my computer was working and because of reiser4 I did not lose any data, have corrupt data and did not have to reinstall my OS. Thanks Zen-Sources.

[DigitalCorpus]

Using zen-sources 2.6.29-rc7-zen1 I had my server hard lock on just regular network traffic going about 10 Mbps and I was going on 6 days of uptime without any problems. Thanks to a modern FS, I had to restore from a backup due to fatal corruption on my root partition. I figured the official 2.6.29 release of the zen-sourecs wouldn't cause me any problems given most quirks like this would've been worked out after 1 release candidate and then a final. About 30 minutes after I went to sleep it hard locked again. Even though I was doing video encoding, my sensors showed temps under 45C from my timed out ssh logins.

After two days of being back on reiser4 patched gentoo-sources, even though it's 2.6.28, I'm still running fine with even heavier work on video encoding. I've had 40+ days of uptime with this kernel before . Sorry, but zen-sources are too unstable for my tastes. I much wanted to really test out BFQ against CFQ since I go through a good 80GB a week between HDDs and network traffic due to regular HD TV recording and encoding.
_________________
Atlas (HDTV PVR, HTTP & Media server)
http://mobrienphotography.com/

[rmh3093]

[mroconnor]

i have to agree. Even vanilla can have stability issues w/ less then sane options or experimental file systems. Unfair to blame Zen Sources.

[DigitalCorpus]

I use the same options for by of my kernels and my system configuration hasn't changed. I've had two failures with normal use and the other I haven't had a problem with. Options have been the same on both and I'd be happy to know why my system crash under zen and not under gentoo-sources when I haven't changed anything, sans BFQ instead of CFQ. The problems I have had with reiser4 I'm not blaming on zen because I have had them before under power failures and the like. I'm sorry my post reads that way.

I only moved from zen because of the 2 hard locks that I had within 12 hours under the same usage patterns I'm doing now.

From what I've read this still falls under the bounds of sane for CFLAGS, which I've compiled both kernels with:

[kernelOfTruth]

[cheater1034]

[DigitalCorpus]

[cheater1034]

[rmh3093]

[yngwin]

[Zoboulo]

[kernelOfTruth]

[ponciarello]

[rmh3093]

[CooSee]

[kernelOfTruth]

[rmh3093]

[tranquilcool]

2.6.30-rc2-zen0 rocks hard.

some reiserfs console messages, i think, from upstream;
REISERFS warning (device sda3): jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-13)

no reiser4, i hope, for now.

for nvidia-drivers 173.14.18 here goes a patch(got it somwhere and modified to suit me)

--- usr/src/nv/nv.c 2009-04-04 08:40:50.000000000 -0700
+++ ../NVIDIA-Linux-x86-173.14.18-pkg0/usr/src/nv/nv.c 2009-04-07 10:32:40.000000000 -0700
@@ -588,9 +588,11 @@
* Set the module owner to ensure that the reference
* count reflects accesses to the proc files.
*/
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
proc_nvidia->owner = THIS_MODULE;
proc_nvidia_cards->owner = THIS_MODULE;
proc_nvidia_warnings->owner = THIS_MODULE;
+#endif

for (j = 0; j < num_nv_devices; j++)
{
@@ -610,8 +612,9 @@

entry->data = nv;
entry->read_proc = nv_kern_read_cardinfo;
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
entry->owner = THIS_MODULE;
-
+#endif
if (nvos_find_agp_capability(dev)) {
/*
@@ -624,7 +627,9 @@
goto failed;
}

+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
entry->owner = THIS_MODULE;
+#endif
proc_nvidia_agp = entry;

entry = create_proc_entry("status", flags, proc_nvidia_agp);
@@ -635,7 +640,9 @@

entry->data = nv;
entry->read_proc = nv_kern_read_status;
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
entry->owner = THIS_MODULE;
+#endif

entry = create_proc_entry("host-bridge", flags, proc_nvidia_agp);
if (!entry) {
@@ -645,8 +652,9 @@

entry->data = NULL;
entry->read_proc = nv_kern_read_agpinfo;
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
entry->owner = THIS_MODULE;
-
+#endif
entry = create_proc_entry("card", flags, proc_nvidia_agp);
if (!entry) {
NV_PCI_DEV_PUT(dev);
@@ -655,7 +663,9 @@

entry->data = nv;
entry->read_proc = nv_kern_read_agpinfo;
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
entry->owner = THIS_MODULE;
+#endif
}

NV_PCI_DEV_PUT(dev);
@@ -666,15 +676,17 @@
goto failed;

entry->read_proc = nv_kern_read_version;
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
entry->owner = THIS_MODULE;
-
+#endif
entry = create_proc_entry("registry", flags, proc_nvidia);
if (!entry)
goto failed;

entry->read_proc = nv_kern_read_registry;
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
entry->owner = THIS_MODULE;
-
+#endif
return;

failed:
@@ -700,7 +712,9 @@

entry->data = (void *)message;
entry->read_proc = nv_kern_read_warning;
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
entry->owner = THIS_MODULE;
+#endif /* below 2.6.29 */
#endif
}

after patching edit nv.c lines 631 to 633 by hand 'cos 'am kinda lazy.
edit the file to use any nvidia-drivers version you have because, i think, it works..
_________________
this is a strange strange world.

[rmh3093]

[chrisyu]

Great source, thanks.

Seems one file block/Makefile has some un-needed lines

http://git.zen-sources.org/?p=zen.git;a=blob_plain;f=block/Makefile;hb=HEAD

Have to delete these lines to get make done.

[rahulthewall]

[kernelOfTruth]