headers
hinko.kocevar-oztQky9TsV0CZtS6sZ44uQ@public.gmane.org | 13 Nov 2006 12:29
Picon
Favicon

Re: IrDA speed

Hello,

I've been very busy last few days, so I didn't manage to test the things
you wrote before. Her goes.

Alan J. McFarlane wrote:
> 
> Has all the testing been done with one machine alone as the IrDA Primary 
> (i.e. the machine that did the IrDA discovery and started the 
> connection)?  That's what the traces you've included appear to show. 
> That could be the cause of the asymmetric behaviour that you're seeing. 
> Hopefully this wouldn't be too hard for you to verify.

I've additionally tested both cases: Where each machine takes primary
role once, and the other is the only one as secondary.
What happens is next:
1) When MCS7780 is acting as primary (sends SNRM) and SMSC-IIRC2 acts as 
secondary (responds with UA), transferring file from primary to 
secondary is very,very slow (few kBs). Here primary acts as sender and 
sends the data in cmd packets for secondary to receive.
Transfering file from secondary to the primary is approx. ten times 
faster (about ~40 - 70 kBs). Here primary is receiving data in rsp 
packets from secondary.

2) When SMSC-IIR2 is acting primary (sends SNRM) and MCS7780 is acting 
as secondary (responds with UA), transferring files from primary to 
secondary is very,very fast (~330kBs)! Here primary is acting as sender 
and sends the data to the secondary in cmd packets for secondary to receive.
Transferring file from secondary to the primary is as slow as in case 
1), where MCS7780 as primary sends the data to the SMSC-IIRC2 as
(Continue reading)

Permalink | Reply | 1 comment |
headers
hinko.kocevar-oztQky9TsV0CZtS6sZ44uQ@public.gmane.org | 13 Nov 2006 13:27
Picon
Favicon

Re: IrDA speed

Alan J. McFarlane wrote:
> I note that there are two instances where the inter frame gap is 0.8s.
> Not in quite the same range of Minimum Turnaround Time! :-)  800 times
> bigger in fact.  What's the Maximum Turnaround Time value in effect?

In prior tests max_turn_time was set to 500ms on both stations. Now I've 
changed irlap.c to accept user defined max_turn_time. Ethereal dump 
shows max_turn_time that station supports ranges from 500ms - 100ms. 
Changing this on MCS7780 machine didn't change a bit. While modifying 
this on SMSC-IIR2 machine it somewhat increased transmission speed from 
few KBs to steady ~30 kBs. I've also put the irdadump packets from 
ethereal to the site:
  http://www.cetrtapot.si/irda/irdadump3
  http://www.cetrtapot.si/irda/irdadump3.txt

What can be seen in the dump is:
  - MCS7780 station in SECONDARY role
  - SMSC-IIR2 station in PRIMARY role
  - modified max_turn_time makes link more responsive, still transfer 
hiccups occur making it reach max ~30 kBs.
  - transfer from secondary to primary station (100k) starts at packet 
157 - 521
  - delay around RR packet is lowered from ~0.5s to 0.09 s

As this looks like improved link, I'm still not happy with the transfer 
speed in this direction. Speed in other direction can reach 350kBs and I 
would sure like to see the same speed in this direction too!

Thanx,
(Continue reading)

Permalink | Reply | 0 comments |
headers
hinko.kocevar-oztQky9TsV0CZtS6sZ44uQ@public.gmane.org | 13 Nov 2006 13:29
Picon
Favicon

Re: IrDA speed

hinko.kocevar <at> cetrtapot.si wrote:
> I've also put irdadump log file on the net for you to see transfer 
> timing and similar.
> TXT ethereal log:
>   https://private.cetrtapot.si/izmenjava/hinko/irdadump1.txt
>   https://private.cetrtapot.si/izmenjava/hinko/irdadump2.txt
> libcap ethereal log:
>   https://private.cetrtapot.si/izmenjava/hinko/irdadump1
>   https://private.cetrtapot.si/izmenjava/hinko/irdadump2
> 

