headers
Andre Puschmann | 9 Feb 09:15
Picon
Picon
Favicon

PCIe GPIO card

Hi folks,

this question seems a little bit off topic to me too but still I believe
there is no better place to ask.

I am looking for an interface card to connect a single pin of an
external device (output 3.3-5V) to a standard PC or notebook. There is
no parallel or serial port available on those modern PCs so I was
looking for some kind of PCI/PCIe/ExpressCard that would do the job. The
application would just poll the GPIO line.

Could anybody suggest anything that works reliably?

Thanks in advance.

-Andre

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Darcy Watkins | 8 Feb 19:18
Favicon

jffs2 filesystem: possible circular locking dependency detected

Hi,

I turned on some lock validation/debugging options in the kernel to debug some softlockups that occur as
soon as I bring up eth0, but in my initial dmesg output, I see something that doesn't look right in the jffs2 driver.

Anyone seen this?

Regards,

Darcy

----------

# dmesg
[    0.000000] Linux version 3.0.18-rt34 (darcy <at> tr-pentomino) (gcc version 4.4.6 (crosstool-NG 1.12.4) )
#41 PREEMPT RT Wed Feb 8 10:04:00 PST 2012
[    0.000000] prom: fw_arg0=00000000, fw_arg1=00000000, fw_arg2=00000000, fw_arg3=b804000c
[    0.000000] MyLoader: sysp=20021107, boardp=20021103, parts=03110220
[    0.000000] MyLoader: id=11f6:0640, sub_id=11f6:0640
[    0.000000] prom: board=WP543
[    0.000000] prom: ethaddr='00:80:48:6e:ae:d1'
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU revision is: 00019374 (MIPS 24Kc)
[    0.000000] SoC: Atheros AR7130 rev 2
[    0.000000] Clocks: CPU:300.000MHz, DDR:300.000MHz, AHB:150.000MHz, Ref:40.000MHz
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 02000000 @ 00000000 (usable)
[    0.000000] Zone PFN ranges:
[    0.000000]   Normal   0x00000000 -> 0x00002000
[    0.000000] Movable zone start PFN for each node
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sankara Muthukrishnan | 8 Feb 05:56
Picon
Gravatar

Suggesting to include timerfd patch

Steven,

Could you please include the patch that Thomas suggested for the
timerfd hangs in the email thread (link below), if Thomas is fine with
the patch? I did verify that that patch fixed the hangs that I saw on
a panda board (ARM Cortex A9 dual core).

http://marc.info/?l=linux-rt-users&m=132753755612168&w=2

Thanks,
Sankara
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Steven Rostedt | 8 Feb 01:56
Gravatar

[PATCH RT 0/2 v5] preempt-rt/x86: Handle sending signals from do_trap() by gdb

OK, this patch set should be good to go.

Oleg, please take a look at the modifications I made to your patch,
and if you are fine with it, please ack it.

Thomas, this should be the final set (after I get an ack from Oleg)
and hopefully this one can go into -rt.

Thanks!

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 4 comments |
headers
Rex Feany | 7 Feb 21:38
Gravatar

lockdep complaints with 3.2.5+rt11 on OMAP

Is this the right place to report this? Booting 3.2.5+rt11 on an omap3730 gives me this:

[    0.138354] 
[    0.138374] =================================
[    0.138386] [ INFO: inconsistent lock state ]
[    0.138400] 3.2.5-rt11-00002-g7b398a8 #10
[    0.138409] ---------------------------------
[    0.138423] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[    0.138442] swapper/1 [HC1[1]:SC0[0]:HE0:SE1] takes:
[    0.138456]  (rcu_kthread_wq.lock.lock.wait_lock){?.+...}, at: [<c0276810>] rt_spin_lock_slowlock+0x38/0x1e8
[    0.138506] {HARDIRQ-ON-W} state was registered at:
[    0.138518]   [<c00729f0>] mark_lock+0x290/0x600
[    0.138542]   [<c00749c8>] __lock_acquire+0x79c/0x1a34
[    0.138562]   [<c0076278>] lock_acquire+0x114/0x134
[    0.138580]   [<c0277724>] _raw_spin_lock+0x4c/0x5c
[    0.138602]   [<c0276810>] rt_spin_lock_slowlock+0x38/0x1e8
[    0.138621]   [<c0276da0>] rt_spin_lock+0x20/0x50
[    0.138639]   [<c005fab0>] prepare_to_wait+0x30/0x74
[    0.138660]   [<c0083c70>] rcu_kthread+0x74/0x1c4
[    0.138682]   [<c005f500>] kthread+0x8c/0x94
[    0.138698]   [<c0014cd4>] kernel_thread_exit+0x0/0x8
[    0.138719] irq event stamp: 2135
[    0.138729] hardirqs last  enabled at (2134): [<c0073360>] debug_check_no_locks_freed+0x11c/0x148
[    0.138755] hardirqs last disabled at (2135): [<c00137b4>] __irq_svc+0x34/0xa0
[    0.138784] softirqs last  enabled at (0): [<c003e3cc>] copy_process+0x334/0xde0
[    0.138811] softirqs last disabled at (0): [<  (null)>]   (null)
[    0.138828] 
[    0.138832] other info that might help us debug this:
[    0.138844]  Possible unsafe locking scenario:
[    0.138852]
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steven Rostedt | 6 Feb 17:36
Gravatar

Re: preempt-rt: Real Time hogging task

