Re: [ANNOUNCE] Git v1.7.12-rc0
On Mon, 23 Jul 2012 22:08:48 -0700, Junio C Hamano wrote: > * The value of core.attributesfile and core.excludesfile default to >$HOME/.config/attributes and $HOME/.config/ignore respectively when >these files exist. $HOME/.config/git/attributes .. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Git v1.7.12-rc0
On Mon, 23 Jul 2012 22:08:48 -0700, Junio C Hamano gits...@pobox.com wrote: * The value of core.attributesfile and core.excludesfile default to $HOME/.config/attributes and $HOME/.config/ignore respectively when these files exist. $HOME/.config/git/attributes .. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 Regression Thinkpad acpi
Lukas Hejtmanek wrote: On Mon, Feb 25, 2008 at 06:01:13PM -0300, Henrique de Moraes Holschuh wrote: Not even over the new netlink socket? Or the thinkpad-acpi input device? how can I check this? A while ago I worked on a new acpi daemon that could receive events from both netlink and /dev/input devices. Right now it's more like a testing tool then a real replacement for the current acpid. I haven't had time to work on it. http://git.dbservice.com/?p=acpid;a=summary $ git clone git://dbservice.com/acpid You'll need dbus and lua to compile it. There's also a readme that describes how to get it running and how it works. In its default configuration it will print the events into stdout. tom -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 Regression Thinkpad acpi
Lukas Hejtmanek wrote: On Mon, Feb 25, 2008 at 06:01:13PM -0300, Henrique de Moraes Holschuh wrote: Not even over the new netlink socket? Or the thinkpad-acpi input device? how can I check this? A while ago I worked on a new acpi daemon that could receive events from both netlink and /dev/input devices. Right now it's more like a testing tool then a real replacement for the current acpid. I haven't had time to work on it. http://git.dbservice.com/?p=acpid;a=summary $ git clone git://dbservice.com/acpid You'll need dbus and lua to compile it. There's also a readme that describes how to get it running and how it works. In its default configuration it will print the events into stdout. tom -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hid device not claimed but /dev/input/event exists
Jiri Kosina wrote: Does anything appear in dmesg when you press those buttons? There should be messages resembling the one you already have there: drivers/hid/hid-core.c: report (size 8) (unnumbered) drivers/hid/hid-core.c: report 0 (size 8) = 00 00 28 00 00 00 00 00 and they should react to keys such as FastForward, Play, Mute, Volume Up, etc. This bug is in a completely different place then I thought! The speakers were plugged into the hub built into my monitor. I plugged it directly into the mainboard and voila, it works. Even g15daemon, the lcd driver, can now display a nice clock on the lcd. Could it be that the hub is defective? tom -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hid device not claimed but /dev/input/event exists
Jiri Kosina wrote: On Tue, 19 Feb 2008, Tomas Carnecky wrote: The device apparently has four 'interfaces' - whatever that is, see [1]. It seems like usbhid probes interface 2 (which is the LCD plus a few buttons, probably the four just under the LCD, as described [1]). Because usbhid doesn't know how to handle the buttons, it fails. But then it probes interface 3 which is a 'proper' HID device with well-defined buttons. Yes, the dump clearly shows that. Does anything appear in dmesg when you press those buttons? There should be messages resembling the one you already have there: drivers/hid/hid-core.c: report (size 8) (unnumbered) drivers/hid/hid-core.c: report 0 (size 8) = 00 00 28 00 00 00 00 00 and they should react to keys such as FastForward, Play, Mute, Volume Up, etc. Nothing. Not even after I removed the alsa-usb-audio driver. All I see is Keyboard.*, but the events from the speaker should be Key.*, right? It looks like the speaker goes into a different mode once the USB cable is plugged in. Without the USB cable, the Z-10 acts as simple/dumb speaker, the volume up/down buttons change the internal volume, and I see that on the display, too. The play/next/prev song buttons don't do anything, which is quite obvious. But once the USB cable is plugged in, the volume up/down buttons stop reacting. I assume they are now meant to send events to the computer so that some software can decide what to do. But features that are not useful for the computer (bass/treble), can still be controlled using the buttons on the speaker. The buttons are not dead. I can see that because the display goes to sleep after a few seconds of inactivity, and when I press the volume buttons, it wakes up and displays the current volume. So the speaker is definitely seeing that the buttons are being pressed. Is there a USB packet inspector/dumper, like libpcap for network? tom -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hid device not claimed but /dev/input/event exists
Jiri Kosina wrote: On Tue, 19 Feb 2008, Tomas Carnecky wrote: usb 1-2.2: new full speed USB device using ehci_hcd and address 6 usb 1-2.2: configuration #1 chosen from 1 choice HID device claimed by neither input, hiddev nor hidraw input: Logitech Z-10 USB Speaker as /devices/pci:00/:00:02.1/usb1/1-2/1-2.2/1-2.2:1.3/input/input4 input: USB HID v1.10 Device [Logitech Z-10 USB Speaker] on usb-:00:02.1-2.2 Nobody claims the device and yet an evdev device shows up in /dev/input? That Yes, that looks indeed bogus. I enabled HID_DEBUG, but no debug messages show up in my dmesg output, which is strange. You have to modprobe the 'hid' module with 'debug=1' parameter. Please send me the resulting output. Attached is the dump from dmesg. The device apparently has four 'interfaces' - whatever that is, see [1]. It seems like usbhid probes interface 2 (which is the LCD plus a few buttons, probably the four just under the LCD, as described [1]). Because usbhid doesn't know how to handle the buttons, it fails. But then it probes interface 3 which is a 'proper' HID device with well-defined buttons. But still nothing shows up if I press the buttons. But something is strange, neither does when I press buttons on my sidewinder pad. Unless I 'cat /dev/input/event5' and then press the buttons, then they shows up in dmesg. But that trick doesn't work with the Z-10 speakers. Maybe the alsa driver is interfering somehow? [1] http://forums.logitech.com/logitech/board/message?board.id=stereo_20=633#M633 usb 1-2.2: new full speed USB device using ehci_hcd and address 8 usb 1-2.2: configuration #1 chosen from 1 choice drivers/hid/usbhid/hid-core.c: HID probe called for ifnum 2 drivers/hid/usbhid/hid-core.c: report descriptor (size 46, read 46) = 06 00 ff 09 00 a1 01 15 00 26 ff 00 75 08 95 08 06 00 ff 09 02 85 02 06 00 ff 09 03 81 02 09 04 95 03 b1 02 09 06 85 03 96 df 03 91 02 c0 drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0102 wIndex=0x0002 wLength=9 drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0302 wIndex=0x0002 wLength=4 INPUT(2)[INPUT] Field(0) Usage(8) ff00.0002 ff00.0003 ff00.0003 ff00.0003 ff00.0003 ff00.0003 ff00.0003 ff00.0003 Logical Minimum(0) Logical Maximum(255) Report Size(8) Report Count(8) Report Offset(0) Flags( Variable Absolute ) OUTPUT(3)[OUTPUT] Field(0) Usage(991) ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006
hid device not claimed but /dev/input/event exists
kernel 2.6.25-rc2 usb 1-2.2: new full speed USB device using ehci_hcd and address 6 usb 1-2.2: configuration #1 chosen from 1 choice HID device claimed by neither input, hiddev nor hidraw input: Logitech Z-10 USB Speaker as /devices/pci:00/:00:02.1/usb1/1-2/1-2.2/1-2.2:1.3/input/input4 input: USB HID v1.10 Device [Logitech Z-10 USB Speaker] on usb-:00:02.1-2.2 Nobody claims the device and yet an evdev device shows up in /dev/input? That device reports ~8 EV_KEY event codes, which is about right, but pressing these buttons doesn't generate any events. The audio part of the device works ok with the alsa-usb-audio driver. Though sometimes it locks up, when I try to change the volume of the speaker through the gnome-volume dialog. When that happens, lsusb becomes _very_ slow and eventually times out (cannot read device status, Connection timed out (110)), I also see some of these messages in dmesg: usb 1-2.2: usbfs: USBDEVFS_CONTROL failed cmd lsusb rqt 128 rq 6 len 255 ret -110 (with different 'len' values). To reset the device I have to plug it out and in again. I enabled HID_DEBUG, but no debug messages show up in my dmesg output, which is strange. Attached is lsusb of the device. tom Bus 001 Device 006: ID 046d:0a07 Logitech, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x046d Logitech, Inc. idProduct 0x0a07 bcdDevice0.1e iManufacturer 1 Logitech iProduct2 Z-10 USB Speaker iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 219 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 3 G6 2006/06/21 10:55 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 43 bInCollection 1 baInterfaceNr( 0) 1 AudioControl Interface Descriptor: bLength12 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID12 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength13 bDescriptorType36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 1 bSourceID 12 bControlSize2 bmaControls( 0) 0x41 bmaControls( 0) 0x01 Mute Automatic Gain Bass Boost bmaControls( 1) 0x02 bmaControls( 1) 0x00 Volume bmaControls( 2) 0x02 bmaControls( 2) 0x00 Volume iFeature0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID20 wTerminalType 0x0301 Speaker bAssocTerminal 0 bSourceID 1 iTerminal 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 12 bDelay
Re: hid device not claimed but /dev/input/event exists
Jiri Kosina wrote: On Tue, 19 Feb 2008, Tomas Carnecky wrote: usb 1-2.2: new full speed USB device using ehci_hcd and address 6 usb 1-2.2: configuration #1 chosen from 1 choice HID device claimed by neither input, hiddev nor hidraw input: Logitech Z-10 USB Speaker as /devices/pci:00/:00:02.1/usb1/1-2/1-2.2/1-2.2:1.3/input/input4 input: USB HID v1.10 Device [Logitech Z-10 USB Speaker] on usb-:00:02.1-2.2 Nobody claims the device and yet an evdev device shows up in /dev/input? That Yes, that looks indeed bogus. I enabled HID_DEBUG, but no debug messages show up in my dmesg output, which is strange. You have to modprobe the 'hid' module with 'debug=1' parameter. Please send me the resulting output. Attached is the dump from dmesg. The device apparently has four 'interfaces' - whatever that is, see [1]. It seems like usbhid probes interface 2 (which is the LCD plus a few buttons, probably the four just under the LCD, as described [1]). Because usbhid doesn't know how to handle the buttons, it fails. But then it probes interface 3 which is a 'proper' HID device with well-defined buttons. But still nothing shows up if I press the buttons. But something is strange, neither does when I press buttons on my sidewinder pad. Unless I 'cat /dev/input/event5' and then press the buttons, then they shows up in dmesg. But that trick doesn't work with the Z-10 speakers. Maybe the alsa driver is interfering somehow? [1] http://forums.logitech.com/logitech/board/message?board.id=stereo_20message.id=633#M633 usb 1-2.2: new full speed USB device using ehci_hcd and address 8 usb 1-2.2: configuration #1 chosen from 1 choice drivers/hid/usbhid/hid-core.c: HID probe called for ifnum 2 drivers/hid/usbhid/hid-core.c: report descriptor (size 46, read 46) = 06 00 ff 09 00 a1 01 15 00 26 ff 00 75 08 95 08 06 00 ff 09 02 85 02 06 00 ff 09 03 81 02 09 04 95 03 b1 02 09 06 85 03 96 df 03 91 02 c0 drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0102 wIndex=0x0002 wLength=9 drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0302 wIndex=0x0002 wLength=4 INPUT(2)[INPUT] Field(0) Usage(8) ff00.0002 ff00.0003 ff00.0003 ff00.0003 ff00.0003 ff00.0003 ff00.0003 ff00.0003 Logical Minimum(0) Logical Maximum(255) Report Size(8) Report Count(8) Report Offset(0) Flags( Variable Absolute ) OUTPUT(3)[OUTPUT] Field(0) Usage(991) ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006 ff00.0006
hid device not claimed but /dev/input/event exists
kernel 2.6.25-rc2 usb 1-2.2: new full speed USB device using ehci_hcd and address 6 usb 1-2.2: configuration #1 chosen from 1 choice HID device claimed by neither input, hiddev nor hidraw input: Logitech Z-10 USB Speaker as /devices/pci:00/:00:02.1/usb1/1-2/1-2.2/1-2.2:1.3/input/input4 input: USB HID v1.10 Device [Logitech Z-10 USB Speaker] on usb-:00:02.1-2.2 Nobody claims the device and yet an evdev device shows up in /dev/input? That device reports ~8 EV_KEY event codes, which is about right, but pressing these buttons doesn't generate any events. The audio part of the device works ok with the alsa-usb-audio driver. Though sometimes it locks up, when I try to change the volume of the speaker through the gnome-volume dialog. When that happens, lsusb becomes _very_ slow and eventually times out (cannot read device status, Connection timed out (110)), I also see some of these messages in dmesg: usb 1-2.2: usbfs: USBDEVFS_CONTROL failed cmd lsusb rqt 128 rq 6 len 255 ret -110 (with different 'len' values). To reset the device I have to plug it out and in again. I enabled HID_DEBUG, but no debug messages show up in my dmesg output, which is strange. Attached is lsusb of the device. tom Bus 001 Device 006: ID 046d:0a07 Logitech, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x046d Logitech, Inc. idProduct 0x0a07 bcdDevice0.1e iManufacturer 1 Logitech iProduct2 Z-10 USB Speaker iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 219 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 3 G6 2006/06/21 10:55 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 43 bInCollection 1 baInterfaceNr( 0) 1 AudioControl Interface Descriptor: bLength12 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID12 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength13 bDescriptorType36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 1 bSourceID 12 bControlSize2 bmaControls( 0) 0x41 bmaControls( 0) 0x01 Mute Automatic Gain Bass Boost bmaControls( 1) 0x02 bmaControls( 1) 0x00 Volume bmaControls( 2) 0x02 bmaControls( 2) 0x00 Volume iFeature0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID20 wTerminalType 0x0301 Speaker bAssocTerminal 0 bSourceID 1 iTerminal 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 12 bDelay
Re: hid device not claimed but /dev/input/event exists
Jiri Kosina wrote: On Tue, 19 Feb 2008, Tomas Carnecky wrote: The device apparently has four 'interfaces' - whatever that is, see [1]. It seems like usbhid probes interface 2 (which is the LCD plus a few buttons, probably the four just under the LCD, as described [1]). Because usbhid doesn't know how to handle the buttons, it fails. But then it probes interface 3 which is a 'proper' HID device with well-defined buttons. Yes, the dump clearly shows that. Does anything appear in dmesg when you press those buttons? There should be messages resembling the one you already have there: drivers/hid/hid-core.c: report (size 8) (unnumbered) drivers/hid/hid-core.c: report 0 (size 8) = 00 00 28 00 00 00 00 00 and they should react to keys such as FastForward, Play, Mute, Volume Up, etc. Nothing. Not even after I removed the alsa-usb-audio driver. All I see is Keyboard.*, but the events from the speaker should be Key.*, right? It looks like the speaker goes into a different mode once the USB cable is plugged in. Without the USB cable, the Z-10 acts as simple/dumb speaker, the volume up/down buttons change the internal volume, and I see that on the display, too. The play/next/prev song buttons don't do anything, which is quite obvious. But once the USB cable is plugged in, the volume up/down buttons stop reacting. I assume they are now meant to send events to the computer so that some software can decide what to do. But features that are not useful for the computer (bass/treble), can still be controlled using the buttons on the speaker. The buttons are not dead. I can see that because the display goes to sleep after a few seconds of inactivity, and when I press the volume buttons, it wakes up and displays the current volume. So the speaker is definitely seeing that the buttons are being pressed. Is there a USB packet inspector/dumper, like libpcap for network? tom -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hid device not claimed but /dev/input/event exists
Jiri Kosina wrote: Does anything appear in dmesg when you press those buttons? There should be messages resembling the one you already have there: drivers/hid/hid-core.c: report (size 8) (unnumbered) drivers/hid/hid-core.c: report 0 (size 8) = 00 00 28 00 00 00 00 00 and they should react to keys such as FastForward, Play, Mute, Volume Up, etc. This bug is in a completely different place then I thought! The speakers were plugged into the hub built into my monitor. I plugged it directly into the mainboard and voila, it works. Even g15daemon, the lcd driver, can now display a nice clock on the lcd. Could it be that the hub is defective? tom -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] teach checkpatch.pl about list_for_each
Christer Weinigel wrote: By the way, what is the consensus on lines over 80 characters? checkpatch complains about the following: WARNING: line over 80 characters #762: FILE: drivers/spi/spi_s3c24xx_dma.c:720: + printk(KERN_INFO "S3C24xx SPI DMA driver (c) 2007 Nordnav Technologies AB\n"); I can of course break this into: printk(KERN_INFO "S3C24xx SPI DMA driver (c) 2007 Nordnav " "Technologies AB\n"); but in my opinion that becomes more even unreadable. Would it be possible to add a special case so that checkpatch ignores long strings that go beyond 80 characters? Do you think it is a good idea? At the top of the file add a #define and use that in the code? Some drivers define their version/author etc that way and then just printk(DRIVER_VERSION DRIVER_AUTHOR); tom -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86] kernel/audit.c cleanup according to checkpatch.pl
Cyrill Gorcunov wrote:
[=?ISO-8859-1?Q?J=F6rn_Engel_ - Thu, Jan 03, 2008 at 12:29:57PM +0100]
| On Thu, 3 January 2008 14:19:25 +0300, Cyrill Gorcunov wrote:
| > @@ -232,7 +232,8 @@ void audit_log_lost(const char *message)
| >
| > if (print) {
| > printk(KERN_WARNING
| > - "audit: audit_lost=%d audit_rate_limit=%d
audit_backlog_limit=%d\n",
| > + "audit: audit_lost=%d audit_rate_limit=%d "
| > + "audit_backlog_limit=%d\n",
| > atomic_read(_lost),
| > audit_rate_limit,
| > audit_backlog_limit);
|
| This hunk is a bit questionable. It can easily deceive a reader to
| assume two seperate lines printed out and sometimes defeats grepping
| for printk output to find the code generating the message.
|
| Rest looks good to me.
|
| Jörn
|
| --
| He that composes himself is wiser than he that composes a book.
| -- B. Franklin
|
indeed.
here is updated one (with these part removed)
Instead of removing that part completely, why not print this:
"audit: lost=%d rate_limit=%d backlog_limit=%d\n"
In that line there were too many 'audit's IMHO, and if someone wants to
grep 'audit_lost=' he still can, 'audit:.*lost=' or something like that..
tom
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [x86] kernel/audit.c cleanup according to checkpatch.pl
Cyrill Gorcunov wrote:
[=?ISO-8859-1?Q?J=F6rn_Engel_ - Thu, Jan 03, 2008 at 12:29:57PM +0100]
| On Thu, 3 January 2008 14:19:25 +0300, Cyrill Gorcunov wrote:
| @@ -232,7 +232,8 @@ void audit_log_lost(const char *message)
|
| if (print) {
| printk(KERN_WARNING
| - audit: audit_lost=%d audit_rate_limit=%d
audit_backlog_limit=%d\n,
| + audit: audit_lost=%d audit_rate_limit=%d
| + audit_backlog_limit=%d\n,
| atomic_read(audit_lost),
| audit_rate_limit,
| audit_backlog_limit);
|
| This hunk is a bit questionable. It can easily deceive a reader to
| assume two seperate lines printed out and sometimes defeats grepping
| for printk output to find the code generating the message.
|
| Rest looks good to me.
|
| Jörn
|
| --
| He that composes himself is wiser than he that composes a book.
| -- B. Franklin
|
indeed.
here is updated one (with these part removed)
Instead of removing that part completely, why not print this:
audit: lost=%d rate_limit=%d backlog_limit=%d\n
In that line there were too many 'audit's IMHO, and if someone wants to
grep 'audit_lost=' he still can, 'audit:.*lost=' or something like that..
tom
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] teach checkpatch.pl about list_for_each
Christer Weinigel wrote: By the way, what is the consensus on lines over 80 characters? checkpatch complains about the following: WARNING: line over 80 characters #762: FILE: drivers/spi/spi_s3c24xx_dma.c:720: + printk(KERN_INFO S3C24xx SPI DMA driver (c) 2007 Nordnav Technologies AB\n); I can of course break this into: printk(KERN_INFO S3C24xx SPI DMA driver (c) 2007 Nordnav Technologies AB\n); but in my opinion that becomes more even unreadable. Would it be possible to add a special case so that checkpatch ignores long strings that go beyond 80 characters? Do you think it is a good idea? At the top of the file add a #define and use that in the code? Some drivers define their version/author etc that way and then just printk(DRIVER_VERSION DRIVER_AUTHOR); tom -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: smp_call_function_single() and smp_call_function_mask()
Arjan van de Ven wrote: > On Sun, 02 Dec 2007 09:43:39 +0100 > Tomas Carnecky <[EMAIL PROTECTED]> wrote: > >> WARNING: at arch/x86/kernel/smp_64.c:427 smp_call_function_single() >> WARNING: at arch/x86/kernel/smp_64.c:397 smp_call_function_mask() >> >> dmesg and config attached. >> >> I'm getting about three of each at boot. I'm running: >> commit e1cca7e8d484390169777b423a7fe46c7021fec1 >> Date: Thu Nov 29 16:25:29 2007 -0800 >> which is the latest git as of yesterday plus a one (unrelated) debug >> statement patch in usb uhci. >> >> There was a similar bug report after 2.6.23-rc8-mm was released. >> Though there seems to be a fundamental problem with how people use >> smp_call_function*() [1]. And this can just as well be another >> incarnation of it. >> >> Is that easy enough to fix or do I need to bisect (it didn't happen in >> 2.6.24-rc3)? >> > > this appears to be a bug in the acpi code, to be exact in > processor_throttling.c file, function > acpi_processor_set_throttling_ptc(); it disables interrupts and then > appears to do a cross-cpu IPI to set the state. Well... we can't do > that due to deadlock reasons (you can't do IPI's with interrupts off or > you can get a very nice deadlock with the cpu that you IPI trying to > do the same thing to you). > I updated the kernel today (to 1a2edea9aff48...) and the warnings are gone. tom -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: smp_call_function_single() and smp_call_function_mask()
Arjan van de Ven wrote: On Sun, 02 Dec 2007 09:43:39 +0100 Tomas Carnecky [EMAIL PROTECTED] wrote: WARNING: at arch/x86/kernel/smp_64.c:427 smp_call_function_single() WARNING: at arch/x86/kernel/smp_64.c:397 smp_call_function_mask() dmesg and config attached. I'm getting about three of each at boot. I'm running: commit e1cca7e8d484390169777b423a7fe46c7021fec1 Date: Thu Nov 29 16:25:29 2007 -0800 which is the latest git as of yesterday plus a one (unrelated) debug statement patch in usb uhci. There was a similar bug report after 2.6.23-rc8-mm was released. Though there seems to be a fundamental problem with how people use smp_call_function*() [1]. And this can just as well be another incarnation of it. Is that easy enough to fix or do I need to bisect (it didn't happen in 2.6.24-rc3)? this appears to be a bug in the acpi code, to be exact in processor_throttling.c file, function acpi_processor_set_throttling_ptc(); it disables interrupts and then appears to do a cross-cpu IPI to set the state. Well... we can't do that due to deadlock reasons (you can't do IPI's with interrupts off or you can get a very nice deadlock with the cpu that you IPI trying to do the same thing to you). I updated the kernel today (to 1a2edea9aff48...) and the warnings are gone. tom -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
WARNING: smp_call_function_single() and smp_call_function_mask()
WARNING: at arch/x86/kernel/smp_64.c:427 smp_call_function_single() WARNING: at arch/x86/kernel/smp_64.c:397 smp_call_function_mask() dmesg and config attached. I'm getting about three of each at boot. I'm running: commit e1cca7e8d484390169777b423a7fe46c7021fec1 Date: Thu Nov 29 16:25:29 2007 -0800 which is the latest git as of yesterday plus a one (unrelated) debug statement patch in usb uhci. There was a similar bug report after 2.6.23-rc8-mm was released. Though there seems to be a fundamental problem with how people use smp_call_function*() [1]. And this can just as well be another incarnation of it. Is that easy enough to fix or do I need to bisect (it didn't happen in 2.6.24-rc3)? tom [1] http://kerneltrap.org/mailarchive/linux-kernel/2007/9/27/324310 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
WARNING: smp_call_function_single() and smp_call_function_mask()
WARNING: at arch/x86/kernel/smp_64.c:427 smp_call_function_single() WARNING: at arch/x86/kernel/smp_64.c:397 smp_call_function_mask() dmesg and config attached. I'm getting about three of each at boot. I'm running: commit e1cca7e8d484390169777b423a7fe46c7021fec1 Date: Thu Nov 29 16:25:29 2007 -0800 which is the latest git as of yesterday plus a one (unrelated) debug statement patch in usb uhci. There was a similar bug report after 2.6.23-rc8-mm was released. Though there seems to be a fundamental problem with how people use smp_call_function*() [1]. And this can just as well be another incarnation of it. Is that easy enough to fix or do I need to bisect (it didn't happen in 2.6.24-rc3)? tom [1] http://kerneltrap.org/mailarchive/linux-kernel/2007/9/27/324310 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH?] OSS: fix operator precedence in return of btaudio_dsp_ioctl
Roel Kluin wrote: > First of all, is /sound/oss/* still maintained? > Documentation/feature-removal-schedule.txt What: drivers depending on OSS_OBSOLETE When: options in 2.6.23, code in 2.6.25 Why: obsolete OSS drivers Who: Adrian Bunk <[EMAIL PROTECTED]> tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH?] OSS: fix operator precedence in return of btaudio_dsp_ioctl
Roel Kluin wrote: First of all, is /sound/oss/* still maintained? Documentation/feature-removal-schedule.txt What: drivers depending on OSS_OBSOLETE When: options in 2.6.23, code in 2.6.25 Why: obsolete OSS drivers Who: Adrian Bunk [EMAIL PROTECTED] tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: laptop reboots right after hibernation
Rafael J. Wysocki wrote: > On Sunday, 18 of November 2007, Tomas Carnecky wrote: >> Pavel Machek wrote: >>> Hi! >>> >>>> echo disk > /sys/power/state >>>> >>>> successfully saves that state to the disk, but just as the laptop is >>>> about to turn itself off, it reboots (successfully, so the >>>> hibernation/resume process works well, even with X running! which is >>>> awesome :) ). But I'd rather like the computer turned off after I >>>> hibernate it. Where could the problem be? >>>> >>>> It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few >>>> days, both suspend and hibernate worked there (with one or two crashes, >>>> probably due to X, I've read that the intel driver got some >>>> suspend/resume improvements recently). Now I'm running gentoo, kernel >>>> 2.6.24-rc2. I'm using newer versions of almost all software now compared >>>> to the ubuntu system. >>> If it works in older ubuntu, you can probably do bisect. Does normal >>> shutdown work? You can try platform vs. shutdown mode... >> I forgot, normal shutdown (init 0) works, the 'shutdown' command fails >> somewhere in the gentoo init scripts, but that has nothing to do with >> the kernel. 'init 6' also works. Both regardless of where the notebook >> is (dock or outside). > > Please verify if you have the ehci_hcd driver loaded when the box is in the > dock. If so, please try to unload it before hibernation and see if the box > will reboot. I had to recompile the kernel because I have a monolithic kernel with as many components as possible compiled in. But after I disabled the whole USB subsystem, the laptop doesn't reboot anymore after hibernation. Is that a bug in the usb driver or are users supposed to unload ehci_hcd each time before hibernation? In the former case, I'd be willing to help debug. tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: laptop reboots right after hibernation
Rafael J. Wysocki wrote: On Sunday, 18 of November 2007, Tomas Carnecky wrote: Pavel Machek wrote: Hi! echo disk /sys/power/state successfully saves that state to the disk, but just as the laptop is about to turn itself off, it reboots (successfully, so the hibernation/resume process works well, even with X running! which is awesome :) ). But I'd rather like the computer turned off after I hibernate it. Where could the problem be? It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few days, both suspend and hibernate worked there (with one or two crashes, probably due to X, I've read that the intel driver got some suspend/resume improvements recently). Now I'm running gentoo, kernel 2.6.24-rc2. I'm using newer versions of almost all software now compared to the ubuntu system. If it works in older ubuntu, you can probably do bisect. Does normal shutdown work? You can try platform vs. shutdown mode... I forgot, normal shutdown (init 0) works, the 'shutdown' command fails somewhere in the gentoo init scripts, but that has nothing to do with the kernel. 'init 6' also works. Both regardless of where the notebook is (dock or outside). Please verify if you have the ehci_hcd driver loaded when the box is in the dock. If so, please try to unload it before hibernation and see if the box will reboot. I had to recompile the kernel because I have a monolithic kernel with as many components as possible compiled in. But after I disabled the whole USB subsystem, the laptop doesn't reboot anymore after hibernation. Is that a bug in the usb driver or are users supposed to unload ehci_hcd each time before hibernation? In the former case, I'd be willing to help debug. tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: laptop reboots right after hibernation
Since this is becoming more an IDE/ATA issue, I added [EMAIL PROTECTED] to CC. I hope that's the right mailinglist. Tomas Carnecky wrote: > (3) Once the notebook was in the docking station (whether I boot it > while in the dock or boot it outside and then put it into the dock) and > I take it out (press the 'undock' button on the dock, wait for the green > led, then take out the notebook) things get interesting: > > (a) I initiate STR, notebook correctly goes to sleep, but it only wakes > up if I have it in the docking station. If I try to wake it up outside > of the docking station it will fail. Magic number: 0:971:888 hash matches drivers/base/power/main.c:82 hash matches device ptyuf hash matches device :00:1f.1 00:1f.1 IDE interface: Intel Corporation Mobile IDE Controller (rev 03) > (5) If the notebook is in the dock, I press the undock button and wait > for the green led then initiate STR, I can take the notebook out but > resuming doesn't work - unless I resume it while the notebook is back in > the docking station (see point 3a) Magic number: 0:648:888 hash matches drivers/base/power/main.c:103 hash matches device ptyuf hash matches device :00:1f.1 00:1f.1 IDE interface: Intel Corporation Mobile IDE Controller (rev 03) I kindof had suspected that. The docking station has an ultrabay slot where I currently have a cdrom drive (since the notebook itself doesn't have any cdrom drive. Once I took the cdrom drive out, I was able to successfully perform what I wanted to do in points 3a and 5! The 'undock' button probably doesn't tell the kernel that it should unload the cdrom driver. Even though after pressing the undock button the drive becomes unusable (the green led that is on the side of the ultrabay disables and it's impossible to open the tray). Though pressing the undock button causes the usb ports to be removed from the kernel, at least that's what dmesg suggests (I put the notebook into the dock, waited a bit and then pressed the undock button): usb 1-4: new high speed USB device using ehci_hcd and address 11 usb 1-4: configuration #1 chosen from 1 choice hub 1-4:1.0: USB hub found hub 1-4:1.0: 4 ports detected ACPI: \_SB_.GDCK - docking ACPI: \_SB_.GDCK - undocking usb 1-4: USB disconnect, address 11 The notebook+dock+STR works as long as the notebook doesn't know about the ultrabay device. That can be because the notebook was started outside of the docking station, or inside the docking station but with the ultrabay removed. But once the notebook sees the ultrabay device it's over. As little as one suspend/resume cycle inside the docking station and with a ultrabay device plugged in is enough to make the kernel (partially) recognize the device - the kernel doesn't recognize the device as a cdrom drive, but only as an UDMA/33 device. After one suspend/resume cycle I see this in dmesg: ata4.00: ACPI cmd ef/03:45:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04) ata4: failed to recover some devices, retrying in 5 secs Coming out of suspend... [... snip ...] ata4.00: ACPI cmd ef/03:45:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04) ata4.00: ACPI on devcfg failed the second time, disabling (errno=-5) ata4.00: revalidation failed (errno=1) ata4: failed to recover some devices, retrying in 5 secs ata4.00: configured for UDMA/33 And after that I can't resume outside of the docking station. So the description of point 3 was incomplete, sorry about that. At least the two failures 3a and 5 can be explained... tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: laptop reboots right after hibernation
Pavel Machek wrote: > Hi! > >> echo disk > /sys/power/state >> >> successfully saves that state to the disk, but just as the laptop is >> about to turn itself off, it reboots (successfully, so the >> hibernation/resume process works well, even with X running! which is >> awesome :) ). But I'd rather like the computer turned off after I >> hibernate it. Where could the problem be? >> >> It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few >> days, both suspend and hibernate worked there (with one or two crashes, >> probably due to X, I've read that the intel driver got some >> suspend/resume improvements recently). Now I'm running gentoo, kernel >> 2.6.24-rc2. I'm using newer versions of almost all software now compared >> to the ubuntu system. > > If it works in older ubuntu, you can probably do bisect. Does normal > shutdown work? You can try platform vs. shutdown mode... I forgot, normal shutdown (init 0) works, the 'shutdown' command fails somewhere in the gentoo init scripts, but that has nothing to do with the kernel. 'init 6' also works. Both regardless of where the notebook is (dock or outside). tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: laptop reboots right after hibernation
Tomas Carnecky wrote: > Pavel Machek wrote: >> Hi! >> >>> echo disk > /sys/power/state >>> >>> successfully saves that state to the disk, but just as the laptop is >>> about to turn itself off, it reboots (successfully, so the >>> hibernation/resume process works well, even with X running! which is >>> awesome :) ). But I'd rather like the computer turned off after I >>> hibernate it. Where could the problem be? >>> >>> It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few >>> days, both suspend and hibernate worked there (with one or two crashes, >>> probably due to X, I've read that the intel driver got some >>> suspend/resume improvements recently). Now I'm running gentoo, kernel >>> 2.6.24-rc2. I'm using newer versions of almost all software now compared >>> to the ubuntu system. >> If it works in older ubuntu, you can probably do bisect. Does normal >> shutdown work? You can try platform vs. shutdown mode... >> > > I don't have ubuntu anymore, though I'll try if hibernate works with the > livecd. One interesting thing I've found out: hibernate reboots the > laptop _only_ if it is in the docking station. If I hibernate while > outside of the docking station, it properly shuts down the laptop. > > The default mode seems to be 'platform', after I echoed 'shutdown' to > /sys/power/disk the notebook correctly shuts down after hibernation! > > Some interesting facts. All tests were done with 2.6.24-rc2, custom > tailored kernel with just the options needed for my notebook (ThinkPad > X61 Tablet) - without drm modules and bluetooth but with iwl4965 loaded. > All tests were done without X running, from the console. If I say > something 'works' it means I tested it at least three/four times in a > row (if not even more). > > (1) Both STR and STD work correctly if I keep the notebook outside of > the docking station (both in platform and shutdown mode). > > (2) Both STR and STD work correctly if I keep the notebook in the > docking station (both in platform and shutdown mode - with the small > glitch in platform mode that the notebook won't power off after > hibernation). > > (3) Once the notebook was in the docking station (whether I boot it > while in the dock or boot it outside and then put it into the dock) and > I take it out (press the 'undock' button on the dock, wait for the green > led, then take out the notebook) things get interesting: > > (a) I initiate STR, notebook correctly goes to sleep, but it only wakes > up if I have it in the docking station. If I try to wake it up outside > of the docking station it will fail. That fails with a non-blinking cursor in the top left screen, just like in point 3b. > > (b) I initiate STD, and it locks up after a few seconds, at that time > only the cursor in the top left screen is visible (not blinking). If I > put the notebook in its locked up state into the dock, it will reboot > after a few seconds. > > (4) If the notebook is in the dock and I initiate STR and then press the > undock button, it resumes (I assume that is 'working as intended'). > > (5) If the notebook is in the dock, I press the undock button and wait > for the green led then initiate STR, I can take the notebook out but > resuming doesn't work - unless I resume it while the notebook is back in > the docking station (see point 3a) > > (6) If the notebook is in the dock, I press the undock button and wait > for the green led, then initiate STD: > > (a) in platform mode: I can take the notebook out but resuming doesn't > work - unless I resume it while the notebook is back in the docking > station (contrary to point 3b). It seems as the notebook 'locks' itself > into the docking station during STD, I see the green led change into red > during the hibernation process (just before heavy HD activity starts). > > (b) in shutdown mode: STD fails with a completely black screen, not even > the cursor is visible. > > There doesn't seem to be a difference between platform and shutdown mode > other than the reboot glitch when the laptop is in the docking station > or as described in point 6. > > tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: laptop reboots right after hibernation
Pavel Machek wrote: > Hi! > >> echo disk > /sys/power/state >> >> successfully saves that state to the disk, but just as the laptop is >> about to turn itself off, it reboots (successfully, so the >> hibernation/resume process works well, even with X running! which is >> awesome :) ). But I'd rather like the computer turned off after I >> hibernate it. Where could the problem be? >> >> It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few >> days, both suspend and hibernate worked there (with one or two crashes, >> probably due to X, I've read that the intel driver got some >> suspend/resume improvements recently). Now I'm running gentoo, kernel >> 2.6.24-rc2. I'm using newer versions of almost all software now compared >> to the ubuntu system. > > If it works in older ubuntu, you can probably do bisect. Does normal > shutdown work? You can try platform vs. shutdown mode... > I don't have ubuntu anymore, though I'll try if hibernate works with the livecd. One interesting thing I've found out: hibernate reboots the laptop _only_ if it is in the docking station. If I hibernate while outside of the docking station, it properly shuts down the laptop. The default mode seems to be 'platform', after I echoed 'shutdown' to /sys/power/disk the notebook correctly shuts down after hibernation! Some interesting facts. All tests were done with 2.6.24-rc2, custom tailored kernel with just the options needed for my notebook (ThinkPad X61 Tablet) - without drm modules and bluetooth but with iwl4965 loaded. All tests were done without X running, from the console. If I say something 'works' it means I tested it at least three/four times in a row (if not even more). (1) Both STR and STD work correctly if I keep the notebook outside of the docking station (both in platform and shutdown mode). (2) Both STR and STD work correctly if I keep the notebook in the docking station (both in platform and shutdown mode - with the small glitch in platform mode that the notebook won't power off after hibernation). (3) Once the notebook was in the docking station (whether I boot it while in the dock or boot it outside and then put it into the dock) and I take it out (press the 'undock' button on the dock, wait for the green led, then take out the notebook) things get interesting: (a) I initiate STR, notebook correctly goes to sleep, but it only wakes up if I have it in the docking station. If I try to wake it up outside of the docking station it will fail. (b) I initiate STD, and it locks up after a few seconds, at that time only the cursor in the top left screen is visible (not blinking). If I put the notebook in its locked up state into the dock, it will reboot after a few seconds. (4) If the notebook is in the dock and I initiate STR and then press the undock button, it resumes (I assume that is 'working as intended'). (5) If the notebook is in the dock, I press the undock button and wait for the green led then initiate STR, I can take the notebook out but resuming doesn't work - unless I resume it while the notebook is back in the docking station (see point 3a) (6) If the notebook is in the dock, I press the undock button and wait for the green led, then initiate STD: (a) in platform mode: I can take the notebook out but resuming doesn't work - unless I resume it while the notebook is back in the docking station (contrary to point 3b). It seems as the notebook 'locks' itself into the docking station during STD, I see the green led change into red during the hibernation process (just before heavy HD activity starts). (b) in shutdown mode: STD fails with a completely black screen, not even the cursor is visible. There doesn't seem to be a difference between platform and shutdown mode other than the reboot glitch when the laptop is in the docking station or as described in point 6. tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: laptop reboots right after hibernation
Pavel Machek wrote: Hi! echo disk /sys/power/state successfully saves that state to the disk, but just as the laptop is about to turn itself off, it reboots (successfully, so the hibernation/resume process works well, even with X running! which is awesome :) ). But I'd rather like the computer turned off after I hibernate it. Where could the problem be? It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few days, both suspend and hibernate worked there (with one or two crashes, probably due to X, I've read that the intel driver got some suspend/resume improvements recently). Now I'm running gentoo, kernel 2.6.24-rc2. I'm using newer versions of almost all software now compared to the ubuntu system. If it works in older ubuntu, you can probably do bisect. Does normal shutdown work? You can try platform vs. shutdown mode... I don't have ubuntu anymore, though I'll try if hibernate works with the livecd. One interesting thing I've found out: hibernate reboots the laptop _only_ if it is in the docking station. If I hibernate while outside of the docking station, it properly shuts down the laptop. The default mode seems to be 'platform', after I echoed 'shutdown' to /sys/power/disk the notebook correctly shuts down after hibernation! Some interesting facts. All tests were done with 2.6.24-rc2, custom tailored kernel with just the options needed for my notebook (ThinkPad X61 Tablet) - without drm modules and bluetooth but with iwl4965 loaded. All tests were done without X running, from the console. If I say something 'works' it means I tested it at least three/four times in a row (if not even more). (1) Both STR and STD work correctly if I keep the notebook outside of the docking station (both in platform and shutdown mode). (2) Both STR and STD work correctly if I keep the notebook in the docking station (both in platform and shutdown mode - with the small glitch in platform mode that the notebook won't power off after hibernation). (3) Once the notebook was in the docking station (whether I boot it while in the dock or boot it outside and then put it into the dock) and I take it out (press the 'undock' button on the dock, wait for the green led, then take out the notebook) things get interesting: (a) I initiate STR, notebook correctly goes to sleep, but it only wakes up if I have it in the docking station. If I try to wake it up outside of the docking station it will fail. (b) I initiate STD, and it locks up after a few seconds, at that time only the cursor in the top left screen is visible (not blinking). If I put the notebook in its locked up state into the dock, it will reboot after a few seconds. (4) If the notebook is in the dock and I initiate STR and then press the undock button, it resumes (I assume that is 'working as intended'). (5) If the notebook is in the dock, I press the undock button and wait for the green led then initiate STR, I can take the notebook out but resuming doesn't work - unless I resume it while the notebook is back in the docking station (see point 3a) (6) If the notebook is in the dock, I press the undock button and wait for the green led, then initiate STD: (a) in platform mode: I can take the notebook out but resuming doesn't work - unless I resume it while the notebook is back in the docking station (contrary to point 3b). It seems as the notebook 'locks' itself into the docking station during STD, I see the green led change into red during the hibernation process (just before heavy HD activity starts). (b) in shutdown mode: STD fails with a completely black screen, not even the cursor is visible. There doesn't seem to be a difference between platform and shutdown mode other than the reboot glitch when the laptop is in the docking station or as described in point 6. tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: laptop reboots right after hibernation
Tomas Carnecky wrote: Pavel Machek wrote: Hi! echo disk /sys/power/state successfully saves that state to the disk, but just as the laptop is about to turn itself off, it reboots (successfully, so the hibernation/resume process works well, even with X running! which is awesome :) ). But I'd rather like the computer turned off after I hibernate it. Where could the problem be? It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few days, both suspend and hibernate worked there (with one or two crashes, probably due to X, I've read that the intel driver got some suspend/resume improvements recently). Now I'm running gentoo, kernel 2.6.24-rc2. I'm using newer versions of almost all software now compared to the ubuntu system. If it works in older ubuntu, you can probably do bisect. Does normal shutdown work? You can try platform vs. shutdown mode... I don't have ubuntu anymore, though I'll try if hibernate works with the livecd. One interesting thing I've found out: hibernate reboots the laptop _only_ if it is in the docking station. If I hibernate while outside of the docking station, it properly shuts down the laptop. The default mode seems to be 'platform', after I echoed 'shutdown' to /sys/power/disk the notebook correctly shuts down after hibernation! Some interesting facts. All tests were done with 2.6.24-rc2, custom tailored kernel with just the options needed for my notebook (ThinkPad X61 Tablet) - without drm modules and bluetooth but with iwl4965 loaded. All tests were done without X running, from the console. If I say something 'works' it means I tested it at least three/four times in a row (if not even more). (1) Both STR and STD work correctly if I keep the notebook outside of the docking station (both in platform and shutdown mode). (2) Both STR and STD work correctly if I keep the notebook in the docking station (both in platform and shutdown mode - with the small glitch in platform mode that the notebook won't power off after hibernation). (3) Once the notebook was in the docking station (whether I boot it while in the dock or boot it outside and then put it into the dock) and I take it out (press the 'undock' button on the dock, wait for the green led, then take out the notebook) things get interesting: (a) I initiate STR, notebook correctly goes to sleep, but it only wakes up if I have it in the docking station. If I try to wake it up outside of the docking station it will fail. That fails with a non-blinking cursor in the top left screen, just like in point 3b. (b) I initiate STD, and it locks up after a few seconds, at that time only the cursor in the top left screen is visible (not blinking). If I put the notebook in its locked up state into the dock, it will reboot after a few seconds. (4) If the notebook is in the dock and I initiate STR and then press the undock button, it resumes (I assume that is 'working as intended'). (5) If the notebook is in the dock, I press the undock button and wait for the green led then initiate STR, I can take the notebook out but resuming doesn't work - unless I resume it while the notebook is back in the docking station (see point 3a) (6) If the notebook is in the dock, I press the undock button and wait for the green led, then initiate STD: (a) in platform mode: I can take the notebook out but resuming doesn't work - unless I resume it while the notebook is back in the docking station (contrary to point 3b). It seems as the notebook 'locks' itself into the docking station during STD, I see the green led change into red during the hibernation process (just before heavy HD activity starts). (b) in shutdown mode: STD fails with a completely black screen, not even the cursor is visible. There doesn't seem to be a difference between platform and shutdown mode other than the reboot glitch when the laptop is in the docking station or as described in point 6. tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: laptop reboots right after hibernation
Pavel Machek wrote: Hi! echo disk /sys/power/state successfully saves that state to the disk, but just as the laptop is about to turn itself off, it reboots (successfully, so the hibernation/resume process works well, even with X running! which is awesome :) ). But I'd rather like the computer turned off after I hibernate it. Where could the problem be? It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few days, both suspend and hibernate worked there (with one or two crashes, probably due to X, I've read that the intel driver got some suspend/resume improvements recently). Now I'm running gentoo, kernel 2.6.24-rc2. I'm using newer versions of almost all software now compared to the ubuntu system. If it works in older ubuntu, you can probably do bisect. Does normal shutdown work? You can try platform vs. shutdown mode... I forgot, normal shutdown (init 0) works, the 'shutdown' command fails somewhere in the gentoo init scripts, but that has nothing to do with the kernel. 'init 6' also works. Both regardless of where the notebook is (dock or outside). tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: laptop reboots right after hibernation
Since this is becoming more an IDE/ATA issue, I added [EMAIL PROTECTED] to CC. I hope that's the right mailinglist. Tomas Carnecky wrote: (3) Once the notebook was in the docking station (whether I boot it while in the dock or boot it outside and then put it into the dock) and I take it out (press the 'undock' button on the dock, wait for the green led, then take out the notebook) things get interesting: (a) I initiate STR, notebook correctly goes to sleep, but it only wakes up if I have it in the docking station. If I try to wake it up outside of the docking station it will fail. Magic number: 0:971:888 hash matches drivers/base/power/main.c:82 hash matches device ptyuf hash matches device :00:1f.1 00:1f.1 IDE interface: Intel Corporation Mobile IDE Controller (rev 03) (5) If the notebook is in the dock, I press the undock button and wait for the green led then initiate STR, I can take the notebook out but resuming doesn't work - unless I resume it while the notebook is back in the docking station (see point 3a) Magic number: 0:648:888 hash matches drivers/base/power/main.c:103 hash matches device ptyuf hash matches device :00:1f.1 00:1f.1 IDE interface: Intel Corporation Mobile IDE Controller (rev 03) I kindof had suspected that. The docking station has an ultrabay slot where I currently have a cdrom drive (since the notebook itself doesn't have any cdrom drive. Once I took the cdrom drive out, I was able to successfully perform what I wanted to do in points 3a and 5! The 'undock' button probably doesn't tell the kernel that it should unload the cdrom driver. Even though after pressing the undock button the drive becomes unusable (the green led that is on the side of the ultrabay disables and it's impossible to open the tray). Though pressing the undock button causes the usb ports to be removed from the kernel, at least that's what dmesg suggests (I put the notebook into the dock, waited a bit and then pressed the undock button): usb 1-4: new high speed USB device using ehci_hcd and address 11 usb 1-4: configuration #1 chosen from 1 choice hub 1-4:1.0: USB hub found hub 1-4:1.0: 4 ports detected ACPI: \_SB_.GDCK - docking ACPI: \_SB_.GDCK - undocking usb 1-4: USB disconnect, address 11 The notebook+dock+STR works as long as the notebook doesn't know about the ultrabay device. That can be because the notebook was started outside of the docking station, or inside the docking station but with the ultrabay removed. But once the notebook sees the ultrabay device it's over. As little as one suspend/resume cycle inside the docking station and with a ultrabay device plugged in is enough to make the kernel (partially) recognize the device - the kernel doesn't recognize the device as a cdrom drive, but only as an UDMA/33 device. After one suspend/resume cycle I see this in dmesg: ata4.00: ACPI cmd ef/03:45:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04) ata4: failed to recover some devices, retrying in 5 secs Coming out of suspend... [... snip ...] ata4.00: ACPI cmd ef/03:45:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04) ata4.00: ACPI on devcfg failed the second time, disabling (errno=-5) ata4.00: revalidation failed (errno=1) ata4: failed to recover some devices, retrying in 5 secs ata4.00: configured for UDMA/33 And after that I can't resume outside of the docking station. So the description of point 3 was incomplete, sorry about that. At least the two failures 3a and 5 can be explained... tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: statically allocated input_dev
CC: lkml, because that's a question anyone familiar with the driver subsystem can answer. Dmitry Torokhov wrote: > On Nov 15, 2007 9:20 AM, Tomas Carnecky <[EMAIL PROTECTED]> wrote: >> Dmitry Torokhov wrote: >>> No, sorry. Current object lifetime rules require input devices (as >>> well as platform devices) to be dynamically allocated. >>> >> Interesting, especially the 'platform device' bit, because, from >> ./drivers/block/floppy.c: >> >>floppy_device[drive].name = floppy_device_name; >>floppy_device[drive].id = drive; >>floppy_device[drive].dev.release = floppy_device_release; >> >>err = platform_device_register(_device[drive]); >> >> where 'floppy_device' is a static array defined as follows: >> >>static struct platform_device floppy_device[N_DRIVE]; >> >> So is that code incorrect? >> > > I would not look at floopy code when searching for examples ;) > Statically allocating platform devices works, I can register those just fine and I don't see any oops when loading/removing the module. Even though there are no signs of breakage, should I change my code anyway? I'm trying to keep the code as simple as possible. The platform device, platform driver and the input device will live only as long as the module is loaded. There is nothing else that would rely or depend on my driver. Any advices you can give? Or is there nothing that I could use to keep the code simple? tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: statically allocated input_dev
CC: lkml, because that's a question anyone familiar with the driver subsystem can answer. Dmitry Torokhov wrote: On Nov 15, 2007 9:20 AM, Tomas Carnecky [EMAIL PROTECTED] wrote: Dmitry Torokhov wrote: No, sorry. Current object lifetime rules require input devices (as well as platform devices) to be dynamically allocated. Interesting, especially the 'platform device' bit, because, from ./drivers/block/floppy.c: floppy_device[drive].name = floppy_device_name; floppy_device[drive].id = drive; floppy_device[drive].dev.release = floppy_device_release; err = platform_device_register(floppy_device[drive]); where 'floppy_device' is a static array defined as follows: static struct platform_device floppy_device[N_DRIVE]; So is that code incorrect? I would not look at floopy code when searching for examples ;) Statically allocating platform devices works, I can register those just fine and I don't see any oops when loading/removing the module. Even though there are no signs of breakage, should I change my code anyway? I'm trying to keep the code as simple as possible. The platform device, platform driver and the input device will live only as long as the module is loaded. There is nothing else that would rely or depend on my driver. Any advices you can give? Or is there nothing that I could use to keep the code simple? tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
laptop reboots right after hibernation
echo disk > /sys/power/state successfully saves that state to the disk, but just as the laptop is about to turn itself off, it reboots (successfully, so the hibernation/resume process works well, even with X running! which is awesome :) ). But I'd rather like the computer turned off after I hibernate it. Where could the problem be? It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few days, both suspend and hibernate worked there (with one or two crashes, probably due to X, I've read that the intel driver got some suspend/resume improvements recently). Now I'm running gentoo, kernel 2.6.24-rc2. I'm using newer versions of almost all software now compared to the ubuntu system. tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
laptop reboots right after hibernation
echo disk /sys/power/state successfully saves that state to the disk, but just as the laptop is about to turn itself off, it reboots (successfully, so the hibernation/resume process works well, even with X running! which is awesome :) ). But I'd rather like the computer turned off after I hibernate it. Where could the problem be? It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few days, both suspend and hibernate worked there (with one or two crashes, probably due to X, I've read that the intel driver got some suspend/resume improvements recently). Now I'm running gentoo, kernel 2.6.24-rc2. I'm using newer versions of almost all software now compared to the ubuntu system. tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Linus Torvalds wrote: The fact is, I've _always_ considered the desktop to be the most important part. And I suspect that that actually is true for most kernel developers, because quite frankly, that's what 99% of them ends up using. If a kernel developer uses Windows for his day-to-day work, I sure as hell wouldn't want to have him developing Linux. That has nothing to do with anything anti-windows: but the whole "eat your own dogfood" is a very fundamental thing, and somebody who doesn't do that shouldn't be allowed to be even _close_ to a compiler! That comes from someone whose desktop is a dual CPU Mac with how much RAM? 4GB? That can hardly be regarded as the average desktop computer. You cannot have computers with heaps of CPU/RAM and claim that you know how a Linux feels on a 'normal' desktop. That simply doesn't add up. So please stop saying that you're 'eating your own dogfood'. Sure, there may be kernel developers who actually test the kernels on older computers, but don't tell us that you're using those for your daily work. That being said, I can't but agree with Con what he said in his recent interview, namely that some kernel developers are out of touch with the 'normal' desktop users who have a bit slower machines (Linus, if you indeed use a desktop computer like I described above then this also applies to you). And I can't imagine that any of you have done such intensive tests of desktop responsiveness etc. like Con did. By all means I'm not a 'Con Fanboy', nor want I be involved in the whole 'CFS vs. CD' flamewar, but I simply can't let your statement leave unanswered. tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
Linus Torvalds wrote: The fact is, I've _always_ considered the desktop to be the most important part. And I suspect that that actually is true for most kernel developers, because quite frankly, that's what 99% of them ends up using. If a kernel developer uses Windows for his day-to-day work, I sure as hell wouldn't want to have him developing Linux. That has nothing to do with anything anti-windows: but the whole eat your own dogfood is a very fundamental thing, and somebody who doesn't do that shouldn't be allowed to be even _close_ to a compiler! That comes from someone whose desktop is a dual CPU Mac with how much RAM? 4GB? That can hardly be regarded as the average desktop computer. You cannot have computers with heaps of CPU/RAM and claim that you know how a Linux feels on a 'normal' desktop. That simply doesn't add up. So please stop saying that you're 'eating your own dogfood'. Sure, there may be kernel developers who actually test the kernels on older computers, but don't tell us that you're using those for your daily work. That being said, I can't but agree with Con what he said in his recent interview, namely that some kernel developers are out of touch with the 'normal' desktop users who have a bit slower machines (Linus, if you indeed use a desktop computer like I described above then this also applies to you). And I can't imagine that any of you have done such intensive tests of desktop responsiveness etc. like Con did. By all means I'm not a 'Con Fanboy', nor want I be involved in the whole 'CFS vs. CD' flamewar, but I simply can't let your statement leave unanswered. tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG: at mm/slab.c:777 __find_general_cachep()
Kernel 2.6.22-rc2-g47b97135, happened while running wine (32bit app) on my amd64 box... should I try -rc3? BUG: at mm/slab.c:777 __find_general_cachep() Call Trace: [] __kmalloc+0xa6/0xe0 [] compat_core_sys_select+0x109/0x290 [] compat_sys_select+0xe1/0x190 [] cstar_do_call+0x1b/0x65 tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG: at mm/slab.c:777 __find_general_cachep()
Kernel 2.6.22-rc2-g47b97135, happened while running wine (32bit app) on my amd64 box... should I try -rc3? BUG: at mm/slab.c:777 __find_general_cachep() Call Trace: [80278146] __kmalloc+0xa6/0xe0 [802ac959] compat_core_sys_select+0x109/0x290 [802ae3f1] compat_sys_select+0xe1/0x190 [8021e124] cstar_do_call+0x1b/0x65 tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SideWinder GameVoice driver
Jiri Kosina wrote:
> On Sat, 19 May 2007, Tomas Carnecky wrote:
>> I already thought about this option (to whitelist this particular
>> vendor/device ID as an hid-input device), but I first wanted some
>> feedback on the whole situation. As for the patch, I have zero knowledge
>> of the hid subsystem.. but if you give me a go on this, I'll try to dig
>> into the code and make a patch :)
>
> Adding a HID_QUIRK_HIDINPUT quirk makes maybe a more sense than fixing
> this particular report descriptor to stop pretending that the device is
> Telephony/Headset - we might in future discover that there are more
> devices that have broken report descriptors and that we want to be forced
> to be handled by hid-input subsystem.
>
> So, could you please test whether the quick and untested patch below
> (against 2.6.22-rc1) works as expected with the device?
Applied to -rc1, rebased to -rc2, works as expected. Thanks.
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 7f81789..8696dbe 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -976,7 +976,7 @@ int hidinput_connect(struct hid_device *
> if (IS_INPUT_APPLICATION(hid->collection[i].usage))
> break;
>
> - if (i == hid->maxcollection)
> + if (i == hid->maxcollection && (hid->quirks & HID_QUIRK_HIDINPUT) == 0)
> return -1;
>
> if (hid->quirks & HID_QUIRK_SKIP_OUTPUT_REPORTS)
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
> index f6c4145..62a7f1e 100644
> --- a/drivers/hid/usbhid/hid-quirks.c
> +++ b/drivers/hid/usbhid/hid-quirks.c
> @@ -209,6 +209,9 @@
> #define USB_DEVICE_ID_MGE_UPS0x
> #define USB_DEVICE_ID_MGE_UPS1 0x0001
>
> +#define USB_VENDOR_ID_MICROSOFT 0x045e
> +#define USB_DEVICE_ID_SIDEWINDER_GV 0x003b
> +
> #define USB_VENDOR_ID_NEC0x073e
> #define USB_DEVICE_ID_NEC_USB_GAME_PAD 0x0301
>
> @@ -290,6 +293,7 @@ static const struct hid_blacklist {
> { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_DINOVO_EDGE,
> HID_QUIRK_DUPLICATE_USAGES },
>
> { USB_VENDOR_ID_BELKIN, USB_DEVICE_ID_FLIP_KVM, HID_QUIRK_HIDDEV },
> + { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_SIDEWINDER_GV,
> HID_QUIRK_HIDINPUT },
>
> { USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_01, HID_QUIRK_IGNORE },
> { USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_10, HID_QUIRK_IGNORE },
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index 827ee74..6e45d10 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -276,6 +276,7 @@ struct hid_item {
> #define HID_QUIRK_DUPLICATE_USAGES 0x0020
> #define HID_QUIRK_RESET_LEDS 0x0040
> #define HID_QUIRK_SWAPPED_MIN_MAX0x0080
> +#define HID_QUIRK_HIDINPUT 0x0100
>
> /*
> * This is the global environment of the parser. This information is
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SideWinder GameVoice driver
Jiri Kosina wrote: > On Fri, 18 May 2007, Lee Revell wrote: > >>> Despite it's a Microsoft product, it's actually very nice and useful. A >>> little pad with a few buttons and connectors for a headset. It's an USB >>> device, but it doesn't represent itself as an input/HID device: >>>HID device not claimed by input or hiddev >> Is the audio part of the device USB audio class compliant? > > Seems like the device is a bit strange - it in fact, as far as my > understanding goes (see the previous posts in this thread), doesn't have > any noticeable USB audio capabilities at all - it is just a HID device > with a few buttons (plus additional audio connector, which only "forwards" > the sound to a real audio device). Exactly, it isn't a 'sound' device at all. It has a USB plug and plain old headset/microphone cables which have to be put into the soundcard. The pad itself has connectors for the headset/microphone, but those are simply forwarded to the soundcard (there's the 'mute' button which can be used to mute the microphone, and a volume wheel, but that's all it can do with the sound). > > So it's just a trivial HID device with probably a bit strange report > descriptor, it seems to me. It even has only one interface (the HID one). > Someone at Microsoft probably thought, Hey, there's this Telephony/Headset category, why not use that? tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SideWinder GameVoice driver
Jiri Kosina wrote: On Fri, 18 May 2007, Lee Revell wrote: Despite it's a Microsoft product, it's actually very nice and useful. A little pad with a few buttons and connectors for a headset. It's an USB device, but it doesn't represent itself as an input/HID device: HID device not claimed by input or hiddev Is the audio part of the device USB audio class compliant? Seems like the device is a bit strange - it in fact, as far as my understanding goes (see the previous posts in this thread), doesn't have any noticeable USB audio capabilities at all - it is just a HID device with a few buttons (plus additional audio connector, which only forwards the sound to a real audio device). Exactly, it isn't a 'sound' device at all. It has a USB plug and plain old headset/microphone cables which have to be put into the soundcard. The pad itself has connectors for the headset/microphone, but those are simply forwarded to the soundcard (there's the 'mute' button which can be used to mute the microphone, and a volume wheel, but that's all it can do with the sound). So it's just a trivial HID device with probably a bit strange report descriptor, it seems to me. It even has only one interface (the HID one). Someone at Microsoft probably thought, Hey, there's this Telephony/Headset category, why not use that? tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SideWinder GameVoice driver
Jiri Kosina wrote:
On Sat, 19 May 2007, Tomas Carnecky wrote:
I already thought about this option (to whitelist this particular
vendor/device ID as an hid-input device), but I first wanted some
feedback on the whole situation. As for the patch, I have zero knowledge
of the hid subsystem.. but if you give me a go on this, I'll try to dig
into the code and make a patch :)
Adding a HID_QUIRK_HIDINPUT quirk makes maybe a more sense than fixing
this particular report descriptor to stop pretending that the device is
Telephony/Headset - we might in future discover that there are more
devices that have broken report descriptors and that we want to be forced
to be handled by hid-input subsystem.
So, could you please test whether the quick and untested patch below
(against 2.6.22-rc1) works as expected with the device?
Applied to -rc1, rebased to -rc2, works as expected. Thanks.
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 7f81789..8696dbe 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -976,7 +976,7 @@ int hidinput_connect(struct hid_device *
if (IS_INPUT_APPLICATION(hid-collection[i].usage))
break;
- if (i == hid-maxcollection)
+ if (i == hid-maxcollection (hid-quirks HID_QUIRK_HIDINPUT) == 0)
return -1;
if (hid-quirks HID_QUIRK_SKIP_OUTPUT_REPORTS)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index f6c4145..62a7f1e 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -209,6 +209,9 @@
#define USB_DEVICE_ID_MGE_UPS0x
#define USB_DEVICE_ID_MGE_UPS1 0x0001
+#define USB_VENDOR_ID_MICROSOFT 0x045e
+#define USB_DEVICE_ID_SIDEWINDER_GV 0x003b
+
#define USB_VENDOR_ID_NEC0x073e
#define USB_DEVICE_ID_NEC_USB_GAME_PAD 0x0301
@@ -290,6 +293,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_DINOVO_EDGE,
HID_QUIRK_DUPLICATE_USAGES },
{ USB_VENDOR_ID_BELKIN, USB_DEVICE_ID_FLIP_KVM, HID_QUIRK_HIDDEV },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_SIDEWINDER_GV,
HID_QUIRK_HIDINPUT },
{ USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_01, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_10, HID_QUIRK_IGNORE },
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 827ee74..6e45d10 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -276,6 +276,7 @@ struct hid_item {
#define HID_QUIRK_DUPLICATE_USAGES 0x0020
#define HID_QUIRK_RESET_LEDS 0x0040
#define HID_QUIRK_SWAPPED_MIN_MAX0x0080
+#define HID_QUIRK_HIDINPUT 0x0100
/*
* This is the global environment of the parser. This information is
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SideWinder GameVoice driver
Jiri Kosina wrote: > On Fri, 18 May 2007, Tomas Carnecky wrote: >> GameVoice is used for VoIP communication between players. It consists of >> a software and the small pad with eight buttons and connectors for the >> headset. One of the buttons can be used to mute the microphone, the >> others are labeled '1' - '4', 'TEAM', 'ALL' and 'COMMAND'. The idea is >> that you can have up to four 'groups' of players and communicate only to >> certain groups by 'activating' the buttons, you can also speak to your >> whole team or all players. The command button is used for voice commands >> (for example, you press the button, say 'throw grenade' and the software >> translates it to a predefined key sequence). That's more or less how >> it's supposed to work. > > But all this is handled actually by userspace applications, right? Or do > you want this whole functionality to go into a specialized kernel driver? > Or does this require some interaction/processing between hardware and the > driver? There's no further processing needed in the kernel. The userspace application would receive these input events and act accordingly, like: read data from the soundcard and send it to the VoIP server, or only certain channels based on which buttons are currently pressed etc. > Well, if the only purpose of this device is to pass status of pressed > buttons into userspace driver (which is the case, as far as I understand > it), it's just broken that it has 05 0b (i.e. Telephony/Headset) in its > report descriptor. > > Either fixing the report descriptor on the fly or adding a special quirk > to force hid-input to claim the device would be needed. Would you care to > create such patch? I already thought about this option (to whitelist this particular vendor/device ID as an hid-input device), but I first wanted some feedback on the whole situation. As for the patch, I have zero knowledge of the hid subsystem.. but if you give me a go on this, I'll try to dig into the code and make a patch :) > Or did I just get it wrong and the device has also other purposes that > should be handled by the kernel driver, than just trivial mapping of a few > buttons into corresponding input events? This pad has no other purposes than just having eight buttons. Mapping these buttons into input events is all that is needed to make a useful userspace application for it. Considering how many users actually have this device and try to get it working under Linux (probably only me), I wouldn't be mad if you rejected a patch. I don't even know if I will ever write an userspace application for it! But, I have this device lying around on my table and in my old Windows days it was quite useful, so I'd like to share my findings with others. tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SideWinder GameVoice driver
Jiri Kosina wrote: > We don't want neither the 'Telephony' nor 'LEDs' usages to be claimed by > the hid-input system, that seems to make a little sense. I changed the IS_INPUT_APPLICATION() macro to accept 'Telephony/Headset' and now the kernel has created a new event device node for the device and it correctly generates evdev events if I press the keys on the pad. (The LEDs can't be controlled, they light up if a key is pressed, they are 'passive' from the POV of the kernel). So right now, I couldn't be happier with how it works :) > > So either the device is bogus and has broken report descriptor (which we > could fix in runtime), or it really can't be handled by hid-input (I have > no idea about the purpose and internal working of the device in question, > sorry). GameVoice is used for VoIP communication between players. It consists of a software and the small pad with eight buttons and connectors for the headset. One of the buttons can be used to mute the microphone, the others are labeled '1' - '4', 'TEAM', 'ALL' and 'COMMAND'. The idea is that you can have up to four 'groups' of players and communicate only to certain groups by 'activating' the buttons, you can also speak to your whole team or all players. The command button is used for voice commands (for example, you press the button, say 'throw grenade' and the software translates it to a predefined key sequence). That's more or less how it's supposed to work. Google gives you lots of images if you search for 'gamevoice': http://pcdreitz.wintotal-forum.de/pys/gamevoice.jpg > > Either we can fix the hiddev_connect() so that the device would be claimed > by hiddev (*) and you can write the driver for this device easily in > userland, or you could try to write generic in-kernel hid-telephony.c > handler of all telephony devices (but I doubt this is doable in a > reasonable way). I'd much rather have this handled by hid-input, there's no reason to have an additional driver (neither in the kernel nor in userland). It 'just works' with hid-input. tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SideWinder GameVoice driver
Jiri Kosina wrote: We don't want neither the 'Telephony' nor 'LEDs' usages to be claimed by the hid-input system, that seems to make a little sense. I changed the IS_INPUT_APPLICATION() macro to accept 'Telephony/Headset' and now the kernel has created a new event device node for the device and it correctly generates evdev events if I press the keys on the pad. (The LEDs can't be controlled, they light up if a key is pressed, they are 'passive' from the POV of the kernel). So right now, I couldn't be happier with how it works :) So either the device is bogus and has broken report descriptor (which we could fix in runtime), or it really can't be handled by hid-input (I have no idea about the purpose and internal working of the device in question, sorry). GameVoice is used for VoIP communication between players. It consists of a software and the small pad with eight buttons and connectors for the headset. One of the buttons can be used to mute the microphone, the others are labeled '1' - '4', 'TEAM', 'ALL' and 'COMMAND'. The idea is that you can have up to four 'groups' of players and communicate only to certain groups by 'activating' the buttons, you can also speak to your whole team or all players. The command button is used for voice commands (for example, you press the button, say 'throw grenade' and the software translates it to a predefined key sequence). That's more or less how it's supposed to work. Google gives you lots of images if you search for 'gamevoice': http://pcdreitz.wintotal-forum.de/pys/gamevoice.jpg Either we can fix the hiddev_connect() so that the device would be claimed by hiddev (*) and you can write the driver for this device easily in userland, or you could try to write generic in-kernel hid-telephony.c handler of all telephony devices (but I doubt this is doable in a reasonable way). I'd much rather have this handled by hid-input, there's no reason to have an additional driver (neither in the kernel nor in userland). It 'just works' with hid-input. tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SideWinder GameVoice driver
Jiri Kosina wrote: On Fri, 18 May 2007, Tomas Carnecky wrote: GameVoice is used for VoIP communication between players. It consists of a software and the small pad with eight buttons and connectors for the headset. One of the buttons can be used to mute the microphone, the others are labeled '1' - '4', 'TEAM', 'ALL' and 'COMMAND'. The idea is that you can have up to four 'groups' of players and communicate only to certain groups by 'activating' the buttons, you can also speak to your whole team or all players. The command button is used for voice commands (for example, you press the button, say 'throw grenade' and the software translates it to a predefined key sequence). That's more or less how it's supposed to work. But all this is handled actually by userspace applications, right? Or do you want this whole functionality to go into a specialized kernel driver? Or does this require some interaction/processing between hardware and the driver? There's no further processing needed in the kernel. The userspace application would receive these input events and act accordingly, like: read data from the soundcard and send it to the VoIP server, or only certain channels based on which buttons are currently pressed etc. Well, if the only purpose of this device is to pass status of pressed buttons into userspace driver (which is the case, as far as I understand it), it's just broken that it has 05 0b (i.e. Telephony/Headset) in its report descriptor. Either fixing the report descriptor on the fly or adding a special quirk to force hid-input to claim the device would be needed. Would you care to create such patch? I already thought about this option (to whitelist this particular vendor/device ID as an hid-input device), but I first wanted some feedback on the whole situation. As for the patch, I have zero knowledge of the hid subsystem.. but if you give me a go on this, I'll try to dig into the code and make a patch :) Or did I just get it wrong and the device has also other purposes that should be handled by the kernel driver, than just trivial mapping of a few buttons into corresponding input events? This pad has no other purposes than just having eight buttons. Mapping these buttons into input events is all that is needed to make a useful userspace application for it. Considering how many users actually have this device and try to get it working under Linux (probably only me), I wouldn't be mad if you rejected a patch. I don't even know if I will ever write an userspace application for it! But, I have this device lying around on my table and in my old Windows days it was quite useful, so I'd like to share my findings with others. tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SideWinder GameVoice driver
Additional info: HID device has two collections (whatever those are, I have _no_ idea): collection 00: type: 1, usage: 000b0005, level: collection 01: type: 2, usage: 0008003a, level: 0001 The usage of the first one means 'Telephony/Headset', the second one 'LEDs/Usage Selected Indicator' (IDs taken from [1]). The culprit is the IS_INPUT_APPLICATION() macro, which only accepts certain 'usage' types. Should it also accept this particular one, too, or even the whole 'Telephony' group? Or maybe add a (configurable) 'quirk' to enable the GameVoice device? tom [1] http://www.freebsddiary.org/APC/usb_hid_usages.php - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SideWinder GameVoice driver
Jiri Kosina wrote: > On Thu, 17 May 2007, Tomas Carnecky wrote: > >> Despite it's a Microsoft product, it's actually very nice and useful. A >> little pad with a few buttons and connectors for a headset. It's an USB >> device, but it doesn't represent itself as an input/HID device: >>HID device not claimed by input or hiddev > > Could you please > > - compile the kernel with CONFIG_HID_DEBUG and send me the output you > receive when you connect the device usb 2-5: new low speed USB device using ohci_hcd and address 4 usb 2-5: configuration #1 chosen from 1 choice drivers/hid/usbhid/hid-core.c: report descriptor (size 61, read 61) = 05 0b 09 05 a1 01 05 09 19 11 29 18 15 00 25 01 75 01 95 08 81 22 05 08 09 3a a1 02 05 09 19 11 29 17 15 00 25 01 75 01 95 07 b1 a2 c0 06 ff ff 09 01 15 00 25 01 75 01 95 01 b1 22 c0 drivers/hid/hid-core.c: report (size 1) (unnumbered) drivers/hid/hid-core.c: report 0 (size 1) = 00 hid-debug: input Button.0011 = 0 hid-debug: input Button.0012 = 0 hid-debug: input Button.0013 = 0 hid-debug: input Button.0014 = 0 hid-debug: input Button.0015 = 0 hid-debug: input Button.0016 = 0 hid-debug: input Button.0017 = 0 hid-debug: input Button.0018 = 0 drivers/hid/hid-core.c: report (size 1) (unnumbered) drivers/hid/hid-core.c: report 0 (size 1) = 00 hid-debug: input Button.0011 = 0 hid-debug: input Button.0012 = 0 hid-debug: input Button.0013 = 0 hid-debug: input Button.0014 = 0 hid-debug: input Button.0015 = 0 hid-debug: input Button.0016 = 0 hid-debug: input Button.0017 = 0 hid-debug: input Vendor-specific-FF.0001 = 0 INPUT[INPUT] Field(0) Usage(8) Button.0011 Button.0012 Button.0013 Button.0014 Button.0015 Button.0016 Button.0017 Button.0018 Logical Minimum(0) Logical Maximum(1) Report Size(1) Report Count(8) Report Offset(0) Flags( Variable Absolute NoPrefferedState ) FEATURE[FEATURE] Field(0) Logical(LED.003a) Usage(7) Button.0011 Button.0012 Button.0013 Button.0014 Button.0015 Button.0016 Button.0017 Logical Minimum(0) Logical Maximum(1) Report Size(1) Report Count(7) Report Offset(0) Flags( Variable Absolute NoPrefferedState Volatile ) Field(1) Usage(1) Vendor-specific-FF.0001 Logical Minimum(0) Logical Maximum(1) Report Size(1) Report Count(1) Report Offset(7) Flags( Variable Absolute NoPrefferedState ) HID device not claimed by input or hiddev - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SideWinder GameVoice driver
Despite it's a Microsoft product, it's actually very nice and useful. A little pad with a few buttons and connectors for a headset. It's an USB device, but it doesn't represent itself as an input/HID device: HID device not claimed by input or hiddev I plugged it into a windows box and the USB protocol it uses looks very simple (see attachment): everytime I press one of the eight buttons, it sends one byte, a bitmap of the pressed buttons. What would be the best way to have this device appear in the system? Having a separate driver/device node? Or is it possible to have a small driver that would translate the gamevoice commands into evdev messages and have a new /dev/input/eventX device appear? I could write something like that myself, my C skills are good enough for that, I'd just need some advice how to use the kernel USB/evdev interfaces. tom [883650 ms] UsbSnoop - MyDispatchInternalIOCTL(f56b8e80) : fdo=82adb998, Irp=848e0008, IRQL=2 [883650 ms] >>> URB 68 going down >>> -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER: PipeHandle = 83a38fdc [endpoint 0x0081] TransferFlags= 0003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK) TransferBufferLength = 0001 TransferBuffer = 857fc078 TransferBufferMDL= UrbLink = [883970 ms] UsbSnoop - MyInternalIOCTLCompletion(f56b8db0) : fido=848db578, Irp=82ae9a78, Context=855c96d0, IRQL=2 [883970 ms] <<< URB 67 coming back <<< -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER: PipeHandle = 83a38fdc [endpoint 0x0081] TransferFlags= 0003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK) TransferBufferLength = 0001 TransferBuffer = 85768370 TransferBufferMDL= 831f13d8 : 0c UrbLink = [883970 ms] UsbSnoop - DispatchAny(f56b7610) : IRP_MJ_INTERNAL_DEVICE_CONTROL [883970 ms] UsbSnoop - MyDispatchInternalIOCTL(f56b8e80) : fdo=82adb998, Irp=82ae9a78, IRQL=2 [883970 ms] >>> URB 69 going down >>> -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER: PipeHandle = 83a38fdc [endpoint 0x0081] TransferFlags= 0003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK) TransferBufferLength = 0001 TransferBuffer = 85768370 TransferBufferMDL= UrbLink =
SideWinder GameVoice driver
Despite it's a Microsoft product, it's actually very nice and useful. A little pad with a few buttons and connectors for a headset. It's an USB device, but it doesn't represent itself as an input/HID device: HID device not claimed by input or hiddev I plugged it into a windows box and the USB protocol it uses looks very simple (see attachment): everytime I press one of the eight buttons, it sends one byte, a bitmap of the pressed buttons. What would be the best way to have this device appear in the system? Having a separate driver/device node? Or is it possible to have a small driver that would translate the gamevoice commands into evdev messages and have a new /dev/input/eventX device appear? I could write something like that myself, my C skills are good enough for that, I'd just need some advice how to use the kernel USB/evdev interfaces. tom [883650 ms] UsbSnoop - MyDispatchInternalIOCTL(f56b8e80) : fdo=82adb998, Irp=848e0008, IRQL=2 [883650 ms]URB 68 going down -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER: PipeHandle = 83a38fdc [endpoint 0x0081] TransferFlags= 0003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK) TransferBufferLength = 0001 TransferBuffer = 857fc078 TransferBufferMDL= UrbLink = [883970 ms] UsbSnoop - MyInternalIOCTLCompletion(f56b8db0) : fido=848db578, Irp=82ae9a78, Context=855c96d0, IRQL=2 [883970 ms]URB 67 coming back -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER: PipeHandle = 83a38fdc [endpoint 0x0081] TransferFlags= 0003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK) TransferBufferLength = 0001 TransferBuffer = 85768370 TransferBufferMDL= 831f13d8 : 0c UrbLink = [883970 ms] UsbSnoop - DispatchAny(f56b7610) : IRP_MJ_INTERNAL_DEVICE_CONTROL [883970 ms] UsbSnoop - MyDispatchInternalIOCTL(f56b8e80) : fdo=82adb998, Irp=82ae9a78, IRQL=2 [883970 ms]URB 69 going down -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER: PipeHandle = 83a38fdc [endpoint 0x0081] TransferFlags= 0003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK) TransferBufferLength = 0001 TransferBuffer = 85768370 TransferBufferMDL= UrbLink =
Re: SideWinder GameVoice driver
Jiri Kosina wrote: On Thu, 17 May 2007, Tomas Carnecky wrote: Despite it's a Microsoft product, it's actually very nice and useful. A little pad with a few buttons and connectors for a headset. It's an USB device, but it doesn't represent itself as an input/HID device: HID device not claimed by input or hiddev Could you please - compile the kernel with CONFIG_HID_DEBUG and send me the output you receive when you connect the device usb 2-5: new low speed USB device using ohci_hcd and address 4 usb 2-5: configuration #1 chosen from 1 choice drivers/hid/usbhid/hid-core.c: report descriptor (size 61, read 61) = 05 0b 09 05 a1 01 05 09 19 11 29 18 15 00 25 01 75 01 95 08 81 22 05 08 09 3a a1 02 05 09 19 11 29 17 15 00 25 01 75 01 95 07 b1 a2 c0 06 ff ff 09 01 15 00 25 01 75 01 95 01 b1 22 c0 drivers/hid/hid-core.c: report (size 1) (unnumbered) drivers/hid/hid-core.c: report 0 (size 1) = 00 hid-debug: input Button.0011 = 0 hid-debug: input Button.0012 = 0 hid-debug: input Button.0013 = 0 hid-debug: input Button.0014 = 0 hid-debug: input Button.0015 = 0 hid-debug: input Button.0016 = 0 hid-debug: input Button.0017 = 0 hid-debug: input Button.0018 = 0 drivers/hid/hid-core.c: report (size 1) (unnumbered) drivers/hid/hid-core.c: report 0 (size 1) = 00 hid-debug: input Button.0011 = 0 hid-debug: input Button.0012 = 0 hid-debug: input Button.0013 = 0 hid-debug: input Button.0014 = 0 hid-debug: input Button.0015 = 0 hid-debug: input Button.0016 = 0 hid-debug: input Button.0017 = 0 hid-debug: input Vendor-specific-FF.0001 = 0 INPUT[INPUT] Field(0) Usage(8) Button.0011 Button.0012 Button.0013 Button.0014 Button.0015 Button.0016 Button.0017 Button.0018 Logical Minimum(0) Logical Maximum(1) Report Size(1) Report Count(8) Report Offset(0) Flags( Variable Absolute NoPrefferedState ) FEATURE[FEATURE] Field(0) Logical(LED.003a) Usage(7) Button.0011 Button.0012 Button.0013 Button.0014 Button.0015 Button.0016 Button.0017 Logical Minimum(0) Logical Maximum(1) Report Size(1) Report Count(7) Report Offset(0) Flags( Variable Absolute NoPrefferedState Volatile ) Field(1) Usage(1) Vendor-specific-FF.0001 Logical Minimum(0) Logical Maximum(1) Report Size(1) Report Count(1) Report Offset(7) Flags( Variable Absolute NoPrefferedState ) HID device not claimed by input or hiddev - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SideWinder GameVoice driver
Additional info: HID device has two collections (whatever those are, I have _no_ idea): collection 00: type: 1, usage: 000b0005, level: collection 01: type: 2, usage: 0008003a, level: 0001 The usage of the first one means 'Telephony/Headset', the second one 'LEDs/Usage Selected Indicator' (IDs taken from [1]). The culprit is the IS_INPUT_APPLICATION() macro, which only accepts certain 'usage' types. Should it also accept this particular one, too, or even the whole 'Telephony' group? Or maybe add a (configurable) 'quirk' to enable the GameVoice device? tom [1] http://www.freebsddiary.org/APC/usb_hid_usages.php - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 SATA error
Ralf Müller wrote: I had the same type of problem using an unstable power supply - after replacing it the problems were gone ... Hm.. my shuttle box has only a 350W power supply, that could indeed be the problem, as I have an Athlon 64 X2 4400+ CPU (dual core), two SATA-II 500GB harddrives and a GeForce 7800GTX. Damn.. I thought I payed attention to the power supply when I bought the components for my computer :( tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 SATA error
Gerhard Mack wrote: ata1.00: configured for UDMA/100 [...] ata1.00: configured for UDMA/66 [...] ata1.00: configured for UDMA/44 [...] ata1.00: configured for UDMA/33 [...] ata1.00: configured for UDMA/25 [...] ata1.00: configured for UDMA/16 [...] ata1.00: configured for PIO4 I have the same problem, though it appears randomly. It seems like the chances for this happening are bigger if I do heavy disk I/O. The only way to fix that is to shut down the computer and wait a few seconds before rebooting (if I don't wait, the problem doesn't go away). I bought new harddrives, so it's most likely not caused by the drives, I also tried putting the drives onto a different controller (I have four on-board SATA controller and two harddrives), that didn't help either, so I suspect its the cable - SATA cables are very error-prone, I don't trust them as they don't hold that tightly in the socket. tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 SATA error
Gerhard Mack wrote: ata1.00: configured for UDMA/100 [...] ata1.00: configured for UDMA/66 [...] ata1.00: configured for UDMA/44 [...] ata1.00: configured for UDMA/33 [...] ata1.00: configured for UDMA/25 [...] ata1.00: configured for UDMA/16 [...] ata1.00: configured for PIO4 I have the same problem, though it appears randomly. It seems like the chances for this happening are bigger if I do heavy disk I/O. The only way to fix that is to shut down the computer and wait a few seconds before rebooting (if I don't wait, the problem doesn't go away). I bought new harddrives, so it's most likely not caused by the drives, I also tried putting the drives onto a different controller (I have four on-board SATA controller and two harddrives), that didn't help either, so I suspect its the cable - SATA cables are very error-prone, I don't trust them as they don't hold that tightly in the socket. tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 SATA error
Ralf Müller wrote: I had the same type of problem using an unstable power supply - after replacing it the problems were gone ... Hm.. my shuttle box has only a 350W power supply, that could indeed be the problem, as I have an Athlon 64 X2 4400+ CPU (dual core), two SATA-II 500GB harddrives and a GeForce 7800GTX. Damn.. I thought I payed attention to the power supply when I bought the components for my computer :( tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Ban module license tag string termination trick
Jon Masters wrote: > need a technological mechanism here to enforce the obvious. To me, it > just seems totally obvious (any legal comment?) that early C string > termination is undermining the intent of the MODULE_LICENSE tag. > I completely agree with that. It's like I sign a contract and the other party later makes claims and says: Well, you sure you read the whole contract? 'Coz in the part that was written with special ink, only visible under special light, it clearly states that ... Can't you put this somewhere into the documentation: it's our kernel, play by our rules, and our rules are, the license is what is visible in 'printf(license)'? tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Ban module license tag string termination trick
Jon Masters wrote: need a technological mechanism here to enforce the obvious. To me, it just seems totally obvious (any legal comment?) that early C string termination is undermining the intent of the MODULE_LICENSE tag. I completely agree with that. It's like I sign a contract and the other party later makes claims and says: Well, you sure you read the whole contract? 'Coz in the part that was written with special ink, only visible under special light, it clearly states that ... Can't you put this somewhere into the documentation: it's our kernel, play by our rules, and our rules are, the license is what is visible in 'printf(license)'? tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 03/26] Dynamic kernel command-line - arm
Russell King wrote: > On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote: >> -static char command_line[COMMAND_LINE_SIZE]; >> +static char __initdata command_line[COMMAND_LINE_SIZE]; > > Uninitialised data is placed in the BSS. Adding __initdata to BSS > data causes grief. > Static variables are implicitly initialized to zero. Does that also count as initialization? tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 03/26] Dynamic kernel command-line - arm
Russell King wrote: On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote: -static char command_line[COMMAND_LINE_SIZE]; +static char __initdata command_line[COMMAND_LINE_SIZE]; Uninitialised data is placed in the BSS. Adding __initdata to BSS data causes grief. Static variables are implicitly initialized to zero. Does that also count as initialization? tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oprofile broken on 2.6.19
Eric Dumazet wrote: > On Thursday 11 January 2007 15:37, Tomas Carnecky wrote: >> Gert Vervoort wrote: >>> Tomas Carnecky wrote: >>>> Gert Vervoort wrote: >>>>> When I try to use oprofile on 2.6.19, it does not seem to work: >>>> http://lkml.org/lkml/2006/11/22/172 >>> Disabling the nmi watchdog, as suggested in: >>> http://marc.theaimsgroup.com/?l=oprofile-list=116422889324043=2, >>> also makes oprofile work again. >> Oh.. that seem to be much easier then compiling a patched oprofile :) >> However, I can't find any NMI option (grep NMI .config), and >> CONFIG_WATCHDOG is disabled here. > > Sure, but did you tried to boot with 'nmi_watchdog=0' appended in your boot > params ? No, I assumed since I don't have any watchdog, I wouldn't have the NMI thing either... these silly assumptions. tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oprofile broken on 2.6.19
Gert Vervoort wrote: > Tomas Carnecky wrote: >> Gert Vervoort wrote: >>> When I try to use oprofile on 2.6.19, it does not seem to work: >>> >> http://lkml.org/lkml/2006/11/22/172 >> > Disabling the nmi watchdog, as suggested in: > http://marc.theaimsgroup.com/?l=oprofile-list=116422889324043=2, > also makes oprofile work again. > Oh.. that seem to be much easier then compiling a patched oprofile :) However, I can't find any NMI option (grep NMI .config), and CONFIG_WATCHDOG is disabled here. tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oprofile broken on 2.6.19
Gert Vervoort wrote: Tomas Carnecky wrote: Gert Vervoort wrote: When I try to use oprofile on 2.6.19, it does not seem to work: http://lkml.org/lkml/2006/11/22/172 Disabling the nmi watchdog, as suggested in: http://marc.theaimsgroup.com/?l=oprofile-listm=116422889324043w=2, also makes oprofile work again. Oh.. that seem to be much easier then compiling a patched oprofile :) However, I can't find any NMI option (grep NMI .config), and CONFIG_WATCHDOG is disabled here. tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oprofile broken on 2.6.19
Eric Dumazet wrote: On Thursday 11 January 2007 15:37, Tomas Carnecky wrote: Gert Vervoort wrote: Tomas Carnecky wrote: Gert Vervoort wrote: When I try to use oprofile on 2.6.19, it does not seem to work: http://lkml.org/lkml/2006/11/22/172 Disabling the nmi watchdog, as suggested in: http://marc.theaimsgroup.com/?l=oprofile-listm=116422889324043w=2, also makes oprofile work again. Oh.. that seem to be much easier then compiling a patched oprofile :) However, I can't find any NMI option (grep NMI .config), and CONFIG_WATCHDOG is disabled here. Sure, but did you tried to boot with 'nmi_watchdog=0' appended in your boot params ? No, I assumed since I don't have any watchdog, I wouldn't have the NMI thing either... these silly assumptions. tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oprofile broken on 2.6.19
Gert Vervoort wrote: > > When I try to use oprofile on 2.6.19, it does not seem to work: > > [EMAIL PROTECTED] tmp]$ sudo opcontrol --no-vmlinux > [EMAIL PROTECTED] tmp]$ sudo opcontrol --start > /usr/bin/opcontrol: line 911: /dev/oprofile/0/enabled: No such file or > directory/usr/bin/opcontrol: line 911: /dev/oprofile/0/event: No such > file or directory oh.. and next time please first try google ;) http://www.google.ch/search?q=%2Fdev%2Foprofile%2F0%2Fevent tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oprofile broken on 2.6.19
Gert Vervoort wrote: > > When I try to use oprofile on 2.6.19, it does not seem to work: > http://lkml.org/lkml/2006/11/22/172 tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oprofile broken on 2.6.19
Gert Vervoort wrote: When I try to use oprofile on 2.6.19, it does not seem to work: http://lkml.org/lkml/2006/11/22/172 tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oprofile broken on 2.6.19
Gert Vervoort wrote: When I try to use oprofile on 2.6.19, it does not seem to work: [EMAIL PROTECTED] tmp]$ sudo opcontrol --no-vmlinux [EMAIL PROTECTED] tmp]$ sudo opcontrol --start /usr/bin/opcontrol: line 911: /dev/oprofile/0/enabled: No such file or directory/usr/bin/opcontrol: line 911: /dev/oprofile/0/event: No such file or directory oh.. and next time please first try google ;) http://www.google.ch/search?q=%2Fdev%2Foprofile%2F0%2Fevent tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Gaming Interface
Dirk wrote: > > How about having a simple Game API like SDL included in the Kernel and > officially announce the promise to change it only once every couple of > years? > A new API would be counter-productive! There's X11/OpenGL for graphics and OpenAL for sound, both APIs widespread even in the windows world and also on BSD and all other flavors of UNIX. X11/OpenGL hasn't changed for years (X11R6 has been released around 1985 IIRC). The whole point of X11 is that anyone can implement a server, the spec is open to anyone, and once you write a X11-compliant client it will run on any UNIX/Linux computer. Now if you introduce a special API for the Linux kernel, the game developers would have to create two versions, one for Linux and one for all other UNIXes. But more realistically, they'd just stick with the plain old X11/OpenGL/OpenAL design because not everyone will have this new kernel and they'd still have to release two versions for Linux: one for the new kernel and one for the older computers. Linus already stated several times that the kernel ABI is not stable! It will change, and it's the responsibility of userspace tools/libraries to provide a stable API. So, to answer your question: We already have a simple API. One that has been stable for 10+ years now and won't be changing anytime soon. tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Gaming Interface
Dirk wrote: How about having a simple Game API like SDL included in the Kernel and officially announce the promise to change it only once every couple of years? A new API would be counter-productive! There's X11/OpenGL for graphics and OpenAL for sound, both APIs widespread even in the windows world and also on BSD and all other flavors of UNIX. X11/OpenGL hasn't changed for years (X11R6 has been released around 1985 IIRC). The whole point of X11 is that anyone can implement a server, the spec is open to anyone, and once you write a X11-compliant client it will run on any UNIX/Linux computer. Now if you introduce a special API for the Linux kernel, the game developers would have to create two versions, one for Linux and one for all other UNIXes. But more realistically, they'd just stick with the plain old X11/OpenGL/OpenAL design because not everyone will have this new kernel and they'd still have to release two versions for Linux: one for the new kernel and one for the older computers. Linus already stated several times that the kernel ABI is not stable! It will change, and it's the responsibility of userspace tools/libraries to provide a stable API. So, to answer your question: We already have a simple API. One that has been stable for 10+ years now and won't be changing anytime soon. tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 3/4 qrcu: add documentation
Jens Axboe wrote: > diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt > index f4dffad..36d6185 100644 > --- a/Documentation/RCU/checklist.txt > +++ b/Documentation/RCU/checklist.txt > @@ -259,3 +259,16 @@ over a rather long period of time, but improvements are > always welcome! > > Note that, rcu_assign_pointer() and rcu_dereference() relate to > SRCU just as they do to other forms of RCU. > + > +14. QRCU is very similar to SRCU, but features very fast grace-period > + processing at the expense of heavier-weight read-side operations. > + The correspondance between QRCU and SRCU is as follows: > + > + QRCUSRCU > + > + struct qrcu_struct struct srcu_struct > + init_qrcu_struct() init_srcu_struct() > + cleanup_qrcu_struct() cleanup_srcu_struct() > + qrcu_read_lock()srcu_read_lock() > + qrcu_read-unlock() srcu_read_unlock() A small typo: qrcu_read_unlock() tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 3/4 qrcu: add documentation
Jens Axboe wrote: diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index f4dffad..36d6185 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt @@ -259,3 +259,16 @@ over a rather long period of time, but improvements are always welcome! Note that, rcu_assign_pointer() and rcu_dereference() relate to SRCU just as they do to other forms of RCU. + +14. QRCU is very similar to SRCU, but features very fast grace-period + processing at the expense of heavier-weight read-side operations. + The correspondance between QRCU and SRCU is as follows: + + QRCUSRCU + + struct qrcu_struct struct srcu_struct + init_qrcu_struct() init_srcu_struct() + cleanup_qrcu_struct() cleanup_srcu_struct() + qrcu_read_lock()srcu_read_lock() + qrcu_read-unlock() srcu_read_unlock() A small typo: qrcu_read_unlock() tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Binary Drivers
James Porter wrote: I'm pretty sure Linus has decided, basically he said the patches to prevent non-gpl binary drivers are not going into his tree unless every other tree adopts it. Of course the few supporting won't get off their high horse and try it on a different tree. .. unfortunately, that doesn't make the legal status any clearer. tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Binary Drivers
Erik Mouw wrote: "However, we thought the legal and technical expense involved in writing this binary driver and possibly violating the Linux kernel copyright was well spend." So Microsoft is right, the legal status of Linux software _is_ unclear. You just gave them every reason to continue their campaign against Linux. . The problem is, nobody wants to decide what to do with closed source software in Linux. I don't care how you decide, for or against binary drivers (well, actually I do but my opinion doesn't matter), just decide already! tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Binary Drivers
Erik Mouw wrote: However, we thought the legal and technical expense involved in writing this binary driver and possibly violating the Linux kernel copyright was well spend. So Microsoft is right, the legal status of Linux software _is_ unclear. You just gave them every reason to continue their campaign against Linux. Don't use Linux, its legal status is unclear, you may get sued. The problem is, nobody wants to decide what to do with closed source software in Linux. I don't care how you decide, for or against binary drivers (well, actually I do but my opinion doesn't matter), just decide already! tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Binary Drivers
James Porter wrote: I'm pretty sure Linus has decided, basically he said the patches to prevent non-gpl binary drivers are not going into his tree unless every other tree adopts it. Of course the few supporting won't get off their high horse and try it on a different tree. .. unfortunately, that doesn't make the legal status any clearer. tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Binary Drivers
Alexey Dobriyan wrote: On Fri, Dec 15, 2006 at 09:20:58PM +, James Porter wrote: For what it's worth, I don't see any problem with binary drivers from hardware manufacturers. Binary drivers from hardware manufacturers are crap. Learn it by heart. That's your personal opinion! A lot other people (including me) have had excellent experience with binary drivers! Just because nvidia makes a closed source driver doesn't mean that we can't also create an open source driver(limited functionality, reverse engineered, etc.,etc.). We can. The day you show me that the open-source driver is faster and more stable then the binary driver, I'll switch. But until then I'll stay with my binary driver. I haven't had any serious problems with it, in fact, I'm very happy, so why should I want to switch? I don't see Linux in such a political way like some of you do, for me Linux is just like any other OS. There are good drivers and bad drivers. And I don't care if they are open source or binary, I don't judge them based on that, but based on how well they work and how good the support is. But users of binary drivers should be blocked from sending bug reports to kernel developers. Most end-users will never get directly in touch with the kernel developers. They'll first go to their distribution. Most Ubuntu users don't even know what a kernel is (not that I use Ubuntu, but it's a distribution that is widespread among the less experienced end-users and people who switch to Linux from the windows world). tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Binary Drivers
Alexey Dobriyan wrote: On Fri, Dec 15, 2006 at 09:20:58PM +, James Porter wrote: For what it's worth, I don't see any problem with binary drivers from hardware manufacturers. Binary drivers from hardware manufacturers are crap. Learn it by heart. That's your personal opinion! A lot other people (including me) have had excellent experience with binary drivers! Just because nvidia makes a closed source driver doesn't mean that we can't also create an open source driver(limited functionality, reverse engineered, etc.,etc.). We can. The day you show me that the open-source driver is faster and more stable then the binary driver, I'll switch. But until then I'll stay with my binary driver. I haven't had any serious problems with it, in fact, I'm very happy, so why should I want to switch? I don't see Linux in such a political way like some of you do, for me Linux is just like any other OS. There are good drivers and bad drivers. And I don't care if they are open source or binary, I don't judge them based on that, but based on how well they work and how good the support is. But users of binary drivers should be blocked from sending bug reports to kernel developers. Most end-users will never get directly in touch with the kernel developers. They'll first go to their distribution. Most Ubuntu users don't even know what a kernel is (not that I use Ubuntu, but it's a distribution that is widespread among the less experienced end-users and people who switch to Linux from the windows world). tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.19: skb_over_panic, followed by a BUG at net/core/skbuff.c:93
I only have a screenshot with no backtrace, if you want to see the function names in the backtrace, please tell me what I need to do. http://dbservice.com/ftpdir/tom/kernel-bug.jpg I was running a 2.6.19-ge??? kernel before (I don't remember which version exactly) and it was running fine, today I upgraded to v2.6.19 and now I have this crash. 2.6.18 works fine, too. The bug happens when gentoo wants to bring up eth0 (starting the lo device works fine), even a simple 'ifconfig eth0 192.168.0.11' will crash the kernel. The computer is a Shuttle XPC with an AMD 64bit CPU, network card is integrated in the nforce chipset. tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.19: skb_over_panic, followed by a BUG at net/core/skbuff.c:93
I only have a screenshot with no backtrace, if you want to see the function names in the backtrace, please tell me what I need to do. http://dbservice.com/ftpdir/tom/kernel-bug.jpg I was running a 2.6.19-ge??? kernel before (I don't remember which version exactly) and it was running fine, today I upgraded to v2.6.19 and now I have this crash. 2.6.18 works fine, too. The bug happens when gentoo wants to bring up eth0 (starting the lo device works fine), even a simple 'ifconfig eth0 192.168.0.11' will crash the kernel. The computer is a Shuttle XPC with an AMD 64bit CPU, network card is integrated in the nforce chipset. tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
