Bug 519772 - installer ignores ieee1394 firewire harddrive
Summary: installer ignores ieee1394 firewire harddrive
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-27 18:53 UTC by John Reiser
Modified: 2009-09-03 21:16 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-03 19:06:01 UTC


Attachments (Terms of Use)
/tmp/storage.log (95.86 KB, text/plain)
2009-08-27 18:53 UTC, John Reiser
no flags Details
dmesg output (46.31 KB, text/plain)
2009-08-27 18:54 UTC, John Reiser
no flags Details
anaconda.log (90.84 KB, text/plain)
2009-08-27 18:55 UTC, John Reiser
no flags Details
syslog (52.74 KB, text/plain)
2009-08-27 18:57 UTC, John Reiser
no flags Details
/tmp/storage.log (95.86 KB, text/plain)
2009-09-03 14:30 UTC, John Reiser
no flags Details
syslog (52.42 KB, text/plain)
2009-09-03 14:34 UTC, John Reiser
no flags Details

Description John Reiser 2009-08-27 18:53:16 UTC
Created attachment 358941 [details]
/tmp/storage.log

Description of problem: The installer ignores a harddrive that is connected via ieee1394a (400MHz FireWire) with a GPT partition table.  The kernel sees it, but the drive and its partitions do not appear in the list of disks in the partitioning dialog.


Version-Release number of selected component (if applicable):
anaconda-12.15 on Fedora-12-Alpha-i686-DVD

How reproducible: every time


Steps to Reproduce:
1. boot Fedora-12-Alpha-i686-DVD for install with FireWire disk connected.
2. proceed to partitioning dialog
3.
  
Actual results: FireWire disk and partitions are not listed in partitioning dialog


Expected results: FIreWire disk and partitions are listed in partitioning dialog


Additional info:

Comment 1 John Reiser 2009-08-27 18:54:28 UTC
Created attachment 358942 [details]
dmesg output

kernel recognizes firewire harddrive as sde

Comment 2 John Reiser 2009-08-27 18:55:59 UTC
Created attachment 358943 [details]
anaconda.log

Comment 3 John Reiser 2009-08-27 18:57:02 UTC
Created attachment 358944 [details]
syslog

Comment 4 Joel Andres Granados 2009-09-02 11:19:19 UTC
Does this happen with a regular device that has a gpt label.  I'm thinking this has to do with the label being gpt and not with the hard drive being ieee1394.

Comment 5 John Reiser 2009-09-02 14:45:35 UTC
Both anaconda-12.15 (F12-Alpha) and anaconda-12.17 recognize all harddrives when there are two drives with DOS label and two drives with GPT label, all internal SATA2 (ASUS main board.)  So a GPT label is not the problem by itself.

Comment 6 Joel Andres Granados 2009-09-03 08:45:06 UTC
hrm, this might have something to do with it:

...
[2009-08-27 18:27:57,676]    DEBUG: no type or existing type for sde, bailing
...

Comment 7 Joel Andres Granados 2009-09-03 10:38:06 UTC
I don't see a message for creating a parted disk for /dev/sde.  Could this be a parted, pyparted related error?
Can you pls go to tty2 and run the following scritp (run it as `python script`):

<snip>
import parted
dev = parted.getDevice("/dev/sde")
disk = parted.Disk(device=dev)
print disk.partitions
print disk.type
</snip>

Comment 8 John Reiser 2009-09-03 14:27:25 UTC
Here is the output of "python ./script".  stdout is empty, stderr has a
traceback:
-----
Traceback (most recent call last):
  File "./script", line 2, in <module>
    dev = parted.getDevice("/dev/sde")
  File "<string>", line 2, in getDevice
  File "/usr/lib/python2.6/site-packages/parted/decorators.py", line 30, in
localeC
    ret = fn(*args, **kwds)
  File "/usr/lib/python2.6/site-packages/parted/__init__.py", line 230, in
getDevice
    return Device(path=path)
  File "<string>", line 2, in __init__
  File "/usr/lib/python2.6/site-packages/parted/decorators.py", line 30, in
localeC
    ret = fn(*args, **kwds)
  File "/usr/lib/python2.6/site-packages/parted/device.py", line 52, in
__init__
    self.__device = _ped.device_get(path)
_ped.DeviceException: Could not find device for path /dev/sde
-----

/dev/sde exists and is a block device (major=8, minor=64) with permissions 0660
(rw-rw----).  Immediately prior to the boot of the DVD for install, a running
Fedora 12 rawhide [of last last week] automatically recognized the device, and
all its partitions appeared on Gnome desktop as icons and as windows.

Here is a copy+paste of ./script itself, just to check for typos, etc:
-----
import parted
dev = parted.getDevice("/dev/sde")
disk = parted.Disk(device=dev)
print disk.partitions
print disk.type
-----

Comment 9 John Reiser 2009-09-03 14:30:28 UTC
Created attachment 359686 [details]
/tmp/storage.log

/tmp/storage.log after running the "python ./script"

Comment 10 John Reiser 2009-09-03 14:34:30 UTC
Created attachment 359687 [details]
syslog

