[git pull] Input update for 2.6.17

[git pull] Input update for 2.6.17

[Dmitry Torokhov]

Linus,

Please pull from:

        git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git

or
        master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git

It fixes broken hardware autorepeat in atkbd, adds a new key mapping
to wistron driver and fixes buffer overrun in db9.

Diffstat:

 joystick/db9.c      |    2 +-
 keyboard/atkbd.c    |    2 +-
 misc/wistron_btns.c |   19 +++++++++++++++++++
 3 files changed, 21 insertions(+), 2 deletions(-)

Changelog:

Dmitry Torokhov:
      Input: atkbd - fix hardware autorepeat

Eric Sesterhenn:
      Input: db9 - fix potential buffer overrun

Frank de Lange:
      Input: wistron - add mapping for Wistron MS 2111

-- 
Dmitry

[git pull] Input update for 2.6.17

[Dmitry Torokhov]

Linus,

Please pull from:

        git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git

or
        master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git

It contains support for Intellimouse 4.0 in psmouse driver, improved
support for korean keyboards; sprintf changed into snprintf to make
sure we don't stop on data adjacent to buffer and some other changes.

Diffstat:

 MAINTAINERS                                 |    3 
 drivers/char/keyboard.c                     |   16 +-
 drivers/input/evdev.c                       |   10 +
 drivers/input/input.c                       |   85 +++++++---
 drivers/input/joydev.c                      |   69 +++++---
 drivers/input/joystick/a3d.c                |    2 
 drivers/input/joystick/analog.c             |   23 +-
 drivers/input/joystick/cobra.c              |    3 
 drivers/input/joystick/db9.c                |    3 
 drivers/input/joystick/gamecon.c            |    3 
 drivers/input/joystick/gf2k.c               |    2 
 drivers/input/joystick/grip.c               |    3 
 drivers/input/joystick/guillemot.c          |    2 
 drivers/input/joystick/iforce/iforce-ff.c   |    8 -
 drivers/input/joystick/iforce/iforce-main.c |    6 
 drivers/input/joystick/interact.c           |    2 
 drivers/input/joystick/magellan.c           |    2 
 drivers/input/joystick/sidewinder.c         |   15 +
 drivers/input/joystick/spaceball.c          |    2 
 drivers/input/joystick/spaceorb.c           |    2 
 drivers/input/joystick/stinger.c            |    2 
 drivers/input/joystick/twidjoy.c            |    2 
 drivers/input/joystick/warrior.c            |    2 
 drivers/input/keyboard/atkbd.c              |  219 +++++++++++++++++-----------
 drivers/input/keyboard/lkkbd.c              |    9 -
 drivers/input/keyboard/newtonkbd.c          |    2 
 drivers/input/keyboard/sunkbd.c             |    2 
 drivers/input/keyboard/xtkbd.c              |    2 
 drivers/input/mouse/alps.c                  |    2 
 drivers/input/mouse/psmouse-base.c          |   39 ++++
 drivers/input/mouse/sermouse.c              |    2 
 drivers/input/mouse/vsxxxaa.c               |   22 +-
 drivers/input/mousedev.c                    |   42 +++--
 drivers/input/touchscreen/gunze.c           |    2 
 drivers/input/touchscreen/h3600_ts_input.c  |    2 
 drivers/input/touchscreen/mtouch.c          |    2 
 drivers/input/tsdev.c                       |   22 +-
 drivers/macintosh/Makefile                  |    2 
 drivers/macintosh/adbhid.c                  |    2 
 drivers/macintosh/via-pmu-event.c           |   80 ++++++++++
 drivers/macintosh/via-pmu-event.h           |    8 +
 drivers/macintosh/via-pmu.c                 |    8 +
 drivers/usb/input/fixp-arith.h              |   15 -
 drivers/usb/input/hid-debug.h               |    2 
 include/linux/input.h                       |   10 -
 45 files changed, 515 insertions(+), 248 deletions(-)

Changelog:

Andreas Mohr:
      Input: constify drivers/char/keyboard.c

Anssi Hannula:
      Input: iforce - use ENOSPC instead of ENOMEM
      Input: fix accuracy of fixp-arith.h

Dmitry Torokhov:
      Input: fix potential overflows in driver/input/mouse
      Input: fix potential overflows in driver/input/joystick
      Input: fix potential overflows in driver/input/touchscreen
      Input: fix potential overflows in driver/input/keyboard
      Input: change my e-mail address in MAINTAINERS file
      Input: reset name, phys and uniq when unregistering
      Input: fix formatting to better follow CodingStyle
      Input: rearrange exports
      Input: atkbd - fix HANGEUL/HANJA keys

Jerome Pinot:
      Input: fix misspelling of Hangeul key

Jesper Juhl:
      Input: iforce - remove some pointless casts

Johannes Berg:
      Input: via-pmu - add input device support

Pozsar Balazs:
      Input: psmouse - add support for Intellimouse 4.0

Richard Purdie:
      Input: return correct size when reading modalias attribute

-- 
Dmitry

Re: [git pull] Input update for 2.6.17

[Linus Torvalds]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3407 bytes --]



On Mon, 26 Jun 2006, Dmitry Torokhov wrote:
> 
> Please pull from:
> 
>         git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git

I think this (or USB) may have problems.

I get a spinlock debugging fault with the current kernel on one of my 
machines at bootup, with the trace-back being:

  Process: khubd
	spin_bug
	_raw_spin_lock
	_spin_lock
	__mutex_lock_slowpath
	mutex_lock
	input_unregister_device
	hidinput_disconnect
	hid_disconnect
	usb_unbind_interface
	__device_release
	device_release_driver
	bus_remove_device
	device_del
	usb_disable_device
	usb_disconnect
	hub_thread
	kthread

it happens pretty early after bootup, but I don't know what triggers that 
usb disconnect (it may be the hand-over from UHCI->EHCI. Greg? Does that 
make sense?)

Does this ring a bell?

The fact that it triggers with spinlock debugging, and there's a bad magic 
number. It seems to be the "mutex_lock(&dev->mutex);" thing in 
input_unregister_device that triggers this. It seems to be a device that 
has been free'd already, because that 0x6b6b6b6b pattern in the 
POISON_FREE pattern.

Greg? Dmitry?

To trigger, you probably need both slab debugging _and_ spinlock debugging 
on. And perhaps just the right timings, although I've been able to do it 
three times in a row now, so it doesn't seem to be _that_ timing 
sensitive.

			Linus

---
BUG: spinlock bad magic on CPU#0, khubd/131
BUG: unable to handle kernel paging request at virtual address 6b6b6c0b
 printing eip:
c01dcf77
*pde = 00000000
Oops: 0000 [#1]
SMP 
Modules linked in: bluetooth ip_conntrack_netbios_ns ipt_REJECT iptable_filter ip_tables ip6table_filter ip6_tables cpufreq_ondemand asus_acpi lp intel_agp agpgart pcspkr
CPU:    0
EIP:    0060:[<c01dcf77>]    Not tainted VLI
EFLAGS: 00010002   (2.6.17-g2ac9f277 #17) 
EIP is at spin_bug+0x5c/0xc0
eax: ffffffff   ebx: 6b6b6b6b   ecx: 6b6b6b6b   edx: c03c7674
esi: dd9c18bc   edi: dd9c18bc   ebp: de04de18   esp: de04de10
ds: 007b   es: 007b   ss: 0068
Process khubd (pid: 131, ti=de04d000 task=de04e560 task.ti=de04d000)
Stack: de04d000 dd9c18b8 de04de30 c01dd1e3 00000001 de04d000 dd9c18b8 00000246 
       de04de38 c039ddeb de04de68 c039d3c1 c02c0e9a de04e560 de04de48 de04de48 
       11111111 11111111 de04de48 dd9c18b8 dd9c1998 dd9c1284 de04de74 c039d6e2 
Call Trace:
 <c0103c3b> show_stack_log_lvl+0x8a/0x95  <c0103dc6> show_registers+0x144/0x1b9
 <c0103fb0> die+0x175/0x285  <c011992e> do_page_fault+0x3f1/0x4eb
 <c0103759> error_code+0x39/0x40  <c01dd1e3> _raw_spin_lock+0x1e/0xe3
 <c039ddeb> _spin_lock+0x8/0xa  <c039d3c1> __mutex_lock_slowpath+0xaa/0x3a7
 <c039d6e2> mutex_lock+0x24/0x27  <c02c0e9a> input_unregister_device+0xc3/0x104
 <c02b957d> hidinput_disconnect+0x31/0x4b  <c02b6405> hid_disconnect+0x75/0xc3
 <c02a722b> usb_unbind_interface+0x37/0x6e  <c023fdeb> __device_release_driver+0x63/0x79
 <c024003d> device_release_driver+0x2e/0x3e  <c023f734> bus_remove_device+0x7e/0x8e
 <c023e6c6> device_del+0x115/0x149  <c02a59f7> usb_disable_device+0x71/0xcf
 <c02a25cd> usb_disconnect+0x8b/0xe7  <c02a3161> hub_thread+0x34d/0x992
 <c0132185> kthread+0xa5/0xd2  <c0101005> kernel_thread_helper+0x5/0xb
Code: 00 00 8b 10 81 c2 90 01 00 00 52 ff 70 10 51 68 a0 31 3d c0 e8 fa 49 f4 ff 83 c8 ff 8b 4e 08 ba 74 76 3c c0 83 c4 14 85 db 74 0c <8b> 83 a0 00 00 00 8d 93 90 01 00 00 51 50 52 ff 76 04 56 68 c6 
EIP: [<c01dcf77>] spin_bug+0x5c/0xc0 SS:ESP 0068:de04de10

Re: [git pull] Input update for 2.6.17

[Greg KH]

On Mon, Jun 26, 2006 at 11:13:19PM -0700, Linus Torvalds wrote:
> 
> 
> On Mon, 26 Jun 2006, Dmitry Torokhov wrote:
> > 
> > Please pull from:
> > 
> > ????????git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
> 
> I think this (or USB) may have problems.
> 
> I get a spinlock debugging fault with the current kernel on one of my 
> machines at bootup, with the trace-back being:
> 
>   Process: khubd
> 	spin_bug
> 	_raw_spin_lock
> 	_spin_lock
> 	__mutex_lock_slowpath
> 	mutex_lock
> 	input_unregister_device
> 	hidinput_disconnect
> 	hid_disconnect
> 	usb_unbind_interface
> 	__device_release
> 	device_release_driver
> 	bus_remove_device
> 	device_del
> 	usb_disable_device
> 	usb_disconnect
> 	hub_thread
> 	kthread
> 
> it happens pretty early after bootup, but I don't know what triggers that 
> usb disconnect (it may be the hand-over from UHCI->EHCI. Greg? Does that 
> make sense?)

Yes, if you have the UHCI driver loaded first, then when EHCI is loaded,
it disconnects everything on the bus and re-enumerates it.

But EHCI is built into the kernel first, before UHCI, so unless you are
using modules, nothing should be getting disconnected at boot time.

I really doubt you are using modules, so I don't know why it would be
disconnected.  What does the kernel log show right before this happened?
Any chance to enable CONFIG_USB_DEBUG?

thanks,

greg k-h

Re: [git pull] Input update for 2.6.17

[Linus Torvalds]

On Mon, 26 Jun 2006, Greg KH wrote:
> 
> Yes, if you have the UHCI driver loaded first, then when EHCI is loaded,
> it disconnects everything on the bus and re-enumerates it.
> 
> But EHCI is built into the kernel first, before UHCI, so unless you are
> using modules, nothing should be getting disconnected at boot time.

Yeah, that's not it.

It _seems_ to be triggered by this:

	Bluetooth: HCI device and connection manager initialized
	Bluetooth: HCI socket layer initialized
	usb 5-1: USB disconnect, address 2
	usb 5-1: new full speed USB device using uhci_hcd and address 4
	usb 5-1: configuration #1 chosen from 1 choice
	Bluetooth: HCI USB driver ver 2.9
	usbcore: registered new driver hci_usb

> I really doubt you are using modules, so I don't know why it would be
> disconnected.

I'm actually using modules for the "don't care" things, like bluetooth. 
But yeah, UHCI/EHCI are compiled-in.

> What does the kernel log show right before this happened?
> Any chance to enable CONFIG_USB_DEBUG?

Will try.

Sadly, grub is buggered on this machine (it's the mac mini) and I can't 
switch kernels around easily, so when a kernel fails to boot, I have to go 
into the rescue-CD thing etc. That makes it a bit painful.

But I've got netconsole to capture the logs, at least ;)

		Linus

Re: [git pull] Input update for 2.6.17

[Linus Torvalds]

On Tue, 27 Jun 2006, Linus Torvalds wrote:
> 
> > What does the kernel log show right before this happened?
> > Any chance to enable CONFIG_USB_DEBUG?
> 
> Will try.

There were _no_ kernel messages just before the oops. Not even with USB 
debugging turned on. Of course, they may have been marked "informational", 
and not shown on the console. Every distribution seems to think that debug 
messages are more annoying than useful, so they tend to set the console 
debug level down (even if you boot with "debug" to turn it on!). Gaah!

		Linus

Re: [git pull] Input update for 2.6.17

[Linus Torvalds]

On Tue, 27 Jun 2006, Linus Torvalds wrote:
> 
> There were _no_ kernel messages just before the oops. Not even with USB 
> debugging turned on. Of course, they may have been marked "informational", 
> and not shown on the console. Every distribution seems to think that debug 
> messages are more annoying than useful, so they tend to set the console 
> debug level down (even if you boot with "debug" to turn it on!). Gaah!

Ok, with that fixed, I get

	hub 4-1:1.0: 300mA power budget left
	hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0000
	hub 4-1:1.0: state 7 ports 3 chg 0000 evt 0008
	usbcore: registered new driver libusual
	usbcore: registered new driver hiddev
	usbhid 5-1:1.0: usb_probe_interface
	usbhid 5-1:1.0: usb_probe_interface - got id
	input: HID 05ac:1000 as /class/input/input0
	input: USB HID v1.11 Keyboard [HID 05ac:1000] on usb-0000:00:1d.3-1
	usbhid 5-1:1.1: usb_probe_interface
	usbhid 5-1:1.1: usb_probe_interface - got id
	input: HID 05ac:1000 as /class/input/input1
	input: USB HID v1.11 Mouse [HID 05ac:1000] on usb-0000:00:1d.3-1
	usbhid 5-2:1.0: usb_probe_interface
	usbhid 5-2:1.0: usb_probe_interface - got id
	drivers/usb/core/file.c: looking for a minor, starting at 96
	PM: Adding info for No Bus:hiddev0
	hiddev96: USB HID v1.11 Device [Apple Computer, Inc. IR Receiver] on usb-0000:00:1d.3-2
	usbhid 1-6.3:1.0: usb_probe_interface
	usbhid 1-6.3:1.0: usb_probe_interface - got id
	drivers/usb/core/file.c: looking for a minor, starting at 96
	PM: Adding info for No Bus:hiddev1
	hiddev97: USB HID v1.11 Device [Apple Cinema Display] on usb-0000:00:1d.7-6.3
	usbhid 4-1.1:1.0: usb_probe_interface
	usbhid 4-1.1:1.0: usb_probe_interface - got id
	input: Mitsumi Electric Apple Optical USB Mouse as /class/input/input2
	input: USB HID v1.10 Mouse [Mitsumi Electric Apple Optical USB Mouse] on usb-0000:00:1d.2-1.1
	usbhid 4-1.3:1.0: usb_probe_interface
	usbhid 4-1.3:1.0: usb_probe_interface - got id
	input: Mitsumi Electric Apple Extended USB Keyboard as /class/input/input3
	input: USB HID v1.10 Keyboard [Mitsumi Electric Apple Extended USB 
	Keyboard] on usb-0000:00:1d.2-1.3
	usbhid 4-1.3:1.1: usb_probe_interface
	usbhid 4-1.3:1.1: usb_probe_interface - got id
	input: Mitsumi Electric Apple Extended USB Keyboard as /class/input/input4
	input: USB HID v1.10 Device [Mitsumi Electric Apple Extended USB Keyboard] on usb-0000:00:1d.2-1.3
	usbcore: registered new driver usbhid
	drivers/usb/input/hid-core.c: v2.6:USB HID core driver
	PNP: No PS/2 controller found. Probing ports directly.
	PM: Adding info for platform:i8042
	i8042.c: No controller found.
	mice: PS/2 mouse device common for all mice
	i2c /dev entries driver

	... snip snip, mounting root filesystem etc - time passes ..

	usb 5-1: uhci_result_common: failed with status 440000
	usb 5-1: usbfs: USBDEVFS_CONTROL failed cmd hid2hci rqt 64 rq 0 len 0 ret -84
	usb 5-1: uhci_result_common: failed with status 440000
	usbhid 5-1:1.0: retrying intr urb
	usb 5-1: uhci_result_common: failed with status 440000
	hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0002
	uhci_hcd 0000:00:1d.3: port 1 portsc 008a,00
	hub 5-0:1.0: port 1, status 0100, change 0003, 12 Mb/s
	usb 5-1: USB disconnect, address 2
	usb 5-1: usb_disable_device nuking all URBs
	usb 5-1: unregistering interface 5-1:1.0
	PM: Removing info for No Bus:usbdev5.2_ep81
	 usbdev5.2_ep81: ep_device_release called for usbdev5.2_ep81

followed by the oops:

	BUG: spinlock bad magic on CPU#0, khubd/131
	BUG: unable to handle kernel paging request at virtual address 6b6b6c0b
	....

which just doesn't tell me anything.

		Linus

Re: [git pull] Input update for 2.6.17

[Dmitry Torokhov]

On 6/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> followed by the oops:
>
>        BUG: spinlock bad magic on CPU#0, khubd/131
>        BUG: unable to handle kernel paging request at virtual address 6b6b6c0b
>        ....
>
> which just doesn't tell me anything.
>

Linus,

Are you dropping mails with attachments or maybe you have not gone
through all your email, because I believe the patch I send to you
should fix the problem.

-- 
Dmitry

Re: [git pull] Input update for 2.6.17

[Linus Torvalds]

On Tue, 27 Jun 2006, Dmitry Torokhov wrote:
> 
> Are you dropping mails with attachments or maybe you have not gone
> through all your email, because I believe the patch I send to you
> should fix the problem.

Sorry too many emails, and I looked at the others first.

Yes, your patch fixes it. Goodie.

		Linus

Re: [git pull] Input update for 2.6.17

[Marcel Holtmann]

Hi Linus,

> > There were _no_ kernel messages just before the oops. Not even with USB 
> > debugging turned on. Of course, they may have been marked "informational", 
> > and not shown on the console. Every distribution seems to think that debug 
> > messages are more annoying than useful, so they tend to set the console 
> > debug level down (even if you boot with "debug" to turn it on!). Gaah!
> 
> Ok, with that fixed, I get
> 
> 	hub 4-1:1.0: 300mA power budget left
> 	hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0000
> 	hub 4-1:1.0: state 7 ports 3 chg 0000 evt 0008
> 	usbcore: registered new driver libusual
> 	usbcore: registered new driver hiddev
> 	usbhid 5-1:1.0: usb_probe_interface
> 	usbhid 5-1:1.0: usb_probe_interface - got id
> 	input: HID 05ac:1000 as /class/input/input0
> 	input: USB HID v1.11 Keyboard [HID 05ac:1000] on usb-0000:00:1d.3-1
> 	usbhid 5-1:1.1: usb_probe_interface
> 	usbhid 5-1:1.1: usb_probe_interface - got id
> 	input: HID 05ac:1000 as /class/input/input1
> 	input: USB HID v1.11 Mouse [HID 05ac:1000] on usb-0000:00:1d.3-1
> 	usbhid 5-2:1.0: usb_probe_interface
> 	usbhid 5-2:1.0: usb_probe_interface - got id
> 	drivers/usb/core/file.c: looking for a minor, starting at 96
> 	PM: Adding info for No Bus:hiddev0
> 	hiddev96: USB HID v1.11 Device [Apple Computer, Inc. IR Receiver] on usb-0000:00:1d.3-2
> 	usbhid 1-6.3:1.0: usb_probe_interface
> 	usbhid 1-6.3:1.0: usb_probe_interface - got id
> 	drivers/usb/core/file.c: looking for a minor, starting at 96
> 	PM: Adding info for No Bus:hiddev1
> 	hiddev97: USB HID v1.11 Device [Apple Cinema Display] on usb-0000:00:1d.7-6.3
> 	usbhid 4-1.1:1.0: usb_probe_interface
> 	usbhid 4-1.1:1.0: usb_probe_interface - got id
> 	input: Mitsumi Electric Apple Optical USB Mouse as /class/input/input2
> 	input: USB HID v1.10 Mouse [Mitsumi Electric Apple Optical USB Mouse] on usb-0000:00:1d.2-1.1
> 	usbhid 4-1.3:1.0: usb_probe_interface
> 	usbhid 4-1.3:1.0: usb_probe_interface - got id
> 	input: Mitsumi Electric Apple Extended USB Keyboard as /class/input/input3
> 	input: USB HID v1.10 Keyboard [Mitsumi Electric Apple Extended USB 
> 	Keyboard] on usb-0000:00:1d.2-1.3
> 	usbhid 4-1.3:1.1: usb_probe_interface
> 	usbhid 4-1.3:1.1: usb_probe_interface - got id
> 	input: Mitsumi Electric Apple Extended USB Keyboard as /class/input/input4
> 	input: USB HID v1.10 Device [Mitsumi Electric Apple Extended USB Keyboard] on usb-0000:00:1d.2-1.3
> 	usbcore: registered new driver usbhid
> 	drivers/usb/input/hid-core.c: v2.6:USB HID core driver
> 	PNP: No PS/2 controller found. Probing ports directly.
> 	PM: Adding info for platform:i8042
> 	i8042.c: No controller found.
> 	mice: PS/2 mouse device common for all mice
> 	i2c /dev entries driver
> 
> 	... snip snip, mounting root filesystem etc - time passes ..
> 
> 	usb 5-1: uhci_result_common: failed with status 440000
> 	usb 5-1: usbfs: USBDEVFS_CONTROL failed cmd hid2hci rqt 64 rq 0 len 0 ret -84
> 	usb 5-1: uhci_result_common: failed with status 440000
> 	usbhid 5-1:1.0: retrying intr urb
> 	usb 5-1: uhci_result_common: failed with status 440000
> 	hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0002
> 	uhci_hcd 0000:00:1d.3: port 1 portsc 008a,00
> 	hub 5-0:1.0: port 1, status 0100, change 0003, 12 Mb/s
> 	usb 5-1: USB disconnect, address 2
> 	usb 5-1: usb_disable_device nuking all URBs
> 	usb 5-1: unregistering interface 5-1:1.0
> 	PM: Removing info for No Bus:usbdev5.2_ep81
> 	 usbdev5.2_ep81: ep_device_release called for usbdev5.2_ep81
> 
> followed by the oops:
> 
> 	BUG: spinlock bad magic on CPU#0, khubd/131
> 	BUG: unable to handle kernel paging request at virtual address 6b6b6c0b
> 	....
> 
> which just doesn't tell me anything.

it is the Bluetooth device of the Mac mini. These devices are HID proxy
devices. This means they can appear as HID mouse and keyboard or as
Bluetooth dongle on the USB bus. The HID mode is used for early boot
stuff where no Bluetooth stack is available and you might wanna use your
keyboard to change PROM settings etc. Once the Bluetooth stack is ready
and capable of taking over full responsibility you might wanna switch
this dongle in HID mode into full HCI mode. This is what hid2hci is
doing at that point. In the success case you will see the disconnect of
a HID mouse and keyboard from the USB bus and a new USB Bluetooth dongle
will appear.

So the problem seems to be when the HID keyboard and mouse are
disconnecting.

Regards

Marcel

Re: [git pull] Input update for 2.6.17

[Linus Torvalds]

Ok, Dmitry's patch fixed one problem, but that one just allows me to get 
further enough that I can now suspend and resume the machine again, but 
there's still something wrong with HCI/USB/Input layer. 

I do believe it's related to the previous problem, because it does end up 
being very _close_, and it's again that usb 5-1 disconnect that seems to 
trigger it (except now it's not at bootup, now it's at resume-time):

	__tx_submit: hci0 tx submit failed urb da8a9cac type 1 err -19
	.. snip snip boring stuff ..
	PM: Adding info for No Bus:usbdev4.5_ep81
	PM: Adding info for No Bus:usbdev4.5
	drivers/usb/core/inode.c: creating file '005'
	hub 5-0:1.0: state 7 ports 2 chg 0006 evt 0006
	uhci_hcd 0000:00:1d.3: port 1 portsc 009b,00
	hub 5-0:1.0: port 1, status 0101, change 0003, 12 Mb/s
	usb 5-1: USB disconnect, address 4
	usb 5-1: usb_disable_device nuking all URBs
	usb 5-1: unregistering interface 5-1:1.0
	PM: Removing info for No Bus:usbdev5.4_ep81
	 usbdev5.4_ep81: ep_device_release called for usbdev5.4_ep81
	PM: Removing info for No Bus:usbdev5.4_ep02
	 usbdev5.4_ep02: ep_device_release called for usbdev5.4_ep02
	PM: Removing info for No Bus:usbdev5.4_ep82
	 usbdev5.4_ep82: ep_device_release called for usbdev5.4_ep82
	slab error in verify_redzone_free(): cache `size-512': memory outside object was overwritten
	 <c0103d31> show_trace+0xd/0x10  <c0104317> dump_stack+0x19/0x1b
	 <c015c5a8> __slab_error+0x17/0x1c  <c015c657> cache_free_debugcheck+0xaa/0x181
	 <c015cc61> kfree+0x75/0xaa  <df0d5146> hci_usb_close+0xbf/0x11d [hci_usb]
	 <df0d51cb> hci_usb_disconnect+0x27/0x67 [hci_usb]  <c02ab0c7> usb_unbind_interface+0x37/0x6e
	 <c024276f> __device_release_driver+0x63/0x79  <c02429c1> device_release_driver+0x2e/0x3e
	 <c02420b8> bus_remove_device+0x7e/0x8e  <c024104a> device_del+0x115/0x149
	 <c02a96f0> usb_disable_device+0xca/0x12d  <c02a5617> usb_disconnect+0x9d/0x117
	 <c02a676e> hub_thread+0x5d4/0xd8a  <c0132ec1> kthread+0xc5/0xf1
	 <c0101005> kernel_thread_helper+0x5/0xb
	dd977458: redzone 1:0x5a5a5a5a, redzone 2:0x170fc2a5.
	------------[ cut here ]------------
	kernel BUG at mm/slab.c:2688!
	...

(the actual OOPS message from the BUG_ON() is due to this one:

	BUG_ON(objp != index_to_obj(cachep, slabp, objnr));

but I think that's just due to the slab corruption that the redzone_free 
check already complained about, so I don't think the OOPS is very 
interesting).

Anyway, maybe it really is a hci_usb bug now, not an input layer thing, 
and it just happens close-by because device disconnect just in general is 
hard and nasty. The traceback certainly seems to point at hci_usb.

I'll see if this is repeatable (and whether it goes away without that 
hci_usb module).

		Linus

Re: [git pull] Input update for 2.6.17

[Linus Torvalds]

On Tue, 27 Jun 2006, Linus Torvalds wrote:
>
>	slab error in verify_redzone_free(): cache `size-512': memory outside object was overwritten
	...
> 	 dd977458: redzone 1:0x5a5a5a5a, redzone 2:0x170fc2a5.

Ok, it's definitely repeatable, although with small variations.

Now, in verify_redzone_free(), the redzone values _should_ have been 
RED_ACTIVE (which is 0x170FC2A5), so here the end-of-zone marker is ok, 
but the beginning has been overwritten with the normal kmalloc poison 
bytes (5a).

In the second version, I got:


	slab error in verify_redzone_free(): cache `size-512': memory outside object was overwritten
	 <c0103d31> show_trace+0xd/0x10  <c0104317> dump_stack+0x19/0x1b
	 <c015c5a8> __slab_error+0x17/0x1c  <c015c657> cache_free_debugcheck+0xaa/0x181
	 <c015cc61> kfree+0x75/0xaa  <df0d5146> hci_usb_close+0xbf/0x11d [hci_usb]
	 <df0d51cb> hci_usb_disconnect+0x27/0x67 [hci_usb]  <c02ab0c7> usb_unbind_interface+0x37/0x6e
	 <c024276f> __device_release_driver+0x63/0x79  <c02429c1> device_release_driver+0x2e/0x3e
	 <c02420b8> bus_remove_device+0x7e/0x8e  <c024104a> device_del+0x115/0x149
	 <c02a96f0> usb_disable_device+0xca/0x12d  <c02a5617> usb_disconnect+0x9d/0x117
	 <c02a676e> hub_thread+0x5d4/0xd8a  <c0132ec1> kthread+0xc5/0xf1
	 <c0101005> kernel_thread_helper+0x5/0xb 
	d570528c: redzone 1:0x5a5a5a5a, redzone 2:0x5a2cf071.

ie now "redzone 2" (which again should be RED_ACTIVE: 0x170FC2A5) is 
actually RED_INACTIVE (0x5A2CF071), which means that the thing basically 
got free'd twice (and corrupted in between).

So I think "hci_usb_close()" is freeing a pointer that it (or somebody 
else) already freed once, and depending on what has happened in the 
meantime to it, it's either allocated by somebody else, or got freed 
again. 

It seems to be inside hci_usb_unlink_urbs() (which has been inlined).

I _think_ it's the

                        kfree(urb->transfer_buffer);

in the "released completed requests" loop. That's if I read the assembly 
right.. (and I'm pretty sure I do - it's just before releasing the urb 
itself which ends up being just another kfree()).

Anyway, "urb->transfer_buffer" was initialized with

	urb->transfer_buffer = skb->data;

and I'm pretty damn sure you're supposed to just kfree() it.

So Marcel, I think this is a hci_usb.c bug. But I'm not able to fix it, 
unless the fix is to just remove that kfree entirely.

			Linus

Re: [git pull] Input update for 2.6.17

[Jeff Garzik]

Linus Torvalds wrote:
> Anyway, "urb->transfer_buffer" was initialized with
> 
> 	urb->transfer_buffer = skb->data;
> 
> and I'm pretty damn sure you're supposed to just kfree() it.

eh?  I would think dev_kfree_skb(), because who knows whether the skb 
was cloned, split, data buffer adjusted, destructors need to be called...

kfree()ing skb->data sounds like a recipe for corruption and crashes...

	Jeff

Re: [git pull] Input update for 2.6.17

[Linus Torvalds]

On Wed, 28 Jun 2006, Jeff Garzik wrote:

> Linus Torvalds wrote:
> > Anyway, "urb->transfer_buffer" was initialized with
> > 
> > 	urb->transfer_buffer = skb->data;
> > 
> > and I'm pretty damn sure you're supposed to just kfree() it.
> 
> eh?  I would think dev_kfree_skb(), because who knows whether the skb was
> cloned, split, data buffer adjusted, destructors need to be called...

Well, we don't actually have the skb available any more.

> kfree()ing skb->data sounds like a recipe for corruption and crashes...

Yeah. But I didn't actually look very deeply, maybe I mistook the init 
sequence. That said, corruption and crashes is obviously what I see, and 
why I started looking at it ;)

Marcel?

		Linus

Re: [git pull] Input update for 2.6.17

[Marcel Holtmann]

Hi Linus,

> > > Anyway, "urb->transfer_buffer" was initialized with
> > > 
> > > 	urb->transfer_buffer = skb->data;
> > > 
> > > and I'm pretty damn sure you're supposed to just kfree() it.
> > 
> > eh?  I would think dev_kfree_skb(), because who knows whether the skb was
> > cloned, split, data buffer adjusted, destructors need to be called...
> 
> Well, we don't actually have the skb available any more.
> 
> > kfree()ing skb->data sounds like a recipe for corruption and crashes...
> 
> Yeah. But I didn't actually look very deeply, maybe I mistook the init 
> sequence. That said, corruption and crashes is obviously what I see, and 
> why I started looking at it ;)

sorry, I haven't found the time to look into that. The hci_usb driver is
actually a mess and in a desperate need of a rewrite. However I haven't
seen anything like this oops in the past. Let me try to reproduce this.

Regards

Marcel

Re: [git pull] Input update for 2.6.17

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Wed, 28 Jun 2006, Jeff Garzik wrote:
> 
>> Linus Torvalds wrote:
>>> Anyway, "urb->transfer_buffer" was initialized with
>>>
>>> 	urb->transfer_buffer = skb->data;
>>>
>>> and I'm pretty damn sure you're supposed to just kfree() it.
>> eh?  I would think dev_kfree_skb(), because who knows whether the skb was
>> cloned, split, data buffer adjusted, destructors need to be called...
> 
> Well, we don't actually have the skb available any more.

You do:

>         urb->transfer_buffer = skb->data;
>         urb->transfer_buffer_length = skb->len;
> 
>         __fill_isoc_desc(urb, skb->len, le16_to_cpu(husb->isoc_out_ep->desc.wMaxPacketSize));
> 
>         _urb->priv = skb;

so it looks like you can grab it out of the 'priv' field.

And a damned good thing too...

	Jeff

Re: [git pull] Input update for 2.6.17

[Linus Torvalds]

On Wed, 28 Jun 2006, Jeff Garzik wrote:
> 
> You do:
> 
> >         urb->transfer_buffer = skb->data;
> >         urb->transfer_buffer_length = skb->len;
> > 
> >         __fill_isoc_desc(urb, skb->len,
> > le16_to_cpu(husb->isoc_out_ep->desc.wMaxPacketSize));
> > 
> >         _urb->priv = skb;
> 
> so it looks like you can grab it out of the 'priv' field.
> 
> And a damned good thing too...

Yeah, you'd have to do something like

	struct _urb *_urb = container_of(urb, struct _urb, urb);

first. However, it also turns out that some other code-paths are _also_ 
filling "urb->transfer_buffer", and those are indeed using a kmalloc'ed 
buffer (hci_usb_isoc_rx_submit()).

So the proper thing to do is probably along the lines of

	static void free_transfer_buffer(struct urb *urb)
	{
		struct _urb *_urb = container_of(urb, struct _urb, urb);

		if (_urb->priv) {
			kfree_skb((struct sk_buff *) _urb->priv);
			_urb->priv = NULL;
			urb->transfer_buffer = NULL;
			return;
		}
		kfree(urb->transfer_buffer);
		urb->transfer_buffer = NULL;
	}

or whatever. I dunno. I ended up just uncommenting the "kfree()" in my 
code, to see that it doesn't oops any more (and it doesn't).

		Linus

Re: [git pull] Input update for 2.6.17

[Marcel Holtmann]

Hi Linus,

> > Yes, if you have the UHCI driver loaded first, then when EHCI is loaded,
> > it disconnects everything on the bus and re-enumerates it.
> > 
> > But EHCI is built into the kernel first, before UHCI, so unless you are
> > using modules, nothing should be getting disconnected at boot time.
> 
> Yeah, that's not it.
> 
> It _seems_ to be triggered by this:
> 
> 	Bluetooth: HCI device and connection manager initialized
> 	Bluetooth: HCI socket layer initialized
> 	usb 5-1: USB disconnect, address 2
> 	usb 5-1: new full speed USB device using uhci_hcd and address 4
> 	usb 5-1: configuration #1 chosen from 1 choice
> 	Bluetooth: HCI USB driver ver 2.9
> 	usbcore: registered new driver hci_usb

I actually doubt that it is any of Bluetooth modules, but to be sure you
might boot the next time without the hci_usb driver around.

Regards

Marcel

Re: [git pull] Input update for 2.6.17

[Dmitry Torokhov]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

On 6/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Greg? Dmitry?
>
> To trigger, you probably need both slab debugging _and_ spinlock debugging
> on. And perhaps just the right timings, although I've been able to do it
> three times in a row now, so it doesn't seem to be _that_ timing
> sensitive.
>

Yep, this was me. I need to activate more debug options by default...

I believe this patch will fix it. Sorry, I had to send it as an attachment.

-- 
Dmitry

[-- Attachment #2: input-fix-resetting-name.patch --]
[-- Type: text/plain, Size: 1052 bytes --]

Input: fix resetting name, phys and uniq when unregistering device

It should be done before calling class_device_unregister() because
it will destroy the device and free memory if there are no other
references to the device.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---
 drivers/input/input.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: linux/drivers/input/input.c
===================================================================
--- linux.orig/drivers/input/input.c
+++ linux/drivers/input/input.c
@@ -1033,12 +1033,13 @@ void input_unregister_device(struct inpu
 	sysfs_remove_group(&dev->cdev.kobj, &input_dev_caps_attr_group);
 	sysfs_remove_group(&dev->cdev.kobj, &input_dev_id_attr_group);
 	sysfs_remove_group(&dev->cdev.kobj, &input_dev_attr_group);
-	class_device_unregister(&dev->cdev);
 
 	mutex_lock(&dev->mutex);
 	dev->name = dev->phys = dev->uniq = NULL;
 	mutex_unlock(&dev->mutex);
 
+	class_device_unregister(&dev->cdev);
+
 	input_wakeup_procfs_readers();
 }
 EXPORT_SYMBOL(input_unregister_device);

[git pull] Input update for 2.6.17

[Dmitry Torokhov]

Linus,

Please pull from:

	git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git

or
	master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git

to receive various updates to the input layer.

Diffstat:

 Documentation/input/joystick-parport.txt    |   11 
 arch/alpha/kernel/setup.c                   |   18 +
 arch/i386/kernel/setup.c                    |   18 +
 arch/mips/Kconfig                           |    6 
 arch/mips/kernel/Makefile                   |    2 
 arch/mips/kernel/i8253.c                    |   28 +
 arch/powerpc/kernel/setup-common.c          |   24 +
 drivers/Makefile                            |    4 
 drivers/char/keyboard.c                     |  118 ++++++-
 drivers/input/evbug.c                       |    3 
 drivers/input/evdev.c                       |    6 
 drivers/input/gameport/gameport.c           |   30 +
 drivers/input/gameport/ns558.c              |   13 
 drivers/input/input.c                       |  436 +++++++++++++++++-----------
 drivers/input/joydev.c                      |    6 
 drivers/input/joystick/amijoy.c             |   11 
 drivers/input/joystick/db9.c                |   13 
 drivers/input/joystick/gamecon.c            |   96 ++++--
 drivers/input/joystick/iforce/iforce-ff.c   |   24 -
 drivers/input/joystick/iforce/iforce-main.c |    2 
 drivers/input/joystick/iforce/iforce.h      |    5 
 drivers/input/joystick/turbografx.c         |   13 
 drivers/input/keyboard/Kconfig              |    2 
 drivers/input/keyboard/atkbd.c              |   24 -
 drivers/input/keyboard/corgikbd.c           |   35 +-
 drivers/input/keyboard/hil_kbd.c            |    9 
 drivers/input/keyboard/spitzkbd.c           |   10 
 drivers/input/misc/pcspkr.c                 |   27 -
 drivers/input/misc/uinput.c                 |   14 
 drivers/input/mouse/hil_ptr.c               |    7 
 drivers/input/mouse/psmouse-base.c          |   38 +-
 drivers/input/mouse/synaptics.c             |   18 -
 drivers/input/mousedev.c                    |    6 
 drivers/input/power.c                       |    3 
 drivers/input/serio/hil_mlc.c               |    3 
 drivers/input/serio/i8042-x86ia64io.h       |   26 +
 drivers/input/serio/libps2.c                |   10 
 drivers/input/serio/parkbd.c                |    3 
 drivers/input/serio/rpckbd.c                |    3 
 drivers/input/serio/serio.c                 |   48 +--
 drivers/input/serio/serio_raw.c             |   29 -
 drivers/input/tsdev.c                       |    6 
 drivers/usb/input/hid-input.c               |    2 
 include/linux/gameport.h                    |    7 
 include/linux/input.h                       |   25 +
 include/linux/kbd_kern.h                    |    2 
 include/linux/keyboard.h                    |   13 
 include/linux/libps2.h                      |    2 
 include/linux/serio.h                       |    9 
 include/linux/uinput.h                      |    4 
 50 files changed, 821 insertions(+), 451 deletions(-)

Changelog:

Adrian Bunk:
      Input: serio - fix memory leak
      Input: gameport - fix memory leak

Arjan van de Ven:
      Input: serio - semaphore to mutex conversion
      Input: gameport - semaphore to mutex conversion

Bjorn Helgaas:
      Input: ns558 - fix logic around pnp_register_driver()
      Input: i8042 - fix logic around pnp_register_driver()

Dmitry Torokhov:
      Input: uinput - semaphore to mutex conversion
      Input: initialize serio and gameport at subsystem level
      Input: fix input_free_device() implementation
      Input: atkbd - allow disabling on X86_PC (if EMBEDDED)
      Input: limit attributes' output to PAGE_SIZE
      Input: convert /proc handling to seq_file
      Input: make modalias code respect allowed buffer size

Eric Sesterhenn:
      Input: use kzalloc() throughout the code

Ingo Molnar:
      Input: psmouse - semaphore to mutex conversion
      Input: atkbd - semaphore to mutex conversion
      Input: joysticks - semaphore to mutex conversion

Jes Sorensen:
      Input: input core - semaphore to mutex conversion

Micah F. Galizia:
      Input: HID - fix duplicate key mapping for Logitech UltraX remote

Michael Neuling:
      Input: pcspkr - separate device and driver registration

Raphael Assenat:
      Input: gamecon - add SNES mouse support

Richard Purdie:
      Input: zaurus keyboard driver updates

Richard Thrippleton:
      Input: synaptics - limit rate to 40pps on Toshiba Protege M300

Samuel Thibault:
      Input: add support for Braille devices

Vojtech Pavlik:
      Input: atkbd - fix complaints about 'releasing unknown key 0x7f'
      Input: atkbd - disable softrepeat for dumb keyboards
 
-- 
Dmitry