Hi.
This dongle used to work fine (at least till 2.6.3) and still does if I
remove the bcm203x kernel module and manually (or via hotplug) use the
bluefw program to upload the firmware.
This dongle gives me an oops on _insert_.
Mass storage devices/HID work fine.
This is on a ppc machine with xmon support compiled in. So if you need
more infos than this backtrace, please say so.
usb 1-1: new full speed USB device using address 5
Bluetooth: Broadcom Blutonium firmware driver ver 1.0
Bluetooth: HCI USB driver ver 2.5
drivers/usb/core/usb.c: registered new driver bcm203x
drivers/usb/core/usb.c: registered new driver hci_usb
usb 1-1: USB disconnect, address 5
usb 1-1: new full speed USB device using address 6
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C0260554 LR: C02607F8 SP: EFEB9D00 REGS: efeb9c50 TRAP: 0301 Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000004, DSISR: 40000000
TASK = c1aee000[5] 'khubd' Last syscall: -1
GPR00: C02607F8 EFEB9D00 C1AEE000 E9B51A2C EE5246AC 00000000 EC987A64 C046273C
GPR08: 00009032 00000008 00010C00 C04F9958 82008022
Call trace:
[c02607f8] usb_set_interface+0x94/0x164
[f2506ab4] hci_usb_probe+0x21c/0x48c [hci_usb]
[c0259f88] usb_probe_interface+0x80/0x98
[c01f5fac] bus_match+0x50/0x8c
[c01f6040] device_attach+0x58/0xbc
[c01f62c0] bus_add_device+0x7c/0xd8
[c01f4b60] device_add+0xb0/0x184
[c0260be4] usb_set_configuration+0x20c/0x25c
[c025b2c4] usb_new_device+0x2bc/0x3d4
[c025cd24] hub_port_connect_change+0x1a0/0x298
[c025d0f0] hub_events+0x2d4/0x354
[c025d1ac] hub_thread+0x3c/0xf4
[c000914c] kernel_thread+0x44/0x60
Soeren.
Hi Soeren,
> This dongle used to work fine (at least till 2.6.3) and still does if I
> remove the bcm203x kernel module and manually (or via hotplug) use the
> bluefw program to upload the firmware.
>
> This dongle gives me an oops on _insert_.
> Mass storage devices/HID work fine.
>
> This is on a ppc machine with xmon support compiled in. So if you need
> more infos than this backtrace, please say so.
>
> usb 1-1: new full speed USB device using address 5
> Bluetooth: Broadcom Blutonium firmware driver ver 1.0
> Bluetooth: HCI USB driver ver 2.5
> drivers/usb/core/usb.c: registered new driver bcm203x
> drivers/usb/core/usb.c: registered new driver hci_usb
> usb 1-1: USB disconnect, address 5
> usb 1-1: new full speed USB device using address 6
> Oops: kernel access of bad area, sig: 11 [#1]
> NIP: C0260554 LR: C02607F8 SP: EFEB9D00 REGS: efeb9c50 TRAP: 0301 Not tainted
> MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
> DAR: 00000004, DSISR: 40000000
> TASK = c1aee000[5] 'khubd' Last syscall: -1
> GPR00: C02607F8 EFEB9D00 C1AEE000 E9B51A2C EE5246AC 00000000 EC987A64 C046273C
> GPR08: 00009032 00000008 00010C00 C04F9958 82008022
> Call trace:
> [c02607f8] usb_set_interface+0x94/0x164
> [f2506ab4] hci_usb_probe+0x21c/0x48c [hci_usb]
> [c0259f88] usb_probe_interface+0x80/0x98
> [c01f5fac] bus_match+0x50/0x8c
> [c01f6040] device_attach+0x58/0xbc
> [c01f62c0] bus_add_device+0x7c/0xd8
> [c01f4b60] device_add+0xb0/0x184
> [c0260be4] usb_set_configuration+0x20c/0x25c
> [c025b2c4] usb_new_device+0x2bc/0x3d4
> [c025cd24] hub_port_connect_change+0x1a0/0x298
> [c025d0f0] hub_events+0x2d4/0x354
> [c025d1ac] hub_thread+0x3c/0xf4
> [c000914c] kernel_thread+0x44/0x60
the bcm203x is only a firmware loader driver and after firmware load the
device resets and should be driven by the hci_usb driver. Does it still
oopses if you remove the hci_usb module from the module directory? What
I don't understand is that the oops comes from the hci_usb driver.
Regards
Marcel
On Mon, 2004-04-05 at 23:40, Marcel Holtmann wrote:
> Hi Soeren,
>
> > Bluetooth: Broadcom Blutonium firmware driver ver 1.0
> > bcm203x_probe: Mini driver request failed
> > bcm203x: probe of 1-1:1.0 failed with error -5
> > usb 1-1: bulk timeout on ep1in
> > usbfs: USBDEVFS_BULK failed dev 3 ep 0x81 len 10 ret -110
>
> these are two different errors. The first is from bcm203x while the
> request of the firmware file through request_firmware() fails and the
> second is form the bluefw program. Maybe hotplug get's into to trouble
> and tries to load the bcm203x and bluefw at the same time while it also
> has to handle requesting of the firmware file with firmware.agent. Does
> it work for you if you uninstall bluefw.
That is why I removed all the bluefw stuff in /etc/hotplug before
testing bluetooth again... but it still oopsed.
Soeren
On Mon, 2004-04-05 at 23:09, Marcel Holtmann wrote:
> Hi Soeren,
>
> > This dongle used to work fine (at least till 2.6.3) and still does if I
> > remove the bcm203x kernel module and manually (or via hotplug) use the
> > bluefw program to upload the firmware.
> >
> > This dongle gives me an oops on _insert_.
> > Mass storage devices/HID work fine.
> >
> > This is on a ppc machine with xmon support compiled in. So if you need
> > more infos than this backtrace, please say so.
> >
> > usb 1-1: new full speed USB device using address 5
> > Bluetooth: Broadcom Blutonium firmware driver ver 1.0
> > Bluetooth: HCI USB driver ver 2.5
> > drivers/usb/core/usb.c: registered new driver bcm203x
> > drivers/usb/core/usb.c: registered new driver hci_usb
> > usb 1-1: USB disconnect, address 5
> > usb 1-1: new full speed USB device using address 6
> > Oops: kernel access of bad area, sig: 11 [#1]
> > NIP: C0260554 LR: C02607F8 SP: EFEB9D00 REGS: efeb9c50 TRAP: 0301 Not tainted
> > MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
> > DAR: 00000004, DSISR: 40000000
> > TASK = c1aee000[5] 'khubd' Last syscall: -1
> > GPR00: C02607F8 EFEB9D00 C1AEE000 E9B51A2C EE5246AC 00000000 EC987A64 C046273C
> > GPR08: 00009032 00000008 00010C00 C04F9958 82008022
> > Call trace:
> > [c02607f8] usb_set_interface+0x94/0x164
> > [f2506ab4] hci_usb_probe+0x21c/0x48c [hci_usb]
> > [c0259f88] usb_probe_interface+0x80/0x98
> > [c01f5fac] bus_match+0x50/0x8c
> > [c01f6040] device_attach+0x58/0xbc
> > [c01f62c0] bus_add_device+0x7c/0xd8
> > [c01f4b60] device_add+0xb0/0x184
> > [c0260be4] usb_set_configuration+0x20c/0x25c
> > [c025b2c4] usb_new_device+0x2bc/0x3d4
> > [c025cd24] hub_port_connect_change+0x1a0/0x298
> > [c025d0f0] hub_events+0x2d4/0x354
> > [c025d1ac] hub_thread+0x3c/0xf4
> > [c000914c] kernel_thread+0x44/0x60
>
> the bcm203x is only a firmware loader driver and after firmware load the
> device resets and should be driven by the hci_usb driver. Does it still
> oopses if you remove the hci_usb module from the module directory? What
> I don't understand is that the oops comes from the hci_usb driver.
The interesting thing is that it did _not_ oops when I remove
/sbin/hotplug (version 0.0.20040329-4). Also step by step modprobing
hci_usb / bcm203x does not cause any trouble (but does not work either,
even when rmmoding modprobing again for some time). It outputs:
modprobe bcm203x
Bluetooth: Broadcom Blutonium firmware driver ver 1.0
bcm203x_probe: Mini driver request failed
bcm203x: probe of 1-1:1.0 failed with error -5
usb 1-1: bulk timeout on ep1in
usbfs: USBDEVFS_BULK failed dev 3 ep 0x81 len 10 ret -110
So it seems the firmware is loaded or hci_usb is started while the
device is not yet ready.
Calling bluefw sometimes also timeouts but mostly works...
When the firmware is finally loaded bluetooth operates perfectly...
HTH,
Soeren
Hi Soeren,
> Bluetooth: Broadcom Blutonium firmware driver ver 1.0
> bcm203x_probe: Mini driver request failed
> bcm203x: probe of 1-1:1.0 failed with error -5
> usb 1-1: bulk timeout on ep1in
> usbfs: USBDEVFS_BULK failed dev 3 ep 0x81 len 10 ret -110
these are two different errors. The first is from bcm203x while the
request of the firmware file through request_firmware() fails and the
second is form the bluefw program. Maybe hotplug get's into to trouble
and tries to load the bcm203x and bluefw at the same time while it also
has to handle requesting of the firmware file with firmware.agent. Does
it work for you if you uninstall bluefw.
Regards
Marcel
Hi Soeren,
> That is why I removed all the bluefw stuff in /etc/hotplug before
> testing bluetooth again... but it still oopsed.
maybe you wanna try 2.6.5-mh1 from http://www.bluez.org/patches.html
Regards
Marcel
On Tue, 2004-04-06 at 01:17, Marcel Holtmann wrote:
> Hi Soeren,
>
> > That is why I removed all the bluefw stuff in /etc/hotplug before
> > testing bluetooth again... but it still oopsed.
>
> maybe you wanna try 2.6.5-mh1 from http://www.bluez.org/patches.html
Alright so I did zcat patch.gz | patch -p0 and a make && make
modules_install and rebooted in the new 2.6.5-mh1 kernel.
Same oops again (see below)!
To be 100% sure I renamed /sbin/bluefw to /sbin/bluefw.inactive (same
oops once again). Then I renamed /sbin/hotplug to /sbin/hotplug.inactive
and manually modprobe bcm203x and then hci_usb.
This time firmware is loaded without any trouble (but this is the very
very rare case it never worked again ...) and hci0 is there and seems to
work...
So I rmmod bcm203x firmware_class hci_usb and wondered what could go
wrong when I do the very same with hotplug ?
So I had a look at the hotplug script and tried to process command by
command manually. Args with which the firmware script is called:
ACTION: add
SYSFS: /sys
DEVPATH: /class/firmware/1-1
FIRMWARE: BCM2033-MD.hex
FIRMWARE_DIR=/usr/lib/hotplug/firmware
# mountpoint of sysfs
SYSFS=$(sed -n 's/^.* \([^ ]*\) sysfs .*$/\1/p' /proc/mounts)
# use /proc for 2.4 kernels
if [ "$SYSFS" = "" ]; then
SYSFS=/proc
fi
#
# What to do with this firmware hotplug event?
#
case "$ACTION" in
add)
if [ ! -e $SYSFS/$DEVPATH/loading ]; then
sleep 1
fi
if [ -f "$FIRMWARE_DIR/$FIRMWARE" ]; then
echo 1 > $SYSFS/$DEVPATH/loading
cp "$FIRMWARE_DIR/$FIRMWARE" $SYSFS/$DEVPATH/data
echo 0 > $SYSFS/$DEVPATH/loading
else
echo -1 > $SYSFS/$DEVPATH/loading
fi
;;
I realized that when I use e.g
...
add)
n=0;
while [ $n -lt 10 ] && [ ! -e $SYSFS/$DEVPATH/loading ]; do
sleep 1
let n++
done
if [ -e $SYSFS/$DEVPATH/loading ]; then
if [ -f "$FIRMWARE_DIR/$FIRMWARE" ]; then
echo 1 > $SYSFS/$DEVPATH/loading
cp "$FIRMWARE_DIR/$FIRMWARE" $SYSFS/$DEVPATH/data
echo 0 > $SYSFS/$DEVPATH/loading
else
echo -1 > $SYSFS/$DEVPATH/loading
fi
fi
I don't get any more oopses.
But still firmware loading does not anymore work (without bluefw)
HTH,
Soeren.
devfs_mk_dev: could not append to parent for bluetooth/rfcomm/0
usb 1-1: new full speed USB device using address 2
Bluetooth: Broadcom Blutonium firmware driver ver 1.0
drivers/usb/core/usb.c: registered new driver bcm203x
usb 1-1: USB disconnect, address 2
usb 1-1: new full speed USB device using address 3
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C0260554 LR: C02607F8 SP: EFEB9D00 REGS: efeb9c50 TRAP: 0301 Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000004, DSISR: 40000000
TASK = c1aee000[5] 'khubd' Last syscall: -1
GPR00: C02607F8 EFEB9D00 C1AEE000 EFCAE550 EE8B5CF4 00000000 EE874A90 C04622C4
GPR08: 00009032 00000017 00010C00 C04F9958 82008022
Call trace:
[c02607f8] usb_set_interface+0x94/0x164
[f2443ab4] hci_usb_probe+0x21c/0x48c [hci_usb]
[c0259f88] usb_probe_interface+0x80/0x98
[c01f5fac] bus_match+0x50/0x8c
[c01f6040] device_attach+0x58/0xbc
[c01f62c0] bus_add_device+0x7c/0xd8
[c01f4b60] device_add+0xb0/0x184
[c0260be4] usb_set_configuration+0x20c/0x25c
[c025b2c4] usb_new_device+0x2bc/0x3d4
[c025cd24] hub_port_connect_change+0x1a0/0x298
[c025d0f0] hub_events+0x2d4/0x354
[c025d1ac] hub_thread+0x3c/0xf4
[c000914c] kernel_thread+0x44/0x60
On Tue, 2004-04-06 at 01:17, Marcel Holtmann wrote:
Hello Marcel,
forget about the while [] change in the hotplug firmware script. It still oopses :(
I was even able to cause the very same oops when I used
/sbin/bluefw.inactive to load the firmware !
Regards,
Soerern
On Tuesday 06 April 2004 10:12, Soeren Sonnenburg wrote:
> On Tue, 2004-04-06 at 01:17, Marcel Holtmann wrote:
>
> Hello Marcel,
>
> forget about the while [] change in the hotplug firmware script. It still
> oopses :(
>
> I was even able to cause the very same oops when I used
> /sbin/bluefw.inactive to load the firmware !
If you feeling desperate, go back to 2.6.3,
verify that it works, and start binary search
in [2.6.3, 2.6.5] range.
--
vda