[ copying Rafael as this appears to be getting into regression territory ] On Mon, Jun 13, 2011 at 12:21 AM, Xiangliang Yu <yuxiangl@xxxxxxxxxxx> wrote: > > >>> > 2.6.39-rc4 work fine, but 2.6.39-rc5 has kernel panic. >>> >>> Still smells like a regression. If you run a git bisect between those >>> two versions it should be pretty straightforward to identify the >>> offending commit. There were some interesting block/scsi changes in >>> that window: >>> >>> Jens Axboe (5): >>> block: kill blk_flush_plug_list() export >> > cfq-iosched: read_lock() does not always imply rcu_read_lock() >> > block: get rid of QUEUE_FLAG_REENTER >> > block: remove stale kerneldoc member from __blk_run_queue() >> > elevator: check for ELEVATOR_INSERT_SORT_MERGE in !elvpriv case too >>> >>> Liu Yuan (1): >>> block, blk-sysfs: Fix an err return path in blk_register_queue() >>> >>> Tao Ma (1): >>> block: Remove the extra check in queue_requests_store >>> >>> Tejun Heo (1): >>> block: don't propagate unlisted DISK_EVENTs to userland > >>Or try linux 3.0-rc2 which as yet another block queue lifetime vs. hotplug >>fix (which is not yet available in a 2.6.39.y kernel). > > It still kernel panic. In the same way? So to recap all kernels prior to 2.6.39-rc4 do not show this problem, and that you have individually tested v2.6.39-rc5 and 3.0-rc2 and the problem still exists, but that you don't know the precise commit between 2.6.39-rc4 and 2.6.39-rc5 that causes the problem? I still think a bisect would be useful, and in the meantime I'll see if this can be reproduced reliably with isci (but presently isci has its own internal hotplug issues that are being worked). -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
