Bug 147270 - kernel firewire driver is causing "sleeping function called from invalid context"
Summary: kernel firewire driver is causing "sleeping function called from invalid cont...
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: 3
Hardware: All Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-05 23:10 UTC by Michal Jaegermann
Modified: 2015-01-04 22:16 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-03 00:13:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Michal Jaegermann 2005-02-05 23:10:15 UTC
Description of problem:

Talking to a video camera hooked to a firewire interface (ohci1394
driver) is causing an incessant stream of debug messages like those:

Debug: sleeping function called from invalid context at mm/slab.c:2061
in_atomic():0, irqs_disabled():1

Call Trace:<ffffffff8012f655>{__might_sleep+171}

Debug: sleeping function called from invalid context at
in_atomic():0, irqs_disabled():1

Call Trace:<ffffffff8012f655>{__might_sleep+171}

Version-Release number of selected component (if applicable):
kernel-2.6.10-1.760_FC3 (traces were actually obtained with
kernel-2.6.10-1.741_FC3, and obviously on x86_64, but sources
involved here did not seem to really change between these two

Other than that the connection seem to be working just fine. :-)

How reproducible:
Way too easy.

Comment 1 Thomas Vander Stichele 2005-04-14 18:40:31 UTC
I had the same problems.  Additionally, once in a while when starting/stopping
grabbing the machine looks up HARD.  No oops, not even anything over serial
link, just hard lock.


This svn repo contains a patch I culled from the --mm branch, with some fixes to
compile, and this solves the issue for me.  No more tracebacks on start/stop,
and no more kernel hangs.  The dvtest.py program tries 1000 open/grab/closes,
and works fine.

Comment 2 Warren Togami 2005-04-14 19:08:44 UTC
If it is in -mm then it is already in the upstream queue for mainline inclusion.
 Convincing davej to include this in the Fedora kernel beforehand might be
difficult, because historically changes to firewire has often lead to
non-bootable systems.  This is systems EVEN WITHOUT FIREWIRE.

Comment 3 Warren Togami 2005-04-14 19:26:20 UTC
(I mean, systems with a firewall controller but no devices plugged in.)

Comment 4 Christian Schaller 2005-04-15 10:08:46 UTC
On the other hand fixes for stuff that makes fedora not crash should be given
some  consideration I think.

Comment 5 Warren Togami 2005-04-15 10:42:53 UTC
1) Firewire is unusable and crashes, but everyone's computer boots.
2) Firewire is usable, but there is a risk of breaking many people's ability to
boot without manual intervention, and this actually happened multiple times in
the past.

Given the choice between #1 and #2, we need to be pretty damned sure the patch
is 100% correct and wont cause problems for anybody before including it.  This
does not even begin to take into the account the workload of Red Hat's
engineers.  They simply don't have time to spend debugging this kind of thing
that so few of the paying customers use.  Even if it is merged, it requires
testing and any resulting problems causes lost time and effort that they cannot

This kind of functionality must depend entirely on the community.  Keep in mind
that it isn't only Fedora in poor firewire shape.  This is an upstream problem
that affects everyone, because there just isn't a large enough community working
on it.  Everyone complains, but few people do something about it.

Get this patch into upstream where it would be exposed to many thousands more
eyes and testing than Fedora's kernel.  Unfortunately the patch is longer than
the "100 lines" requirement and touches multiple files, so would probably be
rejected from the 2.6.X.Y series.  But you need to work *now* to convince them
to include it into 2.6.12.  If it is in -mm now, it is already on that path. 
Ask Andrew Morton about its status.  Test the heck out of it in as many
different configurations you can get your hands on.  See if you can break it.

Comment 6 Dave Jones 2005-07-15 17:46:48 UTC
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

Comment 7 Dave Jones 2005-10-03 00:13:07 UTC
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.

There are a large number of inactive bugs in the database, and this is the only
way to purge them.

Thank you.

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