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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 13 Jul 2009 15:43:32 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Robert Hancock <hancockrwd@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Floppy constantly accessed in 2.6.31-rc2

On Sun, 12 Jul 2009 23:44:19 -0600
Robert Hancock <hancockrwd@...il.com> wrote:

> On 2.6.31-rc2 (actually current git as of today) the floppy drive is 
> constantly being accessed with these messages being reported:
> 
> Platform driver 'floppy' needs updating - please use dev_pm_ops
> Floppy drive(s): fd0 is 1.44M
> FDC 0 is a post-1991 82077
> end_request: I/O error, dev fd0, sector 0
> end_request: I/O error, dev fd0, sector 0
> end_request: I/O error, dev fd0, sector 0
> end_request: I/O error, dev fd0, sector 0
> end_request: I/O error, dev fd0, sector 0
> end_request: I/O error, dev fd0, sector 0
> end_request: I/O error, dev fd0, sector 0
> 
> lsof reports no process with /dev/fd0 open so it is not clear what is 
> causing this activity. It looks like the access starts when I log in to 
> X, but doesn't stop when I log out. I'm guessing HAL or something checks 
> the floppy drive and then the kernel somehow gets stuck in a loop 
> retrying the request..
> 
> Anyone have any ideas what might be causing this? Commit 
> 5e50b9ef975219304cc91d601530994861585bfe seemed a bit suspicious but 
> reverting it didn't seem to help. (It did get rid of the dev_pm_ops 
> message, though..)

I'd suggest doing something like this:

--- a/drivers/block/floppy.c~a
+++ a/drivers/block/floppy.c
@@ -2975,6 +2975,7 @@ static struct cont_t rw_cont = {
 
 static void process_fd_request(void)
 {
+	dump_stack();
 	cont = &rw_cont;
 	schedule_bh(redo_fd_request);
 }
_

to find out who is poking the floppy.

If you're correct and some process is stuck doing infinite retries then
that process should be visible in the `ps' output, probably stuck in D
state.  Please have a look, see if you can work out which process is
hitting the problem and gather its kernel stack backtrace, thanks.

Meanwhile I'll ask Rafael to add this to the regression list.

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