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

Да переустанови систему с нуля. Какой хоть линукс ?

Привет.

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

LFS'ник?

> LFS'ник?

Гентушник. Какая разница, какой дистр?

> Гентушник. Какая разница, какой дистр?

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

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

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

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

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

Не парься с кросскомпилом, а лучше поставь заново.

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

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

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

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

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

> Не парься с кросскомпилом, а лучше поставь заново.

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

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

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

pci=bios пробовал передавать в параметрах ядра (при этом надо в конфигурации ядра разрешить работу с pci через биос)?

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

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

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

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

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