lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 05 Mar 2007 23:13:47 -0500
From:	Eric Buddington <ebuddington@...izon.net>
To:	linux-kernel@...r.kernel.org
Subject: khubd and ent:sda1 sucking CPU with reiser4 + USB HD

Kernel 2.6.20-mm2 on an Athlon XP.

Caveat: I know my USB cabling may cause the initial failure, but I
think the system should be failing more gracefully.

After hours of backing up to my external USB drive, I see in dmesg:

APIC error on CPU0: 00(02)
APIC error on CPU0: 02(02)
APIC error on CPU0: 02(02)
...<repeats many times>
usb 1-6.2: reset high speed USB device using ehci_hcd and address 7
usb 1-6.2: device descriptor read/64, error -110
usb 1-6.2: device descriptor read/64, error -110
...<repeats 3x>
sd 0:0:0:0: scsi: Device offlined - not ready after error recovery
sd 0:0:0:0: SCSI error: return code = 0x00050000
end_request: I/O error, dev sda, sector 612518599
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: SCSI error: return code = 0x00010000
end_request: I/O error, dev sda, sector 612518839
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device
...<repeats many times>
reiser4[khubd(163)]: commit_current_atom (fs/reiser4/txnmgr.c:1049)[nikita-3176]:
WARNING: Flushing like mad: 16384
reiser4[khubd(163)]: commit_current_atom (fs/reiser4/txnmgr.c:1049)[nikita-3176]:
WARNING: Flushing like mad: 32768
...<many simiar messages>

Most problematically, khubd and ent:sda1! are conspiring to suck 100%
CPU time, even after powering off the drive. A bunch of processes are
stuck in 'D' state, possibly because they're trying to access the dead
disk, which won't umount ("device is busy").

I have not been able to test this setup with the ub driver yet (is it
possible with ub as a module, and usb-storage built in?).

I don't know how repeatable this is, but the processes are still going
and I'm happy to provide more diagnostics if you tell me what's
useful. I'll reboot tomorrow to get use of the drive again.

dmesg output from alt-sysrq-[wpp] is attached.

I have the impression that reiser4 development is cool these days, and
I'll likely reformat and try ext3 if nobody asks for more tests with
reiser4.

-Eric

View attachment "dmesg" of type "text/plain" (10878 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