Please download irdadumps mentioned above from address below instead 
(I've forgotten that out https site requires user/pass):

http://www.cetrtapot.si/irda/

Thanx,
hinko

--

-- 
ČETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenija
Tel. +386 (0) 4 280 66 37
E-mail: hinko.kocevar <at> cetrtapot.si
Http: www.cetrtapot.si

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sascha Sommer | 14 Nov 2006 22:56
Picon
Favicon

Ooops in irlmp_add_discovery

Hi,

I discovered an oops whenever I move my Samsung SGV-V200 handy to close to my 
laptop. When I enabled debugging I found the following in dmesg:

irlap_state_reply(), QUERY_TIMER_EXPIRED <23518>
Assertion failed! net/irda/irlap.c:irlap_discovery_indication:605 discovery != 
NULL
Assertion failed! net/irda/irlap.c:irlap_discovery_indication:605 discovery != 
NULL
Assertion failed! net/irda/irlap.c:irlap_discovery_indication:605 discovery != 
NULL
Assertion failed! net/irda/irlap.c:irlap_discovery_indication:605 discovery != 
NULL
Assertion failed! net/irda/irlap.c:irlap_discovery_indication:605 discovery != 
NULL
Assertion failed! net/irda/irlap.c:irlap_discovery_indication:605 discovery != 
NULL
Assertion failed! net/irda/irlap.c:irlap_discovery_indication:605 discovery != 
NULL
Assertion failed! net/irda/irlap.c:irlap_discovery_indication:605 discovery != 
NULL

What else do you need to fix this issue? Kernel version is 2.6.18.1

Regards

Sascha

-------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
hinko.kocevar-oztQky9TsV0CZtS6sZ44uQ@public.gmane.org | 17 Nov 2006 09:21
Picon
Favicon

Fast RR

Hello,

I've been struggling with two IrDA stations in achieving optimal 
transfer rates between them. Both IRda devices are FIR capable, but one 
has slightly different negotiation parameters then the other. Eg. window 
size is 7 for device1 and 3 for device2.
After negotiation devices agree on different window size parameters 
(which is OK). During transfer though window size and max turn time play 
major role in transfer latency.

device1 as primary station (window_size 3, max_turn 500ms)
device2 as secondary station (window_size 7, max_turn 500ms)

Fast case:
- device1 is sending data
- device2 is receiving data
- transfer speed is ~300kbps

In this case data is transfered with no delay (or very little delay). 
irdadump shows that receiving station (device1) responds with I or RR 
frame every 7th frame.

Slow case:
- device1 is receiving data
- device2 is sending data
- transfer speed is ~3kbps

In this case data is transfered with great latency. irdadump shows that 
primary receiving station responds with I or RR frame every 3th frame. 
The problem is - primary station almost always waits max_turn time for
(Continue reading)

Permalink | Reply | 0 comments |
headers
hinko.kocevar-oztQky9TsV0CZtS6sZ44uQ@public.gmane.org | 17 Nov 2006 09:42
Picon
Favicon

IrLAP, no activity on link!

Hello,

I'm trying to establish ppp link on top of ircomm Irda device. As soon 
as Irda stations are recognized, link is up and running. I can send 
files in both directions (speed is not the problem now, although it 
could be better). Device1 is linux 2.6.15 kernel based device (Moschip 
FIR), while device2 is winCE 4.1 based device (PXA FIR).

This is what device negotiate (from linux device dmesg):
...
This should be my Linux device:
[58329.830000] irlap_param_baud_rate(), baud rate = 0x1ff
[58329.830000] irda_insert_integer(), using 2 bytes
[58329.830000] irda_insert_integer(), pi=0x1, pl=2, pi=511
[58329.830000] irda_insert_integer(), pi=0x82, pl=1, pi=7
[58329.830000] irda_insert_integer(), pi=0x83, pl=1, pi=63
[58329.830000] irda_insert_integer(), pi=0x84, pl=1, pi=127
[58329.830000] irda_insert_integer(), pi=0x85, pl=1, pi=255
[58329.830000] irda_insert_integer(), pi=0x86, pl=1, pi=7
[58329.830000] irda_insert_integer(), pi=0x8, pl=1, pi=7

This should be WinCE device:
[58329.970000] irda_extract_integer(), pi=0x1, pl=2, pi=256
[58329.970000] Requested BAUD_RATE: 0x0100
[58329.970000] Final BAUD_RATE: 0x0100
[58329.970000] irda_extract_integer(), pi=0x82, pl=1, pi=1
[58329.970000] irda_extract_integer(), pi=0x83, pl=1, pi=63
[58329.970000] irda_extract_integer(), pi=0x84, pl=1, pi=1
[58329.970000] irda_extract_integer(), pi=0x85, pl=1, pi=128
[58329.970000] irda_extract_integer(), pi=0x86, pl=1, pi=4
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrey Borzenkov | 18 Nov 2006 14:12
Picon

2.6.19-rc5: lockdep warnings starting irattach


I experimented with SyncCE; after starting IrDA I got this:

Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ip_tables: (C) 2000-2006 Netfilter Core Team

=============================================
[ INFO: possible recursive locking detected ]
2.6.19-rc5-2avb #2
---------------------------------------------
pppd/26425 is trying to acquire lock:
 (&hashbin->hb_spinlock){....}, at: [<dfdea87a>] irlmp_slsap_inuse+0x5a/0x170 
[irda]

but task is already holding lock:
 (&hashbin->hb_spinlock){....}, at: [<dfdea857>] irlmp_slsap_inuse+0x37/0x170 
[irda]

other info that might help us debug this:
1 lock held by pppd/26425:
 #0:  (&hashbin->hb_spinlock){....}, at: [<dfdea857>] 
irlmp_slsap_inuse+0x37/0x170 [irda]

stack backtrace:
 [<c010413c>] dump_trace+0x1cc/0x200
 [<c010418a>] show_trace_log_lvl+0x1a/0x30
 [<c01047f2>] show_trace+0x12/0x20
 [<c01048c9>] dump_stack+0x19/0x20
(Continue reading)

Permalink | Reply | 8 comments |
headers
Andrey Borzenkov | 19 Nov 2006 09:16
Picon

Is ircomm possible with smsc_ircc2?


I have Toshiba Portege 4000, which apparently needs smsc_ircc2 driver. Driver 
seems to load OK:

Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip, 
pre-configuring device.
Activated ALi 1533 ISA bridge port 0x02e8.
Activated ALi 1533 ISA bridge port 0x02f8.
found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
smsc_superio_flat(): IrDA not enabled
smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, mode: 0x02
SMsC IrDA Controller found
 IrCC version 2.0, firport 0x2f8, sirport 0x2e8 dma=3, irq=7
No transceiver found. Defaulting to Fast pin select

and it registers irda0 interface but no /dev/ircomm* ever appears. I need them 
(or at least I /think/ I need them) for SynCE (for installing programs in my 
Pocket LOOX).

What is missing? Do I need additional driver? How can I access ircomm on this 
HW?

TIA

-andrey
Permalink | Reply | 2 comments |
headers
Peter Zijlstra | 20 Nov 2006 10:04
Picon

Re: 2.6.19-rc5: lockdep warnings starting irattach

On Sat, 2006-11-18 at 16:12 +0300, Andrey Borzenkov wrote:

> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.19-rc5-2avb #2
> - ---------------------------------------------
> pppd/26425 is trying to acquire lock:
>  (&hashbin->hb_spinlock){....}, at: [<dfdea87a>] irlmp_slsap_inuse+0x5a/0x170 
> [irda]
> 
> but task is already holding lock:
>  (&hashbin->hb_spinlock){....}, at: [<dfdea857>] irlmp_slsap_inuse+0x37/0x170 
> [irda]
> 
> other info that might help us debug this:
> 1 lock held by pppd/26425:
>  #0:  (&hashbin->hb_spinlock){....}, at: [<dfdea857>] 
> irlmp_slsap_inuse+0x37/0x170 [irda]
> 
> stack backtrace:
>  [<c010413c>] dump_trace+0x1cc/0x200
>  [<c010418a>] show_trace_log_lvl+0x1a/0x30
>  [<c01047f2>] show_trace+0x12/0x20
>  [<c01048c9>] dump_stack+0x19/0x20
>  [<c01346ca>] __lock_acquire+0x8fa/0xc20
>  [<c0134d2d>] lock_acquire+0x5d/0x80
>  [<c02a851c>] _spin_lock+0x2c/0x40
>  [<dfdea87a>] irlmp_slsap_inuse+0x5a/0x170 [irda]
>  [<dfdebab2>] irlmp_open_lsap+0x62/0x180 [irda]
>  [<dfdf35d1>] irttp_open_tsap+0x181/0x230 [irda]
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ingo Molnar | 20 Nov 2006 10:12
Picon
Picon
Favicon

Re: 2.6.19-rc5: lockdep warnings starting irattach


* Peter Zijlstra <a.p.zijlstra <at> chello.nl> wrote:

> The comment at the nesting lock says:
> 
> 	/* Careful for priority inversions here !
> 	 * irlmp->links is never taken while another IrDA
> 	 * spinlock is held, so we are safe. Jean II */
> 
> So, under the assumption the author was right, it just needs a lockdep
> annotation.
> 
> (depends on patches in -mm for spin_lock_irqsave_nested())
> 
> Signed-off-by: Peter Zijlstra <a.p.zijlstra <at> chello.nl>

Acked-by: Ingo Molnar <mingo <at> elte.hu>

	Ingo
Permalink | Reply | 0 comments |

Gmane