Agree, but overstated somewhat.
The card in question that the regression is reported against is not a
released card and as such could have a flawed environment, Hardware,
Firmware or other Incompatibility. The fix for the root cause will
likely not touch the driver or the kernel.
It does raise the specter of a possible follow-on patch to address the
root cause under kdump should we determine that the problem can not be
solved in time of release of the Firmware of the current pre-released
card or if we discover that other released cards have a similar Firmware
or Hardware bug. Speculation such as these do not belong on kernel
regression reports IMHO.
Sincerely -- Mark Salyzyn
> -----Original Message-----
> From: Vivek Goyal [mailto:[email protected]]
> Sent: Friday, June 01, 2007 1:54 PM
> To: Andrew Morton
> Cc: Michal Piotrowski; Linus Torvalds; LKML;
> [email protected]; Robert de Rooy; Alan Cox;
> Tejun Heo; [email protected]; Jeff Garzik; Gregor
> Jasny; [email protected]; James Bottomley; AACRAID;
> Yinghai Lu; Vivek Goyal; [email protected]; David
> Miller; Mikael Pettersson
> Subject: Re: [2/3] 2.6.22-rc3: known regressions v2
>
>
> On Fri, Jun 01, 2007 at 09:01:15AM -0700, Andrew Morton wrote:
> > On Fri, 01 Jun 2007 14:20:55 +0200 Michal Piotrowski
> <[email protected]> wrote:
> >
> > > SCSI
> > >
> > > Subject : aacraid: adapter kernel panic'd fffffffd (kexec)
> > > References : http://lkml.org/lkml/2007/5/29/491
> > > Submitter : Yinghai Lu <[email protected]>
> > > Handled-By : Salyzyn, Mark <[email protected]>
> > > Vivek Goyal <[email protected]>
> > > Status : problem is being debugged
> >
> > Mark's
> aacraid-fix-shutdown-handler-to-also-disable-interrupts.patch is
> > known to fix this, so we can move this to "known
> regressions with patches"
>
> Hi Andrew,
>
> aacraid-fix-shutdown-handler-to-also-disable-interrupts.patch is meant
> to ensure that we don't perform an unnecessary reset of the device
> during a kexec boot. During kexec, we perform the device_shutdown()
> which should bring the device to a known sane state and a reset is
> not required while next kernel is coming up.
>
> I think this fix just masks Yinghai's problem and as such does not
> fix the root cause of the problem. In his case a software reset
> of the card is not successful and this is a problem. This problem
> will become visible during kdump.
>
> So I would think that this regression is still there just that got
> shifted from kexec to kdump.
>
> But we do need above patch to make sure kexec boot is fast and does
> not perform any unrequired device reset.
>
> Thanks
> Vivek
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
