From: andrzej z. <ba...@gm...> - 2006-09-11 13:37:38
Attachments:
linux-stir4200.patch
|
Hi, I have a stir 4200 dongle which doesn't work with the driver from the kernel. The chip does have a SigmaTel logo on it and looks genuine. Infrared data seems to be received correctly but nothing meaningfull is being emitted. It turns out that the FIFOCTL register always has the RXERR bit set when the driver reads it so the loop in fifo_txwait() exits immediately and no delay between TX bytes occurs, so the data comes out all garbled. I made a small change in the loop to make it keep waiting despite RXERR or TXERR and IrDA frames can now be sent and received correctly. The errors are still reported, they just don't interrupt the loop. If you have a stir4200 that doesn't seem to work under Linux, please try the attached patch. Maybe if it fixes the problem for more persons, something like it should be merged. Regards, Andrew -- balrog 2oo6 |
From: surfzoid s. <sur...@ho...> - 2006-09-11 16:57:28
|
i have the same dongle STIR 4200 and post a problem with it with subject "*** buffer overflow detected ***: irdadump terminated", if it s necessary i can post it again, but i say it again i m complety newbie in linux world, so this patch is a solution for my probleme ? How can i use this patch to correct my probleme ? Should have to recompile all my kernel ? thanks >From: "andrzej zaborowski" <ba...@gm...> >To: ird...@li... >Subject: [irda-users] Workaround for a bad stir4200 >Date: Mon, 11 Sep 2006 15:37:32 +0200 > >Hi, >I have a stir 4200 dongle which doesn't work with the driver from the >kernel. The chip does have a SigmaTel logo on it and looks genuine. >Infrared data seems to be received correctly but nothing meaningfull >is being emitted. It turns out that the FIFOCTL register always has >the RXERR bit set when the driver reads it so the loop in >fifo_txwait() exits immediately and no delay between TX bytes occurs, >so the data comes out all garbled. I made a small change in the loop >to make it keep waiting despite RXERR or TXERR and IrDA frames can now >be sent and received correctly. The errors are still reported, they >just don't interrupt the loop. > >If you have a stir4200 that doesn't seem to work under Linux, please >try the attached patch. Maybe if it fixes the problem for more >persons, something like it should be merged. > >Regards, >Andrew >-- >balrog 2oo6 ><< linux-stir4200.patch >> >------------------------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job >easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >_______________________________________________ >irda-users mailing list >ird...@li... >http://lists.sourceforge.net/lists/listinfo/irda-users _________________________________________________________________ Retrouvez tout en un clin d'oeil avec la barre d'outil MSN Search ! http://desktop.msn.fr/ |
From: andrzej z. <ba...@za...> - 2006-09-11 17:52:57
|
On 11/09/06, surfzoid surfzoid <sur...@ho...> wrote: > i have the same dongle STIR 4200 and post a problem with it with subject > "*** buffer overflow detected ***: irdadump terminated", if it s necessary i > can post it again, but i say it again i m complety newbie in linux world, so > this patch is a solution for my probleme ? No, I don't think so. I would guess your problem is in userspace, maybe unrelated to STIR 4200. To be honest, I also feel lost in the userspace part of Linux irda. > How can i use this patch to correct my probleme ? > Should have to recompile all my kernel ? > thanks > > > >From: "andrzej zaborowski" <ba...@gm...> > >To: ird...@li... > >Subject: [irda-users] Workaround for a bad stir4200 > >Date: Mon, 11 Sep 2006 15:37:32 +0200 > > > >Hi, > >I have a stir 4200 dongle which doesn't work with the driver from the > >kernel. The chip does have a SigmaTel logo on it and looks genuine. > >Infrared data seems to be received correctly but nothing meaningfull > >is being emitted. It turns out that the FIFOCTL register always has > >the RXERR bit set when the driver reads it so the loop in > >fifo_txwait() exits immediately and no delay between TX bytes occurs, > >so the data comes out all garbled. I made a small change in the loop > >to make it keep waiting despite RXERR or TXERR and IrDA frames can now > >be sent and received correctly. The errors are still reported, they > >just don't interrupt the loop. > > > >If you have a stir4200 that doesn't seem to work under Linux, please > >try the attached patch. Maybe if it fixes the problem for more > >persons, something like it should be merged. > > > >Regards, > >Andrew > >-- > >balrog 2oo6 > > > ><< linux-stir4200.patch >> > > > >------------------------------------------------------------------------- > >Using Tomcat but need to do more? Need to support web services, security? > >Get stuff done quickly with pre-integrated technology to make your job > >easier > >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > >_______________________________________________ > >irda-users mailing list > >ird...@li... > >http://lists.sourceforge.net/lists/listinfo/irda-users > > _________________________________________________________________ > Retrouvez tout en un clin d'oeil avec la barre d'outil MSN Search ! > http://desktop.msn.fr/ > > -- balrog 2oo6 Dear Outlook users: Please remove me from your address books http://www.newsforge.com/article.pl?sid=03/08/21/143258 |
From: surfzoid s. <sur...@ho...> - 2006-09-11 18:37:15
|
I am complety loose, what is the difference beetwen user space and ird...@li.... Can you help me with my probleme ? i put a copy of my posrt for the problem : [irda-users] *** buffer overflow detected ***: irdadump terminated hi first of all i m a poor frenchi and so my english is poor to, so sory by advance. There 1 or two YEAR i try to get my picture on my phone with my linux distrib (mandriva 2006 and the last Kubuntu) whit a STIR4200 usb dongle. My phone is a mitsubichi M341i with MT170 Modem and obex capability. I try so many soft to communicate with my phone and finaly the two best was Wammu/gammu but only AT command works great, Kbeam work wonderfull to get/put file with my memory phone but as the same as windoze it s one by one and directly with the phone software. So i try to use obexftp, first with command line only and one time not succesfull : I have good connection to my phone (kbeam icon was blue) and ability to put file on my phone with the cmd : obexftp -i -p myfile.test i see in the irdadump debug windows evrything is good, but when i try, the more important for me, to list the directory with : obexftp -i -l / irdadump write a "*** buffer overflow detected ***: irdadump terminated" Complete debug here : 19:18:04.165483 xid:rsp 51b83f65 < 3604993f S=6 s=4 MT170 hint=9024 [ Modem IrCOMM IrOBEX ] (22) 19:18:04.183005 xid:cmd 51b83f65 > ffffffff S=6 s=5 (14) 19:18:04.282992 xid:cmd 51b83f65 > ffffffff S=6 s=* surfzoid-PC hint=c420 [ Computer LAN Access IrOBEX ] (28) 19:18:04.703088 snrm:cmd ca=fe pf=1 51b83f65 > 3604993f new-ca=f2 LAP QoS: Baud Rate=19200bps Max Turn Time=500ms Data Size=2048B Window Size=7 Add BOFS=0 Min Turn Time=10us Link Disc=12s (32) 19:18:04.811380 ua:rsp ca=f2 pf=1 51b83f65 < 3604993f LAP QoS: Baud Rate=19200bps Max Turn Time=500ms Data Size=256B Window Size=1 Add BOFS=0 Min Turn Time=10000us Link Disc=12s (31) 19:18:04.811914 rr:cmd > ca=f2 pf=1 nr=0 (2) 19:18:04.846372 rr:rsp < ca=f2 pf=1 nr=0 (2) 19:18:04.846398 i:cmd > ca=f2 pf=1 nr=0 ns=0 LM slsap=2d dlsap=00 CONN_CMD (6) 19:18:04.876368 i:rsp < ca=f2 pf=1 nr=1 ns=0 LM slsap=00 dlsap=2d CONN_RSP (6) 19:18:04.876399 i:cmd > ca=f2 pf=1 nr=1 ns=1 LM slsap=2d dlsap=00 GET_VALUE_BY_CLASS: "OBEX" "IrDA:TinyTP:LsapSel" (30) 19:18:04.922362 i:rsp < ca=f2 pf=1 nr=2 ns=1 LM slsap=00 dlsap=2d GET_VALUE_BY_CLASS: Success Integer: 05 (15) 19:18:04.922404 i:cmd > ca=f2 pf=1 nr=2 ns=2 LM slsap=2d dlsap=00 DISC (6) 19:18:04.952354 rr:rsp < ca=f2 pf=1 nr=3 (2) 19:18:04.952389 i:cmd > ca=f2 pf=1 nr=2 ns=3 LM slsap=2e dlsap=05 CONN_CMD TTP credits=16 (7) 19:18:04.982350 i:rsp < ca=f2 pf=1 nr=4 ns=2 LM slsap=05 dlsap=2e CONN_RSP TTP credits=1 (7) 19:18:04.982380 rr:cmd > ca=f2 pf=1 nr=3 (2) 19:18:05.007349 rr:rsp < ca=f2 pf=1 nr=4 (2) 19:18:05.007381 i:cmd > ca=f2 pf=1 nr=3 ns=4 LM slsap=2e dlsap=05 TTP credits=0 OBEX CONNECT len=26 (31) *** buffer overflow detected ***: irdadump terminated ======= Backtrace: ========= /lib/i686/libc.so.6(__chk_fail+0x41)[0xb7eb6c41] irdadump[0x804c8be] irdadump[0x804d1d1] irdadump[0x804c282] irdadump[0x804ab05] irdadump[0x804b81d] irdadump[0x8048f86] /lib/i686/libc.so.6(__libc_start_main+0xdc)[0xb7dee75c] irdadump[0x8048b11] ======= Memory map: ======== 08048000-08050000 r-xp 00000000 08:07 784704 /usr/bin/irdadump 08050000-08051000 rw-p 00007000 08:07 784704 /usr/bin/irdadump 08051000-08072000 rw-p 08051000 00:00 0 [heap] b7d83000-b7d8d000 r-xp 00000000 08:07 1974804 /lib/libgcc_s-4.0.1.so.1 b7d8d000-b7d8e000 rw-p 00009000 08:07 1974804 /lib/libgcc_s-4.0.1.so.1 b7dbb000-b7dbd000 rw-p b7dbb000 00:00 0 b7dbd000-b7dcc000 r-xp 00000000 08:07 1980802 /lib/i686/libpthread-2.4.so b7dcc000-b7dce000 rw-p 0000e000 08:07 1980802 /lib/i686/libpthread-2.4.so b7dce000-b7dd0000 rw-p b7dce000 00:00 0 b7dd0000-b7dd7000 r-xp 00000000 08:07 1980803 /lib/i686/librt-2.4.so b7dd7000-b7dd9000 rw-p 00006000 08:07 1980803 /lib/i686/librt-2.4.so b7dd9000-b7f00000 r-xp 00000000 08:07 1981262 /lib/i686/libc-2.4.so b7f00000-b7f01000 r--p 00126000 08:07 1981262 /lib/i686/libc-2.4.so b7f01000-b7f03000 rw-p 00127000 08:07 1981262 /lib/i686/libc-2.4.so b7f03000-b7f06000 rw-p b7f03000 00:00 0 b7f06000-b7fa1000 r-xp 00000000 08:07 783488 /usr/lib/libglib-2.0.so.0.1200.3 b7fa1000-b7fa2000 rw-p 0009b000 08:07 783488 /usr/lib/libglib-2.0.so.0.1200.3 b7fce000-b7fd0000 rw-p b7fce000 00:00 0 b7fd0000-b7fe8000 r-xp 00000000 08:07 1974731 /lib/ld-2.4.so b7fe8000-b7fe9000 r--p 00017000 08:07 1974731 /lib/ld-2.4.so b7fe9000-b7fea000 rw-p 00018000 08:07 1974731 /lib/ld-2.4.so bfdd3000-bfde8000 rw-p bfdd3000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Abandon [root@surfzoid-PC obextool]# I find on the web my phone have not a standart AT command to put it in connect mode, it use AT+CPROT=0 but kbeam work with obex and it was good so it s a little "mysterioius" lol >From: "andrzej zaborowski" <ba...@za...> >Reply-To: ba...@gm... >To: "surfzoid surfzoid" <sur...@ho...> >CC: ird...@li... >Subject: Re: [irda-users] Workaround for a bad stir4200 >Date: Mon, 11 Sep 2006 19:52:55 +0200 > >On 11/09/06, surfzoid surfzoid <sur...@ho...> wrote: >>i have the same dongle STIR 4200 and post a problem with it with subject >>"*** buffer overflow detected ***: irdadump terminated", if it s necessary >>i >>can post it again, but i say it again i m complety newbie in linux world, >>so >>this patch is a solution for my probleme ? > >No, I don't think so. I would guess your problem is in userspace, >maybe unrelated to STIR 4200. > >To be honest, I also feel lost in the userspace part of Linux irda. > >>How can i use this patch to correct my probleme ? >>Should have to recompile all my kernel ? >>thanks >> >> >> >From: "andrzej zaborowski" <ba...@gm...> >> >To: ird...@li... >> >Subject: [irda-users] Workaround for a bad stir4200 >> >Date: Mon, 11 Sep 2006 15:37:32 +0200 >> > >> >Hi, >> >I have a stir 4200 dongle which doesn't work with the driver from the >> >kernel. The chip does have a SigmaTel logo on it and looks genuine. >> >Infrared data seems to be received correctly but nothing meaningfull >> >is being emitted. It turns out that the FIFOCTL register always has >> >the RXERR bit set when the driver reads it so the loop in >> >fifo_txwait() exits immediately and no delay between TX bytes occurs, >> >so the data comes out all garbled. I made a small change in the loop >> >to make it keep waiting despite RXERR or TXERR and IrDA frames can now >> >be sent and received correctly. The errors are still reported, they >> >just don't interrupt the loop. >> > >> >If you have a stir4200 that doesn't seem to work under Linux, please >> >try the attached patch. Maybe if it fixes the problem for more >> >persons, something like it should be merged. >> > >> >Regards, >> >Andrew >> >-- >> >balrog 2oo6 >> >> >> ><< linux-stir4200.patch >> >> >> >> >------------------------------------------------------------------------- >> >Using Tomcat but need to do more? Need to support web services, >>security? >> >Get stuff done quickly with pre-integrated technology to make your job >> >easier >> >Download IBM WebSphere Application Server v.1.0.1 based on Apache >>Geronimo >> >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >> >> >> >_______________________________________________ >> >irda-users mailing list >> >ird...@li... >> >http://lists.sourceforge.net/lists/listinfo/irda-users >> >>_________________________________________________________________ >>Retrouvez tout en un clin d'oeil avec la barre d'outil MSN Search ! >>http://desktop.msn.fr/ >> >> > > >-- >balrog 2oo6 > >Dear Outlook users: Please remove me from your address books >http://www.newsforge.com/article.pl?sid=03/08/21/143258 _________________________________________________________________ Retrouvez tout en un clin d'il avec Windows Desktop Search ! http://desktop.msn.fr/ |
From: Samuel O. <sa...@so...> - 2006-09-14 21:26:02
|
Hi Andrzej, On Mon, Sep 11, 2006 at 03:37:32PM +0200, andrzej zaborowski wrote: > Hi, > I have a stir 4200 dongle which doesn't work with the driver from the > kernel. The chip does have a SigmaTel logo on it and looks genuine. > Infrared data seems to be received correctly but nothing meaningfull > is being emitted. It turns out that the FIFOCTL register always has > the RXERR bit set when the driver reads it so the loop in > fifo_txwait() exits immediately and no delay between TX bytes occurs, > so the data comes out all garbled. I made a small change in the loop > to make it keep waiting despite RXERR or TXERR and IrDA frames can now > be sent and received correctly. The errors are still reported, they > just don't interrupt the loop. I was reading the only stir4200 spec file that I have, and it seems that bits 0 and 1 from FIFOCTL are reserved, we shouldn't care about them. I'm actually considering removing those checks from the driver, but first I'd like to hear from the maintainers (Paul, Stephen, Jean). They may explain us why this check on some reserved and undocumented bits is done. Cheers, Samuel. |
From: andrzej z. <ba...@za...> - 2006-09-15 00:22:33
|
On 15/09/06, Samuel Ortiz <sa...@so...> wrote: > Hi Andrzej, > > On Mon, Sep 11, 2006 at 03:37:32PM +0200, andrzej zaborowski wrote: > > Hi, > > I have a stir 4200 dongle which doesn't work with the driver from the > > kernel. The chip does have a SigmaTel logo on it and looks genuine. > > Infrared data seems to be received correctly but nothing meaningfull > > is being emitted. It turns out that the FIFOCTL register always has > > the RXERR bit set when the driver reads it so the loop in > > fifo_txwait() exits immediately and no delay between TX bytes occurs, > > so the data comes out all garbled. I made a small change in the loop > > to make it keep waiting despite RXERR or TXERR and IrDA frames can now > > be sent and received correctly. The errors are still reported, they > > just don't interrupt the loop. > I was reading the only stir4200 spec file that I have, and it seems that > bits 0 and 1 from FIFOCTL are reserved, we shouldn't care about them. > I'm actually considering removing those checks from the driver, but first I'd > like to hear from the maintainers (Paul, Stephen, Jean). They may explain > us why this check on some reserved and undocumented bits is done. Ah, cool. So my dongle complies with the specification. Thanks for checking this, I was almost sure there wouldn't be any specification availiable so I didn't bother to look for it :-) Instead I tried "spying" on a closed-source driver I had, which didn't help much. The closed-source driver does more or less the same usb requests except it sets the "magic" REG_DPLL value to 08 instead of 15. > > Cheers, > Samuel. > Regards, -- balrog 2oo6 |
From: Stephen H. <she...@os...> - 2006-09-15 00:19:53
|
On Fri, 15 Sep 2006 07:40:20 +0300 Samuel Ortiz <sa...@so...> wrote: > Hi Andrzej, > > On Mon, Sep 11, 2006 at 03:37:32PM +0200, andrzej zaborowski wrote: > > Hi, > > I have a stir 4200 dongle which doesn't work with the driver from the > > kernel. The chip does have a SigmaTel logo on it and looks genuine. > > Infrared data seems to be received correctly but nothing meaningfull > > is being emitted. It turns out that the FIFOCTL register always has > > the RXERR bit set when the driver reads it so the loop in > > fifo_txwait() exits immediately and no delay between TX bytes occurs, > > so the data comes out all garbled. I made a small change in the loop > > to make it keep waiting despite RXERR or TXERR and IrDA frames can now > > be sent and received correctly. The errors are still reported, they > > just don't interrupt the loop. > I was reading the only stir4200 spec file that I have, and it seems that > bits 0 and 1 from FIFOCTL are reserved, we shouldn't care about them. > I'm actually considering removing those checks from the driver, but first I'd > like to hear from the maintainers (Paul, Stephen, Jean). They may explain > us why this check on some reserved and undocumented bits is done. > > Cheers, > Samuel. Different versions of the spec (and probably chip) had them. Go ahead, I wrote the driver and haven't used it in over 3years! |