Re: [Xenomai-help] Oops with ifconfig on Sequioa AMCC 440EPX board

[Wolfgang Grandegger <wg@domain.hid>]

Wolfgang Grandegger wrote:
> Hello,
> 
> I get the following Oops with a Xenomai patch kernel when configuring
> the EEPRO100 on the PCI slot:
> 
>  -bash-3.2# ifconfig eth2 172.16.0.20
> ------------[ cut here ]------------
> Badness at c0025db0 [verbose debug info unavailable]
> NIP: c0025db0 LR: c01b5658 CTR: c0190738
> REGS: cfaa9d20 TRAP: 0700   Not tainted  (2.6.26.3-dirty)
> MSR: 00029000 <EE,ME>  CR: 44002044  XER: 00000004
> TASK = cf82b5a0[1052] 'ifconfig' THREAD: cfaa8000
> NIP [c0025db0] local_bh_enable+0x84/0x9c
> LR [c01b5658] dev_set_rx_mode+0x34/0x48
> Call Trace:
> [cfaa9dd0] [c01b54bc] __dev_set_rx_mode+0x40/0xb8 (unreliable)
> [cfaa9de0] [c01b5658] dev_set_rx_mode+0x34/0x48
> [cfaa9e00] [c01b83f8] dev_open+0xd8/0x114
> [cfaa9e10] [c01b7244] dev_change_flags+0x8c/0x1b8
> [cfaa9e30] [c01f7f58] devinet_ioctl+0x63c/0x77c
> [cfaa9ea0] [c01f86f8] inet_ioctl+0xcc/0xf8
> [cfaa9eb0] [c01aa878] sock_ioctl+0x60/0x2ec
> [cfaa9ed0] [c00ba598] vfs_ioctl+0x34/0x98
> [cfaa9ee0] [c00ba8fc] do_vfs_ioctl+0x300/0x430
> [cfaa9f10] [c00baa6c] sys_ioctl+0x40/0x74
> [cfaa9f40] [c000e1ac] ret_from_syscall+0x0/0x3c
> Instruction dump:
> 80010014 83e1000c 7c0803a6 38210010 4e800020 4bfdde81 4bffffdc 3d20c02f
> 39297ba0 80090154 7c000034 5400d97e <0f000000> 2f800000 419eff94 38000001
> -bash-3.2#
> Message from syslogd@ at Thu Jan  1 01:01:21 1970 ...
> sequoia666 kernel: ------------[ cut here ]------------
> 
> -bash-3.2# uname -a
> Linux sequoia666 2.6.26.3-dirty
> -bash-3.2# cat /proc/ipipe/version
> 2.2-04
> -bash-3.2# cat /proc/xenomai/version
> 2.4.5
> 
> The NIP is at:
> 
> (gdb) l *0xc0025db0
> 0xc0025db0 is in local_bh_enable (kernel/softirq.c:141).
> 136	#ifdef CONFIG_TRACE_IRQFLAGS
> 137		unsigned long flags;
> 138	
> 139		WARN_ON_ONCE(in_irq());
> 140	#endif
> 141		WARN_ON_ONCE(irqs_disabled());
> 142	
> 143	#ifdef CONFIG_TRACE_IRQFLAGS
> 144		local_irq_save(flags);
> 145	#endif
> 
> Any idea where the problem could be?

I got a bit further with this problem. It is related to cascaded UIC
interrupts. The following patch inspired by qe_ic.c fixes the oops but
it still hangs the system if using the EEPRO100 with RTnet.

diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
index 625b275..65c50d0 100644
--- a/arch/powerpc/sysdev/uic.c
+++ b/arch/powerpc/sysdev/uic.c
@@ -125,6 +125,18 @@ static void uic_mask_ack_irq(unsigned int virq)
 	spin_unlock_irqrestore(&uic->lock, flags);
 }

+#ifdef CONFIG_IPIPE
+void __ipipe_uic_cascade_irq(unsigned int virq)
+{
+	
+	struct pt_regs regs;    /* Contents not used. */
+
+	ipipe_trace_irq_entry(virq);
+        __ipipe_handle_irq(virq, &regs);
+        ipipe_trace_irq_exit(virq);
+}
+#endif
+
 static int uic_set_irq_type(unsigned int virq, unsigned int flow_type)
 {
 	struct uic *uic = get_irq_chip_data(virq);
@@ -239,7 +251,11 @@ void uic_irq_cascade(unsigned int virq, struct
irq_desc *desc)
 	src = 32 - ffs(msr);

 	subvirq = irq_linear_revmap(uic->irqhost, src);
+#ifdef CONFIG_IPIPE
+	__ipipe_uic_cascade_irq(subvirq);
+#else
 	generic_handle_irq(subvirq);
+#endif

 uic_irq_ret:
 	spin_lock(&desc->lock);


Wolfgang.