Re: hci_usb strikes again (was Re: BUG kmalloc-2048: Poison overwritten)

[Pavel Machek <pavel@suse.cz>]

Hi!
> >> > cpufreq_performance cpufreq_powersave rfcomm hidp l2cap bluetooth fan
> >> > ipmi_watchdog ipmi_msghandler uinput wlan_tkip ieee80211_crypt_tkip
> >> > ieee80211_crypt arpt_mangle arptable_filter arp_tables
> >> > nf_conntrack_ipv4 nf_conntrack iptable_mangle iptable_filter ip_tables
> >> > x_tables intelfb i2c_i810 i2c_algo_bit coretemp eeprom acpi_cpufreq
> >> > fglrx(P) applesmc joydev uvcvideo appletouch wlan_scan_sta
> >> > ath_rate_sample firewire_ohci firewire_core snd_hda_intel ath_pci
> >> > snd_pcm wlan ohci1394 intel_agp evdev ath_hal(P) snd_timer ieee1394
> >> > pata_acpi thermal ehci_hcd uhci_hcd snd_page_alloc snd_hwdep agpgart
> >> > video button processor
> >> > [  232.270800]
> >> > [  232.270802] Pid: 2690, comm: btdelconn Tainted: P
> >> > (2.6.26-rc4-00033-g5463508 #4)
> >
> > ...and we get oops in bluetooth.
> >
> > Use btusb, instead.
> >
> > Actually, I guess we should mark hci_usb as broken. I don't see why we
> > should debug the same problem over and over again.

> Well; "shizzle my frizzle," The funny thing is, is I have not seen
> this after performing more suspends,
> maybe this is a every once in a while scenario.

It was "one in three" in my tests; but you need usb actively in use
while you are suspending for this to bite.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html