Re: [PATCH 1/1] megaraid_{mm,mbox}: fix a bug in reset handler

[James Bottomley <James.Bottomley@SteelEye.com>]

On Wed, 2006-04-12 at 22:00 -0700, Andrew Morton wrote:
> Oh my.  That's an awfully long interrupts-off spin.  1.7e7 operations with
> an NMI watchdog timeout of five seconds - I'm surprised it doesn't trigger.
> 
> Is that reading from a PCI register there?   Or main memory?

It's a "mailbox" region, which is a piece of main memory shared between
the driver and the card (allocated using dma_alloc_coherent).

> I'm somewhat surprised that the compiler never "optimises" this into a
> lockup, actually.  That's what `volatile' is for.

The rmb(); below ensures the compiler can't optimise.  However, I do
agree; tagging the mailbox as volatile would show the compiler better
what the intent is.

> Is it not possible to do this with an interrupt?

I'd guess not.  A lot of these types of driver have what's called a
doorbell/mailbox interface which means that as long as there's a command
slot you get access to the device (or wait for an interrupt to tell you
one's free) but you have to post the command to the device, so you wait
at the mailbox to see that it's taken (usually because the device has to
assign things like tracking numbers or indexes).  The intent is for
there to be a fairly instantaneous response however firmware doesn't
always see it that way ...

> A `cpu_relax()' in that loop would help cool things down a bit.

Actually, I think a simple udelay(25) might help in a lot of these
loops.

James