On Mon, 2012-02-06 at 18:29 +0200, Raz wrote:
> Hey Steven
> 
> I found what the problem is. It is **not** a  preempt-rt bug, it is
> because made some modifications to 
> the kernel.

Thanks for letting me know. But next time, please, make sure you can
trigger the bug with an unmodified version of -rt *before* sending a bug
report.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Steven Rostedt | 3 Feb 19:43
Gravatar

[PATCH RT] futex: Fix bug on when a requeued RT task times out


Requeue with timeout causes a bug with PREEMPT_RT_FULL.

The bug comes from a timed out condition.

	TASK 1				TASK 2
	------				------
    futex_wait_requeue_pi()
	futex_wait_queue_me()
	<timed out>

					double_lock_hb();

	raw_spin_lock(pi_lock);
	if (current->pi_blocked_on) { 
	} else {
	    current->pi_blocked_on = PI_WAKE_INPROGRESS;
	    run_spin_unlock(pi_lock);
	    spin_lock(hb->lock); <-- blocked!

					plist_for_each_entry_safe(this) {
					    rt_mutex_start_proxy_lock();
						task_blocks_on_rt_mutex();
						BUG_ON(task->pi_blocked_on)!!!!

The BUG_ON() actually has a check for PI_WAKE_INPROGRESS, but the
problem is that, after TASK 1 sets PI_WAKE_INPROGRESS, it then tries to
grab the hb->lock, which it fails to do so. As the hb->lock is a mutex,
it will block and set the "pi_blocked_on" to the hb->lock.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven Rostedt | 3 Feb 19:28
Gravatar

[PATCH RT 0/2 v4] preempt-rt/x86: Handle sending signals from do_trap() by gdb

Thomas,

Can you apply these to v3.2-rt.

Version 4:
 In testing, Clark Williams triggered a bug in the paranoid_exit return
 path. The %rcx register was being clobbered by a function call and
 needed to be restored with: GET_THREAD_INFO(%rcx)

This version has been tested and so far has triggered no bugs.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 10 comments |
headers
Raz | 2 Feb 11:52
Picon

preempt-rt: Real Time hogging task

hey

I am trying to understand why a user space MT process behaves in an
unexpected manner.
I have real time process, which executes most of its threads in RT priority,
and from time to time a task ( medium priority ) is executing without
trying to stop.

There are times, that this task is hogging the entire process and no
other **higher*** rt priority
task is getting any cpu time.

Linux is **not** getting hogged. when setting the serial console (
irq/serial ) and its shell ( /bin/sh )
to a higher priority linux is responsive.

Observing the task list  through ps command i can see that this task's
threads when
to un-interruptible sleep.

Any idea why is it happening ?
kernel is 3.2.0-rc5-rt8.
raz
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 5 comments |
headers
Hector Palacios | 1 Feb 13:28
Favicon
Gravatar

infinite spin in RT when booting with DHCP on

Hello,

I'm working on a 2.6.31.14 kernel on ARM where I applied the RT PREEMPT patch 
2.6.31.12-rt21.

When booting my platform with DHCP on, the DHCP request is sent by the network driver 
before the PHY has even started the autonegotiation.
Since the PHY is not ready, the TX interrupt returns with NETDEV_TX_BUSY but the 
softirq [sirq-net-tx] seems to have entered an infinite spin, as my system is 
practically hung and 'top' reveals [sirq-net-tx/0] is consuming 95% of CPU. This is 
preventing the PHY autonegotiation (which is scheduled as a delayed work) to start, so 
the PHY is never ready and the packet never reaches the network.

I was wondering if this situation resembles what the patch by Ingo Molnar "tasklet/rt: 
Prevent tasklets from going into infinite spin in RT" describes.

This patch is already in 2.6.31.12-rt21 patch which I'm using so either it is a 
different problem or a corner case of the same issue.

Could anyone tell whether it is the same or a different problem?
Thank you
--

-- 
Héctor Palacios

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 27 comments |
headers
Christian Kapeller | 30 Jan 18:45
Picon
Gravatar

Unreliable Wireless network with 3.0.9-rt26

Hi,

I'm having trouble running wifi in combination with a rt enabled kernel
3.0.9-rt26 on an imx51 arm platform. The distro is openwrt-trunk.

The device has 2 usb wifi interfaces (AR9271 chipset; driver: based on
compat-wireless-testing 2011-12-01). I am running an iperf load on both
interfaces, one interface is in AP mode, the other in STA mode.

When I configure the kernel without RT preemption, the device runs
stable for >10 hours.

With RT preemption enabled, after a couple of minutes some interface
will stop transmitting data. Sometimes ifconfig wlan[0,1] down will
hang, sometimes ifconfig wlan[0,1] down will work, but then ping will

return the following:

# ping 192.168.2.170
PING 192.168.2.170 (192.168.2.170): 56 data bytes
ping: sendto: Operation not permitted

Right after loading the wireless drivers I get the following kernel
warning:

[   36.917065] ------------[ cut here ]------------
[   36.917202] WARNING: at
/home/chrkap/Development/cworld/openwrt/build_dir/linux-cmotion_generic/compat-wireless-2011-12-01/net/mac80211/rx.c:3011
ieee80211_rx+0x34/0xb2c [mac80211]()
[   36.917222] Modules linked in: mmc_spi gpio_buttons ath9k_htc xt_HL xt_hl ipt_ECN xt_CLASSIFY xt_time
(Continue reading)

Permalink | Reply | 5 comments |

Gmane