|
2.2, Аноним (-), 14:56, 13/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
>А пороли он туда не будет таво?
к /dev/mem только root имеет доступ
| |
|
3.3, Aquarius (ok), 22:37, 13/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
подразумевается, что после перезагрузки root'ом может быть уже root, в общем-то, другой системы
| |
|
|
1.6, pavlinux (ok), 23:05, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Более интересно
> После перезагрузки, текст crash-дампа будет
> лежать в памяти, начиная с адреса 0xfc0000.
Как он туда попадёт, *после перезагрузки* ?! :)
| |
|
2.11, User294 (ok), 03:13, 23/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
Никак. Дамп там *останется* с "прошлого" раза. При мягкой перезагрузке содержимое памяти никто не чистит (насколько это правда-зависит от биоса/загрузчика в принципе). Так что кернелу ничто не помешает при следующей загрузке взять из памяти то что туда сложила покрашившаяся инкарнация ядра до выполнения мягкого ребута. Собссно для того и резервируется(иначе нет никаких гарантий что ядру не приспичит записать чего-то именно в эту же область оперативы, а так его явно тыкают носом в то что низзя этот кус памяти трогать). Просто и старо как мир. IIRC, были даже досовые вирусы которые пытались (с переменным успехом) переживать мягкую (теплую) перезагрузку (ту которая скипает мемтест) юзая похожие фокусы.
| |
|
3.12, pavlinux (ok), 06:07, 23/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Никак. Дамп там *останется* с "прошлого" раза.
Спасибо, что читаете более поздние сообщения
и отвечаете на более ранние. :)
| |
|
|
1.7, pavlinux (ok), 02:21, 14/09/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Единственная хитрость - сначала нужно зарезервировать память в ядре.
> Сделать это можно указав ядру параметр memmap=256K@0xfc0000 (резервируем 256К перед ядром).
1. memmap=256K$0xfc0000 ($ надо писать, для резервирования)
http://lxr.linux.no/#linux+v2.6.35/Documentation/kernel-parameters.txt#L1418
> Если ramoops в ядре, то добавляем параметры
> ramoops.mem_address=0xfc0000 и ramoops.mem_size=0x40000
2. То с вероятностью 99.999% схватите
ramoops: request mem region failed
3. cat /proc/iomem , говорит что по адресу 0xfc0000
00fc0000-00ffffff : System RAM
Где он сцука хранит??? Если я питание выключаю!!!!!!!!!!
| |
|
2.9, Аноним (-), 10:21, 14/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
Рассчитано на мягкий ребут, вызванный крахом ядра. Память не очищается, соответственно старые данные остаются на том же месте, где и оставлены. После ребута посмотрите /dev/mem, много интересного из "прошлой жизни" найти можно.
| |
|
3.10, pavlinux (ok), 14:42, 14/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
Вот что рассказал автор:
>>> Tell me please, where are stored ramoopses, if I turn off the power? :)
>>
>> When you load the module (or with kernel command line) you have to say
>> to the kernel the address to remap, i.e. where you want to store the
>> oops.
>
> It's work if only i make a "soft-reboot", without regeneration of RAM ?
>
The physical address can be normal RAM, NVRAM, and so on. Sure, if you
use normal RAM, the bootloader/bios shouldn't write the memory area
selected to store the oops at the next reboot. In the embedded world
it's a common feature, see CONFIG_PRAM of u-boot for example.
Regards, Marco
| |
|
|
1.8, stranger (??), 09:38, 14/09/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ramoops, like mtdoops, can log oops/panic information but in RAM. It can
be used with *persistent RAM* for systems without flash support. In
addition, for this systems, with this driver, it's no more needed
add to the kernel the mtd subsystem with advantage in footprint.
| |
|