Messages in this thread Patch in this message | | | Date | Sun, 13 Jun 1999 23:43:29 +0100 | From | Duncan Simpson <> | Subject | Dire bug in linux 2.3.6+fix |
| |
After upgrading to linux 2.3.6 I was greeted with sh: liddl.so.2 can not load shared library indicating running out of memory. This more than moderately suspect immediately after booting on a P II with 64Mb of memory. Further investigation showed get_unmapped_area in mm/mmap.c returning a non-page aligned start address which caused do_unmap to die with a result that do_mmap returnd failure. Ouch!
The following patch appears to badly impact system stability but at least I can run *some* programs with it applied.
--- linux-2.3.6/mm/mmap.c.dist Sun Jun 13 06:07:15 1999 +++ linux-2.3.6/mm/mmap.c Sun Jun 13 12:32:25 1999 @@ -358,6 +358,7 @@
for (vmm = find_vma(current->mm, addr); ; vmm = vmm->vm_next) { /* At this point: (!vmm || addr < vmm->vm_end). */ + addr = PAGE_ALIGN(addr); if (TASK_SIZE - len < addr) return 0; if (!vmm || addr + len <= vmm->vm_start) Linux 2.3.6 still regularly locks hard running bootup scripts whether from init or o.w. (SysRq-k usually works though). 2.2.9 and 2.3.5 at least seem to manage to get stuck in state D when things get SIGIOT hitting uninteruptable sleep in down_failed, which sounds like a mutex problem. A reliable way of triggering this bug is building the gcc 2.95 prerelease or running its test (the test definately recieves SIGIOT and then enters prepetual uninteruptable sleep).
I am thinking about how feasable a new heap structured list scheduler would be feasable, so am tracking 2.3.x. The idea would be that priorities are n-bit cyclic numbers (like TCP) and the rate at which a task's desirability decreases is affected by its scheduling priority. At the appropiate moment sift_down moves the task down the pecking order. This would require keeping track of a "base" value for new entrants but should be a lot cheaper (chaning a key, removing an entry and adding a key are all O(log n)).
[I guess really undesirable jobs could become locked out for a large amount of time but that could be alleged to be a feature :-)] Opinions to dps@io.stargate.co.uk about that please. Time to do coding of any sort is at a large premium right now due to problems booting with a 2.3.x kernel in general and "real" work (there is a race to publish a quantum crypto result on now... I am definately in the running).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |