From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <493099E2.6070502@domain.hid> Date: Sat, 29 Nov 2008 02:24:50 +0100 From: Jan Kiszka MIME-Version: 1.0 References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF7A0116A0C84C95A7787D19A" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-help] External PCIe device: MSI interrupt install hangs up the CPU List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Rubio, Martial" Cc: jeanfrancois.gilot@domain.hid, xenomai@xenomai.org, "Dupeyrou, Gilles" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF7A0116A0C84C95A7787D19A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Martial, sorry for the late reply, but my work queue suffered from some overflows.= =2E. Rubio, Martial wrote: > Hello ... >=20 > ... I apologize : pci_bus_read_config_word is an old 32-bit access > routine ...=20 > Sorry for my great haste. >=20 > If I disable CONFIG_PCI_MSI, eth0 is plugged now on a classical PCI IRQ= > vector=20 > And the init part of PEV1100 (my external PCIe device) does not work > (it's normal) >=20 > So CONFIG_PCI_MSI is mandatory . >=20 > About PEV1100 after pci_msi_enable (allways in init part) no source of > interrupt is still enabled ... > So registration can be done (rtdm ...) . >=20 > BUT : are the MSI interrupts (eth0 & PEV1100) are rightly dispatched ??= ? >=20 > By viewing attached file, the last function seems to be > __ipipe_restore_root > And a few lines before irq_tick_handler+0x0/0x14 > [vxworks_tick_time_module]* > As if an interrupt source of PEV1100 has allready been enabled > (obviously no). The problem is that ipipe calls into Linux services (->MSI->PCI) that are not prepared for running in ipipe context: ------------[ cut here ]------------ kernel BUG at kernel/ipipe/core.c:323! invalid opcode: 0000 [#1] PREEMPT SMP Modules linked in: vxworks_tick_time_module(P) lp parport_pc ppdev parport st ide_disk ide_cd_mod ide_core af_packet joydev nfs lockd nfs_acl sunrpc autofs4 snd_pcm_oss snd_mixer_oss snd_seq binfmt_misc snd_seq_device iptable_filter ip_tables ip6_tables x_tables fuse loop dm_mod snd_hda_intel snd_pcm snd_timer snd_page_alloc snd_hwdep snd ohci1394 sr_mod ieee1394 shpchp i2c_nforce2 i2c_core forcedeth sg pci_hotplug soundcore cdrom k8temp usbhid hid ff_memless ehci_hcd ohci_hcd sd_mod usbcore edd ext3 mbcache jbd pata_amd sata_nv libata mptsas mptscsih mptbase scsi_transport_sas scsi_mod [last unloaded: parport_pc] Pid: 12492, comm: tick Tainted: P (2.6.25-pae #10) EIP: 0060:[] EFLAGS: 00010006 CPU: 0 EIP is at __ipipe_restore_root+0x1a/0x3f EAX: c042c574 EBX: 80850000 ECX: 00000001 EDX: 05de7000 ESI: 0000004c EDI: 00000000 EBP: d94e7cd4 ESP: d94e7cd4 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process tick (pid: 12492, ti=3Dd94e6000 task=3Dd89f50e0 task.ti=3Dd94e600= 0)<0> I-pipe domain Linux Stack: d94e7cdc c02e9519 d94e7cf0 c02786d8 c03d8e9c 00000085 d94e7d44 d94e7d14 c0279732 0000004c 00000004 d94e7d44 00000000 00000000 da0c1000 0000004c d94e7d2c c02797b0 0000004c 00000004 d94e7d44 c03d8f00 d94e7d54 c021a89c Call Trace: [] ? _spin_unlock_irqrestore+0x18/0x36 [] ? pci_conf1_read+0xa4/0xab [] ? raw_pci_read+0x4a/0x55 [] ? pci_read+0x1d/0x22 [] ? pci_bus_read_config_dword+0x40/0x63 [] ? read_msi_msg+0x44/0xbf [] ? set_msi_irq_affinity+0x89/0xd0 [] ? __ipipe_set_irq_affinity+0xbd/0xd1 [] ? ipipe_set_irq_affinity+0x41/0x5d [] ? xnintr_attach+0x98/0x117 [] ? rtdm_irq_request+0x23/0x49 [] ? irq_tick_handler+0x0/0x14 [vxworks_tick_time_module] [] ? open_rt+0x82/0xb4 [vxworks_tick_time_module] [] ? __rt_dev_open+0x8d/0x118 [] ? sys_rtdm_open+0x46/0x55 [] ? mq_getattr+0x106/0x158 [] ? hisyscall_event+0x137/0x256 [] ? __ipipe_dispatch_event+0xc6/0x1a3 [] ? hisyscall_event+0x0/0x256 [] ? __ipipe_syscall_root+0x7f/0x112 [] ? system_call+0x29/0x4a =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Philippe, I recall some issue that turned out to be a similar call into pci_read_config - was it resolved in any official ipipe release? However, Martial, you can likely work around it by registering the open handler of vxworks_tick_time_module only to open_nrt. That will switch the caller of rt_dev_open to secondary (Linux) mode and allow to run that service safely. Device opening is almost never time critical (and I'm planning to remove open/socket/close_rt handler for Xenomai 2.5 anywa= y). Jan --------------enigF7A0116A0C84C95A7787D19A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkkwmeIACgkQniDOoMHTA+nsgQCfUWxb103p5hnHW9ClttEBzhKg ePMAnjTa60zu3VdySxkM/+cT7c2AvjRE =sSFF -----END PGP SIGNATURE----- --------------enigF7A0116A0C84C95A7787D19A--