From: David F. <dav...@ya...> - 2005-02-20 03:05:51
|
Craig, I read you grrr comment in svn. One thing bothering me about this routine. Even though a spin_lock_irqsave surrounds the serial_in, it does nothing to prevent resetting the MSR flags than occcurs when the MSR register is read. I think the MSR should be read by the isr and stored, the location it is stored in should be protected by the spinlock. The LSR has similiar side effects. What do you think? David. |
From: David F. <dav...@ya...> - 2005-02-21 01:49:29
|
Ok, I saved the lsr and msr values in the isr routines to variables I added to the uart_pxa_port structure. I replaced the serial_in() where these values are read. I initialized the values in serial_pxa_startup(). No more serial errors, even at 921600! I tested this for 5+ hours. Now I am enabling additional bluetooth stuff in stages to see what else may break. Currently pinging my bluetooth bridge via bnep0, I'll see how long this lives. David. --- David Farrell <dav...@ya...> wrote: > Craig, > I read you grrr comment in svn. One thing > bothering me about this routine. Even though a > spin_lock_irqsave surrounds the serial_in, it > does nothing to prevent resetting the MSR flags > than occcurs when the MSR register is read. I > think the MSR should be read by the isr and > stored, the location it is stored in should be > protected by the spinlock. > > The LSR has similiar side effects. > > What do you think? > > David. > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the > hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Benny S. <ben...@ma...> - 2005-02-21 09:32:10
|
Hi David Great news. I have just received two BT enabled Gumstix boards and Im not able to use BT to anything usable because the link dies almost instantly. Could you send a patch with your changes? By the way, have you changed the BT serial back to use the BTUART again instead of the HWUART? Thanks Benny ----- Original Message ----- From: "David Farrell" <dav...@ya...> To: <gum...@li...> Sent: Monday, February 21, 2005 2:49 AM Subject: Re: [Gumstix-users] serial_pxa_get_mctrl > Ok, I saved the lsr and msr values in the isr > routines to variables I added to the > uart_pxa_port structure. I replaced the > serial_in() where these values are read. I > initialized the values in serial_pxa_startup(). > > No more serial errors, even at 921600! > > I tested this for 5+ hours. Now I am enabling > additional bluetooth stuff in stages to see what > else may break. Currently pinging my bluetooth > bridge via bnep0, I'll see how long this lives. > > David. > > --- David Farrell <dav...@ya...> wrote: > >> Craig, >> I read you grrr comment in svn. One thing >> bothering me about this routine. Even though a >> spin_lock_irqsave surrounds the serial_in, it >> does nothing to prevent resetting the MSR flags >> than occcurs when the MSR register is read. I >> think the MSR should be read by the isr and >> stored, the location it is stored in should be >> protected by the spinlock. >> >> The LSR has similiar side effects. >> >> What do you think? >> >> David. >> >> >> >> > ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT >> Products from real users. >> Discover which products truly live up to the >> hype. Start reading now. >> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: David F. <dav...@ya...> - 2005-02-21 14:42:10
|
Benny, I am being very conservative about testing this. My icmp ping test ran overnight. I enabled some more of the bluetooth options. I'll test more today. It is best if Craig confirms the results and manages the patches. There are several additional things I want to change and I want to hear from him first. I did try it with the BTUART and no serial errors, but I switched back to HWUART. During the course of the test I want to change as little as possible. I think there maybe additional issues with bluetooth. Although my iPAQ now shows the gumsix with serial capabilities and allows a connetion (it never did before). When my Linksys USBBT100 is plugged into my XP machine, the gumstix bt stack complains. Even though the stack compained, it kept running and no serial errors. David. --- Benny Simonsen <ben...@ma...> wrote: > Hi David > > Great news. > I have just received two BT enabled Gumstix > boards and Im not able to use BT > to anything usable because the link dies almost > instantly. > Could you send a patch with your changes? > > By the way, have you changed the BT serial back > to use the BTUART again > instead of the HWUART? > > Thanks > Benny > > > ----- Original Message ----- > From: "David Farrell" <dav...@ya...> > To: <gum...@li...> > Sent: Monday, February 21, 2005 2:49 AM > Subject: Re: [Gumstix-users] > serial_pxa_get_mctrl > > > > Ok, I saved the lsr and msr values in the isr > > routines to variables I added to the > > uart_pxa_port structure. I replaced the > > serial_in() where these values are read. I > > initialized the values in > serial_pxa_startup(). > > > > No more serial errors, even at 921600! > > > > I tested this for 5+ hours. Now I am enabling > > additional bluetooth stuff in stages to see > what > > else may break. Currently pinging my > bluetooth > > bridge via bnep0, I'll see how long this > lives. > > > > David. > > > > --- David Farrell <dav...@ya...> > wrote: > > > >> Craig, > >> I read you grrr comment in svn. One thing > >> bothering me about this routine. Even > though a > >> spin_lock_irqsave surrounds the serial_in, > it > >> does nothing to prevent resetting the MSR > flags > >> than occcurs when the MSR register is read. > I > >> think the MSR should be read by the isr and > >> stored, the location it is stored in should > be > >> protected by the spinlock. > >> > >> The LSR has similiar side effects. > >> > >> What do you think? > >> > >> David. > >> > >> > >> > >> > > > ------------------------------------------------------- > >> SF email is sponsored by - The IT Product > Guide > >> Read honest & candid reviews on hundreds of > IT > >> Products from real users. > >> Discover which products truly live up to the > >> hype. Start reading now. > >> > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >> > _______________________________________________ > >> gumstix-users mailing list > >> gum...@li... > >> > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > >> > > > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product > Guide > > Read honest & candid reviews on hundreds of > IT Products from real users. > > Discover which products truly live up to the > hype. Start reading now. > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the > hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@hu...> - 2005-02-21 19:48:39
|
On Feb 21, 2005, at 6:42 AM, David Farrell wrote: > It is best if Craig confirms the results and > manages the patches. There are several additional > things I want to change and I want to hear from > him first. Dave, sounds like a great approach :) Want to send me the patch to test here at HQ? Thanks C |
From: David F. <dav...@ya...> - 2005-02-21 18:58:33
|
Further tests: I have ssh session open over bnep0 to the gumstix and have been pinging out the bnep0 to my home router. I use ping -s 1024 to get large packets. 15 TX MB amd 32 RX MB later all is still running without error. At the same time the ping is running I can open a web page on the gumstix and a second ssh session. No dmesg messages, only "gumstix kern.err getty: m" messages in /var/log/messages. David. --- David Farrell <dav...@ya...> wrote: > Ok, I saved the lsr and msr values in the isr > routines to variables I added to the > uart_pxa_port structure. I replaced the > serial_in() where these values are read. I > initialized the values in serial_pxa_startup(). > > No more serial errors, even at 921600! > > I tested this for 5+ hours. Now I am enabling > additional bluetooth stuff in stages to see > what > else may break. Currently pinging my bluetooth > bridge via bnep0, I'll see how long this lives. > > David. > > --- David Farrell <dav...@ya...> > wrote: > > > Craig, > > I read you grrr comment in svn. One thing > > bothering me about this routine. Even though > a > > spin_lock_irqsave surrounds the serial_in, it > > does nothing to prevent resetting the MSR > flags > > than occcurs when the MSR register is read. I > > think the MSR should be read by the isr and > > stored, the location it is stored in should > be > > protected by the spinlock. > > > > The LSR has similiar side effects. > > > > What do you think? > > > > David. > > > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product > Guide > > Read honest & candid reviews on hundreds of > IT > > Products from real users. > > Discover which products truly live up to the > > hype. Start reading now. > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the > hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@hu...> - 2005-02-21 19:52:06
|
Dave, I added some OBEX stuff to the buildroot late last week, which lets you do big file transfers over OBEX. Actually, I've sent files to the gumstix from my phone and powerbook, but not the other way round. Also, better than large pings (or next step after large pings are working) is to just jam as much data as will fit on the link through in both directions -- for that I set up a getty on rfcomm0 then connect in and send/receive over the link using sz/rz -- when using HWUART I can send and receive from /dev/urandom at 60-70kBps, which is pretty well maxing out the radio link. C On Feb 21, 2005, at 10:58 AM, David Farrell wrote: > Further tests: > > I have ssh session open over bnep0 to the gumstix > and have been pinging out the bnep0 to my home > router. I use ping -s 1024 to get large packets. > 15 TX MB amd 32 RX MB later all is still running > without error. At the same time the ping is > running I can open a web page on the gumstix and > a second ssh session. No dmesg messages, only > "gumstix kern.err getty: m" messages in > /var/log/messages. > > David. > > > > --- David Farrell <dav...@ya...> wrote: > >> Ok, I saved the lsr and msr values in the isr >> routines to variables I added to the >> uart_pxa_port structure. I replaced the >> serial_in() where these values are read. I >> initialized the values in serial_pxa_startup(). >> >> No more serial errors, even at 921600! >> >> I tested this for 5+ hours. Now I am enabling >> additional bluetooth stuff in stages to see >> what >> else may break. Currently pinging my bluetooth >> bridge via bnep0, I'll see how long this lives. >> >> David. >> >> --- David Farrell <dav...@ya...> >> wrote: >> >>> Craig, >>> I read you grrr comment in svn. One thing >>> bothering me about this routine. Even though >> a >>> spin_lock_irqsave surrounds the serial_in, it >>> does nothing to prevent resetting the MSR >> flags >>> than occcurs when the MSR register is read. I >>> think the MSR should be read by the isr and >>> stored, the location it is stored in should >> be >>> protected by the spinlock. >>> >>> The LSR has similiar side effects. >>> >>> What do you think? >>> >>> David. >>> >>> >>> >>> >> > ------------------------------------------------------- >>> SF email is sponsored by - The IT Product >> Guide >>> Read honest & candid reviews on hundreds of >> IT >>> Products from real users. >>> Discover which products truly live up to the >>> hype. Start reading now. >>> >> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>> >> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >> >> >> >> > ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT >> Products from real users. >> Discover which products truly live up to the >> hype. Start reading now. >> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Christopher Vo <chr...@gm...> - 2005-02-21 20:54:09
|
We have a bnep0 running on our test gumstix doing good for well over 48 hours at moderate load... 200 MB RX and 500 MB TX so far running without error. No error exccept the getty: m stuff like David's getting - what's that? -- Christopher Vo (chr...@gm...) David Farrell wrote: >Further tests: > >I have ssh session open over bnep0 to the gumstix >and have been pinging out the bnep0 to my home >router. I use ping -s 1024 to get large packets. >15 TX MB amd 32 RX MB later all is still running >without error. At the same time the ping is >running I can open a web page on the gumstix and >a second ssh session. No dmesg messages, only >"gumstix kern.err getty: m" messages in >/var/log/messages. > >David. > > > >--- David Farrell <dav...@ya...> wrote: > > > >>Ok, I saved the lsr and msr values in the isr >>routines to variables I added to the >>uart_pxa_port structure. I replaced the >>serial_in() where these values are read. I >>initialized the values in serial_pxa_startup(). >> >>No more serial errors, even at 921600! >> >>I tested this for 5+ hours. Now I am enabling >>additional bluetooth stuff in stages to see >>what >>else may break. Currently pinging my bluetooth >>bridge via bnep0, I'll see how long this lives. >> >>David. >> >>--- David Farrell <dav...@ya...> >>wrote: >> >> >> >>>Craig, >>>I read you grrr comment in svn. One thing >>>bothering me about this routine. Even though >>> >>> >>a >> >> >>>spin_lock_irqsave surrounds the serial_in, it >>>does nothing to prevent resetting the MSR >>> >>> >>flags >> >> >>>than occcurs when the MSR register is read. I >>>think the MSR should be read by the isr and >>>stored, the location it is stored in should >>> >>> >>be >> >> >>>protected by the spinlock. >>> >>>The LSR has similiar side effects. >>> >>>What do you think? >>> >>>David. >>> >>> >>> >>> >>> >>> >------------------------------------------------------- > > >>>SF email is sponsored by - The IT Product >>> >>> >>Guide >> >> >>>Read honest & candid reviews on hundreds of >>> >>> >>IT >> >> >>>Products from real users. >>>Discover which products truly live up to the >>>hype. Start reading now. >>> >>> >>> >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > >>_______________________________________________ >> >> >>>gumstix-users mailing list >>>gum...@li... >>> >>> >>> >https://lists.sourceforge.net/lists/listinfo/gumstix-users > > >> >> >> >> >------------------------------------------------------- > > >>SF email is sponsored by - The IT Product Guide >>Read honest & candid reviews on hundreds of IT >>Products from real users. >>Discover which products truly live up to the >>hype. Start reading now. >> >> >> >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > >>_______________________________________________ >>gumstix-users mailing list >>gum...@li... >> >> >> >https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide >Read honest & candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >_______________________________________________ >gumstix-users mailing list >gum...@li... >https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > |
From: David F. <dav...@ya...> - 2005-02-21 21:45:52
|
You can disable rfcomm in /etc/default/bluetooth to keep the log clean. I think there is some interaction between getty and rfcomm where getty thinks there is a login attempt. David. --- Christopher Vo <chr...@gm...> wrote: > We have a bnep0 running on our test gumstix > doing good for well over 48 > hours at moderate load... 200 MB RX and 500 MB > TX so far running without > error. > > No error exccept the getty: m stuff like > David's getting - what's that? > > -- Christopher Vo (chr...@gm...) > > > David Farrell wrote: > > >Further tests: > > > >I have ssh session open over bnep0 to the > gumstix > >and have been pinging out the bnep0 to my home > >router. I use ping -s 1024 to get large > packets. > >15 TX MB amd 32 RX MB later all is still > running > >without error. At the same time the ping is > >running I can open a web page on the gumstix > and > >a second ssh session. No dmesg messages, only > >"gumstix kern.err getty: m" messages in > >/var/log/messages. > > > >David. > > > > > > > >--- David Farrell <dav...@ya...> > wrote: > > > > > > > >>Ok, I saved the lsr and msr values in the isr > >>routines to variables I added to the > >>uart_pxa_port structure. I replaced the > >>serial_in() where these values are read. I > >>initialized the values in > serial_pxa_startup(). > >> > >>No more serial errors, even at 921600! > >> > >>I tested this for 5+ hours. Now I am enabling > >>additional bluetooth stuff in stages to see > >>what > >>else may break. Currently pinging my > bluetooth > >>bridge via bnep0, I'll see how long this > lives. > >> > >>David. > >> > >>--- David Farrell <dav...@ya...> > >>wrote: > >> > >> > >> > >>>Craig, > >>>I read you grrr comment in svn. One thing > >>>bothering me about this routine. Even > though > >>> > >>> > >>a > >> > >> > >>>spin_lock_irqsave surrounds the serial_in, > it > >>>does nothing to prevent resetting the MSR > >>> > >>> > >>flags > >> > >> > >>>than occcurs when the MSR register is read. > I > >>>think the MSR should be read by the isr and > >>>stored, the location it is stored in should > >>> > >>> > >>be > >> > >> > >>>protected by the spinlock. > >>> > >>>The LSR has similiar side effects. > >>> > >>>What do you think? > >>> > >>>David. > >>> > >>> > >>> > >>> > >>> > >>> > >------------------------------------------------------- > > > > > >>>SF email is sponsored by - The IT Product > >>> > >>> > >>Guide > >> > >> > >>>Read honest & candid reviews on hundreds of > >>> > >>> > >>IT > >> > >> > >>>Products from real users. > >>>Discover which products truly live up to the > >>>hype. Start reading now. > >>> > >>> > >>> > >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > > > > >>_______________________________________________ > >> > >> > >>>gumstix-users mailing list > >>>gum...@li... > >>> > >>> > >>> > >https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > >> > >> > >> > >> > >------------------------------------------------------- > > > > > >>SF email is sponsored by - The IT Product > Guide > >>Read honest & candid reviews on hundreds of > IT > >>Products from real users. > >>Discover which products truly live up to the > >>hype. Start reading now. > >> > >> > >> > >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > > > > >>_______________________________________________ > >>gumstix-users mailing list > >>gum...@li... > >> > >> > >> > >https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > > > > > > >------------------------------------------------------- > >SF email is sponsored by - The IT Product > Guide > >Read honest & candid reviews on hundreds of IT > Products from real users. > >Discover which products truly live up to the > hype. Start reading now. > >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >_______________________________________________ > >gumstix-users mailing list > >gum...@li... > >https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the > hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@hu...> - 2005-02-22 04:32:19
|
Just tested your patched driver on BTUART at 921600, and it breaks as soon as I try to send data from gumstix to outside world at high bandwidth. Looks just like what would happen pre-patch. So sounds like this patch fixes what you were seeing with the HWUART on your gumstix, but doesn't resolve the BTUART issue(s). C On Feb 21, 2005, at 1:45 PM, David Farrell wrote: > You can disable rfcomm in /etc/default/bluetooth > to keep the log clean. I think there is some > interaction between getty and rfcomm where getty > thinks there is a login attempt. > David. > --- Christopher Vo <chr...@gm...> wrote: > >> We have a bnep0 running on our test gumstix >> doing good for well over 48 >> hours at moderate load... 200 MB RX and 500 MB >> TX so far running without >> error. >> >> No error exccept the getty: m stuff like >> David's getting - what's that? >> >> -- Christopher Vo (chr...@gm...) >> >> >> David Farrell wrote: >> >>> Further tests: >>> >>> I have ssh session open over bnep0 to the >> gumstix >>> and have been pinging out the bnep0 to my home >>> router. I use ping -s 1024 to get large >> packets. >>> 15 TX MB amd 32 RX MB later all is still >> running >>> without error. At the same time the ping is >>> running I can open a web page on the gumstix >> and >>> a second ssh session. No dmesg messages, only >>> "gumstix kern.err getty: m" messages in >>> /var/log/messages. >>> >>> David. >>> >>> >>> >>> --- David Farrell <dav...@ya...> >> wrote: >>> >>> >>> >>>> Ok, I saved the lsr and msr values in the isr >>>> routines to variables I added to the >>>> uart_pxa_port structure. I replaced the >>>> serial_in() where these values are read. I >>>> initialized the values in >> serial_pxa_startup(). >>>> >>>> No more serial errors, even at 921600! >>>> >>>> I tested this for 5+ hours. Now I am enabling >>>> additional bluetooth stuff in stages to see >>>> what >>>> else may break. Currently pinging my >> bluetooth >>>> bridge via bnep0, I'll see how long this >> lives. >>>> >>>> David. >>>> >>>> --- David Farrell <dav...@ya...> >>>> wrote: >>>> >>>> >>>> >>>>> Craig, >>>>> I read you grrr comment in svn. One thing >>>>> bothering me about this routine. Even >> though >>>>> >>>>> >>>> a >>>> >>>> >>>>> spin_lock_irqsave surrounds the serial_in, >> it >>>>> does nothing to prevent resetting the MSR >>>>> >>>>> >>>> flags >>>> >>>> >>>>> than occcurs when the MSR register is read. >> I >>>>> think the MSR should be read by the isr and >>>>> stored, the location it is stored in should >>>>> >>>>> >>>> be >>>> >>>> >>>>> protected by the spinlock. >>>>> >>>>> The LSR has similiar side effects. >>>>> >>>>> What do you think? >>>>> >>>>> David. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >> >> ------------------------------------------------------- >>> >>> >>>>> SF email is sponsored by - The IT Product >>>>> >>>>> >>>> Guide >>>> >>>> >>>>> Read honest & candid reviews on hundreds of >>>>> >>>>> >>>> IT >>>> >>>> >>>>> Products from real users. >>>>> Discover which products truly live up to the >>>>> hype. Start reading now. >>>>> >>>>> >>>>> >> >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>> >>> >> >>> _______________________________________________ >>>> >>>> >>>>> gumstix-users mailing list >>>>> gum...@li... >>>>> >>>>> >>>>> >> >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >>>> >>>> >>>> >>>> >> >> ------------------------------------------------------- >>> >>> >>>> SF email is sponsored by - The IT Product >> Guide >>>> Read honest & candid reviews on hundreds of >> IT >>>> Products from real users. >>>> Discover which products truly live up to the >>>> hype. Start reading now. >>>> >>>> >>>> >> >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>> >>> >> >>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> >>>> >>>> >> >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >>> >>> >>> >> >> ------------------------------------------------------- >>> SF email is sponsored by - The IT Product >> Guide >>> Read honest & candid reviews on hundreds of IT >> Products from real users. >>> Discover which products truly live up to the >> hype. Start reading now. >> >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> >> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >> >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >>> >> >> >> >> > ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT >> Products from real users. >> Discover which products truly live up to the >> hype. Start reading now. >> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: David F. <dav...@ya...> - 2005-02-22 13:41:56
|
We must have diffent boards. Via a ssh session to the gumstix I am pinging out the gumstix to my router. Simultaneously I am pinging the gumstix from my Fedora. All pings are using -s 1024. Overnight I saw 80MB of characters both ways without error. It is still running, when I get home tonight I'll check it again. Other than this, what do you mean by high bandwidth? The burst rate can't be any higher since I am always sending more data than FIFO or buffer size. The average rate may be low due to ping behaviour. Tell me what you are doing to test it? I'll try the same. What fails? --- Craig Hughes <cr...@hu...> wrote: > Just tested your patched driver on BTUART at > 921600, and it breaks as > soon as I try to send data from gumstix to > outside world at high > bandwidth. Looks just like what would happen > pre-patch. > > So sounds like this patch fixes what you were > seeing with the HWUART on > your gumstix, but doesn't resolve the BTUART > issue(s). > > C > |
From: Bouwens / M. <Bou...@bl...> - 2005-02-22 14:01:15
|
Hi David, is it possible to receive your patched root file system? I'm having a 400 MHz gum from the 2nd production run. Just for testing if it fails, then... But when it works, that would be wonderfull. Regards Robert ----- Original Message ----- From: "David Farrell" <dav...@ya...> To: <gum...@li...> Sent: Tuesday, February 22, 2005 2:41 PM Subject: Re: [Gumstix-users] serial_pxa_get_mctrl > We must have diffent boards. Via a ssh session to > the gumstix I am pinging out the gumstix to my > router. Simultaneously I am pinging the gumstix > from my Fedora. All pings are using -s 1024. > Overnight I saw 80MB of characters both ways > without error. It is still running, when I get > home tonight I'll check it again. Other than > this, what do you mean by high bandwidth? The > burst rate can't be any higher since I am always > sending more data than FIFO or buffer size. The > average rate may be low due to ping behaviour. > > Tell me what you are doing to test it? I'll try > the same. What fails? > > > --- Craig Hughes <cr...@hu...> wrote: > >> Just tested your patched driver on BTUART at >> 921600, and it breaks as >> soon as I try to send data from gumstix to >> outside world at high >> bandwidth. Looks just like what would happen >> pre-patch. >> >> So sounds like this patch fixes what you were >> seeing with the HWUART on >> your gumstix, but doesn't resolve the BTUART >> issue(s). >> >> C >> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: David F. <dav...@ya...> - 2005-02-22 14:42:14
|
Robert, Benny also asked I send him the patch. It is not that I don't want to share at this point but I really want Craig to manage this. Although my testing has shown good results, Craigs test still indicates a problem. I am a novice at kernel development, I am sure Craig had to massage the patch I sent him to get it right. I don't want to set anyone back do to patch problems when the task at hand is bluetooth testing. At any rate if Craigs schedule can permit him to work this out in the next couple of days, I'll send you and Benny the patch off list. David. --- Bouwens / Mehl <Bou...@bl...> wrote: > Hi David, > > is it possible to receive your patched root > file system? > I'm having a 400 MHz gum from the 2nd > production run. > > Just for testing if it fails, then... > But when it works, that would be wonderfull. > > Regards > Robert > > ----- Original Message ----- > From: "David Farrell" <dav...@ya...> > To: <gum...@li...> > Sent: Tuesday, February 22, 2005 2:41 PM > Subject: Re: [Gumstix-users] > serial_pxa_get_mctrl > > > > We must have diffent boards. Via a ssh > session to > > the gumstix I am pinging out the gumstix to > my > > router. Simultaneously I am pinging the > gumstix > > from my Fedora. All pings are using -s 1024. > > Overnight I saw 80MB of characters both ways > > without error. It is still running, when I > get > > home tonight I'll check it again. Other than > > this, what do you mean by high bandwidth? The > > burst rate can't be any higher since I am > always > > sending more data than FIFO or buffer size. > The > > average rate may be low due to ping > behaviour. > > > > Tell me what you are doing to test it? I'll > try > > the same. What fails? > > > > > > --- Craig Hughes <cr...@hu...> > wrote: > > > >> Just tested your patched driver on BTUART at > >> 921600, and it breaks as > >> soon as I try to send data from gumstix to > >> outside world at high > >> bandwidth. Looks just like what would > happen > >> pre-patch. > >> > >> So sounds like this patch fixes what you > were > >> seeing with the HWUART on > >> your gumstix, but doesn't resolve the BTUART > >> issue(s). > >> > >> C > >> > > > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product > Guide > > Read honest & candid reviews on hundreds of > IT Products from real users. > > Discover which products truly live up to the > hype. Start reading now. > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the > hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Bouwens / M. <Bou...@bl...> - 2005-02-22 14:56:37
|
Hi David, that's ok for me. Would be great to get that device up and running. regards Robert ----- Original Message ----- From: "David Farrell" <dav...@ya...> To: <gum...@li...> Sent: Tuesday, February 22, 2005 3:42 PM Subject: Re: [Gumstix-users] serial_pxa_get_mctrl > Robert, > > Benny also asked I send him the patch. It is not > that I don't want to share at this point but I > really want Craig to manage this. Although my > testing has shown good results, Craigs test still > indicates a problem. I am a novice at kernel > development, I am sure Craig had to massage the > patch I sent him to get it right. I don't want to > set anyone back do to patch problems when the > task at hand is bluetooth testing. At any rate > if Craigs schedule can permit him to work this > out in the next couple of days, I'll send you and > Benny the patch off list. > David. |
From: Craig H. <cr...@hu...> - 2005-02-22 18:14:59
|
Ok, binary at http://www.rungie.com/~craig/root_fs_arm.df-bt and the patch is now in SVN C On Feb 22, 2005, at 6:56 AM, Bouwens / Mehl wrote: > Hi David, > > that's ok for me. > Would be great to get that device up and running. > > regards > Robert > ----- Original Message ----- From: "David Farrell" > <dav...@ya...> > To: <gum...@li...> > Sent: Tuesday, February 22, 2005 3:42 PM > Subject: Re: [Gumstix-users] serial_pxa_get_mctrl > > >> Robert, >> Benny also asked I send him the patch. It is not >> that I don't want to share at this point but I >> really want Craig to manage this. Although my >> testing has shown good results, Craigs test still >> indicates a problem. I am a novice at kernel >> development, I am sure Craig had to massage the >> patch I sent him to get it right. I don't want to >> set anyone back do to patch problems when the >> task at hand is bluetooth testing. At any rate >> if Craigs schedule can permit him to work this >> out in the next couple of days, I'll send you and >> Benny the patch off list. >> David. > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Bouwens / M. <Bou...@bl...> - 2005-02-22 18:19:51
|
Hi Craig, I'll test it after our spaghetti break... the break is supposed to be in 10 minutes.... Regards Robert ----- Original Message ----- From: "Craig Hughes" <cr...@hu...> To: <gum...@li...> Sent: Tuesday, February 22, 2005 7:15 PM Subject: Re: [Gumstix-users] serial_pxa_get_mctrl > Ok, binary at > > http://www.rungie.com/~craig/root_fs_arm.df-bt > > and the patch is now in SVN > > C > > On Feb 22, 2005, at 6:56 AM, Bouwens / Mehl wrote: > >> Hi David, >> >> that's ok for me. >> Would be great to get that device up and running. >> >> regards >> Robert |
From: Benny S. <ben...@ma...> - 2005-02-22 19:39:46
|
Thanks I have installed the binary and as my own build based on SVN 396 it dies almost instantly. I don't know if anyone are able to get the system running with the pand options "--ROLE PANU --search --persist" If I use these options a login on a rfcomm session will quickly die. I login and run yes. After a few seconds no more y's will appear, but if I press a key a few more characters will be received. Ok instead I change the pand options in /etc/default/bluetooth to PAND_OPTIONS="--role NAP --listen" Restart bluetooth and then I can reliable start a rfcomm login and connect to the gumstix NAP from my windoze laptop. I have started two ssh logins on the gumstix and on both I run ping -s 5000 <some ip>. I also flood ping the gumstix from a Linux box with ping -f -s 256 <gum ip> No problem with this setup and I think every buffer in the UART will be stressed with this approach until now (~60 MB Rx and Tx data on the bnep0 interface). I did try with the same pand options on SVN 396 and with that cahnge it was also ok (I did stop it when it reached ~600 MB Rx and Tx data). What I would like now is to switch to BTUART with this setup, but what do I need to change? BR Benny ----- Original Message ----- From: "Craig Hughes" <cr...@hu...> To: <gum...@li...> Sent: Tuesday, February 22, 2005 7:15 PM Subject: Re: [Gumstix-users] serial_pxa_get_mctrl > Ok, binary at > > http://www.rungie.com/~craig/root_fs_arm.df-bt > > and the patch is now in SVN > > C > > On Feb 22, 2005, at 6:56 AM, Bouwens / Mehl wrote: > >> Hi David, >> >> that's ok for me. >> Would be great to get that device up and running. >> >> regards >> Robert >> ----- Original Message ----- From: "David Farrell" >> <dav...@ya...> >> To: <gum...@li...> >> Sent: Tuesday, February 22, 2005 3:42 PM >> Subject: Re: [Gumstix-users] serial_pxa_get_mctrl >> >> >>> Robert, >>> Benny also asked I send him the patch. It is not >>> that I don't want to share at this point but I >>> really want Craig to manage this. Although my >>> testing has shown good results, Craigs test still >>> indicates a problem. I am a novice at kernel >>> development, I am sure Craig had to massage the >>> patch I sent him to get it right. I don't want to >>> set anyone back do to patch problems when the >>> task at hand is bluetooth testing. At any rate >>> if Craigs schedule can permit him to work this >>> out in the next couple of days, I'll send you and >>> Benny the patch off list. >>> David. >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: David F. <dav...@ya...> - 2005-02-22 20:05:04
|
I only test with PAN, never RFCOMM. If you look in /var/log/messages you will see PAN constantly inquiring to find a NAP (--search). This may be killing RFCOMM. I do know that once I have a PAN session to my NAP, I can no longer succeed with a RFCOMM session with my iPAQ. (Well ok, sometimes I test RFCOMM with my iPAQ, but only to check connects, never sending any data.) I usually prevent RFCOMM from starting in the /etc/default/bluetooth file. David. --- Benny Simonsen <ben...@ma...> wrote: > Thanks > > I have installed the binary and as my own build > based on SVN 396 it dies > almost instantly. > I don't know if anyone are able to get the > system running with the pand > options "--ROLE PANU --search --persist" > If I use these options a login on a rfcomm > session will quickly die. I login > and run yes. After a few seconds no more y's > will appear, but if I press a > key a few more characters will be received. > > Ok instead I change the pand options in > /etc/default/bluetooth to > PAND_OPTIONS="--role NAP --listen" > Restart bluetooth and then I can reliable start > a rfcomm login and connect > to the gumstix NAP from my windoze laptop. > I have started two ssh logins on the gumstix > and on both I run ping -s 5000 > <some ip>. I also flood ping the gumstix from a > Linux box with ping -f -s > 256 <gum ip> > > No problem with this setup and I think every > buffer in the UART will be > stressed with this approach until now (~60 MB > Rx and Tx data on the bnep0 > interface). > > I did try with the same pand options on SVN 396 > and with that cahnge it was > also ok (I did stop it when it reached ~600 MB > Rx and Tx data). > > What I would like now is to switch to BTUART > with this setup, but what do I > need to change? > > > BR > Benny > > > > > > ----- Original Message ----- > From: "Craig Hughes" <cr...@hu...> > To: <gum...@li...> > Sent: Tuesday, February 22, 2005 7:15 PM > Subject: Re: [Gumstix-users] > serial_pxa_get_mctrl > > > > Ok, binary at > > > > > http://www.rungie.com/~craig/root_fs_arm.df-bt > > > > and the patch is now in SVN > > > > C > > > > On Feb 22, 2005, at 6:56 AM, Bouwens / Mehl > wrote: > > > >> Hi David, > >> > >> that's ok for me. > >> Would be great to get that device up and > running. > >> > >> regards > >> Robert > >> ----- Original Message ----- From: "David > Farrell" > >> <dav...@ya...> > >> To: <gum...@li...> > >> Sent: Tuesday, February 22, 2005 3:42 PM > >> Subject: Re: [Gumstix-users] > serial_pxa_get_mctrl > >> > >> > >>> Robert, > >>> Benny also asked I send him the patch. It > is not > >>> that I don't want to share at this point > but I > >>> really want Craig to manage this. Although > my > >>> testing has shown good results, Craigs test > still > >>> indicates a problem. I am a novice at > kernel > >>> development, I am sure Craig had to massage > the > >>> patch I sent him to get it right. I don't > want to > >>> set anyone back do to patch problems when > the > >>> task at hand is bluetooth testing. At any > rate > >>> if Craigs schedule can permit him to work > this > >>> out in the next couple of days, I'll send > you and > >>> Benny the patch off list. > >>> David. > >> > >> > >> > >> > ------------------------------------------------------- > >> SF email is sponsored by - The IT Product > Guide > >> Read honest & candid reviews on hundreds of > IT Products from real users. > >> Discover which products truly live up to the > hype. Start reading now. > >> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >> > _______________________________________________ > >> gumstix-users mailing list > >> gum...@li... > >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product > Guide > > Read honest & candid reviews on hundreds of > IT Products from real users. > > Discover which products truly live up to the > hype. Start reading now. > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the > hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Benny S. <ben...@ma...> - 2005-02-22 20:47:37
|
Ahh of course. The pand option "--search" will connect to every BT unit it can find and if that unit become master the gumstix BT clk will sync to this device and that will probaly cause the problem with the rfcomm connection (bluetooth experts please correct if Im wrong). To avoid this problem the hcid.conf "lm accept" can be changed to "lm accept, master" which will force the gumstix unit to become master (which might give other problems if you have a device that deny a role switch). Ok it starts to go off topic, but I will try to see if I can find what will be required to change back to the BTUART. BR Benny ----- Original Message ----- From: "David Farrell" <dav...@ya...> To: <gum...@li...> Sent: Tuesday, February 22, 2005 9:04 PM Subject: Re: [Gumstix-users] serial_pxa_get_mctrl >I only test with PAN, never RFCOMM. If you look > in /var/log/messages you will see PAN constantly > inquiring to find a NAP (--search). This may be > killing RFCOMM. I do know that once I have a PAN > session to my NAP, I can no longer succeed with a > RFCOMM session with my iPAQ. (Well ok, sometimes > I test RFCOMM with my iPAQ, but only to check > connects, never sending any data.) > > I usually prevent RFCOMM from starting in the > /etc/default/bluetooth file. > > David. > > --- Benny Simonsen <ben...@ma...> > wrote: > >> Thanks >> >> I have installed the binary and as my own build >> based on SVN 396 it dies >> almost instantly. >> I don't know if anyone are able to get the >> system running with the pand >> options "--ROLE PANU --search --persist" >> If I use these options a login on a rfcomm >> session will quickly die. I login >> and run yes. After a few seconds no more y's >> will appear, but if I press a >> key a few more characters will be received. >> >> Ok instead I change the pand options in >> /etc/default/bluetooth to >> PAND_OPTIONS="--role NAP --listen" >> Restart bluetooth and then I can reliable start >> a rfcomm login and connect >> to the gumstix NAP from my windoze laptop. >> I have started two ssh logins on the gumstix >> and on both I run ping -s 5000 >> <some ip>. I also flood ping the gumstix from a >> Linux box with ping -f -s >> 256 <gum ip> >> >> No problem with this setup and I think every >> buffer in the UART will be >> stressed with this approach until now (~60 MB >> Rx and Tx data on the bnep0 >> interface). >> >> I did try with the same pand options on SVN 396 >> and with that cahnge it was >> also ok (I did stop it when it reached ~600 MB >> Rx and Tx data). >> >> What I would like now is to switch to BTUART >> with this setup, but what do I >> need to change? >> >> >> BR >> Benny >> >> >> >> >> >> ----- Original Message ----- >> From: "Craig Hughes" <cr...@hu...> >> To: <gum...@li...> >> Sent: Tuesday, February 22, 2005 7:15 PM >> Subject: Re: [Gumstix-users] >> serial_pxa_get_mctrl >> >> >> > Ok, binary at >> > >> > >> http://www.rungie.com/~craig/root_fs_arm.df-bt >> > >> > and the patch is now in SVN >> > >> > C >> > >> > On Feb 22, 2005, at 6:56 AM, Bouwens / Mehl >> wrote: >> > >> >> Hi David, >> >> >> >> that's ok for me. >> >> Would be great to get that device up and >> running. >> >> >> >> regards >> >> Robert >> >> ----- Original Message ----- From: "David >> Farrell" >> >> <dav...@ya...> >> >> To: <gum...@li...> >> >> Sent: Tuesday, February 22, 2005 3:42 PM >> >> Subject: Re: [Gumstix-users] >> serial_pxa_get_mctrl >> >> >> >> >> >>> Robert, >> >>> Benny also asked I send him the patch. It >> is not >> >>> that I don't want to share at this point >> but I >> >>> really want Craig to manage this. Although >> my >> >>> testing has shown good results, Craigs test >> still >> >>> indicates a problem. I am a novice at >> kernel >> >>> development, I am sure Craig had to massage >> the >> >>> patch I sent him to get it right. I don't >> want to >> >>> set anyone back do to patch problems when >> the >> >>> task at hand is bluetooth testing. At any >> rate >> >>> if Craigs schedule can permit him to work >> this >> >>> out in the next couple of days, I'll send >> you and >> >>> Benny the patch off list. >> >>> David. >> >> >> >> >> >> >> >> >> > ------------------------------------------------------- >> >> SF email is sponsored by - The IT Product >> Guide >> >> Read honest & candid reviews on hundreds of >> IT Products from real users. >> >> Discover which products truly live up to the >> hype. Start reading now. >> >> >> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> >> >> _______________________________________________ >> >> gumstix-users mailing list >> >> gum...@li... >> >> >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > >> > >> > >> > >> > ------------------------------------------------------- >> > SF email is sponsored by - The IT Product >> Guide >> > Read honest & candid reviews on hundreds of >> IT Products from real users. >> > Discover which products truly live up to the >> hype. Start reading now. >> > >> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> > >> _______________________________________________ >> > gumstix-users mailing list >> > gum...@li... >> > >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > >> >> >> >> > ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT >> Products from real users. >> Discover which products truly live up to the >> hype. Start reading now. >> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: David F. <dav...@ya...> - 2005-02-22 21:00:28
|
I suppose best practice is to turn off everything you dont required. Also you can connect to a specific NAP if you know its bluetooth address instead of searching for one. PAN and RFCOMM are different services, I think there may be some limitations in the bluez stuff that may prevent concurrent use. I am not sure the BTUART will work (at least at 921K). My test indicated it would not. As much as I would hate to loose the port, I think everyone using the same port is best for now. If things get ironed out, maybe then is the time to check back with the BTUART. David. --- Benny Simonsen <ben...@ma...> wrote: > Ahh of course. > The pand option "--search" will connect to > every BT unit it can find and if > that unit become master the gumstix BT clk will > sync to this device and that > will probaly cause the problem with the rfcomm > connection (bluetooth experts > please correct if Im wrong). > To avoid this problem the hcid.conf "lm accept" > can be changed to "lm > accept, master" which will force the gumstix > unit to become master (which > might give other problems if you have a device > that deny a role switch). > > Ok it starts to go off topic, but I will try to > see if I can find what will > be required to change back to the BTUART. > > BR > Benny > > > ----- Original Message ----- > From: "David Farrell" <dav...@ya...> > To: <gum...@li...> > Sent: Tuesday, February 22, 2005 9:04 PM > Subject: Re: [Gumstix-users] > serial_pxa_get_mctrl > > > >I only test with PAN, never RFCOMM. If you > look > > in /var/log/messages you will see PAN > constantly > > inquiring to find a NAP (--search). This may > be > > killing RFCOMM. I do know that once I have a > PAN > > session to my NAP, I can no longer succeed > with a > > RFCOMM session with my iPAQ. (Well ok, > sometimes > > I test RFCOMM with my iPAQ, but only to check > > connects, never sending any data.) > > > > I usually prevent RFCOMM from starting in the > > /etc/default/bluetooth file. > > > > David. > > > > --- Benny Simonsen > <ben...@ma...> > > wrote: > > > >> Thanks > >> > >> I have installed the binary and as my own > build > >> based on SVN 396 it dies > >> almost instantly. > >> I don't know if anyone are able to get the > >> system running with the pand > >> options "--ROLE PANU --search --persist" > >> If I use these options a login on a rfcomm > >> session will quickly die. I login > >> and run yes. After a few seconds no more y's > >> will appear, but if I press a > >> key a few more characters will be received. > >> > >> Ok instead I change the pand options in > >> /etc/default/bluetooth to > >> PAND_OPTIONS="--role NAP --listen" > >> Restart bluetooth and then I can reliable > start > >> a rfcomm login and connect > >> to the gumstix NAP from my windoze laptop. > >> I have started two ssh logins on the gumstix > >> and on both I run ping -s 5000 > >> <some ip>. I also flood ping the gumstix > from a > >> Linux box with ping -f -s > >> 256 <gum ip> > >> > >> No problem with this setup and I think every > >> buffer in the UART will be > >> stressed with this approach until now (~60 > MB > >> Rx and Tx data on the bnep0 > >> interface). > >> > >> I did try with the same pand options on SVN > 396 > >> and with that cahnge it was > >> also ok (I did stop it when it reached ~600 > MB > >> Rx and Tx data). > >> > >> What I would like now is to switch to BTUART > >> with this setup, but what do I > >> need to change? > >> > >> > >> BR > >> Benny > >> > >> > >> > >> > >> > >> ----- Original Message ----- > >> From: "Craig Hughes" > <cr...@hu...> > >> To: <gum...@li...> > >> Sent: Tuesday, February 22, 2005 7:15 PM > >> Subject: Re: [Gumstix-users] > >> serial_pxa_get_mctrl > >> > >> > >> > Ok, binary at > >> > > >> > > >> > http://www.rungie.com/~craig/root_fs_arm.df-bt > >> > > >> > and the patch is now in SVN > >> > > >> > C > >> > > >> > On Feb 22, 2005, at 6:56 AM, Bouwens / > Mehl > >> wrote: > >> > > >> >> Hi David, > >> >> > >> >> that's ok for me. > >> >> Would be great to get that device up and > >> running. > >> >> > >> >> regards > >> >> Robert > >> >> ----- Original Message ----- From: "David > >> Farrell" > >> >> <dav...@ya...> > >> >> To: <gum...@li...> > >> >> Sent: Tuesday, February 22, 2005 3:42 PM > >> >> Subject: Re: [Gumstix-users] > >> serial_pxa_get_mctrl > >> >> > >> >> > >> >>> Robert, > >> >>> Benny also asked I send him the patch. > It > >> is not > >> >>> that I don't want to share at this point > >> but I > >> >>> really want Craig to manage this. > Although > >> my > >> >>> testing has shown good results, Craigs > test > >> still > >> >>> indicates a problem. I am a novice at > >> kernel > >> >>> development, I am sure Craig had to > massage > >> the > >> >>> patch I sent him to get it right. I > don't > >> want to > >> >>> set anyone back do to patch problems > when > >> the > >> >>> task at hand is bluetooth testing. At > any > >> rate > >> >>> if Craigs schedule can permit him to > work > >> this > >> >>> out in the next couple of days, I'll > send > >> you and > >> >>> Benny the patch off list. > >> >>> David. > >> >> > >> >> > >> >> > >> >> > >> > > > ------------------------------------------------------- > >> >> SF email is sponsored by - The IT Product > >> Guide > >> >> Read honest & candid reviews on hundreds > of > >> IT Products from real users. > >> >> Discover which products truly live up to > the > >> hype. Start reading now. > >> >> > >> > === message truncated === |
From: Craig H. <cr...@hu...> - 2005-02-22 21:33:31
|
My testing shows same results -- HWUART works fine, BTUART doesn't work (at least at 921600). I suspect BTUARt would also fail occasionally at slower speed too, just less often. To switch the port back to using the BTUART, you'll have to reset the GPIO modes for BTUART *after* loading the bluetooth kernel modules. bluetooth_gumstix will currently switch GPIO4[2-5] back to HWUART mode. C On Feb 22, 2005, at 1:00 PM, David Farrell wrote: > I suppose best practice is to turn off everything > you dont required. Also you can connect to a > specific NAP if you know its bluetooth address > instead of searching for one. > PAN and RFCOMM are different services, I think > there may be some limitations in the bluez stuff > that may prevent concurrent use. > > I am not sure the BTUART will work (at least at > 921K). My test indicated it would not. As much > as I would hate to loose the port, I think > everyone using the same port is best for now. If > things get ironed out, maybe then is the time to > check back with the BTUART. > > David. > > > --- Benny Simonsen <ben...@ma...> > wrote: > >> Ahh of course. >> The pand option "--search" will connect to >> every BT unit it can find and if >> that unit become master the gumstix BT clk will >> sync to this device and that >> will probaly cause the problem with the rfcomm >> connection (bluetooth experts >> please correct if Im wrong). >> To avoid this problem the hcid.conf "lm accept" >> can be changed to "lm >> accept, master" which will force the gumstix >> unit to become master (which >> might give other problems if you have a device >> that deny a role switch). >> >> Ok it starts to go off topic, but I will try to >> see if I can find what will >> be required to change back to the BTUART. >> >> BR >> Benny >> >> >> ----- Original Message ----- >> From: "David Farrell" <dav...@ya...> >> To: <gum...@li...> >> Sent: Tuesday, February 22, 2005 9:04 PM >> Subject: Re: [Gumstix-users] >> serial_pxa_get_mctrl >> >> >>> I only test with PAN, never RFCOMM. If you >> look >>> in /var/log/messages you will see PAN >> constantly >>> inquiring to find a NAP (--search). This may >> be >>> killing RFCOMM. I do know that once I have a >> PAN >>> session to my NAP, I can no longer succeed >> with a >>> RFCOMM session with my iPAQ. (Well ok, >> sometimes >>> I test RFCOMM with my iPAQ, but only to check >>> connects, never sending any data.) >>> >>> I usually prevent RFCOMM from starting in the >>> /etc/default/bluetooth file. >>> >>> David. >>> >>> --- Benny Simonsen >> <ben...@ma...> >>> wrote: >>> >>>> Thanks >>>> >>>> I have installed the binary and as my own >> build >>>> based on SVN 396 it dies >>>> almost instantly. >>>> I don't know if anyone are able to get the >>>> system running with the pand >>>> options "--ROLE PANU --search --persist" >>>> If I use these options a login on a rfcomm >>>> session will quickly die. I login >>>> and run yes. After a few seconds no more y's >>>> will appear, but if I press a >>>> key a few more characters will be received. >>>> >>>> Ok instead I change the pand options in >>>> /etc/default/bluetooth to >>>> PAND_OPTIONS="--role NAP --listen" >>>> Restart bluetooth and then I can reliable >> start >>>> a rfcomm login and connect >>>> to the gumstix NAP from my windoze laptop. >>>> I have started two ssh logins on the gumstix >>>> and on both I run ping -s 5000 >>>> <some ip>. I also flood ping the gumstix >> from a >>>> Linux box with ping -f -s >>>> 256 <gum ip> >>>> >>>> No problem with this setup and I think every >>>> buffer in the UART will be >>>> stressed with this approach until now (~60 >> MB >>>> Rx and Tx data on the bnep0 >>>> interface). >>>> >>>> I did try with the same pand options on SVN >> 396 >>>> and with that cahnge it was >>>> also ok (I did stop it when it reached ~600 >> MB >>>> Rx and Tx data). >>>> >>>> What I would like now is to switch to BTUART >>>> with this setup, but what do I >>>> need to change? >>>> >>>> >>>> BR >>>> Benny >>>> >>>> >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Craig Hughes" >> <cr...@hu...> >>>> To: <gum...@li...> >>>> Sent: Tuesday, February 22, 2005 7:15 PM >>>> Subject: Re: [Gumstix-users] >>>> serial_pxa_get_mctrl >>>> >>>> >>>>> Ok, binary at >>>>> >>>>> >>>> >> http://www.rungie.com/~craig/root_fs_arm.df-bt >>>>> >>>>> and the patch is now in SVN >>>>> >>>>> C >>>>> >>>>> On Feb 22, 2005, at 6:56 AM, Bouwens / >> Mehl >>>> wrote: >>>>> >>>>>> Hi David, >>>>>> >>>>>> that's ok for me. >>>>>> Would be great to get that device up and >>>> running. >>>>>> >>>>>> regards >>>>>> Robert >>>>>> ----- Original Message ----- From: "David >>>> Farrell" >>>>>> <dav...@ya...> >>>>>> To: <gum...@li...> >>>>>> Sent: Tuesday, February 22, 2005 3:42 PM >>>>>> Subject: Re: [Gumstix-users] >>>> serial_pxa_get_mctrl >>>>>> >>>>>> >>>>>>> Robert, >>>>>>> Benny also asked I send him the patch. >> It >>>> is not >>>>>>> that I don't want to share at this point >>>> but I >>>>>>> really want Craig to manage this. >> Although >>>> my >>>>>>> testing has shown good results, Craigs >> test >>>> still >>>>>>> indicates a problem. I am a novice at >>>> kernel >>>>>>> development, I am sure Craig had to >> massage >>>> the >>>>>>> patch I sent him to get it right. I >> don't >>>> want to >>>>>>> set anyone back do to patch problems >> when >>>> the >>>>>>> task at hand is bluetooth testing. At >> any >>>> rate >>>>>>> if Craigs schedule can permit him to >> work >>>> this >>>>>>> out in the next couple of days, I'll >> send >>>> you and >>>>>>> Benny the patch off list. >>>>>>> David. >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>> >> > ------------------------------------------------------- >>>>>> SF email is sponsored by - The IT Product >>>> Guide >>>>>> Read honest & candid reviews on hundreds >> of >>>> IT Products from real users. >>>>>> Discover which products truly live up to >> the >>>> hype. Start reading now. >>>>>> >>>> >> > === message truncated === > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Philip T. <ph...@te...> - 2005-02-22 22:08:05
|
On Tue, 2005-02-22 at 13:33 -0800, Craig Hughes wrote: > My testing shows same results -- HWUART works fine, BTUART doesn't work > (at least at 921600). I suspect BTUARt would also fail occasionally at > slower speed too, just less often. > > To switch the port back to using the BTUART, you'll have to reset the > GPIO modes for BTUART *after* loading the bluetooth kernel modules. > bluetooth_gumstix will currently switch GPIO4[2-5] back to HWUART mode. > > C > So would this be a hardware problem then? The BTUART would be useful to use for other purposes, such as hanging a GPS off of or similar, which have low data rates. Craig, did you get reliable transmissions at all with the BTUART at lower rates, eg. 57600 or 115200? These speeds would be fine for a serial terminal. Phil |
From: Craig H. <cr...@hu...> - 2005-02-22 18:11:01
|
I'll be checking something into to SVN soon to give everyone else a chance to bang on this new code. I'll also stick a quick test root_fs on my server to let people quickly test w/out having to rebuild... C On Feb 22, 2005, at 6:42 AM, David Farrell wrote: > Robert, > > Benny also asked I send him the patch. It is not > that I don't want to share at this point but I > really want Craig to manage this. Although my > testing has shown good results, Craigs test still > indicates a problem. I am a novice at kernel > development, I am sure Craig had to massage the > patch I sent him to get it right. I don't want to > set anyone back do to patch problems when the > task at hand is bluetooth testing. At any rate > if Craigs schedule can permit him to work this > out in the next couple of days, I'll send you and > Benny the patch off list. > David. > > > --- Bouwens / Mehl <Bou...@bl...> > wrote: > >> Hi David, >> >> is it possible to receive your patched root >> file system? >> I'm having a 400 MHz gum from the 2nd >> production run. >> >> Just for testing if it fails, then... >> But when it works, that would be wonderfull. >> >> Regards >> Robert >> >> ----- Original Message ----- >> From: "David Farrell" <dav...@ya...> >> To: <gum...@li...> >> Sent: Tuesday, February 22, 2005 2:41 PM >> Subject: Re: [Gumstix-users] >> serial_pxa_get_mctrl >> >> >>> We must have diffent boards. Via a ssh >> session to >>> the gumstix I am pinging out the gumstix to >> my >>> router. Simultaneously I am pinging the >> gumstix >>> from my Fedora. All pings are using -s 1024. >>> Overnight I saw 80MB of characters both ways >>> without error. It is still running, when I >> get >>> home tonight I'll check it again. Other than >>> this, what do you mean by high bandwidth? The >>> burst rate can't be any higher since I am >> always >>> sending more data than FIFO or buffer size. >> The >>> average rate may be low due to ping >> behaviour. >>> >>> Tell me what you are doing to test it? I'll >> try >>> the same. What fails? >>> >>> >>> --- Craig Hughes <cr...@hu...> >> wrote: >>> >>>> Just tested your patched driver on BTUART at >>>> 921600, and it breaks as >>>> soon as I try to send data from gumstix to >>>> outside world at high >>>> bandwidth. Looks just like what would >> happen >>>> pre-patch. >>>> >>>> So sounds like this patch fixes what you >> were >>>> seeing with the HWUART on >>>> your gumstix, but doesn't resolve the BTUART >>>> issue(s). >>>> >>>> C >>>> >>> >>> >>> >>> >> > ------------------------------------------------------- >>> SF email is sponsored by - The IT Product >> Guide >>> Read honest & candid reviews on hundreds of >> IT Products from real users. >>> Discover which products truly live up to the >> hype. Start reading now. >>> >> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>> >> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> >> > ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT >> Products from real users. >> Discover which products truly live up to the >> hype. Start reading now. >> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Craig H. <cr...@hu...> - 2005-02-22 18:09:27
|
Sustained rate I think is important, not just burst rate, because while 1024 is clearly bigger than the 64-byte buffer on the UART, the UART is being drained while it's being filled -- by the time you stick the 1024th byte into the FIFO, 1000 bytes might have already left -- you're 24 bytes behind (and would continue getting further behind if the rate were sustained), but by stopping sending, you give the UART a chance to catch up again. ie the UART could be very slowly falling behind, and any interruption in transmission will give it a chance to catch up (doesn't need long at 921600). The way I'm testing is to use rfcomm to establish a login to the gumstix over BT. I then use sz/rz to transfer big files of data from /dev/urandom (so it's not compressible). I can send files to the gumstix this way at 60-70kBps; transfers from the gumstix to the other end die after about 10-50kB of data has flowed through (ie quite a bit more than 1024 bytes). rfcomm is probably not necessary -- using scp over bnep would get you into the same sustained throughput ballpark. Try transfering 1MB of /dev/urandom data using scp in either direction -- should work fine to the gumstix, but if you're using ttyS1 for the HCI link to the module, I predict you won't be able to send from the gumstix. I haven't had a chance to test bnep over the long weekend because OSX doesn't do that, and my windows and linux machines weren't in radio range. I'll give it a shot today though. C On Feb 22, 2005, at 5:41 AM, David Farrell wrote: > We must have diffent boards. Via a ssh session to > the gumstix I am pinging out the gumstix to my > router. Simultaneously I am pinging the gumstix > from my Fedora. All pings are using -s 1024. > Overnight I saw 80MB of characters both ways > without error. It is still running, when I get > home tonight I'll check it again. Other than > this, what do you mean by high bandwidth? The > burst rate can't be any higher since I am always > sending more data than FIFO or buffer size. The > average rate may be low due to ping behaviour. > > Tell me what you are doing to test it? I'll try > the same. What fails? > > > --- Craig Hughes <cr...@hu...> wrote: > >> Just tested your patched driver on BTUART at >> 921600, and it breaks as >> soon as I try to send data from gumstix to >> outside world at high >> bandwidth. Looks just like what would happen >> pre-patch. >> >> So sounds like this patch fixes what you were >> seeing with the HWUART on >> your gumstix, but doesn't resolve the BTUART >> issue(s). >> >> C >> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: David F. <dav...@ya...> - 2005-02-22 22:31:00
|
Ok, I scp uImage from gumstix to Fedora. No problem. No reponse on linux-arm, I guess no-one cares about hw handhake. David, --- Craig Hughes <cr...@hu...> wrote: > Sustained rate I think is important, not just > burst rate, because while > 1024 is clearly bigger than the 64-byte buffer > on the UART, the UART is > being drained while it's being filled -- by the > time you stick the > 1024th byte into the FIFO, 1000 bytes might > have already left -- you're > 24 bytes behind (and would continue getting > further behind if the rate > were sustained), but by stopping sending, you > give the UART a chance to > catch up again. ie the UART could be very > slowly falling behind, and > any interruption in transmission will give it a > chance to catch up > (doesn't need long at 921600). > > The way I'm testing is to use rfcomm to > establish a login to the > gumstix over BT. I then use sz/rz to transfer > big files of data from > /dev/urandom (so it's not compressible). I can > send files to the > gumstix this way at 60-70kBps; transfers from > the gumstix to the other > end die after about 10-50kB of data has flowed > through (ie quite a bit > more than 1024 bytes). rfcomm is probably not > necessary -- using scp > over bnep would get you into the same sustained > throughput ballpark. > Try transfering 1MB of /dev/urandom data using > scp in either direction > -- should work fine to the gumstix, but if > you're using ttyS1 for the > HCI link to the module, I predict you won't be > able to send from the > gumstix. I haven't had a chance to test bnep > over the long weekend > because OSX doesn't do that, and my windows and > linux machines weren't > in radio range. I'll give it a shot today > though. > > C > > > On Feb 22, 2005, at 5:41 AM, David Farrell > wrote: > > > We must have diffent boards. Via a ssh > session to > > the gumstix I am pinging out the gumstix to > my > > router. Simultaneously I am pinging the > gumstix > > from my Fedora. All pings are using -s 1024. > > Overnight I saw 80MB of characters both ways > > without error. It is still running, when I > get > > home tonight I'll check it again. Other than > > this, what do you mean by high bandwidth? The > > burst rate can't be any higher since I am > always > > sending more data than FIFO or buffer size. > The > > average rate may be low due to ping > behaviour. > > > > Tell me what you are doing to test it? I'll > try > > the same. What fails? > > > > > > --- Craig Hughes <cr...@hu...> > wrote: > > > >> Just tested your patched driver on BTUART at > >> 921600, and it breaks as > >> soon as I try to send data from gumstix to > >> outside world at high > >> bandwidth. Looks just like what would > happen > >> pre-patch. > >> > >> So sounds like this patch fixes what you > were > >> seeing with the HWUART on > >> your gumstix, but doesn't resolve the BTUART > >> issue(s). > >> > >> C > >> > > > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product > Guide > > Read honest & candid reviews on hundreds of > IT Products from real > > users. > > Discover which products truly live up to the > hype. Start reading now. > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the > hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |