According to the release notes this kernel is supposed to have the patch which fixes the nmap issue. I've been testing some various things to see if that same issue is related to the problems I've been having with, well azureus in particularl. They both heavily use the same kernel methods I would assume.

Well I've tested the nmap crash with this kernel and it still dies, at least with a preemptable kernel. 2.6.10-mm2 doesn't(which is what I'm currently testing) so the problem has been fixed, but 2.6.10 has the no binary drivers BS in it.

Could someone who knows more about deep kernel magic check this out for me. The patch doesn't seem to be working or else for some reason it's not installing.

Yes, something like this, except I don't use ReiserFS 4 (I do have a couple of ReiserFS 3 partitions). And while SSH does not work, the num lock key and LED do work, which is kind of odd. Generally if there's a full on kernel panic that breaks SSH, the num lock light does not work either.

It seems to happen while the system is multitasking under heavy load.

Well, after switching my Reiser4 partitions to ext3 and trying for a few days with no Reiser4 compiled in or as module, I am noticing improvement. My box appears to actually run faster overall, something I didn't anticipate. OpenOffice (always has been on a ext3 partition) loads considerably faster and I haven't yet had a runaway process forcing a hard reboot. (btw, my advice is to enable the magic key debugging, I intend on using that to more gently reboot my system in the future, that is something that could use a place in the docs IMHO)

You have a very odd situation... however, are you sure that SSH is actually not working or is timing out? With 2 of my boxes (one has never had reiser4) that display this problem, I really can't do anything once those processes hit 99.9. All remote and local login attempts fail, however if I am still in the box remote or local then I can do whatever I want. Granted if it is anything but type echo "this is not cool" then it does not respond. If I run a ps aux (or just about anything else) it freezes attempting I assume to run that process through the gauntlet of 99.9 % CPU utilization procs. Only because I have tested runing a grep -iR at /usr/src/linux but with a very high nice level and I could later run ps if the grep I ran was the offending process.

And any attempt to kill it (<CTRL><D> or <CTRL><Z>) does nothing. If I am in another session and I kill or kill -9 that process it does nothing. When the opportunity has been available I noticed that the process where always R. I have yet to see a S, Z or D.

I just have a quick question about the alsa snapshot - is it stable, anything new in there and where can I get more info about it?
I just wanna know if the kernel upgrade I just made to nitro2 is the reason why my sound went kaput.

According to the release notes this kernel is supposed to have the patch which fixes the nmap issue. I've been testing some various things to see if that same issue is related to the problems I've been having with, well azureus in particularl.

I'll confim this: Azureus works great with -nitro1, Azureus, or any other BT client for that matter, crashes within a few moments of starting a download on -nitro2.

I don't have any of the reported issues with nvidia drivers, xorg start up, the alsa snapshot, vesafb-tng, or splash on -nitro2. All work like in -nitro1.

This seems to be a hw issue. I'm building -nitro2 on another machine, with a different nic, to test.

Azureus, at least, seems fine on the RTL-8139 nic on my notebook with -nitro2. It crashes after a few seconds of downloading on a nVidia Corporation nForce2 Ethernet Controller (rev a1) [forcedeth kernel module] on -nitro2 on the desktop machine (Asus AMD NForce2 MB).

Others who have reported this problem please chime in with your hw to help isolate the bug. :)

Last edited by mcoulman on Sat Nov 06, 2004 11:44 pm; edited 1 time in total

You can temporary fix Azureus by cranking max connects down to 100 and max connect per torrent down to 30 and only running a few torrents at a time, it's reasonably stable then.

Still crashed in mm-sources though, so whatever it is is either my network card or some still as yet unpatched kernel problem. I try to get sysrq outputs, but the only the print doesn't seem to work, I can unmount and sync(I think) and boot(I know) but that seems to be about it.

apexman has got some ideas about how to get software suspend 2 to work with latest nvidia driver from within X. I can confirm that the preliminary tests suggest that it works. go here if you are interested in suspend:

the compilation went fine for me, the kernel boots perfectly, xorg starts, but dies when running fullscreen glx-based xscreensaver modules. the windowed glx apps work perfectly. i`m using latest nvidia, which built fine

there you get a kexec patch for 2.6.9 which applies to nitro sources. only thing that failed was some insert prior to swsusp2 code because the patch looked for swsusp1, but with common sense and no coding experience in C i applied it by hand.
should be integrated in the next nitro, kexec is really nice (start new kernel, i.e. reboot without going through bios post). search bugzilla for init script etc.

Hi all !
As I read in this topic is problem with win4lin and software-suspend 2 with nitro2. I read that win4lin + nitro2 works fine, swsusp2 + nitro2 works fine too, but win4lin + swsusp2 + nitro2 doesn't compile. So I've made some patch for that problems. This patch include software_suspend-2.1.2 and win4lin. It's now work fine for me with fbsplash and vesafb-tng, but I don't use win4lin and swsusp, so I don't test that and this post is request for tests. You can download patch here : http://www.pepek.neostrada.pl/software_suspend-2.1.2-and-win4lin3-for-2.6.9-nitro2.tar.bz2 and this is archive with software_suspend directory and patch is in that directory. For patch your 2.6.9-nitro2 kernel try sth like this :