From: Brad M. <bmi...@gm...> - 2012-03-09 19:04:50
|
Hey, My understanding is that for some time we couldn't use bluetooth at anything above 115k because of a serial driver issue. Ostensibly, linaro had the fixed kernel and Steve Sakoman had images that would work as well. What is the status on that? Is the serial driver problem fixed at this point? Could a new problem have appeared? I used to be able to run "hciattach ttyS1 csr" using linaro on an overo fire but on a newer board this always produces: Can't get port settings: Input/output error Can't initialize device: Input/output error this linaro image was built last year and reports running Linux linaro 2.6.38-1003-linaro-omap #4~ppa5-Ubuntu SMP PREEMPT Wed May 25 14:44:32 UTC 2011 armv7l armv7l armv7l GNU/Linux -- Brad Midgley |
From: Patrick M. (D. - CA/Ottawa) <Pat...@dr...> - 2012-03-09 19:41:47
|
Hi Brad, I've used the stock (Linux 3.0) serial drivers at 460800bps and patched drivers up to 1.5Mbps. The patched drivers should work up to 3Mbps. One of my collegues noticed that a couple of zero bytes are transmitted by the omap processor at a fixed interval (can't remember exactly how long, but I think it was 192us) after the start of a block of received data. On short receive bursts, the TX line stays idle, but on long receive bursts, 1 or 2 "0" bytes are transmitted. The patches only change the baud rate clock divider from 13 to 16 for speeds of 1M, 1.5M, and 3.0M. Patrick > -----Original Message----- > From: Brad Midgley [mailto:bmi...@gm...] > Sent: March 9, 2012 14:05 > To: General mailing list for gumstix users. > Subject: [Gumstix-users] serial driver & high uart rates > > Hey, > > My understanding is that for some time we couldn't use bluetooth at > anything above 115k because of a serial driver issue. Ostensibly, > linaro had the fixed kernel and Steve Sakoman had images that would > work as well. > > What is the status on that? Is the serial driver problem fixed at this > point? Could a new problem have appeared? > > I used to be able to run "hciattach ttyS1 csr" using linaro on an > overo fire but on a newer board this always produces: > > Can't get port settings: Input/output error > Can't initialize device: Input/output error > > this linaro image was built last year and reports running > > Linux linaro 2.6.38-1003-linaro-omap #4~ppa5-Ubuntu SMP PREEMPT Wed > May 25 14:44:32 UTC 2011 armv7l armv7l armv7l GNU/Linux > > -- > Brad Midgley > > -------------------------------------------------------------- > ---------------- > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Brad M. <bmi...@gm...> - 2012-03-09 22:20:18
|
Patrick > I've used the stock (Linux 3.0) serial drivers at 460800bps and > patched drivers up to 1.5Mbps. The patched drivers should work > up to 3Mbps. The rate we really need is 921k. > One of my collegues noticed that a couple of zero bytes are > transmitted by the omap processor at a fixed interval (can't > remember exactly how long, but I think it was 192us) after the > start of a block of received data. On short receive bursts, > the TX line stays idle, but on long receive bursts, 1 or 2 "0" > bytes are transmitted. Is that a hardware bug? this would probably kill the hci connection. > The patches only change the baud rate clock divider from 13 to > 16 for speeds of 1M, 1.5M, and 3.0M. was 921k fixed by this? iirc it was not getting set properly. -- Brad Midgley |
From: Patrick M. (D. - CA/Ottawa) <Pat...@dr...> - 2012-03-12 12:55:34
|
> -----Original Message----- > From: Brad Midgley [mailto:bmi...@gm...] > > Patrick > > > I've used the stock (Linux 3.0) serial drivers at 460800bps and > > patched drivers up to 1.5Mbps. The patched drivers should work > > up to 3Mbps. > > The rate we really need is 921k. The stock code sets that oversampling rate to 13 for all baud rates above 230400 bps. The patch I used only fixes the baud rate oversampling setting for speeds that should use 16x oversampling rather than 13x. 921k is unaffected by this patch, but if you're Using a recent kernel with omap_serial support, 921k should already be supported. > > > One of my collegues noticed that a couple of zero bytes are > > transmitted by the omap processor at a fixed interval (can't > > remember exactly how long, but I think it was 192us) after the > > start of a block of received data. On short receive bursts, > > the TX line stays idle, but on long receive bursts, 1 or 2 "0" > > bytes are transmitted. > > Is that a hardware bug? this would probably kill the hci connection. I don't know if this is caused by a hardware, driver, or software bug. If I find anything, I'll post back here. > > > The patches only change the baud rate clock divider from 13 to > > 16 for speeds of 1M, 1.5M, and 3.0M. > > was 921k fixed by this? iirc it was not getting set properly. > > -- > Brad Midgley Are your serial ports named "ttyS?" or "ttyO?". The kernels that support the higher (than 230k) baud rates name the serial ports "ttyO?". Patrick |
From: Brad M. <bmi...@gm...> - 2012-03-20 21:20:55
|
Patrick, great find. Steve, thanks for applying the patch to your release. The good news is that I'm now able to repeatably init and use the bluetooth adapter with hciattach ttyO1 csr 921600 noflow We may have a solution here! It sounds like 921k was just fast enough that xon/xoff was trying to throttle things. Everyone thought the kernel was actually disabling flow control when we asked it to :( On Tue, Mar 20, 2012 at 7:47 AM, Steve Sakoman <sa...@gm...> wrote: > On Fri, Mar 16, 2012 at 10:08 AM, Patrick Maheral (DWI - CA/Ottawa) > <Pat...@dr...> wrote: >> Just noticed an entry in the Linux kernel 3.1 Changelog labeled: >> >> omap-serial: Allow IXON and IXOFF to be disabled. >> >> That looks like it would cause the problem I'm seeing. I've >> Install a 3.2 kernel and will test to see if the zero bytes >> are transmitted. > > That bug does look like it could potentially cause the type of issues > you are seeing. > > I've added the patch to my omap-3.0-pm branch: > > http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=f77d38b6ccbd9cb1e4e5fe92f7dd939b9f6f86d9 > > Builds of my GNOME and console images now include this patch: > > http://www.sakoman.com/category/8-gnome-daily-builds-r13.html > > Let me know if this improves the situation for you. > > Steve -- Brad Midgley |
From: Brad M. <bmi...@gm...> - 2012-03-12 16:44:34
|
Patrick, >> > One of my collegues noticed that a couple of zero bytes are >> > transmitted > I don't know if this is caused by a hardware, driver, or software > bug. If I find anything, I'll post back here. So this is the current state I'm seeing. Each of these is attempted on a clean reboot since any dialog with the bt chip can put it in a weird state. So the old way: hciattach ttyO1 csr 115200 noflow works, adapter is up when you check hciconfig, hcitool scan works hciattach ttyO1 csr 921600 flow sometimes (rarely) works, adapter is up when you check hciconfig, hcitool scan works. Usually, it seems to work but hciconfig shows the adapter is down and hciconfig up operations time out. maybe the problem with 921k has been garbage introduced on the line but there could be some interaction with something else since it sometimes works. Is there anything to suggest that the serial driver can have random failures? Are the transmitted zeroes on the line always present or only sometimes? -- Brad Midgley |
From: Thots <sra...@as...> - 2012-04-25 02:03:28
|
Brad, I was also able to run bluetooth at a speed of 921600. My thanks to the three of you that worked on the problem. I'm using Sakoman's 3.2 kernel so I already had the patch. I tried using your method of switching baud rates: "hciattach ttyO1 csr 921600 noflow". But I got this error: Failed to write init command (GET_BUILD_ID): Success Can't initialize device: Success I got it running by changing "/etc/default/bluetooth". I changed "HCIATTACH_SPEED" from 115200 to 921600. In order to test that the speed of my bluetooth connection was actually 921600, I ran a few different internet speed test programs over my laptop. I connected my laptop to my gumstix over a pand connection. I then used this pand connection for my laptop to access the internet (my Gumstix had internet coming into it via Ethernet, but my laptop could only get internet over the pand connection). When I ran these various speed tests, I wouldn't get a speed near 921600. I got a speed of about 470 kbps. This is about half of what I expected. This lead to testing with different baud rates: baud kbps 115200 75 230400 160 460800 280 921600 470 Does anyone have any suggestions as to why these bluetooth connections don't seem as fast as they should be for their given baud rates? Brad Midgley-3 wrote > > Patrick, great find. Steve, thanks for applying the patch to your > release. The good news is that I'm now able to repeatably init and use > the bluetooth adapter with > > hciattach ttyO1 csr 921600 noflow > > We may have a solution here! It sounds like 921k was just fast enough > that xon/xoff was trying to throttle things. Everyone thought the > kernel was actually disabling flow control when we asked it to :( > > -- > Brad Midgley > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > gumstix-users mailing list > gumstix-users@.sourceforge > https://lists.sourceforge.net/lists/listinfo/gumstix-users > -- View this message in context: http://gumstix.8.n6.nabble.com/serial-driver-high-uart-rates-tp4563332p4915373.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Thots <sra...@as...> - 2012-05-11 23:37:12
|
At first I was excited about being able to set the baud rate to 921600 for Bluetooth. However, I have found out that it is very unreliable at that speed. If I'm not doing anything on my Gumstix besides using Bluetooth, everything works great. However, it always breaks when I start using the Gumstix for lots of other things. For example, as soon as I start using VLC to capture and display video from a normal USB webcam, Bluetooth barfs. Bluetooth stops working at all, and from the console I see a stream of these errors: Bluetooth: Frame Reassembly Failed If I switch back to a baud rate of 115200, everything works perfectly. Does anyone have a suggestion as to how to get Bluetooth working reliably at the 921600 baud rate. It is sad to be running Bluetooth at such a low speed when the hardware supports faster. Thanks for your time, Thots -- View this message in context: http://gumstix.8.n6.nabble.com/serial-driver-high-uart-rates-tp4563332p4964302.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Patrick M. (D. - CA/Ottawa) <Pat...@dr...> - 2012-03-12 17:05:04
|
Brad, > -----Original Message----- > From: Brad Midgley [mailto:bmi...@gm...] > > Patrick, > > >> > One of my collegues noticed that a couple of zero bytes are > >> > transmitted > > I don't know if this is caused by a hardware, driver, or software > > bug. If I find anything, I'll post back here. [ ... ] > Is there anything to suggest that the serial driver can have random > failures? Are the transmitted zeroes on the line always present or > only sometimes? I just checked, and the zeroes are not always present. However, when a pair of (spurious) zero are transmitted, the first always starts 391.25us after the start of the received data burst. The time between The first and second zero appears to vary (iirc) but is around 300-500us after the first. BTW, we are using ttyO0 and ttyO2 for communication with a custom I/O board. We are not using the bluetooth interface, so I don't have any experience with that particular connection. Patrick |
From: Thots <sra...@as...> - 2012-03-13 00:11:14
|
So far I've only been able to use the default speed of 115200 for Bluetooth. I'm trying to get Bluetooth as fast as possible. However, I don't know about linaro. I'm using Sakoman's 3.2 kernel (works great) with the normal Gumstix/Angstrom file system. Any suggestions on how to increase the speed would be appreciated. Bluetooth should be going faster than a 115200 baud. -- View this message in context: http://gumstix.8.n6.nabble.com/serial-driver-high-uart-rates-tp4563332p4572273.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Patrick M. (D. - CA/Ottawa) <Pat...@dr...> - 2012-05-14 13:04:56
|
Hi Thots, Are you using a cpu frequency governor? We noticed that the serial overflows disappeared when The system was busy (ie. high CPU usage) which seemed counter-intuitive until we realized that, under those conditions, the CPU frequency never dropped below 500MHz. We found that with the default "On Demand" governor, it would drop the frequency down to 125MHz, and it wouldn't switch to a higher speed fast enough to handle the bursty serial data. We solved our overflow issue by switching to the "Conservative" governor and set the low limit to 250MHz. Patrick > -----Original Message----- > From: Thots [mailto:sra...@as...] > > At first I was excited about being able to set the baud > rate to 921600 for Bluetooth. However, I have found out > that it is very unreliable at that speed. If I'm not > doing anything on my Gumstix besides using Bluetooth, > everything works great. However, it always breaks when > I start using the Gumstix for lots of other things. For > example, as soon as I start using VLC to capture and > display video from a normal USB webcam, Bluetooth barfs. > Bluetooth stops working at all, and from the console I see > a stream of these errors: > > Bluetooth: Frame Reassembly Failed > > If I switch back to a baud rate of 115200, everything works > perfectly. > > Does anyone have a suggestion as to how to get Bluetooth > working reliably at the 921600 baud rate. It is sad to be > running Bluetooth at such a low speed when the hardware > supports faster. > > Thanks for your time, > Thots |
From: Thots <sra...@as...> - 2012-05-17 00:34:28
|
Thanks for your suggestion, Patrick. I've tried setting the CPU frequency governor a couple of different ways. Unfortunately, it hasn't solved the problem of Bluetooth not working at 921600 during the heavy CPU load of capturing and displaying video with VLC. I've used a Fire Storm Gumstix running at 800MHz. The current governor is set to "userspace". I tried using menu_config to set the governor to "conservative". Then I rebuilt the kernel. However, the Gumstix crashes before the new kernel ever finishes booting. Next I tried setting the governor to conservative during run-time via: echo conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor However, this definitely doesn't work for high CPU loads. The kernel crashes as soon as I turn on VLC and start capturing and displaying video (I don't even have Bluetooth running). If I don't set the governor to "conservative", I can run VLC without any problem. Are there any other suggestions how to fix Bluetooth not working reliably at the 921600 speed? Thanks for your time, Thots Patrick Maheral (DWI - CA/Ottawa) wrote > > Hi Thots, > > Are you using a cpu frequency governor? > > We noticed that the serial overflows disappeared when > The system was busy (ie. high CPU usage) which seemed > counter-intuitive until we realized that, under those > conditions, the CPU frequency never dropped below 500MHz. > We found that with the default "On Demand" governor, > it would drop the frequency down to 125MHz, and it > wouldn't switch to a higher speed fast enough to handle > the bursty serial data. We solved our overflow issue by > switching to the "Conservative" governor and set the low > limit to 250MHz. > > Patrick > -- View this message in context: http://gumstix.8.n6.nabble.com/serial-driver-high-uart-rates-tp4563332p4964339.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Brad M. <bmi...@gm...> - 2012-03-13 04:22:40
|
maybe someone at gumstix could comment on the driver situation. We could confirm corruption by looking at the hcidump output and comparing it to what is actually sent over the uart. I don't have a setup to spy on the uart though. On Mon, Mar 12, 2012 at 5:51 PM, Thots <sra...@as...> wrote: > So far I've only been able to use the default speed of 115200 for Bluetooth. > I'm trying to get Bluetooth as fast as possible. However, I don't know > about linaro. I'm using Sakoman's 3.2 kernel (works great) with the normal > Gumstix/Angstrom file system. > > Any suggestions on how to increase the speed would be appreciated. > Bluetooth should be going faster than a 115200 baud. -- Brad Midgley |
From: Patrick M. (D. - CA/Ottawa) <Pat...@dr...> - 2012-03-16 13:07:34
|
> -----Original Message----- > From: Brad Midgley [mailto:bmi...@gm...] > > maybe someone at gumstix could comment on the driver situation. We > could confirm corruption by looking at the hcidump output and > comparing it to what is actually sent over the uart. I don't have a > setup to spy on the uart though. > We did a bit of testing yesterday with the CPU speed. We are processing receiving about 100 bursts of data per second. At a core speed of 125MHz, we see the zero's being transmitted once or twice a second. At a core speed of 250MHz, this drops down to once or twice a minute. There is very little (if any) improvement at 500MHz. I'll post here as I find more info. I have a suspicion that it might be XON/XOFF characters being transmitted by the UART even though, AFAIK, software flow control is turned off. Patrick |
From: Brad M. <bmi...@gm...> - 2012-03-16 16:29:23
|
this sounds like something gumstix should take up with TI On Fri, Mar 16, 2012 at 7:07 AM, Patrick Maheral (DWI - CA/Ottawa) <Pat...@dr...> wrote: >> -----Original Message----- >> From: Brad Midgley [mailto:bmi...@gm...] >> >> maybe someone at gumstix could comment on the driver situation. We >> could confirm corruption by looking at the hcidump output and >> comparing it to what is actually sent over the uart. I don't have a >> setup to spy on the uart though. >> > > We did a bit of testing yesterday with the CPU speed. We are processing > receiving about 100 bursts of data per second. At a core speed of 125MHz, > we see the zero's being transmitted once or twice a second. At a core > speed of 250MHz, this drops down to once or twice a minute. There is > very little (if any) improvement at 500MHz. > > I'll post here as I find more info. I have a suspicion that it might be > XON/XOFF characters being transmitted by the UART even though, AFAIK, > software flow control is turned off. > > Patrick > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users -- Brad Midgley |
From: Patrick M. (D. - CA/Ottawa) <Pat...@dr...> - 2012-03-16 17:08:41
|
Just noticed an entry in the Linux kernel 3.1 Changelog labeled: omap-serial: Allow IXON and IXOFF to be disabled. That looks like it would cause the problem I'm seeing. I've Install a 3.2 kernel and will test to see if the zero bytes are transmitted. Patrick > -----Original Message----- > From: Brad Midgley [mailto:bmi...@gm...] > Sent: March 16, 2012 12:29 > To: General mailing list for gumstix users. > Subject: Re: [Gumstix-users] serial driver & high uart rates > > this sounds like something gumstix should take up with TI > > On Fri, Mar 16, 2012 at 7:07 AM, Patrick Maheral (DWI - CA/Ottawa) > <Pat...@dr...> wrote: > >> -----Original Message----- > >> From: Brad Midgley [mailto:bmi...@gm...] > >> > >> maybe someone at gumstix could comment on the driver situation. We > >> could confirm corruption by looking at the hcidump output and > >> comparing it to what is actually sent over the uart. I don't have a > >> setup to spy on the uart though. > >> > > > > We did a bit of testing yesterday with the CPU speed. We > are processing > > receiving about 100 bursts of data per second. At a core > speed of 125MHz, > > we see the zero's being transmitted once or twice a second. > At a core > > speed of 250MHz, this drops down to once or twice a minute. > There is > > very little (if any) improvement at 500MHz. > > > > I'll post here as I find more info. I have a suspicion > that it might be > > XON/XOFF characters being transmitted by the UART even > though, AFAIK, > > software flow control is turned off. > > > > Patrick > > > > > > > -------------------------------------------------------------- > ---------------- > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > -- > Brad Midgley > > -------------------------------------------------------------- > ---------------- > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Steve S. <sa...@gm...> - 2012-03-20 13:47:31
|
On Fri, Mar 16, 2012 at 10:08 AM, Patrick Maheral (DWI - CA/Ottawa) <Pat...@dr...> wrote: > Just noticed an entry in the Linux kernel 3.1 Changelog labeled: > > omap-serial: Allow IXON and IXOFF to be disabled. > > That looks like it would cause the problem I'm seeing. I've > Install a 3.2 kernel and will test to see if the zero bytes > are transmitted. That bug does look like it could potentially cause the type of issues you are seeing. I've added the patch to my omap-3.0-pm branch: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=f77d38b6ccbd9cb1e4e5fe92f7dd939b9f6f86d9 Builds of my GNOME and console images now include this patch: http://www.sakoman.com/category/8-gnome-daily-builds-r13.html Let me know if this improves the situation for you. Steve >> -----Original Message----- >> From: Brad Midgley [mailto:bmi...@gm...] >> Sent: March 16, 2012 12:29 >> To: General mailing list for gumstix users. >> Subject: Re: [Gumstix-users] serial driver & high uart rates >> >> this sounds like something gumstix should take up with TI >> >> On Fri, Mar 16, 2012 at 7:07 AM, Patrick Maheral (DWI - CA/Ottawa) >> <Pat...@dr...> wrote: >> >> -----Original Message----- >> >> From: Brad Midgley [mailto:bmi...@gm...] >> >> >> >> maybe someone at gumstix could comment on the driver situation. We >> >> could confirm corruption by looking at the hcidump output and >> >> comparing it to what is actually sent over the uart. I don't have a >> >> setup to spy on the uart though. >> >> >> > >> > We did a bit of testing yesterday with the CPU speed. We >> are processing >> > receiving about 100 bursts of data per second. At a core >> speed of 125MHz, >> > we see the zero's being transmitted once or twice a second. >> At a core >> > speed of 250MHz, this drops down to once or twice a minute. >> There is >> > very little (if any) improvement at 500MHz. >> > >> > I'll post here as I find more info. I have a suspicion >> that it might be >> > XON/XOFF characters being transmitted by the UART even >> though, AFAIK, >> > software flow control is turned off. >> > >> > Patrick >> > >> > >> > >> -------------------------------------------------------------- >> ---------------- >> > This SF email is sponsosred by: >> > Try Windows Azure free for 90 days Click Here >> > http://p.sf.net/sfu/sfd2d-msazure >> > _______________________________________________ >> > gumstix-users mailing list >> > gum...@li... >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> >> >> -- >> Brad Midgley >> >> -------------------------------------------------------------- >> ---------------- >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Brad M. <bmi...@gm...> - 2012-03-21 04:02:29
|
Steve, A few questions about your distro, first related to the topic at hand, bt: I created a user account so pulse would start but it shows no hardware available, even when a bluetooth headset is connected. Not even wired audio. There should be pulseaudio/hal/d-bus magic that goes into this for ubuntu etc, but for these any connected bt headset appears in the devices part of the pulse control panel and also has device-specific tweaks, like choosing voice or hifi. Too bad there's not a firefox 4 or newer. Has anyone tried webgl in firefox with sgx? Monitor resolutions are stuck at 1024x768 max which usually means image stretching. I am very excited about the prospect of having full support for bluetooth. Guys, let's figure out how to get closer... :) I can now boot without any usb devices and use bt keyboard/mouse. I did have to let things settle first, so in rcS.d I have a script: (sleep 30 ; hciattach ttyO1 csr 921600 noflow ) & Brad On Tue, Mar 20, 2012 at 3:20 PM, Brad Midgley <bmi...@gm...> wrote: > Patrick, great find. Steve, thanks for applying the patch to your > release. The good news is that I'm now able to repeatably init and use > the bluetooth adapter with > > hciattach ttyO1 csr 921600 noflow > > We may have a solution here! It sounds like 921k was just fast enough > that xon/xoff was trying to throttle things. Everyone thought the > kernel was actually disabling flow control when we asked it to :( > > On Tue, Mar 20, 2012 at 7:47 AM, Steve Sakoman <sa...@gm...> wrote: >> On Fri, Mar 16, 2012 at 10:08 AM, Patrick Maheral (DWI - CA/Ottawa) >> <Pat...@dr...> wrote: >>> Just noticed an entry in the Linux kernel 3.1 Changelog labeled: >>> >>> omap-serial: Allow IXON and IXOFF to be disabled. >>> >>> That looks like it would cause the problem I'm seeing. I've >>> Install a 3.2 kernel and will test to see if the zero bytes >>> are transmitted. >> >> That bug does look like it could potentially cause the type of issues >> you are seeing. >> >> I've added the patch to my omap-3.0-pm branch: >> >> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=f77d38b6ccbd9cb1e4e5fe92f7dd939b9f6f86d9 >> >> Builds of my GNOME and console images now include this patch: >> >> http://www.sakoman.com/category/8-gnome-daily-builds-r13.html >> >> Let me know if this improves the situation for you. >> >> Steve > > -- > Brad Midgley -- Brad Midgley |
From: Steve S. <sa...@gm...> - 2012-03-21 05:43:24
|
On Tue, Mar 20, 2012 at 9:02 PM, Brad Midgley <bmi...@gm...> wrote: > Steve, > > A few questions about your distro, first related to the topic at hand, bt: > > I created a user account so pulse would start but it shows no hardware > available, even when a bluetooth headset is connected. Not even wired > audio. There should be pulseaudio/hal/d-bus magic that goes into this > for ubuntu etc, but for these any connected bt headset appears in the > devices part of the pulse control panel and also has device-specific > tweaks, like choosing voice or hifi. I fussed around with pulse a bit, but never got it to work right. Sadly the OE recipes for pulse don't seem to work "out of the box" and I haven't had the motivation to debug it. If you can figure out what is broken I'm happy to fix recipes to do the right thing. I suspect it is just a bunch of config/init work. > Too bad there's not a firefox 4 or newer. Has anyone tried webgl in > firefox with sgx? No, sgx has been broken for omap35xx in the last few TI SDK releases, 37xx seems to work ok. Haven't tried to get sgx working in Firefox -- another case of no strong motivation to do so. > Monitor resolutions are stuck at 1024x768 max which usually means > image stretching. Not true! I use higher resolutions all the time! You need to set the monitor resolution in the u-boot environment: http://www.sakoman.com/OMAP/how-to-change-the-display-resolution.html > I am very excited about the prospect of having full support for > bluetooth. Guys, let's figure out how to get closer... :) I don't normally use bluetooth, but I am happy to tweak my images to fix any issues you find -- as long as you give me good instructions on what needs to change :-) Steve > I can now boot without any usb devices and use bt keyboard/mouse. I > did have to let things settle first, so in rcS.d I have a script: > > (sleep 30 ; hciattach ttyO1 csr 921600 noflow ) & > > Brad > > On Tue, Mar 20, 2012 at 3:20 PM, Brad Midgley <bmi...@gm...> wrote: >> Patrick, great find. Steve, thanks for applying the patch to your >> release. The good news is that I'm now able to repeatably init and use >> the bluetooth adapter with >> >> hciattach ttyO1 csr 921600 noflow >> >> We may have a solution here! It sounds like 921k was just fast enough >> that xon/xoff was trying to throttle things. Everyone thought the >> kernel was actually disabling flow control when we asked it to :( >> >> On Tue, Mar 20, 2012 at 7:47 AM, Steve Sakoman <sa...@gm...> wrote: >>> On Fri, Mar 16, 2012 at 10:08 AM, Patrick Maheral (DWI - CA/Ottawa) >>> <Pat...@dr...> wrote: >>>> Just noticed an entry in the Linux kernel 3.1 Changelog labeled: >>>> >>>> omap-serial: Allow IXON and IXOFF to be disabled. >>>> >>>> That looks like it would cause the problem I'm seeing. I've >>>> Install a 3.2 kernel and will test to see if the zero bytes >>>> are transmitted. >>> >>> That bug does look like it could potentially cause the type of issues >>> you are seeing. >>> >>> I've added the patch to my omap-3.0-pm branch: >>> >>> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=f77d38b6ccbd9cb1e4e5fe92f7dd939b9f6f86d9 >>> >>> Builds of my GNOME and console images now include this patch: >>> >>> http://www.sakoman.com/category/8-gnome-daily-builds-r13.html >>> >>> Let me know if this improves the situation for you. >>> >>> Steve >> >> -- >> Brad Midgley > > > > -- > Brad Midgley > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |