Bug 145108 - kernel panic while trying to get SMART data from FireWire hdd
kernel panic while trying to get SMART data from FireWire hdd
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
All Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-14 09:43 EST by Bernd Bartmann
Modified: 2015-01-04 17:15 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-25 04:26:41 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)

  None (edit)
Description Bernd Bartmann 2005-01-14 09:43:11 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
While trying to get SMART data from a HDD in an external FireWire
enclosure I get a kernel panic and the system freezes:

[root@deanna ~]# smartctl -a /dev/sdb
smartctl version 5.33 [i386-redhat-linux-gnu] Copyright (C) 2002-4
Bruce Allen
Home Page is http://smartmontools.sourceforge.net/

Device: IC35L120 AVVA07-0         Version:
Serial number:       VNC602A6C267HA
Device type: simplified disk
Local Time is: Fri Jan 14 15:22:48 2005 CET
Device does not support SMART
Kernel panic - not syncing: drivers/ieee1394/sbp2.c:2671:
spin_lock(drivers/scsi/hosts.c:f5ccb034) already locked by
drivers/scsi/scsi.c/615

<0>Kernel panic - not syncing: drivers/scsi/scsi_error.c:74:
spin_lock(drivers/scsi/hosts.c:f5ccb034) already locked by
drivers/scsi/scsi.c/615

Kernel is kernel-2.6.10-1.741_FC3.i686

Version-Release number of selected component (if applicable):
kernel-2.6.10-1.741_FC3.i686

How reproducible:
Always

Steps to Reproduce:
1. try to run smartctl on a FireWire hdd
2.
3.
    

Additional info:
Comment 1 Graydon Saunders 2005-04-09 21:43:05 EDT
I'm getting the exact same thing; /dev/sdf is an IDE drive in an external 
firewire enclosure, mounted as sdf by a udev rule. 
  
Running kernel-2.6.10-1.770_FC3; kernel-utils-2.4-13.1.49_FC3  (up-to-date FC3) 
 
Error messages from: 
 
smartctl -a -d scsi /dev/sdf 
kernel panic - not syncing: drivers /scsi/scsi_error.c:74: 
spin_lock(drivers/scsi/hosts.c:de80c434) already locked by 
drivers/scsi/scsi.c/615 
 
smartctl -a /dev/sdf 
kernel panic - not syncing: drivers /ieee1394/sbp2.c:2671: 
spin_lock(drivers/scsi/hosts.c:df08c834) already locked by 
drivers/scsi/scsi.c/615 
 
There were a pile of kernel state dump console messages in front of these but I 
didn't try to transcribe them. 
Comment 2 Dave Jones 2005-07-15 15:48:56 EDT
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 3 Bernd Bartmann 2005-07-15 17:19:35 EDT
I'm afraid this problem is not solved yet. In the meantime I've upgraded to FC4
and kernel-2.6.12-1.1398_FC4, but after a "smartctl -a /dev/sdb" the system
still locks hard. I could capture a trace via serial console. The "<0>Kernel
panic" appears some seconds after the first one.

Kernel panic - not syncing: drivers/ieee1394/sbp2.c:2683: spin_lock(drivers/scs)
 [<c0120908>] panic+0x45/0x1e2
 [<f8da8f71>] sbp2scsi_complete_command+0x2b5/0x2f7 [sbp2]
 [<f8da8c66>] sbp2scsi_queuecommand+0x11c/0x121 [sbp2]
 [<f881b1bf>] scsi_done+0x0/0x16 [scsi_mod]
 [<f881b1bf>] scsi_done+0x0/0x16 [scsi_mod]
 [<f881ad83>] scsi_dispatch_cmd+0x156/0x44f [scsi_mod]
 [<c02990e1>] cfq_remove_request+0x14/0xcc
 [<f8822cf1>] scsi_request_fn+0x24e/0x89f [scsi_mod]
 [<c029a7ba>] cfq_insert_request+0x55/0xef
 [<c028d156>] elv_next_request+0x56/0x157
 [<c028f665>] __generic_unplug_device+0x31/0x33
 [<c028f6b6>] generic_unplug_device+0x4f/0x166
 [<c0157673>] buffered_rmqueue+0xb8/0x31b
 [<c011be01>] default_wake_function+0x0/0xc
 [<c02908d7>] blk_execute_rq+0xc2/0x104
 [<c0157a32>] __alloc_pages+0xd1/0x3df
 [<c029444c>] sg_io+0x1a8/0x2c3
 [<c0294a90>] scsi_cmd_ioctl+0x271/0x421
 [<c01f4f3d>] inode_has_perm+0x3b/0x7f
 [<f8869916>] sd_ioctl+0x91/0xf3 [sd_mod]
 [<f8869885>] sd_ioctl+0x0/0xf3 [sd_mod]
 [<c029309f>] blkdev_ioctl+0x84/0x354
 [<c0187323>] block_ioctl+0x0/0xd
 [<c01931b1>] do_ioctl+0x51/0x55
 [<c01932a7>] vfs_ioctl+0x50/0x1aa
 [<c019345e>] sys_ioctl+0x5d/0x6b
 [<c0103a51>] syscall_call+0x7/0xb
