Hi folks,
I've played around with btsco the last few days - now it sort of works
like intended.
I got the following comments about the procedure:
1. I'd like to suggest to put the comment about compatible dongles on
the btsco website a little clearer.
"If it doesn't say anything at all about SCO mapping, " wasn't clear
to me (being a bluetooth newbie), as it was "displaying something
with SCO" (i.e. the MTU, but I didn't grasp the difference at first,
as my first adapter didn't show more than the first 2 lines).
I'd suggest to put a simple exaple there, how the results from
"hciconfig hci0 revision" should look like. I.e. that the line
"SCO mapping: HCI" should exist.
2. I think the following comment might be something for the BlueZ-FAQ,
as I have seen more people with this problem, while googling for
a solution:
Q: I have used the same bluetooth dongle on different machines or with
different machine configurations (e.g. using windows). Now my device
will refuse to pair again with the dongle.
A: Remove the line in /var/lib/bluetooth/[my-bdaddr]/linkkeys that is
corresponding to the device that doesn't want to pair. BlueZ thinks it
is already paired, but the Link-Key does not match.
Another - maybe better - solution would be to initiate a re-pair
request in case the Link fails due to wrong keys.
I had the case that I first tested the newly bought (CSR) dongle
using the laptop, while I actually wanted to use it on the desktop
later. After being paired with the laptop, the headset refused
to pair with the desktop with the same dongle.
I've seen a rather recent question that seems to be the same problem
on bluez-users. However the hints there point to
/etc/bluetooth/linkkeys - is this outdated or is this due to me using
debian packages?
Another - possibly very interesting - solution would be to allow to
change the bdaddr in software. This would allow me to fake the same
dongle to have two different bdaddrs depending on where I use it,
thus allowing the headset to correctly pair with _both_ devices,
so that I only need to move the dongle and everything works.
Is there such a command? Please excuse, if it is obvious. I'm very
new to this stuff.
3. I have written a small Python-Script and a .btscorc that allows me
to pick up Skype calls with the headset button. I got to hold the
button, as it otherwise will just change the volume and reacting on
those AT sequences didn't seem like a good idea to me.
I'm not sure, if the AT-command is always the same, but that's easy
enough to adjust. The files are at:
http://www.acs.uni-duesseldorf.de/~becka/download/skype/
The python script is probably ugly. I have no clue abou python -
I just mangled the skype sample script.
4. I also have the "microphone transmits noise" problem sometimes
(rarely). Could it be, that there is a missed byte that swaps high
and lowbyte? It sounded a bit like this to me.
5. My cheap (EUR 22.- incl. VAT) LevelOne BLH-1000 Headset works fine,
except for the glitch just described. It ignores microphone level
setup, though. Loopback control works. Using the buttons, you can
only reach Speaker Level 12 (80%) - using the mixer you can go to
100%.
Have fun,
Andy
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Andreas Beck <[email protected]> wrote:
> He's right. Depending on how the problem is created, my fix is actually
> flawed anyway, though it will mask the problem quite well.
> I'll think about a better swapping fix. Maybe I can make the stuff
> nicer to understand as well.
[x] Done. New patch attached. Smaller, more readable and more correct.
There is one catch, though, that I hadn't noticed before:
If you turn on loopback and AGC together, chances are, that the headset
will go into a feedback loop, emitting an unpleasant beep.
This is a generic problem of loopback, which is only emphasized by the
AGC, as it will (by its design) tune up input gain until it gets a
significant signal.
Feedback loop beep will occur, if total gain of the loop is >1.
Actually the behaviour of the beep shows, that the AGC is working
fine, as the beep will not go to full scale due to the AGC tuning
down gain until the total gain is about 1.
However I don't see much use for loopback mode anyway, and both are
controllable in the mixer, so I don't think it will be much of a
problem. If you need loopback, keep your fingers off AGC, or tune the
parameters so that even max gain (COMPRESSION_MAX_16) will not
trigger a feedback loop.
CU, Andy
Brad Midgley <[email protected]> wrote:
> Converting our kernel module to an alsa userspace driver is on the
> roadmap and I believe your approach could be used there as well.
Yeah. I like such copying-around much better in Userspace. Much less you
can do wrong and _really_ mess things up.
> Marcel will probably ask why we don't fix the problem in the bluez
> layers if that's where it is, so every SCO app benefits.
He's right. Depending on how the problem is created, my fix is actually
flawed anyway, though it will mask the problem quite well.
I handle it, as if it were an endianness problem. However it is probably
a loosing data problem. As I just swap endianness, I group the data
wrongly. This is probably only noticeable on high-pitched tones.
Example:
orig data: 1L 1H 2L 2H 3L 3H
lost 1L: 1H 2L 2H 3L 3H
with swap: 2L 1H 3L 2H ...
Thus we will get 1H2L as a value. I group together bytes that don't
belong together.
We really should fix that in the SCO layer if possible.
But I can as well think about a better fix. The downside of a better fix
would be, that I need to keep around a byte for the next round of
copying, as the last byte in a packet and the first in the next form
a pair.
How does the SCO socket react to short reads? I suppose it would give
1 byte and the 47 on the next, if I tried, right? It will usually
give out the data packets just as they arrive - right?
In that case I really only see one other fix: keeping around the byte
from the last round.
> Can you surround the adaptive stuff and swapping stuff with two
> different macros so we can select them independently? Like USE_ADAPTIVE
> and USE_AUTOSWAP or something?
I have tried that. Attached. It makes the patch rather unwieldy, though,
as I use the same mechanism to efficiently check the swap stuff and
do the AGC. The patch should work for the none-defined and for the
both-defined case. If it does for mixed cases, I just hope.
I could probably make it more readable at the expense of speed by
splitting the analysis loop in two.
I'll think about a better swapping fix. Maybe I can make the stuff
nicer to understand as well.
Interim patch attached.
CU, Andy
--
= Andreas Beck | Email : <[email protected]> =
Andreas,
The adaptive strategy you chose seems like it will work well. That was
very quick coding and good intuition on the noise problem! I'll try the
patch.
Converting our kernel module to an alsa userspace driver is on the
roadmap and I believe your approach could be used there as well.
Marcel will probably ask why we don't fix the problem in the bluez
layers if that's where it is, so every SCO app benefits.
Can you surround the adaptive stuff and swapping stuff with two
different macros so we can select them independently? Like USE_ADAPTIVE
and USE_AUTOSWAP or something?
Brad
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Now for the patch (against CVS) described in the previous mail ...
Have fun with it,
Andy
Andreas Beck <[email protected]> wrote:
> > >[I just noticed, that the copying around is done in kernelspace. Got to
> > > check it there, then.]
> > I'll bet we could watch for this. If byte order gets reversed, it might
> > present a pattern that we can identify.
> Very probably. If there is a little noise on the line, the pattern for a
> signed16 signal will be, that there is an unusual amount of
> lowbytes being 0x00 or 0xff.
That was right. I have a patch that fixes this. It basically checks, if
all lowbytes are 0x00 or 0xff in a transmission block (which happens when
there is silence, and the bytes are swapped). I also request that the
block is at least 32 bytes long, but I suppose this always happens.
I have only seen 48 byte blocks for my hardware.
> > It seems like SCO is not a reliable transport so maybe bluez is
> > supposed to watch for this kind of stuff somehow. I should read
> > up on it...
> I had assumed it is reliable enough to send only even-length messages.
> But that might be not true. You might want to check that.
It seems it is not an issue of variable length messages. I have put in a
warning, if you get odd length packets, but it doesn't trigger for me,
though I have the noise-problem occasionally.
The above heuristic seems to fix it, though.
For me, it happend once on the first connection after loading the
module, usually.
For this reason, my fixup code will trigger on the first and second
connection now (fix the first, fall back to normal behaviour for the
second). All connections are ok now.
> > >A nice addition for me would be a software mic-boost. The quality of the
> > >sound is not bad, but (probably due to the ridiculously compact design
> > >of my headset) the dynamic range is not used appropriately.
> > The general solution is an adaptive boost which would be nice even for
> > mics that use the full range. It's a common problem so I'll bet you can
> > get this from one of the alsa layers in userspace.
> The main problem is, that I got to work without floating point stuff,
> as this goes into kernelspace and that I got to keep CPU usage low.
> But I think I can manage that. I used to do some realtime signal
> processing a while ago.
[x] Done.
I added a new boolean mixer variable AGC that will turn on AGC.
You may want to check if I did that right, and if it was really
necessary to put in the put and get functions, or if alsa standard
functions would have done.
AGC is very simplistic, but works nicely for me:
AGC ist limited to 1/16 - 20 times gain.
It goes up by 1/16 for every 1/20 second that the signal (after processing)
stays below an absolute value of 1000. This puts an upper limit to
amplifying MIC noise.
It goes down immediately ba 1/16 for every overshoot value detected.
Works ok for me.
> > I've seen times where the mouse starts acting whacked and focus gets
> > stuck on some widget even if the mouse is pointing elsewhere. I've been
> > meaning to restart hidd and/or reload evdev to see if it's linked to the
> > bluetooth mouse.
> This sounds more like a windowmanager problem. I've seen this with wired
> mice as well at times. Restarting the WM usually helps.
Very interesting. I got that one as well this afternoon.
However keyboard was not working as well (maybe due to the stuck focus)
So restarting fvwm didn't work. Killing from the console did.
CU, ANdy
--
= Andreas Beck | Email : <[email protected]> =
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
> >>>3. I have written a small Python-Script and a .btscorc
> >>I will link to you or put these in a contrib dir (what do you think?)
> >I don't care. I don't think this will need updates, unless the skype
> >d-bus protocol gets changed in a fundamental way.
> Ok, I will put it in contrib and add a note that it's derived from the
> api documentation example. If you like the mod from "Whoopie" I'll apply
> that too.
Yeah. I like it. Much appreciated enhancement. I've uploaded his version
to my site as well.
I suggest you use this version. I made a minimal change to Whoopie's
version. I call the API-Name "SkypePickup" which is probably more
generic, as the script will do a pickup - it does not really have
something to do with BT headsets, except that it is a nice sample
application.
> >[I just noticed, that the copying around is done in kernelspace. Got to
> > check it there, then.]
> I'll bet we could watch for this. If byte order gets reversed, it might
> present a pattern that we can identify.
Very probably. If there is a little noise on the line, the pattern for a
signed16 signal will be, that there is an unusual amount of
lowbytes being 0x00 or 0xff.
My first idea would be to check, if _all_ lowbytes (i.e. the lowbytes
as they are transmitted) are 0x00 or 0xff in a transmitted block of not
too short length. If that is the case, I'd suggest to just "miss" a
single byte in transfer. If that cures the problem, it should be ok.
The only case where this doesn't work should be very noisy environments.
I don't think it will mistrigger on natural inputs.
> It seems like SCO is not a reliable transport so maybe bluez is
> supposed to watch for this kind of stuff somehow. I should read
> up on it...
I had assumed it is reliable enough to send only even-length messages.
But that might be not true. You might want to check that.
> >A nice addition for me would be a software mic-boost. The quality of the
> >sound is not bad, but (probably due to the ridiculously compact design
> >of my headset) the dynamic range is not used appropriately.
> The general solution is an adaptive boost which would be nice even for
> mics that use the full range. It's a common problem so I'll bet you can
> get this from one of the alsa layers in userspace.
The main problem is, that I got to work without floating point stuff,
as this goes into kernelspace and that I got to keep CPU usage low.
But I think I can manage that. I used to do some realtime signal
processing a while ago.
> >Another thing I noticed (which is probably not btsco related, but more
> >of a general bluez problem, maybe even a general kernel problem) is,
> >that I now had two occasions where my USB subsystem became unresponsive
> >to a point where the machine froze.
> I suppose since it's only happened twice you can't reproduce it?
No, not really. The shutdown-lockup seems to happen quite often,
though.
> I've seen times where the mouse starts acting whacked and focus gets
> stuck on some widget even if the mouse is pointing elsewhere. I've been
> meaning to restart hidd and/or reload evdev to see if it's linked to the
> bluetooth mouse.
This sounds more like a windowmanager problem. I've seen this with wired
mice as well at times. Restarting the WM usually helps.
CU, ANdy
--
= Andreas Beck | Email : <[email protected]> =
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Andreas
>>>3. I have written a small Python-Script and a .btscorc
>>
>>Perfect. I gave a talk about btsco at our usergroup meeting and this
>>very question came up! (slides at http://flamebot.com/blog)
>>I will link to you or put these in a contrib dir (what do you think?)
>
>
> I don't care. I don't think this will need updates, unless the skype
> d-bus protocol gets changed in a fundamental way.
Ok, I will put it in contrib and add a note that it's derived from the
api documentation example. If you like the mod from "Whoopie" I'll apply
that too.
> [I just noticed, that the copying around is done in kernelspace. Got to
> check it there, then.]
I'll bet we could watch for this. If byte order gets reversed, it might
present a pattern that we can identify. It seems like SCO is not a
reliable transport so maybe bluez is supposed to watch for this kind of
stuff somehow. I should read up on it...
> A nice addition for me would be a software mic-boost. The quality of the
> sound is not bad, but (probably due to the ridiculously compact design
> of my headset) the dynamic range is not used appropriately.
The general solution is an adaptive boost which would be nice even for
mics that use the full range. It's a common problem so I'll bet you can
get this from one of the alsa layers in userspace.
> Another thing I noticed (which is probably not btsco related, but more
> of a general bluez problem, maybe even a general kernel problem) is,
> that I now had two occasions where my USB subsystem became unresponsive
> to a point where the machine froze.
I suppose since it's only happened twice you can't reproduce it? I'm not
much help looking over logs since I don't know what to look for.
I've seen times where the mouse starts acting whacked and focus gets
stuck on some widget even if the mouse is pointing elsewhere. I've been
meaning to restart hidd and/or reload evdev to see if it's linked to the
bluetooth mouse.
Brad
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
[had to resend that, as I forgot to use the right source address, sorry.
Thus a few comments I make now in [] ]
Hi Brad,
> > I'd suggest to put a simple exaple there, how the results from
> > "hciconfig hci0 revision" should look like. I.e. that the line
> > "SCO mapping: HCI" should exist.
> I cleaned this up a bit.
Great. That should be clear now.
> I don't know of such a command. /etc/bluetooth/link_key is how the keys
> are stored in the older daemon so I've mentioned both in the docs.
Yeah - this might as well help.
> >3. I have written a small Python-Script and a .btscorc
> Perfect. I gave a talk about btsco at our usergroup meeting and this
> very question came up! (slides at http://flamebot.com/blog)
> I will link to you or put these in a contrib dir (what do you think?)
I don't care. I don't think this will need updates, unless the skype
d-bus protocol gets changed in a fundamental way. So you might as well
put it in a contrib dir. That makes it more obvious and readily
available.
License is PD as far as my part is concerned. It is derived from
http://download.skype.com/share/devzone/example_linux.zip
which does not have any copyright or license notes.
However as it is a sample file from their API docs, I suppose this is
not a problem.
> >4. I also have the "microphone transmits noise" problem sometimes
> > (rarely). Could it be, that there is a missed byte that swaps high
> > and lowbyte? It sounded a bit like this to me.
> I think you are right. There is some kind of fundamental transport glitch.
If it gets annoying, I'll have a look at the btsco daemon and see if I
can introduce a signal that will purposefully skip a single byte thus
regaining sync (if my assumption is correct - I got to look at the
code first or get a clue about the transmission format) if I have a
noisy line.
[I just noticed, that the copying around is done in kernelspace. Got to
check it there, then.]
> >5. My cheap (EUR 22.- incl. VAT) LevelOne BLH-1000 Headset works fine,
> > except for the glitch just described. It ignores microphone level
> > setup, though. Loopback control works. Using the buttons, you can
> > only reach Speaker Level 12 (80%) - using the mixer you can go to
> > 100%.
> I added it to the list.
A nice addition for me would be a software mic-boost. The quality of the
sound is not bad, but (probably due to the ridiculously compact design
of my headset) the dynamic range is not used appropriately.
I'll have a look, if I can add something like a "--micboost" switch that
will just scale up the input before giving it to the sound device.
[ I have in the meantime done this - crude patch attached. Only use
if you know what it does and what you are doing.
It cures my problem, but it's of course ugly.
What do you think about adding a third Mixer bar like "Mic Softboost"
which will allow to adjust a value by which the mic data gets scaled
between about *0.1 and *10.0?
This would allow for better usability for devices that ignore the mic
setup sequences when used with software that doesn't scale by itself.
If someone feels like implementing it, it might as well be a good idea
to provide some kind of dynamic compression?
]
Another thing I noticed (which is probably not btsco related, but more
of a general bluez problem, maybe even a general kernel problem) is,
that I now had two occasions where my USB subsystem became unresponsive
to a point where the machine froze.
I could still ping it, but mouse was unresponsive, and higher level
network protocols had also stopped working.
The syslogs say:
Aug 19 00:34:58 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 00:35:09 cupido kernel: uhci_hcd 0000:00:04.2: host system error, PCI problems?
Aug 19 00:35:09 cupido kernel: uhci_hcd 0000:00:04.2: host controller halted, very bad!
Aug 19 00:36:17 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 00:36:17 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 00:36:17 cupido kernel: snd-bt-sco: capture_trigger 0
Aug 19 00:36:17 cupido kernel: snd-bt-sco: setting capture to NULL
Aug 19 00:36:17 cupido kernel: snd-bt-sco: Disposing of previous socket count 2
Aug 19 00:36:59 cupido kernel: snd-bt-sco: playback_open
Aug 19 00:36:59 cupido kernel: snd-bt-sco: capture_open
Aug 19 00:36:59 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 672 count: 42
Aug 19 00:36:59 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 00:36:59 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 00:37:19 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 00:37:19 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 00:38:01 cupido /USR/SBIN/CRON[8130]: (mail) CMD ( if [ -x /usr/lib/exim/exim3 -a -f /etc/exim/exim.conf ]; then /usr/lib/exim/exim3 -q ; fi)
Aug 19 00:38:17 cupido kernel: hci_cmd_task: hci0 command tx timeout
Aug 19 00:39:12 cupido kernel: usb 1-2: USB disconnect, address 2
Aug 19 00:39:12 cupido kernel: usb 1-2.3: USB disconnect, address 8
Aug 19 00:39:12 cupido kernel: usb 1-2.6: USB disconnect, address 13
Aug 19 00:39:41 cupido kernel: __tx_submit: hci0 tx submit failed urb f53cabf4 type 1 err -19
Aug 19 00:39:41 cupido kernel: __tx_submit: hci0 tx submit failed urb f53cabf4 type 1 err -19
[about 10 more similar messages]
[at this point the system was still responsive to mouse/keyboard (PS/2
based) - I think I tried to reset the USB hub (Noname, called USB1007,
Vendor 05e3, Product 0604, Revision 0.05) by pulling it's inbound plug,
as it's link LEDs looked wrong (all off)]
Aug 19 00:39:41 cupido hcid[7720]: HCI dev 0 down
Aug 19 00:39:41 cupido hcid[7720]: Stoping security manager 0
Aug 19 00:39:42 cupido hcid[7720]: HCI dev 0 unregistered
Aug 19 00:39:43 cupido kernel: usb 1-2: new full speed USB device using uhci_hcd and address 14
Aug 19 00:39:43 cupido kernel: hub 1-2:1.0: USB hub found
Aug 19 00:39:43 cupido kernel: hub 1-2:1.0: 7 ports detected
Aug 19 00:39:43 cupido kernel: usb 1-2.3: new full speed USB device using uhci_hcd and address 15
Aug 19 00:39:43 cupido kernel: drivers/usb/media/ov511.c: USB OV518 video device found
Aug 19 00:39:43 cupido kernel: drivers/usb/media/ov511.c: Device revision 1
Aug 19 00:39:43 cupido kernel: drivers/usb/media/ov511.c: Compression required with OV518...enabling
Aug 19 00:39:44 cupido usb.agent[8289]: ov511: already loaded
Aug 19 00:39:45 cupido usb.agent[8322]: usbcore: already loaded
Aug 19 00:39:45 cupido kernel: drivers/usb/media/ov511.c: Sensor is an OV6630AF
Aug 19 00:39:46 cupido kernel: drivers/usb/media/ov511.c: Device at usb-0000:00:04.2-2.3 registered to minor 0
Aug 19 00:39:46 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 16
Aug 19 00:39:46 cupido kernel: Unable to load interpreter /lib/ld-linux.so.2
Aug 19 00:39:46 cupido kernel: Unable to handle kernel paging request at virtual address 000a7d02
Aug 19 00:39:46 cupido kernel: printing eip:
Aug 19 00:39:46 cupido kernel: f88821e9
Aug 19 00:39:46 cupido kernel: *pde = 00000000
Aug 19 00:39:46 cupido kernel: Oops: 0000 [#1]
Aug 19 00:39:46 cupido kernel: PREEMPT
Aug 19 00:39:46 cupido kernel: Modules linked in: hci_usb sco tun rfcomm l2cap actisys_sir irtty_sir sir_dev irda crc_ccitt sg via_agp nls_iso8859_1 nls_cp437 vfat eth1394 w83781d i2c_sensor i2c_viapro i2c_core usb_storage msr microcode cpuid smbfs msdos fat video1394 raw1394 ohci1394 ieee1394 mga drm agpgart parport_pc lp parport snd_bt_sco snd_hwdep usbmouse ide_cd via82cxxx ide_core 8250_pci 8250 serial_core snd_ens1371 snd_rawmidi snd_ac97_codec snd_pcm_oss ov511 videodev snd_mixer_oss bluetooth snd_pcm snd_timer snd snd_page_alloc uhci_hcd usbcore evdev
Aug 19 00:39:46 cupido kernel: CPU: 0
Aug 19 00:39:46 cupido kernel: EIP: 0060:[pg0+944181737/1069470720] Not tainted VLI
Aug 19 00:39:46 cupido kernel: EFLAGS: 00010246 (2.6.12.5)
Aug 19 00:39:46 cupido kernel: EIP is at usb_disable_interface+0x49/0x80 [usbcore]
Aug 19 00:39:46 cupido kernel: eax: 00000000 ebx: eec94848 ecx: 00000282 edx: 000a7d00
Aug 19 00:39:46 cupido kernel: esi: 00000001 edi: eb595000 ebp: eec94880 esp: f70abd74
Aug 19 00:39:46 cupido kernel: ds: 007b es: 007b ss: 0068
Aug 19 00:39:46 cupido kernel: Process khubd (pid: 1138, threadinfo=f70aa000 task=f70425e0)
Aug 19 00:39:46 cupido kernel: Stack: 0000000b 0000000b 00000000 eb595000 00000001 f8882533 eb595000 ea4c00a0
Aug 19 00:39:46 cupido kernel: 0000000b 00000001 00000002 00000001 00000000 00000000 00001388 ea4c00a0
Aug 19 00:39:46 cupido kernel: f88a5ec0 ea4c0ba0 00000002 eb595000 f88a4c09 eb595000 00000001 00000002
Aug 19 00:39:46 cupido kernel: Call Trace:
Aug 19 00:39:46 cupido usb.agent[8388]: hci_usb: already loaded
Aug 19 00:39:47 cupido kernel: [pg0+944182579/1069470720] usb_set_interface+0xe3/0x190 [usbcore]
Aug 19 00:39:47 cupido kernel: [pg0+944323593/1069470720] hci_usb_probe+0x4a9/0x5e0 [hci_usb]
Aug 19 00:39:47 cupido kernel: [new_inode+36/176] new_inode+0x24/0xb0
Aug 19 00:39:47 cupido kernel: [sysfs_new_dirent+41/128] sysfs_new_dirent+0x29/0x80
Aug 19 00:39:47 cupido kernel: [pg0+944148612/1069470720] usb_probe_interface+0x64/0x80 [usbcore]
Aug 19 00:39:47 cupido kernel: [driver_probe_device+47/128] driver_probe_device+0x2f/0x80
Aug 19 00:39:47 cupido kernel: [device_attach+123/208] device_attach+0x7b/0xd0
Aug 19 00:39:47 cupido kernel: [kobject_get+23/32] kobject_get+0x17/0x20
Aug 19 00:39:47 cupido kernel: [bus_add_device+95/208] bus_add_device+0x5f/0xd0
Aug 19 00:39:47 cupido kernel: [device_pm_add+85/144] device_pm_add+0x55/0x90
Aug 19 00:39:47 cupido kernel: [device_add+232/384] device_add+0xe8/0x180
Aug 19 00:39:47 cupido kernel: [pg0+944183698/1069470720] usb_set_configuration+0x262/0x560 [usbcore]
Aug 19 00:39:47 cupido kernel: [pg0+944159474/1069470720] usb_new_device+0x142/0x1e0 [usbcore]
Aug 19 00:39:47 cupido kernel: [pg0+944163887/1069470720] hub_port_connect_change+0x36f/0x430 [usbcore]
Aug 19 00:39:47 cupido kernel: [pg0+944164761/1069470720] hub_events+0x2a9/0x440 [usbcore]
Aug 19 00:39:47 cupido kernel: [pg0+944165247/1069470720] hub_thread+0x4f/0x110 [usbcore]
Aug 19 00:39:47 cupido kernel: [autoremove_wake_function+0/96] autoremove_wake_function+0x0/0x60
Aug 19 00:39:47 cupido kernel: [pg0+944165168/1069470720] hub_thread+0x0/0x110 [usbcore]
Aug 19 00:39:47 cupido kernel: [kernel_thread_helper+5/12] kernel_thread_helper+0x5/0xc
Aug 19 00:39:47 cupido kernel: Code: 75 10 8b 5c 24 08 8b 74 24 0c 8b 7c 24 10 83 c4 14 c3 31 f6 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 8b 53 0c 89 f0 46 c1 e0 05 <0f> b6 44 10 02 89 3c 24 89 44 24 04 e8 36 ff ff ff 0f b6 43 04
Aug 19 00:40:41 cupido sdpd[7722]: terminating...
Aug 19 00:40:42 cupido hcid[8451]: Bluetooth HCI daemon
Aug 19 00:40:42 cupido sdpd[8453]: Bluetooth SDP daemon
Aug 19 00:41:32 cupido kernel: <6>usbcore: deregistering driver hci_usb
Aug 19 00:43:08 cupido kernel: usbcore: deregistering driver ov511
Aug 19 00:43:52 cupido modprobe: FATAL: Error running install command for sound_slot_2
Aug 19 00:43:52 cupido modprobe: FATAL: Error running install command for sound_slot_2
Aug 19 00:48:02 cupido kernel: mtrr: no MTRR for e2000000,1000000 found
Aug 19 00:48:02 cupido gdm[4128]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0
Aug 19 00:48:05 cupido kernel: mtrr: no MTRR for e2000000,1000000 found
Aug 19 00:48:06 cupido kernel: atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
Aug 19 00:48:06 cupido kernel: atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
Aug 19 00:48:23 cupido gconfd (becka-www-5389): GConf server is not in use, shutting down.
Aug 19 00:48:23 cupido gconfd (becka-www-5389): Exiting
Aug 19 00:48:23 cupido shutdown[8537]: shutting down for system reboot
Aug 19 00:48:24 cupido init: Switching to runlevel: 6
Aug 19 00:48:27 cupido irattach: got SIGTERM or SIGINT
Aug 19 00:48:27 cupido irattach: exiting ...
Aug 19 00:48:27 cupido kernel: sirdev_put_instance
Aug 19 00:48:27 cupido kernel: irtty_close - ttyS1: irda line discipline closed
Aug 19 00:48:28 cupido ovpn-client[5651]: event_wait : Interrupted system call (code=4)
Aug 19 00:48:28 cupido ovpn-client[5651]: TCP/UDP: Closing socket
Aug 19 00:48:28 cupido ovpn-client[5651]: /sbin/route del -net 192.168.111.0 netmask 255.255.255.0
Aug 19 00:48:28 cupido ovpn-client[5651]: ERROR: Linux route delete command failed: shell command exited with error status: 7
Aug 19 00:48:28 cupido ovpn-client[5651]: /sbin/route del -net 192.168.112.0 netmask 255.255.255.0
Aug 19 00:48:28 cupido ovpn-client[5651]: ERROR: Linux route delete command failed: shell command exited with error status: 7
Aug 19 00:48:28 cupido ovpn-client[5651]: Closing TUN/TAP interface
Aug 19 00:48:29 cupido ovpn-client[5651]: SIGTERM[hard,] received, process exiting
Aug 19 00:48:29 cupido xfs[3884]: terminating
Aug 19 00:48:30 cupido ntpd[4026]: ntpd exiting on signal 15
Aug 19 01:08:33 cupido syslogd 1.4.1#17: restart.
On another occasion, it went down more drastically:
Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:51:08 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 cou
Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:51:08 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:59:52 cupido syslogd 1.4.1#17: restart.
However before that happened, I see a few occurences of
hci_scodata_packet: hci0 SCO packet for unknown connection handle [varies]
and a bit later:
snd-bt-sco: Disposing of previous socket count 3
snd-bt-sco: file_count is 1 (expected 3)
shortly before it went down, I got:
Aug 19 21:50:33 cupido kernel: hub 1-2:1.0: port 6 disabled by hub (EMI?), re-enabling...
Aug 19 21:50:33 cupido kernel: usb 1-2.6: USB disconnect, address 10
Aug 19 21:50:33 cupido kernel: __tx_submit: hci0 tx submit failed urb f46d5214 type 3 err -19
Aug 19 21:50:33 cupido kernel: __tx_submit: hci0 tx submit failed urb f46d5214 type 3 err -19
Aug 19 21:50:33 cupido hcid[4121]: HCI dev 0 down
Aug 19 21:50:33 cupido hcid[4121]: Stoping security manager 0
Aug 19 21:50:33 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:50:33 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:50:33 cupido hcid[4121]: HCI dev 0 unregistered
Aug 19 21:50:34 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 11
Aug 19 21:50:34 cupido kernel: usb 1-2.6: device descriptor read/64, error -71
Aug 19 21:50:34 cupido kernel: usb 1-2.6: device descriptor read/64, error -71
Aug 19 21:50:34 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 12
Aug 19 21:50:34 cupido kernel: usb 1-2.6: device descriptor read/64, error -71
Aug 19 21:50:34 cupido kernel: usb 1-2.6: device descriptor read/64, error -71
Aug 19 21:50:34 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 13
Aug 19 21:50:35 cupido kernel: usb 1-2.6: device not accepting address 13, error -71
Aug 19 21:50:35 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 14
Aug 19 21:50:35 cupido kernel: usb 1-2.6: device not accepting address 14, error -71
Aug 19 21:50:37 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 15
Aug 19 21:50:38 cupido hcid[4121]: HCI dev 0 registered
Aug 19 21:50:38 cupido usb.agent[26062]: hci_usb: already loaded
Aug 19 21:50:38 cupido hcid[4121]: HCI dev 0 up
Aug 19 21:50:38 cupido usb.agent[26105]: hci_usb: already loaded
Aug 19 21:50:38 cupido hcid[4121]: Starting security manager 0
Aug 19 21:50:38 cupido usb.agent[26122]: hci_usb: already loaded
Aug 19 21:50:41 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 21:50:41 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 21:50:41 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:50:41 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800
Aug 19 21:50:41 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:50:41 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:50:45 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 21:50:45 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 21:50:45 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:50:45 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800
Aug 19 21:50:45 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:50:45 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:50:46 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 21:50:46 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 21:50:46 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:50:46 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800
Aug 19 21:50:46 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:50:46 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:50:49 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 21:50:49 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 21:50:49 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:50:49 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800
Aug 19 21:50:49 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:50:49 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:50:51 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 21:50:51 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 21:50:51 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:50:51 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800
Aug 19 21:50:51 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:50:51 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:50:56 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 21:50:56 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 21:50:56 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:50:56 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800
Aug 19 21:50:56 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:50:56 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:50:57 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 21:50:57 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 21:50:58 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:50:58 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800
Aug 19 21:50:58 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:50:58 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:51:02 cupido hcid[4121]: link_key_request (sba=00:09:DD:10:4E:8C, dba=00:0A:94:93:74:B7)
Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 21:51:08 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:51:08 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800
Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:51:08 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:59:52 cupido syslogd 1.4.1#17: restart.
I'm not sure, what that means. It seems to be related to the USB Hub,
which also usually shows erratic LED Link display when that happens.
However I haven't seen this before using the BT dongle, and I was using
it for a webcam before, so it shouldn't be related just to the larger
amounts of traffic.
I have also noticed my system hanging on shutdown when trying to unload
the rfcomm stuff. This is usually cured by resetting the USB hub.
This looks like this:
Aug 21 04:12:14 cupido xfs[3928]: terminating
Aug 21 04:12:15 cupido ntpd[4072]: ntpd exiting on signal 15
Aug 21 04:13:24 cupido kernel: usb 1-2: USB disconnect, address 2
Aug 21 04:13:24 cupido kernel: usb 1-2.3: USB disconnect, address 3
Aug 21 04:13:24 cupido kernel: usb 1-2.6: USB disconnect, address 4
Aug 21 04:13:26 cupido kernel: 1-2.6: usbfs: USBDEVFS_CONTROL failed cmd hid2hci rqt 64 rq 0 len 0 ret -110
Aug 21 04:13:26 cupido sdpd[4103]: terminating...
Aug 21 04:13:26 cupido rpc.statd[4057]: Caught signal 15, un-registering and exiting.
CU, ANdy
Hi Brad,
> > I'd suggest to put a simple exaple there, how the results from
> > "hciconfig hci0 revision" should look like. I.e. that the line
> > "SCO mapping: HCI" should exist.
> I cleaned this up a bit.
Great. That should be clear now.
> I don't know of such a command. /etc/bluetooth/link_key is how the keys
> are stored in the older daemon so I've mentioned both in the docs.
Yeah - this might as well help.
> >3. I have written a small Python-Script and a .btscorc
> Perfect. I gave a talk about btsco at our usergroup meeting and this
> very question came up! (slides at http://flamebot.com/blog)
> I will link to you or put these in a contrib dir (what do you think?)
I don't care. I don't think this will need updates, unless the skype
d-bus protocol gets changed in a fundamental way. So you might as well
put it in a contrib dir. That makes it more obvious and readily
available.
License is PD as far as my part is concerned. It is derived from
http://download.skype.com/share/devzone/example_linux.zip
which does not have any copyright or license notes.
However as it is a sample file from their API docs, I suppose this is
not a problem.
> >4. I also have the "microphone transmits noise" problem sometimes
> > (rarely). Could it be, that there is a missed byte that swaps high
> > and lowbyte? It sounded a bit like this to me.
> I think you are right. There is some kind of fundamental transport glitch.
If it gets annoying, I'll have a look at the btsco daemon and see if I
can introduce a signal that will purposefully skip a single byte thus
regaining sync (if my assumption is correct - I got to look at the
code first or get a clue about the transmission format) if I have a
noisy line.
> >5. My cheap (EUR 22.- incl. VAT) LevelOne BLH-1000 Headset works fine,
> > except for the glitch just described. It ignores microphone level
> > setup, though. Loopback control works. Using the buttons, you can
> > only reach Speaker Level 12 (80%) - using the mixer you can go to
> > 100%.
> I added it to the list.
A nice addition for me would be a software mic-boost. The quality of the
sound is not bad, but (probably due to the ridiculously compact design
of my headset) the dynamic range is not used appropriately.
I'll have a look, if I can add something like a "--micboost" switch that
will just scale up the input before giving it to the sound device.
Another thing I noticed (which is probably not btsco related, but more
of a general bluez problem, maybe even a general kernel problem) is,
that I now had two occasions where my USB subsystem became unresponsive
to a point where the machine froze.
I could still ping it, but mouse was unresponsive, and higher level
network protocols had also stopped working.
The syslogs say:
Aug 19 00:34:58 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 00:35:09 cupido kernel: uhci_hcd 0000:00:04.2: host system error, PCI problems?
Aug 19 00:35:09 cupido kernel: uhci_hcd 0000:00:04.2: host controller halted, very bad!
Aug 19 00:36:17 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 00:36:17 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 00:36:17 cupido kernel: snd-bt-sco: capture_trigger 0
Aug 19 00:36:17 cupido kernel: snd-bt-sco: setting capture to NULL
Aug 19 00:36:17 cupido kernel: snd-bt-sco: Disposing of previous socket count 2
Aug 19 00:36:59 cupido kernel: snd-bt-sco: playback_open
Aug 19 00:36:59 cupido kernel: snd-bt-sco: capture_open
Aug 19 00:36:59 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 672 count: 42
Aug 19 00:36:59 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 00:36:59 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 00:37:19 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 00:37:19 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 00:38:01 cupido /USR/SBIN/CRON[8130]: (mail) CMD ( if [ -x /usr/lib/exim/exim3 -a -f /etc/exim/exim.conf ]; then /usr/lib/exim/exim3 -q ; fi)
Aug 19 00:38:17 cupido kernel: hci_cmd_task: hci0 command tx timeout
Aug 19 00:39:12 cupido kernel: usb 1-2: USB disconnect, address 2
Aug 19 00:39:12 cupido kernel: usb 1-2.3: USB disconnect, address 8
Aug 19 00:39:12 cupido kernel: usb 1-2.6: USB disconnect, address 13
Aug 19 00:39:41 cupido kernel: __tx_submit: hci0 tx submit failed urb f53cabf4 type 1 err -19
Aug 19 00:39:41 cupido kernel: __tx_submit: hci0 tx submit failed urb f53cabf4 type 1 err -19
[about 10 more similar messages]
[at this point the system was still responsive to mouse/keyboard (PS/2
based) - I think I tried to reset the USB hub (Noname, called USB1007,
Vendor 05e3, Product 0604, Revision 0.05) by pulling it's inbound plug,
as it's link LEDs looked wrong (all off)]
Aug 19 00:39:41 cupido hcid[7720]: HCI dev 0 down
Aug 19 00:39:41 cupido hcid[7720]: Stoping security manager 0
Aug 19 00:39:42 cupido hcid[7720]: HCI dev 0 unregistered
Aug 19 00:39:43 cupido kernel: usb 1-2: new full speed USB device using uhci_hcd and address 14
Aug 19 00:39:43 cupido kernel: hub 1-2:1.0: USB hub found
Aug 19 00:39:43 cupido kernel: hub 1-2:1.0: 7 ports detected
Aug 19 00:39:43 cupido kernel: usb 1-2.3: new full speed USB device using uhci_hcd and address 15
Aug 19 00:39:43 cupido kernel: drivers/usb/media/ov511.c: USB OV518 video device found
Aug 19 00:39:43 cupido kernel: drivers/usb/media/ov511.c: Device revision 1
Aug 19 00:39:43 cupido kernel: drivers/usb/media/ov511.c: Compression required with OV518...enabling
Aug 19 00:39:44 cupido usb.agent[8289]: ov511: already loaded
Aug 19 00:39:45 cupido usb.agent[8322]: usbcore: already loaded
Aug 19 00:39:45 cupido kernel: drivers/usb/media/ov511.c: Sensor is an OV6630AF
Aug 19 00:39:46 cupido kernel: drivers/usb/media/ov511.c: Device at usb-0000:00:04.2-2.3 registered to minor 0
Aug 19 00:39:46 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 16
Aug 19 00:39:46 cupido kernel: Unable to load interpreter /lib/ld-linux.so.2
Aug 19 00:39:46 cupido kernel: Unable to handle kernel paging request at virtual address 000a7d02
Aug 19 00:39:46 cupido kernel: printing eip:
Aug 19 00:39:46 cupido kernel: f88821e9
Aug 19 00:39:46 cupido kernel: *pde = 00000000
Aug 19 00:39:46 cupido kernel: Oops: 0000 [#1]
Aug 19 00:39:46 cupido kernel: PREEMPT
Aug 19 00:39:46 cupido kernel: Modules linked in: hci_usb sco tun rfcomm l2cap actisys_sir irtty_sir sir_dev irda crc_ccitt sg via_agp nls_iso8859_1 nls_cp437 vfat eth1394 w83781d i2c_sensor i2c_viapro i2c_core usb_storage msr microcode cpuid smbfs msdos fat video1394 raw1394 ohci1394 ieee1394 mga drm agpgart parport_pc lp parport snd_bt_sco snd_hwdep usbmouse ide_cd via82cxxx ide_core 8250_pci 8250 serial_core snd_ens1371 snd_rawmidi snd_ac97_codec snd_pcm_oss ov511 videodev snd_mixer_oss bluetooth snd_pcm snd_timer snd snd_page_alloc uhci_hcd usbcore evdev
Aug 19 00:39:46 cupido kernel: CPU: 0
Aug 19 00:39:46 cupido kernel: EIP: 0060:[pg0+944181737/1069470720] Not tainted VLI
Aug 19 00:39:46 cupido kernel: EFLAGS: 00010246 (2.6.12.5)
Aug 19 00:39:46 cupido kernel: EIP is at usb_disable_interface+0x49/0x80 [usbcore]
Aug 19 00:39:46 cupido kernel: eax: 00000000 ebx: eec94848 ecx: 00000282 edx: 000a7d00
Aug 19 00:39:46 cupido kernel: esi: 00000001 edi: eb595000 ebp: eec94880 esp: f70abd74
Aug 19 00:39:46 cupido kernel: ds: 007b es: 007b ss: 0068
Aug 19 00:39:46 cupido kernel: Process khubd (pid: 1138, threadinfo=f70aa000 task=f70425e0)
Aug 19 00:39:46 cupido kernel: Stack: 0000000b 0000000b 00000000 eb595000 00000001 f8882533 eb595000 ea4c00a0
Aug 19 00:39:46 cupido kernel: 0000000b 00000001 00000002 00000001 00000000 00000000 00001388 ea4c00a0
Aug 19 00:39:46 cupido kernel: f88a5ec0 ea4c0ba0 00000002 eb595000 f88a4c09 eb595000 00000001 00000002
Aug 19 00:39:46 cupido kernel: Call Trace:
Aug 19 00:39:46 cupido usb.agent[8388]: hci_usb: already loaded
Aug 19 00:39:47 cupido kernel: [pg0+944182579/1069470720] usb_set_interface+0xe3/0x190 [usbcore]
Aug 19 00:39:47 cupido kernel: [pg0+944323593/1069470720] hci_usb_probe+0x4a9/0x5e0 [hci_usb]
Aug 19 00:39:47 cupido kernel: [new_inode+36/176] new_inode+0x24/0xb0
Aug 19 00:39:47 cupido kernel: [sysfs_new_dirent+41/128] sysfs_new_dirent+0x29/0x80
Aug 19 00:39:47 cupido kernel: [pg0+944148612/1069470720] usb_probe_interface+0x64/0x80 [usbcore]
Aug 19 00:39:47 cupido kernel: [driver_probe_device+47/128] driver_probe_device+0x2f/0x80
Aug 19 00:39:47 cupido kernel: [device_attach+123/208] device_attach+0x7b/0xd0
Aug 19 00:39:47 cupido kernel: [kobject_get+23/32] kobject_get+0x17/0x20
Aug 19 00:39:47 cupido kernel: [bus_add_device+95/208] bus_add_device+0x5f/0xd0
Aug 19 00:39:47 cupido kernel: [device_pm_add+85/144] device_pm_add+0x55/0x90
Aug 19 00:39:47 cupido kernel: [device_add+232/384] device_add+0xe8/0x180
Aug 19 00:39:47 cupido kernel: [pg0+944183698/1069470720] usb_set_configuration+0x262/0x560 [usbcore]
Aug 19 00:39:47 cupido kernel: [pg0+944159474/1069470720] usb_new_device+0x142/0x1e0 [usbcore]
Aug 19 00:39:47 cupido kernel: [pg0+944163887/1069470720] hub_port_connect_change+0x36f/0x430 [usbcore]
Aug 19 00:39:47 cupido kernel: [pg0+944164761/1069470720] hub_events+0x2a9/0x440 [usbcore]
Aug 19 00:39:47 cupido kernel: [pg0+944165247/1069470720] hub_thread+0x4f/0x110 [usbcore]
Aug 19 00:39:47 cupido kernel: [autoremove_wake_function+0/96] autoremove_wake_function+0x0/0x60
Aug 19 00:39:47 cupido kernel: [pg0+944165168/1069470720] hub_thread+0x0/0x110 [usbcore]
Aug 19 00:39:47 cupido kernel: [kernel_thread_helper+5/12] kernel_thread_helper+0x5/0xc
Aug 19 00:39:47 cupido kernel: Code: 75 10 8b 5c 24 08 8b 74 24 0c 8b 7c 24 10 83 c4 14 c3 31 f6 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 8b 53 0c 89 f0 46 c1 e0 05 <0f> b6 44 10 02 89 3c 24 89 44 24 04 e8 36 ff ff ff 0f b6 43 04
Aug 19 00:40:41 cupido sdpd[7722]: terminating...
Aug 19 00:40:42 cupido hcid[8451]: Bluetooth HCI daemon
Aug 19 00:40:42 cupido sdpd[8453]: Bluetooth SDP daemon
Aug 19 00:41:32 cupido kernel: <6>usbcore: deregistering driver hci_usb
Aug 19 00:43:08 cupido kernel: usbcore: deregistering driver ov511
Aug 19 00:43:52 cupido modprobe: FATAL: Error running install command for sound_slot_2
Aug 19 00:43:52 cupido modprobe: FATAL: Error running install command for sound_slot_2
Aug 19 00:48:02 cupido kernel: mtrr: no MTRR for e2000000,1000000 found
Aug 19 00:48:02 cupido gdm[4128]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0
Aug 19 00:48:05 cupido kernel: mtrr: no MTRR for e2000000,1000000 found
Aug 19 00:48:06 cupido kernel: atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
Aug 19 00:48:06 cupido kernel: atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
Aug 19 00:48:23 cupido gconfd (becka-www-5389): GConf server is not in use, shutting down.
Aug 19 00:48:23 cupido gconfd (becka-www-5389): Exiting
Aug 19 00:48:23 cupido shutdown[8537]: shutting down for system reboot
Aug 19 00:48:24 cupido init: Switching to runlevel: 6
Aug 19 00:48:27 cupido irattach: got SIGTERM or SIGINT
Aug 19 00:48:27 cupido irattach: exiting ...
Aug 19 00:48:27 cupido kernel: sirdev_put_instance
Aug 19 00:48:27 cupido kernel: irtty_close - ttyS1: irda line discipline closed
Aug 19 00:48:28 cupido ovpn-client[5651]: event_wait : Interrupted system call (code=4)
Aug 19 00:48:28 cupido ovpn-client[5651]: TCP/UDP: Closing socket
Aug 19 00:48:28 cupido ovpn-client[5651]: /sbin/route del -net 192.168.111.0 netmask 255.255.255.0
Aug 19 00:48:28 cupido ovpn-client[5651]: ERROR: Linux route delete command failed: shell command exited with error status: 7
Aug 19 00:48:28 cupido ovpn-client[5651]: /sbin/route del -net 192.168.112.0 netmask 255.255.255.0
Aug 19 00:48:28 cupido ovpn-client[5651]: ERROR: Linux route delete command failed: shell command exited with error status: 7
Aug 19 00:48:28 cupido ovpn-client[5651]: Closing TUN/TAP interface
Aug 19 00:48:29 cupido ovpn-client[5651]: SIGTERM[hard,] received, process exiting
Aug 19 00:48:29 cupido xfs[3884]: terminating
Aug 19 00:48:30 cupido ntpd[4026]: ntpd exiting on signal 15
Aug 19 01:08:33 cupido syslogd 1.4.1#17: restart.
On another occasion, it went down more drastically:
Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:51:08 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 cou
Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:51:08 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:59:52 cupido syslogd 1.4.1#17: restart.
However before that happened, I see a few occurences of
hci_scodata_packet: hci0 SCO packet for unknown connection handle [varies]
and a bit later:
snd-bt-sco: Disposing of previous socket count 3
snd-bt-sco: file_count is 1 (expected 3)
shortly before it went down, I got:
Aug 19 21:50:33 cupido kernel: hub 1-2:1.0: port 6 disabled by hub (EMI?), re-enabling...
Aug 19 21:50:33 cupido kernel: usb 1-2.6: USB disconnect, address 10
Aug 19 21:50:33 cupido kernel: __tx_submit: hci0 tx submit failed urb f46d5214 type 3 err -19
Aug 19 21:50:33 cupido kernel: __tx_submit: hci0 tx submit failed urb f46d5214 type 3 err -19
Aug 19 21:50:33 cupido hcid[4121]: HCI dev 0 down
Aug 19 21:50:33 cupido hcid[4121]: Stoping security manager 0
Aug 19 21:50:33 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:50:33 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:50:33 cupido hcid[4121]: HCI dev 0 unregistered
Aug 19 21:50:34 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 11
Aug 19 21:50:34 cupido kernel: usb 1-2.6: device descriptor read/64, error -71
Aug 19 21:50:34 cupido kernel: usb 1-2.6: device descriptor read/64, error -71
Aug 19 21:50:34 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 12
Aug 19 21:50:34 cupido kernel: usb 1-2.6: device descriptor read/64, error -71
Aug 19 21:50:34 cupido kernel: usb 1-2.6: device descriptor read/64, error -71
Aug 19 21:50:34 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 13
Aug 19 21:50:35 cupido kernel: usb 1-2.6: device not accepting address 13, error -71
Aug 19 21:50:35 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 14
Aug 19 21:50:35 cupido kernel: usb 1-2.6: device not accepting address 14, error -71
Aug 19 21:50:37 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 15
Aug 19 21:50:38 cupido hcid[4121]: HCI dev 0 registered
Aug 19 21:50:38 cupido usb.agent[26062]: hci_usb: already loaded
Aug 19 21:50:38 cupido hcid[4121]: HCI dev 0 up
Aug 19 21:50:38 cupido usb.agent[26105]: hci_usb: already loaded
Aug 19 21:50:38 cupido hcid[4121]: Starting security manager 0
Aug 19 21:50:38 cupido usb.agent[26122]: hci_usb: already loaded
Aug 19 21:50:41 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 21:50:41 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 21:50:41 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:50:41 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800
Aug 19 21:50:41 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:50:41 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:50:45 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 21:50:45 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 21:50:45 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:50:45 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800
Aug 19 21:50:45 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:50:45 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:50:46 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 21:50:46 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 21:50:46 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:50:46 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800
Aug 19 21:50:46 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:50:46 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:50:49 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 21:50:49 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 21:50:49 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:50:49 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800
Aug 19 21:50:49 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:50:49 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:50:51 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 21:50:51 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 21:50:51 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:50:51 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800
Aug 19 21:50:51 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:50:51 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:50:56 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 21:50:56 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 21:50:56 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:50:56 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800
Aug 19 21:50:56 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:50:56 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:50:57 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 21:50:57 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 21:50:58 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:50:58 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800
Aug 19 21:50:58 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:50:58 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:51:02 cupido hcid[4121]: link_key_request (sba=00:09:DD:10:4E:8C, dba=00:0A:94:93:74:B7)
Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_trigger 0
Aug 19 21:51:08 cupido kernel: snd-bt-sco: setting playback to NULL
Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_open
Aug 19 21:51:08 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800
Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_trigger 1
Aug 19 21:51:08 cupido kernel: snd-bt-sco: setting playback to bspcm
Aug 19 21:59:52 cupido syslogd 1.4.1#17: restart.
I'm not sure, what that means. It seems to be related to the USB Hub,
which also usually shows erratic LED Link display when that happens.
However I haven't seen this before using the BT dongle, and I was using
it for a webcam before, so it shouldn't be related just to the larger
amounts of traffic.
I have also noticed my system hanging on shutdown when trying to unload
the rfcomm stuff. This is usually cured by resetting the USB hub.
This looks like this:
Aug 21 04:12:14 cupido xfs[3928]: terminating
Aug 21 04:12:15 cupido ntpd[4072]: ntpd exiting on signal 15
Aug 21 04:13:24 cupido kernel: usb 1-2: USB disconnect, address 2
Aug 21 04:13:24 cupido kernel: usb 1-2.3: USB disconnect, address 3
Aug 21 04:13:24 cupido kernel: usb 1-2.6: USB disconnect, address 4
Aug 21 04:13:26 cupido kernel: 1-2.6: usbfs: USBDEVFS_CONTROL failed cmd hid2hci rqt 64 rq 0 len 0 ret -110
Aug 21 04:13:26 cupido sdpd[4103]: terminating...
Aug 21 04:13:26 cupido rpc.statd[4057]: Caught signal 15, un-registering and exiting.
CU, ANdy
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Andreas,
> I've played around with btsco the last few days - now it sort of works
> like intended.
great
> I got the following comments about the procedure:
>
> 1. I'd like to suggest to put the comment about compatible dongles on
> the btsco website a little clearer.
>
> "If it doesn't say anything at all about SCO mapping, " wasn't clear
> to me (being a bluetooth newbie), as it was "displaying something
> with SCO" (i.e. the MTU, but I didn't grasp the difference at first,
> as my first adapter didn't show more than the first 2 lines).
>
> I'd suggest to put a simple exaple there, how the results from
> "hciconfig hci0 revision" should look like. I.e. that the line
> "SCO mapping: HCI" should exist.
I cleaned this up a bit.
> A: Remove the line in /var/lib/bluetooth/[my-bdaddr]/linkkeys that is
> corresponding to the device that doesn't want to pair. BlueZ thinks it
> is already paired, but the Link-Key does not match.
>
> Another - possibly very interesting - solution would be to allow to
> change the bdaddr in software. This would allow me to fake the same
> dongle to have two different bdaddrs depending on where I use it,
> thus allowing the headset to correctly pair with _both_ devices,
> so that I only need to move the dongle and everything works.
>
> Is there such a command? Please excuse, if it is obvious. I'm very
> new to this stuff.
I don't know of such a command. /etc/bluetooth/link_key is how the keys
are stored in the older daemon so I've mentioned both in the docs.
> 3. I have written a small Python-Script and a .btscorc
Perfect. I gave a talk about btsco at our usergroup meeting and this
very question came up! (slides at http://flamebot.com/blog)
I will link to you or put these in a contrib dir (what do you think?)
> 4. I also have the "microphone transmits noise" problem sometimes
> (rarely). Could it be, that there is a missed byte that swaps high
> and lowbyte? It sounded a bit like this to me.
I think you are right. There is some kind of fundamental transport glitch.
> 5. My cheap (EUR 22.- incl. VAT) LevelOne BLH-1000 Headset works fine,
> except for the glitch just described. It ignores microphone level
> setup, though. Loopback control works. Using the buttons, you can
> only reach Speaker Level 12 (80%) - using the mixer you can go to
> 100%.
I added it to the list.
thanks for all the contribs!
Brad
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Fri, Aug 19, 2005 at 09:38:55PM +0200, Andreas Beck wrote:
>Q: I have used the same bluetooth dongle on different machines or with
>different machine configurations (e.g. using windows). Now my device
>will refuse to pair again with the dongle.
>
>A: Remove the line in /var/lib/bluetooth/[my-bdaddr]/linkkeys that is
>corresponding to the device that doesn't want to pair. BlueZ thinks it
>is already paired, but the Link-Key does not match.
>
> I've seen a rather recent question that seems to be the same problem
> on bluez-users. However the hints there point to
> /etc/bluetooth/linkkeys - is this outdated or is this due to me using
> debian packages?
This was my experience. My device simply stopped working after I had used it
on another machine (same dongle though). I am also using the Debian packages
and there is no /etc/bluetooth/linkkeys.
For me, the problem manifested itself as "input/output error" messages when
trying most bluetooth commands or btsco. That's not a lot of help.
Eventually, somebody in my local users group tipped me off to the location of
the link keys as /var/lib/bluetooth and after deleting the offending files, my
headset could be paired again and it works now.
This seems, to me, to be a bug on both ends.
Bug 1) When you list the files in the Debian bluez packages,
/var/lib/bluetooth is not listed. This is a clear packaging bug as that
directory should definitely be listed therein, even if the package doesn't
actually ship with any files *in* that directory (they are program
generated).
Bug 2) When the bluez tools (hcitool I think) are told to remove a key, they
do not do so. That also made tracking down my problem harder. Thinking it
was a key issue, the command to delete the key was given, but it didn't seem
to do anything. Only manually deleting the file off the filesystem did the
trick.
--
--John Gruenenfelder Research Assistant, Steward Observatory, U of Arizona
[email protected]
Try Weasel Reader for PalmOS -- http://gutenpalm.sf.net
"This is the most fun I've had without being drenched in the blood
of my enemies!"
--Sam of Sam & Max
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel