Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 157642 - scsi: sleeping function called from invalid context at mm/slab.c:2110
Summary: scsi: sleeping function called from invalid context at mm/slab.c:2110
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
: 160673 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-13 12:48 UTC by John Ellson
Modified: 2015-01-04 22:19 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-11-23 15:43:11 UTC


Attachments (Terms of Use)
dmesg output (deleted)
2005-05-13 12:48 UTC, John Ellson
no flags Details

Description John Ellson 2005-05-13 12:48:49 UTC
Created attachment 114331 [details]
dmesg output

Comment 1 John Ellson 2005-05-13 12:48:49 UTC
Description of problem:
dmesg shows some debug output that looks bad, but system runs OK.
Seems to be related to SCSI drivers.  Messages begin with:
  Debug: sleeping function called from invalid context at mm/slab.c:2110
  in_atomic():0, irqs_disabled():1
Full dmesg output attached.

Version-Release number of selected component (if applicable):
kernel-2.6.11-1.1303_FC4

How reproducible:
100%

Steps to Reproduce:
1. reboot
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 2 Gordon Ewasiuk 2005-07-17 08:19:27 UTC
Observed same error message when a network card in an FC4 server went offline:

Jul 17 04:03:22 amanda2 kernel: NETDEV WATCHDOG: eth2: transmit timed out
Jul 17 04:03:22 amanda2 kernel: Debug: sleeping function called from invalid
context at mm/slab.c:2126
Jul 17 04:03:22 amanda2 kernel: in_atomic():1, irqs_disabled():0
Jul 17 04:03:22 amanda2 kernel:  [<c014cc1c>] __kmalloc+0x89/0x8b
Jul 17 04:03:22 amanda2 kernel:  [<c019445d>] proc_create+0x84/0xe6
Jul 17 04:03:22 amanda2 kernel:  [<c019456f>] proc_mkdir_mode+0x22/0x57
Jul 17 04:03:22 amanda2 kernel:  [<c014456e>] register_handler_proc+0x7b/0x89
Jul 17 04:03:22 amanda2 kernel:  [<c0143dbf>] setup_irq+0x8e/0xe2
Jul 17 04:03:22 amanda2 kernel:  [<f89944cf>] e100_intr+0x0/0x14b [e100]
Jul 17 04:03:22 amanda2 kernel:  [<c0143ffa>] request_irq+0x85/0x9b
Jul 17 04:03:22 amanda2 kernel:  [<f89951ac>] e100_up+0xe7/0x1bd [e100]
Jul 17 04:03:22 amanda2 kernel:  [<c02b8bc2>] dev_watchdog+0x0/0xa9
Jul 17 04:03:22 amanda2 kernel:  [<c02b8c63>] dev_watchdog+0xa1/0xa9
Jul 17 04:03:22 amanda2 kernel:  [<c012a28d>] run_timer_softirq+0xe5/0x1b9
Jul 17 04:03:22 amanda2 kernel:  [<c0126602>] __do_softirq+0x72/0xdc
Jul 17 04:03:22 amanda2 kernel:  [<c0106753>] do_softirq+0x4b/0x4f
Jul 17 04:03:23 amanda2 kernel:  =======================
Jul 17 04:03:23 amanda2 kernel:  [<c0104ae8>] apic_timer_interrupt+0x1c/0x24
Jul 17 04:03:23 amanda2 kernel:  [<c010201a>] default_idle+0x0/0x29
Jul 17 04:03:23 amanda2 kernel:  [<c0102040>] default_idle+0x26/0x29
Jul 17 04:03:23 amanda2 kernel:  [<c01020c4>] cpu_idle+0x4e/0x63
Jul 17 04:03:23 amanda2 kernel: e100: eth2: e100_watchdog: link up, 100Mbps,
full-duplex

Server was up and running and the other NIC (another e100) was online.  Didn't
try an ifdown/ifup.  Didn't think about it before I rebooted the box.  Sorry.  :(

Comment 3 Dan Carpenter 2005-07-17 08:26:39 UTC
  John:  Can you upgrade to a newer kernel?
Gordon:  What kernel are you running?



Comment 4 Dan Carpenter 2005-07-18 06:09:12 UTC
I found the bug.  I don't know what the fix is.

In drivers/scsi/scsi_transport_spi.c in the funciton spi_dv_device()
spi_dv_device_internal(sdev, buffer) is called with BKL held.

The problematic call tree is:
spi_dv_device_internal()
spi_dv_device_compare_inquiry()
spi_execute()
scsi_execute()
blk_rq_map_kern(sdev->request_queue, req, buffer, bufflen, __GFP_WAIT))

The __GFP_WAIT is passed to a kmalloc later.


Comment 5 Dan Carpenter 2005-07-18 08:47:09 UTC
Crap.  I'm an idiot.  I thought down() was BKL but really it's just a semafor...  

Gordon, you're bug is probably something different from John's.  Can you open a
new bug for the issue you see?

bug 160673 is probably a duplicate of this (John's) bug.



Comment 6 Joe Orton 2005-07-18 09:23:11 UTC
*** Bug 160673 has been marked as a duplicate of this bug. ***

Comment 7 Joe Orton 2005-07-18 09:24:09 UTC
Still seen in 2.6.12-1.1398_FC4smp, i686

Comment 8 Dan Carpenter 2005-07-30 09:42:18 UTC
There is a fix upstream.
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=53222b906903fd861dc24ebccfa07ee125941313


The allocation in sym_alloc_lcb_tags() becomes GFP_ATOMIC.



Comment 9 Dave Jones 2005-09-30 06:14:35 UTC
Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.


Comment 10 Dave Jones 2005-11-10 19:12:01 UTC
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.


Comment 11 Joe Orton 2005-11-23 15:43:11 UTC
I've not seen this recur after the last few updates, marking as fixed.


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