From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48A3D20B.2080509@domain.hid> Date: Thu, 14 Aug 2008 08:34:51 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20080812075358.4cg1ix9945msccsc@domain.hid> <48A12EA8.4070601@domain.hid> <48A34D75.9090509@domain.hid> <48A359D4.9090002@domain.hid> In-Reply-To: <48A359D4.9090002@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEF9E5AB2F51C402020911ED9" Sender: jan.kiszka@domain.hid Subject: Re: [Adeos-main] [RTnet-users] e1000 & MSI List-Id: General discussion about Adeos List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bernhard Pfund Cc: adeos-main , RTnet-users@domain.hid This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEF9E5AB2F51C402020911ED9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > Bernhard Pfund wrote: >> Jan Kiszka wrote: >>> Please post the oops. Also include the Adeos patch version you are us= ing >>> for this. >>> >>> Jan >>> >> >> Hi Jan >> >> Eventually I found the call that is responsible for the mess. It's >> basically not in the rt_e1000 driver when loaded, but the ioctl sent b= y >> rtifconfig (ifonfig of RTnet) when trying to activate the NIC. I enabl= ed >> i-pipe debugging in the kernel and got the following. I also posted th= e >> trace to the RTAI list, but maybe you've seen something similar before= ? >=20 > That's good that you forwarded it as this is an Adeos issue, not an RTA= I > thing. Added the related list. >=20 >> >> Bernhard >> >> Adeos is RTAI's hal-linux-2.6.26-x86-2.0-09.patch >=20 > OK. >=20 >> >> I-pipe: Domain RTAI registered. >> RTAI[hal]: mounted over IPIPE-NOTHREADS 2.0-09. >> RTAI[hal]: compiled with gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7). >> RTAI[hal]: mounted (IPIPE-NOTHREADS, IMMEDIATE (INTERNAL IRQs VECTORED= ), >> ISOL_CPUS_MASK: e). >> PIPELINE layers: >> f8936600 9ac15d93 RTAI 200 >> c0737540 0 Linux 100 >> RTAI[malloc]: global heap size =3D 4194304 bytes, . >> RTAI[sched]: IMMEDIATE, MP, USER/KERNEL SPACE: ,= >> kstacks pool size =3D 1048576 bytes. >> RTAI[sched]: hard timer type/freq =3D APIC/16666663(Hz); default timin= g: >> periodic; linear timed lists. >> RTAI[sched]: Linux timer freq =3D 1000 (Hz), CPU freq =3D 2400046000 h= z. >> RTAI[sched]: timer setup =3D 999 ns, resched latency =3D 0 ns. >> RTAI[usi]: enabled. >> RTAI[rtai_msgq]: loaded. >> RTAI[mq]: loaded. >> RTDM started. >> >> *** RTnet 0.9.11 - built on Aug 13 2008 22:31:19 *** >> >> RTnet: initialising real-time networking >> Intel(R) PRO/1000 Network Driver - version 7.1.9 >> Copyright (c) 1999-2006 Intel Corporation. >> ACPI: PCI Interrupt Link [APC8] enabled at IRQ 16 >> ACPI: PCI Interrupt 0000:03:00.0[A] -> Link [APC8] -> GSI 16 (level, >> low) -> IRQ 16 >> PCI: Setting latency timer of device 0000:03:00.0 to 64 >> e1000: 0000:03:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) >> 00:1b:21:1e:56:64 >> RTnet: registered rteth0 >> e1000: rteth0: e1000_probe: Intel(R) PRO/1000 Network Connection >> I-pipe: Detected illicit call from domain 'RTAI' >> into a service reserved for domain 'Linux' and below. >> Pid: 0, comm: swapper Not tainted 2.6.26.2-FuCS #3 >> [] ipipe_check_context+0xd6/0xf0 >> [] <6>e1000: rteth0: e1000_watchdog: NIC Link is Up 1000 Mb= ps >> Full Duplex >> _spin_lock_irqsave+0x1e/0x80 >> [] pci_bus_read_config_word+0x36/0x80 >> [] __pci_bus_find_cap_start+0x1e/0x50 >> [] pci_find_capability+0x24/0x50 >> [] msi_set_enable+0x22/0x80 >> [] ? mcount+0x1f/0x23 >> [] msi_set_mask_bits+0xcf/0xe0 >> [] ? mcount+0x1f/0x23 >> [] unmask_msi_irq+0x17/0x30 >> [] default_enable+0x1a/0x30 >> [] rt_enable_irq+0xe/0x10 [rtai_hal] >> [] ? xnintr_irq_handler+0x149/0x1f0 [rtai_rtdm] >> [] rtai_hirq_dispatcher+0xfb/0x430 [rtai_hal] >> [] default_idle+0x45/0x60 >> [] default_idle+0x0/0x60 >> [] common_interrupt+0x2f/0x54 >> [] default_idle+0x0/0x60 >> [] cgroup_file_write+0x118/0x140 >> [] default_idle+0x45/0x60 >> [] cpu_idle+0x86/0x140 >> [] start_secondary+0x16d/0x210 >> [] initialize_secondary+0x8/0x20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> I-pipe tracer log (100 points): >> | +*func 0 ipipe_trace_panic_freeze+0x9 >> (ipipe_check_context+0x94) >> | +*func 0 find_next_bit+0xa (__next_cpu+0x1a) >> | +*func 0 __next_cpu+0x9 (ipipe_check_context+0x= 88) >> | +*func 0 find_next_bit+0xa (__next_cpu+0x1a) >> | +*func 0 __next_cpu+0x9 (ipipe_check_context+0x= 88) >> | +*func 0 find_next_bit+0xa (__next_cpu+0x1a) >> | +*func 0 __next_cpu+0x9 (ipipe_check_context+0x= 88) >> | +*func 0 find_next_bit+0xa (__next_cpu+0x1a) >> | +*func 0 __next_cpu+0x9 (ipipe_check_context+0x= 88) >> | +*func 0 find_first_bit+0xa (__first_cpu+0x12) >> | +*func -1 __first_cpu+0x8 >> (ipipe_check_context+0x66) >> | +*func -1 ipipe_check_context+0x14 >> (_spin_lock_irqsave+0x1e) >> | +*func -1 _spin_lock_irqsave+0x12 >> (pci_bus_read_config_word+0x36) >> | +*func -1 pci_bus_read_config_word+0x14 >> (__pci_bus_find_cap_start+0x1e) >> | +*func -1 __pci_bus_find_cap_start+0xc >> (pci_find_capability+0x24) >> | +*func -1 pci_find_capability+0x11 >> (msi_set_enable+0x22) >> | +*func -1 msi_set_enable+0x14 >> (msi_set_mask_bits+0xcf) >> | +*func -1 msi_set_mask_bits+0xe >> (unmask_msi_irq+0x17) >> | +*func -1 unmask_msi_irq+0x9 (default_enable+0x1= a) >=20 > I think to remember a similar issue biting the preempt-rt patch, and > that resulted in some activity to cache that capability information. /m= e > needs to dig into the archives, will let you know if I find something > (tomorrow, likely). Found it. Could you give this patch a try and report the result? http://permalink.gmane.org/gmane.linux.kernel/682362 If it's ok, I guess we should include it in ipipe until someone (From -rt) manages to get it accepted upstream (I didn't recall much activity in this direction yet, though). Jan --------------enigEF9E5AB2F51C402020911ED9 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 iEYEARECAAYFAkij0g8ACgkQniDOoMHTA+mamQCcDZubT6cCpKdmM5+70VqzwajQ qMEAn2Cb396xUMdvH7i2gDF0VBgnkMaj =SW7d -----END PGP SIGNATURE----- --------------enigEF9E5AB2F51C402020911ED9--