Bug#644362: linux-image-2.6.39-bpo.2-686-pae: hpacucli hangs when creating disks on cciss
On Wed, Oct 5, 2011 at 12:19 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi,
>
> leo weppelman wrote:
>
>> [ 240.760011] INFO: task .hpacucli:2049 blocked for more than 120 seconds.
> [...]
>> [ 240.764157] [<c12b1766>] ? mutex_lock+0x17/0x24
>> [ 240.764164] [<f84c14b7>] ? cciss_unlocked_open+0x15/0x8a [cciss]
>> [ 240.764168] [<c10ed886>] ? __blkdev_get+0xb5/0x2f3
>> [ 240.764171] [<c10edc50>] ? blkdev_get+0x18c/0x270
>> [ 240.764175] [<c10dd034>] ? iget5_locked+0xbf/0xf7
>> [ 240.764178] [<c10ec7d0>] ? I_BDEV+0x4/0x4
>> [ 240.764180] [<c10dbe6b>] ? unlock_new_inode+0x31/0x36
>> [ 240.764183] [<c10ed1fa>] ? bdget+0xd9/0xdf
> [...]
>> [ 240.764200] [<c114b107>] ? get_disk+0x6a/0x6a
>> [ 240.764204] [<f84c1455>] ? cciss_add_disk+0xf7/0x111 [cciss]
>> [ 240.764209] [<f84c414b>] ? rebuild_lun_table+0x717/0x862 [cciss]
>> [ 240.764213] [<f84c4635>] ? do_ioctl+0x39f/0x7d6 [cciss]
> [...]
>> [ 240.764225] [<c10adc89>] ? do_wp_page+0x33e/0x6f0
>> [ 240.764230] [<f84c4296>] ? rebuild_lun_table+0x862/0x862 [cciss]
>> [ 240.764234] [<c114a011>] ? __blkdev_driver_ioctl+0x1d/0x25
>
> Thanks for a clear report. There have been some cciss fixes upstream
> recently, though none of them seem particularly relevant. Please test
> v3.1-rc1 or later from experimental --- it should not require any
> packages from outside squeeze except for linux-base and
> initramfs-tools (which you can get from squeeze-backports).
>
> If that fails, please send a summary of your findings to Stephen M.
> Cameron <scameron@beardog.cce.hp.com>, Mike Miller
> <mike.miller@hp.com>, and iss_storagedev@hp.com (addresses taken from
> MAINTAINERS), and cc this bug log so we can track the resulting
> discussion.
I will see if I can make a setup for this....
As an extra datapoint, I had also tried the cciss-4.6.28-14.tar.bz2
from http://sourceforge.net/projects/cciss/files/cciss-4.6-tarballs. I
had to patch that source for the removal of the 'big lock' and that
driver had the same problem. Which is logical (of course in retrospect
;-) because the problem seems to be caused from replacing the big-lock
on the ioctl-function by the mutex_lock/unlock on cciss_mutex...
Leo
Reply to: