So it's delayed a few days, and I really was struggling with the
decision of whether I wanted to cut a final release at all: it could
easily have made more sense to just do an -rc8. However, since I'm
going to be at LinuxCon Japan in two weeks, the choice for me ended up
whether I should just release, or drag it out *three* more weeks, or
have some really messy merge window with a break in between.
None of those choices really looked all that great. There were
certainly more code changes since -rc7 than I really was all that
happy with, and some outstanding discussion. Doing another -rc
wouldn't necessarily have been a bad idea, but then I just decided
that if I held off making the release, next week my timing choices
would have been even worse.
So there it is. The one thing that pushed me over the edge is that
this release window has been fairly "easy". -rc2 was calm, -rc3 was
_really_ calm, and -rc7 was tiny. And while this has more commits than
-rc7 had, I didn't feel like that changed the overall picture much: we
really did have much less churn after the merge window closed than we
usually do. Which actually makes me pretty happy about the state of
2.6.39.
(Just to put that "calm after the merge window" in quantitative
numbers: doing some git statistics, we have fewer commits after -rc1
than any of the last ten releases).
As to the merge window for 2.6.40 (which is obviously open now):
because of the delay, the normal 14 days would be with the last two
days when I'm already in Japan. Which is certainly not unthinkable
(I'll have my laptop and access to wifi, and could do some final
tweaks that way even if I wouldn't want to do a bigger portion of a
merge window while traveling). But I do want to warn that if I get the
feeling that I've merged "enough", I might just make it easier for
myself and cut it two days short and release just before I leave on
Memorial day (which for the non-US based of you is May 30th this
year).
Having a slightly shorter (and actually smaller, not just more
hurried) merge window and release cycle for 2.6.40 might not be a
horrible fate. Of course, I just know that you're all actively trying
to sabotage that dream of mine.
But I can still dream, can't I?
Linus
---
Alex Deucher (4):
drm/radeon/kms: fix cayman acceleration
drm/radeon/kms: fix tiling reg on fusion
drm/radeon/kms: fix extended lvds info parsing
drm/radeon/kms: add some evergreen/ni safe regs
Alexander Stein (2):
Input: ads7846 - make transfer buffers DMA safe
Input: ads7846 - remove unused variable from struct ads7845_ser_req
Alexandre Bounine (1):
rapidio: fix default routing initialization
Andi Kleen (2):
mm: add alloc_pages_exact_nid()
memcg: allocate memory cgroup structures in local nodes
Andy Adamson (2):
NFSv41: Resend on NFS4ERR_RETRY_UNCACHED_REP
NFSv4.1: remove pnfs_layout_hdr from pnfs_destroy_all_layouts tmp_list
Andy Lutomirski (2):
drm/i915: Revert i915.semaphore=1 default from i915 merge
drm/i915: Revert i915.semaphore=1 default from 47ae63e0
Anton Blanchard (1):
ehea: Fix memory hotplug oops
Arnaldo Carvalho de Melo (2):
perf tools: Honour the cpu list parameter when also monitoring a
thread list
perf evlist: Fix per thread mmap setup
Arnd Bergmann (1):
ARM: 6892/1: handle ptrace requests to change PC during
interrupted system calls
Avinash H.M (1):
OMAP3: set the core dpll clk rate in its set_rate function
Axel Lin (2):
mfd: Fix asic3 build error
drivers/leds/leds-lm3530.c: add MODULE_DEVICE_TABLE
Ben Dooks (1):
drivers/rtc/rtc-s3c.c: fixup wake support for rtc
Ben Hutchings (3):
ipheth: Properly distinguish length and alignment in URBs and skbs
sfc: Always map MCDI shared memory as uncacheable
sfc: Fix oops in register dump after mapping change
Borislav Petkov (2):
Revert "x86, AMD: Fix APIC timer erratum 400 affecting K8
Rev.A-E processors"
x86, AMD: Fix ARAT feature setting again
Bruno Prémont (1):
Further fbcon sanity checking
Catalin Marinas (2):
MIPS: Rename .data..mostly and properly handle it in linker script
ARM: 6870/1: The mandatory barrier rmb() must be a dsb() in for
device accesses
Chris Ball (1):
Revert "mmc: fix a race between card-detect rescan and
clock-gate work instances"
Chris Wilson (1):
drm: Take lock around probes for drm_fb_helper_hotplug_event
Christian Borntraeger (1):
[S390] disassembler: handle b280/spp instruction
Cliff Wickman (1):
x86: Fix UV BAU for non-consecutive nasids
Dan Rosenberg (1):
dccp: handle invalid feature options length
Dan Williams (1):
net/usb: mark LG VL600 LTE modem ethernet interface as WWAN
Daniel J Blueman (1):
Prevent oopsing in posix_acl_valid()
Dave Airlie (2):
drm/radeon: fix cayman struct accessors.
drm/radeon/nouveau: fix build regression on alpha due to Xen changes.
Dave Chinner (5):
xfs: ensure reclaim cursor is reset correctly at end of AG
xfs: exit AIL push work correctly when AIL is empty
xfs: always push the AIL to the target
xfs: make AIL target updates and compares 32bit safe.
xfs: fix race condition in AIL push trigger
David Daney (4):
MIPS: Mask jump target in ftrace_dyn_arch_init_insns().
MIPS: Octeon: Cleanup Kconfig IRQ_CPU* symbols.
MIPS: Octeon: Guard the Kconfig body with CPU_CAVIUM_OCTEON
MIPS: Invalidate old TLB mappings when updating huge page PTEs.
David Rientjes (1):
slub: Revert "[PARISC] slub: fix panic with DISCONTIGMEM"
Eric Dumazet (4):
net: ip_expire() must revalidate route
netfilter: fix ebtables compat support
vlan: fix GVRP at dismantle time
net: dev_close() should check IFF_UP
Eric Paris (1):
SELinux: delete debugging printks from filename_trans rule processing
Fernando Luis Vazquez Cao (2):
netfilter: IPv6: initialize TOS field in REJECT target module
netfilter: IPv6: fix DSCP mangle code
Florian Fainelli (1):
MIPS: AR7: Fix GPIO register size for Titan variant.
Florian Mickler (1):
vga_switcheroo: don't toggle-switch devices
Florian Westphal (1):
netfilter: ebtables: only call xt_compat_add_offset once per rule
Geert Uytterhoeven (3):
zorro8390: Fix regression caused during net_device_ops conversion
hydra: Fix regression caused during net_device_ops conversion
ne-h8300: Fix regression caused during net_device_ops conversion
Grant Likely (1):
drivercore: revert addition of of_match to struct device
Hans Schillstrom (3):
IPVS: Change of socket usage to enable name space exit.
IPVS: init and cleanup restructuring
IPVS: fix netns if reading ip_vs_* procfs entries
Hans Verkuil (1):
[media] v4l2-subdev: fix broken subdev control enumeration
Harry Wei (1):
MAINTAINERS: fix sorting
Heiko Carstens (1):
[S390] sclp/memory hotplug: fix initial usecount of increments
Henry C Chang (3):
ceph: print debug message before put mds session
ceph: fix list_add in ceph_put_snap_realm
ceph: do not use i_wrbuffer_ref as refcount for Fb cap
Hugh Dickins (4):
tmpfs: fix race between umount and writepage
tmpfs: fix race between umount and swapoff
tmpfs: fix spurious ENOSPC when racing with unswap
tmpfs: fix race between swapoff and writepage
Ingo Molnar (1):
vsprintf: Turn kptr_restrict off by default
Jack Steiner (1):
x86, UV: Fix NMI handler for UV platforms
Jeff Layton (2):
cifs: add fallback in is_path_accessible for old servers
cifs: fix cifsConvertToUCS() for the mapchars case
Jens Axboe (1):
scsi: remove performance regression due to async queue run
Jiri Olsa (1):
kprobes, x86: Disable irqs during optimized callback
Joel Becker (2):
configfs: Don't try to d_delete() negative dentries.
configfs: Fix race between configfs_readdir() and configfs_d_iput()
John Stultz (9):
clocksource: Install completely before selecting
rtc: ds1286: Initialize drvdata before registering device
rtc: m41t80: Initialize clientdata before registering device
rtc: max8925: Initialize drvdata before registering device
rtc: max8998: Initialize drvdata before registering device
rtc: msm6242: Initialize drvdata before registering device
rtc: pcap: Initialize drvdata before registering device
rtc: rp5c01: Initialize drvdata before registering device
alpha: convert to clocksource_register_hz
Jonas Gorski (1):
MIPS: bcm63xx: Fix header_crc comment in bcm963xx_tag.h
Juergen Kilb (1):
mfd: Fixed gpio polarity of omap-usb gpio USB-phy reset
Julia Lawall (1):
x86, mce, AMD: Fix leaving freed data in a list
KAMEZAWA Hiroyuki (1):
memcg: fix zone congestion
Kleber Sacilotto de Souza (1):
ehea: fix wrongly reported speed and port
Konrad Rzeszutek Wilk (1):
Revert "xen/mmu: Add workaround "x86-64, mm: Put early page table high""
Kurt Van Dijck (1):
can: fix SJA1000 dlc for RTR packets
Lars-Peter Clausen (5):
ASoC: JZ4740: Fix i2s shutdown
ASoC: SSM2602: Properly annotate i2c probe and remove functions
ASoC: SSM2602: Fix 'Mic Boost2' control
ASoC: SSM2602: Fix reg_cache_size
MIPS: JZ4740: Set one-shot feature flag for the clockevent
Laurent Pinchart (2):
[media] v4l: Release module if subdev registration fails
omap: iommu: Return IRQ_HANDLED in fault handler when no fault occured
Lawrence Rust (1):
[media] Fix cx88 remote control input
Lesly A M (1):
mfd: Fix for the TWL4030 PM sleep/wakeup sequence
Li Zefan (3):
fs: remove FS_COW_FL
Btrfs: fix FS_IOC_GETFLAGS ioctl
Btrfs: fix FS_IOC_SETFLAGS ioctl
Linus Torvalds (7):
Revert "Bluetooth: fix shutdown on SCO sockets"
fbcon: add lifetime refcount to opened frame buffers
fbmem: make read/write/ioctl use the frame buffer at open time
Revert "drm/i915: Only enable the plane after setting the fb
base (pre-ILK)"
vfs: micro-optimize acl_permission_check()
fbmem: fix remove_conflicting_framebuffers races
Linux 2.6.39
Luciano Coelho (1):
mac80211: don't start the dynamic ps timer if not associated
M. Mohan Kumar (1):
net/9p: Handle get_user_pages_fast return properly
Manuel Lauss (1):
MIPS: Alchemy: fix xxs1500 build error
Marcus Meissner (1):
ocfs2: Initialize data_ac (might be used uninitialized)
Marek Belisko (1):
ASoC: UDA134x: Remove POWER_OFF_ON_STANDBY define.
Mark Brown (1):
ASoC: Don't crash on PM operations
Martin Schwidefsky (2):
[S390] oprofile: fix min/max interval query checks
[S390] fix alloc_pgste check in init_new_context
Matvejchikov Ilya (1):
NET: slip, fix ldisc->open retval
Mel Gorman (1):
mm: tracing: add missing GFP flags to tracing
Michael Cree (1):
alpha: Wire up syscalls new to 2.6.39
Michael Holzheu (2):
[S390] kernel: Initialize register 14 when starting new CPU
[S390] replace diag10() with diag10_range() function
Michał Mirosław (1):
net: Change netdev_fix_features messages loglevel
Miklos Szeredi (1):
fuse: fix oops in revalidate when called with NULL nameidata
Milton Miller (1):
of: fix race when matching drivers
Minchan Kim (1):
mm: check PageUnevictable in lru_deactivate_fn()
Ming Lei (1):
usbnet: runtime pm: fix out of memory
Mohammed Shafi Shajakhan (1):
ath9k: Fix a warning due to a queued work during S3 state
Nicolas Pitre (3):
ARM: zImage: make sure the stack is 64-bit aligned
ARM: zImage: make sure not to relocate on top of the relocation code
ARM: zImage: the page table memory must be considered before relocation
Oliver Hartkopp (1):
slcan: fix ldisc->open retval
Pablo Neira Ayuso (2):
netfilter: ctnetlink: fix timestamp support for new conntracks
netfilter: revert a2361c8735e07322023aedc36e4938b35af31eb0
Paul Fox (1):
libertas: fix cmdpendingq locking
Pedro Scarapicchia Junior (1):
net/9p/protocol.c: Fix a memory leak
Rafael J. Wysocki (3):
PM: Fix warning in pm_restrict_gfp_mask() during SNAPSHOT_S2RAM ioctl
PM / Hibernate: Make snapshot_release() restore GFP mask
PM / Hibernate: Fix ioctl SNAPSHOT_S2RAM
Ralf Baechle (21):
MIPS: c-r4k: Fix GCC 4.6.0 build error
MIPS: tlbex: Fix GCC 4.6.0 build error
MIPS: IP22: Fix GCC 4.6.0 build error
MIPS: IP22: Fix GCC 4.6.0 build error
MIPS: Malta: Fix GCC 4.6.0 build error
MIPS: Malta: Fix GCC 4.6.0 build error
MIPS: SNI: Fix GCC 4.6.0 build error
MIPS: Jazz: Fix GCC 4.6.0 build error
MIPS: Loongson: Fix GCC 2.6.0 build error.
MIPS: MSP: Fix build error
MIPS: IP27: Fix GCC 4.6.0 build error.
MIPS: IP27: Fix GCC 4.6.0 build error.
MIPS: Document former use of timerfd(2) syscall number.
MIPS: Alchemy: Fix GCC 4.6.0 build error.
MIPS: Fix calc_vmlinuz_load_addr build warnings.
MIPS: Audit: Fix success success argument pass to audit_syscall_exit
MIPS: JZ4740: Fix GCC 4.6.0 build error.
MIPS: JZ4740: Export symbols to the watchdog driver module
MIPS: RB532: Fix iomap resource size miscalculation.
MIPS: Fix duplicate invocation of notify_die.
MIPS: Kludge IP27 build for 2.6.39.
Randy Dunlap (2):
mm: fix kernel-doc warning in page_alloc.c
procfs: add stub for proc_mkdir_mode()
Richard Weinberger (1):
um: fix abort
Roland Dreier (1):
vmxnet3: Consistently disable irqs when taking adapter->cmd_lock
Russell King (2):
ARM: RiscPC: etherh: fix section mismatches
ARM: RiscPC: acornfb: fix section mismatches
Ryusuke Konishi (1):
nilfs2: fix infinite loop in nilfs_palloc_freev function
Sage Weil (1):
rbd: fix leak of ops struct
Sam Ravnborg (2):
sparc32: fix section mismatch warnings in apc, pmc and time_32
sparc32: fix sparcstation 5 boot
Sedat Dilek (1):
x86/mm: Fix section mismatch derived from native_pagetable_reserve()
Serge E. Hallyn (1):
Cache user_ns in struct cred
Sergio Aguirre (1):
[media] V4L: soc-camera: regression fix: calculate .sizeimage in
soc_camera.c
Shaohua Li (1):
block: don't delay blk_run_queue_async
Somnath Kotur (1):
be2net: Fixed bugs related to PVID.
Stanislaw Gruszka (1):
iwlegacy: fix IBSS mode crashes
Stefan Haberland (1):
[S390] dasd: prevent IO error during reserve/release loop
Stefano Stabellini (1):
x86,xen: introduce x86_init.mapping.pagetable_reserve
Steffen Klassert (2):
xfrm: Assign the inner mode output function to the dst entry
xfrm: Don't allow esn with disabled anti replay detection
Steinar H. Gunderson (1):
ipv6: restore correct ECN handling on TCP xmit
Stephen Hemminger (2):
bridge: fix forwarding of IPv6
bridge: fix forwarding of IPv6
Stephen Warren (1):
ASoC: WM8903: Fix Digital Capture Volume range
Sunil Mushran (5):
ocfs2/dlm: Use negotiated o2dlm protocol version
ocfs2/cluster: Increase the live threshold for global heartbeat
ocfs2/cluster: Heartbeat mismatch message improved
ocfs2: Skip mount recovery for hard-ro mounts
ocfs2/dlm: Target node death during resource migration leads to
thread spin
Tejun Heo (5):
block: unexport DISK_EVENT_MEDIA_CHANGE for legacy/fringe drivers
cdrom: always check_disk_change() on open
block: rescan partitions on invalidated devices on -ENOMEDIA too
Revert "libata: ahci_start_engine compliant to AHCI spec"
libata: fix oops when LPM is used with PMP
Thomas Gleixner (1):
tick: Clear broadcast active bit when switching to oneshot
Thomas Jarosch (1):
vmxnet3: Fix inconsistent LRO state after initialization
Tkhai Kirill (1):
sparc32: Fixed unaligned memory copying in function
__csum_partial_copy_sparc_generic
Tomoya (1):
pch_gbe: support ML7223 IOH
Tony Lindgren (1):
ARM: zImage: Fix bad SP address after relocating kernel
Toshiharu Okada (2):
PCH_GbE : Fixed the issue of collision detection
PCH_GbE : Fixed the issue of checksum judgment
Tristan Ye (1):
ocfs2: skip existing hole when removing the last extent_rec in
punching-hole codes.
Trond Myklebust (1):
NFSv4.1: Ensure that layoutget uses the correct gfp modes
Uwe Kleine-König (1):
rtc: mc13xxx: Don't call rtc_device_register while holding lock
Vitalii Demianets (1):
bonding,llc: Fix structure sizeof incompatibility for some PDUs
Vivek Goyal (1):
blk-throttle: Use task_subsys_state() to determine a task's blkio_cgroup
Will Deacon (1):
ARM: 6890/1: memmap: only free allocated memmap entries when
using SPARSEMEM
Wolfram Sang (4):
rtc: mxc: Initialize drvdata before registering device
rtc: davinci: Initialize drvdata before registering device
rtc: ep93xx: Initialize drvdata before registering device
i2c: pnx: Fix crash due to wrong init of timer->data
Wu Zhangjin (1):
MIPS: Hibernation: Fixes for PAGE_SIZE >= 64kb
Yehuda Sadeh (1):
rbd: fix split bio handling
Yinghai Lu (2):
mm: use alloc_bootmem_node_nopanic() on really needed path
PCI: Clear bridge resource flags if requested size is 0
Yoichi Yuasa (1):
MIPS: MSP71xx: Fix typo in msp_per_irq_controller
Youquan Song (1):
x86, apic: Fix spurious error interrupts triggering on all non-boot APs
liubo (1):
Btrfs: fix easily get into ENOSPC in mixed case
stephen hemminger (1):
tcp_cubic: limit delayed_ack ratio to prevent divide error
xingchao (1):
ASoC: sst_platform: add hw_free callback to fix resource leak
Hi Linus,
On Wed, 18 May 2011 22:04:53 -0700 Linus Torvalds <[email protected]> wrote:
>
> As to the merge window for 2.6.40 (which is obviously open now):
If linux-next is anything to go by, 2.6.40 should be our smallest
release. See http://neuling.org/linux-next-size.html (you can zoom by
slecting a horizontal section and zoom out by double clicking).
Note, though, that the rate of including commits accelerated over the last
week :-).
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Just got weird stuff in the syslog this morning from rc7-git12:
[43190.824700] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
[43190.827426] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
[43190.827506] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
[43190.827568] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
[43190.828685] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
[43190.830498] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
[43190.830603] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
[43190.831055] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
[43190.832580] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
[43190.832788] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
[ 0.000000] Linux version 2.6.39-rc7-git12-ml (root@atom) (gcc version 4.4.3
(Ubuntu 4.4.3-4ubuntu5) ) #12 SMP Wed May 18 15:54:07 EDT 2011
Here's some more funny business that was new after rc7-git12:
warning: (AX88796_93CX6 && RTL8180 && RTL8187 && ADM8211 && RT2400PCI &&
RT2500PCI && RT61PCI && RT2800PCI && R8187SE) selects EEPROM_93CX6 which has
unmet direct dependencies (MISC_DEVICES)
warning: (ACPI_APEI) selects PSTORE which has unmet direct dependencies
(MISC_FILESYSTEMS)
The exact same .config didn't do that with rc7-git12,
but does do it with 2.6.39 final.
Odd thing is, if I select both MISC_DEVICES and MISC_FILESYSTEMS,
but do NOT select anything from under either of those,
the warnings go away.
Which likely means the warnings are totally bogus.
Cheers
On Thu, 19 May 2011 11:44:37 -0400 Mark Lord wrote:
> Here's some more funny business that was new after rc7-git12:
>
> warning: (AX88796_93CX6 && RTL8180 && RTL8187 && ADM8211 && RT2400PCI &&
> RT2500PCI && RT61PCI && RT2800PCI && R8187SE) selects EEPROM_93CX6 which has
> unmet direct dependencies (MISC_DEVICES)
> warning: (ACPI_APEI) selects PSTORE which has unmet direct dependencies
> (MISC_FILESYSTEMS)
>
> The exact same .config didn't do that with rc7-git12,
> but does do it with 2.6.39 final.
I've seen those kconfig warnings plenty of times, before 2.6.39.
Tony Luck has posted a patch for the ACPI_APEI/PSTORE warning (yes, select
MISC_FILESYSTEMS).
> Odd thing is, if I select both MISC_DEVICES and MISC_FILESYSTEMS,
> but do NOT select anything from under either of those,
> the warnings go away.
>
> Which likely means the warnings are totally bogus.
It's just the nature of the tree-structured kconfig hierarchy.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 19 May 2011 16:44, Mark Lord <[email protected]> wrote:
> Here's some more funny business that was new after rc7-git12:
>
> warning: (AX88796_93CX6 && RTL8180 && RTL8187 && ADM8211 && RT2400PCI &&
> RT2500PCI && RT61PCI && RT2800PCI && R8187SE) selects EEPROM_93CX6 which has
> unmet direct dependencies (MISC_DEVICES)
> warning: (ACPI_APEI) selects PSTORE which has unmet direct dependencies
> (MISC_FILESYSTEMS)
>
> The exact same .config didn't do that with rc7-git12,
> but does do it with 2.6.39 final.
>
> Odd thing is, if I select both MISC_DEVICES and MISC_FILESYSTEMS,
> but do NOT select anything from under either of those,
> the warnings go away.
>
> Which likely means the warnings are totally bogus.
The problem is:
AX88796_93CX6 selects EEPROM_93CX6
EEPROM_93CX6 depends on MISC_DEVICES (as part of the EEPROM menu which
is only included if MISC_DEVICES)
By enabling MISC_DEVICES, you allow AX88796_93CX6 to select
EEPROM_93CX6 without any warning as it has the dependencies met.
The issue here is that EEPROM_93CX6 doesn't really depend on any
MISC_DEVICES infrastructure. That's just a directory for various
drivers and MISC_DEVICES only has a visibility role. There was a
proposal last year for kbuild to differentiate between dependency and
visibility but I don't know what happened to it.
--
Catalin
On Thu, 19 May 2011 17:16:32 +0100 Catalin Marinas wrote:
> On 19 May 2011 16:44, Mark Lord <[email protected]> wrote:
> > Here's some more funny business that was new after rc7-git12:
> >
> > warning: (AX88796_93CX6 && RTL8180 && RTL8187 && ADM8211 && RT2400PCI &&
> > RT2500PCI && RT61PCI && RT2800PCI && R8187SE) selects EEPROM_93CX6 which has
> > unmet direct dependencies (MISC_DEVICES)
> > warning: (ACPI_APEI) selects PSTORE which has unmet direct dependencies
> > (MISC_FILESYSTEMS)
> >
> > The exact same .config didn't do that with rc7-git12,
> > but does do it with 2.6.39 final.
> >
> > Odd thing is, if I select both MISC_DEVICES and MISC_FILESYSTEMS,
> > but do NOT select anything from under either of those,
> > the warnings go away.
> >
> > Which likely means the warnings are totally bogus.
>
> The problem is:
>
> AX88796_93CX6 selects EEPROM_93CX6
> EEPROM_93CX6 depends on MISC_DEVICES (as part of the EEPROM menu which
> is only included if MISC_DEVICES)
>
> By enabling MISC_DEVICES, you allow AX88796_93CX6 to select
> EEPROM_93CX6 without any warning as it has the dependencies met.
>
> The issue here is that EEPROM_93CX6 doesn't really depend on any
> MISC_DEVICES infrastructure. That's just a directory for various
> drivers and MISC_DEVICES only has a visibility role. There was a
> proposal last year for kbuild to differentiate between dependency and
> visibility but I don't know what happened to it.
fwiw, there is a VISIBLE attribute now. It defaults to yes/on.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Thu, May 19, 2011 at 8:26 AM, Mark Lord <[email protected]> wrote:
>
> Just got weird stuff in the syslog this morning from rc7-git12:
>
> [43190.824700] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
> [43190.827426] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
> [43190.827506] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
> [43190.827568] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
> [43190.828685] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
> [43190.830498] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
> [43190.830603] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
> [43190.831055] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
> [43190.832580] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
> [43190.832788] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
Quoting from an earlier mail about this issue from the DRM people:
"Userspace is attempting to write to/read from a buffer it has
marked as being no longer required, so some rendering is going amiss.
And it does not rule out the possibility that at some point it will
catch the error later and result in a SIGBUS being sent to the
application (probably X).
However since it is not a kernel error nor is it fatal, that and a
lot of similar messages can be demoted to debug."
So it's basically user space trying to access something stale, but it
should be harmless.
Linus
On 11-05-20 06:00 PM, Linus Torvalds wrote:
> On Thu, May 19, 2011 at 8:26 AM, Mark Lord <[email protected]> wrote:
>>
>> Just got weird stuff in the syslog this morning from rc7-git12:
>>
>> [43190.824700] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
>> [43190.827426] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
>> [43190.827506] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
>> [43190.827568] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
>> [43190.828685] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
>> [43190.830498] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
>> [43190.830603] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
>> [43190.831055] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
>> [43190.832580] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
>> [43190.832788] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a purgeable buffer
>
> Quoting from an earlier mail about this issue from the DRM people:
>
> "Userspace is attempting to write to/read from a buffer it has
> marked as being no longer required, so some rendering is going amiss.
> And it does not rule out the possibility that at some point it will
> catch the error later and result in a SIGBUS being sent to the
> application (probably X).
>
> However since it is not a kernel error nor is it fatal, that and a
> lot of similar messages can be demoted to debug."
>
> So it's basically user space trying to access something stale, but it
> should be harmless.
Peachy. I suspect the messages get generated when I run gmplayer or vlc
(not sure which, don't really care much either).
Thanks.
Hi Linus, I'm sorry bothering you, but my usb-bluetooth dongle stop working in
2.6.39 kernel series.
I know it is nothing ground breaking but it is bug.
I'm using this hardware from 2.6.11 kernel series.
Details are included in this thread:
https://lkml.org/lkml/2011/4/18/481
I hope I'm doing nothing false writing this email.
With best greetings
Milan
On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> Hi Linus, I'm sorry bothering you, but my usb-bluetooth dongle stop working in
> 2.6.39 kernel series.
> I know it is nothing ground breaking but it is bug.
> I'm using this hardware from 2.6.11 kernel series.
> Details are included in this thread:
>
> https://lkml.org/lkml/2011/4/18/481
>
> I hope I'm doing nothing false writing this email.
Same device, same problem here.
You are not alone
Ed Tomlinson
2.6.39 first observations: The framerate jitter in games that seem to
depend on kernel for low-jitter, like doom 3, is almost completely gone
now. (Tested with latest nvidia driver something 75 something)
I decided to try threadirqs from grub, but that did not work. Looks like
the same error as I get when I tried the rt kernels, which was this one:
http://www.paradoxuncreated.com/tmp/rterror.jpg
Peace Be With You,
Uwaysi.
http://www.paradoxuncreated.com/tmp/.config39
Pentium(R) Dual-Core CPU E5200 @ 2.50GHz
uwaysi@Millennium:~$ lspci -v
00:00.0 Host bridge: nVidia Corporation C55 Host Bridge (rev a2)
Flags: bus master, 66MHz, fast devsel, latency 0
Capabilities: <access denied>
00:00.1 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
Flags: 66MHz, fast devsel
00:00.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
Flags: 66MHz, fast devsel
00:00.3 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
Flags: bus master, 66MHz, fast devsel, latency 0
00:00.4 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
Flags: bus master, 66MHz, fast devsel, latency 0
00:00.5 RAM memory: nVidia Corporation C55 Memory Controller (rev a2)
Flags: bus master, 66MHz, fast devsel, latency 0
00:00.6 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
Flags: 66MHz, fast devsel
00:00.7 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
Flags: 66MHz, fast devsel
00:01.0 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
Flags: 66MHz, fast devsel
00:01.1 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
Flags: 66MHz, fast devsel
00:01.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
Flags: 66MHz, fast devsel
00:01.3 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
Flags: 66MHz, fast devsel
00:01.4 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
Flags: 66MHz, fast devsel
00:01.5 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
Flags: 66MHz, fast devsel
00:01.6 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
Flags: 66MHz, fast devsel
00:02.0 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
Flags: 66MHz, fast devsel
00:02.1 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
Flags: bus master, 66MHz, fast devsel, latency 0
00:02.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
Flags: 66MHz, fast devsel
00:03.0 PCI bridge: nVidia Corporation C55 PCI Express bridge (rev a1)
(prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=05, sec-latency=0
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: fa000000-feafffff
Prefetchable memory behind bridge: 00000000d0000000-00000000dfffffff
Capabilities: <access denied>
Kernel driver in use: pcieport
Kernel modules: shpchp
00:06.0 PCI bridge: nVidia Corporation C55 PCI Express bridge (rev a1)
(prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=06, subordinate=06, sec-latency=0
Capabilities: <access denied>
Kernel driver in use: pcieport
Kernel modules: shpchp
00:07.0 PCI bridge: nVidia Corporation C55 PCI Express bridge (rev a1)
(prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=07, subordinate=07, sec-latency=0
Capabilities: <access denied>
Kernel driver in use: pcieport
Kernel modules: shpchp
00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
Subsystem: Micro-Star International Co., Ltd. Device 7380
Flags: bus master, 66MHz, fast devsel, latency 0
Capabilities: <access denied>
00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
Subsystem: Micro-Star International Co., Ltd. Device 7380
Flags: bus master, 66MHz, fast devsel, latency 0
I/O ports at 4f00 [size=128]
00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
Subsystem: Micro-Star International Co., Ltd. Device 7380
Flags: 66MHz, fast devsel, IRQ 11
I/O ports at 5000 [size=64]
I/O ports at 6000 [size=64]
Capabilities: <access denied>
Kernel driver in use: nForce2_smbus
Kernel modules: i2c-nforce2
00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3)
Subsystem: Micro-Star International Co., Ltd. Device 7380
Flags: 66MHz, fast devsel
00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
(prog-if 10 [OHCI])
Subsystem: Micro-Star International Co., Ltd. Device 7380
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 20
Memory at f9fff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
Kernel driver in use: ohci_hcd
00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
(prog-if 20 [EHCI])
Subsystem: Micro-Star International Co., Ltd. Device 7380
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 21
Memory at f9ffec00 (32-bit, non-prefetchable) [size=256]
Capabilities: <access denied>
Kernel driver in use: ehci_hcd
00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev a1) (prog-if 8a
[Master SecP PriP])
Subsystem: Micro-Star International Co., Ltd. Device 7380
Flags: bus master, 66MHz, fast devsel, latency 0
[virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1]
[virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 00000370 (type 3, non-prefetchable) [size=1]
I/O ports at ffa0 [size=16]
Capabilities: <access denied>
Kernel driver in use: pata_amd
Kernel modules: pata_amd
00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev
a1) (prog-if 85 [Master SecO PriO])
Subsystem: Micro-Star International Co., Ltd. Device 7380
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23
I/O ports at c800 [size=8]
I/O ports at c480 [size=4]
I/O ports at c400 [size=8]
I/O ports at c080 [size=4]
I/O ports at c000 [size=16]
Memory at f9ffd000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
Kernel driver in use: sata_nv
Kernel modules: sata_nv
00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev
a1) (prog-if 85 [Master SecO PriO])
Subsystem: Micro-Star International Co., Ltd. Device 7380
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22
I/O ports at bc00 [size=8]
I/O ports at b880 [size=4]
I/O ports at b800 [size=8]
I/O ports at b480 [size=4]
I/O ports at b400 [size=16]
Memory at f9ffc000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
Kernel driver in use: sata_nv
Kernel modules: sata_nv
00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2) (prog-if
01 [Subtractive decode])
Flags: bus master, 66MHz, fast devsel, latency 0
Bus: primary=00, secondary=08, subordinate=08, sec-latency=32
I/O behind bridge: 0000e000-0000efff
Memory behind bridge: feb00000-febfffff
Capabilities: <access denied>
00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev
a2)
Subsystem: Micro-Star International Co., Ltd. Device 7380
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22
Memory at f9ff8000 (32-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel
00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)
Subsystem: Micro-Star International Co., Ltd. Device 380c
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23
Memory at f9ff7000 (32-bit, non-prefetchable) [size=4K]
I/O ports at b080 [size=8]
Capabilities: <access denied>
Kernel driver in use: forcedeth
Kernel modules: forcedeth
01:00.0 PCI bridge: nVidia Corporation NF200 PCIe 2.0 switch for
mainboards (rev a2) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=01, secondary=02, subordinate=05, sec-latency=0
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: fa000000-feafffff
Prefetchable memory behind bridge: 00000000d0000000-00000000dfffffff
Capabilities: <access denied>
Kernel driver in use: pcieport
Kernel modules: shpchp
02:00.0 PCI bridge: nVidia Corporation NF200 PCIe 2.0 switch for
mainboards (rev a2) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=02, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: fa000000-feafffff
Prefetchable memory behind bridge: 00000000d0000000-00000000dfffffff
Capabilities: <access denied>
Kernel driver in use: pcieport
Kernel modules: shpchp
02:02.0 PCI bridge: nVidia Corporation NF200 PCIe 2.0 switch for
mainboards (rev a2) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=02, secondary=04, subordinate=04, sec-latency=0
Capabilities: <access denied>
Kernel driver in use: pcieport
Kernel modules: shpchp
02:03.0 PCI bridge: nVidia Corporation NF200 PCIe 2.0 switch for
mainboards (rev a2) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=02, secondary=05, subordinate=05, sec-latency=0
Capabilities: <access denied>
Kernel driver in use: pcieport
Kernel modules: shpchp
03:00.0 VGA compatible controller: nVidia Corporation GT200 [GeForce GTX
280] (rev a1) (prog-if 00 [VGA controller])
Subsystem: eVga.com. Corp. Device 1280
Flags: bus master, fast devsel, latency 0, IRQ 19
Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
Memory at d0000000 (64-bit, prefetchable) [size=256M]
Memory at fa000000 (64-bit, non-prefetchable) [size=32M]
I/O ports at dc00 [size=128]
[virtual] Expansion ROM at fea80000 [disabled] [size=512K]
Capabilities: <access denied>
Kernel driver in use: nvidia
Kernel modules: nvidia, nvidiafb
08:09.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire
II(M)] IEEE 1394 OHCI Controller (rev c0) (prog-if 10 [OHCI])
Subsystem: Micro-Star International Co., Ltd. Device 380d
Flags: bus master, medium devsel, latency 32, IRQ 10
Memory at febff800 (32-bit, non-prefetchable) [size=2K]
I/O ports at ec00 [size=128]
Capabilities: <access denied>
Um. Should my routing table be being displayed in reverse order all of
a sudden?
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth1
ip route list is similar. I'm sure this is going to break a script or two
(and, perhaps, a mind or two :).
--
"A search of his car uncovered pornography, a homemade sex aid, women's
stockings and a Jack Russell terrier."
- http://www.dailytelegraph.com.au/news/wacky/indeed/story-e6frev20-1111118083480
On Thu, 2011-05-19 at 17:23 +0100, Randy Dunlap wrote:
> On Thu, 19 May 2011 17:16:32 +0100 Catalin Marinas wrote:
> > On 19 May 2011 16:44, Mark Lord <[email protected]> wrote:
> > > Here's some more funny business that was new after rc7-git12:
> > >
> > > warning: (AX88796_93CX6 && RTL8180 && RTL8187 && ADM8211 && RT2400PCI &&
> > > RT2500PCI && RT61PCI && RT2800PCI && R8187SE) selects EEPROM_93CX6 which has
> > > unmet direct dependencies (MISC_DEVICES)
> > > warning: (ACPI_APEI) selects PSTORE which has unmet direct dependencies
> > > (MISC_FILESYSTEMS)
> > >
> > > The exact same .config didn't do that with rc7-git12,
> > > but does do it with 2.6.39 final.
> > >
> > > Odd thing is, if I select both MISC_DEVICES and MISC_FILESYSTEMS,
> > > but do NOT select anything from under either of those,
> > > the warnings go away.
> > >
> > > Which likely means the warnings are totally bogus.
> >
> > The problem is:
> >
> > AX88796_93CX6 selects EEPROM_93CX6
> > EEPROM_93CX6 depends on MISC_DEVICES (as part of the EEPROM menu which
> > is only included if MISC_DEVICES)
> >
> > By enabling MISC_DEVICES, you allow AX88796_93CX6 to select
> > EEPROM_93CX6 without any warning as it has the dependencies met.
> >
> > The issue here is that EEPROM_93CX6 doesn't really depend on any
> > MISC_DEVICES infrastructure. That's just a directory for various
> > drivers and MISC_DEVICES only has a visibility role. There was a
> > proposal last year for kbuild to differentiate between dependency and
> > visibility but I don't know what happened to it.
>
> fwiw, there is a VISIBLE attribute now. It defaults to yes/on.
OK. It helps but only if all the misc devices have "visible if
MISC_DEVICES" in their config options and entirely eliminate the
"if/endif" block.
Alternatively, maybe the if/endif block could generate a visibility
expression rather than a dependency. It works for MISC_DEVICES but I'm
not sure whether this is applicable across the kernel.
--
Catalin
On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
> On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> > Hi Linus, I'm sorry bothering you, but my usb-bluetooth dongle stop working in
> > 2.6.39 kernel series.
> > I know it is nothing ground breaking but it is bug.
> > I'm using this hardware from 2.6.11 kernel series.
> > Details are included in this thread:
> >
> > https://lkml.org/lkml/2011/4/18/481
> >
> > I hope I'm doing nothing false writing this email.
>
> Same device, same problem here.
>
> You are not alone
I had some time this afternood so I tried bisecting without much luck. I ended up somewhere rc1 ish with a system
that would paniced during boot. Here is the bisect log incase it helps:
# bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
# good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38
git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
# bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
git bisect bad 7a6362800cb7d1d618a697a650c7aaed3eb39320
# bad: [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
git bisect bad 0a0e9ae1bd788bc19adc4d4ae08c98b233697402
# skip: [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use usb_fill_int_urb()
git bisect skip 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69
# skip: [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci a child of the corresponding tty device.
git bisect skip 7f4b2b04c88377af30c022f36c060190182850fb
# skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth: ath3k: Avoid duplication of code
git bisect skip 84f0e17f78471857104a20dfc57711409f68d7bf
Ring any bells for anyone?
Probably should open a regression bug for this too....
TIA
Ed
On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
> On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
> > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> > > Hi Linus, I'm sorry bothering you, but my usb-bluetooth dongle stop working in
> > > 2.6.39 kernel series.
> > > I know it is nothing ground breaking but it is bug.
> > > I'm using this hardware from 2.6.11 kernel series.
> > > Details are included in this thread:
> > >
> > > https://lkml.org/lkml/2011/4/18/481
> > >
> > > I hope I'm doing nothing false writing this email.
> >
> > Same device, same problem here.
> >
> > You are not alone
>
> I had some time this afternood so I tried bisecting without much luck. I ended up somewhere rc1 ish with a system
> that would paniced during boot. Here is the bisect log incase it helps:
>
> # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
> # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38
> git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
> # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
> git bisect bad 7a6362800cb7d1d618a697a650c7aaed3eb39320
> # bad: [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
> git bisect bad 0a0e9ae1bd788bc19adc4d4ae08c98b233697402
> # skip: [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use usb_fill_int_urb()
> git bisect skip 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69
> # skip: [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci a child of the corresponding tty device.
> git bisect skip 7f4b2b04c88377af30c022f36c060190182850fb
> # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth: ath3k: Avoid duplication of code
> git bisect skip 84f0e17f78471857104a20dfc57711409f68d7bf
>
> Ring any bells for anyone?
>
> Probably should open a regression bug for this too....
I think this is regression with d5859e22cd40b73164b3e5d8d5d796f96edcc6af
commit. Probably the code tries to enable something that is not supported.
Could you pastebin hcidump while doing hciconfig hci0 up?
--
Ville
On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
> > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
> > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
> > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> > > > > Hi Linus, I'm sorry bothering you, but my usb-bluetooth dongle stop working in
> > > > > 2.6.39 kernel series.
> > > > > I know it is nothing ground breaking but it is bug.
> > > > > I'm using this hardware from 2.6.11 kernel series.
> > > > > Details are included in this thread:
> > > > >
> > > > > https://lkml.org/lkml/2011/4/18/481
> > > > >
> > > > > I hope I'm doing nothing false writing this email.
> > > >
> > > > Same device, same problem here.
> > > >
> > > > You are not alone
> > >
> > > I had some time this afternood so I tried bisecting without much luck. I ended up \
> > > somewhere rc1 ish with a system that would paniced during boot. Here is the bisect \
> > > log incase it helps:
> > > # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
> > > # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38
> > > git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
> > > # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge \
> > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6 git bisect bad \
> > > 7a6362800cb7d1d618a697a650c7aaed3eb39320 # bad: \
> > > [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch 'master' of \
> > > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git bisect bad \
> > > 0a0e9ae1bd788bc19adc4d4ae08c98b233697402 # skip: \
> > > [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use usb_fill_int_urb() git \
> > > bisect skip 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69 # skip: \
> > > [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci a child of the \
> > > corresponding tty device. git bisect skip 7f4b2b04c88377af30c022f36c060190182850fb
> > > # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth: ath3k: Avoid \
> > > duplication of code git bisect skip 84f0e17f78471857104a20dfc57711409f68d7bf
> > >
> > > Ring any bells for anyone?
> > >
> > > Probably should open a regression bug for this too....
> >
> > I think this is regression with d5859e22cd40b73164b3e5d8d5d796f96edcc6af
> > commit. Probably the code tries to enable something that is not supported.
> >
> > Could you pastebin hcidump while doing hciconfig hci0 up?
hcidump
HCI sniffer - Bluetooth packet analyzer ver 2.0
device: hci0 snap_len: 1028 filter: 0xffffffffffffffff
< HCI Command: Reset (0x03|0x0003) plen 0
> HCI Event: Command Complete (0x0e) plen 4
Reset (0x03|0x0003) ncmd 1
status 0x00
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
> HCI Event: Command Complete (0x0e) plen 12
Read Local Supported Features (0x04|0x0003) ncmd 1
status 0x00
Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
> HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
status 0x00
HCI Version: 1.1 (0x1) HCI Revision: 0x20d
LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
Manufacturer: Cambridge Silicon Radio (10)
< HCI Command: Read Buffer Size (0x04|0x0005) plen 0
> HCI Event: Command Complete (0x0e) plen 11
Read Buffer Size (0x04|0x0005) ncmd 1
status 0x00
ACL MTU 192:8 SCO MTU 64:8
< HCI Command: Read BD ADDR (0x04|0x0009) plen 0
> HCI Event: Command Complete (0x0e) plen 10
Read BD ADDR (0x04|0x0009) ncmd 1
status 0x00 bdaddr 00:0A:3A:55:07:5A
< HCI Command: Read Class of Device (0x03|0x0023) plen 0
> HCI Event: Command Complete (0x0e) plen 7
Read Class of Device (0x03|0x0023) ncmd 1
status 0x00 class 0x000000
< HCI Command: Read Local Name (0x03|0x0014) plen 0
> HCI Event: Command Complete (0x0e) plen 252
Read Local Name (0x03|0x0014) ncmd 1
status 0x00 name 'grover-0'
< HCI Command: Read Voice Setting (0x03|0x0025) plen 0
> HCI Event: Command Complete (0x0e) plen 6
Read Voice Setting (0x03|0x0025) ncmd 1
status 0x00 voice setting 0x0060
< HCI Command: Set Event Filter (0x03|0x0005) plen 1
type 0 condition 0
Clear all filters
> HCI Event: Command Complete (0x0e) plen 4
Set Event Filter (0x03|0x0005) ncmd 1
status 0x00
< HCI Command: Write Connection Accept Timeout (0x03|0x0016) plen 2
timeout 32000
> HCI Event: Command Complete (0x0e) plen 4
Write Connection Accept Timeout (0x03|0x0016) ncmd 1
status 0x00
< HCI Command: Delete Stored Link Key (0x03|0x0012) plen 7
bdaddr 00:00:00:00:00:00 all 1
> HCI Event: Command Complete (0x0e) plen 6
Delete Stored Link Key (0x03|0x0012) ncmd 1
status 0x00 deleted 0
< HCI Command: Set Event Mask (0x03|0x0001) plen 8
Mask: 0xfffffbff00000000
> HCI Event: Command Complete (0x0e) plen 4
Set Event Mask (0x03|0x0001) ncmd 1
status 0x12
Error: Invalid HCI Command Parameters
Thanks
Ed
> This sounds like it could be the same problem I mailed about here:
> http://marc.info/?l=linux-bluetooth&m=130610549726588&w=2.
> I still haven't determined why the HCI_OP_SET_EVENT_MASK command was failing.
>
> Hope this helps!
>
>
On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
> On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
> > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
> > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
> > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> > > > > > Hi Linus, I'm sorry bothering you, but my usb-bluetooth dongle stop working in
> > > > > > 2.6.39 kernel series.
> > > > > > I know it is nothing ground breaking but it is bug.
> > > > > > I'm using this hardware from 2.6.11 kernel series.
> > > > > > Details are included in this thread:
> > > > > >
> > > > > > https://lkml.org/lkml/2011/4/18/481
> > > > > >
> > > > > > I hope I'm doing nothing false writing this email.
> > > > >
> > > > > Same device, same problem here.
> > > > >
> > > > > You are not alone
> > > >
> > > > I had some time this afternood so I tried bisecting without much luck. I ended up \
> > > > somewhere rc1 ish with a system that would paniced during boot. Here is the bisect \
> > > > log incase it helps:
> > > > # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
> > > > # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38
> > > > git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
> > > > # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge \
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6 git bisect bad \
> > > > 7a6362800cb7d1d618a697a650c7aaed3eb39320 # bad: \
> > > > [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch 'master' of \
> > > > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git bisect bad \
> > > > 0a0e9ae1bd788bc19adc4d4ae08c98b233697402 # skip: \
> > > > [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use usb_fill_int_urb() git \
> > > > bisect skip 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69 # skip: \
> > > > [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci a child of the \
> > > > corresponding tty device. git bisect skip 7f4b2b04c88377af30c022f36c060190182850fb
> > > > # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth: ath3k: Avoid \
> > > > duplication of code git bisect skip 84f0e17f78471857104a20dfc57711409f68d7bf
> > > >
> > > > Ring any bells for anyone?
> > > >
> > > > Probably should open a regression bug for this too....
> > >
> > > I think this is regression with d5859e22cd40b73164b3e5d8d5d796f96edcc6af
> > > commit. Probably the code tries to enable something that is not supported.
> > >
> > > Could you pastebin hcidump while doing hciconfig hci0 up?
Some cutting done
>
> hcidump
> HCI sniffer - Bluetooth packet analyzer ver 2.0
> < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
> > HCI Event: Command Complete (0x0e) plen 12
> Read Local Supported Features (0x04|0x0003) ncmd 1
> status 0x00
> Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
> < HCI Command: Read Local Version Information (0x04|0x0001) plen 0
> > HCI Event: Command Complete (0x0e) plen 12
> Read Local Version Information (0x04|0x0001) ncmd 1
> status 0x00
> HCI Version: 1.1 (0x1) HCI Revision: 0x20d
> LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
> Manufacturer: Cambridge Silicon Radio (10)
> < HCI Command: Set Event Mask (0x03|0x0001) plen 8
> Mask: 0xfffffbff00000000
> > HCI Event: Command Complete (0x0e) plen 4
> Set Event Mask (0x03|0x0001) ncmd 1
> status 0x12
> Error: Invalid HCI Command Parameters
>
Yes the HCI_OP_SET_EVENT_MASK cmd seems to be the source of problems.
Maybe is rejects it because two reserved bits are being enabled. Could you try
this patch?
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 19cd4af..e483e30 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -475,7 +475,7 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
/* The second byte is 0xff instead of 0x9f (two reserved bits
* disabled) since a Broadcom 1.2 dongle doesn't respond to the
* command otherwise */
- u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
+ u8 events[8] = { 0xff, 0x9f, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
/* Events for 1.2 and newer controllers */
if (hdev->lmp_ver > 1) {
--
Ville
On Wed, May 25, 2011 at 7:36 AM, Ville Tervo <[email protected]> wrote:
> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
>> On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
>> > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>> > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>> > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
>> > > > > > Hi Linus, I'm sorry bothering you, but my usb-bluetooth dongle stop working in
>> > > > > > 2.6.39 kernel series.
>> > > > > > I know it is nothing ground breaking but it is bug.
>> > > > > > I'm using this hardware from 2.6.11 kernel series.
>> > > > > > Details are included in this thread:
>> > > > > >
>> > > > > > https://lkml.org/lkml/2011/4/18/481
>> > > > > >
>> > > > > > I hope I'm doing nothing false writing this email.
>> > > > >
>> > > > > Same device, same problem here.
>> > > > >
>> > > > > You are not alone
>> > > >
>> > > > I had some time this afternood so I tried bisecting without much luck. ?I ended up \
>> > > > somewhere rc1 ish with a system that would paniced during boot. ?Here is the bisect \
>> > > > log incase it helps:
>> > > > # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
>> > > > # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38
>> > > > git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
>> > > > # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge \
>> > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6 git bisect bad \
>> > > > 7a6362800cb7d1d618a697a650c7aaed3eb39320 # bad: \
>> > > > [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch 'master' of \
>> > > > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git bisect bad \
>> > > > 0a0e9ae1bd788bc19adc4d4ae08c98b233697402 # skip: \
>> > > > [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use usb_fill_int_urb() git \
>> > > > bisect skip 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69 # skip: \
>> > > > [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci a child of the \
>> > > > corresponding tty device. git bisect skip 7f4b2b04c88377af30c022f36c060190182850fb
>> > > > # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth: ath3k: Avoid \
>> > > > duplication of code git bisect skip 84f0e17f78471857104a20dfc57711409f68d7bf
>> > > >
>> > > > Ring any bells for anyone?
>> > > >
>> > > > Probably should open a regression bug for this too....
>> > >
>> > > I think this is regression with d5859e22cd40b73164b3e5d8d5d796f96edcc6af
>> > > commit. Probably the code tries to enable something that is not supported.
>> > >
>> > > Could you pastebin hcidump while doing hciconfig hci0 up?
>
> Some cutting done
>
>>
>> hcidump
>> HCI sniffer - Bluetooth packet analyzer ver 2.0
>> < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
>> > HCI Event: Command Complete (0x0e) plen 12
>> ? ? Read Local Supported Features (0x04|0x0003) ncmd 1
>> ? ? status 0x00
>> ? ? Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
>> < HCI Command: Read Local Version Information (0x04|0x0001) plen 0
>> > HCI Event: Command Complete (0x0e) plen 12
>> ? ? Read Local Version Information (0x04|0x0001) ncmd 1
>> ? ? status 0x00
>> ? ? HCI Version: 1.1 (0x1) HCI Revision: 0x20d
>> ? ? LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
>> ? ? Manufacturer: Cambridge Silicon Radio (10)
>> < HCI Command: Set Event Mask (0x03|0x0001) plen 8
>> ? ? Mask: 0xfffffbff00000000
>> > HCI Event: Command Complete (0x0e) plen 4
>> ? ? Set Event Mask (0x03|0x0001) ncmd 1
>> ? ? status 0x12
>> ? ? Error: Invalid HCI Command Parameters
>>
>
> Yes the HCI_OP_SET_EVENT_MASK cmd seems to be the source of problems.
>
> Maybe is rejects it because two reserved bits are being enabled. Could you try
> this patch?
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 19cd4af..e483e30 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -475,7 +475,7 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
> ? ? ? ?/* The second byte is 0xff instead of 0x9f (two reserved bits
> ? ? ? ? * disabled) since a Broadcom 1.2 dongle doesn't respond to the
> ? ? ? ? * command otherwise */
> - ? ? ? u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
> + ? ? ? u8 events[8] = { 0xff, 0x9f, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
>
> ? ? ? ?/* Events for 1.2 and newer controllers */
> ? ? ? ?if (hdev->lmp_ver > 1) {
>
>
> --
> Ville
>
No luck for me with a Microsoft Wireless Transceiver for Bluetooth.
Not sending the HCI_OP_SET_EVENT_MASK command at all seems to fix it,
but it seems to have negative effects on my devices battery life when
doing so.
On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> > > > > > > Hi Linus, I'm sorry bothering you, but my usb-bluetooth dongle stop working in
> > > > > > > 2.6.39 kernel series.
> > > > > > > I know it is nothing ground breaking but it is bug.
> > > > > > > I'm using this hardware from 2.6.11 kernel series.
> > > > > > > Details are included in this thread:
> > > > > > >
> > > > > > > https://lkml.org/lkml/2011/4/18/481
> > > > > > >
> > > > > > > I hope I'm doing nothing false writing this email.
> > > > > >
> > > > > > Same device, same problem here.
> > > > > >
> > > > > > You are not alone
> > > > >
> > > > > I had some time this afternood so I tried bisecting without much luck. I ended up \
> > > > > somewhere rc1 ish with a system that would paniced during boot. Here is the bisect \
> > > > > log incase it helps:
> > > > > # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
> > > > > # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38
> > > > > git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
> > > > > # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge \
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6 git bisect bad \
> > > > > 7a6362800cb7d1d618a697a650c7aaed3eb39320 # bad: \
> > > > > [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch 'master' of \
> > > > > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git bisect bad \
> > > > > 0a0e9ae1bd788bc19adc4d4ae08c98b233697402 # skip: \
> > > > > [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use usb_fill_int_urb() git \
> > > > > bisect skip 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69 # skip: \
> > > > > [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci a child of the \
> > > > > corresponding tty device. git bisect skip 7f4b2b04c88377af30c022f36c060190182850fb
> > > > > # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth: ath3k: Avoid \
> > > > > duplication of code git bisect skip 84f0e17f78471857104a20dfc57711409f68d7bf
> > > > >
> > > > > Ring any bells for anyone?
> > > > >
> > > > > Probably should open a regression bug for this too....
> > > >
> > > > I think this is regression with d5859e22cd40b73164b3e5d8d5d796f96edcc6af
> > > > commit. Probably the code tries to enable something that is not supported.
> > > >
> > > > Could you pastebin hcidump while doing hciconfig hci0 up?
>
> Some cutting done
>
> >
> > hcidump
> > HCI sniffer - Bluetooth packet analyzer ver 2.0
> > < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
> > > HCI Event: Command Complete (0x0e) plen 12
> > Read Local Supported Features (0x04|0x0003) ncmd 1
> > status 0x00
> > Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
> > < HCI Command: Read Local Version Information (0x04|0x0001) plen 0
> > > HCI Event: Command Complete (0x0e) plen 12
> > Read Local Version Information (0x04|0x0001) ncmd 1
> > status 0x00
> > HCI Version: 1.1 (0x1) HCI Revision: 0x20d
> > LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
> > Manufacturer: Cambridge Silicon Radio (10)
> > < HCI Command: Set Event Mask (0x03|0x0001) plen 8
> > Mask: 0xfffffbff00000000
> > > HCI Event: Command Complete (0x0e) plen 4
> > Set Event Mask (0x03|0x0001) ncmd 1
> > status 0x12
> > Error: Invalid HCI Command Parameters
> >
>
> Yes the HCI_OP_SET_EVENT_MASK cmd seems to be the source of problems.
>
> Maybe is rejects it because two reserved bits are being enabled. Could you try
> this patch?
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 19cd4af..e483e30 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -475,7 +475,7 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
> /* The second byte is 0xff instead of 0x9f (two reserved bits
> * disabled) since a Broadcom 1.2 dongle doesn't respond to the
> * command otherwise */
> - u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
> + u8 events[8] = { 0xff, 0x9f, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
>
> /* Events for 1.2 and newer controllers */
> if (hdev->lmp_ver > 1) {
No luck here - same results.
Thanks
Ed
On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> > > > > > > Hi Linus, I'm sorry bothering you, but my usb-bluetooth
> > > > > > > dongle stop working in
> > > > > > > 2.6.39 kernel series.
> > > > > > > I know it is nothing ground breaking but it is bug.
> > > > > > > I'm using this hardware from 2.6.11 kernel series.
> > > > > > > Details are included in this thread:
> > > > > > >
> > > > > > > https://lkml.org/lkml/2011/4/18/481
> > > > > > >
> > > > > > > I hope I'm doing nothing false writing this email.
> > > > > >
> > > > > > Same device, same problem here.
> > > > > >
> > > > > > You are not alone
> > > > >
> > > > > I had some time this afternood so I tried bisecting without
> > > > > much luck. I ended up \ somewhere rc1 ish with a system that
> > > > > would paniced during boot. Here is the bisect \ log incase it helps:
> > > > > # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
> > > > > # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux
> > > > > 2.6.38 git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
> > > > > # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge \
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2
> > > > > .6 git bisect bad \
> > > > > 7a6362800cb7d1d618a697a650c7aaed3eb39320 # bad: \
> > > > > [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch
> > > > > 'master' of \
> > > > > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git
> > > > > bisect bad \
> > > > > 0a0e9ae1bd788bc19adc4d4ae08c98b233697402 # skip: \
> > > > > [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use
> > > > > usb_fill_int_urb() git \ bisect skip
> > > > > 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69 # skip: \
> > > > > [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci
> > > > > a child of the \ corresponding tty device. git bisect skip
> > > > > 7f4b2b04c88377af30c022f36c060190182850fb
> > > > > # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth:
> > > > > ath3k: Avoid \ duplication of code git bisect skip
> > > > > 84f0e17f78471857104a20dfc57711409f68d7bf
> > > > >
> > > > > Ring any bells for anyone?
> > > > >
> > > > > Probably should open a regression bug for this too....
> > > >
> > > > I think this is regression with
> > > > d5859e22cd40b73164b3e5d8d5d796f96edcc6af
> > > > commit. Probably the code tries to enable something that is not supported.
> > > >
> > > > Could you pastebin hcidump while doing hciconfig hci0 up?
>
> Some cutting done
>
> >
> > hcidump
> > HCI sniffer - Bluetooth packet analyzer ver 2.0 < HCI Command: Read
> > Local Supported Features (0x04|0x0003) plen 0
> > > HCI Event: Command Complete (0x0e) plen 12
> > Read Local Supported Features (0x04|0x0003) ncmd 1
> > status 0x00
> > Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00 < HCI Command:
> > Read Local Version Information (0x04|0x0001) plen 0
> > > HCI Event: Command Complete (0x0e) plen 12
> > Read Local Version Information (0x04|0x0001) ncmd 1
> > status 0x00
> > HCI Version: 1.1 (0x1) HCI Revision: 0x20d
> > LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
> > Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
> > Event Mask (0x03|0x0001) plen 8
> > Mask: 0xfffffbff00000000
> > > HCI Event: Command Complete (0x0e) plen 4
> > Set Event Mask (0x03|0x0001) ncmd 1
> > status 0x12
> > Error: Invalid HCI Command Parameters
> >
>
> Yes the HCI_OP_SET_EVENT_MASK cmd seems to be the source of problems.
>
> Maybe is rejects it because two reserved bits are being enabled. Could
> you try this patch?
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 19cd4af..e483e30 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -475,7 +475,7 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
> /* The second byte is 0xff instead of 0x9f (two reserved bits
> * disabled) since a Broadcom 1.2 dongle doesn't respond to the
> * command otherwise */
> - u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
> + u8 events[8] = { 0xff, 0x9f, 0xfb, 0xff, 0x00, 0x00, 0x00,
> + 0x00 };
>
> /* Events for 1.2 and newer controllers */
> if (hdev->lmp_ver > 1) {
> No luck here - same results.
For what it's worth:
With a (recent)CSR chipset, with 2.6.38 only Set Event Filter is used (with a 0 filter) and no Set Event Mask is sent at all. With Bluetooth-next, I get the following:
< HCI Command: Set Event Mask (0x03|0x0001) plen 8
Mask: 0xfffffbff07f8bf3d
> HCI Event: Command Complete (0x0e) plen 4
Set Event Mask (0x03|0x0001) ncmd 1
status 0x00
So Set Event Mask actually seems to go through without any problems.
Carles
On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <[email protected]> wrote:
>
>
> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
>> > > > > > > Hi Linus, I'm sorry bothering you, but my usb-bluetooth
>> > > > > > > dongle stop working in
>> > > > > > > 2.6.39 kernel series.
>> > > > > > > I know it is nothing ground breaking but it is bug.
>> > > > > > > I'm using this hardware from 2.6.11 kernel series.
>> > > > > > > Details are included in this thread:
>> > > > > > >
>> > > > > > > https://lkml.org/lkml/2011/4/18/481
>> > > > > > >
>> > > > > > > I hope I'm doing nothing false writing this email.
>> > > > > >
>> > > > > > Same device, same problem here.
>> > > > > >
>> > > > > > You are not alone
>> > > > >
>> > > > > I had some time this afternood so I tried bisecting without
>> > > > > much luck. ?I ended up \ somewhere rc1 ish with a system that
>> > > > > would paniced during boot. ?Here is the bisect \ log incase it helps:
>> > > > > # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
>> > > > > # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux
>> > > > > 2.6.38 git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
>> > > > > # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge \
>> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2
>> > > > > .6 git bisect bad \
>> > > > > 7a6362800cb7d1d618a697a650c7aaed3eb39320 # bad: \
>> > > > > [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch
>> > > > > 'master' of \
>> > > > > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git
>> > > > > bisect bad \
>> > > > > 0a0e9ae1bd788bc19adc4d4ae08c98b233697402 # skip: \
>> > > > > [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use
>> > > > > usb_fill_int_urb() git \ bisect skip
>> > > > > 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69 # skip: \
>> > > > > [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci
>> > > > > a child of the \ corresponding tty device. git bisect skip
>> > > > > 7f4b2b04c88377af30c022f36c060190182850fb
>> > > > > # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth:
>> > > > > ath3k: Avoid \ duplication of code git bisect skip
>> > > > > 84f0e17f78471857104a20dfc57711409f68d7bf
>> > > > >
>> > > > > Ring any bells for anyone?
>> > > > >
>> > > > > Probably should open a regression bug for this too....
>> > > >
>> > > > I think this is regression with
>> > > > d5859e22cd40b73164b3e5d8d5d796f96edcc6af
>> > > > commit. Probably the code tries to enable something that is not supported.
>> > > >
>> > > > Could you pastebin hcidump while doing hciconfig hci0 up?
>>
>> Some cutting done
>>
>> >
>> > hcidump
>> > HCI sniffer - Bluetooth packet analyzer ver 2.0 < HCI Command: Read
>> > Local Supported Features (0x04|0x0003) plen 0
>> > > HCI Event: Command Complete (0x0e) plen 12
>> > ? ? Read Local Supported Features (0x04|0x0003) ncmd 1
>> > ? ? status 0x00
>> > ? ? Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00 < HCI Command:
>> > Read Local Version Information (0x04|0x0001) plen 0
>> > > HCI Event: Command Complete (0x0e) plen 12
>> > ? ? Read Local Version Information (0x04|0x0001) ncmd 1
>> > ? ? status 0x00
>> > ? ? HCI Version: 1.1 (0x1) HCI Revision: 0x20d
>> > ? ? LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
>> > ? ? Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
>> > Event Mask (0x03|0x0001) plen 8
>> > ? ? Mask: 0xfffffbff00000000
>> > > HCI Event: Command Complete (0x0e) plen 4
>> > ? ? Set Event Mask (0x03|0x0001) ncmd 1
>> > ? ? status 0x12
>> > ? ? Error: Invalid HCI Command Parameters
>> >
>>
>> Yes the HCI_OP_SET_EVENT_MASK cmd seems to be the source of problems.
>>
>> Maybe is rejects it because two reserved bits are being enabled. Could
>> you try this patch?
>>
>> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
>> index 19cd4af..e483e30 100644
>> --- a/net/bluetooth/hci_event.c
>> +++ b/net/bluetooth/hci_event.c
>> @@ -475,7 +475,7 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
>> ? ? ? ? /* The second byte is 0xff instead of 0x9f (two reserved bits
>> ? ? ? ? ?* disabled) since a Broadcom 1.2 dongle doesn't respond to the
>> ? ? ? ? ?* command otherwise */
>> - ? ? ? u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
>> + ? ? ? u8 events[8] = { 0xff, 0x9f, 0xfb, 0xff, 0x00, 0x00, 0x00,
>> + 0x00 };
>>
>> ? ? ? ? /* Events for 1.2 and newer controllers */
>> ? ? ? ? if (hdev->lmp_ver > 1) {
>
>> No luck here - same results.
>
> For what it's worth:
>
> With a (recent)CSR chipset, with 2.6.38 only Set Event Filter is used (with a 0 filter) and no Set Event Mask is sent at all. With Bluetooth-next, I get the following:
>
> < HCI Command: Set Event Mask (0x03|0x0001) plen 8
> ? ?Mask: 0xfffffbff07f8bf3d
>> HCI Event: Command Complete (0x0e) plen 4
> ? ?Set Event Mask (0x03|0x0001) ncmd 1
> ? ?status 0x00
>
> So Set Event Mask actually seems to go through without any problems.
>
> Carles
>
My adapter is from 2002 so I'm guessing it either doesn't support Set
Event Mask at all, or is very sensitive about the values it receives.
I tried to figure out what chip it is using by disassembling the
dongle, but the chip seems to be covered by a metal case which is
soldered to the board and I'd rather not try to rip it off.
Any thoughts on how to further debug this apart from trying all
possible values of event mask?
On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <[email protected]> wrote:
>
>
> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
>> > > > > > > Hi Linus, I'm sorry bothering you, but my usb-bluetooth
>> > > > > > > dongle stop working in
>> > > > > > > 2.6.39 kernel series.
>> > > > > > > I know it is nothing ground breaking but it is bug.
>> > > > > > > I'm using this hardware from 2.6.11 kernel series.
>> > > > > > > Details are included in this thread:
>> > > > > > >
>> > > > > > > https://lkml.org/lkml/2011/4/18/481
>> > > > > > >
>> > > > > > > I hope I'm doing nothing false writing this email.
>> > > > > >
>> > > > > > Same device, same problem here.
>> > > > > >
>> > > > > > You are not alone
>> > > > >
>> > > > > I had some time this afternood so I tried bisecting without
>> > > > > much luck. ?I ended up \ somewhere rc1 ish with a system that
>> > > > > would paniced during boot. ?Here is the bisect \ log incase it helps:
>> > > > > # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux
>> > > > > 2.6.39 # good: [521cb40b0c44418a4fd36dc633f575813d59a43d]
>> > > > > Linux
>> > > > > 2.6.38 git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
>> > > > > # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge \
>> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-
>> > > > > 2
>> > > > > .6 git bisect bad \
>> > > > > 7a6362800cb7d1d618a697a650c7aaed3eb39320 # bad: \
>> > > > > [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch
>> > > > > 'master' of \
>> > > > > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git
>> > > > > bisect bad \
>> > > > > 0a0e9ae1bd788bc19adc4d4ae08c98b233697402 # skip: \
>> > > > > [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use
>> > > > > usb_fill_int_urb() git \ bisect skip
>> > > > > 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69 # skip: \
>> > > > > [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make
>> > > > > hci a child of the \ corresponding tty device. git bisect
>> > > > > skip 7f4b2b04c88377af30c022f36c060190182850fb
>> > > > > # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth:
>> > > > > ath3k: Avoid \ duplication of code git bisect skip
>> > > > > 84f0e17f78471857104a20dfc57711409f68d7bf
>> > > > >
>> > > > > Ring any bells for anyone?
>> > > > >
>> > > > > Probably should open a regression bug for this too....
>> > > >
>> > > > I think this is regression with
>> > > > d5859e22cd40b73164b3e5d8d5d796f96edcc6af
>> > > > commit. Probably the code tries to enable something that is not supported.
>> > > >
>> > > > Could you pastebin hcidump while doing hciconfig hci0 up?
>>
>> Some cutting done
>>
>> >
>> > hcidump
>> > HCI sniffer - Bluetooth packet analyzer ver 2.0 < HCI Command: Read
>> > Local Supported Features (0x04|0x0003) plen 0
>> > > HCI Event: Command Complete (0x0e) plen 12
>> > ? ? Read Local Supported Features (0x04|0x0003) ncmd 1
>> > ? ? status 0x00
>> > ? ? Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00 < HCI Command:
>> > Read Local Version Information (0x04|0x0001) plen 0
>> > > HCI Event: Command Complete (0x0e) plen 12
>> > ? ? Read Local Version Information (0x04|0x0001) ncmd 1
>> > ? ? status 0x00
>> > ? ? HCI Version: 1.1 (0x1) HCI Revision: 0x20d
>> > ? ? LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
>> > ? ? Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
>> > Event Mask (0x03|0x0001) plen 8
>> > ? ? Mask: 0xfffffbff00000000
>> > > HCI Event: Command Complete (0x0e) plen 4
>> > ? ? Set Event Mask (0x03|0x0001) ncmd 1
>> > ? ? status 0x12
>> > ? ? Error: Invalid HCI Command Parameters
>> >
>>
>> Yes the HCI_OP_SET_EVENT_MASK cmd seems to be the source of problems.
>>
>> Maybe is rejects it because two reserved bits are being enabled.
>> Could you try this patch?
>>
>> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
>> index 19cd4af..e483e30 100644
>> --- a/net/bluetooth/hci_event.c
>> +++ b/net/bluetooth/hci_event.c
>> @@ -475,7 +475,7 @@ static void hci_setup_event_mask(struct hci_dev
>> *hdev)
>> ? ? ? ? /* The second byte is 0xff instead of 0x9f (two reserved bits
>> ? ? ? ? ?* disabled) since a Broadcom 1.2 dongle doesn't respond to
>> the
>> ? ? ? ? ?* command otherwise */
>> - ? ? ? u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00,
>> 0x00 };
>> + ? ? ? u8 events[8] = { 0xff, 0x9f, 0xfb, 0xff, 0x00, 0x00, 0x00,
>> + 0x00 };
>>
>> ? ? ? ? /* Events for 1.2 and newer controllers */
>> ? ? ? ? if (hdev->lmp_ver > 1) {
>
>> No luck here - same results.
>
> For what it's worth:
>
> With a (recent)CSR chipset, with 2.6.38 only Set Event Filter is used (with a 0 filter) and no Set Event Mask is sent at all. With Bluetooth-next, I get the following:
>
> < HCI Command: Set Event Mask (0x03|0x0001) plen 8
> ? ?Mask: 0xfffffbff07f8bf3d
>> HCI Event: Command Complete (0x0e) plen 4
> ? ?Set Event Mask (0x03|0x0001) ncmd 1
> ? ?status 0x00
>
> So Set Event Mask actually seems to go through without any problems.
>
> Carles
>
>My adapter is from 2002 so I'm guessing it either doesn't support Set Event Mask at all, or is very sensitive about the values it >receives.
Set Event Mask has been in the Bluetooth Spec since day 1, so it must be the bitmask, which has been extended with each new spec release to cover newly added events. Looking at the latest spec, and judging by the year your chipset was released in (it probably is a 1.1 compliant chipset) I believe that 0x000000008FFFFFFF is the highest event mask it would support (up until and including Page Scan Repetition Mode Change Event), but since I don't have the old 1.1 spec around I may be one or two bits off.
Carles
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Cufi, Carles
Sent: Wednesday, May 25, 2011 7:15 AM
To: [email protected]
Cc: Ed Tomlinson; Ville Tervo; Bluettooth Linux;
[email protected]
Subject: RE: Linux 2.6.39
(Snipping...)
On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <[email protected]>
wrote:
> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
...
>> > Read Local Version Information (0x04|0x0001) plen 0
>> > > HCI Event: Command Complete (0x0e) plen 12
>> > ? ? Read Local Version Information (0x04|0x0001) ncmd 1
>> > ? ? status 0x00
>> > ? ? HCI Version: 1.1 (0x1) HCI Revision: 0x20d
*************************
>> > ? ? LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
*************************
>> > ? ? Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
>> > Event Mask (0x03|0x0001) plen 8
>> > ? ? Mask: 0xfffffbff00000000
*************************
>> > > HCI Event: Command Complete (0x0e) plen 4
>> > ? ? Set Event Mask (0x03|0x0001) ncmd 1
>> > ? ? status 0x12
>> > ? ? Error: Invalid HCI Command Parameters
>
>Set Event Mask has been in the Bluetooth Spec since day 1, so it must be
the bitmask, which has been extended with each new spec release to cover
newly >added events. Looking at the latest spec, and judging by the year
your chipset was released in (it probably is a 1.1 compliant chipset) I
believe that >0x000000008FFFFFFF is the highest event mask it would support
(up until and including Page Scan Repetition Mode Change Event), but since I
don't have the >old 1.1 spec around I may be one or two bits off.
The device appears to have identified itself as CSR firmware using Bluetooth
version 1.1.
I do happen to have the 1.1 spec lying around :-), for Set_Event_Mask it
says
0x0000000100000000
To Reserved for future use
0x8000000000000000
0x00000000FFFFFFFF Default (All events enabled)
The mask above looks ok (no undefined bits), but are they supposed to be
displayed in that order? (IOW, are the bytes in correct order?)
--- tom
tom allebrandi
[email protected]
(Snipping...)
On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <[email protected]>
wrote:
> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
...
>> > Read Local Version Information (0x04|0x0001) plen 0
>> > > HCI Event: Command Complete (0x0e) plen 12
>> > ? ? Read Local Version Information (0x04|0x0001) ncmd 1
>> > ? ? status 0x00
>> > ? ? HCI Version: 1.1 (0x1) HCI Revision: 0x20d
*************************
>> > ? ? LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
*************************
>> > ? ? Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
>> > Event Mask (0x03|0x0001) plen 8
>> > ? ? Mask: 0xfffffbff00000000
*************************
>> > > HCI Event: Command Complete (0x0e) plen 4
>> > ? ? Set Event Mask (0x03|0x0001) ncmd 1
>> > ? ? status 0x12
>> > ? ? Error: Invalid HCI Command Parameters
>
>Set Event Mask has been in the Bluetooth Spec since day 1, so it must
>be
>the bitmask, which has been extended with each new spec release to cover newly >added events. Looking at the latest spec, and judging >by the year your chipset was released in (it probably is a 1.1 compliant chipset) I believe that >0x000000008FFFFFFF is the highest >event mask it would support (up until and including Page Scan Repetition Mode Change Event), but since I don't have the >old 1.1 spec >around I may be one or two bits off.
>The device appears to have identified itself as CSR firmware using Bluetooth version 1.1.
>I do happen to have the 1.1 spec lying around :-), for Set_Event_Mask it says
>0x0000000100000000
>To Reserved for future use
>0x8000000000000000
>0x00000000FFFFFFFF Default (All events enabled)
>The mask above looks ok (no undefined bits), but are they supposed to be displayed in that order? (IOW, are the bytes in correct >order?)
The HCI spec lists this as a 64-bit number but it must be sent in Little Endian to the controller, hence the reverse order in Ville Tervo's patch earlier in the email thread.
Carles
> >> > Read Local Version Information (0x04|0x0001) plen 0
> >> > > HCI Event: Command Complete (0x0e) plen 12
> >> > ? ? Read Local Version Information (0x04|0x0001) ncmd 1
> >> > ? ? HCI Version: 1.1 (0x1) HCI Revision: 0x20d
> >> > ? ? LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
> >> > ? ? Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
> >> > Event Mask (0x03|0x0001) plen 8
> >> > ? ? Mask: 0xfffffbff00000000
>
> The HCI spec lists this as a 64-bit number but it must be sent in Little
Endian to
> the controller, hence the reverse order in Ville Tervo's patch earlier in
the
> email thread.
That I knew. I was just checking that 64 bit values are displayed left to
right since other little endian values (0x020d, 0x0001 above) are displayed
right to left.
Cheers!
--- tom
tom allebrandi
[email protected]
Hi Ville, thank you for your help.
In 2.6.39 kernel command hciconfig hci0 up produces this output:
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Reset (0x03|0x0003) plen 0
> > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
> > HCI Event: Command Complete (0x0e) plen 12
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
> > HCI Event: Command Complete (0x0e) plen 12
< HCI Command: Read Buffer Size (0x04|0x0005) plen 0
> > HCI Event: Command Complete (0x0e) plen 11
< HCI Command: Read BD ADDR (0x04|0x0009) plen 0
> > HCI Event: Command Complete (0x0e) plen 10
< HCI Command: Read Class of Device (0x03|0x0023) plen 0
> > HCI Event: Command Complete (0x0e) plen 7
< HCI Command: Read Local Name (0x03|0x0014) plen 0
> > HCI Event: Command Complete (0x0e) plen 252
< HCI Command: Read Voice Setting (0x03|0x0025) plen 0
> > HCI Event: Command Complete (0x0e) plen 6
< HCI Command: Set Event Filter (0x03|0x0005) plen 1
> > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Connection Accept Timeout (0x03|0x0016) plen 2
> > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Delete Stored Link Key (0x03|0x0012) plen 7
> > HCI Event: Command Complete (0x0e) plen 6
< HCI Command: Set Event Mask (0x03|0x0001) plen 8
> > HCI Event: Command Complete (0x0e) plen 4
In 2.6.38.7 kernel command hciconfig hci0 up produces:
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Reset (0x03|0x0003) plen 0
> > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
> > HCI Event: Command Complete (0x0e) plen 12
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
> > HCI Event: Command Complete (0x0e) plen 12
< HCI Command: Read Buffer Size (0x04|0x0005) plen 0
> > HCI Event: Command Complete (0x0e) plen 11
< HCI Command: Read BD ADDR (0x04|0x0009) plen 0
> > HCI Event: Command Complete (0x0e) plen 10
< HCI Command: Read Class of Device (0x03|0x0023) plen 0
> > HCI Event: Command Complete (0x0e) plen 7
< HCI Command: Read Local Name (0x03|0x0014) plen 0
> > HCI Event: Command Complete (0x0e) plen 252
< HCI Command: Read Voice Setting (0x03|0x0025) plen 0
> > HCI Event: Command Complete (0x0e) plen 6
< HCI Command: Set Event Filter (0x03|0x0005) plen 1
> > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Page Timeout (0x03|0x0018) plen 2
> > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Connection Accept Timeout (0x03|0x0016) plen 2
> > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Page Timeout (0x03|0x0018) plen 2
> > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Read Stored Link Key (0x03|0x000d) plen 7
> > HCI Event: Command Complete (0x0e) plen 8
< HCI Command: Set Event Mask (0x03|0x0001) plen 8
> > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Default Link Policy Settings (0x02|0x000f) plen 2
> > HCI Event: Command Status (0x0f) plen 4
< HCI Command: Write Local Name (0x03|0x0013) plen 248
> > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Class of Device (0x03|0x0024) plen 3
> > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Scan Enable (0x03|0x001a) plen 1
> > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Read Local Name (0x03|0x0014) plen 0
> > HCI Event: Command Complete (0x0e) plen 252
< HCI Command: Read Scan Enable (0x03|0x0019) plen 0
> > HCI Event: Command Complete (0x0e) plen 5
Hope this helps.
Best regards,
Milan
On 05/25/2011 10:27 AM, Ville Tervo wrote:
> On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>> On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>>> On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
>>>> Hi Linus, I'm sorry bothering you, but my usb-bluetooth dongle stop working in
>>>> 2.6.39 kernel series.
>>>> I know it is nothing ground breaking but it is bug.
>>>> I'm using this hardware from 2.6.11 kernel series.
>>>> Details are included in this thread:
>>>>
>>>> https://lkml.org/lkml/2011/4/18/481
>>>>
>>>> I hope I'm doing nothing false writing this email.
>>>
>>> Same device, same problem here.
>>>
>>> You are not alone
>>
>> I had some time this afternood so I tried bisecting without much luck. I ended up somewhere rc1 ish with a system
>> that would paniced during boot. Here is the bisect log incase it helps:
>>
>> # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
>> # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38
>> git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
>> # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
>> git bisect bad 7a6362800cb7d1d618a697a650c7aaed3eb39320
>> # bad: [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
>> git bisect bad 0a0e9ae1bd788bc19adc4d4ae08c98b233697402
>> # skip: [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use usb_fill_int_urb()
>> git bisect skip 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69
>> # skip: [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci a child of the corresponding tty device.
>> git bisect skip 7f4b2b04c88377af30c022f36c060190182850fb
>> # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth: ath3k: Avoid duplication of code
>> git bisect skip 84f0e17f78471857104a20dfc57711409f68d7bf
>>
>> Ring any bells for anyone?
>>
>> Probably should open a regression bug for this too....
>
> I think this is regression with d5859e22cd40b73164b3e5d8d5d796f96edcc6af
> commit. Probably the code tries to enable something that is not supported.
>
> Could you pastebin hcidump while doing hciconfig hci0 up?
>
On Wed, May 25, 2011 at 12:31 PM, Tom Allebrandi <[email protected]> wrote:
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Cufi, Carles
> Sent: Wednesday, May 25, 2011 7:15 AM
> To: [email protected]
> Cc: Ed Tomlinson; Ville Tervo; Bluettooth Linux;
> [email protected]
> Subject: RE: Linux 2.6.39
>
> (Snipping...)
> On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <[email protected]>
> wrote:
>> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
>>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
>>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
>>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> ...
>>> > Read Local Version Information (0x04|0x0001) plen 0
>>> > > HCI Event: Command Complete (0x0e) plen 12
>>> > ? ? Read Local Version Information (0x04|0x0001) ncmd 1
>>> > ? ? status 0x00
>>> > ? ? HCI Version: 1.1 (0x1) HCI Revision: 0x20d
> *************************
>>> > ? ? LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
> *************************
>>> > ? ? Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
>>> > Event Mask (0x03|0x0001) plen 8
>>> > ? ? Mask: 0xfffffbff00000000
> *************************
>>> > > HCI Event: Command Complete (0x0e) plen 4
>>> > ? ? Set Event Mask (0x03|0x0001) ncmd 1
>>> > ? ? status 0x12
>>> > ? ? Error: Invalid HCI Command Parameters
>>
>>Set Event Mask has been in the Bluetooth Spec since day 1, so it must be
> the bitmask, which has been extended with each new spec release to cover
> newly >added events. Looking at the latest spec, and judging by the year
> your chipset was released in (it probably is a 1.1 compliant chipset) I
> believe that >0x000000008FFFFFFF is the highest event mask it would support
> (up until and including Page Scan Repetition Mode Change Event), but since I
> don't have the >old 1.1 spec around I may be one or two bits off.
>
> The device appears to have identified itself as CSR firmware using Bluetooth
> version 1.1.
>
> I do happen to have the 1.1 spec lying around :-), for Set_Event_Mask it
> says
>
> 0x0000000100000000
> To ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Reserved for future use
> 0x8000000000000000
>
> 0x00000000FFFFFFFF ? ? ?Default (All events enabled)
>
I am beginning to think that my adapter simply does not support this
command. I have tried with all the suggested bitmasks, all zeros, all
ones, all combinations where a single bit is set, etc. I'm not sure
where to go from here other than add a flag which incidates that
certain devices don't support this command so it can be skipped.
Again, the only way I have gotten it to work is by not sending the
command at all. Thoughts?
On Wed, May 25, 2011 at 09:11:19PM -0400, ext Corey Boyle wrote:
> On Wed, May 25, 2011 at 12:31 PM, Tom Allebrandi <[email protected]> wrote:
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of Cufi, Carles
> > Sent: Wednesday, May 25, 2011 7:15 AM
> > To: [email protected]
> > Cc: Ed Tomlinson; Ville Tervo; Bluettooth Linux;
> > [email protected]
> > Subject: RE: Linux 2.6.39
> >
> > (Snipping...)
> > On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <[email protected]>
> > wrote:
> >> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
> >>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
> >>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
> >>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
> >>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
> >>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> > ...
> >>> > Read Local Version Information (0x04|0x0001) plen 0
> >>> > > HCI Event: Command Complete (0x0e) plen 12
> >>> > ? ? Read Local Version Information (0x04|0x0001) ncmd 1
> >>> > ? ? status 0x00
> >>> > ? ? HCI Version: 1.1 (0x1) HCI Revision: 0x20d
> > *************************
> >>> > ? ? LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
> > *************************
> >>> > ? ? Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
> >>> > Event Mask (0x03|0x0001) plen 8
> >>> > ? ? Mask: 0xfffffbff00000000
> > *************************
> >>> > > HCI Event: Command Complete (0x0e) plen 4
> >>> > ? ? Set Event Mask (0x03|0x0001) ncmd 1
> >>> > ? ? status 0x12
> >>> > ? ? Error: Invalid HCI Command Parameters
> >>
> >>Set Event Mask has been in the Bluetooth Spec since day 1, so it must be
> > the bitmask, which has been extended with each new spec release to cover
> > newly >added events. Looking at the latest spec, and judging by the year
> > your chipset was released in (it probably is a 1.1 compliant chipset) I
> > believe that >0x000000008FFFFFFF is the highest event mask it would support
> > (up until and including Page Scan Repetition Mode Change Event), but since I
> > don't have the >old 1.1 spec around I may be one or two bits off.
> >
> > The device appears to have identified itself as CSR firmware using Bluetooth
> > version 1.1.
> >
> > I do happen to have the 1.1 spec lying around :-), for Set_Event_Mask it
> > says
> >
> > 0x0000000100000000
> > To ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Reserved for future use
> > 0x8000000000000000
> >
> > 0x00000000FFFFFFFF ? ? ?Default (All events enabled)
> >
>
> I am beginning to think that my adapter simply does not support this
> command. I have tried with all the suggested bitmasks, all zeros, all
> ones, all combinations where a single bit is set, etc. I'm not sure
> where to go from here other than add a flag which incidates that
> certain devices don't support this command so it can be skipped.
> Again, the only way I have gotten it to work is by not sending the
> command at all. Thoughts?
I also played a bit with 1.1 CSR dongle and couldn't find any mask that would
be accepted. I think this command can be left out for older than 1.2 devices.
Following patch should do it. Could you verify it. I don't have access to old
hw ATM.
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 19cd4af..86d1e26 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -477,14 +477,16 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
* command otherwise */
u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
- /* Events for 1.2 and newer controllers */
- if (hdev->lmp_ver > 1) {
- events[4] |= 0x01; /* Flow Specification Complete */
- events[4] |= 0x02; /* Inquiry Result with RSSI */
- events[4] |= 0x04; /* Read Remote Extended Features Complete */
- events[5] |= 0x08; /* Synchronous Connection Complete */
- events[5] |= 0x10; /* Synchronous Connection Changed */
- }
+ /* CSR 1.1 dongles does not accept any bitfield so don't try to set
+ * any event mask for pre 1.2 devices */
+ if (hdev->lmp_ver <= 1)
+ return;
+
+ events[4] |= 0x01; /* Flow Specification Complete */
+ events[4] |= 0x02; /* Inquiry Result with RSSI */
+ events[4] |= 0x04; /* Read Remote Extended Features Complete */
+ events[5] |= 0x08; /* Synchronous Connection Complete */
+ events[5] |= 0x10; /* Synchronous Connection Changed */
if (hdev->features[3] & LMP_RSSI_INQ)
events[4] |= 0x04; /* Inquiry Result with RSSI */
--
On Thu, May 26, 2011 at 4:37 AM, Ville Tervo <[email protected]> wrote:
> On Wed, May 25, 2011 at 09:11:19PM -0400, ext Corey Boyle wrote:
>> On Wed, May 25, 2011 at 12:31 PM, Tom Allebrandi <[email protected]> wrote:
>> > -----Original Message-----
>> > From: [email protected]
>> > [mailto:[email protected]] On Behalf Of Cufi, Carles
>> > Sent: Wednesday, May 25, 2011 7:15 AM
>> > To: [email protected]
>> > Cc: Ed Tomlinson; Ville Tervo; Bluettooth Linux;
>> > [email protected]
>> > Subject: RE: Linux 2.6.39
>> >
>> > (Snipping...)
>> > On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <[email protected]>
>> > wrote:
>> >> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
>> >>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
>> >>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
>> >>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>> >>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>> >>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
>> > ...
>> >>> > Read Local Version Information (0x04|0x0001) plen 0
>> >>> > > HCI Event: Command Complete (0x0e) plen 12
>> >>> > ? ? Read Local Version Information (0x04|0x0001) ncmd 1
>> >>> > ? ? status 0x00
>> >>> > ? ? HCI Version: 1.1 (0x1) HCI Revision: 0x20d
>> > *************************
>> >>> > ? ? LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
>> > *************************
>> >>> > ? ? Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
>> >>> > Event Mask (0x03|0x0001) plen 8
>> >>> > ? ? Mask: 0xfffffbff00000000
>> > *************************
>> >>> > > HCI Event: Command Complete (0x0e) plen 4
>> >>> > ? ? Set Event Mask (0x03|0x0001) ncmd 1
>> >>> > ? ? status 0x12
>> >>> > ? ? Error: Invalid HCI Command Parameters
>> >>
>> >>Set Event Mask has been in the Bluetooth Spec since day 1, so it must be
>> > the bitmask, which has been extended with each new spec release to cover
>> > newly >added events. Looking at the latest spec, and judging by the year
>> > your chipset was released in (it probably is a 1.1 compliant chipset) I
>> > believe that >0x000000008FFFFFFF is the highest event mask it would support
>> > (up until and including Page Scan Repetition Mode Change Event), but since I
>> > don't have the >old 1.1 spec around I may be one or two bits off.
>> >
>> > The device appears to have identified itself as CSR firmware using Bluetooth
>> > version 1.1.
>> >
>> > I do happen to have the 1.1 spec lying around :-), for Set_Event_Mask it
>> > says
>> >
>> > 0x0000000100000000
>> > To ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Reserved for future use
>> > 0x8000000000000000
>> >
>> > 0x00000000FFFFFFFF ? ? ?Default (All events enabled)
>> >
>>
>> I am beginning to think that my adapter simply does not support this
>> command. ?I have tried with all the suggested bitmasks, all zeros, all
>> ones, all combinations where a single bit is set, etc. ?I'm not sure
>> where to go from here other than add a flag which incidates that
>> certain devices don't support this command so it can be skipped.
>> Again, the only way I have gotten it to work is by not sending the
>> command at all. ?Thoughts?
>
> I also played a bit with 1.1 CSR dongle and couldn't find any mask that would
> be accepted. I think this command can be left out for older than 1.2 devices.
>
> Following patch should do it. Could you verify it. I don't have access to old
> hw ATM.
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 19cd4af..86d1e26 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -477,14 +477,16 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
> ? ? ? ? * command otherwise */
> ? ? ? ?u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
>
> - ? ? ? /* Events for 1.2 and newer controllers */
> - ? ? ? if (hdev->lmp_ver > 1) {
> - ? ? ? ? ? ? ? events[4] |= 0x01; /* Flow Specification Complete */
> - ? ? ? ? ? ? ? events[4] |= 0x02; /* Inquiry Result with RSSI */
> - ? ? ? ? ? ? ? events[4] |= 0x04; /* Read Remote Extended Features Complete */
> - ? ? ? ? ? ? ? events[5] |= 0x08; /* Synchronous Connection Complete */
> - ? ? ? ? ? ? ? events[5] |= 0x10; /* Synchronous Connection Changed */
> - ? ? ? }
> + ? ? ? /* CSR 1.1 dongles does not accept any bitfield so don't try to set
> + ? ? ? ?* any event mask for pre 1.2 devices */
> + ? ? ? if (hdev->lmp_ver <= 1)
> + ? ? ? ? ? ? ? return;
> +
> + ? ? ? events[4] |= 0x01; /* Flow Specification Complete */
> + ? ? ? events[4] |= 0x02; /* Inquiry Result with RSSI */
> + ? ? ? events[4] |= 0x04; /* Read Remote Extended Features Complete */
> + ? ? ? events[5] |= 0x08; /* Synchronous Connection Complete */
> + ? ? ? events[5] |= 0x10; /* Synchronous Connection Changed */
>
> ? ? ? ?if (hdev->features[3] & LMP_RSSI_INQ)
> ? ? ? ? ? ? ? ?events[4] |= 0x04; /* Inquiry Result with RSSI */
> --
>
>
Patch works great - typing this email from my bluetooth keyboard.
On Thursday 26 May 2011 06:17:20 Corey Boyle wrote:
> On Thu, May 26, 2011 at 4:37 AM, Ville Tervo <[email protected]> wrote:
> > On Wed, May 25, 2011 at 09:11:19PM -0400, ext Corey Boyle wrote:
> >> On Wed, May 25, 2011 at 12:31 PM, Tom Allebrandi <[email protected]> wrote:
> >> > -----Original Message-----
> >> > From: [email protected]
> >> > [mailto:[email protected]] On Behalf Of Cufi, Carles
> >> > Sent: Wednesday, May 25, 2011 7:15 AM
> >> > To: [email protected]
> >> > Cc: Ed Tomlinson; Ville Tervo; Bluettooth Linux;
> >> > [email protected]
> >> > Subject: RE: Linux 2.6.39
> >> >
> >> > (Snipping...)
> >> > On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <[email protected]>
> >> > wrote:
> >> >> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
> >> >>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
> >> >>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
> >> >>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
> >> >>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
> >> >>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> >> > ...
> >> >>> > Read Local Version Information (0x04|0x0001) plen 0
> >> >>> > > HCI Event: Command Complete (0x0e) plen 12
> >> >>> > Read Local Version Information (0x04|0x0001) ncmd 1
> >> >>> > status 0x00
> >> >>> > HCI Version: 1.1 (0x1) HCI Revision: 0x20d
> >> > *************************
> >> >>> > LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
> >> > *************************
> >> >>> > Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
> >> >>> > Event Mask (0x03|0x0001) plen 8
> >> >>> > Mask: 0xfffffbff00000000
> >> > *************************
> >> >>> > > HCI Event: Command Complete (0x0e) plen 4
> >> >>> > Set Event Mask (0x03|0x0001) ncmd 1
> >> >>> > status 0x12
> >> >>> > Error: Invalid HCI Command Parameters
> >> >>
> >> >>Set Event Mask has been in the Bluetooth Spec since day 1, so it must be
> >> > the bitmask, which has been extended with each new spec release to cover
> >> > newly >added events. Looking at the latest spec, and judging by the year
> >> > your chipset was released in (it probably is a 1.1 compliant chipset) I
> >> > believe that >0x000000008FFFFFFF is the highest event mask it would support
> >> > (up until and including Page Scan Repetition Mode Change Event), but since I
> >> > don't have the >old 1.1 spec around I may be one or two bits off.
> >> >
> >> > The device appears to have identified itself as CSR firmware using Bluetooth
> >> > version 1.1.
> >> >
> >> > I do happen to have the 1.1 spec lying around :-), for Set_Event_Mask it
> >> > says
> >> >
> >> > 0x0000000100000000
> >> > To Reserved for future use
> >> > 0x8000000000000000
> >> >
> >> > 0x00000000FFFFFFFF Default (All events enabled)
> >> >
> >>
> >> I am beginning to think that my adapter simply does not support this
> >> command. I have tried with all the suggested bitmasks, all zeros, all
> >> ones, all combinations where a single bit is set, etc. I'm not sure
> >> where to go from here other than add a flag which incidates that
> >> certain devices don't support this command so it can be skipped.
> >> Again, the only way I have gotten it to work is by not sending the
> >> command at all. Thoughts?
> >
> > I also played a bit with 1.1 CSR dongle and couldn't find any mask that would
> > be accepted. I think this command can be left out for older than 1.2 devices.
> >
> > Following patch should do it. Could you verify it. I don't have access to old
> > hw ATM.
> >
> > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> > index 19cd4af..86d1e26 100644
> > --- a/net/bluetooth/hci_event.c
> > +++ b/net/bluetooth/hci_event.c
> > @@ -477,14 +477,16 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
> > * command otherwise */
> > u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
> >
> > - /* Events for 1.2 and newer controllers */
> > - if (hdev->lmp_ver > 1) {
> > - events[4] |= 0x01; /* Flow Specification Complete */
> > - events[4] |= 0x02; /* Inquiry Result with RSSI */
> > - events[4] |= 0x04; /* Read Remote Extended Features Complete */
> > - events[5] |= 0x08; /* Synchronous Connection Complete */
> > - events[5] |= 0x10; /* Synchronous Connection Changed */
> > - }
> > + /* CSR 1.1 dongles does not accept any bitfield so don't try to set
> > + * any event mask for pre 1.2 devices */
> > + if (hdev->lmp_ver <= 1)
> > + return;
> > +
> > + events[4] |= 0x01; /* Flow Specification Complete */
> > + events[4] |= 0x02; /* Inquiry Result with RSSI */
> > + events[4] |= 0x04; /* Read Remote Extended Features Complete */
> > + events[5] |= 0x08; /* Synchronous Connection Complete */
> > + events[5] |= 0x10; /* Synchronous Connection Changed */
> >
> > if (hdev->features[3] & LMP_RSSI_INQ)
> > events[4] |= 0x04; /* Inquiry Result with RSSI */
> > --
> >
> >
>
> Patch works great - typing this email from my bluetooth keyboard.
Works here too.
Thanks
Ed
* Ed Tomlinson <[email protected]> [2011-05-26 06:47:55 -0400]:
> On Thursday 26 May 2011 06:17:20 Corey Boyle wrote:
> > On Thu, May 26, 2011 at 4:37 AM, Ville Tervo <[email protected]> wrote:
> > > On Wed, May 25, 2011 at 09:11:19PM -0400, ext Corey Boyle wrote:
> > >> On Wed, May 25, 2011 at 12:31 PM, Tom Allebrandi <[email protected]> wrote:
> > >> > -----Original Message-----
> > >> > From: [email protected]
> > >> > [mailto:[email protected]] On Behalf Of Cufi, Carles
> > >> > Sent: Wednesday, May 25, 2011 7:15 AM
> > >> > To: [email protected]
> > >> > Cc: Ed Tomlinson; Ville Tervo; Bluettooth Linux;
> > >> > [email protected]
> > >> > Subject: RE: Linux 2.6.39
> > >> >
> > >> > (Snipping...)
> > >> > On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <[email protected]>
> > >> > wrote:
> > >> >> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
> > >> >>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
> > >> >>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
> > >> >>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
> > >> >>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
> > >> >>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> > >> > ...
> > >> >>> > Read Local Version Information (0x04|0x0001) plen 0
> > >> >>> > > HCI Event: Command Complete (0x0e) plen 12
> > >> >>> > Read Local Version Information (0x04|0x0001) ncmd 1
> > >> >>> > status 0x00
> > >> >>> > HCI Version: 1.1 (0x1) HCI Revision: 0x20d
> > >> > *************************
> > >> >>> > LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
> > >> > *************************
> > >> >>> > Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
> > >> >>> > Event Mask (0x03|0x0001) plen 8
> > >> >>> > Mask: 0xfffffbff00000000
> > >> > *************************
> > >> >>> > > HCI Event: Command Complete (0x0e) plen 4
> > >> >>> > Set Event Mask (0x03|0x0001) ncmd 1
> > >> >>> > status 0x12
> > >> >>> > Error: Invalid HCI Command Parameters
> > >> >>
> > >> >>Set Event Mask has been in the Bluetooth Spec since day 1, so it must be
> > >> > the bitmask, which has been extended with each new spec release to cover
> > >> > newly >added events. Looking at the latest spec, and judging by the year
> > >> > your chipset was released in (it probably is a 1.1 compliant chipset) I
> > >> > believe that >0x000000008FFFFFFF is the highest event mask it would support
> > >> > (up until and including Page Scan Repetition Mode Change Event), but since I
> > >> > don't have the >old 1.1 spec around I may be one or two bits off.
> > >> >
> > >> > The device appears to have identified itself as CSR firmware using Bluetooth
> > >> > version 1.1.
> > >> >
> > >> > I do happen to have the 1.1 spec lying around :-), for Set_Event_Mask it
> > >> > says
> > >> >
> > >> > 0x0000000100000000
> > >> > To Reserved for future use
> > >> > 0x8000000000000000
> > >> >
> > >> > 0x00000000FFFFFFFF Default (All events enabled)
> > >> >
> > >>
> > >> I am beginning to think that my adapter simply does not support this
> > >> command. I have tried with all the suggested bitmasks, all zeros, all
> > >> ones, all combinations where a single bit is set, etc. I'm not sure
> > >> where to go from here other than add a flag which incidates that
> > >> certain devices don't support this command so it can be skipped.
> > >> Again, the only way I have gotten it to work is by not sending the
> > >> command at all. Thoughts?
> > >
> > > I also played a bit with 1.1 CSR dongle and couldn't find any mask that would
> > > be accepted. I think this command can be left out for older than 1.2 devices.
> > >
> > > Following patch should do it. Could you verify it. I don't have access to old
> > > hw ATM.
> > >
> > > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> > > index 19cd4af..86d1e26 100644
> > > --- a/net/bluetooth/hci_event.c
> > > +++ b/net/bluetooth/hci_event.c
> > > @@ -477,14 +477,16 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
> > > * command otherwise */
> > > u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
> > >
> > > - /* Events for 1.2 and newer controllers */
> > > - if (hdev->lmp_ver > 1) {
> > > - events[4] |= 0x01; /* Flow Specification Complete */
> > > - events[4] |= 0x02; /* Inquiry Result with RSSI */
> > > - events[4] |= 0x04; /* Read Remote Extended Features Complete */
> > > - events[5] |= 0x08; /* Synchronous Connection Complete */
> > > - events[5] |= 0x10; /* Synchronous Connection Changed */
> > > - }
> > > + /* CSR 1.1 dongles does not accept any bitfield so don't try to set
> > > + * any event mask for pre 1.2 devices */
> > > + if (hdev->lmp_ver <= 1)
> > > + return;
> > > +
> > > + events[4] |= 0x01; /* Flow Specification Complete */
> > > + events[4] |= 0x02; /* Inquiry Result with RSSI */
> > > + events[4] |= 0x04; /* Read Remote Extended Features Complete */
> > > + events[5] |= 0x08; /* Synchronous Connection Complete */
> > > + events[5] |= 0x10; /* Synchronous Connection Changed */
> > >
> > > if (hdev->features[3] & LMP_RSSI_INQ)
> > > events[4] |= 0x04; /* Inquiry Result with RSSI */
> > > --
> > >
> > >
> >
> > Patch works great - typing this email from my bluetooth keyboard.
>
> Works here too.
Great, I'll consider both comments as a Tested-by thing and add it to the
commit.
--
Gustavo F. Padovan
http://profusion.mobi
Hi Ville, than you for your patch. BT dongle works now again in 3.0-rc4
kernel.
Best wishes,
Milan
On 05/25/2011 10:27 AM, Ville Tervo wrote:
> On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>> On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>>> On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
>>>> Hi Linus, I'm sorry bothering you, but my usb-bluetooth dongle stop working in
>>>> 2.6.39 kernel series.
>>>> I know it is nothing ground breaking but it is bug.
>>>> I'm using this hardware from 2.6.11 kernel series.
>>>> Details are included in this thread:
>>>>
>>>> https://lkml.org/lkml/2011/4/18/481
>>>>
>>>> I hope I'm doing nothing false writing this email.
>>>
>>> Same device, same problem here.
>>>
>>> You are not alone
>>
>> I had some time this afternood so I tried bisecting without much luck. I ended up somewhere rc1 ish with a system
>> that would paniced during boot. Here is the bisect log incase it helps:
>>
>> # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
>> # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38
>> git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
>> # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
>> git bisect bad 7a6362800cb7d1d618a697a650c7aaed3eb39320
>> # bad: [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
>> git bisect bad 0a0e9ae1bd788bc19adc4d4ae08c98b233697402
>> # skip: [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use usb_fill_int_urb()
>> git bisect skip 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69
>> # skip: [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci a child of the corresponding tty device.
>> git bisect skip 7f4b2b04c88377af30c022f36c060190182850fb
>> # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth: ath3k: Avoid duplication of code
>> git bisect skip 84f0e17f78471857104a20dfc57711409f68d7bf
>>
>> Ring any bells for anyone?
>>
>> Probably should open a regression bug for this too....
>
> I think this is regression with d5859e22cd40b73164b3e5d8d5d796f96edcc6af
> commit. Probably the code tries to enable something that is not supported.
>
> Could you pastebin hcidump while doing hciconfig hci0 up?
>