From: "J.D." <jd@freeshell.org>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: bluez-devel@lists.sourceforge.net
Subject: Re: Linux 2.4.27rc3 and Bluetooth
Date: Sat, 24 Jul 2004 02:36:27 -0500 (CDT) [thread overview]
Message-ID: <Pine.NEB.4.60.0407240115590.25504@norge.freeshell.org> (raw)
In-Reply-To: <1090055676.4558.15.camel@pegasus>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3326 bytes --]
Marcel,
Great! I'll CC this message to the mailing list.
Regarding the bt3c_cs error message, I merely have a personal
preference for error messages *without* a kernel panic. (aiee!)
I do appreciate you sharing your view on the specific problem.
I finally burned some time, studied the code, and created a
working patch for bt3c_cs.c (patch attached). It adds a test
in bt3c_release to check whether the DEV_CONFIG_PENDING bit of
link->state is clear before a call to bt3c_close. If the
DEV_CONFIG_PENDING bit is not clear, bt3c_open has failed,
and never succeeded in a call to hci_register_dev and friends.
When loading the firmware fails, the unpatched code ignores the
failure of bt3c_open, goes ahead with bt3c_close, and invokes
hci_unregister_dev and friends (despite the fact that
hci_register_dev was never called), thus provoking a kernel panic
with the NULL pointer dereference. (aiee!)
I suspect the 2.6 kernel may have the same problem by casual
inspection, but I have neither confirmed the existence of a problem
through testing of the 2.6 kernel, nor carefully traced that code
of Linux 2.6 for possible key differences.
With Linux 2.4 and the patch, I was able to temporarily erase
"/usr/lib/hotplug/firmware/BT3CPCC.bin", and insert the Bluetooth
card with a kernel error message, but no panic. After replacing
the file, and re-inserting the card, everything worked again.
(BTW, thank you Marcel for the tip on disabling the SCO support;
network transfers via bluetooth do not stall on that machine like
they did with SCO enabled.)
Kind regards,
- John
--
http://jodarom.sdf1.org/
On Sat, 17 Jul 2004, Marcel Holtmann wrote:
> Hi John,
>
>> Thank you for the information. I just wrote you because your name was on
>> the patch that caused my kernel to panic. What's the mailing list of
>> choice for bluetooth bugs in the Linux kernel?
>
> check the MAINTAINERS file in the Linux kernel source code. It says the
> BlueZ developer mailing list for the Bluetooth subsystem.
>
>> I issued the commands,
>>
>> cd /usr/lib/hotplug/firmware
>> ln -s /etc/bluetooth/firmware/BT3CPCC.bin BT3CPCC.bin
>>
>> and all was happy again.
>>
>> If you ever feel the initiative, making the system spit out a somewhat
>> succinct and relevant error message, as opposed to a full kernel panic
>> (aiee!) is much preferred by Linux users who desire to maintain the
>> illusion that Linux is a stable operating system. =)
>
> the error message was there:
>
> bt3c_cs: Firmware request failed.
> Unable to handle kernel NULL pointer ...
>
> So there must be a NULL pointer somewhere when the firmware can't be
> loaded into kernel space. I don't know if it is in the Bluetooth or the
> PCMCIA subsystem. I have no 2.4 system where I can check this.
>
>> ... but personally I'm satisfied at the moment. At least on a different
>> machine (running 2.4.27rc2), when the bluetooth USB device randomly locks
>> during repeated or extended transmissions, a nice message appears in the
>> log, ("kernel: NETDEV WATCHDOG: bnep0: transmit timed out"), and the
>> device works again after physically being unplugged and plugged back in
>> again.
>
> Maybe it helps if you compile your kernel without the SCO support option
> for the hci_usb driver. Disable CONFIG_BLUEZ_HCIUSB_SCO.
>
> Regards
>
> Marcel
>
>
[-- Attachment #2: kernel patch - bt3c_cs - missing firmware? Don't panic! --]
[-- Type: TEXT/PLAIN, Size: 504 bytes --]
diff -urN kernel-source-2.4.27-rc3.orig/drivers/bluetooth/bt3c_cs.c kernel-source-2.4.27-rc3/drivers/bluetooth/bt3c_cs.c
--- kernel-source-2.4.27-rc3.orig/drivers/bluetooth/bt3c_cs.c Sat Jun 26 03:53:03 2004
+++ kernel-source-2.4.27-rc3/drivers/bluetooth/bt3c_cs.c Fri Jul 23 23:16:03 2004
@@ -896,7 +896,8 @@
bt3c_info_t *info = link->priv;
if (link->state & DEV_PRESENT)
- bt3c_close(info);
+ if (!(link->state & DEV_CONFIG_PENDING))
+ bt3c_close(info);
MOD_DEC_USE_COUNT;
next parent reply other threads:[~2004-07-24 7:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.NEB.4.60.0407131537590.12135@norge.freeshell.org>
[not found] ` <1089826204.4517.0.camel@pegasus>
[not found] ` <Pine.NEB.4.60.0407141844100.22049@mx.freeshell.org>
[not found] ` <1090055676.4558.15.camel@pegasus>
2004-07-24 7:36 ` J.D. [this message]
2004-07-24 20:35 ` [Bluez-devel] Re: Linux 2.4.27rc3 and Bluetooth Marcel Holtmann
2004-07-30 13:36 ` John Dahlstrom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.NEB.4.60.0407240115590.25504@norge.freeshell.org \
--to=jd@freeshell.org \
--cc=bluez-devel@lists.sourceforge.net \
--cc=marcel@holtmann.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox