Notice: Trying to access array offset on value of type bool in /srv/www/vhosts/openpandora.org/domains/bugs.openpandora.org/httpdocs/scripts/details.php on line 649 FS#304 : bluetooth serial port sleep causes lost / frozen connection (and bluetooth) if connection idle

OpenPandora Main OS

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Core
  • Operating System Release 1 (Zaxxon)
  • Severity Low
  • Reported Version SuperZaxxon Final 1.53
Attached to Project: OpenPandora Main OS
Opened by Urja Rannikko - 23.11.2012
Last edited by Grazvydas - 24.11.2012

FS#304 - bluetooth serial port sleep causes lost / frozen connection (and bluetooth) if connection idle

I experienced (reliably) 3 times that if I had an idle ppp/rfcomm connection to my phone, it would eventually freeze so that the phone reported no active bluetooth connection and the pandora ppp would still think that the connection is active, but no data would flow. Killing pppd and re-trying would fail opening of the rfcomm link with "Host is down". Disabling & enabling bluetooth "fixed" this so that pppd worked again (so it is not the phone that was "down"). Adding these lines to op_bluetooth_work.sh (apparently atleast) fixed it for me: add between lines 14-15: echo 0 > /sys/devices/platform/omap_uart.0/sleep_timeout (or at any place during enable for that matter) And to disable (before exit 0, line 30) to save power when bluetooth is off and restore normal settings: echo 10 > /sys/devices/platform/omap_uart.0/sleep_timeout I remember mentioning this way back when I last tested bluetooth, but got a reply that this should not be needed because we have flow control between the bt chip and pandora. But if a sleeping serial port loses a character when somebody sends a burst to it, what could flow control do? If it reported not ready to receive, the character would never be sent (and things would freeze...). If it reports ready to receive (what I think it does) the character will be lost. One would need to periodically disable the serial port sleep (and enable ready to receive) for a moment to check for pending data, but I think this would use more power than keeping the serial port active and/or possibly cause way too big delays. I'm not really certain of this thing (whether this is a workaround, hack or a real fix... and whether my interpretation of what is happening is correct - i have no real proof), but I think that reporting what I've found is better than not. (And am I the only user of bluetooth with an old phone for internet (ppp+rfcomm, not pan)? ...)
Closed by  Grazvydas
24.11.2012 20:38
Reason for closing:  Fixed
Additional comments about closing:  applied proposed changes
Grazvydas commented on 23.11.2012 15:05
I'm not sure myself now. One thing is for sure that the driver in 3.2 is rather broken and kernel update is needed to fix it, some details can be found here: http://marc.info/?l=linux-omap&m=134952717104700&w=2 so maybe some problems are actually coming from there. As for 3.2 I think your changes make sense, can you generate a patch or at least attach the patched, tested script? I don't want to touch the script myself right now as I don't have anything to test it on (yes the changes are simple, but I recently confused < with > in PCSX that took a few hours to debug later).
Urja Rannikko commented on 23.11.2012 15:56
Since attaching a file seems to not work (per #271) here is a link: http://urjaman.dyndns.info/op_bluetooth_work.sh (my patched, tested script). Generating a patch would have been a lot of work since I failed to remember to backup the original, sorry. (EDIT: Oh, i could have pseudo-patched it by reverting based on memory and so on, but that is also error-prone...)
Grazvydas commented on 24.11.2012 20:38
ok committed on your behalf: http://git.openpandora.org/cgi-bin/gitweb.cgi?p=openpandora.oe.git;a=summary

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing