[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Neil Williams wrote: > On Wed, 28 Feb 2007 11:36:25 +0000 > Simon Williams <systemparadox@xxxxxxxxxxxxxx> wrote: > >> The module is bt3c_cs- the driver for my 3Com PCMCIA bluetooth card. It >> could be in use by anything that uses bluetooth, but the most likely >> ones are hcid, hidd, etc and kbluetoothd. > > May I suggest a USB bluetooth instead? No. I could have got one for 2 quid ages ago, but I deliberately found a low profile (actually mine doesn't stick out at all) PCMCIA card that I could just leave in the slot. >> The problem is that after a suspend the card cannot reinitialise- its >> hardware address is stuck at 00:00:00:00:00 in hciconfig, and hciconfig >> hci0 reset or hciconfig hci0 up says connection timed out. >> If I close all bluetooth applications, stop bluetooth services, >> hciconfig hci0 down, rmmod bt3c_cs, modprobe bt3c_cs, and start >> everything back up again it works fine. > > Bad driver - a bug should be filed against the driver. This won't be > solved by just identifying the application using the module, it needs > to be fixed within the module source code itself. In that case I'd better file one against snd-intel8x0 and ath_pci as well. The biggest problem is that bluez is as good as unmaintained- especially PCMCIA, and even more especially bt3c_cs. >> I really would like some way of reloading the module without having to >> kill all the applications, but I don't think that's possible. > > It is possible, from within the driver itself - IF the driver is > actually being told about the suspend. Not every suspend process > bothers to tell the devices that the suspend is happening. Great. >> I guess >> the point is that the module is supposed to handle the resetting itself >> (why do no module developers account for people who suspend?). > > Because suspend is a complete nightmare of incompatibilities, ignored > standards, proprietary blobware and uncooperative hardware suppliers. > Module developers would take account of suspend if they actually had > usable information on what actually happens during a suspend. > > The easiest solution here is to vote with your feet: change the hardware. Not an option I'm afraid. There are a grand total of 2 Linux compatible low profile PCMCIA bluetooth cards, and I doubt the other one is any better for this, considering the other devices I have a similar problem with. >> Both rmmod -w and rmmod -f just sit there. >> >> Physically removing the card stops the use of it, but I want to have >> this done automatically. > > When you reinsert the card, does everything work as normal? Once the module is reloaded yes. I can see myself having a "fixbluetooth" script which just kills kbluetoothd and a few other things that might be using it. A nice one to add to "fixsound" and "fixwireless". Can anyone give me any pointers on how to contribute code to large open source projects? I'd also like to do something with KDE, but I have no idea how I go about it. Thanks Simon -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html