Hi,
drivers/net/ethernet/intel/e100.c has a following construct:
static u16 mdio_ctrl_hw(struct nic *nic, ...
...
spin_lock_irqsave(&nic->mdio_lock, flags);
...
udelay(20);
...
spin_unlock_irqrestore(&nic->mdio_lock, flags);
This function is indirectly called from
static void e100_watchdog(unsigned long data)
which is a timer. So if I understand it correctly, this
will be called as a softirq. There is also another path -
e.g. via ioctl() - where this will be called in the thread
context.
Is this legal? From googling I am a bit confused, I think
it is (usleep is not really "blocking" and under RT
it is always (?) processed in a thread context), but I'd
like to check. I am mostly a userspace developer and I admit
I do not yet know all the fine differences in hard-irq,
soft-irq, when are soft-irqs processed etc).
I am still hunting livelock issues where the RT throttler
activates and after 1-3 seconds all is OK again; so far
I have been unable to capture a trace of it, as it is
strongly timing-dependent and nearly never happens in
a lab :( Due to an oversight in our code we are calling
the mdio_ctrl_hw really often (but not more often the
udelays can handle), so I suspect it can be related.
Thanks
--
Stano
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
