Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261708AbUKIVoY (ORCPT ); Tue, 9 Nov 2004 16:44:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261710AbUKIVoY (ORCPT ); Tue, 9 Nov 2004 16:44:24 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]:42958 "EHLO nwkea-mail-2.sun.com") by vger.kernel.org with ESMTP id S261708AbUKIVoI (ORCPT ); Tue, 9 Nov 2004 16:44:08 -0500 Date: Tue, 09 Nov 2004 16:43:50 -0500 From: Mike Waychison Subject: Re: More linux-2.6.9 module problems In-reply-to: To: linux-os@analogic.com Cc: Linux kernel Message-id: <41913A16.5090508@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.8 (X11/20040918) X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <41911FD4.2060902@sun.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3162 Lines: 86 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 linux-os wrote: > On Tue, 9 Nov 2004, Mike Waychison wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> linux-os wrote: >> >>> >>> I have a memory-test procedure that tests >>> memory on a board, accessed via the PCI bus. >>> There is a lot of RAM and it's bank-switched >>> into some 64k windows so it takes a lot of >>> time to test, about 60 seconds. >>> >>> This is in a module, therefore inside the kernel. >>> When it is invoked via an ioctl() call, the >>> kernel is frozen for the whole test-time. The >>> test procedure does not use any spin-locks nor >>> does it even use any semaphores. It just does a >>> bunch of read/write operations over the PCI/Bus. >>> >>> I thought that I could enable the preemptible- >>> kernel option and the machine would then respond >>> normally. Not so. Even with 4 CPUs, when one >>> ioctl() is busy in the kernel, nothing else >>> happens until its done. Even keyboard activity >>> is gone, no Caps Lock and no Num Lock, no `ping` >>> response over the network. However, the machine >>> comes back to life when the memory-test is done. >>> >>> This is kernel version 2.6.9. Is it possible that >>> somebody left on the BKL when calling a module >>> ioctl() on this version? If not, what do I do >>> to be able to execute a time-consuming procedure >>> from inside the kernel? Do I break it up into >>> sections and execute schedule() periodically >>> (temporary work-around --works)?? >>> >> >> The BKL has always been grabbed across ioctls. Drop the lock when you >> enter your f_op->ioctl call and grab it again open completion. >> > > Hmmm. I get 'scheduling while atomic' screaming across the screen! > There are no atomic operations in my ioctl functions so I don't > know what its complaining about. I think I shouldn't have tried > to do anything with BKL because I (my task) doesn't own it. > 'Scheduling while atomic' means you called some function that may schedule itself out while you are holding a spinlock. Note that the BKL is not a regular spinlock, and scheduling is allowed while holding it. Please see http://james.bond.edu.au/courses/inft73626@033/Assigs/Papers/kernel_locking_techniques.html by Robert Love, the section titled "The Big Kernel Lock" Something else is wrong with your code. - -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBkToWdQs4kOxk3/MRAl2KAJ0e3Eg72MnrTWwJrctdN9YAY4T8ngCeN8p/ 7G2IkrNjDaHpkYIi0dUdoQY= =JUUw -----END PGP SIGNATURE----- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/