Summary: | Problems when compiled with --enable-kernel-2.2.x, but works on a 2.4.x kernel | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Mikhail Zabaluev <mhz> |
Component: | glibc-core | Assignee: | Gleb F-Malinovskiy <glebfm> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | minor | ||
Priority: | P4 | CC: | glebfm, ldv |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux |
Description
Mikhail Zabaluev
2002-05-28 10:02:38 MSD
Resolved with adding an optional package glibc-core-%_target_cpu, compiled with the CPU-specific features turned on. Wish it was not optionally enabled and separately built. Resolved with adding an optional package glibc-core-%_target_cpu, compiled with the CPU-specific features turned on. Wish it was not optionally enabled and separately built. Не понял. Для решения проблемы достаточно было установить glibc-core-i686? В последний никаких изменений не вносилось? Не понял. Для решения проблемы достаточно было установить glibc-core-i686? В последний никаких изменений не вносилось? Да, glibc-core-i686, без изменений, достаточно. Предыдущая bugnote сделана на публику :) P.S. Почему-то не проходит make ... tests в подкаталоге elf, хотя если запустить его вручную, всё OK. Да, glibc-core-i686, без изменений, достаточно. Предыдущая bugnote сделана на публику :) P.S. Почему-то не проходит make ... tests в подкаталоге elf, хотя если запустить его вручную, всё OK. Это значит, что jdk-sun-1.4.0 requires glibc-core-i686? Это значит, что jdk-sun-1.4.0 requires glibc-core-i686? С Requires не всё ясно. j2sdk-sun-1.4.0_01 собирается под i586. Может быть, имеет смысл предоставлять виртуальную \"фичу\" оптимизированного glibc, которую требует JDK/JRE, типа, glibc(floating-stack)? Чтение багрепорта JDK (см. ссылку в описании выще) подсказывает, что для \"неулучшенной\" libpthread можно решить проблему установкой ulimit -s 2048. Сделать скрипт запуска java, который этим будет заниматься? С Requires не всё ясно. j2sdk-sun-1.4.0_01 собирается под i586. Может быть, имеет смысл предоставлять виртуальную \"фичу\" оптимизированного glibc, которую требует JDK/JRE, типа, glibc(floating-stack)? Чтение багрепорта JDK (см. ссылку в описании выще) подсказывает, что для \"неулучшенной\" libpthread можно решить проблему установкой ulimit -s 2048. Сделать скрипт запуска java, который этим будет заниматься? Если нет ничего лучше. Если нет ничего лучше. В итоге, что будем делать? В итоге, что будем делать? Выглядит как проблема комюинации JVM/libc/kernel: на jdk-1.4.1 были отзывы \"легче\"; с glibc-core-i686 -- отчетливо легче; на kernel24-linus-2.4.18-alt6 легче, чем на том же -up/-smp. Также прозвучало следующее: echo 0 > /proc/sys/vm/heap-stack-gap -- после этого SegFaultTest стало еще в раза в полтора легче (дольше прожил) и получился трейс. При этом кол-во итераций уперлось в 1024, судя по трейсу. Сегодя в sisyphus@. :-) PS: насчет ulimit -s 2048 -- не уверен. Оно by default на свежем сизифе стоит в 8192 и ->2048 -- _ухудшает_ ситуацию. Выглядит как проблема комюинации JVM/libc/kernel: на jdk-1.4.1 были отзывы \"легче\"; с glibc-core-i686 -- отчетливо легче; на kernel24-linus-2.4.18-alt6 легче, чем на том же -up/-smp. Также прозвучало следующее: echo 0 > /proc/sys/vm/heap-stack-gap -- после этого SegFaultTest стало еще в раза в полтора легче (дольше прожил) и получился трейс. При этом кол-во итераций уперлось в 1024, судя по трейсу. Сегодя в sisyphus@. :-) PS: насчет ulimit -s 2048 -- не уверен. Оно by default на свежем сизифе стоит в 8192 и ->2048 -- _ухудшает_ ситуацию. glibc-2.5-alt1 is built with --enable-kernel=2.6.9 |