This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 125482 - Badness in interruptible_sleep_on_timeout at kernel/sched.c:1942
Badness in interruptible_sleep_on_timeout at kernel/sched.c:1942
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
2
i586 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-07 18:32 EDT by Richard Stover
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-19 08:25:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Portion of /var/log/messages (15.83 KB, text/plain)
2004-06-07 18:35 EDT, Richard Stover
no flags Details

  None (edit)
Description Richard Stover 2004-06-07 18:32:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

Description of problem:
I have developed a USB driver which worked OK under Fedora Core 1.
Under Fedora Core 2 I get some panic-like messages in
/var/log/messages when the driver is loaded. Since the panic seems to
be in sched.c I it isn't obvious how this is caused by my code. I
don't use interruptible_sleep_on_timout in my driver. My driver uses
wait_event_interruptible_timeout.


~


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Load my device driver (obviously you can't reproduce this)
2.
3.
    

Actual Results:  Panic messages shown in attachment

Expected Results:  No panic messages

Additional info:
Comment 1 Richard Stover 2004-06-07 18:35:12 EDT
Created attachment 100945 [details]
Portion of /var/log/messages

I don't know why the panic occurs 10 times.
Comment 2 Richard Stover 2004-06-07 18:53:00 EDT
I looked into sched.c. It is using  SLEEP_ON_BKLCHECK which is defined as:
#define SLEEP_ON_BKLCHECK                               \
        if (unlikely(!kernel_locked()) &&               \
            sleep_on_bkl_warnings < 10) {               \
                sleep_on_bkl_warnings++;                \
                WARN_ON(1);                             \
        }

There is the reason for 10 panic (wanrning?) messages. But what does
'unlikely(!kernel_locked())' mean?

P.S. My real name is Richard Stover - I thought I filled in that field...
Comment 3 Arjan van de Ven 2004-06-08 01:59:42 EDT
using *_sleep_on without BKL is quite a bad/nasty bug so we moan
loudly. (well technically using interruptible_sleep_on is *almost*
always a bug but with BKL you actually *can* use it correct)

if your driver is open source (it is GPL, right?) then it would be
nice if you could put a pointer to it somewhere so that I can check
this thing out better
Comment 4 Richard Stover 2004-06-08 13:05:56 EDT
I have placed my driver source code here:
ftp://www.ccd.ucolick.org/pub/usbfo

The warning messages are generated from line 3071 of usbfo.c

I thought of another possibly related issue. I tried to replace all of my
init_waitqueue_head() calls with DECLARE_WAIT_QUEUE_HEAD() but I
always get a syntax error. For instance, replace line 3937,
    init_waitqueue_head(&(dev->wait));
with
    DECLARE_WAIT_QUEUE_HEAD(dev->wait);
Shouldn't this work? And is it at all related to the BKL problem?
   
Comment 5 Arjan van de Ven 2004-06-08 16:32:09 EDT
I don't quite yet see how wait_event_interruptible_timeout leads to
interruptible_sleep_* ....
Comment 6 Richard Stover 2004-06-08 18:21:47 EDT
We'll I'm baffled now. The warnings are no longer happening! I'm
running the exact same driver code. There must be some sequence of
things that has to happen for the interruptible_sleep* to be
triggered. I see a few instances of interruptible_sleep_* still in the
FC2 source code in drivers/usb/* but I don't see why any of that code
should be
involved.


I'll have to pick this up again when I get back from vacation.

Note You need to log in before you can comment on or make changes to this bug.