<0>Kernel panic - not syncing: drivers/scsi/scsi_error.c:74: spin_lock(drivers)
 [<c0120908>] panic+0x45/0x1e2
 [<f881e36a>] scsi_add_timer+0x0/0x77 [scsi_mod]
 [<f881e439>] scsi_times_out+0x0/0x9c [scsi_mod]
 [<f881e475>] scsi_times_out+0x3c/0x9c [scsi_mod]
 [<c027c6bb>] i8042_timer_func+0x0/0xb
 [<c012cf53>] run_timer_softirq+0x10b/0x472
 [<c0103c0e>] common_interrupt+0x1a/0x20
 [<f881b1bf>] scsi_done+0x0/0x16 [scsi_mod]
 [<c01282ce>] __do_softirq+0x3e/0x8a
 [<c0105c29>] do_softirq+0x3e/0x42
 =======================
 [<c0105b24>] do_IRQ+0x51/0x82
 [<c0103c0e>] common_interrupt+0x1a/0x20
 [<f881b1bf>] scsi_done+0x0/0x16 [scsi_mod]
 [<c0112959>] delay_pmtmr+0x9/0x13
 [<c02130cd>] __delay+0x9/0xa
 [<c0120a2c>] panic+0x169/0x1e2
 [<f8da8f71>] sbp2scsi_complete_command+0x2b5/0x2f7 [sbp2]
 [<f8da8c66>] sbp2scsi_queuecommand+0x11c/0x121 [sbp2]
 [<f881b1bf>] scsi_done+0x0/0x16 [scsi_mod]
 [<f881b1bf>] scsi_done+0x0/0x16 [scsi_mod]
 [<f881ad83>] scsi_dispatch_cmd+0x156/0x44f [scsi_mod]
 [<c02990e1>] cfq_remove_request+0x14/0xcc
 [<f8822cf1>] scsi_request_fn+0x24e/0x89f [scsi_mod]
 [<c029a7ba>] cfq_insert_request+0x55/0xef
 [<c028d156>] elv_next_request+0x56/0x157
 [<c028f665>] __generic_unplug_device+0x31/0x33
 [<c028f6b6>] generic_unplug_device+0x4f/0x166
 [<c0157673>] buffered_rmqueue+0xb8/0x31b
 [<c011be01>] default_wake_function+0x0/0xc
 [<c02908d7>] blk_execute_rq+0xc2/0x104
 [<c0157a32>] __alloc_pages+0xd1/0x3df
 [<c029444c>] sg_io+0x1a8/0x2c3
 [<c0294a90>] scsi_cmd_ioctl+0x271/0x421
 [<c01f4f3d>] inode_has_perm+0x3b/0x7f
 [<f8869916>] sd_ioctl+0x91/0xf3 [sd_mod]
 [<f8869885>] sd_ioctl+0x0/0xf3 [sd_mod]
 [<c029309f>] blkdev_ioctl+0x84/0x354
 [<c0187323>] block_ioctl+0x0/0xd
 [<c01931b1>] do_ioctl+0x51/0x55
 [<c01932a7>] vfs_ioctl+0x50/0x1aa
 [<c019345e>] sys_ioctl+0x5d/0x6b
 [<c0103a51>] syscall_call+0x7/0xb

Comment 4 Dave Jones 2005-07-15 17:40:52 EDT
[This comment has been added as a mass update for all FC4 kernel bugs.
 If you have migrated this bug from an FC3 bug today, ignore this comment.]

Please retest your problem with todays 2.6.12-1.1398_FC4 update.

If your problem involved being unable to boot, or some hardware not being
detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE*
installing any kernel updates.
If in doubt, you can recreate this file using..

mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak
mv /etc/modprobe.conf /etc/modprobe.conf.bak
kudzu


Thank you.
Comment 5 Dave Jones 2005-09-30 02:27:18 EDT
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 6 Graydon Saunders 2005-10-01 22:46:06 EDT
It's not crashing anymore with  2.6.13-1.1526_FC4, but it's not working, 
either:  
  
[root@grithr ~]# smartctl -a /dev/sda -T permissive  
smartctl version 5.33 [i386-redhat-linux-gnu] Copyright (C) 2002-4 Bruce Allen  
Home page is http://smartmontools.sourceforge.net/  
  
Device: WDC WD16 00JB-00GVA0      Version:  
scsiModePageOffset: response length too short, resp_len=1 offset=4 bd_len=0  
>> Terminate command early due to bad response to IEC mode page  
  
Error Counter logging not supported  
  
Error Events logging not supported  
scsiModePageOffset: response length too short, resp_len=1 offset=4 bd_len=0  
Device does not support Self Test logging  
  
 
This might be because I don't know what to tell it.  Perfectly ordinary IDE 
drive enclosure, Western Digital hard drive which ought to be SMART 
capable.  /dev/sda gets created by accepting the defaults; there are no 
specific udev rules in place. 
Comment 7 Bernd Bartmann 2005-10-22 07:32:36 EDT
With kernel 2.6.13-1.1532_FC4 is also doesn't crash for me anymore, but SMART
still does not work:

smartctl version 5.33 [i386-redhat-linux-gnu] Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Device: Maxtor 4 G160J8           Version: GAK8
Serial number: G809B7YE
Device type: simplified disk
Local Time is: Sat Oct 22 13:32:05 2005 CEST
Device does not support SMART

Error Counter logging not supported

Error Events logging not supported
Device does not support Self Test logging

I'm sure that the hard disk does support SMART. 
Comment 8 Dave Jones 2005-10-25 04:26:41 EDT
I suspect the firewire drivers don't support passthrough of commands such as
SMART.  I recommend bringing this up upstream, as its not a bug per se, but
missing functionality that needs to be developed.

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