Kernel Panic on Linux

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Using 3 bluetooth dongles with one instance of the same application for
each dongle.
2. Performing device inquiry and service search and OBEX Put simultaneously.
3. The SO freeze with a kernel panic.

What is the expected output? What do you see instead?
The system should be stable while the PC is on. The system raises a kernel
panic, locking the PC.

What BlueCove version are you using (include build number for SNAPSHOT)? On
what operating system and jvm? Is this 64-bit or 32-bit OS and jvm?
Using Bluecove release 2.0.3
Linux Debian 2.6.24-etchnhalf.1-686 32-bit
JVM (build 1.5.0_14-b03)

The motherboard in use is:
Model: VIA EPIA LN10000EG

http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=473

Please provide any additional information below.
The system is loaded from a pen-drive. When the system is started, it
indenifies the bluetooth dongles attached to the hardware and initialize
one instance of a java aplication which handle each device. Simultaneously,
the java application performs device inquiry, service search and obex put
operations. So, in an undefined time space, a kernel panic raises, freezing
the system. I could not identify the reason of the kernel panic, but I
think is related to use multiple dongles, becouse an error message is
logged when 2 dongle finds the same device on create a temporary file in
the same directory (bluez implementation).

Original issue reported on code.google.com by cleber.t...@gmail.com on 10 Nov 2008 at 6:17

Attachments:

• Imagem001.jpg
• syslog-erro.txt

[GoogleCodeExporter]

The error log is also been created.

Original comment by cleber.t...@gmail.com on 10 Nov 2008 at 6:19

Attachments:

• hs_err_pid2745.log

[GoogleCodeExporter]

Just to correct.
One instance of a java application is started for each identified bluetooth 
dongle.
If 3 dongles are attached then 3 instances will be started.

Original comment by cleber.t...@gmail.com on 10 Nov 2008 at 6:26

[GoogleCodeExporter]

I think this is bad idea to use 3 java instance.
Does one instance with multiple dongles working fine?
We specially created an extended API to allow this. 

http://bluecove.org/apidocs/com/intel/bluetooth/BlueCoveImpl.html#useThreadLocal
BluetoothStack()

I used to test the app with 1 java and two dongles.

What I will do next week is a test of up to 6 dongles in one JVM and will try 
to load
then full for receiving data.

Original comment by skarzhev...@gmail.com on 11 Nov 2008 at 3:33

[GoogleCodeExporter]

Thanks for the tip.

Change my app to use this extended API will spent much time. So first I'll try 
to
isolate the libbluecove in a specific dir insted using it inside of the JAR and 
make
all java app point to this file. I've read some coments, that just one instance 
of a
shared library should be loaded at time, and I think, using this library inside 
of a
JAR will load more than one instance. If this test do not workout, I'll try 
using the
extend API.

Thanks ;)

Original comment by cleber.t...@gmail.com on 11 Nov 2008 at 1:39

[GoogleCodeExporter]

I would not spend much time on this test since we don't have any shared memory 
in
library...

Any way what operation in particular device inquiry or  service search causing 
crash?
Try to synchronize instances using TCP/IP to avoid running this operations 
concurrently. 

Another suggestion is to use D-Bus bound bluecove version bluecove-bluez.

Original comment by skarzhev...@gmail.com on 11 Nov 2008 at 2:22

[GoogleCodeExporter]

When you talk about concurrently operations, You mean concurrently in the same
application instance? Or between diferent application, where each one handle a
diferent device?

Original comment by cleber.t...@gmail.com on 11 Nov 2008 at 3:59

[GoogleCodeExporter]

I think that in the same java instance I try to handle it correctly.
The problem may be when you different instances doing the same.
---
This may be a BlueZ problem and they solved it by using new D-Bus API...

Original comment by skarzhev...@gmail.com on 11 Nov 2008 at 4:06

[GoogleCodeExporter]

First I'm doing some tests without change the bluecove version and the new 
version of
the kernel. Maybe this can be an issue from the kernel. Any news about the 
problem,
I'll post here.

Thanks.

Original comment by cleber.t...@gmail.com on 12 Nov 2008 at 11:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi skarzhevskyy, making some intensive tests I could reproduce the kernel 
panic. 
Some specific phones, doing the pairing with the computer, freezes the kernel.
Sometimes with a kernel panic and sometimes not. I found some panic messages
at the syslog, which are related to multiple dongles creating simultaneous
connections with a specific device, becouse both dongles try to generate a file 
in
the same directory with the same name 'aclXXXXXXXXXXXX' (where XXXXXXXXXXXX is 
the
MAC of the target device), this BUG was fixed in the kernel 2.6.27.5.
Updating my kernel to this version, until now I could not reproduce the error 
again.
Hopefully the problem was fixed with the new version of the kernel and is not 
related
to the bluevoce library.

Thanks!

Original comment by cleber.t...@gmail.com on 14 Nov 2008 at 5:44

[GoogleCodeExporter]

Look at another BUG #50
http://code.google.com/p/bluecove/issues/detail?id=50

Maybe this will help?  Of So I will add this standard documentation.

--
Vlad

Original comment by skarzhev...@gmail.com on 14 Nov 2008 at 9:52

• Changed state: Accepted
• Added labels: OpSys-Linux

[GoogleCodeExporter]

Yep... I also made a comment on that issue. Which is related to use multiple
instances of an application with the library inside of the jar.

Original comment by cleber.t...@gmail.com on 14 Nov 2008 at 11:01