From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752318Ab0D0BYm (ORCPT ); Mon, 26 Apr 2010 21:24:42 -0400 Received: from mail-pw0-f46.google.com ([209.85.160.46]:61729 "EHLO mail-pw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751312Ab0D0BYk (ORCPT ); Mon, 26 Apr 2010 21:24:40 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=JO1cDEXdQh7J9pZsq/k3NsxcaoUtc8/AAFACb8dPoR7V0kkeYJOKDivD/r0rnShKlR yF0HCKWDYoSx3S4JVv/6X/Ge0Czu9CphOBH8RG48CxWfBB57zg9QMcxS7IAQww3k4x/O i9C9kaGuZy/BtD9I0SNogqMgB6AIhW3VpY6hY= Message-ID: <4BD63CD5.3020307@gmail.com> Date: Mon, 26 Apr 2010 19:24:37 -0600 From: Robert Hancock User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: textshell-dOFHIR@neutronstar.dyndns.org CC: linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, Jens Axboe , Doug Gilbert , "James E.J. Bottomley" , Jeff Garzik Subject: Re: Regression: hang while burning DVD in scsi_init_sgtable References: <20100425175639.GA31060@neutronstar.dyndns.org> In-Reply-To: <20100425175639.GA31060@neutronstar.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/25/2010 11:56 AM, textshell-dOFHIR@neutronstar.dyndns.org wrote: > After upgradeing from 2.6.31 to 2.6.33.2 buring a DVD with growisofs > occasionally looks up in the kernel. > The DVD drive is connected via IDE to an ICH7 IDE controller(using ATA_PIIX > driver). > > i usually burn DVDs with > growisofs -speed 4 -Z /dev/sr0 -dvd-video -udf . > and sometimes it does work with just outputting: > > 2010-04-11T15:22:14+02:00 eclipse info sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > 2010-04-11T15:22:14+02:00 eclipse info sr 0:0:1:0: [sr0] Sense Key : Illegal Request [current] > 2010-04-11T15:22:14+02:00 eclipse alert Info fld=0x0 > 2010-04-11T15:22:14+02:00 eclipse info sr 0:0:1:0: [sr0] Add. Sense: Logical block address out of range > 2010-04-11T15:22:14+02:00 eclipse info sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00 > 2010-04-11T15:22:14+02:00 eclipse err end_request: I/O error, dev sr0, sector 0 > 2010-04-11T15:22:14+02:00 eclipse err Buffer I/O error on device sr0, logical block 0 > 2010-04-11T15:22:14+02:00 eclipse info sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > 2010-04-11T15:22:14+02:00 eclipse info sr 0:0:1:0: [sr0] Sense Key : Illegal Request [current] > 2010-04-11T15:22:14+02:00 eclipse alert Info fld=0x0 > 2010-04-11T15:22:14+02:00 eclipse info sr 0:0:1:0: [sr0] Add. Sense: Logical block address out of range > 2010-04-11T15:22:14+02:00 eclipse info sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00 > 2010-04-11T15:22:14+02:00 eclipse err end_request: I/O error, dev sr0, sector 0 > 2010-04-11T15:22:14+02:00 eclipse err Buffer I/O error on device sr0, logical block 0 > > But the DVD gets written properly, so i don't really care, although it > looks like something might be working here already. > Anyway now for the second time it didn't output these messages, but instead > just hangs in the kernel. > The other processes keep running but the growisofs process is hung in the > kernel. ctrl-C or even killing with SIGKILL doesn't work. > according to /proc the task is in state "D (disk sleep)" (at the time of > writing this email). > > a bit later the kernel logs this: > > 2010-04-22T23:50:00+02:00 eclipse err INFO: task growisofs:23916 blocked for more than 120 seconds. > 2010-04-22T23:50:00+02:00 eclipse err "echo 0> /proc/sys/kernel/hung_task_timeout_secs" disables this message. > 2010-04-22T23:50:00+02:00 eclipse info growisofs D ffff8800a96ee3c0 0 23916 23913 0x00000000 > 2010-04-22T23:50:00+02:00 eclipse alert ffff8800b7845858 0000000000000086 0000007fcf195000 ffff8800aa14f058 > 2010-04-22T23:50:00+02:00 eclipse alert 000000000000ddc8 ffff8800b7845fd8 0000000000012400 0000000000012400 > 2010-04-22T23:50:00+02:00 eclipse alert ffff8800b78457c8 ffffffff811ea32c ffff88000181a1c0 ffff88009e829b00 > 2010-04-22T23:50:00+02:00 eclipse alert Call Trace: > 2010-04-22T23:50:00+02:00 eclipse alert [] ? scsi_init_sgtable+0x83/0x8a > 2010-04-22T23:50:00+02:00 eclipse alert [] ? scsi_setup_blk_pc_cmnd+0x99/0x115 > 2010-04-22T23:50:00+02:00 eclipse alert [] schedule_timeout+0x26/0x1c9 > 2010-04-22T23:50:00+02:00 eclipse alert [] ? kobject_put+0x47/0x4b > 2010-04-22T23:50:00+02:00 eclipse alert [] ? _raw_spin_lock_irq+0x17/0x2f > 2010-04-22T23:50:00+02:00 eclipse alert [] wait_for_common+0xc2/0x138 > 2010-04-22T23:50:00+02:00 eclipse alert [] ? default_wake_function+0x0/0xf > 2010-04-22T23:50:00+02:00 eclipse alert [] ? __generic_unplug_device+0x2d/0x31 > 2010-04-22T23:50:00+02:00 eclipse alert [] wait_for_completion+0x18/0x1a > 2010-04-22T23:50:00+02:00 eclipse alert [] blk_execute_rq+0x92/0xb0 > 2010-04-22T23:50:00+02:00 eclipse alert [] ? blk_rq_append_bio+0x19/0x46 > 2010-04-22T23:50:00+02:00 eclipse alert [] ? blk_rq_map_user+0x160/0x204 > 2010-04-22T23:50:00+02:00 eclipse alert [] ? security_capable+0x27/0x29 > 2010-04-22T23:50:00+02:00 eclipse alert [] sg_io+0x273/0x385 > 2010-04-22T23:50:00+02:00 eclipse alert [] scsi_cmd_ioctl+0x1e2/0x448 > 2010-04-22T23:50:00+02:00 eclipse alert [] ? sched_clock_cpu+0xc6/0xd4 > 2010-04-22T23:50:00+02:00 eclipse alert [] ? cpuacct_charge+0x57/0x5f > 2010-04-22T23:50:00+02:00 eclipse alert [] cdrom_ioctl+0x30/0xe01 > 2010-04-22T23:50:00+02:00 eclipse alert [] ? enqueue_entity+0x125/0x12d > 2010-04-22T23:50:00+02:00 eclipse alert [] ? wakeup_preempt_entity+0x9d/0xab > 2010-04-22T23:50:00+02:00 eclipse alert [] ? check_preempt_wakeup+0x1ae/0x23d > 2010-04-22T23:50:00+02:00 eclipse alert [] sr_block_ioctl+0x4b/0x82 > 2010-04-22T23:50:00+02:00 eclipse alert [] __blkdev_driver_ioctl+0x75/0x9d > 2010-04-22T23:50:00+02:00 eclipse alert [] blkdev_ioctl+0x86c/0x8a7 > 2010-04-22T23:50:00+02:00 eclipse alert [] ? _raw_spin_unlock+0x10/0x29 > 2010-04-22T23:50:00+02:00 eclipse alert [] ? do_futex+0xc2/0x92a > 2010-04-22T23:50:00+02:00 eclipse alert [] ? _raw_spin_lock_irqsave+0x18/0x34 > 2010-04-22T23:50:00+02:00 eclipse alert [] ? _raw_spin_unlock_irqrestore+0x12/0x2b > 2010-04-22T23:50:00+02:00 eclipse alert [] ? remove_wait_queue+0x48/0x4d > 2010-04-22T23:50:00+02:00 eclipse alert [] ? _raw_spin_unlock_irqrestore+0x12/0x2b > 2010-04-22T23:50:00+02:00 eclipse alert [] block_ioctl+0x38/0x3c > 2010-04-22T23:50:00+02:00 eclipse alert [] vfs_ioctl+0x2a/0x9e > 2010-04-22T23:50:00+02:00 eclipse alert [] do_vfs_ioctl+0x449/0x486 > 2010-04-22T23:50:00+02:00 eclipse alert [] ? fget_light+0xa8/0xc0 > 2010-04-22T23:50:00+02:00 eclipse alert [] ? sys_futex+0x10e/0x12c > 2010-04-22T23:50:00+02:00 eclipse alert [] sys_ioctl+0x55/0x77 > 2010-04-22T23:50:00+02:00 eclipse alert [] ? sys_write+0x60/0x6e > 2010-04-22T23:50:00+02:00 eclipse alert [] system_call_fastpath+0x16/0x1b It won't actually be blocked in scsi_init_sgtable, that's likely a spurious IP value on the stack. It looks like we're waiting for a completion of a command - could be we lost a completion somehow and it never timed out, or the application specified some huge timeout value (I think the app can do that for SG_IO commands..)