Re: [PATCH] [MMC] omap: Remove BUG_ON for disabled interrupts

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

 



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


[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux