linux-kernel - Re: [linux-usb-devel] khubd and ent:sda1 sucking CPU with reiser4 + USB HD

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.0703071713220.9831-100000@iolanthe.rowland.org>
Date:	Wed, 7 Mar 2007 17:18:29 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	ebuddington@...leyan.edu
cc:	Oliver Neukum <oneukum@...e.de>,
	USB development list <linux-usb-devel@...ts.sourceforge.net>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [linux-usb-devel] khubd and ent:sda1 sucking CPU with reiser4
 + USB HD

On Wed, 7 Mar 2007, Eric Buddington wrote:

> On Wed, Mar 07, 2007 at 03:22:05PM -0500, Alan Stern wrote:
> > On Wed, 7 Mar 2007, Eric Buddington,,, wrote:
> > 
> > > > > So SysRq-t doesn't show anything about khubd, and SysRq-p doesn't give
> > > > > me anything at all. What else can I try?
> > 
> > How about SysRq-r?
> 
> SysRq : Keyboard mode set to XLATE

Whoops, I was thinking of SysRq-p, which you have already tried.

> > These problems start with some USB resets, right?  Did they occur with 
> > earlier kernel versions, or is this new behavior?
> 
> Yes, the problem starts with USB resets (or USB errors that trigger a reset)
> 
> > How often does the problem occur?
> 
> Recently, the USB drive has choked up after several hours of moderate
> use. However, before this instance, it would consistently hang up my
> watchdog process and force a system reboot (no idea why; the watchdog
> process didn't use this drive at all). This may have changed when I
> upgraded from 2.6.20-rc6-mm3 to 2.6.20-mm2, but my sample size is to
> small to be sure.

What about earlier kernels?  Does 2.6.19 work any better?

What about non -mm kernels, like 2.6.21-rc2?

I've never heard of a process failing to show up in a SysRq-t listing.  It 
suggests something is wrong with the process management in the kernel you 
were using.  That leads me to think a non -mm kernel might give more 
informative results.

And as long as you're testing, you might as well also turn on 
CONFIG_USB_DEBUG.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/