[d-kernel] Cryptoloop на usb
Alex Yustasov
snmon at server.by
Wed Nov 5 17:08:41 MSK 2003
Здравствуйте!
У меня проблема с cryptoloop на USB устройстве.
На USB flash-ka. Попробовал
modprobe cryptoloop
losetup -e blowfish /dev/loop0 /dev/sda1
mkfs.ext3 /dev/loop0
mount /dev/loop0 /mnt/disk
Записываю данные. Размонтирую
umount /mnt/disk
losetup -d /dev/loop0
rmmod cryptoloop
В логах
kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on loop(7,0), internal journal
kernel: EXT3-fs: mounted filesystem with ordered data mode.
kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24688
kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24689
kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24752
kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24753
kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24816
kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24817
kernel: cryptoloop: unloaded
При следующем монтировании того-же один каталог оказывается
?<каталог> красного цвета. Иногда получается со второго раза
(монтирование, запись, размонтирование).
Если использовался usb-uhci (на другой машине usb-ohci), то при
перезагрузке oops при unload usb-uhci (в аттаче)
и заняты /usr /proc.
Если использовался uhci - перезагрузка проходит нормально.
При загрузке системы, если usb-uhci, то usb-storage загружается очень долго.
Первый раз случилось это на ядре с swsusp, проверил на std-up-2.4.22-alt7
тоже самое. Последний сизиф.
В файл на flash-ke cryptoloop пишет нормально, пробовал сделать тоже
на раздел диска - все нормально.
Это у меня одного такое? Или я что-то делаю не так?
-------------- next part --------------
ksymoops 2.4.9 on i686 2.4.22-std-up-alt7. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.22-std-up-alt7/ (default)
-m /boot/System.map-2.4.22-std-up-alt7 (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Warning (compare_ksyms_lsmod): module ext3 is in lsmod but not in ksyms, probably no symbols exported
Unable to handle kernel paging request at virtual address d0c62010
c0155784
*pde = 01385067
Oops: 0002
CPU: 0
EIP: 0010:[proc_get_inode+196/320] Not tainted
EIP: 0010:[<c0155784>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: d0c62000 ebx: cd38d860 ecx: 00000000 edx: 00000003
esi: ce9070e0 edi: cd38d860 ebp: ccb211cd esp: c9445cb4
ds: 0018 es: 0018 ss: 0018
Process updfstab (pid: 2057, stackpage=c9445000)
Stack: ccb22e00 00000246 c0157515 ccb22da0 ce9070e0 ccb22889 ce907139 c0157540
cfdc4800 000011cd ce9070e0 ffffffea 00000000 cffb94e0 cc09200b 12f82eba
0000000d ccb22820 fffffff4 cd38d680 ccb22da0 c0140cef cd38d680 ccb22820
Call Trace: [proc_lookup+149/224] [proc_lookup+192/224] [real_lookup+79/192] [link_path_walk+1684/2432] [__alloc_pages+64/368]
Call Trace: [<c0157515>] [<c0157540>] [<c0140cef>] [<c0141594>] [<c0131130>]
[<c0127035>] [<c0127094>] [<c01272a8>] [<c0225227>] [<c0225227>] [<c012abdd>]
[<c012ac0b>] [<c0127048>] [<c012ab20>] [<c01419fb>] [<c0141db7>] [<c011d9be>]
[<c01156d9>] [<c0137114>] [<c0140a3f>] [<c0137454>] [<c0108933>]
Code: ff 40 10 8b 46 24 8b 50 14 83 ca 18 89 50 14 8b 46 18 85 c0
>>EIP; c0155784 <proc_get_inode+c4/140> <=====
>>eax; d0c62000 <[xfs]qm_dqtrxzone+187e8/2b848>
>>ebx; cd38d860 <_end+d085230/1080da30>
>>esi; ce9070e0 <_end+e5feab0/1080da30>
>>edi; cd38d860 <_end+d085230/1080da30>
>>ebp; ccb211cd <_end+c818b9d/1080da30>
>>esp; c9445cb4 <_end+913d684/1080da30>
Trace; c0157515 <proc_lookup+95/e0>
Trace; c0157540 <proc_lookup+c0/e0>
Trace; c0140cef <real_lookup+4f/c0>
Trace; c0141594 <link_path_walk+694/980>
Trace; c0131130 <__alloc_pages+40/170>
Trace; c0127035 <do_anonymous_page+115/140>
Trace; c0127094 <do_no_page+34/1f0>
Trace; c01272a8 <handle_mm_fault+58/c0>
Trace; c0225227 <vsnprintf+2b7/450>
Trace; c0225227 <vsnprintf+2b7/450>
Trace; c012abdd <filemap_nopage+bd/210>
Trace; c012ac0b <filemap_nopage+eb/210>
Trace; c0127048 <do_anonymous_page+128/140>
Trace; c012ab20 <filemap_nopage+0/210>
Trace; c01419fb <path_lookup+1b/30>
Trace; c0141db7 <open_namei+77/750>
Trace; c011d9be <parse_table+be/e0>
Trace; c01156d9 <do_page_fault+189/4cb>
Trace; c0137114 <filp_open+34/60>
Trace; c0140a3f <getname+5f/a0>
Trace; c0137454 <sys_open+34/80>
Trace; c0108933 <system_call+33/40>
Code; c0155784 <proc_get_inode+c4/140>
00000000 <_EIP>:
Code; c0155784 <proc_get_inode+c4/140> <=====
0: ff 40 10 incl 0x10(%eax) <=====
Code; c0155787 <proc_get_inode+c7/140>
3: 8b 46 24 mov 0x24(%esi),%eax
Code; c015578a <proc_get_inode+ca/140>
6: 8b 50 14 mov 0x14(%eax),%edx
Code; c015578d <proc_get_inode+cd/140>
9: 83 ca 18 or $0x18,%edx
Code; c0155790 <proc_get_inode+d0/140>
c: 89 50 14 mov %edx,0x14(%eax)
Code; c0155793 <proc_get_inode+d3/140>
f: 8b 46 18 mov 0x18(%esi),%eax
Code; c0155796 <proc_get_inode+d6/140>
12: 85 c0 test %eax,%eax
2 warnings issued. Results may not be reliable.
-------------- next part --------------
Scanned by evaluation version of Dr.Web antivirus Daemon
http://drweb.ru/unix/
More information about the devel-kernel
mailing list