linux-kernel - Re: Boot regression on Mackerel with current mainline

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 10 Jul 2012 08:49:37 +0200 (CEST)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	Chris Ball <cjb@...top.org>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>, linux-sh@...r.kernel.org,
	Magnus Damm <magnus.damm@...il.com>,
	Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Boot regression on Mackerel with current mainline

Hi Chris

On Tue, 10 Jul 2012, Chris Ball wrote:

> Hi Guennadi,
> 
> On Wed, Jul 04 2012, Guennadi Liakhovetski wrote:
> > On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:
> >
> >> On Tuesday, July 03, 2012, Guennadi Liakhovetski wrote:
> >> > Hi Rafael
> >> > 
> >> > On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:
> >> > 
> >> > > Hi,
> >> > > 
> >> > > We seem to have a functional regression on Mackerel with 3.5-rc5 which
> >> > > seems to be related to SDHI.  Namely, the SDHI driver appears to wait forever
> >> > > for the devices to appear and commenting out all of the sdhi devices in the
> >> > > board file works around the problem.
> >> > > 
> >> > > I can investigate some more later today if need be.
> >> > 
> >> > Have you checked the logs? Are you seeing any of these in the kernel log:
> >> > 
> >> > genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 
> >> 
> >> I see this only once per boot, but then sh_mobile_sdhi is saying "timeout
> >> waiting for hardware interrupt" pretty much continuously.
> >
> > Yes, that's the one. Ok, let's fix it in the driver. In fact, a fix has 
> > already been submitted, but for 3.6. I hoped, 3.5 would resort to a softer 
> > form of the ONESHOT failing, so, I didn't push it for -rc. I think, the 
> > easiest would be to apply these two patches:
> >
> > "mmc: tmio: use MMC opcode defines instead of numbers"
> > http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=598cd9cc217b0aa46089a3838a8b1c37b97aa08b
> >
> > and
> >
> > "mmc: extend and rename cd-gpio helpers to handle more slot GPIO functions"
> > http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=d8e60fb51effc83e6f53de191a8440f46e5a3f2c
> >
> > The latter one looks big because of a rename, but with "-M" it's pretty 
> > trivial. Chris, do you agree?
> 
> Is the minimal fix to just add "| IRQF_ONESHOT" to the request_threaded_irq
> argument?  If so, I'd rather push just that for 3.5, and I can take care of
> having that change appear simultaneously in linux-next so that there aren't
> any conflicts.  Is that okay with you?

For that you'd have to rebase -next, right? you'd like to do that? Because 
the patch

"mmc: extend and rename cd-gpio helpers to handle more slot GPIO functions"
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=d8e60fb51effc83e6f53de191a8440f46e5a3f2c

obviously would conflict with adding "| IRQF_ONESHOT". Either would work 
with me, sure. Would you like me to submit this trivial ONESHOT fix and an 
updated version of the above patch, or would you prefer to do this 
yourself?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/