[patch 15/24] ALPS: Fix resume for DualPoints

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread James Morris

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

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread Budde, Marco
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

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread David Gibson
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)

2005-07-25 Thread Mark Burton



[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

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread Andrew Morton
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

2005-07-25 Thread Dmitry Torokhov
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)

2005-07-25 Thread Amit S. Kale
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

2005-07-25 Thread Ciprian
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

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread Michael Krufky
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()

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread Denis Vlasenko
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

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread Evgeniy Polyakov
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

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread Dmitry Torokhov
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)

2005-07-25 Thread Stefan Seyfried
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/

2005-07-25 Thread Jörn Engel
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

2005-07-25 Thread zvi Dubitzki

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

2005-07-25 Thread Jan Engelhardt
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)

2005-07-25 Thread Dave Airlie

  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)

2005-07-25 Thread Stefan Seyfried
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

2005-07-25 Thread Sonny Rao
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...

2005-07-25 Thread Paolo Ornati
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

2005-07-25 Thread Ladislav Michl
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)

2005-07-25 Thread Loïc MARTIN
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

2005-07-25 Thread Bernd Petrovitsch
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

2005-07-25 Thread Richard Purdie
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

2005-07-25 Thread Seiji Kihara
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?

2005-07-25 Thread msmulders
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

2005-07-25 Thread Tony Lindgren
* 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

2005-07-25 Thread Tony Lindgren
* 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

2005-07-25 Thread Glennie Vignarajah
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?

2005-07-25 Thread msmulders

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

2005-07-25 Thread Tony Lindgren
* 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

2005-07-25 Thread Christoph Pleger
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

2005-07-25 Thread Nigel Rantor


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

2005-07-25 Thread Christian Hesse
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

2005-07-25 Thread Jan Engelhardt

 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?

2005-07-25 Thread Vladimir V. Saveliev

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

2005-07-25 Thread Wakko Warner
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

2005-07-25 Thread Michael Tokarev
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

2005-07-25 Thread Paulo Marques

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?

2005-07-25 Thread msmulders

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

2005-07-25 Thread Jiri Benc
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

2005-07-25 Thread bert hubert
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)

2005-07-25 Thread Theodore Ts'o
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)

2005-07-25 Thread Amit S. Kale
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-

2005-07-25 Thread Andreas Baer

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

2005-07-25 Thread Vojtech Pavlik
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

2005-07-25 Thread VASM
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

2005-07-25 Thread Sheo Shanker Prasad
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-

2005-07-25 Thread Paulo Marques

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

2005-07-25 Thread Marc Ballarin
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

2005-07-25 Thread Gene Heskett
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

2005-07-25 Thread Jon Smirl
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

2005-07-25 Thread Roger Heflin
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

2005-07-25 Thread Neil Horman
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.

2005-07-25 Thread Andrew Haninger
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

2005-07-25 Thread Pavel Machek
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

2005-07-25 Thread Andrew Haninger
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

2005-07-25 Thread Pavel Machek
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

2005-07-25 Thread Pavel Machek
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

2005-07-25 Thread Dmitry Torokhov
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. . .

2005-07-25 Thread Valdis . Kletnieks
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

2005-07-25 Thread Valdis . Kletnieks
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

2005-07-25 Thread Richard Purdie
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?

2005-07-25 Thread Christopher Friesen

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

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread Roger Heflin

/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

2005-07-25 Thread Patrick McHardy

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

2005-07-25 Thread Eric Leblond
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-

2005-07-25 Thread Willy Tarreau
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

2005-07-25 Thread Russell King
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

2005-07-25 Thread Pavel Machek
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()

2005-07-25 Thread Rene Scharfe
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

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread Russell King
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

2005-07-25 Thread Wakko Warner
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

2005-07-25 Thread Russell King
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

2005-07-25 Thread Aleksey Gorelov
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?

2005-07-25 Thread Erik Mouw
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

2005-07-25 Thread Bill Davidsen

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

2005-07-25 Thread Jon Smirl
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?

2005-07-25 Thread bert hubert
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

2005-07-25 Thread Brian Gerst

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

2005-07-25 Thread Bill Davidsen

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

2005-07-25 Thread Dmitry Torokhov
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

2005-07-25 Thread Russell King
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/


  1   2   3   >