Hi all,
Here is a list of some known regressions in 2.6.22-rc3.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
PCMCIA
Subject : libata and legacy ide pcmcia failure
References : http://lkml.org/lkml/2007/5/17/305
Submitter : Robert de Rooy <[email protected]>
Status : Unknown
SATA/PATA
Subject : 22-rc3 broke the CDROM in Dell notebook
References : http://lkml.org/lkml/2007/5/27/63
Submitter : Gregor Jasny <[email protected]>
Handled-By : Tejun Heo <[email protected]>
Jeff Garzik <[email protected]>
Caused-By : Tejun Heo <[email protected]>
commit d4b2bab4f26345ea1803feb23ea92fbe3f6b77bc
Status : problem is being debugged
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
Sparc64
Subject : 2.6.22-rc broke X on Ultra5
References : http://lkml.org/lkml/2007/5/22/78
Submitter : Mikael Pettersson <[email protected]>
Handled-By : David Miller <[email protected]>
Status : problem is being debugged
Regards,
Michal
--
"Najbardziej brakowa?o mi twojego milczenia."
-- Andrzej Sapkowski "Co? wi?cej"
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"
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
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
>
>
>
On 6/1/07, Salyzyn, Mark <[email protected]> wrote:
> 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
So aacraid.reset_devices=1 works with Vivek's test system?
YH