[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#776192: Linux null-pointer deref in 3.16.7-ctk2-1 (was: Bug#776192: upgrade-reports wheezy to jessie boot problem)

Apologies for being slow in getting back to you.

--On Monday, April 06, 2015 09:10:48 PM +0100 Ben Hutchings <ben@decadent.org.uk> wrote:


Control: tag -1 patch

On Mon, 2015-04-06 at 20:50 +0100, Ben Hutchings wrote:

Control: tag -1 moreinfo upstream
Control: forwarded -1 http://thread.gmane.org/gmane.linux.ubuntu.devel.kernel.general/39123/

On Thu, 2015-04-02 at 01:01 -0700, Bill MacAllister wrote:
>
> --On Sunday, January 25, 2015 11:25:34 AM +0100 Niels Thykier <niels@thykier.net> wrote:
>
> > I have CC'ed the Debian linux maintainers as I noticed your kernel
> > reports a null pointer deference in the kernel (see below for the
> > trace).  I have taken the liberty of reassigning it to the linux package
> > as well.
> >   @linux maintainers: if you suspect that the null pointer issue is
> > unrelated to Bills boot problem, please clone the bug and throw the bug
> > back to upgrade-reports for further analysis.
> >
> > Bug link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776192
> >
> > Thanks,
> > ~Niels
>
> Any news on this problem?  I am still seeing this problem even though
> we have moved on to 3.16.7-ckt7-1.
>
> I had the thought to look at the kernel modules that support the
> PERC controller on these Dell systems.  Explicitly specifying the
> mpt* modules and updating initramfs does not fix the problem.
>
> We have plenty of these 1950s.  I really need to come up with a
> work around or a solution to this problem.  Any ideas about what
> I should try next?

It looks the same as this problem:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705
http://thread.gmane.org/gmane.linux.ubuntu.devel.kernel.general/39123/

Can you confirm that the LSI controller (mptsas driver) takes more than
30 seconds to scan for devices at boot time when running the wheezy
(Linux 3.2) kernel?


I am not sure how to get a timing.  I am just starting to look at this
and see what I can figure out.


If so then we need a change to the udev rules to increase the timeout
for this driver module.  We also need to fix the driver so that it fails
cleanly if it still hits the timeout.


Also, does this patch work around the problem?

(Instructions for rebuilding the Debian kernel package:
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official )


I built a new kernel with this patch and the system now finds it
system disk and boots successfully.

Bill

--

Bill MacAllister
Systems Programmer, Stanford University
Reply to: