Maybe we should consider something like:
dev->a_ops.adapter_sync_cmd = rx_sync_cmd;
dev->a_ops.adapter_enable_int = aac_rx_disable_interrupt;
- dev->OIMR = status = rx_readb (dev, MUnit.OIMR);
- if ((((status & 0xff) != 0xff) || reset_devices) &&
+ if (reset_devices &&
!aac_rx_restart_adapter(dev, 0))
++restart;
/*
* Check to see if the board panic'd while booting.
As an option for a patch (later), what was the actual value of the
Munit.OIMR register (on the x3550 and the x3650 please, just in case)?
The BIOS should not be enabling any interrupts, I will be checking if
they have needed to in some variants(IBM?) for customization or
chip(Aurora interface?) reasons...
Sincerely -- Mark Salyzyn
> -----Original Message-----
> From: Darrick J. Wong [mailto:djwong@xxxxxxxxxx]
> Sent: Friday, April 27, 2007 2:11 PM
> To: Salyzyn, Mark
> Cc: linux-scsi@xxxxxxxxxxxxxxx; Alexis Bruemmer; Vivek Goyal;
> Judith Lebzelter
> Subject: Re: [PATCH] aacraid: Initialize rx/rkt function
> pointers before calling them
>
>
> Salyzyn, Mark wrote:
>
> > In my unit tests of aacraid_kexec_5.patch, restart was not
> called for
> > normal operations. If you are just doing a normal boot,
> what conditions
> > are causing restart to be called in your case? Is it a warm restart?
> > Some kind of operation that leaves the Adapter in an
> initialized state,
> > or a bug in the driver making sure that interrupts are disabled when
> > shut down. Inquiring minds want to know!
>
> This is a normal boot of a "Serveraid 8k-l" on an IBM x3550. One
> wrinkle in the configuration is that the system is booted off the
> network, though I don't see how that would affect the aacraid's state.
> It looks like the MUnit.OIMR test just after the "Failure to
> reset here
> is an option..." comment is succeeding. The crash seems to happen
> regardless of whether we had just done a warm or cold boot.
> The option
> ROM had run during POST, if that makes any difference. No kexec/kdump
> have been configured. For that matter, neither kexec nor kdump have
> ever been run in the lifetime of the machine.
>
> Also observed on an IBM x3650.
>
> --D
>
-
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
