Re: Sleeping on "isp_mboxwaiting" with the followingnon-sleepablelocks held:

> On Tue, Oct 21, 2003 at 02:30:21PM -0700, Matthew Jacob wrote:
> > So? How about some details and context?
>
> Um, what more "details and context" do you need?  I provided the log
> of the system activity (specifically, media errors and swap read
> failure) leading up to the panic, and the ddb backtrace.

I, and all device driver writers, typically need to know:

	a) software version- it seemed to be post 5.0, but a window of date
	is always helpful?

	b) alpha, but what attached hardware?

	c) system state. It *appears* that you were booting from the messages,
	but stating so would be helpful.

> > I thought was told that being able to use locks in HBAs is fine. I had
> > them on for a while, and then had them off. I turned them on again over
> > a month ago. I'm somewhat surprised to see that a problem shows up now.
>
> This was apparently triggered by the disk failure, which is not a
> commonly exercised code path.

Yes. After a bit more thought I now see why. A check condition will
force a renegotiation. Too bad this will now be a polled operation.

> > *I* do the right thing with locks, IMO. I hold them in my module when I
> > enter and release them if/when I leave. Seeing a lock held by some
> > random caller causing me to blow up to me seems to be a hole in the
> > architecture, but I'd be the first to admit that I hardly am up to date
> > on what the rules of the road are now so such an opinion is
> > ill-informed.
> >
> > Comment out ISP_SMPLOCK in isp_freebsd.h. If the problem goes away,
> > we'll make the change back again.
>
> I'll do what I can.
>

That's okay. PHK pointed out why he's now forced the issue, so I've
accommodated it.


> > -matt
> >
> > p.s.: you have *way* more issues here than locking- you've a bad disk.
>
> I know, but the system shouldn't blow up with a lock assertion in this
> failure mode.
>
> > Anyway, isn't alpha desupported?
>
> No.
>

Hmm- I thought the tenor of a recent thread was this.

-matt