Bug 709432 - [scsi_request_fn] BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1087
Summary: [scsi_request_fn] BUG: sleeping function called from invalid context at arch/...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 15
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:db1ec1d26f7fe2140cbc31e2b4f...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-31 17:37 UTC by Garve
Modified: 2012-04-12 14:05 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
GNOME 3
Last Closed: 2012-04-12 14:05:54 UTC
Type: ---


Attachments (Terms of Use)

Description Garve 2011-05-31 17:37:41 UTC
abrt version: 2.0.1
architecture:   x86_64
cmdline:        ro root=UUID=02d75961-c821-4ac4-8c2c-dff297ab9150 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=de-latin1-nodeadkeys rhgb quiet
comment:        Plugged out an USB stick.
component:      kernel
kernel:         2.6.38.6-27.fc15.x86_64
kernel_tainted: 640
os_release:     Fedora release 15 (Lovelock)
package:        kernel
reason:         BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1087
reported_to:    kerneloops: URL=http://submit.kerneloops.org/submitoops.php
time:           Tue May 31 19:32:31 2011

backtrace:
:BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1087
:in_atomic(): 0, irqs_disabled(): 1, pid: 1471, name: gvfs-gdu-volume
:Pid: 1471, comm: gvfs-gdu-volume Not tainted 2.6.38.6-27.fc15.x86_64 #1
:Call Trace:
: [<ffffffff81047d33>] __might_sleep+0xeb/0xf0
: [<ffffffff81478c83>] do_page_fault+0x1eb/0x37a
: [<ffffffff8123060f>] ? vsnprintf+0x83/0x401
: [<ffffffff81080b33>] ? arch_local_irq_save+0x15/0x1b
: [<ffffffff8147588c>] ? _raw_spin_unlock_irqrestore+0x17/0x19
: [<ffffffff8147588c>] ? _raw_spin_unlock_irqrestore+0x17/0x19
: [<ffffffff81055f02>] ? console_unlock+0x17d/0x18a
: [<ffffffff81476095>] page_fault+0x25/0x30
: [<ffffffff81216da9>] ? blk_peek_request+0x159/0x1b6
: [<ffffffff811444c8>] ? sync_buffer+0x0/0x2e
: [<ffffffff812fd96e>] scsi_request_fn+0x48/0x421
: [<ffffffff811444c8>] ? sync_buffer+0x0/0x2e
: [<ffffffff81216858>] __generic_unplug_device+0x34/0x38
: [<ffffffff81216b10>] generic_unplug_device+0x2d/0x3d
: [<ffffffff812145e2>] ? blk_backing_dev_unplug+0x0/0x14
: [<ffffffff812145de>] blk_unplug+0x26/0x2a
: [<ffffffff812145e2>] ? blk_backing_dev_unplug+0x0/0x14
: [<ffffffff812145f4>] blk_backing_dev_unplug+0x12/0x14
: [<ffffffff81143aac>] blk_run_address_space+0x24/0x26
: [<ffffffff811444ed>] sync_buffer+0x25/0x2e
: [<ffffffff81474805>] __wait_on_bit+0x48/0x7b
: [<ffffffff814748aa>] out_of_line_wait_on_bit+0x72/0x7d
: [<ffffffff811444c8>] ? sync_buffer+0x0/0x2e
: [<ffffffff8106f24f>] ? wake_bit_function+0x0/0x31
: [<ffffffff8114448c>] __wait_on_buffer+0x26/0x28
: [<ffffffff811444c4>] wait_on_buffer+0x36/0x3a
: [<ffffffff811451a0>] __bread+0x5b/0x73
: [<ffffffffa036ae77>] fat_get_entry+0x190/0x1f5 [fat]
: [<ffffffffa036b422>] __fat_readdir+0x1d4/0x81d [fat]
: [<ffffffff8112f5e7>] ? filldir+0x0/0xc7
: [<ffffffff8112f5e7>] ? filldir+0x0/0xc7
: [<ffffffff8112f5e7>] ? filldir+0x0/0xc7
: [<ffffffffa036bcb1>] fat_readdir+0x28/0x2a [fat]
: [<ffffffff8112f8a6>] vfs_readdir+0x76/0xac
: [<ffffffff8112f9c2>] sys_getdents+0x7e/0xce
: [<ffffffff81009bc2>] system_call_fastpath+0x16/0x1b

event_log:
:2011-05-31-19:37:32> Submitting oops report to http://submit.kerneloops.org/submitoops.php
:2011-05-31-19:37:39  Kernel oops report was uploaded

Comment 1 Dave Jones 2011-08-15 21:54:35 UTC
Can you confirm whether or not this still occurs in the 2.6.40 update ?

Comment 2 Garve 2011-08-16 10:36:01 UTC
Hi!

Yes, it happened last time again with the 2.6.40 kernel. I plugged in an external USB HDD, put a few data around and then I wanted to safely remove the drive (in Nautilus, rightclick the drive etc.). And right after the click the error occured again.

Comment 3 Garve 2011-08-18 21:48:10 UTC
Update: It happened just again with an external USB drive I wanted to safely remove via Nautilus (rightclick, safely remove).
But when I unmounted the drive before (umount /media/volume) and the safely remove, everything was fine.

Maybe that helps.

Comment 4 Dave Jones 2012-04-11 16:43:35 UTC
is this still happening in the 2.6.43.1 update ?

There were a number of scsi related hotplug bugfixes the last few releases.

Comment 5 Garve 2012-04-12 12:55:38 UTC
It didn't happen again! Using version 3.3 now.

Comment 6 Josh Boyer 2012-04-12 14:05:54 UTC
Thank you for letting us know.


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