On Wed, Jun 2, 2010 at 2:05 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > On Sat, 29 May 2010 19:27:23 -0700 > Cory Maccarrone <darkstar6262@xxxxxxxxx> wrote: > >> This change removes a BUG_ON for when interrupts are disabled >> during an MMC request. During boot, interrupts can be disabled >> when a request is made, causing this bug to be triggered. In reality, >> there's no reason this should halt the kernel, as the driver has proved >> reliable in spite of disabled interrupts, and additionally, there's >> nothing in this code that would require interrupts to be enabled. >> >> Signed-off-by: Cory Maccarrone <darkstar6262@xxxxxxxxx> >> --- >> drivers/mmc/host/omap.c | 1 - >> 1 files changed, 0 insertions(+), 1 deletions(-) >> >> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c >> index 2b28168..d98ddcf 100644 >> --- a/drivers/mmc/host/omap.c >> +++ b/drivers/mmc/host/omap.c >> @@ -1157,7 +1157,6 @@ static void mmc_omap_start_request(struct mmc_omap_host *host, >> mmc_omap_start_command(host, req->cmd); >> if (host->dma_in_use) >> omap_start_dma(host->dma_ch); >> - BUG_ON(irqs_disabled()); >> } >> >> static void mmc_omap_request(struct mmc_host *mmc, struct mmc_request *req) > > So we need to decide whether this should be backported into 2.6.34.x > and perhaps earlier. > > For that decision we'll need to know the things you didn't tell us: > Which drivers are affected? Under which setups is it triggering? Why > aren't lots of people reporting "hey my kernel went BUG"? > > The only setup I've managed to make it trigger on is on the HTC Herald during bootup when the driver is built into the kernel (mostly because that's all I have). I believe it's related to the fact that on bootup I get many timeout errors on "CMD5" while initializing the card. Each CMD5 timeout triggers that bug (I changed it to a WARN_ON to get it to boot in) due to the fact that part of the timeout code involves sending the request again. With interrupts turned off, that BUG would be triggered. I can't answer the question of why other people aren't reporting this -- I know the CMD timeouts are fairly common with this driver, and it's only within the last few kernel releases that their triggering the BUG started happening. (I had only been able to test it because I was carrying forward the MMC 16-bit patch I submitted a while ago which only recently made it in. I'm not sure if that's related or not, but I need that to use the MMC-OMAP on herald.) I imagine a better solution to this would be to fix the timeout issues so the repeated requests aren't a problem. But any hardware bugs that cause a timeout during boot would cause this bug to be triggered, which is why I'm proposing removing the BUG_ON entirely (since everything seems to work fine anyway). I don't know why interrupts are disabled at this point, but my limited googling around leads me to believe the recent LOCKDEP work may be the cause. I couldn't find enough information on that to know for sure though. I do know that the bug no longer triggers after the card initializes successfully (and presumably interrupts re-enable). My guess is that since other people aren't reporting this problem, it's not hugely important to backport. A better question in that case would be why am I seeing it? I don't understand why interrupts would be disabled at this point in bootup. - Cory -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
