Fwd: Re: scsi_scan_host will hang up my system!

Fwd: Re: scsi_scan_host will hang up my system!

[crazyrushstar]

I am still reading scsi_mid_low_api.txt file.

Report my newly discovery.
Trace to kernel code,function call to
"blk_execute_rq(req->q, NULL, req, 1);" at scsi_lib.c
It's too deep to trace.

This function not response to my driver so that insmod
stuck.

If you are well known on this please tell me what 
wrong is!



___________________________________________________ 
 您的生活即時通 － 溝通、娛樂、生活、工作一次搞定！ 
 http://messenger.yahoo.com.tw/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: Re: scsi_scan_host will hang up my system!

[Hannes Reinecke]

crazyrushstar@yahoo.com.tw wrote:
> I am still reading scsi_mid_low_api.txt file.
> 
> Report my newly discovery.
> Trace to kernel code,function call to
> "blk_execute_rq(req->q, NULL, req, 1);" at scsi_lib.c
> It's too deep to trace.
> 
> This function not response to my driver so that insmod
> stuck.
> 
It looks as if you trigger a recursion in the block layer.
We've stumbled across this, too; it can happen if a driver returns
SCSI_MLQUEUE_HOST_BUSY errorneously. This can cause a really deep or
even infinite stack depth (as is triggers blk_requeue_request over and
over again).
Check for such a condition and make sure that it is _temporary_.
Otherwise use proper SCSI error codes (ie DID_NO_CONNECT) which do not
have this problem.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux Products GmbH		S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html