OSNews

There are a lot of significant new features in this release! Two new virtualization interfaces (finally paravirt_ops made it in), a new architecture (Cell/PS3), and the lockless radix tree reads (for the dcache) should be just the ticket for scaling to 2048 CPUs and possibly beyond (they'll have to slow down and wait for the systems vendors to catch up ;-)

Basically, there's a lot of stuff in here that should scare the pants off the big UNIX guys (myself included, but I like to root for the underdog... too bad about the bears).

Allows you to load the kernel at a different address. e.g. I think for kdump you don't need a separately compiled kernel for your dump kernel anymore (previously you needed one that was compiled for a different, fixed base address).

Like Mark said, previous kernel releases needed a second kernel image in order to handle crash dumps. A bunch of releases ago, the Linux kernel added kexec, a method of loading a Linux kernel image from the running kernel and turning control over to the new kernel instance. This allowed Linux to finally have crash dump support via kdump. The new image needs to be able to dump the old kernel image, so it obviously can't be loaded into the same memory range as the old image.

The new system allows kexec to load the same kernel image into a different memory range, so you don't need to jump through hoops to get a crash dump. It would be "cooler" if Linux had dump routines that could run from within the crashing kernel, but that requires being very careful and having access to a raw block device dedicated for dumps. You can't take page faults or service interrupts from dump routines that run inside a crashing kernel, so the Linux kexec/kdump approach is a more conservative design.

I'm not completely sure if the dump image can continue to run the system after the dump. If a new production image can be loaded via kexec into the original memory range, I believe that this capability would place Linux ahead of all commercial UNIX implementations in terms of downtime due to a crash dump. Very impressive!

hmm, impressive indeed.

still, there would be the chance of it going from crash to crash. thereby getting nothing done as the kernel is to occupied firing up a new version of itself to take over for the old.

But this is fairly simple to test for. If it happens, the system can just die like it does now.

try this:
http://bugs.gentoo.org/show_bug.cgi?id=161378

There's a patch for ati-drivers 8.33.6 in Gentoo's portage. Works for me™.

Yes, but not much.

small microoptimizations in x86 (sleazy FPU, regparm, support for the Processor Data Area, optimizations for the Core 2 platform)

Sleazy FPU and regparm seem to be defaults in x86-64 already, and were just ported back to x86.

Read the reply - need I say, he is a more patient man than what I would be like in those circumstances

Just discovered the hard way that the netfilter team has made some structural changes that could impact existing iptables scripts/utilities you may run.

Oh, please, not again. This is, I'm not sure, the third time?, I'm forced to recheck every option because they screw up with the config names.

There exists a bug like that (wireless drops when system under 'heavy' load)?

If so, I'd like to know since then I might be affected by that myself.

Edited 2007-02-05 14:57

There could be a hundred reasons why the system slows wireless transfers when there is a heavy I/O load. One could be that the computer isn't fast enough to do both at the same time. More likely, the DVD burner is running as a very high priority process to prevent turning the DVD-R into a beer coaster at the expense of wireless transfer performance. Processing power and I/O are not infinite.

That is incorrect; the computer is 'powerful enough' given that I've accomplished the same task under Windows XP without any problems.

As a side note, I was not burning a cd, but ripping audio from a cd - this is on a Toshiba A100, 1.73Ghz Core Duo, 1gig ram etc. so its hardly an 'under spec'ed' machine.

The cause of the problem is more due to bad scheduler rather than an under powered machine.

The cause of the problem is more due to bad scheduler rather than an under powered machine.

It's never happened to me, I regularly do what you're describing, ripping from CD/DVD. It sounds like you have IRQ issues, try checking your dmesg output for "use pci=irqroute" errors or something like that. Or switch schedulers if that's what you think it is - I assure you that it's a bad assumption.

What you say is stupid : ripping a CD on a 1.73 GHz PC never was a heavy load to begin with. It won't tax the IO nor any scheduler. What is this nonsense ?
And the scheduler sure enough isn't bad.
I wouldn't be surprised that your wireless card driver (or even the hardware) is the culprit here.
Try the same thing you're doing with an ethernet cable, and see if your bandwidth is decreasing, instead of saying such nonsense.

I don't get your point... Maybe you forgot a smile in your post? If you didn't, just relax - noone forces you to use Linux!