Ээээ, как то не обращал внимания раньше, вот дочкин хьюлет павильён dv7:

[dasha@bender ~]$ free -m && uname -r && lsb_release -d
             total       used       free     shared    buffers     cached
Mem:          3023       1066       1957          0         67        523
-/+ buffers/cache:        475       2547
Swap:         2047          0       2047
2.6.29.4-167.fc11.i586
Description:	Fedora release 11 (Leonidas)

биос кажет 3072 метра, да, вроде как 49 метров не видит

а скока видит?

Два видит. А должно быть три. Биос их видит. И когда PAE ещё не сломался тоже было 3.

$ free -m && uname -r && lsb_release -d
             total       used       free     shared    buffers     cached
Mem:          2014       1933         81          0         76       1238
-/+ buffers/cache:        618       1396
Swap:         4094         12       4082
2.6.29.4-167.fc11.i586
bash: lsb_release: команда не найдена

Enable memory remapping в биосе включал, не помогает :(

Насчёт поломанного kmod-nvidia-PAE я нагнал. Это руки. Удалил kmod-nvidia-PAE, оставил akmod-nvidia и kernel-PAE-devel. Перезагрузился - заработало PAE. Так что остроту вопрос утратил, но всё равно интересно где гигабайт.

>bash: lsb_release: команда не найдена

sudo yum install redhat-lsb -y

Какое ещё в транду sudo? И при чём тут вообще LSB?

ну ты ж скопипастил с моего поста цепочку команд, lsb_release у тебя не отрабатывает, и я всего лишь показал как поставить, к теме топа не относится конечно, но всё же. посмотри свой пост на который я ответил. а sudo ... ну поставь пакет от простого юзера, я посмотрю.

Смотри dmesg, там обычно говориться что к чему.

я тут подумал, отключи-ка ты своп в /etc/fstab и загрузись без свопа (на запущенной swapoff не покатит), и дай-ка выхлоп free сюда

Абсолютно такая же ерунда была на Centos 5.3 с обычным ядром, из 4 гигов виделось первых два,
решилось установкой PAE ядра, ну разумеется так же решается сборкой ядра, в конфиге ядра CONFIG_HIGHMEM64G=y.
Почему так, не разбирался, сдается мне есть еще один путь - прошивка биос и/или настройка биос, возможно специфика железа.

Самый простой вариант - поставить 64-х битную версию.

>Самый простой вариант - поставить 64-х битную версию.

Простой? А что отвалится?

PS за советы спасибо, сейчас нельзя перезагружаться, как можно будет - попробую загрузиться без свопа. Хотя он то легко больше 4х гб делается.

>Cмотри dmesg, там обычно говориться что к чему.

Ёлки, там много всего. Что конкретно искать?

Anyway, if you're wondering why you see only 2GB, I'll explain: 32 bit systems (without PAE) can access only 4GB of memory. Since part of that memory needs to be reserved for I/O, only part of it remains for RAM (about 3GB). One solution is called memory mapping but since it pushes any RAM above 2GB over the 4GB limit, 32 bit users won't see the benefit: rather than getting more, they will get less (only the first 2 GB that fall within the 4GB area). 64 bit, however, can see way beyond 4GB so it doesn't suffer from such quirks.

http://www.linuxquestions.org/questions/linux-hardware-18/cant-see-4-gb-ram-w...

Скажу проще - на 3Gb использовать PAE просто не нужно. Будет четыре (и будет жалко сто, если не ошибаюсь, метров), тогда можно будет включать. Но лучше использовать, когда больше четырех - 6, 8 и т.п.

Опять же, чтобы не было оверхеда в этом случае лучше поставить 64-битку.

Что отвалится? Уже почти ничего не отвалится. Флэш работает, RealPlayer тоже, 32-битные работают.

Отвалится coreavc при сборке mplayer под 64 и не помню какой звуковой виндовый кодек оттуда же. Но можно тупо воткнуть 32-битный и он прекрасно будет все показывать.

>Скажу проще - на 3Gb использовать PAE просто не нужно. Будет четыре (и будет жалко сто, если не ошибаюсь, метров)

Мне сейчас жалко 1058 мегабайт. Это не повод использовать PAE?

dmesg

Вот вывод dmesg. Я не очень хорошо понимаю все эти процессы, но видно, что сначала ядво видит 3 гб, а потом ограничивается двумя.

BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
 BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000007ff90000 (usable)
 BIOS-e820: 000000007ff90000 - 000000007ff9e000 (ACPI data)
 BIOS-e820: 000000007ff9e000 - 000000007ffe0000 (ACPI NVS)
 BIOS-e820: 000000007ffe0000 - 0000000080000000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 000000013c000000 (usable)
DMI 2.4 present.
AMI BIOS detected: BIOS may corrupt low RAM, working around it.
last_pfn = 0x7ff90 max_arch_pfn = 0x100000
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
original variable MTRRs
reg 0, base: 2GB, range: 2GB, type UC
reg 1, base: 0GB, range: 4GB, type WB
reg 2, base: 4GB, range: 512MB, type WB
reg 3, base: 4608MB, range: 256MB, type WB
reg 4, base: 4864MB, range: 128MB, type WB
reg 5, base: 4992MB, range: 64MB, type WB
total RAM coverred: 3008M
Found optimal setting for mtrr clean up
 gran_size: 64K         chunk_size: 128M        num_reg: 3      lose cover RAM: 0G
New variable MTRRs
reg 0, base: 0GB, range: 2GB, type WB
reg 1, base: 4GB, range: 1GB, type WB
reg 2, base: 5056MB, range: 64MB, type UC

<skip>

1163MB HIGHMEM available.
883MB LOWMEM available.

Кажется, я начинаю понимать.

reg 1, base: 4GB, range: 1GB, type WB

вот это и есть "it pushes any RAM above 2GB over the 4GB limit", да? Но это происходит не у всех почему-то.

отключи ремапинг в биосе. И попробуй биос обновить.

>отключи ремапинг в биосе. И попробуй биос обновить.

Биос уже обновлён. А вот отключение ремаппинга помогло! Спасибо.

хотя я был уверен, что до обновления биоса репамминг также был отключён...