[d-kernel] Cryptoloop на usb

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/