Notice these lines from syslog:
-----
<5>firewire_sbp2: fw1.0: sbp2_scsi_abort
<3>firewire_sbp2: status write for unknown orb
<3>=============================================================================
<3>BUG kmalloc-192 (Not tainted): Invalid object pointer 0xc19e50a4
<3>-----------------------------------------------------------------------------
<3>
<3>INFO: Slab 0xc28501ac objects=17 used=17 fp=0x(null) flags=0x40000083
<4>Pid: 316, comm: hald Not tainted 2.6.31-0.125.4.2.rc5.git2.fc12.i686 #1
<4>Call Trace:
<4> [<c04ed059>] slab_err+0x63/0x7c
<4> [<c0600d4c>] ? free_object+0x7c/0xa1
<4> [<c04ed0a1>] ? slab_pad_check+0x2f/0xde
<4> [<c04eeb07>] __slab_free+0x140/0x24e
<4> [<f870a2aa>] ? free_orb+0x1f/0x32 [firewire_sbp2]
<4> [<c04ef151>] kfree+0xf8/0x13a
<4> [<f870a2aa>] ? free_orb+0x1f/0x32 [firewire_sbp2]
<4> [<f870a2aa>] ? free_orb+0x1f/0x32 [firewire_sbp2]
<4> [<f870a28b>] ? free_orb+0x0/0x32 [firewire_sbp2]
<4> [<f870a2aa>] free_orb+0x1f/0x32 [firewire_sbp2]
<4> [<c05f63ef>] kref_put+0x47/0x62
<4> [<f870ae22>] sbp2_status_write+0x13d/0x163 [firewire_sbp2]
<4> [<c081d4e3>] ? _spin_unlock_irqrestore+0x4f/0x6d
<4> [<f8363587>] fw_core_handle_request+0x20b/0x249 [firewire_core]
<4> [<f83791f3>] handle_ar_packet+0x106/0x12f [firewire_ohci]
<4> [<f837930f>] ar_context_tasklet+0xf3/0x112 [firewire_ohci]
<4> [<c044a5ef>] ? tasklet_action+0x4b/0xe6
<4> [<c046f25f>] ? trace_hardirqs_on_caller+0x109/0x155
<4> [<c044a627>] tasklet_action+0x83/0xe6
<4> [<c044ae23>] __do_softirq+0xc8/0x192
<4> [<c044af36>] do_softirq+0x49/0x7f
<4> [<c044b08a>] irq_exit+0x48/0x8c
<4> [<c0405705>] do_IRQ+0x92/0xb7
<4> [<c0404095>] common_interrupt+0x35/0x3c
<3>FIX kmalloc-192: Object at 0xc19e50a4 not freed
<5>firewire_sbp2: fw1.0: sbp2_scsi_abort
<6>sd 6:0:0:0: Device offlined - not ready after error recovery
<3>sd 6:0:0:0: rejecting I/O to offline device
<3>sd 6:0:0:0: rejecting I/O to offline device
<5>sd 6:0:0:0: [sde] Write Protect is off
<7>sd 6:0:0:0: [sde] Mode Sense: 00 00 00 00
<3>sd 6:0:0:0: rejecting I/O to offline device
<3>sd 6:0:0:0: [sde] Asking for cache data failed
<3>sd 6:0:0:0: [sde] Assuming drive cache: write through
<5>sd 6:0:0:0: [sde] Attached SCSI disk
-----

Comment 11 Chris Lumens 2009-09-03 14:47:43 UTC
Yeah, that would explain why the device node exists and yet parted is unable to do anything with it.  I'm going to reassign this to kernel.  Once the kernel bug is fixed, if you are still experiencing problems in anaconda, feel free to open another bug and we'll take a look at it.  There may be some work to do in pyparted/libparted to fully support firewire disks.

Comment 12 John Reiser 2009-09-03 19:06:01 UTC
The problem has disappeared using
  kernel-2.6.31-0.199.rc8.git2.fc12i.686
  anaconda-12.20
when booted from a self-composed DVD of rawhide for Thurs.Sept.3.

Comment 13 Stefan Richter 2009-09-03 20:56:47 UTC
There are two independent issues here.

Problem 1)
The disk responded to SCSI Inquiry and Read Capacity commands, but the next SCSI command timed out.  IIRC that's a Mode_Sense command to query the cache type of the disk.

Since the disk did not respond to such a command (and to a retry) during the sd driver's probe, the SCSI core takes the device offline.

The disk did actually respond, but too late.  Or did the SCSI timer fire earlier than intended?  Unlikely, but who knows.

From comment 0:
> How reproducible: every time

And from comment 12:
> The problem has disappeared using
>   kernel-2.6.31-0.199.rc8.git2.fc12i.686
>   anaconda-12.20
> when booted from a self-composed DVD of rawhide for Thurs.Sept.3.

Very strange.

Problem 2)
The firewire-sbp2 driver attempted to free memory which it hadn't allocated.  That's a bug in the driver, happening in the code path which is taken if a disk sends status for a SCSI command that already timed out.  I'll post a fix.

Comment 14 Stefan Richter 2009-09-03 21:16:44 UTC
> Problem 2)
> I'll post a fix.

http://marc.info/?l=linux1394-devel&m=125201214331538


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