[patch 15/24] ALPS: Fix resume for DualPoints
From: David Moore [EMAIL PROTECTED] Input: ALPS - fix resume (for DualPoints) The driver would not reset pass-through mode when performing resume of a DualPoint touchpad causing it to stop working until next reboot. Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED] Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED] --- drivers/input/mouse/alps.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Index: work/drivers/input/mouse/alps.c === --- work.orig/drivers/input/mouse/alps.c +++ work/drivers/input/mouse/alps.c @@ -358,7 +358,7 @@ static int alps_reconnect(struct psmouse if (!(priv-i = alps_get_model(psmouse, version))) return -1; - if (priv-i-flags ALPS_PASS alps_passthrough_mode(psmouse, 1)) + if ((priv-i-flags ALPS_PASS) alps_passthrough_mode(psmouse, 1)) return -1; if (alps_get_status(psmouse, param)) @@ -372,7 +372,7 @@ static int alps_reconnect(struct psmouse return -1; } - if (priv-i-flags == ALPS_PASS alps_passthrough_mode(psmouse, 0)) + if ((priv-i-flags ALPS_PASS) alps_passthrough_mode(psmouse, 0)) return -1; return 0; - 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/
[patch 05/24] Add usb_to_input_id
Input: introduce usb_to_input_id() to uniformly produce struct input_id for USB input devices. Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED] --- drivers/usb/input/acecad.c |6 ++ drivers/usb/input/aiptek.c |6 ++ drivers/usb/input/ati_remote.c |8 +++- drivers/usb/input/hid-input.c |6 ++ drivers/usb/input/itmtouch.c|6 ++ drivers/usb/input/kbtab.c |6 ++ drivers/usb/input/mtouchusb.c |6 ++ drivers/usb/input/powermate.c |6 ++ drivers/usb/input/touchkitusb.c |7 ++- drivers/usb/input/usbkbd.c |6 ++ drivers/usb/input/usbmouse.c|6 ++ drivers/usb/input/wacom.c |6 ++ drivers/usb/input/xpad.c|6 ++ drivers/usb/media/konicawc.c|6 ++ include/linux/usb_input.h | 25 + 15 files changed, 54 insertions(+), 58 deletions(-) Index: work/drivers/usb/input/acecad.c === --- work.orig/drivers/usb/input/acecad.c +++ work/drivers/usb/input/acecad.c @@ -31,6 +31,7 @@ #include linux/module.h #include linux/init.h #include linux/usb.h +#include linux/usb_input.h /* * Version Information @@ -212,10 +213,7 @@ static int usb_acecad_probe(struct usb_i acecad-dev.name = acecad-name; acecad-dev.phys = acecad-phys; - acecad-dev.id.bustype = BUS_USB; - acecad-dev.id.vendor = le16_to_cpu(dev-descriptor.idVendor); - acecad-dev.id.product = le16_to_cpu(dev-descriptor.idProduct); - acecad-dev.id.version = le16_to_cpu(dev-descriptor.bcdDevice); + usb_to_input_id(dev, acecad-dev.id); acecad-dev.dev = intf-dev; usb_fill_int_urb(acecad-irq, dev, pipe, Index: work/drivers/usb/input/aiptek.c === --- work.orig/drivers/usb/input/aiptek.c +++ work/drivers/usb/input/aiptek.c @@ -77,6 +77,7 @@ #include linux/module.h #include linux/init.h #include linux/usb.h +#include linux/usb_input.h #include linux/sched.h #include asm/uaccess.h #include asm/unaligned.h @@ -2125,10 +2126,7 @@ aiptek_probe(struct usb_interface *intf, aiptek-inputdev.absflat[ABS_WHEEL] = 0; aiptek-inputdev.name = Aiptek; aiptek-inputdev.phys = aiptek-features.usbPath; - aiptek-inputdev.id.bustype = BUS_USB; - aiptek-inputdev.id.vendor = le16_to_cpu(usbdev-descriptor.idVendor); - aiptek-inputdev.id.product = le16_to_cpu(usbdev-descriptor.idProduct); - aiptek-inputdev.id.version = le16_to_cpu(usbdev-descriptor.bcdDevice); + usb_to_input_id(usbdev, aiptek-inputdev.id); aiptek-inputdev.dev = intf-dev; aiptek-usbdev = usbdev; Index: work/drivers/usb/input/usbkbd.c === --- work.orig/drivers/usb/input/usbkbd.c +++ work/drivers/usb/input/usbkbd.c @@ -32,6 +32,7 @@ #include linux/input.h #include linux/init.h #include linux/usb.h +#include linux/usb_input.h /* * Version Information @@ -288,10 +289,7 @@ static int usb_kbd_probe(struct usb_inte kbd-dev.name = kbd-name; kbd-dev.phys = kbd-phys; - kbd-dev.id.bustype = BUS_USB; - kbd-dev.id.vendor = le16_to_cpu(dev-descriptor.idVendor); - kbd-dev.id.product = le16_to_cpu(dev-descriptor.idProduct); - kbd-dev.id.version = le16_to_cpu(dev-descriptor.bcdDevice); + usb_to_input_id(dev, kbd-dev.id); kbd-dev.dev = iface-dev; if (dev-manufacturer) Index: work/drivers/usb/input/usbmouse.c === --- work.orig/drivers/usb/input/usbmouse.c +++ work/drivers/usb/input/usbmouse.c @@ -32,6 +32,7 @@ #include linux/module.h #include linux/init.h #include linux/usb.h +#include linux/usb_input.h /* * Version Information @@ -171,10 +172,7 @@ static int usb_mouse_probe(struct usb_in mouse-dev.name = mouse-name; mouse-dev.phys = mouse-phys; - mouse-dev.id.bustype = BUS_USB; - mouse-dev.id.vendor = le16_to_cpu(dev-descriptor.idVendor); - mouse-dev.id.product = le16_to_cpu(dev-descriptor.idProduct); - mouse-dev.id.version = le16_to_cpu(dev-descriptor.bcdDevice); + usb_to_input_id(dev, mouse-dev.id); mouse-dev.dev = intf-dev; if (dev-manufacturer) Index: work/drivers/usb/input/wacom.c === --- work.orig/drivers/usb/input/wacom.c +++ work/drivers/usb/input/wacom.c @@ -69,6 +69,7 @@ #include linux/module.h #include linux/init.h #include linux/usb.h +#include linux/usb_input.h #include asm/unaligned.h #include asm/byteorder.h @@ -823,10 +824,7 @@ static int wacom_probe(struct usb_interf wacom-dev.name = wacom-features-name; wacom-dev.phys = wacom-phys; - wacom-dev.id.bustype = BUS_USB; - wacom-dev.id.vendor =
Netlink connector
On Sun, 24 Jul 2005, David S. Miller wrote: From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Sat, 23 Jul 2005 13:14:55 +0400 Andrew has no objection against connector and it lives in -mm A patch sitting in -mm has zero significance. The significance I think is that Andrew is trying to gently encourage some further progress in the area. I recall some netconf discussion about TIPC over Netlink, or more likely a variation thereof, which may be a better way forward. It's cool stuff http://tipc.sourceforge.net/ - James -- James Morris [EMAIL PROTECTED] - 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/
[patch 08/24] input: make name, phys and uniq const char
Input: make name, phys and uniq be 'const char *' because once
set noone should attempt to change them.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/char/sonypi.c | 24 ++--
drivers/input/misc/uinput.c | 23 ---
include/linux/input.h |6 +++---
3 files changed, 17 insertions(+), 36 deletions(-)
Index: work/drivers/char/sonypi.c
===
--- work.orig/drivers/char/sonypi.c
+++ work/drivers/char/sonypi.c
@@ -1228,14 +1228,7 @@ static int __devinit sonypi_probe(void)
sonypi_device.input_jog_dev.keybit[LONG(BTN_MOUSE)] =
BIT(BTN_MIDDLE);
sonypi_device.input_jog_dev.relbit[0] = BIT(REL_WHEEL);
- sonypi_device.input_jog_dev.name =
- kmalloc(sizeof(SONYPI_JOG_INPUTNAME), GFP_KERNEL);
- if (!sonypi_device.input_jog_dev.name) {
- printk(KERN_ERR sonypi: kmalloc failed\n);
- ret = -ENOMEM;
- goto out_inkmallocinput1;
- }
- sprintf(sonypi_device.input_jog_dev.name, SONYPI_JOG_INPUTNAME);
+ sonypi_device.input_jog_dev.name = SONYPI_JOG_INPUTNAME;
sonypi_device.input_jog_dev.id.bustype = BUS_ISA;
sonypi_device.input_jog_dev.id.vendor = PCI_VENDOR_ID_SONY;
@@ -1249,14 +1242,7 @@ static int __devinit sonypi_probe(void)
if (sonypi_inputkeys[i].inputev)
set_bit(sonypi_inputkeys[i].inputev,
sonypi_device.input_key_dev.keybit);
- sonypi_device.input_key_dev.name =
- kmalloc(sizeof(SONYPI_KEY_INPUTNAME), GFP_KERNEL);
- if (!sonypi_device.input_key_dev.name) {
- printk(KERN_ERR sonypi: kmalloc failed\n);
- ret = -ENOMEM;
- goto out_inkmallocinput2;
- }
- sprintf(sonypi_device.input_key_dev.name, SONYPI_KEY_INPUTNAME);
+ sonypi_device.input_key_dev.name = SONYPI_KEY_INPUTNAME;
sonypi_device.input_key_dev.id.bustype = BUS_ISA;
sonypi_device.input_key_dev.id.vendor = PCI_VENDOR_ID_SONY;
@@ -1314,11 +1300,7 @@ out_platformdev:
kfifo_free(sonypi_device.input_fifo);
out_infifo:
input_unregister_device(sonypi_device.input_key_dev);
- kfree(sonypi_device.input_key_dev.name);
-out_inkmallocinput2:
input_unregister_device(sonypi_device.input_jog_dev);
- kfree(sonypi_device.input_jog_dev.name);
-out_inkmallocinput1:
free_irq(sonypi_device.irq, sonypi_irq);
out_reqirq:
release_region(sonypi_device.ioport1, sonypi_device.region_size);
@@ -1345,9 +1327,7 @@ static void __devexit sonypi_remove(void
if (useinput) {
input_unregister_device(sonypi_device.input_key_dev);
- kfree(sonypi_device.input_key_dev.name);
input_unregister_device(sonypi_device.input_jog_dev);
- kfree(sonypi_device.input_jog_dev.name);
kfifo_free(sonypi_device.input_fifo);
}
Index: work/include/linux/input.h
===
--- work.orig/include/linux/input.h
+++ work/include/linux/input.h
@@ -811,9 +811,9 @@ struct input_dev {
void *private;
- char *name;
- char *phys;
- char *uniq;
+ const char *name;
+ const char *phys;
+ const char *uniq;
struct input_id id;
unsigned long evbit[NBITS(EV_MAX)];
Index: work/drivers/input/misc/uinput.c
===
--- work.orig/drivers/input/misc/uinput.c
+++ work/drivers/input/misc/uinput.c
@@ -251,6 +251,7 @@ static int uinput_alloc_device(struct fi
struct uinput_user_dev *user_dev;
struct input_dev*dev;
struct uinput_device*udev;
+ char*name;
int size;
int retval;
@@ -274,13 +275,13 @@ static int uinput_alloc_device(struct fi
kfree(dev-name);
size = strnlen(user_dev-name, UINPUT_MAX_NAME_SIZE) + 1;
- dev-name = kmalloc(size, GFP_KERNEL);
- if (!dev-name) {
+ dev-name = name = kmalloc(size, GFP_KERNEL);
+ if (!name) {
retval = -ENOMEM;
goto exit;
}
+ strlcpy(name, user_dev-name, size);
- strlcpy(dev-name, user_dev-name, size);
dev-id.bustype = user_dev-id.bustype;
dev-id.vendor = user_dev-id.vendor;
dev-id.product = user_dev-id.product;
@@ -397,6 +398,7 @@ static int uinput_ioctl(struct inode *in
struct uinput_ff_erase ff_erase;
struct uinput_request *req;
int
[patch 16/24] ALPS: fix enabling tapping mode
From: Peter Osterlund [EMAIL PROTECTED]
Input: ALPS - unconditionally enable tapping mode
The condition in alps_init() was also inverted and the driver
was enabling tapping mode only if it was already enabled.
Signed-off-by: Peter Osterlund [EMAIL PROTECTED]
Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED]
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/input/mouse/alps.c | 25 +++--
1 files changed, 7 insertions(+), 18 deletions(-)
Index: work/drivers/input/mouse/alps.c
===
--- work.orig/drivers/input/mouse/alps.c
+++ work/drivers/input/mouse/alps.c
@@ -2,7 +2,7 @@
* ALPS touchpad PS/2 mouse driver
*
* Copyright (c) 2003 Neil Brown [EMAIL PROTECTED]
- * Copyright (c) 2003 Peter Osterlund [EMAIL PROTECTED]
+ * Copyright (c) 2003-2005 Peter Osterlund [EMAIL PROTECTED]
* Copyright (c) 2004 Dmitry Torokhov [EMAIL PROTECTED]
* Copyright (c) 2005 Vojtech Pavlik [EMAIL PROTECTED]
*
@@ -350,7 +350,6 @@ static int alps_tap_mode(struct psmouse
static int alps_reconnect(struct psmouse *psmouse)
{
struct alps_data *priv = psmouse-private;
- unsigned char param[4];
int version;
psmouse_reset(psmouse);
@@ -361,14 +360,13 @@ static int alps_reconnect(struct psmouse
if ((priv-i-flags ALPS_PASS) alps_passthrough_mode(psmouse, 1))
return -1;
- if (alps_get_status(psmouse, param))
+ if (alps_tap_mode(psmouse, 1)) {
+ printk(KERN_WARNING alps.c: Failed to reenable hardware
tapping\n);
return -1;
-
- if (!(param[0] 0x04))
- alps_tap_mode(psmouse, 1);
+ }
if (alps_absolute_mode(psmouse)) {
- printk(KERN_ERR alps.c: Failed to enable absolute mode\n);
+ printk(KERN_ERR alps.c: Failed to reenable absolute mode\n);
return -1;
}
@@ -389,7 +387,6 @@ static void alps_disconnect(struct psmou
int alps_init(struct psmouse *psmouse)
{
struct alps_data *priv;
- unsigned char param[4];
int version;
psmouse-private = priv = kmalloc(sizeof(struct alps_data), GFP_KERNEL);
@@ -403,16 +400,8 @@ int alps_init(struct psmouse *psmouse)
if ((priv-i-flags ALPS_PASS) alps_passthrough_mode(psmouse, 1))
goto init_fail;
- if (alps_get_status(psmouse, param)) {
- printk(KERN_ERR alps.c: touchpad status report request
failed\n);
- goto init_fail;
- }
-
- if (param[0] 0x04) {
- printk(KERN_INFO alps.c: Enabling hardware tapping\n);
- if (alps_tap_mode(psmouse, 1))
- printk(KERN_WARNING alps.c: Failed to enable hardware
tapping\n);
- }
+ if (alps_tap_mode(psmouse, 1))
+ printk(KERN_WARNING alps.c: Failed to enable hardware
tapping\n);
if (alps_absolute_mode(psmouse)) {
printk(KERN_ERR alps.c: Failed to enable absolute mode\n);
-
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/
Stripping in module
Hi, at the moment I am packaging a Linux module as an RPM archive. Therefor I would like to remove some of the not exported/needed symbols (like e.g. static functions or constants) from the Linux module. What is the best way to do this with v2.6. I have tried e.g. to remove all symbols starting with telos from the module like this (after kbuild): strip -w -K '!telos*' -K 'telosi2c_usb_driver' telosi2c_linux.ko When I try to load such a module, insmod dies with a segmentation fault or the complete kernel dies (with invalid operand: ). What is the reason for this problem? What is the correct way using kbuild to remove some symbols? cu, Marco - 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/
[patch 12/24] i8042 - add Alienware Sentia to NOMUX blacklist
Input: i8042 - add Alienware Sentia to NOMUX blacklist.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/input/serio/i8042-x86ia64io.h |7 +++
1 files changed, 7 insertions(+)
Index: work/drivers/input/serio/i8042-x86ia64io.h
===
--- work.orig/drivers/input/serio/i8042-x86ia64io.h
+++ work/drivers/input/serio/i8042-x86ia64io.h
@@ -137,6 +137,13 @@ static struct dmi_system_id __initdata i
DMI_MATCH(DMI_PRODUCT_NAME, Satellite P10),
},
},
+ {
+ .ident = Alienware Sentia,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, ALIENWARE),
+ DMI_MATCH(DMI_PRODUCT_NAME, Sentia),
+ },
+ },
{ }
};
-
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/
[PPC64] Remove another fixed address constraint
Presently the LparMap, one of the structures the kernel shares with
the legacy iSeries hypervisor has a fixed offset address in head.S.
This patch changes this so the LparMap is a normally initialized
structure, without fixed address. This allows us to use macros to
compute some of the values in the structure, which wasn't previously
possible because the assembler always uses signed-% which gets the
wrong answers for the computations in question.
Unfortunately, a gcc bug means that doing this requires another
structure (hvReleaseData) to be initialized in asm instead of C, but
on the whole the result is cleaner than before.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: working-2.6/include/asm-ppc64/iSeries/LparMap.h
===
--- working-2.6.orig/include/asm-ppc64/iSeries/LparMap.h2005-07-06
10:30:53.0 +1000
+++ working-2.6/include/asm-ppc64/iSeries/LparMap.h 2005-07-25
15:28:42.0 +1000
@@ -49,19 +49,26 @@
* entry to map the Esid to the Vsid.
*/
+#define HvEsidsToMap 2
+#define HvRangesToMap 1
+
/* Hypervisor initially maps 32MB of the load area */
#define HvPagesToMap 8192
struct LparMap {
- u64 xNumberEsids; // Number of ESID/VSID pairs (1)
- u64 xNumberRanges; // Number of VA ranges to map (1)
- u64 xSegmentTableOffs; // Page number within load area of seg table
(0)
+ u64 xNumberEsids; // Number of ESID/VSID pairs
+ u64 xNumberRanges; // Number of VA ranges to map
+ u64 xSegmentTableOffs; // Page number within load area of seg table
u64 xRsvd[5];
- u64 xKernelEsid;// Esid used to map kernel load (0x0C)
- u64 xKernelVsid;// Vsid used to map kernel load (0x0C)
- u64 xPages; // Number of pages to be mapped (8192)
- u64 xOffset;// Offset from start of load area (0)
- u64 xVPN; // Virtual Page Number (0x000C)
+ struct {
+ u64 xKernelEsid;// Esid used to map kernel load
+ u64 xKernelVsid;// Vsid used to map kernel load
+ } xEsids[HvEsidsToMap];
+ struct {
+ u64 xPages; // Number of pages to be mapped
+ u64 xOffset;// Offset from start of load area
+ u64 xVPN; // Virtual Page Number
+ } xRanges[HvRangesToMap];
};
extern struct LparMap xLparMap;
Index: working-2.6/include/asm-ppc64/iSeries/HvReleaseData.h
===
--- working-2.6.orig/include/asm-ppc64/iSeries/HvReleaseData.h 2005-07-06
10:30:53.0 +1000
+++ working-2.6/include/asm-ppc64/iSeries/HvReleaseData.h 2005-07-25
15:28:42.0 +1000
@@ -39,6 +39,11 @@
* know that this PLIC does not support running an OS that old.
*/
+#defineHVREL_TAGSINACTIVE 0x8000
+#define HVREL_32BIT0x4000
+#define HVREL_NOSHAREDPROCS0x2000
+#define HVREL_NOHMT0x1000
+
struct HvReleaseData {
u32 xDesc; /* Descriptor HvRD ebcdic x00-x03 */
u16 xSize; /* Size of this control block x04-x05 */
@@ -46,11 +51,7 @@
struct naca_struct *xSlicNacaAddr; /* Virt addr of SLIC NACA
x08-x0F */
u32 xMsNucDataOffset; /* Offset of Linux Mapping Data x10-x13 */
u32 xRsvd1; /* Reserved x14-x17 */
- u16 xTagsMode:1;/* 0 == tags active, 1 == tags inactive */
- u16 xAddressSize:1; /* 0 == 64-bit, 1 == 32-bit */
- u16 xNoSharedProcs:1; /* 0 == shared procs, 1 == no shared */
- u16 xNoHMT:1; /* 0 == allow HMT, 1 == no HMT */
- u16 xRsvd2:12; /* Reserved x18-x19 */
+ u16 xFlags;
u16 xVrmIndex; /* VRM Index of OS imagex1A-x1B */
u16 xMinSupportedPlicVrmIndex; /* Min PLIC level (soft) x1C-x1D */
u16 xMinCompatablePlicVrmIndex; /* Min PLIC levelP (hard) x1E-x1F */
Index: working-2.6/arch/ppc64/kernel/LparData.c
===
--- working-2.6.orig/arch/ppc64/kernel/LparData.c 2005-07-14
10:57:49.0 +1000
+++ working-2.6/arch/ppc64/kernel/LparData.c2005-07-25 15:09:55.0
+1000
@@ -33,17 +33,36 @@
* the hypervisor and Linux.
*/
+/*
+ * WARNING - magic here
+ *
+ * Ok, this is a horrid hack below, but marginally better than the
+ * alternatives. What we really want is just to initialize
+ * hvReleaseData in C as in the #if 0 section here. However, gcc
+ * refuses to believe that (u32)x is a constant expression, so will
+ * not allow the xMsNucDataOffset field to be properly initialized.
+ * So, we declare hvReleaseData in inline asm instead. We use inline
+ * asm, rather than a .S file,
Re: tx queue start entry x dirty entry y (was 8139too PCI IRQ issues)
[I'm currently having nasty ISP problems, so I've removed myself from the list for the time-being, as e-mail is struggling to get through to me -- hence the delay in my reply to this, SORRY] Probably it's the miss config of PIC. Can you post more info? Thanks for helping! :-))) - /proc/interrupt more /proc/interrupts CPU0 0: 473349IO-APIC-edge timer 1: 10IO-APIC-edge i8042 2: 0 XT-PIC cascade 5: 1IO-APIC-edge soundblaster 7: 2IO-APIC-edge parport0 9: 8152IO-APIC-edge aic7xxx 10: 19988IO-APIC-edge eth0 11:577IO-APIC-edge ohci_hcd, ohci_hcd, ohci_hcd, ohci_hcd, eth1 12:101IO-APIC-edge i8042 14: 51421IO-APIC-edge ide0 NMI: 0 LOC: 473350 ERR: 0 MIS: 0 - mptable I'm running a single (old) processor, and I dont have mptable installed I can't even find a package for it, am I missing something? Sorry! - 8259A.pl perl 8259A.pl irq 0: 00, edge irq 1: 00, edge irq 2: 00, edge irq 3: 00, edge irq 4: 00, edge irq 5: 00, edge irq 6: 00, edge irq 7: 00, edge irq 8: 0a, edge irq 9: 0a, level irq 10: 0a, edge irq 11: 0a, level irq 12: 0a, edge irq 13: 0a, edge irq 14: 0a, edge irq 15: 0a, edge - lspci -vvv :00:00.0 Non-VGA unclassified device: Intel Corp. 82378ZB/IB, 82379AB (SIO, SIO.A) PCI to ISA Bridge (rev 88) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 :00:01.0 IDE interface: Silicon Image, Inc. (formerly CMD Technology Inc) PCI0646 (rev 01) (prog-if 8a [Master SecP PriP]) Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (500ns min, 1000ns max) Interrupt: pin A routed to IRQ 14 Region 0: I/O ports at ignored Region 1: I/O ports at ignored Region 2: I/O ports at ignored Region 3: I/O ports at ignored Region 4: I/O ports at fc00 [size=16] :00:02.0 SCSI storage controller: Adaptec AIC-7880U Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 248 (2000ns min, 2000ns max), Cache Line Size: 0x08 (32 bytes) Interrupt: pin A routed to IRQ 9 Region 0: I/O ports at f800 [disabled] [size=256] Region 1: Memory at ffbfc000 (32-bit, non-prefetchable) [size=4K] :00:0b.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2064W [Millennium] (rev 01) (prog-if 00 [VGA]) Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Interrupt: pin A routed to IRQ 11 Region 0: Memory at a000 (32-bit, non-prefetchable) [size=16K] Region 1: Memory at a080 (32-bit, prefetchable) [size=8M] Expansion ROM at d000 [disabled] [size=64K] :00:0d.0 USB Controller: Lucent Microelectronics USS-344S USB Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Lucent Microelectronics USS-344S USB Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 248 (750ns min, 21500ns max) Interrupt: pin A routed to IRQ 11 Region 0: Memory at ffbec000 (32-bit, non-prefetchable) [size=4K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=1 PME- :00:0d.1 USB Controller: Lucent Microelectronics USS-344S USB Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Lucent Microelectronics USS-344S USB Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 248 (750ns min, 21500ns max) Interrupt: pin A routed to IRQ 11 Region 0: Memory at ffbdc000 (32-bit, non-prefetchable) [size=4K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=1 PME- :00:0d.2 USB Controller: Lucent Microelectronics USS-344S USB Controller (rev 11) (prog-if 10 [OHCI])
[patch 20/24] HID - only report events coming from interrupts to hiddev
From: Adam Kropelin [EMAIL PROTECTED]
Input: HID - only report events coming from interrupts to hiddev
Currently hid-core follows the same code path for input reports
regardless of whether they are a result of interrupt transfers or
control transfers. That leads to interrupt events erroneously being
reported to hiddev for regular control transfers.
Prior to 2.6.12 the problem was mitigated by the fact that
reporting to hiddev is supressed if the field value has not changed,
which is often the case. Said filtering was removed in 2.6.12-rc1 which
means any input reports fetched via control transfers result in hiddev
interrupt events. This behavior can quickly lead to a feedback loop
where a userspace app, in response to interrupt events, issues control
transfers which in turn create more interrupt events.
This patch prevents input reports that arrive via control transfers from
being reported to hiddev as interrupt events.
Signed-off-by: Adam Kropelin [EMAIL PROTECTED]
Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED]
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/usb/input/hid-core.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
Index: work/drivers/usb/input/hid-core.c
===
--- work.orig/drivers/usb/input/hid-core.c
+++ work/drivers/usb/input/hid-core.c
@@ -789,12 +789,12 @@ static __inline__ int search(__s32 *arra
return -1;
}
-static void hid_process_event(struct hid_device *hid, struct hid_field *field,
struct hid_usage *usage, __s32 value, struct pt_regs *regs)
+static void hid_process_event(struct hid_device *hid, struct hid_field *field,
struct hid_usage *usage, __s32 value, int interrupt, struct pt_regs *regs)
{
hid_dump_input(usage, value);
if (hid-claimed HID_CLAIMED_INPUT)
hidinput_hid_event(hid, field, usage, value, regs);
- if (hid-claimed HID_CLAIMED_HIDDEV)
+ if (hid-claimed HID_CLAIMED_HIDDEV interrupt)
hiddev_hid_event(hid, field, usage, value, regs);
}
@@ -804,7 +804,7 @@ static void hid_process_event(struct hid
* reporting to the layer).
*/
-static void hid_input_field(struct hid_device *hid, struct hid_field *field,
__u8 *data, struct pt_regs *regs)
+static void hid_input_field(struct hid_device *hid, struct hid_field *field,
__u8 *data, int interrupt, struct pt_regs *regs)
{
unsigned n;
unsigned count = field-report_count;
@@ -831,19 +831,19 @@ static void hid_input_field(struct hid_d
for (n = 0; n count; n++) {
if (HID_MAIN_ITEM_VARIABLE field-flags) {
- hid_process_event(hid, field, field-usage[n],
value[n], regs);
+ hid_process_event(hid, field, field-usage[n],
value[n], interrupt, regs);
continue;
}
if (field-value[n] = min field-value[n] = max
field-usage[field-value[n] - min].hid
search(value, field-value[n], count))
- hid_process_event(hid, field,
field-usage[field-value[n] - min], 0, regs);
+ hid_process_event(hid, field,
field-usage[field-value[n] - min], 0, interrupt, regs);
if (value[n] = min value[n] = max
field-usage[value[n] - min].hid
search(field-value, value[n], count))
- hid_process_event(hid, field,
field-usage[value[n] - min], 1, regs);
+ hid_process_event(hid, field,
field-usage[value[n] - min], 1, interrupt, regs);
}
memcpy(field-value, value, count * sizeof(__s32));
@@ -851,7 +851,7 @@ exit:
kfree(value);
}
-static int hid_input_report(int type, struct urb *urb, struct pt_regs *regs)
+static int hid_input_report(int type, struct urb *urb, int interrupt, struct
pt_regs *regs)
{
struct hid_device *hid = urb-context;
struct hid_report_enum *report_enum = hid-report_enum + type;
@@ -899,7 +899,7 @@ static int hid_input_report(int type, st
hiddev_report_event(hid, report);
for (n = 0; n report-maxfield; n++)
- hid_input_field(hid, report-field[n], data, regs);
+ hid_input_field(hid, report-field[n], data, interrupt, regs);
if (hid-claimed HID_CLAIMED_INPUT)
hidinput_report_event(hid, report);
@@ -918,7 +918,7 @@ static void hid_irq_in(struct urb *urb,
switch (urb-status) {
case 0: /* success */
- hid_input_report(HID_INPUT_REPORT, urb, regs);
+ hid_input_report(HID_INPUT_REPORT, urb, 1, regs);
break;
case -ECONNRESET: /* unlink */
case -ENOENT:
@@ -1142,7 +1142,7 @@ static void hid_ctrl(struct urb *urb, st
[patch 13/24] i8042 - add Fujitsu T3010 to NOMUX blacklist
From: Vojtech Pavlik [EMAIL PROTECTED]
Input: i8042 - add Fujitsu T3010 to NOMUX blacklist.
Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED]
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/input/serio/i8042-x86ia64io.h |7 +++
1 files changed, 7 insertions(+)
Index: work/drivers/input/serio/i8042-x86ia64io.h
===
--- work.orig/drivers/input/serio/i8042-x86ia64io.h
+++ work/drivers/input/serio/i8042-x86ia64io.h
@@ -131,6 +131,13 @@ static struct dmi_system_id __initdata i
},
},
{
+ .ident = Fujitsu-Siemens Lifebook T3010,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, FUJITSU SIEMENS),
+ DMI_MATCH(DMI_PRODUCT_NAME, LIFEBOOK T3010),
+ },
+ },
+ {
.ident = Toshiba P10,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
-
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/
[patch 17/24] HID: Add a quirk for Aashima gamepad
From: Luca T. [EMAIL PROTECTED]
Input: HID - add a quirk for Aashima Trust (06d6:0025) gamepad
Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED]
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/usb/input/hid-core.c |4
1 files changed, 4 insertions(+)
Index: work/drivers/usb/input/hid-core.c
===
--- work.orig/drivers/usb/input/hid-core.c
+++ work/drivers/usb/input/hid-core.c
@@ -1372,6 +1372,9 @@ void hid_init_reports(struct hid_device
#define USB_VENDOR_ID_A4TECH 0x09da
#define USB_DEVICE_ID_A4TECH_WCP32PU 0x0006
+#define USB_VENDOR_ID_AASHIMA 0x06D6
+#define USB_DEVICE_ID_AASHIMA_GAMEPAD 0x0025
+
#define USB_VENDOR_ID_CYPRESS 0x04b4
#define USB_DEVICE_ID_CYPRESS_MOUSE0x0001
#define USB_DEVICE_ID_CYPRESS_HIDCOM 0x5500
@@ -1524,6 +1527,7 @@ static struct hid_blacklist {
{ USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_WCP32PU,
HID_QUIRK_2WHEEL_MOUSE_HACK_7 },
{ USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_MOUSE,
HID_QUIRK_2WHEEL_MOUSE_HACK_5 },
+ { USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_GAMEPAD,
HID_QUIRK_BADPAD },
{ USB_VENDOR_ID_ALPS, USB_DEVICE_ID_IBM_GAMEPAD, HID_QUIRK_BADPAD },
{ USB_VENDOR_ID_CHIC, USB_DEVICE_ID_CHIC_GAMEPAD, HID_QUIRK_BADPAD },
{ USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_DRIVING, HID_QUIRK_BADPAD |
HID_QUIRK_MULTI_INPUT },
-
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/
[patch 06/24] sonypi: make sure input_work is not running when unloading
Sonypi: make sure that input_work is not running when unloading
the module; submit/retrieve key release data into/from
input_fifo in one shot.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/char/sonypi.c | 122 +-
1 files changed, 63 insertions(+), 59 deletions(-)
Index: work/drivers/char/sonypi.c
===
--- work.orig/drivers/char/sonypi.c
+++ work/drivers/char/sonypi.c
@@ -439,6 +439,11 @@ static struct {
{ 0, 0 },
};
+struct sonypi_keypress {
+ struct input_dev *dev;
+ int key;
+};
+
static struct sonypi_device {
struct pci_dev *dev;
struct platform_device *pdev;
@@ -710,22 +715,61 @@ static void sonypi_setbluetoothpower(u8
static void input_keyrelease(void *data)
{
- struct input_dev *input_dev;
- int key;
-
- while (1) {
- if (kfifo_get(sonypi_device.input_fifo,
- (unsigned char *)input_dev,
- sizeof(input_dev)) != sizeof(input_dev))
- return;
- if (kfifo_get(sonypi_device.input_fifo,
- (unsigned char *)key,
- sizeof(key)) != sizeof(key))
- return;
+ struct sonypi_keypress kp;
+ while (kfifo_get(sonypi_device.input_fifo, (unsigned char *)kp,
+sizeof(kp)) == sizeof(kp)) {
msleep(10);
- input_report_key(input_dev, key, 0);
- input_sync(input_dev);
+ input_report_key(kp.dev, kp.key, 0);
+ input_sync(kp.dev);
+ }
+}
+
+static void sonypi_report_input_event(u8 event)
+{
+ struct input_dev *jog_dev = sonypi_device.input_jog_dev;
+ struct input_dev *key_dev = sonypi_device.input_key_dev;
+ struct sonypi_keypress kp = { NULL };
+ int i;
+
+ switch (event) {
+ case SONYPI_EVENT_JOGDIAL_UP:
+ case SONYPI_EVENT_JOGDIAL_UP_PRESSED:
+ input_report_rel(jog_dev, REL_WHEEL, 1);
+ input_sync(jog_dev);
+ break;
+
+ case SONYPI_EVENT_JOGDIAL_DOWN:
+ case SONYPI_EVENT_JOGDIAL_DOWN_PRESSED:
+ input_report_rel(jog_dev, REL_WHEEL, -1);
+ input_sync(jog_dev);
+ break;
+
+ case SONYPI_EVENT_JOGDIAL_PRESSED:
+ kp.key = BTN_MIDDLE;
+ kp.dev = jog_dev;
+ break;
+
+ case SONYPI_EVENT_FNKEY_RELEASED:
+ /* Nothing, not all VAIOs generate this event */
+ break;
+
+ default:
+ for (i = 0; sonypi_inputkeys[i].sonypiev; i++)
+ if (event == sonypi_inputkeys[i].sonypiev) {
+ kp.dev = key_dev;
+ kp.key = sonypi_inputkeys[i].inputev;
+ break;
+ }
+ break;
+ }
+
+ if (kp.dev) {
+ input_report_key(kp.dev, kp.key, 1);
+ input_sync(kp.dev);
+ kfifo_put(sonypi_device.input_fifo,
+ (unsigned char *)kp, sizeof(kp));
+ schedule_work(sonypi_device.input_work);
}
}
@@ -768,51 +812,8 @@ found:
printk(KERN_INFO
sonypi: event port1=0x%02x,port2=0x%02x\n, v1, v2);
- if (useinput) {
- struct input_dev *input_jog_dev = sonypi_device.input_jog_dev;
- struct input_dev *input_key_dev = sonypi_device.input_key_dev;
- switch (event) {
- case SONYPI_EVENT_JOGDIAL_UP:
- case SONYPI_EVENT_JOGDIAL_UP_PRESSED:
- input_report_rel(input_jog_dev, REL_WHEEL, 1);
- break;
- case SONYPI_EVENT_JOGDIAL_DOWN:
- case SONYPI_EVENT_JOGDIAL_DOWN_PRESSED:
- input_report_rel(input_jog_dev, REL_WHEEL, -1);
- break;
- case SONYPI_EVENT_JOGDIAL_PRESSED: {
- int key = BTN_MIDDLE;
- input_report_key(input_jog_dev, key, 1);
- kfifo_put(sonypi_device.input_fifo,
- (unsigned char *)input_jog_dev,
- sizeof(input_jog_dev));
- kfifo_put(sonypi_device.input_fifo,
- (unsigned char *)key, sizeof(key));
- break;
- }
- case SONYPI_EVENT_FNKEY_RELEASED:
- /* Nothing, not all VAIOs generate this event */
- break;
- }
- input_sync(input_jog_dev);
-
- for (i = 0; sonypi_inputkeys[i].sonypiev; i++) {
- int key;
-
- if
[patch 14/24] synaptics - limit rate on Toshiba Dynabooks
From: Simon Horman [EMAIL PROTECTED]
Input: synaptics - limit rate to 40pps on Toshiba Dynabooks
Toshiba Dynabooks require the same workaround as Satellites -
Synaptics report rate should be lowered to 40pps (from 80),
otherwise KBC starts losing keypresses.
Signed-off-by: Simon Horman [EMAIL PROTECTED]
Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED]
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/input/mouse/synaptics.c | 10 +-
1 files changed, 9 insertions(+), 1 deletion(-)
Index: work/drivers/input/mouse/synaptics.c
===
--- work.orig/drivers/input/mouse/synaptics.c
+++ work/drivers/input/mouse/synaptics.c
@@ -608,6 +608,13 @@ static struct dmi_system_id toshiba_dmi_
DMI_MATCH(DMI_PRODUCT_NAME , Satellite),
},
},
+ {
+ .ident = Toshiba Dynabook,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
+ DMI_MATCH(DMI_PRODUCT_NAME , dynabook),
+ },
+ },
{ }
};
#endif
@@ -656,7 +663,8 @@ int synaptics_init(struct psmouse *psmou
* thye same as rate of standard PS/2 mouse.
*/
if (psmouse-rate = 80 dmi_check_system(toshiba_dmi_table)) {
- printk(KERN_INFO synaptics: Toshiba Satellite detected,
limiting rate to 40pps.\n);
+ printk(KERN_INFO synaptics: Toshiba %s detected, limiting rate
to 40pps.\n,
+ dmi_get_system_info(DMI_PRODUCT_NAME));
psmouse-rate = 40;
}
#endif
-
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.13-rc3-mm1
Richard Purdie [EMAIL PROTECTED] wrote: On Fri, 2005-07-15 at 01:36 -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ On the Zaurus I'm seeing a couple of false BUG: soft lockup detected on CPU#0! reports. These didn't show under 2.6.12-mm1 which was the last -mm kernel I tested. softlockup.c seems identical between these versions so it looks like some other change has caused this to appear... Both of these are triggered from the nand driver. The functions concerned (nand_wait_ready and nand_read_buf) are known to be slow (they wait on hardware). OK, thanks. We can stick a touch_softlockup_watchdog() into those two functions to tell them that we know what we're doing. If you have time to write-and-test a patch then please do so - otherwise I'll take an untested shot at it. - 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/
[patch 01/24] uinput: formatting, cleanup
Input: clean up uinput driver (formatting, extra braces)
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/input/misc/uinput.c | 81 +++-
1 files changed, 35 insertions(+), 46 deletions(-)
Index: work/drivers/input/misc/uinput.c
===
--- work.orig/drivers/input/misc/uinput.c
+++ work/drivers/input/misc/uinput.c
@@ -36,16 +36,6 @@
#include linux/miscdevice.h
#include linux/uinput.h
-static int uinput_dev_open(struct input_dev *dev)
-{
- return 0;
-}
-
-static void uinput_dev_close(struct input_dev *dev)
-{
-
-}
-
static int uinput_dev_event(struct input_dev *dev, unsigned int type, unsigned
int code, int value)
{
struct uinput_device*udev;
@@ -68,17 +58,20 @@ static int uinput_request_alloc_id(struc
/* Atomically allocate an ID for the given request. Returns 0 on
success. */
struct uinput_device *udev = dev-private;
int id;
+ int err = -1;
down(udev-requests_sem);
- for (id=0; idUINPUT_NUM_REQUESTS; id++)
+
+ for (id = 0; id UINPUT_NUM_REQUESTS; id++)
if (!udev-requests[id]) {
udev-requests[id] = request;
request-id = id;
- up(udev-requests_sem);
- return 0;
+ err = 0;
+ break;
}
+
up(udev-requests_sem);
- return -1;
+ return err;
}
static struct uinput_request* uinput_request_find(struct uinput_device *udev,
int id)
@@ -101,7 +94,7 @@ static void uinput_request_init(struct i
/* Allocate an ID. If none are available right away, wait. */
request-retval = wait_event_interruptible(udev-requests_waitq,
- !uinput_request_alloc_id(dev, request));
+ !uinput_request_alloc_id(dev, request));
}
static void uinput_request_submit(struct input_dev *dev, struct uinput_request
*request)
@@ -159,32 +152,30 @@ static int uinput_create_device(struct u
return -EINVAL;
}
- udev-dev-open = uinput_dev_open;
- udev-dev-close = uinput_dev_close;
udev-dev-event = uinput_dev_event;
udev-dev-upload_effect = uinput_dev_upload_effect;
udev-dev-erase_effect = uinput_dev_erase_effect;
udev-dev-private = udev;
- init_waitqueue_head((udev-waitq));
+ init_waitqueue_head(udev-waitq);
input_register_device(udev-dev);
- set_bit(UIST_CREATED, (udev-state));
+ set_bit(UIST_CREATED, udev-state);
return 0;
}
static int uinput_destroy_device(struct uinput_device *udev)
{
- if (!test_bit(UIST_CREATED, (udev-state))) {
+ if (!test_bit(UIST_CREATED, udev-state)) {
printk(KERN_WARNING %s: create the device first\n,
UINPUT_NAME);
return -EINVAL;
}
input_unregister_device(udev-dev);
- clear_bit(UIST_CREATED, (udev-state));
+ clear_bit(UIST_CREATED, udev-state);
return 0;
}
@@ -253,15 +244,15 @@ static int uinput_alloc_device(struct fi
struct uinput_user_dev *user_dev;
struct input_dev*dev;
struct uinput_device*udev;
- int size,
- retval;
+ int size;
+ int retval;
retval = count;
udev = file-private_data;
dev = udev-dev;
- user_dev = kmalloc(sizeof(*user_dev), GFP_KERNEL);
+ user_dev = kmalloc(sizeof(struct uinput_user_dev), GFP_KERNEL);
if (!user_dev) {
retval = -ENOMEM;
goto exit;
@@ -272,7 +263,7 @@ static int uinput_alloc_device(struct fi
goto exit;
}
- if (NULL != dev-name)
+ if (dev-name)
kfree(dev-name);
size = strnlen(user_dev-name, UINPUT_MAX_NAME_SIZE) + 1;
@@ -314,14 +305,13 @@ static ssize_t uinput_write(struct file
{
struct uinput_device *udev = file-private_data;
- if (test_bit(UIST_CREATED, (udev-state))) {
+ if (test_bit(UIST_CREATED, udev-state)) {
struct input_event ev;
if (copy_from_user(ev, buffer, sizeof(struct input_event)))
return -EFAULT;
input_event(udev-dev, ev.type, ev.code, ev.value);
- }
- else
+ } else
count = uinput_alloc_device(file, buffer, count);
return count;
@@ -332,26 +322,24 @@ static ssize_t uinput_read(struct file *
struct uinput_device *udev = file-private_data;
int retval = 0;
- if (!test_bit(UIST_CREATED, (udev-state)))
+ if (!test_bit(UIST_CREATED, udev-state))
return -ENODEV;
- if ((udev-head == udev-tail) (file-f_flags O_NONBLOCK))
+
Re: CheckFS: Checkpoints and Block Level Incremental Backup (BLIB)
On Sunday 24 Jul 2005 8:44 pm, Jan Engelhardt wrote: Maybe you want to put your development machines on ext*2* while doing this ;-). Or perhaps reiserfs/xfs/something. Or perhaps into at the VFS level, so any fs can benefit from it. We thought about that. While it's possible to do that, it would need hooks into all filesystems etc. Definitely worth trying once we get some more basic stuff working for ext3 After all the things that need to be saved at the time of taking a checkpoint for any filesystem would be the superblock and inode table (or their equivalents). Everything else is automatically taken care of. -Amit - 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: kernel 2.6 speed
Thanks guys for your help. I should have asked you this right from the beginning. :) Ciprian __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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/
[patch 21/24] psmouse: wheel mice always have middle button
From: Vojtech Pavlik [EMAIL PROTECTED]
Input: psmouse - wheel mice (imps, exps) always have 3rd button
There are wheel mice that respond to Logitech probes and report
that they have only 2 buttons (such as e-Aser mouse) and this
stops the wheel from being used as a middle button. Change the
driver to always report BTN_MIDDLE capability if a wheel is
present.
Also, never reset BTN_RIGHT capability in logips2pp code - there
are no Logitech mice that have only one button and if some other
mice happen to respond to Logitech's query we could do the wrong
thing.
Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED]
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/input/mouse/logips2pp.c|2 --
drivers/input/mouse/psmouse-base.c |2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
Index: work/drivers/input/mouse/logips2pp.c
===
--- work.orig/drivers/input/mouse/logips2pp.c
+++ work/drivers/input/mouse/logips2pp.c
@@ -385,8 +385,6 @@ int ps2pp_init(struct psmouse *psmouse,
if (buttons 3)
clear_bit(BTN_MIDDLE, psmouse-dev.keybit);
- if (buttons 2)
- clear_bit(BTN_RIGHT, psmouse-dev.keybit);
if (model_info)
ps2pp_set_model_properties(psmouse, model_info,
use_ps2pp);
Index: work/drivers/input/mouse/psmouse-base.c
===
--- work.orig/drivers/input/mouse/psmouse-base.c
+++ work/drivers/input/mouse/psmouse-base.c
@@ -344,6 +344,7 @@ static int intellimouse_detect(struct ps
return -1;
if (set_properties) {
+ set_bit(BTN_MIDDLE, psmouse-dev.keybit);
set_bit(REL_WHEEL, psmouse-dev.relbit);
if (!psmouse-vendor) psmouse-vendor = Generic;
@@ -376,6 +377,7 @@ static int im_explorer_detect(struct psm
return -1;
if (set_properties) {
+ set_bit(BTN_MIDDLE, psmouse-dev.keybit);
set_bit(REL_WHEEL, psmouse-dev.relbit);
set_bit(BTN_SIDE, psmouse-dev.keybit);
set_bit(BTN_EXTRA, psmouse-dev.keybit);
-
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/
[PATCH] DVB: rename lgdt3302 frontend module to lgdt330x
This patch depends on the following patches to be applied first in order
to apply cleanly:
01-lgdt3302-isolate-tuner.patch
02-lgdt3302-rf-input.patch
03-lgdt3302-suppress-compile-warning.patch
04-cx88-dvb-cleanup.patch
[-mm PATCH] v4l: hybrid dvb: fix warnings with -Wundef
[-mm PATCH] v4l: hybrid dvb: move #defines to Makefile
[-mm PATCH] v4l: hybrid dvb: rename CFLAGS from CONFIG_DVB_ back to
original HAVE_
I am listing these because I haven't seen any of these in -mm-commits
mailing list yet. (No commits at all for a week or so)
I am changing the name of this module now so that hopefully the name
will be changed before the release of 2.6.13 ... It wouldn't make sense
to release 2.6.13 with the name lgdt3302 in it, which will only be
renamed to lgdt330x in later versions.
Andrew-
If you, for any reason, don't want to send my #ifdef changes to 2.6.13
right away, just let me know and I'll regenerate these patches such that
the #ifdef patches aren't a prerequisite... Although it would just be a
lot easier to merge all of the patches above...
Rename lgdt3302 to lgdt330x, to make way for the addition of lgdt3303
support in future revisions.
Signed-off-by: Michael Krufky [EMAIL PROTECTED]
linux/drivers/media/dvb/frontends/Kconfig |4
linux/drivers/media/dvb/frontends/Makefile|2
linux/drivers/media/dvb/frontends/lgdt3302.c | 607 --
linux/drivers/media/dvb/frontends/lgdt3302.h | 49 -
linux/drivers/media/dvb/frontends/lgdt3302_priv.h | 72 -
linux/drivers/media/dvb/frontends/lgdt330x.c | 606 +
linux/drivers/media/dvb/frontends/lgdt330x.h | 49 +
linux/drivers/media/dvb/frontends/lgdt330x_priv.h | 70 +
linux/drivers/media/video/Kconfig |2
linux/drivers/media/video/cx88/Makefile |4
linux/drivers/media/video/cx88/cx88-dvb.c | 29
linux/drivers/media/video/cx88/cx88-i2c.c |4
12 files changed, 747 insertions(+), 751 deletions(-)
diff -u linux-2.6.13/drivers/media/video/cx88/cx88-dvb.c
linux/drivers/media/video/cx88/cx88-dvb.c
--- linux-2.6.13/drivers/media/video/cx88/cx88-dvb.c2005-07-25
02:37:22.0 +
+++ linux/drivers/media/video/cx88/cx88-dvb.c 2005-07-25 02:41:15.0
+
@@ -1,5 +1,5 @@
/*
- * $Id: cx88-dvb.c,v 1.52 2005/07/24 22:12:47 mkrufky Exp $
+ * $Id: cx88-dvb.c,v 1.54 2005/07/25 05:13:50 mkrufky Exp $
*
* device driver for Conexant 2388x based TV cards
* MPEG Transport Stream (DVB) routines
@@ -31,7 +31,6 @@
#include linux/suspend.h
#include linux/config.h
-
#include cx88.h
#include dvb-pll.h
@@ -45,8 +44,8 @@
#ifdef HAVE_OR51132
# include or51132.h
#endif
-#ifdef HAVE_LGDT3302
-# include lgdt3302.h
+#ifdef HAVE_LGDT330X
+# include lgdt330x.h
#endif
MODULE_DESCRIPTION(driver for cx2388x based DVB cards);
@@ -207,8 +206,8 @@
};
#endif
-#ifdef HAVE_LGDT3302
-static int lgdt3302_pll_set(struct dvb_frontend* fe,
+#ifdef HAVE_LGDT330X
+static int lgdt330x_pll_set(struct dvb_frontend* fe,
struct dvb_frontend_parameters* params,
u8* pllbuf)
{
@@ -220,7 +219,7 @@
return 0;
}
-static int lgdt3302_pll_rf_set(struct dvb_frontend* fe, int index)
+static int lgdt330x_pll_rf_set(struct dvb_frontend* fe, int index)
{
struct cx8802_dev *dev= fe-dvb-priv;
struct cx88_core *core = dev-core;
@@ -233,7 +232,7 @@
return 0;
}
-static int lgdt3302_set_ts_param(struct dvb_frontend* fe, int is_punctured)
+static int lgdt330x_set_ts_param(struct dvb_frontend* fe, int is_punctured)
{
struct cx8802_dev *dev= fe-dvb-priv;
if (is_punctured)
@@ -243,10 +242,10 @@
return 0;
}
-static struct lgdt3302_config fusionhdtv_3_gold = {
+static struct lgdt330x_config fusionhdtv_3_gold = {
.demod_address= 0x0e,
- .pll_set = lgdt3302_pll_set,
- .set_ts_params= lgdt3302_set_ts_param,
+ .pll_set = lgdt330x_pll_set,
+ .set_ts_params= lgdt330x_set_ts_param,
};
#endif
@@ -297,7 +296,7 @@
dev-core-i2c_adap);
break;
#endif
-#ifdef HAVE_LGDT3302
+#ifdef HAVE_LGDT330X
case CX88_BOARD_DVICO_FUSIONHDTV_3_GOLD_Q:
dev-ts_gen_cntrl = 0x08;
{
@@ -310,10 +309,10 @@
mdelay(200);
/* Select RF connector callback */
- fusionhdtv_3_gold.pll_rf_set = lgdt3302_pll_rf_set;
+ fusionhdtv_3_gold.pll_rf_set = lgdt330x_pll_rf_set;
dev-core-pll_addr = 0x61;
dev-core-pll_desc = dvb_pll_microtune_4042;
- dev-dvb.frontend = lgdt3302_attach(fusionhdtv_3_gold,
+ dev-dvb.frontend = lgdt330x_attach(fusionhdtv_3_gold,
dev-core-i2c_adap);
}
break;
@@ -329,7
[patch 22/24] i8042 - dont use negation in i8042_command()
Input: i8042 - don't use negation to mark AUX data
Currently i8042_command() negates data coming from the AUX port
of keyboard controller; this is not a very reliable indicator.
Change i8042_command() to fail if response to I8042_CMD_AUX_LOOP
is not coming from AUX channel and get rid of negation.
Based on patch by Vojtech Pavlik.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/input/serio/i8042.c | 62 +++-
1 files changed, 33 insertions(+), 29 deletions(-)
Index: work/drivers/input/serio/i8042.c
===
--- work.orig/drivers/input/serio/i8042.c
+++ work/drivers/input/serio/i8042.c
@@ -100,7 +100,7 @@ struct i8042_port {
static struct i8042_port i8042_ports[I8042_NUM_PORTS] = {
{
.disable= I8042_CTR_KBDDIS,
- .irqen = I8042_CTR_KBDINT,
+ .irqen = I8042_CTR_KBDINT,
.mux= -1,
.name = KBD,
},
@@ -191,41 +191,45 @@ static int i8042_flush(void)
static int i8042_command(unsigned char *param, int command)
{
unsigned long flags;
- int retval = 0, i = 0;
+ int i, retval, auxerr = 0;
if (i8042_noloop command == I8042_CMD_AUX_LOOP)
return -1;
spin_lock_irqsave(i8042_lock, flags);
- retval = i8042_wait_write();
- if (!retval) {
- dbg(%02x - i8042 (command), command 0xff);
- i8042_write_command(command 0xff);
- }
+ if ((retval = i8042_wait_write()))
+ goto out;
- if (!retval)
- for (i = 0; i ((command 12) 0xf); i++) {
- if ((retval = i8042_wait_write())) break;
- dbg(%02x - i8042 (parameter), param[i]);
- i8042_write_data(param[i]);
- }
+ dbg(%02x - i8042 (command), command 0xff);
+ i8042_write_command(command 0xff);
- if (!retval)
- for (i = 0; i ((command 8) 0xf); i++) {
- if ((retval = i8042_wait_read())) break;
- if (i8042_read_status() I8042_STR_AUXDATA)
- param[i] = ~i8042_read_data();
- else
- param[i] = i8042_read_data();
- dbg(%02x - i8042 (return), param[i]);
+ for (i = 0; i ((command 12) 0xf); i++) {
+ if ((retval = i8042_wait_write()))
+ goto out;
+ dbg(%02x - i8042 (parameter), param[i]);
+ i8042_write_data(param[i]);
+ }
+
+ for (i = 0; i ((command 8) 0xf); i++) {
+ if ((retval = i8042_wait_read()))
+ goto out;
+
+ if (command == I8042_CMD_AUX_LOOP
+ !(i8042_read_status() I8042_STR_AUXDATA)) {
+ retval = auxerr = -1;
+ goto out;
}
- spin_unlock_irqrestore(i8042_lock, flags);
+ param[i] = i8042_read_data();
+ dbg(%02x - i8042 (return), param[i]);
+ }
if (retval)
- dbg( -- i8042 (timeout));
+ dbg( -- i8042 (%s), auxerr ? auxerr : timeout);
+ out:
+ spin_unlock_irqrestore(i8042_lock, flags);
return retval;
}
@@ -507,17 +511,17 @@ static int i8042_set_mux_mode(unsigned i
*/
param = 0xf0;
- if (i8042_command(param, I8042_CMD_AUX_LOOP) || param != 0x0f)
+ if (i8042_command(param, I8042_CMD_AUX_LOOP) || param != 0xf0)
return -1;
param = mode ? 0x56 : 0xf6;
- if (i8042_command(param, I8042_CMD_AUX_LOOP) || param != (mode ? 0xa9
: 0x09))
+ if (i8042_command(param, I8042_CMD_AUX_LOOP) || param != (mode ? 0x56
: 0xf6))
return -1;
param = mode ? 0xa4 : 0xa5;
- if (i8042_command(param, I8042_CMD_AUX_LOOP) || param == (mode ? 0x5b
: 0x5a))
+ if (i8042_command(param, I8042_CMD_AUX_LOOP) || param == (mode ? 0xa4
: 0xa5))
return -1;
if (mux_version)
- *mux_version = ~param;
+ *mux_version = param;
return 0;
}
@@ -619,7 +623,7 @@ static int __init i8042_check_aux(void)
*/
param = 0x5a;
- if (i8042_command(param, I8042_CMD_AUX_LOOP) || param != 0xa5) {
+ if (i8042_command(param, I8042_CMD_AUX_LOOP) || param != 0x5a) {
/*
* External connection test - filters out AT-soldered PS/2 i8042's
@@ -630,7 +634,7 @@ static int __init i8042_check_aux(void)
*/
if (i8042_command(param, I8042_CMD_AUX_TEST)
- || (param param != 0xfa param != 0xff))
+ || (param param != 0xfa param != 0xff))
return -1;
}
-
To unsubscribe from this list: send the line
Re: 2.6.11-rc5 and 2.6.12: cannot transmit anything
On Monday 25 July 2005 08:28, David S. Miller wrote: Probably your link is never coming up. We won't send packets over the wire unless the device is in the link-up state. However, if -dequeue() is returning NULL, there really aren't any packets in the device queue to be sent. If you want, add more tracing to pfifo_fast_dequeue() since that's almost certainly which queueing discipline is hooked up to your VIA Rhine device as it's the default. Will do. -- vda - 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/
[patch 07/24] input: rearrange procfs code
Input: rearrange procfs code to reduce number of #ifdefs
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/input/input.c | 389 +-
1 files changed, 198 insertions(+), 191 deletions(-)
Index: work/drivers/input/input.c
===
--- work.orig/drivers/input/input.c
+++ work/drivers/input/input.c
@@ -48,12 +48,6 @@ static LIST_HEAD(input_handler_list);
static struct input_handler *input_table[8];
-#ifdef CONFIG_PROC_FS
-static struct proc_dir_entry *proc_bus_input_dir;
-static DECLARE_WAIT_QUEUE_HEAD(input_devices_poll_wait);
-static int input_devices_state;
-#endif
-
void input_event(struct input_dev *dev, unsigned int type, unsigned int code,
int value)
{
struct input_handle *handle;
@@ -312,6 +306,7 @@ static struct input_device_id *input_mat
return NULL;
}
+
/*
* Input hotplugging interface - loading event handlers based on
* device bitfields.
@@ -428,6 +423,177 @@ static void input_call_hotplug(char *ver
#endif
+#ifdef CONFIG_PROC_FS
+
+static struct proc_dir_entry *proc_bus_input_dir;
+static DECLARE_WAIT_QUEUE_HEAD(input_devices_poll_wait);
+static int input_devices_state;
+
+static inline void input_wakeup_procfs_readers(void)
+{
+ input_devices_state++;
+ wake_up(input_devices_poll_wait);
+}
+
+static unsigned int input_devices_poll(struct file *file, poll_table *wait)
+{
+ int state = input_devices_state;
+ poll_wait(file, input_devices_poll_wait, wait);
+ if (state != input_devices_state)
+ return POLLIN | POLLRDNORM;
+ return 0;
+}
+
+#define SPRINTF_BIT_B(bit, name, max) \
+ do { \
+ len += sprintf(buf + len, B: %s, name); \
+ for (i = NBITS(max) - 1; i = 0; i--) \
+ if (dev-bit[i]) break; \
+ for (; i = 0; i--) \
+ len += sprintf(buf + len, %lx , dev-bit[i]); \
+ len += sprintf(buf + len, \n); \
+ } while (0)
+
+#define SPRINTF_BIT_B2(bit, name, max, ev) \
+ do { \
+ if (test_bit(ev, dev-evbit)) \
+ SPRINTF_BIT_B(bit, name, max); \
+ } while (0)
+
+static int input_devices_read(char *buf, char **start, off_t pos, int count,
int *eof, void *data)
+{
+ struct input_dev *dev;
+ struct input_handle *handle;
+
+ off_t at = 0;
+ int i, len, cnt = 0;
+
+ list_for_each_entry(dev, input_dev_list, node) {
+
+ len = sprintf(buf, I: Bus=%04x Vendor=%04x Product=%04x
Version=%04x\n,
+ dev-id.bustype, dev-id.vendor, dev-id.product,
dev-id.version);
+
+ len += sprintf(buf + len, N: Name=\%s\\n, dev-name ?
dev-name : );
+ len += sprintf(buf + len, P: Phys=%s\n, dev-phys ? dev-phys
: );
+ len += sprintf(buf + len, H: Handlers=);
+
+ list_for_each_entry(handle, dev-h_list, d_node)
+ len += sprintf(buf + len, %s , handle-name);
+
+ len += sprintf(buf + len, \n);
+
+ SPRINTF_BIT_B(evbit, EV=, EV_MAX);
+ SPRINTF_BIT_B2(keybit, KEY=, KEY_MAX, EV_KEY);
+ SPRINTF_BIT_B2(relbit, REL=, REL_MAX, EV_REL);
+ SPRINTF_BIT_B2(absbit, ABS=, ABS_MAX, EV_ABS);
+ SPRINTF_BIT_B2(mscbit, MSC=, MSC_MAX, EV_MSC);
+ SPRINTF_BIT_B2(ledbit, LED=, LED_MAX, EV_LED);
+ SPRINTF_BIT_B2(sndbit, SND=, SND_MAX, EV_SND);
+ SPRINTF_BIT_B2(ffbit, FF=, FF_MAX, EV_FF);
+
+ len += sprintf(buf + len, \n);
+
+ at += len;
+
+ if (at = pos) {
+ if (!*start) {
+ *start = buf + (pos - (at - len));
+ cnt = at - pos;
+ } else cnt += len;
+ buf += len;
+ if (cnt = count)
+ break;
+ }
+ }
+
+ if (dev-node == input_dev_list)
+ *eof = 1;
+
+ return (count cnt) ? cnt : count;
+}
+
+static int input_handlers_read(char *buf, char **start, off_t pos, int count,
int *eof, void *data)
+{
+ struct input_handler *handler;
+
+ off_t at = 0;
+ int len = 0, cnt = 0;
+ int i = 0;
+
+ list_for_each_entry(handler, input_handler_list, node) {
+
+ if (handler-fops)
+ len = sprintf(buf, N: Number=%d Name=%s Minor=%d\n,
+ i++, handler-name, handler-minor);
+ else
+ len = sprintf(buf, N: Number=%d Name=%s\n,
+ i++, handler-name);
+
+ at += len;
+
+ if (at = pos) {
+ if (!*start) {
+ *start = buf + (pos - (at - len));
+
[patch 18/24] joydev - remove MSECS macro
From: Tobias Klauser [EMAIL PROTECTED]
Input: joydev - remove custom conversion from jiffies to msecs
Replace the MSECS() macro with the jiffies_to_msecs() function provided
in jiffies.h
Signed-off-by: Tobias Klauser [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED]
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/input/joydev.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
Index: work/drivers/input/joydev.c
===
--- work.orig/drivers/input/joydev.c
+++ work/drivers/input/joydev.c
@@ -37,8 +37,6 @@ MODULE_LICENSE(GPL);
#define JOYDEV_MINORS 16
#define JOYDEV_BUFFER_SIZE 64
-#define MSECS(t) (1000 * ((t) / HZ) + 1000 * ((t) % HZ) / HZ)
-
struct joydev {
int exist;
int open;
@@ -117,7 +115,7 @@ static void joydev_event(struct input_ha
return;
}
- event.time = MSECS(jiffies);
+ event.time = jiffies_to_msecs(jiffies);
list_for_each_entry(list, joydev-list, node) {
@@ -245,7 +243,7 @@ static ssize_t joydev_read(struct file *
struct js_event event;
- event.time = MSECS(jiffies);
+ event.time = jiffies_to_msecs(jiffies);
if (list-startup joydev-nkey) {
event.type = JS_EVENT_BUTTON | JS_EVENT_INIT;
-
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: Netlink connector
On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris ([EMAIL PROTECTED]) wrote: On Sun, 24 Jul 2005, David S. Miller wrote: From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Sat, 23 Jul 2005 13:14:55 +0400 Andrew has no objection against connector and it lives in -mm A patch sitting in -mm has zero significance. That is why I'm asking netdev@ people again... The significance I think is that Andrew is trying to gently encourage some further progress in the area. I recall some netconf discussion about TIPC over Netlink, or more likely a variation thereof, which may be a better way forward. It's cool stuff http://tipc.sourceforge.net/ I read it quite long ago - I'm sure you do not want to use that monster for event bus. It was designed and implemented for heavy intermachine communications, and it is quite hard to setup for userspace - kernelspace message bus. - James -- James Morris [EMAIL PROTECTED] -- Evgeniy Polyakov - 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/
[patch 00/24] Input patches for 2.6.13
Hi Vojtech, I have a bunch of changes for input subsystem I would like to get in. Half of the stuff is patches I picked from your quilt tree (ALPS dualpoint resume fix, ALPS tapping mode, couple HID changes, etc) plus some of my changes (usb_to_input_id, small acecad cleanup, add modalias for serio bus, couple of input cleanups). The full changelog is at the end of the mail. Could you please bless these for Linus to pull: git pull rsync://rsync.kernel.org/pub/scm/linux/kernel/git/dtor/input.git Thanks! -- Dmitry Changelog: == author Sergey Vlasov [EMAIL PROTECTED] Sun, 24 Jul 2005 10:53:32 -0500 Input: synaptics - fix setting packet size on passthrough port. Synaptics driver used child-type to select either 3-byte or 4-byte packet size for the pass-through port; this gives wrong results for the newer protocols. Change the check to use child-pktsize instead. Signed-off-by: Sergey Vlasov [EMAIL PROTECTED] Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED] -- author Vojtech Pavlik [EMAIL PROTECTED] Sun, 24 Jul 2005 10:50:03 -0500 Input: check keycodesize when adjusting keymaps When changing key mappings we need to make sure that the new keycode value can be stored in dev-keycodesize bytes. Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED] Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED] -- author Dmitry Torokhov [EMAIL PROTECTED] Fri, 15 Jul 2005 11:51:56 -0500 Input: i8042 - don't use negation to mark AUX data Currently i8042_command() negates data coming from the AUX port of keyboard controller; this is not a very reliable indicator. Change i8042_command() to fail if response to I8042_CMD_AUX_LOOP is not coming from AUX channel and get rid of negation. Based on patch by Vojtech Pavlik. Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED] -- author Vojtech Pavlik [EMAIL PROTECTED] Fri, 15 Jul 2005 11:50:08 -0500 Input: psmouse - wheel mice (imps, exps) always have 3rd button There are wheel mice that respond to Logitech probes and report that they have only 2 buttons (such as e-Aser mouse) and this stops the wheel from being used as a middle button. Change the driver to always report BTN_MIDDLE capability if a wheel is present. Also, never reset BTN_RIGHT capability in logips2pp code - there are no Logitech mice that have only one button and if some other mice happen to respond to Logitech's query we could do the wrong thing. Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED] Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED] -- author Adam Kropelin [EMAIL PROTECTED] Mon, 11 Jul 2005 11:09:32 -0500 Input: HID - only report events coming from interrupts to hiddev Currently hid-core follows the same code path for input reports regardless of whether they are a result of interrupt transfers or control transfers. That leads to interrupt events erroneously being reported to hiddev for regular control transfers. Prior to 2.6.12 the problem was mitigated by the fact that reporting to hiddev is supressed if the field value has not changed, which is often the case. Said filtering was removed in 2.6.12-rc1 which means any input reports fetched via control transfers result in hiddev interrupt events. This behavior can quickly lead to a feedback loop where a userspace app, in response to interrupt events, issues control transfers which in turn create more interrupt events. This patch prevents input reports that arrive via control transfers from being reported to hiddev as interrupt events. Signed-off-by: Adam Kropelin [EMAIL PROTECTED] Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED] Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED] -- author Michael Prokop [EMAIL PROTECTED] Mon, 11 Jul 2005 11:09:10 -0500 Input: elo - fix help in Kconfig (wrong module name) Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED] Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED] -- author Tobias Klauser [EMAIL PROTECTED] Mon, 11 Jul 2005 11:08:56 -0500 Input: joydev - remove custom conversion from jiffies to msecs Replace the MSECS() macro with the jiffies_to_msecs() function provided in jiffies.h Signed-off-by: Tobias Klauser [EMAIL PROTECTED] Signed-off-by: Domen Puncer [EMAIL PROTECTED] Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED] Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED] -- author Luca T [EMAIL PROTECTED] Mon, 11 Jul 2005 11:08:40 -0500 Input: HID - add a quirk for Aashima Trust (06d6:0025) gamepad Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED] Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED] -- author Peter Osterlund [EMAIL PROTECTED] Mon, 11 Jul 2005 11:08:04 -0500 Input: ALPS - unconditionally enable tapping mode The condition in alps_init() was also inverted and the driver was enabling tapping mode only if it was already enabled. Signed-off-by: Peter Osterlund [EMAIL PROTECTED] Signed-off-by:
[patch 24/24] Synaptics - fix setting packet size on passthrough port
From: Sergey Vlasov [EMAIL PROTECTED]
Input: synaptics - fix setting packet size on passthrough port.
Synaptics driver used child-type to select either 3-byte or 4-byte
packet size for the pass-through port; this gives wrong results for
the newer protocols. Change the check to use child-pktsize instead.
Signed-off-by: Sergey Vlasov [EMAIL PROTECTED]
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/input/mouse/synaptics.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Index: work/drivers/input/mouse/synaptics.c
===
--- work.orig/drivers/input/mouse/synaptics.c
+++ work/drivers/input/mouse/synaptics.c
@@ -219,7 +219,7 @@ static void synaptics_pass_pt_packet(str
serio_interrupt(ptport, packet[1], 0, NULL);
serio_interrupt(ptport, packet[4], 0, NULL);
serio_interrupt(ptport, packet[5], 0, NULL);
- if (child-type = PSMOUSE_GENPS)
+ if (child-pktsize == 4)
serio_interrupt(ptport, packet[2], 0, NULL);
} else
serio_interrupt(ptport, packet[1], 0, NULL);
@@ -233,7 +233,7 @@ static void synaptics_pt_activate(struct
/* adjust the touchpad to child's choice of protocol */
if (child) {
- if (child-type = PSMOUSE_GENPS)
+ if (child-pktsize == 4)
priv-mode |= SYN_BIT_FOUR_BYTE_CLIENT;
else
priv-mode = ~SYN_BIT_FOUR_BYTE_CLIENT;
-
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] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Pavel Machek wrote: Anyway, this patch is really good, and enables S3 to work on more machines. Thats good. It is not intrusive and I'll probably (try to) push it. which acpi_sleep=... parameter enables it? I have machines resuming perfectly fine without it that i don't want to break ;-) -- Stefan Seyfried \ I didn't want to write for pay. I QA / RD Team Mobile Devices \ wanted to be paid for what I write. SUSE LINUX Products GmbH, Nürnberg \-- Leonard Cohen - 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] vfree and kfree cleanup in drivers/
On Sat, 23 July 2005 22:27:58 +0200, Jesper Juhl wrote: drivers/mtd/devices/mtdram.c|3 +-- drivers/mtd/ftl.c | 11 --- This part of the patch has my blessing. Jörn -- The grand essentials of happiness are: something to do, something to love, and something to hope for. -- Allan K. Chalmers - 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/
accessing CD fs from initrd
Hi there I want to be CC-ed on a possible answer to the following question. I have not found yet an answer to the question in the Linux archives. In need access the CD filesystem (iso9660) from within the Linux initrd or right after that (make it root fs). I need an example for that since allocating enough ramdisk space (ramdisk_size=90k in kernel command line) + loading the cdrom.o module at the initrd did not help mount the CD device (/dev/cdrom) at the initrd Also I need know how to pivot between the initrd and the CD filesystem I am actually using Isolinux/syslinux, but can make test on a regular Linux . Any pointer to a literature will also be welcomed . thanks Zvi Dubitzki _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ - 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: Stripping in module
What is the best way to do this with v2.6. I have tried e.g. to remove all symbols starting with telos from the module like this (after kbuild): strip -w -K '!telos*' -K 'telosi2c_usb_driver' telosi2c_linux.ko Yes, I'd also be interested in what sections can actually be stripped, if any. Userspace shared libs for example can be `strip -s`'ed and they still work as expected, does not look like this holds for kernel modules. Jan Engelhardt -- - 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] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Anyway, this patch is really good, and enables S3 to work on more machines. Thats good. It is not intrusive and I'll probably (try to) push it. which acpi_sleep=... parameter enables it? I have machines resuming perfectly fine without it that i don't want to break ;-) I'll clean it up to add that stuff soon, but I've hit a problem with it on my main desktop, it won't come out of suspend using my patch, however vbepost in userspace works... this is very strange, as they do the same thing which is execute the VBIOS at c000:3, one does it in the kernel in REAL mode and the other does it in vm86 mode from userspace.. I think it may be calling into the real BIOS and hanging up in there.. maybe something to do with segment register setup or stacks.. (I've tried on-board i865, radeon and MGA cards)... Dave -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - 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] reset VGA adapters via BIOS on resume... (non-fbdev/con)
Dave Airlie wrote: Anyway, this patch is really good, and enables S3 to work on more machines. Thats good. It is not intrusive and I'll probably (try to) push it. which acpi_sleep=... parameter enables it? I have machines resuming perfectly fine without it that i don't want to break ;-) I'll clean it up to add that stuff soon, but I've hit a problem with it on my main desktop, it won't come out of suspend using my patch, however this is why it needs a boot-parameter :-) -- Stefan Seyfried \ I didn't want to write for pay. I QA / RD Team Mobile Devices \ wanted to be paid for what I write. SUSE LINUX Products GmbH, Nürnberg \-- Leonard Cohen - 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: diskstat 0.1: simple tool to study io patterns via relayfs
On Sun, Jul 24, 2005 at 03:07:30AM +0200, bert hubert wrote: It is with distinct lack of pride that I release version 0.1 of diskstat 'Geeks in Black Thorn', a tool that allows you to generate the kinds of graphs as presented in my OLS talk 'On faster application startup times: Cache stuffing, seek profiling, adaptive preloading'. The lack of pride is because this release is more a promise of what is to come than how things should be. The presentation, paper, and software can be found on http://ds9a.nl/diskstat and http://ds9a.nl/diskstat/diskstat-0.1.tar.gz From the README: The quality of this code is abysmal, for which I squarely blame the fun people at OLS who've been keeping me from my code! (...) The next version will be based on k/jprobes, and will make better use of relayfs features. This also means you won't have to patch your kernel anymore, as long as you compiled with kprobes support. Hi, I had some trouble compiling it, I figured out that one needs libboost, but then I've also discovered that g++-3.4.4 and g++-4.0.1 don't want to compile it while g++-3.3.5 works. (FYI, all of these were Ubuntu versions) You might want to document some of this in the README :) Thanks, Sonny - 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: Lack of Documentation about SA_RESTART...
On Sun, 24 Jul 2005 10:56:08 -0400 Theodore Ts'o [EMAIL PROTECTED] wrote: The spect says unless otherwise specified. The description for pause() states that the process will sleep until receiving a signal that terminates the process or causes it to call signal-handling function. That would presumably count as an otherwise specified. I don't think that way for at least 2 reasons: 1) SA_RESTART is an XSI extension, so every exception to the rule everything automatically restarted should be under an XSI section (like it is on the select() page). 2) The same thing that you claim for pause() (that isn't restarted) can be claimed for other syscalls that _ARE_ restarted. Example: wait() SUSV3 DOC: ... The wait() function shall suspend execution of the calling thread until status information for one of the terminated child processes of the calling process is available, or until delivery of a signal whose action is either to execute a signal-catching function or to terminate the process ... And wait() is actually RESTARTED because: - it makes sense - FreeBSD sigaction() mapage says it is retarted - Linux does it (see kernel/exit.c) ... retval = -ERESTARTSYS; if (signal_pending(current)) goto end; ... See? -- Paolo Ornati Linux 2.6.13-rc3 on x86_64 - 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/
[PATCH] I2C: ds1337 - fix 12/24 hour mode bug
DS1339 manual, page 6, chapter Date and time operation: The DS1339 can be run in either 12-hour or 24-hour mode. Bit 6 of the hours register is defined as the 12-hour or 24-hour mode-select bit. When high, the 12-hour mode is selected. Patch below makes ds1337 driver work as documented in manual. Signed-off-by: Ladislav Michl [EMAIL PROTECTED] drivers/i2c/chips/ds1337.c: needs update Index: drivers/i2c/chips/ds1337.c === --- 19f75ba1af6b4b16744159e62fbb7decab5553ef/drivers/i2c/chips/ds1337.c (mode:100644) +++ uncommitted/drivers/i2c/chips/ds1337.c (mode:100644) @@ -165,7 +165,7 @@ buf[0] = 0; /* reg offset */ buf[1] = BIN2BCD(dt-tm_sec); buf[2] = BIN2BCD(dt-tm_min); - buf[3] = BIN2BCD(dt-tm_hour) | (1 6); + buf[3] = BIN2BCD(dt-tm_hour); buf[4] = BIN2BCD(dt-tm_wday) + 1; buf[5] = BIN2BCD(dt-tm_mday); buf[6] = BIN2BCD(dt-tm_mon) + 1; @@ -344,9 +344,9 @@ /* Ensure that device is set in 24-hour mode */ val = i2c_smbus_read_byte_data(client, DS1337_REG_HOUR); - if ((val = 0) (val (1 6)) == 0) + if ((val = 0) (val (1 6))) i2c_smbus_write_byte_data(client, DS1337_REG_HOUR, - val | (1 6)); + val 0x3f); } static int ds1337_detach_client(struct i2c_client *client) - 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/
int pci_register_driver(pci_driver) and void driver_attach(struct device_driver * drv)
kernel: 2.6.11.10 Currently writting down a pci driver, I notice that pci_register_driver(pci_driver) don't forward my probe function errors. Actually errors are noticed in the kernel ring buffer but don't make pci_register_driver fail. It returns a zero value in any case. I traced back to the kernel in order to try to understand this problem and find the void driver_attach(struct device_driver * drv) function in the linux-2.6.11.10/drivers/base/bus.c file which, obviously, can not returns an error. So I just wish to know why this function only print this message : /* driver matched but the probe failed */ printk(KERN_WARNING %s: probe of %s failed with error %d\n, drv-name, dev-bus_id, error); but don't return the error. Actually I don't understand why the module is loaded (because pci_register_driver, which is called during __init, don't fail) while my pci card could not have been initialized by probe function because it failed for such reasons. Thanks -- Loïc Martin - 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: xor as a lazy comparison
On Sun, 2005-07-24 at 18:15 -0400, Puneet Vyas wrote: [...] I just compiled two identical program , one with != and other with ^. The assembly output is identical. Hmm, which compiler and which version? You might want to try much older and other compilers. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - 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/
[patch] Stop the nand functions triggering false softlockup reports
Stop the nand functions triggering false softlockup reports.
Signed-off-by: Richard Purdie [EMAIL PROTECTED]
Index: linux-2.6.12/drivers/mtd/nand/nand_base.c
===
--- linux-2.6.12.orig/drivers/mtd/nand/nand_base.c 2005-07-24
18:49:35.0 +0100
+++ linux-2.6.12/drivers/mtd/nand/nand_base.c 2005-07-25 09:31:51.0
+0100
@@ -526,6 +526,7 @@
do {
if (this-dev_ready(mtd))
return;
+ touch_softlockup_watchdog();
} while (time_before(jiffies, timeo));
}
-
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: Memory Management
Hello, At Sun, 24 Jul 2005 22:40:19 -0300, Márcio Oliveira wrote: I'm using the kernel-source package and trying to compiling the source (in /usr/src/linux-2.4 directory) with make config, make dep, make clean, make bzImage, make modules and make modules_install. I also try to compile a RHEL3 kernel-source without the sysrq-m changes on other RHEL3 systems and get the same errors... I wonder if the topic is suitable for the list... Anyway, I think make mrproper is required before make config for the Red Hat kernel-source package. The reason may be described in http://people.redhat.com/dledford/README.mod_devel_kit_theory.html Regards, Seiji Kihara NTT Laboratories, Japan - 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/
help! kernel errors?
Hello, I'm getting loads and loads of kernel errors in my syslog, but am unable to decipher them into anything meaningful. It occurs during a backup procedure and looking at the error it's got something to do with process 'rsync' but I haven't got a clue what's going wrong here (hardware? drivers? modules? kernel? what?). I'm hoping you guys can help me out. The repeating error is attached below! Thanks so much in advance, - Mark Jul 24 23:24:51 server kernel: Unable to handle kernel paging request at virtual address 04003428 Jul 24 23:24:51 server kernel: printing eip: Jul 24 23:24:51 server kernel: c014f3e8 Jul 24 23:24:51 server kernel: *pde = Jul 24 23:24:51 server kernel: Oops: Jul 24 23:24:51 server kernel: CPU:0 Jul 24 23:24:51 server kernel: EIP:0010:[c014f3e8]Not tainted Jul 24 23:24:51 server kernel: EFLAGS: 00010213 Jul 24 23:24:51 server kernel: eax: 0015422f ebx: 04003400 ecx: 000f edx: c144 Jul 24 23:24:51 server kernel: esi: edi: c1453fa8 ebp: 0015422e esp: c329de34 Jul 24 23:24:51 server kernel: ds: 0018 es: 0018 ss: 0018 Jul 24 23:24:51 server kernel: Process rsync (pid: 29653, stackpage=c329d000) Jul 24 23:24:51 server kernel: Stack: 00e4 d8a18040 0002 0015422e 0002 cf313000 c99e0b00 c014f641 Jul 24 23:24:51 server kernel:cf313000 0015422e c1453fa8 fff3 c99e0b00 c329de8c Jul 24 23:24:51 server kernel:d8a1147a cf313000 0002 0001075a 0001075a 0286 0020 Jul 24 23:24:51 server kernel: Call Trace:[c014f641] [d8a1147a] [c0143bc7] [c01444a8] [c01448f9] Jul 24 23:24:51 server kernel: [c0144d60] [c0138e63] [c0139213] [c0108c87] Jul 24 23:24:51 server kernel: Jul 24 23:24:51 server kernel: Code: 39 6b 28 89 de 75 f1 8b 44 24 20 39 83 a0 00 00 00 75 e5 8b - 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] Dynamic tick for x86 version 050610-1
* Benjamin Herrenschmidt [EMAIL PROTECTED] [050719 06:55]: On Tue, 2005-07-19 at 14:51 +0800, [EMAIL PROTECTED] wrote: On Sat, Jun 18, 2005 at 04:30:32PM +1000, Benjamin Herrenschmidt wrote: I'm try to port it powerpc, Here is a patch. Port Dynamic Tick Timer to new platform is easy. :) 1) Find the reprogram timer interface. 2) do a hook in the idle function. That worked on my PowerBookG4 12'. Did you get a measurable gain on power consumption ? Last time I toyed with this, I didn't. Today I do a measurable about it. First I using 2.6.12 without dynamic enable and unplug the AC power, I check the /proc/pmu/battery_0, like this. -- flags : 0011 charge : 907 max_charge : 2863 current: -987 voltage: 10950 time rem. : 3600 -- I only intresting with current, that show the system power load. When I enable dynamic, The current can low at -900. The numbers are repeatable ? I mean, if you actually let it settle down in both cases ? Also, you should be careful about parasites in the measurement, like pbbuttons dimming the backlight, the hard disk going to sleep etc... From your numbers you get something like 10% improvement, which isn't too bad. Just quick update here, I'm back from vacation and will try to post updated dyn-tick patch soon with the PPC patch integrated. Tony - 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.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
* Voluspa [EMAIL PROTECTED] [050722 11:46]: On Fri, 22 Jul 2005 20:02:36 +0200 Pavel Machek wrote: will not help. It seems like your machine is simply not able to do reasonable powersaving. Digging up this patch from last month regarding C2 on a AMD K7 implies that the whole blame can be put on kernel acpi: http://marc.theaimsgroup.com/?l=linux-kernelm=111933745131301w=2 AFAIK Linux ACPI expects BIOS to contain all the necessary stuff to enable C2 and C3. Otherwise they won't get enabled, and you have to create a custom module like the amd76x_pm is. There's been some talk on adding a module to enable C2 and C3 states for various chipsets, but nobody seems to have enough time to do it... Tony - 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: accessing CD fs from initrd
Le Monday 25 July 2005 09:27, zvi Dubitzki(zvi Dubitzki [EMAIL PROTECTED]) disait: Hello, In need access the CD filesystem (iso9660) from within the Linux initrd or right after that (make it root fs). I need an example for that since allocating enough ramdisk space (ramdisk_size=90k in kernel command line) + loading the cdrom.o module at the initrd did not help mount the CD device (/dev/cdrom) at the initrd Also I need know how to pivot between the initrd and the CD filesystem 'MkCDrec' makes a bootable CDs. Have look at it. It uses shells scripts only. So, it's easy to understand. If you want, I can mail you the initrd made by those scripts! If you're using Debian, have a look at bootcd-mkinitrd package ! I suppose any live CDs based distributions (like knopix) do such things too By the way, this is not the correct ML for these questions. Please use a list based on your GNU/Linux distribution ! -- Glennie Personne ne survit au fait d'être estimé au-dessus de sa valeur. - 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: help! kernel errors?
I'm sorry, here's some info on the backup procedure and system info: The backup script mounts an smbfs filesystem (smbmnt v2.2.10) over a direct (crosslink) 1000mbps link and uses rsync to backup the remote files from the mountpoint to a local removable disk. (yeah I know. I tried nfs, but it's a pain in the butt on Winblows. Better ideas/suggestions are welcome!) The removable disk is a Maxtor 6Y120P0 120GB drive in a Promise SuperSWAP 1000 bay connected to a Promise TX2000 ATA RAID card. Using kernel module 'FastTrak' built from the latest PROMISE FastTrak Series Linux Driver source. The backup was running flawlessly until a month ago. I updated the kernel (as can be seen below) but to no avail. Now, the backup runs ok for quite some time.. when it started spitting the errors it had already transferred 65GB of data. Thanks for any pointers in the right direction! # /usr/src/linux-2.4.31/scripts/ver_linux Linux server 2.4.31 #1 Thu Jul 7 12:19:58 CEST 2005 i686 unknown unknown GNU/Linux Gnu C 3.2.3 Gnu make 3.80 util-linux 2.12 mount 2.12 modutils 2.4.25 e2fsprogs 1.34 jfsutils 1.1.3 xfsprogs 2.5.6 pcmcia-cs 3.2.5 quota-tools3.09. PPP2.4.1 Linux C Library2.3.2 Dynamic linker (ldd) 2.3.2 Linux C++ Library 5.0.3 Procps 2.0.16 Net-tools 1.60 Kbd1.08 Sh-utils 5.0 Modules Loaded ide-scsi natsemi crc32 ns83820 agpgart FastTrak # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 0 model name : Intel(R) Pentium(R) 4 CPU 1400MHz stepping: 10 cpu MHz : 1399.990 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips: 2791.83 # cat /proc/modules ide-scsi 10288 0 natsemi16800 1 crc32 2880 0 [natsemi] ns8382012268 1 agpgart40440 0 (unused) FastTrak 94692 0 # cat /proc/ioports -001f : dma1 0020-003f : pic1 0040-0043 : timer0 0050-0053 : timer1 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 01f0-01f7 : ide0 02f8-02ff : serial(auto) 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0500-050f : Intel Corp. 82801BA/BAM SMBus 0cf8-0cff : PCI conf1 9000-9007 : Promise Technology, Inc. PDC20271 9000-9007 : ide2 9400-9403 : Promise Technology, Inc. PDC20271 9402-9402 : ide2 9800-9807 : Promise Technology, Inc. PDC20271 9800-9807 : FT(base) 9c00-9c03 : Promise Technology, Inc. PDC20271 9c02-9c02 : FT(ctrl) a000-a00f : Promise Technology, Inc. PDC20271 a000-a007 : ide2 a008-a00f : ide3 a400-a4ff : National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller a400-a4ff : eth1 a800-a8ff : National Semiconductor Corporation DP83820 10/100/1000 Ethernet Controller f000-f00f : Intel Corp. 82801BA IDE U100 f000-f007 : ide0 f008-f00f : ide1 # cat /proc/iomem -0009fbff : System RAM 0009fc00-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000d-000d97ff : Extension ROM 000f-000f : System ROM 0010-17ff : System RAM 0010-002e1a28 : Kernel code 002e1a29-00379e03 : Kernel data e000-e3ff : Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge e400-e5ff : PCI Bus #01 e400-e5ff : nVidia Corporation NV5M64 [RIVA TNT2 Model 64/Model 64 Pro] e600-e7ff : PCI Bus #01 e600-e6ff : nVidia Corporation NV5M64 [RIVA TNT2 Model 64/Model 64 Pro] e900-e900 : Promise Technology, Inc. PDC20271 e901-e9010fff : National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller e901-e9010fff : eth1 e9011000-e9011fff : National Semiconductor Corporation DP83820 10/100/1000 Ethernet Controller fec0-fec00fff : reserved fee0-fee00fff : reserved ffb0- : reserved # lspci -vvv 00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 03) Subsystem: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 Region 0: Memory at e000 (32-bit, prefetchable) [size=64M] Capabilities: [e4] #09 [0104] Capabilities: [a0] AGP version 2.0 Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+
Re: [2.6.12.3] dyntick 050610-1 breaks makes S3 suspend
* Christian Hesse [EMAIL PROTECTED] [050723 05:51]: On Saturday 23 July 2005 14:35, Jan De Luyck wrote: Hello, I recently tried out dyntick 050610-1 against 2.6.12.3, works great, it actually makes a noticeable difference on my laptop's battery life. I don't have hard numbers, lets just say that instead of the usual ~3 hours i get out of it, i was ~4 before it started nagging, usual use pattern at work. The only gripe I have with it that it stops S3 from working. If the patch is compiled in the kernel, it makes S3 suspend correctly, but resuming goes into a solid hang (nothing get's it back alive, have to keep the powerbutton for ~5 secs to shutdown the system) Anything I could test? The logs don't give anything useful.. I reported this some time ago [1], but there's no sulution so far... [1] http://groups.google.com/groups?selm=4b4NI-7mJ-9%40gated-at.bofh.it In theory it should not happen... And it's working on my laptop for resume just fine with dyntick on. Can you try it without APIC support? Maybe that's the differerence again. (I don't have APIC on my laptop) Also a workaround is to disable dyntick before suspend with: # echo 0 /sys/devices/system/timer/timer0/dyn_tick_state and then enable it again after resume. Tony - 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: 10 GB in Opteron machine
Hello, I now could compile the amd64-kernel successfully. I installed it on my machine, rebooted and in the beginning everything seemed fine. But after mounting the root (ext 3) filesystem (or before mounting, I do not know exactly) the machine hangs. The last message I see is: Mounting root filesystem, starting kjournald. What can I do now? Christoph - 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.12 Boot Hang Disabled IRQ 11
Hi all, I downloaded and compiled 2.6.12 yesterday, I am currently running 2.6.7-rc3. The boot eventually hangs (irq 11, nobody cared) but since the disks aren't mounted yet I have no dmesg output. So, before I can provide a decent report I need some way of getting this output, is there a better way than simply copying it down from the terminal? Ta, n - 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.12.3] dyntick 050610-1 breaks makes S3 suspend
On Monday 25 July 2005 12:27, Tony Lindgren wrote: * Christian Hesse [EMAIL PROTECTED] [050723 05:51]: On Saturday 23 July 2005 14:35, Jan De Luyck wrote: Hello, I recently tried out dyntick 050610-1 against 2.6.12.3, works great, it actually makes a noticeable difference on my laptop's battery life. I don't have hard numbers, lets just say that instead of the usual ~3 hours i get out of it, i was ~4 before it started nagging, usual use pattern at work. The only gripe I have with it that it stops S3 from working. If the patch is compiled in the kernel, it makes S3 suspend correctly, but resuming goes into a solid hang (nothing get's it back alive, have to keep the powerbutton for ~5 secs to shutdown the system) Anything I could test? The logs don't give anything useful.. I reported this some time ago [1], but there's no sulution so far... [1] http://groups.google.com/groups?selm=4b4NI-7mJ-9%40gated-at.bofh.it In theory it should not happen... And it's working on my laptop for resume just fine with dyntick on. Can you try it without APIC support? Maybe that's the differerence again. (I don't have APIC on my laptop) [EMAIL PROTECTED]:~# zcat /proc/config.gz | grep APIC CONFIG_X86_GOOD_APIC=y # CONFIG_X86_UP_APIC is not set Only the second one can be changed in make (menu)config. So I think this is what you have? Also a workaround is to disable dyntick before suspend with: # echo 0 /sys/devices/system/timer/timer0/dyn_tick_state and then enable it again after resume. IIRC, this didn't work, system hangs at resume as well. Will try again if you've released an updated version. -- Christian pgpeNQS7NjPD8.pgp Description: PGP signature
Re: accessing CD fs from initrd
I suppose any live CDs based distributions (like knopix) do such things too Only using (syslinux), mkisofs and mksquashfs here. Jan Engelhardt -- - 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: help! kernel errors?
Hello [EMAIL PROTECTED] wrote: Hello, I'm getting loads and loads of kernel errors in my syslog, but am unable to decipher them into anything meaningful. You may want to take a look at linux/Documentation/oops-tracing.txt It occurs during a backup procedure and looking at the error it's got something to do with process 'rsync' but I haven't got a clue what's going wrong here (hardware? drivers? modules? kernel? what?). I'm hoping you guys can help me out. The repeating error is attached below! - 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: Stripping in module
Jan Engelhardt wrote: What is the best way to do this with v2.6. I have tried e.g. to remove all symbols starting with telos from the module like this (after kbuild): strip -w -K '!telos*' -K 'telosi2c_usb_driver' telosi2c_linux.ko Yes, I'd also be interested in what sections can actually be stripped, if any. Userspace shared libs for example can be `strip -s`'ed and they still work as expected, does not look like this holds for kernel modules. I would also be interested in this. For instance the AIC7xxx driver has every PCI id in the module I think in the .modinfo section which is not truely required once depmod has been run. I wanted to strip out this information so that modules would be smaller. I had stripped this section out in testing a floppy boot and then most modules would not load anymore. -- Lab tests show that use of micro$oft causes cancer in lab animals - 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: Stripping in module
Wakko Warner wrote: [] I would also be interested in this. For instance the AIC7xxx driver has every PCI id in the module I think in the .modinfo section which is not truely required once depmod has been run. [] The .modinfo section, for example the PCI IDs, IS required for the module to function properly. The kernel and the module uses that tables to determime which devices to work with, and with which paramteres. /mjt - 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] Re: itimer oddness in 2.6.12
George Anzinger wrote: Tom Marshall wrote: On Fri, Jul 22, 2005 at 08:21:25PM +0100, Paulo Marques wrote: [...] Unfortunately, this is not so clear cut as it seems :( Oops! That patch is wrong. The +1 should be applied to the initial interval _only_. We KNOW when the repeating intervals start (i.e. at the jiffie edge) and don't need to adjust them. The patch, however, incorrectly, rolls them all into one. The attach patch should fix the problem. Warnning, it compiles and boots, but I have not tested it. Yes, this seems to be the Right Thing :) Acked-by: Paulo Marques [EMAIL PROTECTED] -- Paulo Marques - www.grupopie.com It is a mistake to think you can solve any major problems just with potatoes. Douglas Adams - 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: help! kernel errors?
Beantwoorden Vladimir V. Saveliev [EMAIL PROTECTED]: You may want to take a look at linux/Documentation/oops-tracing.txt Does this get us any closer? Still gibberish to me? ~/ksymoops-2.4.9# ./ksymoops err.txt ksymoops 2.4.9 on i686 2.4.31. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.31/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Jul 24 23:24:51 server kernel: Unable to handle kernel paging request at virtual address 04003428 Jul 24 23:24:51 server kernel: c014f3e8 Jul 24 23:24:51 server kernel: *pde = Jul 24 23:24:51 server kernel: Oops: Jul 24 23:24:51 server kernel: CPU:0 Jul 24 23:24:51 server kernel: EIP:0010:[c014f3e8]Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 Jul 24 23:24:51 server kernel: EFLAGS: 00010213 Jul 24 23:24:51 server kernel: eax: 0015422f ebx: 04003400 ecx: 000f edx: c144 Jul 24 23:24:51 server kernel: esi: edi: c1453fa8 ebp: 0015422e esp: c329de34 Jul 24 23:24:51 server kernel: ds: 0018 es: 0018 ss: 0018 Jul 24 23:24:51 server kernel: Process rsync (pid: 29653, stackpage=c329d000) Jul 24 23:24:51 server kernel: Stack: 00e4 d8a18040 0002 0015422e 0002 cf313000 c99e0b00 c014f641 Jul 24 23:24:51 server kernel:cf313000 0015422e c1453fa8 fff3 c99e0b00 c329de8c Jul 24 23:24:51 server kernel:d8a1147a cf313000 0002 0001075a 0001075a 0286 0020 Jul 24 23:24:51 server kernel: Call Trace:[c014f641] [d8a1147a] [c0143bc7] [c01444a8] [c01448f9] Jul 24 23:24:51 server kernel: [c0144d60] [c0138e63] [c0139213] [c0108c87] Jul 24 23:24:51 server kernel: Code: 39 6b 28 89 de 75 f1 8b 44 24 20 39 83 a0 00 00 00 75 e5 8b EIP; c014f3e8 find_inode+28/80 = edx; c144 _end+10672fc/1852635c edi; c1453fa8 _end+107b2a4/1852635c esp; c329de34 _end+2ec5130/1852635c Trace; c014f641 iunique+71/80 Trace; d8a1147a END_OF_CODE+ccaf/ Trace; c0143bc7 real_lookup+c7/f0 Trace; c01444a8 link_path_walk+788/a20 Trace; c01448f9 path_lookup+39/40 Trace; c0144d60 open_namei+70/5f0 Trace; c0138e63 filp_open+43/70 Trace; c0139213 sys_open+53/a0 Trace; c0108c87 system_call+33/38 Code; c014f3e8 find_inode+28/80 _EIP: Code; c014f3e8 find_inode+28/80 = 0: 39 6b 28 cmp%ebp,0x28(%ebx) = Code; c014f3eb find_inode+2b/80 3: 89 de mov%ebx,%esi Code; c014f3ed find_inode+2d/80 5: 75 f1 jnefff8 _EIP+0xfff8 Code; c014f3ef find_inode+2f/80 7: 8b 44 24 20 mov0x20(%esp,1),%eax Code; c014f3f3 find_inode+33/80 b: 39 83 a0 00 00 00 cmp%eax,0xa0(%ebx) Code; c014f3f9 find_inode+39/80 11: 75 e5 jnefff8 _EIP+0xfff8 Code; c014f3fb find_inode+3b/80 13: 8b 00 mov(%eax),%eax 1 warning issued. Results may not be reliable. - 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: [BUG] Tulip for ULi M5263: No packets transmitted
On Sat, 23 Jul 2005 20:22:04 +0100, Ricardo Bugalho wrote: the tulip driver isn't work out for my ULi M5263 network adapter. The driver loads and the interface receives packets but it won't transmit any. Running a packet capture on it shows no outbound packets, so I guess the driver thinks the card is screwed up and can't transmit. Does tulip-fixes-for-uli5261.patch from -mm tree help? http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/broken-out/tulip-fixes-for-uli5261.patch -- Jiri Benc SUSE Labs - 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: diskstat 0.1: simple tool to study io patterns via relayfs
On Mon, Jul 25, 2005 at 03:56:48AM -0400, Sonny Rao wrote: Hi, I had some trouble compiling it, I figured out that one needs libboost, but then I've also discovered that g++-3.4.4 and g++-4.0.1 don't want to compile it while g++-3.3.5 works. (FYI, all of these were Ubuntu versions) Yes, you are right. I'll fix the Boost thing, but it really should compile using all those gcc's. Would you mind sending me the errors you get with the other compilers (privately)? You might want to document some of this in the README :) This is the least of what needs fixing hehe. Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - 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: CheckFS: Checkpoints and Block Level Incremental Backup (BLIB)
On Mon, Jul 25, 2005 at 11:24:43AM +0530, Amit S. Kale wrote: On Sunday 24 Jul 2005 8:44 pm, Jan Engelhardt wrote: Maybe you want to put your development machines on ext*2* while doing this ;-). Or perhaps reiserfs/xfs/something. Or perhaps into at the VFS level, so any fs can benefit from it. We thought about that. While it's possible to do that, it would need hooks into all filesystems etc. Definitely worth trying once we get some more basic stuff working for ext3 After all the things that need to be saved at the time of taking a checkpoint for any filesystem would be the superblock and inode table (or their equivalents). Everything else is automatically taken care of. You are aware of the block-device-level snapshot solutions, right? They can be more painful to use, although that's mostly a UI issue, and they have the added advantage that you can safely run e2fsck on the snapshot image if you want to check the consistency of the filesystem while it is mounted. (If it is clean, you can then use tune2fs to reset the max-mount-count and last-checked-time on the original filesystem image; if it is not clean, you can send e-mail to the system administrator suggesting that she schedule downtime ASAP and do a e2fsck on the filesystem image. This is a good thing that a paranoid sysadmin might schedule via cron every Saturday morning at 3am, for example.) - Ted - 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: CheckFS: Checkpoints and Block Level Incremental Backup (BLIB)
On Monday 25 Jul 2005 6:02 pm, Theodore Ts'o wrote: On Mon, Jul 25, 2005 at 11:24:43AM +0530, Amit S. Kale wrote: On Sunday 24 Jul 2005 8:44 pm, Jan Engelhardt wrote: Maybe you want to put your development machines on ext*2* while doing this ;-). Or perhaps reiserfs/xfs/something. Or perhaps into at the VFS level, so any fs can benefit from it. We thought about that. While it's possible to do that, it would need hooks into all filesystems etc. Definitely worth trying once we get some more basic stuff working for ext3 After all the things that need to be saved at the time of taking a checkpoint for any filesystem would be the superblock and inode table (or their equivalents). Everything else is automatically taken care of. You are aware of the block-device-level snapshot solutions, right? They can be more painful to use, although that's mostly a UI issue, and they have the added advantage that you can safely run e2fsck on the snapshot image if you want to check the consistency of the filesystem while it is mounted. That would be a lesser advantage IMHO compared to the advantage of being able to manage disks in a better way. Block-device level snapshots are simple to implement, though making them intelligent is quite difficult. Block device level snapshots can't detect which block are allocated and which are not (unless they look into a filesystem's block allocation map, which requires a device-fs interface). A snapshot may hence require an exhorbitant amount of space when it's not really needed. The BLIB procedure to be used with checkfs is to create a checkpoint. Transfer it to disk as the first full backup. This operation uses the free space available within the filesystem till the time the data is transfered to a tape. A similar procedure used with block-level backup will require an auxilliary device. Generally filesystem level snapshots/checkpoints can be more intelligent hence easier to use and requires fewer resources. -Amit (If it is clean, you can then use tune2fs to reset the max-mount-count and last-checked-time on the original filesystem image; if it is not clean, you can send e-mail to the system administrator suggesting that she schedule downtime ASAP and do a e2fsck on the filesystem image. This is a good thing that a paranoid sysadmin might schedule via cron every Saturday morning at 3am, for example.) - 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: Problem with Asus P4C800-DX and P4 -Northwood-
Hi, Thanks for reply. Sorry, but I've never done any vmstat operation before so next time I'll send the output in the first mail :) Willy Tarreau wrote: Hi, On Mon, Jul 25, 2005 at 02:50:05AM +0200, Andreas Baer wrote: Hi everyone, First I want to say sorry for this BIG post, but it seems that I have no other chance. :) It's not big enough, you did not explain us what your database does nor how it does work, what type of resource it consumes most, any vmstat capture during operation. There are so many possibilities here : - poor optimisation from gcc = CPU bound I doubt it, because I've run the same binaries (no recompilation) on both systems. (you will see vmstat output below) - many random disk accesses = I/O bound, but changing/tuning the I/O scheduler could help Indeed, the data is stored in random access files. - intensive disk reads = perhaps your windows and linux partitions are on the same disk and windows is the first one, then you have 50 MB/s on the windows one and 25 MB/s on the linux one ? I have (S-ATA-150 Disk 80GB) /dev/sda: 50.59 MB/sec /dev/sda1: 50.62 MB/sec(Windows FAT32) /dev/sda6: 41.63 MB/sec(Linux ReiserFS) On the Notebook I have at most an ATA-100 Disk with 80GB and it shows the same declension. Here I have /dev/hda: 26.91 MB/sec /dev/hda1: 26.90 MB/sec(Windows FAT32) /dev/hda7: 17.89 MB/sec(Linux EXT3) Could you give me a reason how this is possible? - task scheduling : if your application is multi-process/multi-thread, it is possible that you hit some corner cases. There are only a maximum of 2 Threads started and they have more background activity or do nothing, should have nothing to do with this problem. So please start vmstat 1 before your 3min request, and stop it at the end, so that it covers all the work. It will tell us many more useful information. all output below... Regards, Willy I have a Asus P4C800-DX with a P4 2,4 GHz 512 KB L2 Cache Northwood Processor (lowest Processor that supports HyperThreading) and 1GB DDR400 RAM. I'm also running S-ATA disks with about 50 MB/s (just to show that it shouldn't be due to hard disk speed). Everything was bought back in 2003 and I recently upgraded to the lastest BIOS Version. I've installed Gentoo Linux and WinXP with dual-boot on this system. Now to my problem: I'm currently developing a little database in C++ (runs currently under Windows and Linux) that internally builds up an R-Tree and does a lot of equality tests and other time consuming checks. For perfomance issue I ran a test with 20 entries and it took me about 3 minutes to complete under Gentoo Linux. So I ran the same test in Windows on the same platform and it took about 30(!) seconds. I was a little bit surprised about this result so I started to run several tests on different machines like an Athlon XP 2000+ platform and on my P4 3GHz Prescott Notebook and they all showed something about 30 seconds or below. Then I began to search for errors or any misconfiguration in Gentoo, in my code and also for people that have made equal experiences with that hardware configuration on the internet. I thought I have a problem with a broken gcc or libraries like glibc or libstdc++ and so I recompiled my whole system with the stable gcc 3.3.5 release, but that didn't make any changes. I also tried an Ubuntu and a Suse LiveCD to verify that it has nothing to do with Gentoo and my kernel version and they had the same problem and ran the test in about 3 min. Currently I'm at a loss what to do. I'm beginning to think that this is maybe a kernel problem because I have no problems under Windows and it doesn't matter whether I change any software or any configuration in Gentoo. I'm currently running kernel-2.6.12, but the Livecd's had other kernels. HyperThreading(HT) is also not the reason for the loss of power, because I tried to disable it and to create a uniprocessor kernel, but that didn't solve the problem. If you need some output of my configuration/log files or anything like that, just mail me. Is it possible that the kernel has a lack of support for P4 with Northwood core? Maybe only this one? Could I solve the problem if I change the processor to a Prescott core? Perhaps someone could provide any information if this would make any sense or not. Thanks in advance for anything that could help. ...sorry for bad english :) - 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/ Vmstat for Notebook P4 3.0 GHz 512 MB RAM: procs ---memory-- ---swap-- -io --system-- cpu r b swpd free buff cache si sobibo incs us sy id wa 1 0 0 179620 14812
Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt
On Sat, Jul 23, 2005 at 04:40:46PM -0700, randy_dunlap wrote:
On Sat, 16 Jul 2005 23:55:17 -0400 Lee Revell wrote:
On Sat, 2005-07-16 at 19:35 -0700, Nish Aravamudan wrote:
As you've seen, I think it depends on the timesource: for the PIT, it
would be arch/i386/kernel/timers/timer_pit.c::setup_pit_timer().
That one looks pretty straightforward.
arch/i386/kernel/timers/timer_tsc.c really looks like fun. So many
corner cases...
BTW shouldn't this code from mark_offset_tsc():
402 if (pit_latch_buggy) {
403 /* get center value of last 3 time lutch */
404 if ((count2 = count count = count1)
405 || (count1 = count count = count2)) {
406 count2 = count1; count1 = count;
407 } else if ((count1 = count2 count2 = count)
408|| (count = count2 count2 = count1)) {
409 countmp = count;count = count2;
410 count2 = count1;count1 = countmp;
411 } else {
412 count2 = count1; count1 = count; count = count1;
413 }
414 }
use an ifdef? It only applies to cyrix_55x0, and mark_offset_tsc is a
pretty hot path.
I see your point, but several distros build kernels that run on
almost any x86-32 machine, so I think that it's there as is
for universal-kernel support.
The same latch bug is in stone age Intel Pentium chipsets and some
medieval SiS chipsets. VIA chipsets from the middle age have another
interesting bug in the PIT.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-
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: kernel page size explanation
On 7/25/05, Nix [EMAIL PROTECTED] wrote: On Mon, 25 Jul 2005, VASM wrote: i had one question does the linux kernel support only one default page size even if the processor on which it is working supports multiple ? No. Some architectures have compile-time support for multiple different page sizes (e.g. Itanium, SPARC64); many have support for a (non-swappable) `large pages) system, and a filesystem backed by huge pages. (Often, the kernel is stored in huge pages, to keep the number of page table entries wasted by the nonswappable kernel to a minimum.) What is *not* presently supported is using multiple page sizes to back userspace processes; that size is currently fixed at compile-time, even on architectures supporting multiple variably-sized pages. are there any specific reasons for not using large page size for userspace processes -- `But of course, GR is the very best relativity for the masses.' --- Wayne Throop - 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/
Please help with following NUMA-related questions
I will greatly appreciate any help regarding the following matters: (1) How to know whether my machine is NUMA-aware or not, (2) Difference between memory bank interleaving and node interleaving (3) When the BIOS asks me to set bank interleaving as AUTO, then it says that AUTO allows memory access to spread out over banks on the same node or across nodes decreasing memory access contentions. However, I have no idea when the memory access is spread over banks on the same node or across nodes. I also do not know how to tell the machine to access memory across the nodes or on the same node. I have no idea as to how the AUTO choice affects NUMA-awareness. (4) The BIOS also tells me that I could choose bani interleaving as DISABLED. But I do not know what its implications are for NUMA awareness. Here are other relevant details. I have a dual-Opteron 250 (2.4GHz) set in Tyan Thunder 2885 K8W with AMIBIOS version 2.05. When I bought it last year, the machine was running under SuSE 9.1 Pro and the Linux kernel was 2.6.5-7.108-smp. At that time both the Hardware Info from YAST and /vat/log/messages were explicitly mentioning things : Scanning NUMA topology in Northbridge 24 6Number of nodes 2 (10010) 6Node 0 MemBase Limit 7fff 6Node 1 MemBase 8000 Limit cbff 6Using node hash shift of 24 These messages indicated that NODE interleaving was off and the machine was NUMA-aware. Then, after a few months, the motherboard failed and the machine was sent to the vendor for repair. It came back with SuSE 9.3 and the Linux kernel version 2.6.11.4-21.7-smp ([EMAIL PROTECTED]) (gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)) #1 SMP Thu Jun 2 14:23:14 UTC 2005. Now both the Hardware Info from YAST and /vat/log/messages DO NOT mention NUMA anywhere, and I do not have anyway to check whether the NODE-Interleaving is OFF or ON. My difficulties are compounded because I do not know how to interpret the chipset related setting in the BIOS. Currently, in the BIOS setting (Chipset-memory config - Bank Interleaving), I am asked to choose between AUTO DISABLED. No choice is offered for Node Interleaving. The only guidance for the choice is that interleaving allows memory access to spread out over banks on the same node or across nodes decreasing memory access contentions. Nothing is mentioned about what happens when Interleaving is disabled. Furthermore, if I choose AUTO, then I do not know when the memory is spread out over banks on the same node or across nodes. Any help will be greatly appreciated. Thanking you in advance. -- Best regards. Sheo (Sheo S. Prasad) Creative Research Enterprises 6354 Camino del Lago Pleasanton, CA 94566, USA Voice Phone: (+1) 925 426-9341 Fax Phone: (+1) 925 426-9417 e-mail: [EMAIL PROTECTED] - 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: Problem with Asus P4C800-DX and P4 -Northwood-
Andreas Baer wrote: [...] Vmstat for Notebook P4 3.0 GHz 512 MB RAM: procs ---memory-- ---swap-- -io --system-- cpu r b swpd free buff cache si sobibo incs us sy id wa 1 0 0 179620 14812 228832003321 557 184 3 1 95 1 2 0 0 178828 14812 22883200 0 0 1295 819 6 2 92 0 1 0 0 175948 14812 22883200 0 0 1090 111 37 17 This vmstat output doesn't show any input / output happening. Are you sure this was taken *while* your test is running? If it is, then all files are already in pagecache. The fact that you have free memory at all times, and that the run on the notebook takes less than 20 seconds confirms this. The second takes a lot more time to execute. The 1Gb memory does make me suspicious, though. There is a known problem with BIOS that don't set up the mtrr's correctly for the whole memory and leave a small amount of memory on the top with the wrong settings. Accessing this memory becomes painfully slow. Can you send the output of /proc/mtrr and try to boot with something like mem=768M to see if that improves performance on the Desktop P4? -- Paulo Marques - www.grupopie.com It is a mistake to think you can solve any major problems just with potatoes. Douglas Adams - 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/
Power consumption HZ250 vs. HZ1000
Hi, I did some measurements in order to compare power drain with HZ250 and HZ1000. To measure the actual drain, I used the smart battery's internal measurement. (Available with acpi-sbs in /proc/acpi/sbs/SBS0/SB0/state.) No clue how accurate this is. Here some battery details, in case someone knows: charge reporting error: 25% SB specification:v1.1 (with PEC) manufacturer name: Panasonic manufacture date:2004-11-27 device name: 02ZL device chemistry:Lion Kernel: 2.6.13-rc3-mm1 + acpi-sbs CPU: cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.60GHz stepping: 6 The ondemand governor was running, using acpi_cpufreq. (Idle at 600MHz). Systems was running X11/KDE to get a more or less realistic scenario. No cron jobs, network traffic or additional applications. WLAN and built-in display were disabled completely, all fans and LEDs were off, internal hard disc was running. Additional peripherals: external keyboard, mouse, display and externally-powered hard disk (USB). The results are quite simple: In both configurations the current settles between 727-729 mA (Voltage ~16.5 V). Some issues: - C-states look strange: active state:C2 max_cstate: C8 bus master activity: 00887fff states: C1: type[C1] promotion[C2] demotion[--] latency[000] usage[0010] *C2: type[C2] promotion[C3] demotion[C1] latency[001] usage[01367471] C3: type[C3] promotion[--] demotion[C2] latency[085] usage[] - I don't know, how much polling of the battery affects results. Reads always block for ~10 seconds, and I used this behaviour for rate-limiting. - Is this approach valid at all? - I could repeat the test in single user mode with internal hard disc turned off. Regards - 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/
Question re the dot releases such as 2.6.12.3
Greetings; I just built what I thought was 2.6.12.3, but my script got a tummy ache because I didn't check the Makefile's EXTRA_VERSION, which was set to .2 in the .2 patch. Now my 2.6.12 modules will need a refresh build. :( So whats the proper patching sequence to build a 2.6.12.3? -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - 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] driver core: Add the ability to unbind drivers to devices from userspace
On 7/25/05, Dmitry Torokhov [EMAIL PROTECTED] wrote: On Sunday 24 July 2005 23:09, Jon Smirl wrote: I just pulled from GIT to test bind/unbind. I couldn't get it to work; it isn't taking into account the CR on the end of the input value of the sysfs attribute. This patch will fix it but I'm sure there is a cleaner solution. echo -n should take care of this problem I think. That will work around it but I think we should fix it. Changing to strncmp() fixes most cases. - if (strcmp(name, dev-bus_id) == 0) + if (strncmp(name, dev-bus_id, strlen(dev-bus_id)) == 0) I work in this area and I couldn't figure out why it was silently not working. I had to add the printk to the source before I could figure it out. I suspect most people are going to have this trouble. This has also made me realize that I have created other places in the kernel where my sysfs attribute code is not going to work correctly. Maybe we should adjust the sysfs driver to strip leading and trailing white space before passing the string on. -- Jon Smirl [EMAIL PROTECTED] - 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: HELP: NFS mount hangs when attempting to copy file
A kde and gnome are well above MTU they don't know anything about MTU and neither does NFS, if those hang it up you have a network configuration problem, and should probably fix it, as a number of other things will show the problem also. Routers almost always have hard coded MTU limits, and they are almost never the default 1500, so everything needs to be properly told what your networks MTU is, or some external device needs to be taking care of it properly. Roger -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Miller Sent: Saturday, July 23, 2005 9:52 PM To: Trond Myklebust Cc: linux-kernel@vger.kernel.org Subject: Re: HELP: NFS mount hangs when attempting to copy file On 7/23/05, Trond Myklebust [EMAIL PROTECTED] wrote: I beg to disagree. A lot of these VPN solutions are unfriendly to MTU path discovery over UDP. Sun uses TCP by default when mounting NFS partitions. Have you tried this on your Linux box? I changed the protocol to TCP and changed rsize and wsize to 1024. I don't know which of those fixed it, but I'm going to leave it for now. As for MTU, yeah, the Watchguard box seems to have some hard-coded limits, and for whatever reason KDE and GNOME graphical logins do something that exceeds those limits, completely independent of NFS, and hang up hard. Thanks. - 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/ - 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: Memory Management
On Sun, Jul 24, 2005 at 10:40:19PM -0300, Márcio Oliveira wrote: Neil Horman wrote: On Sat, Jul 23, 2005 at 08:16:20PM -0300, Márcio Oliveira wrote: Neil, The best way I can think to do that is take a look at /proc/slabinfo. That will likely give you a pointer to which area of code is eating up your memory. OK. I will monitor the /proc/slabinfo file. Based on the sysrq-m info you posted it looks like due to fragmentation the largest chunk of memory you can allocate is 2MB (perhaps less depending on address space availability). If you can build a test kernel to do a show_state rather than a show_mem at the beginning of oom_kil, then you should be able to tell who is trying to do an allocation that leads to kswapd calling out_of_memory. Neil, I'm trying to recompile the kernel source 2.4.21-32.0.1 and get some error messages: In file included from /usr/src/linux-2.4.21-32.0.1.EL/include/linux/prefetch.h:13, from /usr/src/linux-2.4.21-32.0.1.EL/include/linux/list.h:6, from /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:12, from 3w-.c:172: /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:61: warning: parameter names (without types) in function declaration /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:61: field `loops_per_jiffy_R_ver_str' declared as a function /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: invalid suffix on integer constant /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: syntax error before numeric constant /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: warning: function declaration isn't a prototype /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: invalid suffix on integer constant /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: syntax error before numeric constant /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: warning: function declaration isn't a prototype /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:273: warning: parameter names (without types) in function declaration In file included from 3w-.c:172: /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: invalid suffix on integer constant /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: syntax error before numeric constant /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: `inter_module_register_R_ver_str' declared as function returning a function /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: warning: function declaration isn't a prototype /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: invalid suffix on integer constant /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: syntax error before numeric constant /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: `inter_module_unregister_R_ver_str' declared as function returning a function /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: warning: function declaration isn't a prototype /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:192: `inter_module_get_R_ver_str' declared as function returning a function /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:192: warning: parameter names (without types) in function declaration /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:193: `inter_module_get_request_R_ver_str' declared as function returning a function /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:193: warning: parameter names (without types) in function declaration /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: invalid suffix on integer constant /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: syntax error before numeric constant /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: `inter_module_put_R_ver_str' declared as function returning a function /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: warning: function declaration isn't a prototype /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:203: `try_inc_mod_count_R_ver_str' declared as function returning a function /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:203: warning: parameter names (without types) in function declaration make[3]: *** [3w-_10200033.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.4.21-32.0.1.EL/drivers/addon/3w-_10200033' make[2]: *** [_modsubdir_3w-_10200033] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.21-32.0.1.EL/drivers/addon' make[1]: *** [_modsubdir_addon] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.21-32.0.1.EL/drivers' make: *** [_mod_drivers] Error 2 Is there any relationship between the sysrq-m changes to do show_state() rather than a show_mem() and the compiling erros? /usr/src/linux-2.4.21-32.0.1.EL/include/linux/prefetch.h, line 13: #include
BUG: Yamaha OPL3SA2 does not work with ALSA on 2.6 kernels.
Hello. I have a 5 year old Gateway Solo 2500 that is currently running Linux 2.6.12.2. If I install ALSA and try to have alsaconf bruteforce-detect the OPL3SA2 sound card, it will say that it has detected it, but loading the modules will fail. If I install Linux 2.4 and recompile/rerun alsaconf, the detection works fine and the card works. Copying the configuration detected under 2.4 into a modprobe.conf on 2.6 allows me to use the card in 2.6 with occasional crashes (which might be due to suspend2). Searching around the net, I find many other people having trouble with these cards and the ALSA-Linux2.6 combination. On one page, someone suggested that there were changes made between 2.4 and 2.6 to the ISA code that broke ALSA's detection routines. I'm not sure what information might be needed in order to get this card working well once and for all, but if someone will let me know, I'd be happy to provide. Thanks. -Andy - 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: ugly, FYI] battery charging support for sharp sl-5500
Hi!
I took battery charging code from sharp and placed it in
arch/arm/mach-sa1100/battery-collie.c (hope that's good place...). It
still does not link, and will need complete rewrite, but... If you
have done this already please let me know.
I replaced sharp functions with ucb_1x00 functions this way; I hope I
did not mess it up.
diff --git a/arch/arm/mach-sa1100/battery-collie.c
b/arch/arm/mach-sa1100/battery-collie.c
--- a/arch/arm/mach-sa1100/battery-collie.c
+++ b/arch/arm/mach-sa1100/battery-collie.c
@@ -54,9 +54,6 @@
/* Various strange defines, coming from sharp */
-#define COLLIE_TC35143_IODAT_LOW 0 /* set up fs 8k LPF on data
*/
-#define COLLIE_TC35143_IODAT_HIGH 1 /* set up fs 8k LPF off data
*/
-
#define COLLIE_TC35143_IODIR_OUTPUT1 /* set up output mode
*/
#define COLLIE_TC35143_IODIR_INPUT 0 /* set up input mode
*/
@@ -226,13 +223,8 @@ static struct miscdevice battery_device
#define ADC_REQ_ID (u32)(battery_device)
-#ifdef CONFIG_COLLIE_TR0
-#define CHARGE_ON()ucb1200_set_io(COLLIE_TC35143_GPIO_CHRG_ON,
COLLIE_TC35143_IODAT_HIGH)
-#define CHARGE_OFF() ucb1200_set_io(COLLIE_TC35143_GPIO_CHRG_ON,
COLLIE_TC35143_IODAT_LOW)
-#else
#define CHARGE_ON()SCP_REG_GPWR |= COLLIE_SCP_CHARGE_ON
#define CHARGE_OFF() SCP_REG_GPWR = ~COLLIE_SCP_CHARGE_ON
-#endif
#define CHARGE_LED_ON()printk(charger on\n);
#define CHARGE_LED_OFF() printk(charger off\n);
@@ -540,9 +532,6 @@ int GetMainChargePercent( int Volt )
/*** get adc
*/
int collie_get_main_battery(void)
{
-#ifdef CONFIG_COLLIE_TR0
- return COLLIE_BATTERY_STATUS_HIGH;
-#else
int i = 0;
MainCntWk++;
@@ -570,8 +559,6 @@ int collie_get_main_battery(void)
DPRINTK(MainCntWk = %d\n,MainCntWk);
}
return collie_main_battery;
-
-#endif
}
@@ -617,14 +604,13 @@ int collie_read_MainBattery(void)
{
int voltage;
-
- ucb1200_set_io(COLLIE_TC35143_GPIO_BBAT_ON, COLLIE_TC35143_IODAT_LOW);
- ucb1200_set_io(COLLIE_TC35143_GPIO_MBAT_ON, COLLIE_TC35143_IODAT_HIGH);
- voltage = ucb1200_get_adc_value(ADC_REQ_ID, COLLIE_TC35143_ADC_BAT_VOL);
+ ucb1x00_io_write(NULL, 0, COLLIE_TC35143_GPIO_BBAT_ON);
+ ucb1x00_io_write(NULL, COLLIE_TC35143_GPIO_MBAT_ON, 0);
+ voltage = ucb1x00_adc_read(NULL, COLLIE_TC35143_ADC_BAT_VOL, UCB_SYNC);
if ( battery_off_flag )
voltage = -1;
- ucb1200_set_io(COLLIE_TC35143_GPIO_MBAT_ON, COLLIE_TC35143_IODAT_LOW);
+ ucb1x00_io_write(NULL, 0, COLLIE_TC35143_GPIO_MBAT_ON);
battery_off_flag = 0;
DPRINTK(adc = %d\n,voltage);
@@ -641,13 +627,13 @@ int collie_read_BackBattery(void)
{
int voltage;
- ucb1200_set_io(COLLIE_TC35143_GPIO_MBAT_ON, COLLIE_TC35143_IODAT_LOW);
- ucb1200_set_io(COLLIE_TC35143_GPIO_BBAT_ON, COLLIE_TC35143_IODAT_HIGH);
+ ucb1x00_io_write(NULL, 0, COLLIE_TC35143_GPIO_MBAT_ON);
+ ucb1x00_io_write(NULL, COLLIE_TC35143_GPIO_BBAT_ON, 0);
mdelay(3);
- voltage = ucb1200_get_adc_value(ADC_REQ_ID, COLLIE_TC35143_ADC_BAT_VOL);
+ voltage = ucb1x00_adc_read(NULL, COLLIE_TC35143_ADC_BAT_VOL, UCB_SYNC);
if ( battery_off_flag )
voltage = -1;
- ucb1200_set_io(COLLIE_TC35143_GPIO_BBAT_ON, COLLIE_TC35143_IODAT_LOW);
+ ucb1x00_io_write(NULL, 0, COLLIE_TC35143_GPIO_BBAT_ON);
battery_off_flag = 0;
return voltage;
@@ -657,12 +643,12 @@ int collie_read_Temp(void)
{
int voltage;
-
- ucb1200_set_io(COLLIE_TC35143_GPIO_TMP_ON, COLLIE_TC35143_IODAT_HIGH);
- voltage = ucb1200_get_adc_value(ADC_REQ_ID, COLLIE_TC35143_ADC_BAT_TMP);
+ ucb1x00_io_write(NULL, COLLIE_TC35143_GPIO_TMP_ON, 0);
+ voltage = ucb1x00_adc_read(NULL, COLLIE_TC35143_ADC_BAT_TMP, UCB_SYNC);
if ( battery_off_flag )
voltage = -1;
- ucb1200_set_io(COLLIE_TC35143_GPIO_TMP_ON, COLLIE_TC35143_IODAT_LOW);
+ ucb1x00_io_write(NULL, 0, COLLIE_TC35143_GPIO_TMP_ON);
+
battery_off_flag = 0;
return voltage;
@@ -722,14 +708,12 @@ int suspend_collie_read_Temp(void)
{
int temp;
- ucb1200_set_io(COLLIE_TC35143_GPIO_TMP_ON, COLLIE_TC35143_IODAT_HIGH);
+ ucb1x00_io_write(NULL, COLLIE_TC35143_GPIO_TMP_ON, 0);
udelay(700);
- temp = suspend_read_adc((int)temp, COLLIE_TC35143_ADC_BAT_TMP);
- ucb1200_set_io(COLLIE_TC35143_GPIO_TMP_ON, COLLIE_TC35143_IODAT_LOW);
+ temp = ucb1x00_adc_read(NULL, COLLIE_TC35143_ADC_BAT_TMP, UCB_SYNC);
+ ucb1x00_io_write(NULL, 0, COLLIE_TC35143_GPIO_TMP_ON);
printk(suspend temp = %d\n,temp);
-
-
return temp;
}
@@ -738,10 +722,11 @@ unsigned short suspend_collie_read_MainB
{
int temp;
- ucb1200_set_io(COLLIE_TC35143_GPIO_MBAT_ON, COLLIE_TC35143_IODAT_HIGH);
+ ucb1x00_io_write(NULL, COLLIE_TC35143_GPIO_MBAT_ON, 0);
Re: seeing minute plus hangs during boot - 2.6.12 and 2.6.13
On 7/22/05, Francisco Figueiredo Jr. [EMAIL PROTECTED] wrote: Hangs appears just before mounting filesystems message and before configuring system to use udev. I don't know if this will help, but there were issues raised earlier about older versions of udev causing hangs on newer kernels. Look for the thread with the subject 2.6.12 udev hangs at boot. Actually, look here: http://marc.theaimsgroup.com/?l=linux-kernelm=111909806104523w=2 Basically, upgrade to a newer udev if you're running an older one (I think I had 0.30 at the time; installing 0.58 sped things up noticeably). HTH. -Andy - 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: ugly, FYI] battery charging support for sharp sl-5500
Hi!
I took battery charging code from sharp and placed it in
arch/arm/mach-sa1100/battery-collie.c (hope that's good place...). It
still does not link, and will need complete rewrite, but... If you
have done this already please let me know.
/*
* Battery routines for collie (Sharp Zaurus sl-5500)
*
* Copyright (C) 2001 SHARP
* Copyright 2005 Pavel Machek [EMAIL PROTECTED]
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* ChangeLog:
* 12-Nov-2001 Lineo Japan, Inc.
* 30-Jul-2002 Lineo Japan, Inc. for 2.4.18
*/
/* this driver supports the following functions:
* - apm_get_power_status
* - charge proc
*/
#include linux/config.h
#include linux/module.h
#include linux/poll.h
#include linux/types.h
#include linux/stddef.h
#include linux/timer.h
#include linux/fcntl.h
#include linux/stat.h
#include linux/proc_fs.h
#include linux/miscdevice.h
#include linux/init.h
#include linux/sched.h
#include linux/pm.h
#include linux/kernel.h
#include linux/smp_lock.h
#include linux/apm_bios.h
#include linux/delay.h
#include asm/hardware.h
#include asm/irq.h
#include asm/mach/irq.h
#include asm/hardware/scoop.h
#include asm/arch/ucb1x00.h
#include asm/arch/collie.h
/* Various strange defines, coming from sharp */
#define COLLIE_TC35143_IODAT_LOW 0 /* set up fs 8k LPF on data
*/
#define COLLIE_TC35143_IODAT_HIGH 1 /* set up fs 8k LPF off data
*/
#define COLLIE_TC35143_IODIR_OUTPUT1 /* set up output mode
*/
#define COLLIE_TC35143_IODIR_INPUT 0 /* set up input mode
*/
/*
* UCB1200 register 10: ADC control register
*/
#define ADC_SYNC_ENA (1 0)
#define ADC_INPUT_MASK (7 2)
#define ADC_INPUT_TSPX (0 2)
#define ADC_INPUT_TSMX (1 2)
#define ADC_INPUT_TSPY (2 2)
#define ADC_INPUT_TSMY (3 2)
#define ADC_INPUT_AD0 (4 2)
#define ADC_INPUT_AD1 (5 2)
#define ADC_INPUT_AD2 (6 2)
#define ADC_INPUT_AD3 (7 2)
#define ADC_START (1 7)
#define ADC_ENA (1 15)
#define COLLIE_TC35143_ADC_BAT_TMP ADC_INPUT_AD0 /* BAT TMP
*/
#define COLLIE_TC35143_ADC_BAT_VOL ADC_INPUT_AD1 /* MAIN/BACKUP BAT VOL
*/
#define COLLIE_TC35143_ADC_TC_PRESSURE ADC_INPUT_AD2 /* TC PRESSURE
*/
#define COLLIE_TC35143_ADC_REMOCON_KEY ADC_INPUT_AD3 /* REMOCON KEY
*/
#define CF_BUF_CTRL_BASE 0xF080
#defineSCP_REG(adr) (*(volatile unsigned
short*)(CF_BUF_CTRL_BASE+(adr)))
#defineSCP_MCR 0x00
#defineSCP_CDR 0x04
#defineSCP_CSR 0x08
#defineSCP_CPR 0x0C
#defineSCP_CCR 0x10
#defineSCP_IRR 0x14
#defineSCP_IRM 0x14
#defineSCP_IMR 0x18
#defineSCP_ISR 0x1C
#defineSCP_GPCR 0x20
#defineSCP_GPWR 0x24
#defineSCP_GPRR 0x28
#defineSCP_REG_MCR SCP_REG(SCP_MCR)
#defineSCP_REG_CDR SCP_REG(SCP_CDR)
#defineSCP_REG_CSR SCP_REG(SCP_CSR)
#defineSCP_REG_CPR SCP_REG(SCP_CPR)
#defineSCP_REG_CCR SCP_REG(SCP_CCR)
#defineSCP_REG_IRR SCP_REG(SCP_IRR)
#defineSCP_REG_IRM SCP_REG(SCP_IRM)
#defineSCP_REG_IMR SCP_REG(SCP_IMR)
#defineSCP_REG_ISR SCP_REG(SCP_ISR)
#defineSCP_REG_GPCRSCP_REG(SCP_GPCR)
#defineSCP_REG_GPWRSCP_REG(SCP_GPWR)
#defineSCP_REG_GPRRSCP_REG(SCP_GPRR)
#define FLASH_MEM_BASE 0xe8ffc000
#defineFLASH_DATA(adr) (*(volatile unsigned int*)(FLASH_MEM_BASE+(adr)))
#defineFLASH_DATA_F(adr) (*(volatile float32 *)(FLASH_MEM_BASE+(adr)))
#define FLASH_MAGIC_CHG(a,b,c,d) ( ( d 24 ) | ( c 16 ) | ( b 8 ) | a )
// AD
#define FLASH_AD_MAJIC FLASH_MAGIC_CHG('B','V','A','D')
#defineFLASH_AD_MAGIC_ADR 0x30
#defineFLASH_AD_DATA_ADR 0x34
#define IRQ_GPIO_COIRQ_GPIO20
#define IRQ_GPIO_AC_IN IRQ_GPIO1
//#define DEBUG 1
#ifdef DEBUG
#define DPRINTK(x, args...) printk(__FUNCTION__ : x,##args)
#define DPRINTK2(x, args...) printk(__FUNCTION__ : x,##args)
#else
#define DPRINTK(x, args...) if ( msglevel 1 ) printk(x,##args);
#define DPRINTK2(x, args...) if ( msglevel 0 ) printk(x,##args);
#endif
/*** prototype
*/
int collie_read_MainBattery(void);
int collie_read_BackBattery(void);
int collie_read_Temp(void);
int collie_check_temp(void);
int collie_check_voltage(void);
static void collie_charge_on(void);
static void collie_charge_off(void);
int
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi!
This adds support for reading ADCs (etc), neccessary to operate touch
screen on Sharp Zaurus sl-5500.
I would like to know what the diffs are between my version (attached)
and this version before they get applied.
Hmm, diff looks quite big (attached), and I got it from lenz for 99%
part.
I have made quite a lot of cleanups to touchscreen part, and it seems
to be acceptable by input people. I think it should go into
drivers/input/touchscreen/collie_ts.c... Also it looks to me like
mcp.h should go into asm/arch-sa1100, so that other drivers can use it...
The only reason my version has not been submitted is because it lives
in the drivers/misc directory, and mainline kernel folk don't like
drivers which clutter up that directory. In fact, I had been told
that drivers/misc should remain completely empty - which makes this
set of miscellaneous drivers homeless.
Could they simply live in arch/arm/mach-sa1100? Or is arch/arm/soc
better place?
Pavel
--- linux-rmk/drivers/input/touchscreen/Kconfig 2005-07-14 00:41:02.0
+0200
+++ linux-z/drivers/input/touchscreen/Kconfig 2005-07-21 17:22:31.0
+0200
@@ -36,6 +36,15 @@
To compile this driver as a module, choose M here: the
module will be called ads7846_ts.
+config TOUCHSCREEN_COLLIE
+ tristate Collie touchscreen (for Sharp SL-5500)
+ depends on MCP_UCB1200
+ help
+ Say Y here to enable the driver for the touchscreen on the
+ Sharp SL-5500 series of PDAs.
+
+ If unsure, say N.
+
config TOUCHSCREEN_GUNZE
tristate Gunze AHL-51S touchscreen
select SERIO
--- linux-rmk/drivers/input/touchscreen/Makefile2005-07-14
00:41:02.0 +0200
+++ linux-z/drivers/input/touchscreen/Makefile 2005-07-21 06:39:52.0
+0200
@@ -6,6 +6,7 @@
obj-$(CONFIG_TOUCHSCREEN_BITSY)+= h3600_ts_input.o
obj-$(CONFIG_TOUCHSCREEN_CORGI)+= corgi_ts.o
+obj-$(CONFIG_TOUCHSCREEN_COLLIE)+= collie_ts.o
obj-$(CONFIG_TOUCHSCREEN_GUNZE)+= gunze.o
obj-$(CONFIG_TOUCHSCREEN_ELO) += elo.o
obj-$(CONFIG_TOUCHSCREEN_MTOUCH) += mtouch.o
--- linux-rmk/drivers/misc/Makefile 2005-07-25 05:17:11.0 +0200
+++ linux-z/drivers/misc/Makefile 2005-07-21 06:36:17.0 +0200
@@ -6,12 +6,15 @@
obj-$(CONFIG_IBM_ASM) += ibmasm/
obj-$(CONFIG_HDPU_FEATURES)+= hdpuftrs/
-obj-$(CONFIG_MCP) += mcp-core.o
-obj-$(CONFIG_MCP_SA1100) += mcp-sa1100.o
-obj-$(CONFIG_MCP_UCB1200) += ucb1x00-core.o
-obj-$(CONFIG_MCP_UCB1200_AUDIO)+= ucb1x00-audio.o
-obj-$(CONFIG_MCP_UCB1200_TS) += ucb1x00-ts.o
+obj-$(CONFIG_MCP) += mcp-core.o
+obj-$(CONFIG_MCP_UCB1200) += ucb1x00-core.o
+obj-$(CONFIG_MCP_UCB1200_AUDIO)+= ucb1x00-audio.o
ifeq ($(CONFIG_SA1100_ASSABET),y)
-obj-$(CONFIG_MCP_UCB1200) += ucb1x00-assabet.o
+obj-$(CONFIG_MCP_UCB1200) += ucb1x00-assabet.o
endif
+
+obj-$(CONFIG_MCP_SA1100) += mcp-sa1100.o
+
+ucb1400-core-y := ucb1x00-core.o mcp-ac97.o
+obj-$(CONFIG_UCB1400_TS) += ucb1400-core.o ucb1x00-ts.o
Only in linux-z/drivers/misc: mcp-ac97.c
--- linux-rmk/drivers/misc/mcp-core.c 2005-07-25 05:17:11.0 +0200
+++ linux-z/drivers/misc/mcp-core.c 2005-07-21 06:57:36.0 +0200
@@ -19,9 +19,9 @@
#include asm/dma.h
#include asm/system.h
-#include mcp.h
+#include asm/arch-sa1100/mcp.h
-#define to_mcp(d) container_of(d, struct mcp, attached_device)
+#define to_mcp(d) ((struct mcp *)(d)-platform_data)
#define to_mcp_driver(d) container_of(d, struct mcp_driver, drv)
static int mcp_bus_match(struct device *dev, struct device_driver *drv)
@@ -46,7 +46,7 @@
return 0;
}
-static int mcp_bus_suspend(struct device *dev, pm_message_t state)
+static int mcp_bus_suspend(struct device *dev, u32 state)
{
struct mcp *mcp = to_mcp(dev);
int ret = 0;
@@ -179,26 +179,40 @@
spin_unlock_irqrestore(mcp-lock, flags);
}
-static void mcp_release(struct device *dev)
-{
- struct mcp *mcp = container_of(dev, struct mcp, attached_device);
-
- kfree(mcp);
+static void mcp_host_release(struct device *dev) {
+ struct mcp *mcp = dev-platform_data;
+ complete(mcp-attached_device_released);
}
int mcp_host_register(struct mcp *mcp, struct device *parent)
{
- mcp-attached_device.parent = parent;
- mcp-attached_device.bus = mcp_bus_type;
- mcp-attached_device.dma_mask = parent-dma_mask;
- mcp-attached_device.release = mcp_release;
- strcpy(mcp-attached_device.bus_id, mcp0);
- return device_register(mcp-attached_device);
+ int ret;
+ struct device *dev = kmalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev)
+ return -ENOMEM;
+ memset(dev, 0, sizeof(*dev));
+ dev-platform_data = mcp;
+ dev-parent = parent;
+ dev-bus = mcp_bus_type;
+
Re: [PATCH] driver core: Add the ability to unbind drivers to devices from userspace
On 7/25/05, Jon Smirl [EMAIL PROTECTED] wrote: On 7/25/05, Dmitry Torokhov [EMAIL PROTECTED] wrote: On Sunday 24 July 2005 23:09, Jon Smirl wrote: I just pulled from GIT to test bind/unbind. I couldn't get it to work; it isn't taking into account the CR on the end of the input value of the sysfs attribute. This patch will fix it but I'm sure there is a cleaner solution. echo -n should take care of this problem I think. That will work around it but I think we should fix it. Changing to strncmp() fixes most cases. - if (strcmp(name, dev-bus_id) == 0) + if (strncmp(name, dev-bus_id, strlen(dev-bus_id)) == 0) This will produce interesting results if you have both blah-1 and blah-10 devices on the bus. -- Dmitry - 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: Fault tolerance. . .
On Sun, 24 Jul 2005 21:59:59 EDT, John Richard Moser said: I'm thinking of application level fault tolerance using roll-back states or something weird, to restore the system as affected by that application to a point before the error. The obvious visual effect would be that if an application were to crash, it and potentially interrelated applications would suddenly reset to a state a few seconds to a few minutes earlier. Google for checkpoint-restart - it's a big field in scientific computing, where you don't want to lose the results of a 3 week run on a supercomputer just because the system crashes 5 minutes before it's done. (Just think - if they'd had a proper checkpointing scheme, most of the Hitchhiker's trilogy wouldn't have happened... :) Maintaining the state is also easy: - When a file is changed, track the changes and attach them to the last state save - When memory pages are written to, cache the old copies first (unfortunately each page has to be made CoW after every state save) This is actually a lot harder than it looks - most of the real-life applications of checkpoint-restart have been to programs that were designed to play nice with checkpointing. It's *really* hard to do it with a program that wasn't designed to to be checkpointed, as you noticed yourself: This of course raises many questions and concerns that make this rediculous and probably not entirely possible: - What about huge modifications to files in a short time? Make a new file, then write 10,000,000,000 bytes past the end and watch it crash. - What about lost work in interrelated applications? - Will the system state remain consistent? - Will it crash over and over and over? - Connecting to named pipes? (easily handled, not discussed here) - Crashes are usually trappable, and then programs exit cleanly. They won't care about this - How does a process know to change course if it gets restored? Exactly the sort of things that make it hard... pgpUIU84vNnJl.pgp Description: PGP signature
Re: kernel page size explanation
On Mon, 25 Jul 2005 19:12:47 +0530, VASM said: are there any specific reasons for not using large page size for userspace processes Assume you can use 4K or 4M page sizes. Compute the total memory usage for a system that has 50 processes running, each 1556K in size pgpcU7vVX9g8Z.pgp Description: PGP signature
Re: [warning: ugly, FYI] battery charging support for sharp sl-5500
On Mon, 2005-07-25 at 07:46 +0200, Pavel Machek wrote:
I took battery charging code from sharp and placed it in
arch/arm/mach-sa1100/battery-collie.c (hope that's good place...). It
still does not link, and will need complete rewrite, but... If you
have done this already please let me know.
#define CF_BUF_CTRL_BASE 0xF080
#defineSCP_REG(adr) (*(volatile unsigned
short*)(CF_BUF_CTRL_BASE+(adr)))
#defineSCP_MCR 0x00
#defineSCP_CDR 0x04
#defineSCP_CSR 0x08
#defineSCP_CPR 0x0C
#defineSCP_CCR 0x10
#defineSCP_IRR 0x14
#defineSCP_IRM 0x14
#defineSCP_IMR 0x18
#defineSCP_ISR 0x1C
#defineSCP_GPCR 0x20
#defineSCP_GPWR 0x24
#defineSCP_GPRR 0x28
#defineSCP_REG_MCR SCP_REG(SCP_MCR)
#defineSCP_REG_CDR SCP_REG(SCP_CDR)
#defineSCP_REG_CSR SCP_REG(SCP_CSR)
#defineSCP_REG_CPR SCP_REG(SCP_CPR)
#defineSCP_REG_CCR SCP_REG(SCP_CCR)
#defineSCP_REG_IRR SCP_REG(SCP_IRR)
#defineSCP_REG_IRM SCP_REG(SCP_IRM)
#defineSCP_REG_IMR SCP_REG(SCP_IMR)
#defineSCP_REG_ISR SCP_REG(SCP_ISR)
#defineSCP_REG_GPCRSCP_REG(SCP_GPCR)
#defineSCP_REG_GPWRSCP_REG(SCP_GPWR)
#defineSCP_REG_GPRRSCP_REG(SCP_GPRR)
You'll find the scoop driver deals with the above
(arch/arm/common/scoop.c).
#define FLASH_MEM_BASE 0xe8ffc000
#defineFLASH_DATA(adr) (*(volatile unsigned
int*)(FLASH_MEM_BASE+(adr)))
#defineFLASH_DATA_F(adr) (*(volatile float32 *)(FLASH_MEM_BASE+(adr)))
#define FLASH_MAGIC_CHG(a,b,c,d) ( ( d 24 ) | ( c 16 ) | ( b 8 ) |
a )
// AD
#define FLASH_AD_MAJIC FLASH_MAGIC_CHG('B','V','A','D')
#defineFLASH_AD_MAGIC_ADR 0x30
#defineFLASH_AD_DATA_ADR 0x34
and arch/arm/common/sharpsl_param.c with these.
#define IRQ_GPIO_COIRQ_GPIO20
#define IRQ_GPIO_AC_IN IRQ_GPIO1
There will (or if not, there should) be an equivalent in collie.h for
the above.
I have similar problems with the corgi battery driver which is probably
even more of a mess than this. My conclusion is the whole lot needs
rewriting in a nice fashion before it can be included in mainline. My
work so far on the corgi code is here:
http://www.rpsys.net/openzaurus/patches/corgi_power-r24.patch
http://www.rpsys.net/openzaurus/patches/corgi_power1-r1.patch
I'm making progress in areas but I'm not sure how much can be shared
between devices. My plan is to split the above into two sections, a
battery driver and some power management code. The powermanagement code
can probably then make mainline. The battery driver still needs a lot of
work.
--
Richard
-
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: do_gettimeofday monotony?
bert hubert wrote: Is do_gettimeofday supposed to be monotonous? Nope. I'm seeing time go backward by tiny amounts, and then progressing. Are you running NTP? Corrections could cause this. Is there another monotonous clock in the kernel that doesn't wrap (all that often)? Doesn't really need to be wall time. clock_gettime() Chris - 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 1/2] Touchscreen support for sharp sl-5500
Hi Pavel,
On 7/24/05, Pavel Machek [EMAIL PROTECTED] wrote:
I have made quite a lot of cleanups to touchscreen part, and it seems
to be acceptable by input people. I think it should go into
drivers/input/touchscreen/collie_ts.c... Also it looks to me like
mcp.h should go into asm/arch-sa1100, so that other drivers can use it...
I have couple of nitpicks (below) and one bigger concern - I am
surprised that a driver for a physical device is implemented as an
interface to a class device. This precludes implementing any kind of
power management in the driver and pushes it into the parent and is
generally speaking is a wrong thing to do (IMHO).
If the problem is that you have a single piece of hardware you need to
bind several drivers to - I guess you will have to create a new
sub-device bus for that. Or just register sub-devices on the same bus
the parent device is registered on - I am not sure what is best in
this particular case - I am not familiar with the arch. It is my
understanding that the purpose of interfaces to to present different
views to userspace and therefore they are not quie suited for what
you are trying to do...
+static int ucb1x00_thread(void *_ts)
+{
+ struct ucb1x00_ts *ts = _ts;
+ struct task_struct *tsk = current;
+ int valid;
+
+ ts-rtask = tsk;
Just move that assignment into ucb1x00_input_open and kill all this
current stuff.
+
+ /*
+* We run as a real-time thread. However, thus far
+* this doesn't seem to be necessary.
+*/
+ tsk-policy = SCHED_FIFO;
+ tsk-rt_priority = 1;
+
+ valid = 0;
+ for (;;) {
Can we change this to while (!kthread_should_stop()) to make me
completely happy?
Thanks!
--
Dmitry
-
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: accessing CD fs from initrd
/dev/cdrom is a link to the proper device, if that link is not on the initrd /dev/cdrom won't work. I previously had some statically linked linuxrc C code (I don't have the code anymore- it was a work-for-hire), that scanned the various locations that the cd could be (/dev/hd[abcd...]) and looked for specific files that it expected to be on the cd, once it found it it setup real-root-dev to be proper for that device. This work rather nicely in situations where the location of the cd drive was not the same from one machine to another, and was rather simple to write. Roger -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of zvi Dubitzki Sent: Monday, July 25, 2005 2:28 AM To: linux-kernel@vger.kernel.org Subject: accessing CD fs from initrd Hi there I want to be CC-ed on a possible answer to the following question. I have not found yet an answer to the question in the Linux archives. In need access the CD filesystem (iso9660) from within the Linux initrd or right after that (make it root fs). I need an example for that since allocating enough ramdisk space (ramdisk_size=90k in kernel command line) + loading the cdrom.o module at the initrd did not help mount the CD device (/dev/cdrom) at the initrd Also I need know how to pivot between the initrd and the CD filesystem I am actually using Isolinux/syslinux, but can make test on a regular Linux . Any pointer to a literature will also be welcomed . thanks Zvi Dubitzki _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ - 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/ - 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: Netlink connector
Evgeniy Polyakov wrote: On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris ([EMAIL PROTECTED]) wrote: On Sun, 24 Jul 2005, David S. Miller wrote: From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Sat, 23 Jul 2005 13:14:55 +0400 Andrew has no objection against connector and it lives in -mm A patch sitting in -mm has zero significance. That is why I'm asking netdev@ people again... If I understand correctly it tries to workaround some netlink limitations (limited number of netlink families and multicast groups) by sending everything to userspace and demultiplexing it there. Same in the other direction, an additional layer on top of netlink does basically the same thing netlink already does. This looks like a step in the wrong direction to me, netlink should instead be fixed to support what is needed. - 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: Netlink connector
Le lundi 25 juillet 2005 à 16:32 +0200, Patrick McHardy a écrit : Evgeniy Polyakov wrote: On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris ([EMAIL PROTECTED]) wrote: If I understand correctly it tries to workaround some netlink limitations (limited number of netlink families and multicast groups) by sending everything to userspace and demultiplexing it there. Same in the other direction, an additional layer on top of netlink does basically the same thing netlink already does. This looks like a step in the wrong direction to me, netlink should instead be fixed to support what is needed. I totally agree with you, it could be great to fix netlink to support multiple queue. I like to be able to use projects like snort-inline or nufw together. This will make Netfilter really stronger. Furthermore, there's a repetition of filtering capabilities with such a solution. Netfilter has to filter to send to netlink and this is the same with the queue dispatcher. I think this introduce too much complexity. my 0.02$ BR, -- Éric Leblond, [EMAIL PROTECTED] Téléphone : 01 44 89 46 40, Fax : 01 44 89 45 01 INL, http://www.inl.fr - 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: Problem with Asus P4C800-DX and P4 -Northwood-
On Mon, Jul 25, 2005 at 03:10:08PM +0200, Andreas Baer wrote: (...) I have (S-ATA-150 Disk 80GB) /dev/sda: 50.59 MB/sec /dev/sda1: 50.62 MB/sec(Windows FAT32) /dev/sda6: 41.63 MB/sec(Linux ReiserFS) On the Notebook I have at most an ATA-100 Disk with 80GB and it shows the same declension. Here I have /dev/hda: 26.91 MB/sec /dev/hda1: 26.90 MB/sec(Windows FAT32) /dev/hda7: 17.89 MB/sec(Linux EXT3) Could you give me a reason how this is possible? a reason for what ? the fact that the notebook performs faster than the desktop while slower on I/O ? Vmstat for Notebook P4 3.0 GHz 512 MB RAM: Your Notebook's P4 has HT enabled (50% apparent idle remain permanently during operation). But you'll note that your load is 60% system + 40% user there, and that you do absolutely no I/O (I presume it's the second run and it's cached). procs ---memory-- ---swap-- -io --system-- cpu r b swpd free buff cache si sobibo incs us sy id wa 1 0 0 179620 14812 228832003321 557 184 3 1 95 1 2 0 0 178828 14812 22883200 0 0 1295 819 6 2 92 0 1 0 0 175948 14812 22883200 0 0 1090 111 37 17 46 0 1 0 0 175948 14812 22883200 0 0 1064 101 23 28 50 0 1 0 0 175948 14812 22883200 0 0 1066 100 20 31 49 0 1 0 0 175980 14820 22882400 048 1066 119 20 30 50 0 1 0 0 175980 14820 22882400 0 0 106786 19 31 50 0 1 0 0 175988 14820 22882400 0 0 1064 115 20 30 50 0 (...) Vmstat for Desktop P4 2.4 GHz 1024 MB RAM: This one's hyperthreaded too (apparent consumption never goes above 50%). However, while not doing any I/O either, you're always spending only 4% in user and 96% in system. This means that it might take 10x more time to complete the same operations, had it been user-cpu bound. And this is about what you observe. There clearly is a problem on the system installed on this machine. You should use strace to see what this machine does all the time, it is absolutely not expected that the user/system ratios change so much between two nearly identical systems. So there are system calls which eat all CPU. You may want to try strace -Tttt on the running process during a few tens of seconds. I guess you'll immediately find the culprit amongst the syscalls, and it might give you a clue. procs ---memory-- ---swap-- -io --system-- cpu r b swpd free buff cache si sobibo incs us sy id wa 1 0 0 594688 39340 292228005229 581 484 5 2 92 2 1 0 0 591208 39340 29222800 068 1116 545 15 14 71 0 1 0 0 591208 39340 29222800 0 0 1090 112 3 48 50 0 1 0 0 591208 39340 29222800 0 0 1089 124 2 48 50 0 1 0 0 591208 39340 29222800 0 0 1089 114 3 48 50 0 1 0 0 591208 39340 29222800 0 0 1090 120 1 49 50 0 1 0 0 591208 39340 29222800 024 1094 138 2 49 50 0 1 0 0 591256 39340 29222800 0 0 1090 118 2 48 50 0 (...) Regards, Willy - 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 1/2] Touchscreen support for sharp sl-5500
On Mon, Jul 25, 2005 at 10:16:05AM -0500, Dmitry Torokhov wrote: If the problem is that you have a single piece of hardware you need to bind several drivers to - I guess you will have to create a new sub-device bus for that. Or just register sub-devices on the same bus the parent device is registered on - I am not sure what is best in this particular case - I am not familiar with the arch. That is exactly the problem - these kinds of devices do _not_ fit well into the device model. A struct device for every different possible sub-unit is completely overkill. For instance, you may logically use one ADC and some GPIO lines on the device for X and something else for Y and they logically end up in different drivers. The problem is that the parent doesn't actually know how many devices to create nor what to call them, and they're logically indistinguishable from each other so there's no logical naming system. Can we change this to while (!kthread_should_stop()) to make me completely happy? I still ask, and I'll keep repeating this. What is the difference between this and the reference implementation which is known to work on other hardware. Let's not go all out on one implementation for one set of hardware, but try to work out what we need to do to the generic reference implementation to make it work on this hardware. IOW, you're working on the wrong version. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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: Power consumption HZ250 vs. HZ1000
Hi! I did some measurements in order to compare power drain with HZ250 and HZ1000. To measure the actual drain, I used the smart battery's internal measurement. (Available with acpi-sbs in /proc/acpi/sbs/SBS0/SB0/state.) No clue how accurate this is. Here some battery details, in case someone knows: charge reporting error: 25% SB specification:v1.1 (with PEC) manufacturer name: Panasonic manufacture date:2004-11-27 device name: 02ZL device chemistry:Lion Kernel: 2.6.13-rc3-mm1 + acpi-sbs CPU: cpu family: 6 model : 13 model name: Intel(R) Pentium(R) M processor 1.60GHz stepping : 6 The ondemand governor was running, using acpi_cpufreq. (Idle at 600MHz). Systems was running X11/KDE to get a more or less realistic scenario. No cron jobs, network traffic or additional applications. WLAN and built-in display were disabled completely, all fans and LEDs were off, internal hard disc was running. Additional peripherals: external keyboard, mouse, display and externally-powered hard disk (USB). USB devices prevent entering C3 and any interesting powersaving, try without USB... -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - 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 NFS 3/3] Replace nfs_block_bits() with roundup_pow_of_two()
On Sun, Jul 24, 2005 at 07:24:23PM -0400, Trond Myklebust wrote:
su den 24.07.2005 Klokka 19:09 (-0400) skreiv Trond Myklebust:
What non-power-of-two target? Anything _not_ aligned to a power of two
boundary is a BUG!
So we could simply replace the loop in nfs_block_bits() with call to
BUG()? :-
Furthermore, rounding UP in order to correct this non-alignment would
definitely be a bug.
If users choose to override the default rsize/wsize, that is almost
always in order to limit the UDP fragmentation per read/write request on
lossy networks. By rounding up, you are doubling the number of fragments
that the user requested instead of respecting the limit.
OK. Either way, this function can be cleaned up. Apparently the Plan 9
filesystem guys thought it rounds up.
What's your opinion of the following patch, which explicitly states the
intent of nfs_block_bits()? It still needs patch 1 and 2.
Thanks,
Rene
[PATCH 3/4] Simplify and rename nfs_block_bits() to rounddown_pow_of_two()
nfs_block_bits() doesn't have a lot to do with bits anymore. It can
also be implemented simpler and clearer with fls().
Signed-off-by: Rene Scharfe [EMAIL PROTECTED]
---
fs/nfs/inode.c | 21 +
1 files changed, 5 insertions(+), 16 deletions(-)
1388b63224334877b1b154e38ad9ee17f1726bca
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -185,20 +185,9 @@ nfs_umount_begin(struct super_block *sb)
rpc_killall_tasks(rpc);
}
-
-static inline unsigned long
-nfs_block_bits(unsigned long bsize)
+static inline unsigned long rounddown_pow_of_two(unsigned long x)
{
- /* make sure blocksize is a power of two */
- if (bsize (bsize - 1)) {
- unsigned char nrbits;
-
- for (nrbits = 31; nrbits !(bsize (1 nrbits)); nrbits--)
- ;
- bsize = 1 nrbits;
- }
-
- return bsize;
+ return x ? (1UL (fls(x) - 1)) : 0;
}
/*
@@ -222,7 +211,7 @@ nfs_block_size(unsigned long bsize)
else if (bsize = NFS_MAX_FILE_IO_BUFFER_SIZE)
bsize = NFS_MAX_FILE_IO_BUFFER_SIZE;
- return nfs_block_bits(bsize);
+ return rounddown_pow_of_two(bsize);
}
/*
@@ -319,10 +308,10 @@ nfs_sb_init(struct super_block *sb, rpc_
}
if (sb-s_blocksize == 0) {
- sb-s_blocksize = nfs_block_bits(server-wsize);
+ sb-s_blocksize = rounddown_pow_of_two(server-wsize);
sb-s_blocksize_bits = fls(sb-s_blocksize - 1);
}
- server-wtmult = nfs_block_bits(fsinfo.wtmult);
+ server-wtmult = rounddown_pow_of_two(fsinfo.wtmult);
server-dtsize = nfs_block_size(fsinfo.dtpref);
if (server-dtsize PAGE_CACHE_SIZE)
-
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 1/2] Touchscreen support for sharp sl-5500
On 7/25/05, Russell King [EMAIL PROTECTED] wrote: On Mon, Jul 25, 2005 at 10:16:05AM -0500, Dmitry Torokhov wrote: If the problem is that you have a single piece of hardware you need to bind several drivers to - I guess you will have to create a new sub-device bus for that. Or just register sub-devices on the same bus the parent device is registered on - I am not sure what is best in this particular case - I am not familiar with the arch. That is exactly the problem - these kinds of devices do _not_ fit well into the device model. A struct device for every different possible sub-unit is completely overkill. For instance, you may logically use one ADC and some GPIO lines on the device for X and something else for Y and they logically end up in different drivers. The problem is that the parent doesn't actually know how many devices to create nor what to call them, and they're logically indistinguishable from each other so there's no logical naming system. Then we should probably not try to force them into driver model. Have parent device register struct device and when sub-drivers register they could attach class devices (like input devices) directly to the main device thus hiding presence of sub-sections of the chip from sysfs completely. My point is that we should not be using class_interface here - its purpose is diferent. -- Dmitry - 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 1/2] Touchscreen support for sharp sl-5500
On Mon, Jul 25, 2005 at 06:56:07AM +0200, Pavel Machek wrote: Hi! This adds support for reading ADCs (etc), neccessary to operate touch screen on Sharp Zaurus sl-5500. I would like to know what the diffs are between my version (attached) and this version before they get applied. Hmm, diff looks quite big (attached), and I got it from lenz for 99% part. It looks like John's version is actually based on a previous revision of this driver. 8/ I have made quite a lot of cleanups to touchscreen part, and it seems to be acceptable by input people. I think it should go into drivers/input/touchscreen/collie_ts.c... Err, why should my assabet touchscreen be called collie_ts ? collie is just a platform which happens to use it - it's got no relevance to the driver naming at all. Also it looks to me like mcp.h should go into asm/arch-sa1100, so that other drivers can use it... That doesn't make sense when you have other non-SA1100 devices using mcp-core.c. Whether that happens or not I've no idea - I can't see what everyone's using out there (just like I've absolutely zero idea what collie folk are doing or not doing.) The only reason my version has not been submitted is because it lives in the drivers/misc directory, and mainline kernel folk don't like drivers which clutter up that directory. In fact, I had been told that drivers/misc should remain completely empty - which makes this set of miscellaneous drivers homeless. Could they simply live in arch/arm/mach-sa1100? Or is arch/arm/soc better place? arch/arm/soc? That means that (a) we end up with another directory to accumulate crap, (b) it's not a SoC so doesn't belong in a directory named as such, (c) it means that the MCP and UCB drivers get their individual files scattered throughout the kernel tree, one in this directory, one in that directory, one in another random directory. That's far from ideal. Anyway, summarising this, the results are that what we have here is a complete and utter mess. ;( So, if the collie folk would like to clean their changes up and send them to me as the driver author, I'll see about integrating them into my version and we'll take it from there. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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: Stripping in module
Michael Tokarev wrote: Wakko Warner wrote: [] I would also be interested in this. For instance the AIC7xxx driver has every PCI id in the module I think in the .modinfo section which is not truely required once depmod has been run. [] The .modinfo section, for example the PCI IDs, IS required for the module to function properly. The kernel and the module uses that tables to determime which devices to work with, and with which paramteres. I stripped out the section that had alias= and other vars from aic7xxx and it still worked. Not all modules worked doing that. -- Lab tests show that use of micro$oft causes cancer in lab animals - 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 1/2] Touchscreen support for sharp sl-5500
On Mon, Jul 25, 2005 at 11:02:43AM -0500, Dmitry Torokhov wrote: On 7/25/05, Russell King [EMAIL PROTECTED] wrote: On Mon, Jul 25, 2005 at 10:16:05AM -0500, Dmitry Torokhov wrote: If the problem is that you have a single piece of hardware you need to bind several drivers to - I guess you will have to create a new sub-device bus for that. Or just register sub-devices on the same bus the parent device is registered on - I am not sure what is best in this particular case - I am not familiar with the arch. That is exactly the problem - these kinds of devices do _not_ fit well into the device model. A struct device for every different possible sub-unit is completely overkill. For instance, you may logically use one ADC and some GPIO lines on the device for X and something else for Y and they logically end up in different drivers. The problem is that the parent doesn't actually know how many devices to create nor what to call them, and they're logically indistinguishable from each other so there's no logical naming system. Then we should probably not try to force them into driver model. Have parent device register struct device and when sub-drivers register they could attach class devices (like input devices) directly to the main device thus hiding presence of sub-sections of the chip from sysfs completely. My point is that we should not be using class_interface here - its purpose is diferent. If you look at _my_ version, you'll notice that it doesn't use the class interface stuff. A previous version of it did, and this seems to be what the collie stuff is based upon. What I suggest is that the collie folk need to update their driver to my version so that we don't have two different forks of the same driver in existance. Then we can start discussing whether things should be using kthreads or not. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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: Stripping in module
Well, the best you can do is strip -R .note -R .comment --strip-unneeded. If you go for more, module might not be loaded/initialized properlly Aleks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Budde, Marco Sent: Sunday, July 24, 2005 11:24 PM To: linux-kernel@vger.kernel.org Subject: Stripping in module Hi, at the moment I am packaging a Linux module as an RPM archive. Therefor I would like to remove some of the not exported/needed symbols (like e.g. static functions or constants) from the Linux module. What is the best way to do this with v2.6. I have tried e.g. to remove all symbols starting with telos from the module like this (after kbuild): strip -w -K '!telos*' -K 'telosi2c_usb_driver' telosi2c_linux.ko When I try to load such a module, insmod dies with a segmentation fault or the complete kernel dies (with invalid operand: ). What is the reason for this problem? What is the correct way using kbuild to remove some symbols? cu, Marco - 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/ - 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: help! kernel errors?
On Mon, Jul 25, 2005 at 03:03:03PM +0400, Vladimir V. Saveliev wrote: [EMAIL PROTECTED] wrote: Hello, I'm getting loads and loads of kernel errors in my syslog, but am unable to decipher them into anything meaningful. You may want to take a look at linux/Documentation/oops-tracing.txt And we're only interested in the *first* Oops, not in any later one. The first Oops is most probably the cause of all other Oopses. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Kernel doesn't free Cached Memory
Al Boldi wrote:
Dick Johnson wrote: {
On Fri, 2005-07-22 at 08:27 -0300, Vinicius wrote:
[...]
I have a server with 2 Pentium 4 HT processors and 32 GB of RAM,
this server runs lots of applications that consume lots of memory to.
When I stop this applications, the kernel doesn't free memory (the
memory still in use) and the server cache lots of memory (~27GB).
When I start this applications, the kernel sends Out of Memory
messages and kill some random applications.
...you might even need to turn memory over-commit off:
echo 0 /proc/sys/vm/overcommit_memory
}
That's in 2.4. In 2.6 it's:
echo 2 /proc/sys/vm/overcommit_memory
RHEL3 *is* a 2.4 kernel.
But the kernel doesn't honor no-overcommit in either version, i.e. it still
overcommits/pages-out loaded/running procs, thus invoking OOM!
Is there a way to make the kernel strictly honor the no-overcommit request?
Don't have swap?
--
-bill davidsen ([EMAIL PROTECTED])
The secret to procrastination is to put things off until the
last possible moment - but no longer -me
-
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] driver core: Add the ability to unbind drivers to devices from userspace
On 7/25/05, Dmitry Torokhov [EMAIL PROTECTED] wrote: On 7/25/05, Jon Smirl [EMAIL PROTECTED] wrote: On 7/25/05, Dmitry Torokhov [EMAIL PROTECTED] wrote: On Sunday 24 July 2005 23:09, Jon Smirl wrote: I just pulled from GIT to test bind/unbind. I couldn't get it to work; it isn't taking into account the CR on the end of the input value of the sysfs attribute. This patch will fix it but I'm sure there is a cleaner solution. echo -n should take care of this problem I think. That will work around it but I think we should fix it. Changing to strncmp() fixes most cases. - if (strcmp(name, dev-bus_id) == 0) + if (strncmp(name, dev-bus_id, strlen(dev-bus_id)) == 0) This will produce interesting results if you have both blah-1 and blah-10 devices on the bus. Then the better solution is to fix the generic attribute set code to strip leading and trailing white space. -- Jon Smirl [EMAIL PROTECTED] - 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: do_gettimeofday monotony?
On Mon, Jul 25, 2005 at 11:12:25AM -0400, Christopher Friesen wrote: Is do_gettimeofday supposed to be monotonous? Nope. I'm seeing time go backward by tiny amounts, and then progressing. Are you running NTP? Corrections could cause this. No. I am running a machine which often changes it clockspeed though. The bad news is that I don't appear to be able to reproduce this, there must be something specific that causes it. But then again, it wasn't a large effect. Is there another monotonous clock in the kernel that doesn't wrap (all that often)? Doesn't really need to be wall time. clock_gettime() Thank you. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - 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: Question re the dot releases such as 2.6.12.3
Gene Heskett wrote: Greetings; I just built what I thought was 2.6.12.3, but my script got a tummy ache because I didn't check the Makefile's EXTRA_VERSION, which was set to .2 in the .2 patch. Now my 2.6.12 modules will need a refresh build. :( So whats the proper patching sequence to build a 2.6.12.3? The dot-release patches are not incremental. You apply each one to the base 2.6.12 tree. -- Brian Gerst - 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: Kernel cached memory
Gábor Lénárt wrote: On Fri, Jul 22, 2005 at 05:46:58PM +0800, Ashley wrote: I've a server with 2 Operton 64bit CPU and 12G memory, and this server is used to run applications which will comsume huge memory, the problem is: when this aplications exits, the free memory of the server is still very low(accroding to the output of top), and from the output of command free, I can see that many GB memory was cached by kernel. Does anyone know how to free the kernel cached memory? thanks in advance. It's a very - very - very old and bad logic (at least nowdays) from the stone age to free up memory. It's very Microsoft to claim that the OS always knows best, and not let the user tune the system the way they want it tuned. And if that means to leave a bunch of free memory for absolute fastest availability, the admin should have that option. Memory is for using ... If you have memory why don't you want to use? For an actively used system, memory should be used as much as possible to maximize the performance. The only problem when kernel does not want to give back used memory for eg caching for an application though but it's another problem ... No, that's the problem he's trying to address. Anyway, want to have 'free memory' is a thing like having dozens of cars in your garage which don't want to be used ... Which wait to be used when needed, rather than after someone cleans a bunch of old junk out of them and scurries around the garage looking for the right car to let you use. Just because default operation works well for you, kindly don't try to convice us that there are no cases when the default operation is NOT optimal. And IMHO Linux is *way* too willing to evicy clean pages of my programs to use as disk buffer, so that when system memory is full I pay the overhead of TWO disk i/o's, one to finally write the data to the disk and one to read my program back in. If free software is about choice, I wish there was more in the area of how memory is used. -- -bill davidsen ([EMAIL PROTECTED]) The secret to procrastination is to put things off until the last possible moment - but no longer -me - 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 1/2] Touchscreen support for sharp sl-5500
On 7/25/05, Russell King [EMAIL PROTECTED] wrote: On Mon, Jul 25, 2005 at 11:02:43AM -0500, Dmitry Torokhov wrote: On 7/25/05, Russell King [EMAIL PROTECTED] wrote: On Mon, Jul 25, 2005 at 10:16:05AM -0500, Dmitry Torokhov wrote: If the problem is that you have a single piece of hardware you need to bind several drivers to - I guess you will have to create a new sub-device bus for that. Or just register sub-devices on the same bus the parent device is registered on - I am not sure what is best in this particular case - I am not familiar with the arch. That is exactly the problem - these kinds of devices do _not_ fit well into the device model. A struct device for every different possible sub-unit is completely overkill. For instance, you may logically use one ADC and some GPIO lines on the device for X and something else for Y and they logically end up in different drivers. The problem is that the parent doesn't actually know how many devices to create nor what to call them, and they're logically indistinguishable from each other so there's no logical naming system. Then we should probably not try to force them into driver model. Have parent device register struct device and when sub-drivers register they could attach class devices (like input devices) directly to the main device thus hiding presence of sub-sections of the chip from sysfs completely. My point is that we should not be using class_interface here - its purpose is diferent. If you look at _my_ version, you'll notice that it doesn't use the class interface stuff. A previous version of it did, and this seems to be what the collie stuff is based upon. I was only commenting on something that was posted on LKML for inclusion into input subtree that I am interested in. I don't track ARM development that closely. Where can we see your version, please? What I suggest is that the collie folk need to update their driver to my version so that we don't have two different forks of the same driver in existance. Then we can start discussing whether things should be using kthreads or not. Do you have any reason why, generally speaking, threads should not be used? They seem to clean up code in drivers quite a bit. -- Dmitry - 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 1/2] Touchscreen support for sharp sl-5500
On Mon, Jul 25, 2005 at 11:47:25AM -0500, Dmitry Torokhov wrote: On 7/25/05, Russell King [EMAIL PROTECTED] wrote: If you look at _my_ version, you'll notice that it doesn't use the class interface stuff. A previous version of it did, and this seems to be what the collie stuff is based upon. I was only commenting on something that was posted on LKML for inclusion into input subtree that I am interested in. I don't track ARM development that closely. Where can we see your version, please? See earlier in this thread, 24th July. What I suggest is that the collie folk need to update their driver to my version so that we don't have two different forks of the same driver in existance. Then we can start discussing whether things should be using kthreads or not. Do you have any reason why, generally speaking, threads should not be used? They seem to clean up code in drivers quite a bit. It depends what the reasoning is behind them. The touchscreen driver is threaded because it wants to collect touschreen samples independently of the availability of a user thread. Moreover, obtaining ADC samples needs a sleeping context since it may take a while to complete. However, putting all UCB interrupts into a thread does not make sense to me - if we allow UCB interrupts to sleep, it allows one UCB interrupt to be processed at the exclusion of the others. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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/
