Re: [sisyphus] nvidia & kernel-std-pae

[Sergey Vlasov <vsu@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]

On Sat, Jan 27, 2007 at 11:51:31AM +0800, Valery Pipin wrote:
> Всем здраствуйте!
> 
> Konstantin A. Lepikhov wrote:
> > Hi Valery!
> >
> > Friday 26, at 07:42:14 PM you wrote:
> > > Имеются,
> > > kernel-image-std-pae-2.6.18-alt3
> > > kernel-modules-nvidia-std-pae-1.0.9746-alt1.132626.3
> > > nvidia_glx_1.0.9746
> > >
> > > кернеловский модуль не грузится и ругается  типа  "no device ..".

Странно.  А std-smp пробовали?  (В принципе std-pae обязательно
применять только для возможности полного использования >= 4G RAM, хотя
вместе с PAE в нём ещё добавляется поддержка NX; ну и оптимизация в
std-pae делается чуть получше, поскольку на старых процессорах это
ядро всё равно не работает.)

И покажите вывод dmesg при загрузке модуля nvidia - возможно, в нём
что-то появляется.

> > > PS. c wks ядром этих проблем нет, но мне не нравится в нем работать,

А там та же самая версия модуля nvidia?

> > > (cmucl'у тоже  не нравится)
> >
> > ась?
> vv@localhost ~]$ rpm -q cmucl
> cmucl-19c-alt1
> Вот что имеем на текущем wks ядре
> [vv@localhost ~]$ lisp
> Couldn't mmap at 0xbe000000, len 1048576; got mapping at 0xa7ccb000 
> insteadensure_space: Failed to validate 1048576 bytes at 0xbe000000

Это результат включения CONFIG_VMSPLIT_3G_OPT - некоторые программы не
переносят уменьшения доступного для userspace адресного пространства
(в частности, эта проблема наблюдалась в valgrind, хотя сейчас там
очередной раз сменили механизм загрузки, и вроде бы он теперь не так
чувствителен к урезанию адресного пространства).

> Проблема давняя, cmucl не хочет дружить с альтовскими smp ядрами

Имелось в виду wks?  В std никогда не было нестандартных VMSPLIT; вот
в wks это тянется уже давно.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]