BUG: sleeping function called from invalid context at arch/arm/mm/fault.c:301
Krzysztof Hałasa
khalasa at piap.pl
Wed Sep 18 09:01:31 EDT 2013
Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
>> ipx435, v3.11, the card hw has gone wild (another issue) and generates
>> data abort on register access in ISR. The issue here is the warning in
>> do_page_fault(), is it normal?
>
> It is normal if the data abort gets caused from a non-atomic context.
Hmm, the ISR should be an atomic context...
#define in_atomic() ((preempt_count() & ~PREEMPT_ACTIVE) != 0)
I think a hardware IRQ is supposed to add_preempt_count() via
irq_enter() -> __irq_enter()? How could in_atomic() return 0?
A delayed, imprecise abort?
> The real question is what is solo_isr() doing causing a data abort
> in the first place.
Right.
> I suspect it's this great bit of coding in free_solo_dev():
/* Now cleanup the PCI device */
solo_irq_off(solo_dev, ~0);
pci_iounmap(pdev, solo_dev->reg_base);
if (pdev->irq)
free_irq(pdev->irq, solo_dev);
solo_irq_off() tries to disable IRQ by masking the hw line but I guess
there may be some time window in which a problem may show up.
Anyway, there is no reason to unmap registers before free_irq().
> Yep, we try to read from memory we've just unmapped.
> It's a driver bug. Please report this to the driver authors.
Right (that's a "staging" driver and I better fix it myself).
Thanks.
--
Krzysztof Halasa
Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
More information about the linux-arm-kernel
mailing list