Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 May 2008 08:01:58 -0500
From:      Graham Allan <allan@physics.umn.edu>
To:        freebsd-scsi@freebsd.org
Subject:   Re: Hang on boot in isp with QLA2342 after upgrading to 6.3
Message-ID:  <482C3446.8010203@physics.umn.edu>
In-Reply-To: <20080514014307.GV25577@physics.umn.edu>
References:  <20080509011028.GV25577@physics.umn.edu>	<20080509215621.GX25577@physics.umn.edu>	<482646B5.807@miralink.com> <482760D0.1070106@physics.umn.edu>	<48276560.30302@miralink.com> <4827AD9F.50202@physics.umn.edu>	<3c0b01820805120919s7c8d5249xf5dd62934c113506@mail.gmail.com>	<20080512171404.GE25577@physics.umn.edu> <20080514014307.GV25577@physics.umn.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
Graham Allan wrote:
> On Mon, May 12, 2008 at 12:14:04PM -0500, Graham Allan wrote:
>> It has been pointed out to me that this kind of weird interaction isn't
>> exactly unknown in the SAN world, and setting up zoning on the switch
>> would probably make it go away. So I will also try that (it's probably
>> a giveway of a SAN novice that I hadn't already done so - it certainly
>> does sound like it would help). But if the hang does point to a problem
>> in the driver, I'm also happy to keep trying different things in the
>> hope of revealing where the problem actually lies.
> 
> Replying to my own message here.
> 
> The good news for me is that setting up zoning in the switch does fix
> (or at least hide) the problem on this server for me.
> 
> The bad news is, I believe I'm seeing a similar kind of behaviour on a
> completely different 6.3 setup. Haven't had time to fully characterise
> it yet, but in short... Dell 1950 with QLA2342, connected directly to
> an EMC CX300 array. Very often (lets say unpredictably 50% of time)
> hangs during boot at exactly the same point as the first system, right
> around the time it would be probing for drives.

So I guess one thing I could do is build a kernal with debugging support 
(and possibly the "deadlock recipe" from the freebsd handbook), and 
force it to the debugger when it hangs. Then I could at least get some 
tracebacks and other information - though as it never actually panics 
I'm not sure how useful the information will be - I guess it's likely 
stuck in a loop somehow. It should give some clue.

Does that sound like a reasonable idea? Does the kernel version matter 
(eg standard 6.3 vs RELENG_6)? Is this list the most appropriate place 
for me to talk about the issue?

(I also think I should double-check 6.2 again, as its release notes 
indicate it was where isp was synced from CURRENT - I'd think it should 
have the same issue).

Thanks for everyones interest,

Graham



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?482C3446.8010203>