LINUX.ORG.RU
Форум — General  

Ядро для x86_64 не совсем грузится


0

0
Обновил машинку на Athlon64 X2 4200. Собрал тулчейны, скомпилил ядро под архитектуру x86_64 (ARCH=x86_64 CROSS_COMPILE=x86_64-pc-linux-gnu- ...). Оно до конца не грузится. Путём ковыряний, обнаружил, что глохнет при инициализации PCI подсистемы. Включил дебаг PCI, пересобрал, гружусь. Перед тем, как заглохнуть, появляются строчки вида:

PCI: Calling quirk ffffffff805047ea for 0000:00:0b.0

(это последняя). Подозрительным мне кажется адрес (ffff...), может, параметры компилятора какие надо написать, или в конфиге ядра чего поправить. Я уже сдался, не могу найти причину.

Ядро 2.6.18. Сейчас сижу на нём же, но под архитектурой i386. Компилятор 4.1.1, оба ядра собирались компиляторами этой же версии (под i386 и x86_64)

☆
← emerge
Вопрос относительно GPL →
Да переустанови систему с нуля. Какой хоть линукс ?
iron ★★★★★
()
Привет.

Не совсем в тему, а ты пробовал пересобрать под i386 с debug PCI и посмотреть что должно быть вместо этой злосчасной строчки? Глупая метода, конечно, но все же...

lego_12239
()
Ответ на: комментарий от Zmacs
> Гентушник. Какая разница, какой дистр?

Огромная. LFS - не дистр, плюс гораздо ближе своей политикой минимального патчинга и изменений к той же Слаке. Т.е. по дефолту мало что поломато может оказаться. А в Генте - хз, что в очередной версии ебилда приедет, но у Генты свои преимущества.

У меня вот с 2.6.15 система стоит и ядра обновляются без проблем - единственный гимор в изменениях в .config при апдейте.

Так что рецепт прост - берем сорцы ядра, руками апдейтим и внимательно думаем над каждым пунктом. А ближе к вечеру (от 00.00 до 07.00 ;) ) - могу свой конфиг выложить, для nforce4-based системки.

Gharik ☆
()
Кстати, а нафиг CROSS_COMPILE какой-то делать? ИМХО самая большая проблема в "апгрейде с единственной перезагрузкой" - это собрать мини-тулчейн (gcc, опционально binutils) для получения нативного 64-битного ядра. Потом все уже на рабочей системе строится без малейшего напряга.
Gharik ☆
()
Ответ на: комментарий от Gharik
Если не сложно, выложи конфиг. Тулчейны собрал с помощью crossdev без проблем, ядро тоже собрал, только видимо сконфигурял криво.
Zmacs ☆
() автор топика
Не парься с кросскомпилом, а лучше поставь заново.

>Подозрительным мне кажется адрес (ffff...)

Все нормально с адресом.

xnix ★★
()
Ответ на: комментарий от Gharik
> Огромная. LFS - не дистр, плюс гораздо ближе своей политикой минимального патчинга и изменений к той же Слаке. Т.е. по дефолту мало что поломано может оказаться.

Очень сожалею, но эта политика меня уже достала. Она фактически обозначает, что разработчики LFS закрывают глаза на известные всем остальным баги до следующей версии.

Разве Вам нужен GCC, который при компиляции программы с -Os -ffast-math заставляет ее сегфолтиться? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28621

AEP ★★★★★
()
Ответ на: комментарий от xnix
> Не парься с кросскомпилом, а лучше поставь заново.

Дык качать исохи - дороговато, у меня не анлим, купить какой-нить дистр для amd64 - не могу найти, а закажешь в интернет-магазине - долго ждать. А так по идее всё есть. Я ещё раз повторяю: с кросскомпиляцией проблем нет, есть проблемы с конфигурянием ядра.

Zmacs ☆
() автор топика
Ответ на: комментарий от Gharik
> ИМХО самая большая проблема в "апгрейде с единственной перезагрузкой" - это собрать мини-тулчейн (gcc, опционально binutils) для получения нативного 64-битного ядра

Нативное 64-битное ядро есть (readelf на модули и file это подтверждают), но оно не работает :)

Zmacs ☆
() автор топика
pci=bios пробовал передавать в параметрах ядра (при этом надо в конфигурации ядра разрешить работу с pci через биос)?
slav ★★★
()
Ответ на: комментарий от AEP
> Очень сожалею, но эта политика меня уже достала. Она фактически обозначает, что разработчики LFS закрывают глаза на известные всем остальным баги до следующей версии.

Полная х*рня, танки грязи не боятся. В бинарных дистрах половина багов от древности софта, а вторая половина от собственных патчей. Ну а валят все, известное дело - на опенсорц.

> Разве Вам нужен GCC, который при компиляции программы с -Os -ffast-math заставляет ее сегфолтиться? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28621

Мне хватает моска, чтобы не мешать оптимизированный по размеру код и код, с претензией на скорость. И вообще - мне неизвестны флаги gcc отличные от "-O2 -march=... -DNDEBUG -pipe".

Поэтому все сорцы, авторы коих столь самонадеянны, что позволяют себе ставить глюкавые флаги по дефолту - патчатся специальным образом для приведения ситуации к виду указанному выше. И все работает годами.

Gharik ☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← emerge
General
Вопрос относительно GPL →